From liach at openjdk.org Fri Jan 2 01:00:00 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 Jan 2026 01:00:00 GMT Subject: RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs [v2] In-Reply-To: References: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> Message-ID: On Mon, 29 Dec 2025 02:59:04 GMT, Jeremy Wood wrote: >> When decoding an uninterlaced 8-bit PNG image, the PNGImageDecoder is basically copying one byte at a time. >> >> This PR uses System.arraycopy instead, and it shows approx a 10% improvement. >> >> This graph shows the time it takes different decoders to convert a byte array into a BufferedImage as the size of the PNG image increases: >> >> Screenshot 2025-12-27 at 9 14 19?PM >> >> (This originally came to my attention when looking at an image in Java 1.8. There the ImageConsumer model took approx 400% longer than ImageIO. I was happy to see in recent JDKs that gap narrowed significantly, but there was still a noticeable 10% discrepancy.) >> >> I haven't tried submitting a performance enhancement PR before; I'm not sure if this issue meets this group's threshold for being worth addressing. And if it does: I'm not sure how to structure a unit test for it. > > Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: > > 8374377: Adding a JMH test for PNGImageDecoder > > This corroborates previous (more informal) tests that show approx a 10% improvement. > > Without this PR I observed this result on my Mac 26.2 laptop: > > ``` > Benchmark Mode Cnt Score Error Units > PNGImageDecoder_8bit_uninterlaced.measurePNGImageDecoder avgt 15 25.296 ? 0.521 ms/op > ``` > > With this PR I observed this result: > > ``` > Benchmark Mode Cnt Score Error Units > PNGImageDecoder_8bit_uninterlaced.measurePNGImageDecoder avgt 15 22.132 ? 0.378 ms/op > ``` With the patch, the code `case 8: bPixels[col+rowOffset] = rowByteBuffer[spos++];` at old line 415/new line 427 is now dead. Should we replace that site with an assertion, or just move the arraycopy code to there instead? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29004#issuecomment-3704286867 From serb at openjdk.org Fri Jan 2 01:31:10 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 2 Jan 2026 01:31:10 GMT Subject: RFR: 6562639: Wrong pixel bounds from TextLayout with white font In-Reply-To: <42XmY3f4QQ9W3we9fR70rzJpwdr0F5_vycMn610NRmw=.0952f2dc-04b1-4eea-88fd-7b3a85ba1118@github.com> References: <42XmY3f4QQ9W3we9fR70rzJpwdr0F5_vycMn610NRmw=.0952f2dc-04b1-4eea-88fd-7b3a85ba1118@github.com> Message-ID: On Sat, 13 Dec 2025 00:33:30 GMT, Daniel Gredler wrote: > One of the possible code paths for `TextLayout.getPixelBounds(...)` actually draws the text on a `Graphics2D` and checks the image pixels afterwards. The text is drawn over a white background, so if the user sets the font's foreground color to white then the text pixels cannot be detected (white on white). > > This PR fixes the issue by removing the code that sets the background to white, leaving the background as the default ARGB color (0 = transparent black). This does not cause a new problem for users who might set their font foreground color to transparent black, because transparent font foreground colors always return an empty bounds anyway (by virtue of being transparent). > > The updated code should also be slightly faster since it's doing less work, though I haven't run any performance tests. Seems the year in the header should be bumped =( ------------- Marked as reviewed by serb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28809#pullrequestreview-3622123574 From jwood at openjdk.org Fri Jan 2 02:34:55 2026 From: jwood at openjdk.org (Jeremy Wood) Date: Fri, 2 Jan 2026 02:34:55 GMT Subject: RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs [v3] In-Reply-To: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> References: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> Message-ID: > When decoding an uninterlaced 8-bit PNG image, the PNGImageDecoder is basically copying one byte at a time. > > This PR uses System.arraycopy instead, and it shows approx a 10% improvement. > > This graph shows the time it takes different decoders to convert a byte array into a BufferedImage as the size of the PNG image increases: > > Screenshot 2025-12-27 at 9 14 19?PM > > (This originally came to my attention when looking at an image in Java 1.8. There the ImageConsumer model took approx 400% longer than ImageIO. I was happy to see in recent JDKs that gap narrowed significantly, but there was still a noticeable 10% discrepancy.) > > I haven't tried submitting a performance enhancement PR before; I'm not sure if this issue meets this group's threshold for being worth addressing. And if it does: I'm not sure how to structure a unit test for it. Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: 8374377: test correctness of non-interlaced PNGs too Also this removes the performance comparison. (As of this writing there's a separate `test/micro/org/openjdk/bench/sun/awt/image/PNGImageDecoder_8bit_uninterlaced.java` file used to demonstrate that this change is more performant.) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29004/files - new: https://git.openjdk.org/jdk/pull/29004/files/c91a1f44..313cf437 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29004&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29004&range=01-02 Stats: 118 lines in 1 file changed: 37 ins; 64 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/29004.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29004/head:pull/29004 PR: https://git.openjdk.org/jdk/pull/29004 From jwood at openjdk.org Fri Jan 2 02:36:54 2026 From: jwood at openjdk.org (Jeremy Wood) Date: Fri, 2 Jan 2026 02:36:54 GMT Subject: RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs [v2] In-Reply-To: References: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> Message-ID: On Fri, 2 Jan 2026 00:57:05 GMT, Chen Liang wrote: >> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: >> >> 8374377: Adding a JMH test for PNGImageDecoder >> >> This corroborates previous (more informal) tests that show approx a 10% improvement. >> >> Without this PR I observed this result on my Mac 26.2 laptop: >> >> ``` >> Benchmark Mode Cnt Score Error Units >> PNGImageDecoder_8bit_uninterlaced.measurePNGImageDecoder avgt 15 25.296 ? 0.521 ms/op >> ``` >> >> With this PR I observed this result: >> >> ``` >> Benchmark Mode Cnt Score Error Units >> PNGImageDecoder_8bit_uninterlaced.measurePNGImageDecoder avgt 15 22.132 ? 0.378 ms/op >> ``` > > With the patch, the code `case 8: bPixels[col+rowOffset] = rowByteBuffer[spos++];` at old line 415/new line 427 is now dead. Should we replace that site with an assertion, or just move the arraycopy code to there instead? @liach thanks for checking that far ahead. I just confirmed that code is NOT dead, though. It should still be used for interlaced 8-bit PNGs. `spos` is incremented by 1, but `col` may be incremented by different amounts when we reach `col += colInc`. I rewrote the unit test just now so that: 1. It only tests for correctness (it does NOT try to measure performance anymore) 2. It tests correctness of 8-bit non-interlaced PNGs (the crux of this bug) and 8-bit interlaced PNGs. I tried removing the line you mentioned (`bPixels[col+rowOffset] = rowByteBuffer[spos++];`), and confirmed that the 8-bit interlaced PNG fails without that line. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29004#issuecomment-3704352410 From jwood at openjdk.org Fri Jan 2 02:42:50 2026 From: jwood at openjdk.org (Jeremy Wood) Date: Fri, 2 Jan 2026 02:42:50 GMT Subject: RFR: 4197755: Arc2D.getBounds() returns an unnecessarily large bounding box [v2] In-Reply-To: References: Message-ID: > 4197755 is marked as a duplicate of [JDK-8176501](https://bugs.openjdk.org/browse/JDK-8176501) , but I think that is a mistake. The complaint in that ticket still reproduces, and it is resolved in this PR. > > The complaint is: Arc2D.getBounds() is too large. If an Arc2D represents a small slice of an ellipse, then Arc2D.getBounds() always returns the size of the total ellipse. Arc2D.getBounds2D(), by contrast, has been "high-precision" for decades. > > This PR makes Arc2D.getBounds() resemble the same implementation already used in Area, CubicCurve2D, Line2D, Path2D, and QuadCurve2D: > > public Rectangle getBounds() { > return getBounds2D().getBounds(); > } > > > This modifies (simplifies) the javadoc for Arc2D.getBounds2D(). If we generally like this PR I assume we'll need a CSR to approve the javadoc change. Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: 4197755: Updating copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26715/files - new: https://git.openjdk.org/jdk/pull/26715/files/abe14a2d..de609581 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26715&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26715&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26715.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26715/head:pull/26715 PR: https://git.openjdk.org/jdk/pull/26715 From jwood at openjdk.org Fri Jan 2 02:43:39 2026 From: jwood at openjdk.org (Jeremy Wood) Date: Fri, 2 Jan 2026 02:43:39 GMT Subject: RFR: 8303904: [macos]Transparent Windows Paint Wrong (Opaque, Pixelated) w/o Volatile Buffering [v5] In-Reply-To: References: Message-ID: > When "swing.volatileImageBufferEnabled" is false: we were mistakenly using an opaque image at 100% resolution. > > In hindsight the original ticket probably should be split up into two distinct issues: > 1. The window is opaque, so pixels that should be transparent are black. > 2. The window is the wrong resolution. On a 200% resolution monitor it renders as if it were 100% (so it looks pixelated). > > This PR started 2 years ago. I got stuck and abandoned it, and @anass-baya picked it back up again this year: https://github.com/openjdk/jdk/pull/23430/ > > In that PR @mrserb suggested we try to fix this problem in RepaintManager (see https://github.com/openjdk/jdk/pull/23430#discussion_r2089555453 ), so that's what this PR does. > > Also this refactors some existing code (the BackingStoreMultiResolutionImage) from JViewport to wrap a BufferedImage in a smaller (transformed) MultiResolutionImage. Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: 8303904: Updating copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13196/files - new: https://git.openjdk.org/jdk/pull/13196/files/a3eb2d62..547b121e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13196&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13196&range=03-04 Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/13196.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13196/head:pull/13196 PR: https://git.openjdk.org/jdk/pull/13196 From jdv at openjdk.org Fri Jan 2 08:29:53 2026 From: jdv at openjdk.org (Jayathirth D V) Date: Fri, 2 Jan 2026 08:29:53 GMT Subject: RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs [v3] In-Reply-To: References: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> Message-ID: On Fri, 2 Jan 2026 02:34:55 GMT, Jeremy Wood wrote: >> When decoding an uninterlaced 8-bit PNG image, the PNGImageDecoder is basically copying one byte at a time. >> >> This PR uses System.arraycopy instead, and it shows approx a 10% improvement. >> >> This graph shows the time it takes different decoders to convert a byte array into a BufferedImage as the size of the PNG image increases: >> >> Screenshot 2025-12-27 at 9 14 19?PM >> >> (This originally came to my attention when looking at an image in Java 1.8. There the ImageConsumer model took approx 400% longer than ImageIO. I was happy to see in recent JDKs that gap narrowed significantly, but there was still a noticeable 10% discrepancy.) >> >> I haven't tried submitting a performance enhancement PR before; I'm not sure if this issue meets this group's threshold for being worth addressing. And if it does: I'm not sure how to structure a unit test for it. > > Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: > > 8374377: test correctness of non-interlaced PNGs too > > Also this removes the performance comparison. (As of this writing there's a separate `test/micro/org/openjdk/bench/sun/awt/image/PNGImageDecoder_8bit_uninterlaced.java` file used to demonstrate that this change is more performant.) Product change looks good to me. Some changes are needed to make the JMH test run. I have also given full functional test run after this update. Will update once i have results. test/micro/org/openjdk/bench/sun/awt/image/PNGImageDecoder_8bit_uninterlaced.java line 23: > 21: * questions. > 22: */ > 23: package org.openjdk.bench.sun.misc; package should be `org.openjdk.bench.sun.awt.image` test/micro/org/openjdk/bench/sun/awt/image/PNGImageDecoder_8bit_uninterlaced.java line 33: > 31: import org.openjdk.jmh.annotations.State; > 32: import org.openjdk.jmh.annotations.Warmup; > 33: import org.openjdk.jmh.infra.Blackhole; We need to import `import org.openjdk.jmh.annotations.Benchmark;` and `import org.openjdk.jmh.annotations.Setup;` also. Otherwise i am seeing compilation errors. ------------- PR Review: https://git.openjdk.org/jdk/pull/29004#pullrequestreview-3622415433 PR Review Comment: https://git.openjdk.org/jdk/pull/29004#discussion_r2657041047 PR Review Comment: https://git.openjdk.org/jdk/pull/29004#discussion_r2657043086 From jdv at openjdk.org Fri Jan 2 08:29:54 2026 From: jdv at openjdk.org (Jayathirth D V) Date: Fri, 2 Jan 2026 08:29:54 GMT Subject: RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs In-Reply-To: References: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> Message-ID: On Sun, 28 Dec 2025 17:36:51 GMT, Daniel Gredler wrote: >> When decoding an uninterlaced 8-bit PNG image, the PNGImageDecoder is basically copying one byte at a time. >> >> This PR uses System.arraycopy instead, and it shows approx a 10% improvement. >> >> This graph shows the time it takes different decoders to convert a byte array into a BufferedImage as the size of the PNG image increases: >> >> Screenshot 2025-12-27 at 9 14 19?PM >> >> (This originally came to my attention when looking at an image in Java 1.8. There the ImageConsumer model took approx 400% longer than ImageIO. I was happy to see in recent JDKs that gap narrowed significantly, but there was still a noticeable 10% discrepancy.) >> >> I haven't tried submitting a performance enhancement PR before; I'm not sure if this issue meets this group's threshold for being worth addressing. And if it does: I'm not sure how to structure a unit test for it. > > Do you have a JMH test for the attached graph that can be used to replicate locally? If you've not used JMH before, or haven't used it in the context of OpenJDK, you can check existing performance tests in the `test/micro` directory, or see this example (not part of OpenJDK, just something I've used in the past to test things locally): https://gist.github.com/gredler/e8ff9d52440cd103cd5b7766defff5b8 > @gredler Thanks. I'm not familiar with JMH. > > I used your example (and a lot of googling) to set up a basic benchmark that is now attached to this ticket. > > For a 2500x2500 px image, the time on my Mac went from approx 25.296 to 22.132. > > Is there any interest in me: A. Creating a graph as the image dimensions change? B. Contrasting this implementation against ImageIO? > > I'm not sure what the long-term usage of this benchmark .java would be. If this PR is accepted: the slower "before" time will not be relevant to anyone going forward. > > And the most important question (IMO): is there enough interest in this group to review/accept this proposal? (If not: I can stop spending time on it.) > ## Before this PR > > ``` > Benchmark Mode Cnt Score Error Units > PNGImageDecoder_8bit_uninterlaced.measurePNGImageDecoder avgt 15 25.296 ? 0.521 ms/op > ``` > > ## After this PR > > ``` > Benchmark Mode Cnt Score Error Units > PNGImageDecoder_8bit_uninterlaced.measurePNGImageDecoder avgt 15 22.132 ? 0.378 ms/op > ``` I also see similar improvements when i run the newly added JMH test locally on my Macbook. Before PR: Benchmark Mode Cnt Score Error Units PNGImageDecoder_8bit_uninterlaced.measurePNGImageDecoder avgt 15 26.428 ? 0.127 ms/op After PR: After PR: Benchmark Mode Cnt Score Error Units PNGImageDecoder_8bit_uninterlaced.measurePNGImageDecoder avgt 15 22.930 ? 0.125 ms/op Its good that we are adding a JMH test for performance bench-marking. I am trying to get information on how frequently these JMH tests are run for Java performance bench-marking. This test will help in future if there are any perf regressions for this particular scenario. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29004#issuecomment-3704739763 From psadhukhan at openjdk.org Fri Jan 2 09:51:20 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 2 Jan 2026 09:51:20 GMT Subject: Integrated: 4337898: Serializing DefaultTableCellRenderer changes colors In-Reply-To: <7RPOHaLbFxCEgnFqBg5HFXrU1t6gx3CsiiqwbRKN3VQ=.3213266e-8746-4bdf-a4a4-0d3ea7969087@github.com> References: <7RPOHaLbFxCEgnFqBg5HFXrU1t6gx3CsiiqwbRKN3VQ=.3213266e-8746-4bdf-a4a4-0d3ea7969087@github.com> Message-ID: On Fri, 28 Nov 2025 06:29:45 GMT, Prasanta Sadhukhan wrote: > When a `JTable `using any objects of type `DefaultTableCellRenderer`, or subclasses, is serialized, > the colors used to render cells in the JTable subsequent to the call to `writeObject()` > are forced to the default colors for `DefaultTableCellRenderer`'s immediate base class, JLabel, causing the colors > defined in the JTable (typically black on white) to be ignored. > > The problem seems to stem from a call to > `installUI `in the `writeObject()` method of `JLabel`, `DefaultTableCellRenderer`'s base class. > This causes the `setForeground` and `setBackground` methods to be invoked with specific colors, which turn out to be JLabel's defaults. > Invoking these methods subsequently with parameters of null restores normal operation same as is explicitly done in `DefaultTableCellRenderer.updateUI()` > https://github.com/openjdk/jdk/blob/195b36f90b789b64f4a0fc867c620935d609a455/src/java.desktop/share/classes/javax/swing/table/DefaultTableCellRenderer.java#L159-L162 > > CI run is ok.. This pull request has now been integrated. Changeset: 2ea3c00e Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/2ea3c00e4f2a6e8c0a55039aee6fdfc8194a70a7 Stats: 151 lines in 2 files changed: 150 ins; 0 del; 1 mod 4337898: Serializing DefaultTableCellRenderer changes colors Reviewed-by: azvegint ------------- PR: https://git.openjdk.org/jdk/pull/28549 From psadhukhan at openjdk.org Fri Jan 2 09:56:37 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 2 Jan 2026 09:56:37 GMT Subject: Integrated: 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the =?UTF-8?B?4oCcTm90aGluZ+KAnQ==?= menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test In-Reply-To: <8vHbWPbMWKh65Jn3GJkBum39hNQYmedfV7AbtVojmAw=.0ba484fa-2762-44a7-93c0-6dca2a7211c3@github.com> References: <8vHbWPbMWKh65Jn3GJkBum39hNQYmedfV7AbtVojmAw=.0ba484fa-2762-44a7-93c0-6dca2a7211c3@github.com> Message-ID: On Thu, 18 Dec 2025 03:32:15 GMT, Prasanta Sadhukhan wrote: > When user selects any menu item from "No nothing". the following exception happens because PassFailJFrame logArea is not created > > java.lang.NullPointerException: Cannot invoke "javax.swing.JTextArea.append(String)" because "PassFailJFrame.logArea" is null > at PassFailJFrame.lambda$log$0(PassFailJFrame.java:1353) > at PassFailJFrame.invokeOnEDT(PassFailJFrame.java:570) > at PassFailJFrame.invokeOnEDTUncheckedException(PassFailJFrame.java:584) > at PassFailJFrame.log(PassFailJFrame.java:1353) > at MenuItemTestHelper.lambda$createNoNothingMenu$0(MenuItemTestHelper.java:118) > > > Fix is to create log area This pull request has now been integrated. Changeset: 05d2f7f4 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/05d2f7f4080f5cc6d3eef97878806e28773d6f70 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test Reviewed-by: serb, aivanov, dnguyen ------------- PR: https://git.openjdk.org/jdk/pull/28887 From psadhukhan at openjdk.org Fri Jan 2 09:58:56 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 2 Jan 2026 09:58:56 GMT Subject: RFR: 8373650: Test javax/swing/JMenuItem/6458123/ManualBug6458123.java fails because the check icons are not aligned properly as expected [v2] In-Reply-To: References: Message-ID: > Check/radiobutton icon are not aligned properly in RTL. `WindowsMenuItemUI `uses `MenuItemLayoutHelper.layoutMenuItem` to do the layout which calls `doRTLColumnLayout `which calculates x positions in `calcXPositionsRTL `and then again aligns in `alignRects`. However, since in Windows historically radiobutton/check icon was not drawn or drawn below the menuitem image icon (since image icon and check icon was drawn in the same layout space and not separately) the aligned x position of check icons returned from `MenuItemLayoutHelper` was not correct but since `MenuItemLayoutHelper` alignment is used in other L&Fs also so we need to realign it in windows specific class i.e in WindowsIconFactory in paintIcon > > Before fix > > image > > After fix > > image Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Alignment fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28889/files - new: https://git.openjdk.org/jdk/pull/28889/files/f0b99274..bb174e9b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28889&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28889&range=00-01 Stats: 12 lines in 1 file changed: 6 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/28889.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28889/head:pull/28889 PR: https://git.openjdk.org/jdk/pull/28889 From psadhukhan at openjdk.org Fri Jan 2 09:58:57 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 2 Jan 2026 09:58:57 GMT Subject: RFR: 8373650: Test javax/swing/JMenuItem/6458123/ManualBug6458123.java fails because the check icons are not aligned properly as expected [v2] In-Reply-To: References: Message-ID: <-YkA4Us3iCuf0jXpuJxdpU_ypJ89H2iRTdaEnnkpOqA=.0277bd2a-7b9a-424a-a276-bfcfc3fd521d@github.com> On Wed, 24 Dec 2025 01:51:44 GMT, Damon Nguyen wrote: > Any reason why the "After fix" image also has the "Radio button" dot misaligned still? Fixed image ------------- PR Comment: https://git.openjdk.org/jdk/pull/28889#issuecomment-3704931780 From psadhukhan at openjdk.org Fri Jan 2 10:05:57 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 2 Jan 2026 10:05:57 GMT Subject: RFR: 6441373: Editing JTable is not Serializable [v7] In-Reply-To: References: Message-ID: > Issue is when JTable is in editing mode, it is not Serializable as it gives exception > > java.io.NotSerializableException: java.lang.reflect.Constructor > at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1149) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1502) > at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1467) > at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1385) > at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1143) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1502) > ....... > > > It is caused by creation of `GenericEditor` class which uses a non-serializable Constructor field. > This is fixed by making the field transient.. > Also, `editorRemover` field is made transient as it is object of `CellEditorRemover` class which is not Serializable.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Component count leakage fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28627/files - new: https://git.openjdk.org/jdk/pull/28627/files/57f55306..d4cf50ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28627&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28627&range=05-06 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28627.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28627/head:pull/28627 PR: https://git.openjdk.org/jdk/pull/28627 From dgredler at openjdk.org Fri Jan 2 10:46:49 2026 From: dgredler at openjdk.org (Daniel Gredler) Date: Fri, 2 Jan 2026 10:46:49 GMT Subject: RFR: 6562639: Wrong pixel bounds from TextLayout with white font [v2] In-Reply-To: <42XmY3f4QQ9W3we9fR70rzJpwdr0F5_vycMn610NRmw=.0952f2dc-04b1-4eea-88fd-7b3a85ba1118@github.com> References: <42XmY3f4QQ9W3we9fR70rzJpwdr0F5_vycMn610NRmw=.0952f2dc-04b1-4eea-88fd-7b3a85ba1118@github.com> Message-ID: > One of the possible code paths for `TextLayout.getPixelBounds(...)` actually draws the text on a `Graphics2D` and checks the image pixels afterwards. The text is drawn over a white background, so if the user sets the font's foreground color to white then the text pixels cannot be detected (white on white). > > This PR fixes the issue by removing the code that sets the background to white, leaving the background as the default ARGB color (0 = transparent black). This does not cause a new problem for users who might set their font foreground color to transparent black, because transparent font foreground colors always return an empty bounds anyway (by virtue of being transparent). > > The updated code should also be slightly faster since it's doing less work, though I haven't run any performance tests. Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision: Update copyright year 2025 -> 2026 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28809/files - new: https://git.openjdk.org/jdk/pull/28809/files/ad0ff83a..dbac4944 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28809&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28809&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28809.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28809/head:pull/28809 PR: https://git.openjdk.org/jdk/pull/28809 From serb at openjdk.org Fri Jan 2 10:46:50 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 2 Jan 2026 10:46:50 GMT Subject: RFR: 6562639: Wrong pixel bounds from TextLayout with white font [v2] In-Reply-To: References: <42XmY3f4QQ9W3we9fR70rzJpwdr0F5_vycMn610NRmw=.0952f2dc-04b1-4eea-88fd-7b3a85ba1118@github.com> Message-ID: On Fri, 2 Jan 2026 10:43:20 GMT, Daniel Gredler wrote: >> One of the possible code paths for `TextLayout.getPixelBounds(...)` actually draws the text on a `Graphics2D` and checks the image pixels afterwards. The text is drawn over a white background, so if the user sets the font's foreground color to white then the text pixels cannot be detected (white on white). >> >> This PR fixes the issue by removing the code that sets the background to white, leaving the background as the default ARGB color (0 = transparent black). This does not cause a new problem for users who might set their font foreground color to transparent black, because transparent font foreground colors always return an empty bounds anyway (by virtue of being transparent). >> >> The updated code should also be slightly faster since it's doing less work, though I haven't run any performance tests. > > Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year 2025 -> 2026 Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28809#pullrequestreview-3622904219 From dgredler at openjdk.org Fri Jan 2 10:54:44 2026 From: dgredler at openjdk.org (Daniel Gredler) Date: Fri, 2 Jan 2026 10:54:44 GMT Subject: RFR: 8374340: FontRenderContext instance variables should be final [v3] In-Reply-To: References: Message-ID: > Instances of FontRenderContext are immutable, but its instance variables are not declared final. Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision: Update copyright year 2025 -> 2026 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28981/files - new: https://git.openjdk.org/jdk/pull/28981/files/2f279543..f0b35529 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28981&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28981&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28981.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28981/head:pull/28981 PR: https://git.openjdk.org/jdk/pull/28981 From aturbanov at openjdk.org Fri Jan 2 11:03:12 2026 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 2 Jan 2026 11:03:12 GMT Subject: RFR: 8374340: FontRenderContext instance variables should be final [v3] In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 10:54:44 GMT, Daniel Gredler wrote: >> Instances of FontRenderContext are immutable, but its instance variables are not declared final. > > Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year 2025 -> 2026 Marked as reviewed by aturbanov (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28981#pullrequestreview-3622931023 From aivanov at openjdk.org Fri Jan 2 13:15:53 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 2 Jan 2026 13:15:53 GMT Subject: RFR: 8374340: FontRenderContext instance variables should be final [v3] In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 10:54:44 GMT, Daniel Gredler wrote: >> Instances of FontRenderContext are immutable, but its instance variables are not declared final. > > Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year 2025 -> 2026 Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28981#pullrequestreview-3623105389 From dgredler at openjdk.org Fri Jan 2 14:16:06 2026 From: dgredler at openjdk.org (Daniel Gredler) Date: Fri, 2 Jan 2026 14:16:06 GMT Subject: RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs [v3] In-Reply-To: References: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> Message-ID: <0zJ7el7WYzjTl4D8DRHZgBhGvAaOTPQh_oMaZaPOVcM=.10067a3c-7659-4c8f-922b-e7048273431d@github.com> On Fri, 2 Jan 2026 02:34:55 GMT, Jeremy Wood wrote: >> When decoding an uninterlaced 8-bit PNG image, the PNGImageDecoder is basically copying one byte at a time. >> >> This PR uses System.arraycopy instead, and it shows approx a 10% improvement. >> >> This graph shows the time it takes different decoders to convert a byte array into a BufferedImage as the size of the PNG image increases: >> >> Screenshot 2025-12-27 at 9 14 19?PM >> >> (This originally came to my attention when looking at an image in Java 1.8. There the ImageConsumer model took approx 400% longer than ImageIO. I was happy to see in recent JDKs that gap narrowed significantly, but there was still a noticeable 10% discrepancy.) >> >> I haven't tried submitting a performance enhancement PR before; I'm not sure if this issue meets this group's threshold for being worth addressing. And if it does: I'm not sure how to structure a unit test for it. > > Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: > > 8374377: test correctness of non-interlaced PNGs too > > Also this removes the performance comparison. (As of this writing there's a separate `test/micro/org/openjdk/bench/sun/awt/image/PNGImageDecoder_8bit_uninterlaced.java` file used to demonstrate that this change is more performant.) The change in `PNGImageDecoder` makes sense to me, although I haven't had a chance to run the JMH benchmark locally on my end. test/jdk/sun/awt/image/png/PNGImageDecoder_8bit_performance.java line 60: > 58: * This test has never failed. > 59: */ > 60: public class PNGImageDecoder_8bit_performance { Since this is now purely a regression test and the performance aspect has been removed, perhaps rename to e.g. `PngImageDecoder8BitTest`? test/jdk/sun/awt/image/png/PNGImageDecoder_8bit_performance.java line 174: > 172: BufferedImage actual = models[1].load(imageData); > 173: > 174: testCorrectness(expected, actual); Am I correct in assuming that both models end up using `PNGImageDecoder` under the covers? If so, won't `expected` and `actual` always match, even if there is a bug in `PNGImageDecoder`? I wonder if it would be better to keep the original `BufferedImage` around (the one we draw on), use it as `expected`, and compare it to the two model-generated images. test/jdk/sun/awt/image/png/PNGImageDecoder_8bit_performance.java line 233: > 231: BufferedImage actual) { > 232: if (expected.getWidth() != actual.getWidth()) { > 233: throw new Error(); Probably better to throw a `RuntimeException` instead of an `Error` here and below (at least that seems to be the convention that I've seen elsewhere). Also always best to include a short error message that helps zero in on the exact issue if it ever fails. test/jdk/sun/awt/image/png/PNGImageDecoder_8bit_performance.java line 243: > 241: int argb2 = actual.getRGB(x, y); > 242: if (argb1 != argb2) { > 243: throw new Error("x = " + x + ", y = " + y); `Error` -> `RuntimeException`, and I'd probably also include the two colors that didn't match in the message test/micro/org/openjdk/bench/sun/awt/image/PNGImageDecoder_8bit_uninterlaced.java line 76: > 74: @Benchmark > 75: public void measurePNGImageDecoder(Blackhole bh) throws Exception { > 76: Image img = Toolkit.getDefaultToolkit().createImage(pngImageData); Does the `BufferedImage` need to be created this way, or could it be simplified down to a simple `ImageIO.read()` with a `ByteArrayInputStream`? test/micro/org/openjdk/bench/sun/awt/image/PNGImageDecoder_8bit_uninterlaced.java line 172: > 170: * any accuracy. > 171: */ > 172: private static void testCorrectness(BufferedImage expected, Should the correctness check in the JMH benchmark be removed, since that's handled in the unit test? ------------- PR Review: https://git.openjdk.org/jdk/pull/29004#pullrequestreview-3623125208 PR Review Comment: https://git.openjdk.org/jdk/pull/29004#discussion_r2657759447 PR Review Comment: https://git.openjdk.org/jdk/pull/29004#discussion_r2657780639 PR Review Comment: https://git.openjdk.org/jdk/pull/29004#discussion_r2657765027 PR Review Comment: https://git.openjdk.org/jdk/pull/29004#discussion_r2657763413 PR Review Comment: https://git.openjdk.org/jdk/pull/29004#discussion_r2657722294 PR Review Comment: https://git.openjdk.org/jdk/pull/29004#discussion_r2657715697 From aivanov at openjdk.org Fri Jan 2 19:53:54 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 2 Jan 2026 19:53:54 GMT Subject: RFR: 8373650: Test javax/swing/JMenuItem/6458123/ManualBug6458123.java fails because the check icons are not aligned properly as expected [v2] In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 09:58:56 GMT, Prasanta Sadhukhan wrote: >> Check/radiobutton icon are not aligned properly in RTL. `WindowsMenuItemUI `uses `MenuItemLayoutHelper.layoutMenuItem` to do the layout which calls `doRTLColumnLayout `which calculates x positions in `calcXPositionsRTL `and then again aligns in `alignRects`. However, since in Windows historically radiobutton/check icon was not drawn or drawn below the menuitem image icon (since image icon and check icon was drawn in the same layout space and not separately) the aligned x position of check icons returned from `MenuItemLayoutHelper` was not correct but since `MenuItemLayoutHelper` alignment is used in other L&Fs also so we need to realign it in windows specific class i.e in WindowsIconFactory in paintIcon >> >> Before fix >> >> image >> >> After fix >> >> image > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Alignment fix src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 922: > 920: x + OFFSET, > 921: (icon.getIconHeight() <= 16) ? y + OFFSET : (y + icon.getIconHeight() / 2), state); > 922: } else if (icon.getIconWidth() <= 16) { I don't understand why painting an icon and check marks / radio bullets in RTL case depends on the width of the icon but there's no such dependency in LTR case. Shouldn't the performed menu layout handle these cases? src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 923: > 921: (icon.getIconHeight() <= 16) ? y + OFFSET : (y + icon.getIconHeight() / 2), state); > 922: } else if (icon.getIconWidth() <= 16) { > 923: if ((c instanceof JMenuItem mi) && mi.getText().isEmpty()) { The condition `(c instanceof JMenuItem mi)` is always `true` according to the assert at line 881: https://github.com/openjdk/jdk/blob/2daf12edd24e641d4d7706d582994c2b3fe95e87/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java#L881 where `menuItem` is a field in `VistaMenuItemCheckIcon`, the type of the field is `JMenuItem`. This means, you can use `menuItem` and ignore the passed in parameter `c`. src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 936: > 934: skin.paintSkin(g, > 935: (type == JRadioButtonMenuItem.class) ? (x + 3 * OFFSET) : (x + 4 * OFFSET), > 936: (icon.getIconHeight() <= 16) ? y + OFFSET : (y + icon.getIconHeight() / 2), state); I wonder why painting the skin for radio button menu requires such a fix up whereas it's not required for `JCheckBoxMenuItem`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28889#discussion_r2658309916 PR Review Comment: https://git.openjdk.org/jdk/pull/28889#discussion_r2658290233 PR Review Comment: https://git.openjdk.org/jdk/pull/28889#discussion_r2658311962 From alexey.ivanov at oracle.com Fri Jan 2 20:02:12 2026 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 2 Jan 2026 20:02:12 +0000 Subject: Request to work on JDK-8374344 In-Reply-To: References: Message-ID: Hi Vignesh, This question belongs in core-libs-dev because the component of the issue is *core-libs*. On 2025-12-27 15:53, Vignesh Sadanki wrote: > Hi everyone, > > I'm new to OpenJDK and interested in contributing. I came across bug > JDK-8374344 ("Clarifying HttpURLConnection.disconnect() Behavior > Regarding Resource Management and Connection Pooling") and would like > to work on it. > > Could someone confirm if this bug is available for me to take, and if > there are any guidelines I should follow? > > Thanks, > Vignesh Sadankae -- Regards, Alexey From alexey.ivanov at oracle.com Fri Jan 2 20:22:34 2026 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 2 Jan 2026 20:22:34 +0000 Subject: Request to work on JDK-8263355 In-Reply-To: References: Message-ID: <08d33418-038e-41a5-9545-7ea97bd1debf@oracle.com> Hi Vignesh, JDK-8263355 is currently unassigned. However, I can't reproduce the problem with a recent build of mainline JDK on macOS. Can you? Neither can I reproduce the bug with a recent build of Oracle JDK 17 that is explicitly mentioned in the comment [1]. It seems the bug has been fixed since that time. You can find the guidelines in OpenJDK Developers? Guide [2]. On 2025-12-27 15:11, Vignesh Sadanki wrote: > Hi everyone, > > I'm new to OpenJDK and interested in contributing. I came across bug > JDK-8263355 ("Drag color change appearing at mouse press itself") and > would like to work on it. > > Could someone confirm if this bug is available for me to take, and if > there are any guidelines I should follow? > > Thanks, > Vignesh Sadankae -- Regards, Alexey [1] https://bugs.openjdk.org/browse/JDK-8263355?focusedId=14407198&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14407198 [2] https://openjdk.org/guide/ From jwood at openjdk.org Sat Jan 3 04:37:21 2026 From: jwood at openjdk.org (Jeremy Wood) Date: Sat, 3 Jan 2026 04:37:21 GMT Subject: RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs [v4] In-Reply-To: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> References: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> Message-ID: > When decoding an uninterlaced 8-bit PNG image, the PNGImageDecoder is basically copying one byte at a time. > > This PR uses System.arraycopy instead, and it shows approx a 10% improvement. > > This graph shows the time it takes different decoders to convert a byte array into a BufferedImage as the size of the PNG image increases: > > Screenshot 2025-12-27 at 9 14 19?PM > > (This originally came to my attention when looking at an image in Java 1.8. There the ImageConsumer model took approx 400% longer than ImageIO. I was happy to see in recent JDKs that gap narrowed significantly, but there was still a noticeable 10% discrepancy.) > > I haven't tried submitting a performance enhancement PR before; I'm not sure if this issue meets this group's threshold for being worth addressing. And if it does: I'm not sure how to structure a unit test for it. Jeremy Wood has updated the pull request incrementally with eight additional commits since the last revision: - 8374377: trivial line break formatting - 8374377: test orig img against decoded img This is in response to: https://github.com/openjdk/jdk/pull/29004#discussion_r2657780639 - 8374377: changing Error to RTE This is in response to: https://github.com/openjdk/jdk/pull/29004#discussion_r2657765027 - 8374377: changing Error to RTE This is in response to: https://github.com/openjdk/jdk/pull/29004#discussion_r2657763413 - 8374377: changing classname This is in response to: hhttps://github.com/openjdk/jdk/pull/29004#discussion_r2657759447 - 8374377: removing correctness check The PNGImageDecoder_8bit_performance.java /PngImageDecoder8BitTest.java class will test correctness. This is in response to: https://github.com/openjdk/jdk/pull/29004#discussion_r2657715697 - 8374377: adding imports This is in response to: https://github.com/openjdk/jdk/pull/29004#discussion_r2657043086 - 8374377: fixing package This is in response to: https://github.com/openjdk/jdk/pull/29004#discussion_r2657041047 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29004/files - new: https://git.openjdk.org/jdk/pull/29004/files/313cf437..c609b00e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29004&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29004&range=02-03 Stats: 503 lines in 3 files changed: 225 ins; 277 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29004.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29004/head:pull/29004 PR: https://git.openjdk.org/jdk/pull/29004 From jwood at openjdk.org Sat Jan 3 04:37:26 2026 From: jwood at openjdk.org (Jeremy Wood) Date: Sat, 3 Jan 2026 04:37:26 GMT Subject: RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs [v3] In-Reply-To: <0zJ7el7WYzjTl4D8DRHZgBhGvAaOTPQh_oMaZaPOVcM=.10067a3c-7659-4c8f-922b-e7048273431d@github.com> References: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> <0zJ7el7WYzjTl4D8DRHZgBhGvAaOTPQh_oMaZaPOVcM=.10067a3c-7659-4c8f-922b-e7048273431d@github.com> Message-ID: <2DkgEa6Dp91-h-tFO1FoEq72Lw1HhhTvTIBC9kTvHJo=.aebcc163-96d9-4de3-81c6-cdc03b856a4c@github.com> On Fri, 2 Jan 2026 13:56:54 GMT, Daniel Gredler wrote: >> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: >> >> 8374377: test correctness of non-interlaced PNGs too >> >> Also this removes the performance comparison. (As of this writing there's a separate `test/micro/org/openjdk/bench/sun/awt/image/PNGImageDecoder_8bit_uninterlaced.java` file used to demonstrate that this change is more performant.) > > test/jdk/sun/awt/image/png/PNGImageDecoder_8bit_performance.java line 60: > >> 58: * This test has never failed. >> 59: */ >> 60: public class PNGImageDecoder_8bit_performance { > > Since this is now purely a regression test and the performance aspect has been removed, perhaps rename to e.g. `PngImageDecoder8BitTest`? This is renamed > test/jdk/sun/awt/image/png/PNGImageDecoder_8bit_performance.java line 233: > >> 231: BufferedImage actual) { >> 232: if (expected.getWidth() != actual.getWidth()) { >> 233: throw new Error(); > > Probably better to throw a `RuntimeException` instead of an `Error` here and below (at least that seems to be the convention that I've seen elsewhere). Also always best to include a short error message that helps zero in on the exact issue if it ever fails. This is updated > test/jdk/sun/awt/image/png/PNGImageDecoder_8bit_performance.java line 243: > >> 241: int argb2 = actual.getRGB(x, y); >> 242: if (argb1 != argb2) { >> 243: throw new Error("x = " + x + ", y = " + y); > > `Error` -> `RuntimeException`, and I'd probably also include the two colors that didn't match in the message This is updated > Am I correct in assuming that both models end up using PNGImageDecoder under the covers? It'd make a lot of sense if they shared the same code, but no. It is my understanding we have two separate decoders. ImageIO uses the com.sun.imageio.plugins.png.PNGImageReader , and this PR modifies the sun.awt.image.PNGImageDecoder. The fact that the PNGImageDecoder is a little slower than the ImageIO classes came to my attention because I was comparing the two decoding models, and the older sun.awt classes [appear to be faster](https://docs.google.com/spreadsheets/d/1SoiqnDPSVALb4xraq5hBIGAQLrOQTzA-XuVDohZbCJs/edit?usp=sharing) than the newer ImageIO classes -- except for this one case. This PR will fix this discrepancy. (Separately: I've submitted a few other PRs that similarly focus on the older sun.awt decoding classes. See [JDK-8357034](https://github.com/openjdk/jdk/pull/25264) , [JDK-8356320](https://github.com/openjdk/jdk/pull/25076) , [JDK-8356137](https://github.com/openjdk/jdk/pull/25044) , [JDK-8351913](https://github.com/openjdk/jdk/pull/24271) . They generally compare the two models against each other for correctness. I also visually inspected the results at the time to triple-check, but in all of those cases ImageIO was already "doing the right thing". I guess I've made it my goal to bring the older sun.awt decoding classes up-to-date.) > I wonder if it would be better to keep the original BufferedImage around (the one we draw on), use it as expected, and compare it to the two model-generated images. Sure. I updated this test so it avoids decoding with ImageIO. > test/micro/org/openjdk/bench/sun/awt/image/PNGImageDecoder_8bit_uninterlaced.java line 76: > >> 74: @Benchmark >> 75: public void measurePNGImageDecoder(Blackhole bh) throws Exception { >> 76: Image img = Toolkit.getDefaultToolkit().createImage(pngImageData); > > Does the `BufferedImage` need to be created this way, or could it be simplified down to a simple `ImageIO.read()` with a `ByteArrayInputStream`? ImageIO is a different rendering model; the BufferedImage needs to be created this way. (Or maybe (?) with a PixelGrabber or MediaTracker?) > test/micro/org/openjdk/bench/sun/awt/image/PNGImageDecoder_8bit_uninterlaced.java line 172: > >> 170: * any accuracy. >> 171: */ >> 172: private static void testCorrectness(BufferedImage expected, > > Should the correctness check in the JMH benchmark be removed, since that's handled in the unit test? Yes, this is updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29004#discussion_r2658709767 PR Review Comment: https://git.openjdk.org/jdk/pull/29004#discussion_r2658709810 PR Review Comment: https://git.openjdk.org/jdk/pull/29004#discussion_r2658709798 PR Review Comment: https://git.openjdk.org/jdk/pull/29004#discussion_r2658709823 PR Review Comment: https://git.openjdk.org/jdk/pull/29004#discussion_r2658709730 PR Review Comment: https://git.openjdk.org/jdk/pull/29004#discussion_r2658709701 From jwood at openjdk.org Sat Jan 3 04:37:29 2026 From: jwood at openjdk.org (Jeremy Wood) Date: Sat, 3 Jan 2026 04:37:29 GMT Subject: RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs [v3] In-Reply-To: References: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> Message-ID: On Fri, 2 Jan 2026 08:13:40 GMT, Jayathirth D V wrote: >> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: >> >> 8374377: test correctness of non-interlaced PNGs too >> >> Also this removes the performance comparison. (As of this writing there's a separate `test/micro/org/openjdk/bench/sun/awt/image/PNGImageDecoder_8bit_uninterlaced.java` file used to demonstrate that this change is more performant.) > > test/micro/org/openjdk/bench/sun/awt/image/PNGImageDecoder_8bit_uninterlaced.java line 23: > >> 21: * questions. >> 22: */ >> 23: package org.openjdk.bench.sun.misc; > > package should be `org.openjdk.bench.sun.awt.image` This is updated > test/micro/org/openjdk/bench/sun/awt/image/PNGImageDecoder_8bit_uninterlaced.java line 33: > >> 31: import org.openjdk.jmh.annotations.State; >> 32: import org.openjdk.jmh.annotations.Warmup; >> 33: import org.openjdk.jmh.infra.Blackhole; > > We need to import `import org.openjdk.jmh.annotations.Benchmark;` and `import org.openjdk.jmh.annotations.Setup;` also. Otherwise i am seeing compilation errors. This is updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29004#discussion_r2658709686 PR Review Comment: https://git.openjdk.org/jdk/pull/29004#discussion_r2658709693 From serb at openjdk.org Sun Jan 4 02:18:58 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 4 Jan 2026 02:18:58 GMT Subject: RFR: 8369311: De-problemlist 8305915 since the issue is not reproducible In-Reply-To: <4LAh1FXUeqdb0B1nNWCmB7TDzBJp1wwH6h6X8FaddFw=.c1f92044-9389-4541-88b7-a7356e82abef@github.com> References: <4LAh1FXUeqdb0B1nNWCmB7TDzBJp1wwH6h6X8FaddFw=.c1f92044-9389-4541-88b7-a7356e82abef@github.com> Message-ID: On Tue, 7 Oct 2025 16:43:08 GMT, Tejesh R wrote: > [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915) is not reproducible with multiple CI checks. The main test java/awt/Frame/FrameLocation/FrameLocation.java which was failing is been missed in the Problem-List file, rather java/awt/Frame/SizeMinimizedTest.java is been added which still doesn't fail. So de-problemlisting with a sub-task and closing the main bug as "Not-reproducible". Is this PR still active, or is there any ongoing work on it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27678#issuecomment-3707539754 From serb at openjdk.org Sun Jan 4 02:20:09 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 4 Jan 2026 02:20:09 GMT Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression [v5] In-Reply-To: <26Gs2omFeLXWjo85AUbAb34PpolWLLsjB2aMS92fNKY=.04fb0491-212d-4212-9dde-08250f361053@github.com> References: <26Gs2omFeLXWjo85AUbAb34PpolWLLsjB2aMS92fNKY=.04fb0491-212d-4212-9dde-08250f361053@github.com> Message-ID: On Mon, 10 Nov 2025 22:24:52 GMT, Archie Cobbs wrote: >> This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings. >> >> Summary of code changes: >> >> * Add new warning and associated lint category `"suppression"` >> * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ? >> * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect. >> * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression. >> * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations. >> * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break >> >> ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 135 commits: > > - Suppress new unnecessary suppresion warnings created by recent commits. > - Merge branch 'master' into JDK-8344159 > - Merge branch 'master' into JDK-8344159 to fix conflict. > - Merge branch 'master' into JDK-8344159 to fix conflict. > - Merge branch 'master' into JDK-8344159 to fix conflicts. > - Add clarifying comment. > - Merge branch 'master' into JDK-8344159 > - Change inner class name to avoid shadowing superclass name. > - Add a couple of code clarification comments. > - Refactor test to avoid requiring changes to TestRunner. > - ... and 125 more: https://git.openjdk.org/jdk/compare/43afce54...aaf029e8 Is this PR still active, or is there any ongoing work on it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3707541329 From serb at openjdk.org Sun Jan 4 02:26:58 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 4 Jan 2026 02:26:58 GMT Subject: RFR: 8372651: Remove unreachable code in sun.awt.geom.AreaOp::calculate In-Reply-To: References: Message-ID: <8jhNR0pBZLvp7BI7FpAQqJqy5QpKwp06nlylHL-yn0Y=.2ae581a2-953b-4d9f-af4e-77a49ec1a18f@github.com> On Thu, 27 Nov 2025 08:58:50 GMT, wb-zjp846396 wrote: > JBS: https://bugs.openjdk.org/browse/JDK-8372651 > > Summary: > - Fix a constant-condition `if` statement in `AreaOp.java` line 160. > - Clean up dead code and clarify control flow. > > Testing: > - No functional modification involved. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28528#pullrequestreview-3624635232 From acobbs at openjdk.org Sun Jan 4 16:27:07 2026 From: acobbs at openjdk.org (Archie Cobbs) Date: Sun, 4 Jan 2026 16:27:07 GMT Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression [v5] In-Reply-To: References: <26Gs2omFeLXWjo85AUbAb34PpolWLLsjB2aMS92fNKY=.04fb0491-212d-4212-9dde-08250f361053@github.com> Message-ID: On Sun, 4 Jan 2026 02:17:35 GMT, Sergey Bylokhov wrote: >> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 135 commits: >> >> - Suppress new unnecessary suppresion warnings created by recent commits. >> - Merge branch 'master' into JDK-8344159 >> - Merge branch 'master' into JDK-8344159 to fix conflict. >> - Merge branch 'master' into JDK-8344159 to fix conflict. >> - Merge branch 'master' into JDK-8344159 to fix conflicts. >> - Add clarifying comment. >> - Merge branch 'master' into JDK-8344159 >> - Change inner class name to avoid shadowing superclass name. >> - Add a couple of code clarification comments. >> - Refactor test to avoid requiring changes to TestRunner. >> - ... and 125 more: https://git.openjdk.org/jdk/compare/43afce54...aaf029e8 > > Is this PR still active, or is there any ongoing work on it? Hi @mrserb, > Is this PR still active, or is there any ongoing work on it? Work is completed to the point that it's ready for review, but this is a new feature and as such is lower priority than other changes that are currently being worked on. In the meantime if you're interested in doing any testing or playing around with it I'd love to hear any feedback. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3708223841 From acobbs at openjdk.org Sun Jan 4 18:04:45 2026 From: acobbs at openjdk.org (Archie Cobbs) Date: Sun, 4 Jan 2026 18:04:45 GMT Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression [v6] In-Reply-To: References: Message-ID: <6hvrmK7tyWXAYYeJoCF9jP68LEShyo45T3vo3o7eF2U=.a8c1af86-8025-447e-b531-d195409e3117@github.com> > This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings. > > Summary of code changes: > > * Add new warning and associated lint category `"suppression"` > * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ? > * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect. > * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression. > * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations. > * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break > > ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 139 commits: - Update copyrights to 2026. - Merge branch 'master' into JDK-8344159 - Merge branch 'master' into JDK-8344159 - Merge branch 'master' into JDK-8344159 - Suppress new unnecessary suppresion warnings created by recent commits. - Merge branch 'master' into JDK-8344159 - Merge branch 'master' into JDK-8344159 to fix conflict. - Merge branch 'master' into JDK-8344159 to fix conflict. - Merge branch 'master' into JDK-8344159 to fix conflicts. - Add clarifying comment. - ... and 129 more: https://git.openjdk.org/jdk/compare/53824cf2...cad270ed ------------- Changes: https://git.openjdk.org/jdk/pull/25167/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=05 Stats: 1695 lines in 35 files changed: 1492 ins; 49 del; 154 mod Patch: https://git.openjdk.org/jdk/pull/25167.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25167/head:pull/25167 PR: https://git.openjdk.org/jdk/pull/25167 From psadhukhan at openjdk.org Mon Jan 5 07:07:28 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 5 Jan 2026 07:07:28 GMT Subject: RFR: 8373650: Test javax/swing/JMenuItem/6458123/ManualBug6458123.java fails because the check icons are not aligned properly as expected [v3] In-Reply-To: References: Message-ID: > Check/radiobutton icon are not aligned properly in RTL. `WindowsMenuItemUI `uses `MenuItemLayoutHelper.layoutMenuItem` to do the layout which calls `doRTLColumnLayout `which calculates x positions in `calcXPositionsRTL `and then again aligns in `alignRects`. However, since in Windows historically radiobutton/check icon was not drawn or drawn below the menuitem image icon (since image icon and check icon was drawn in the same layout space and not separately) the aligned x position of check icons returned from `MenuItemLayoutHelper` was not correct but since `MenuItemLayoutHelper` alignment is used in other L&Fs also so we need to realign it in windows specific class i.e in WindowsIconFactory in paintIcon > > Before fix > > image > > After fix > > image Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Use menuItem var ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28889/files - new: https://git.openjdk.org/jdk/pull/28889/files/bb174e9b..c4bda416 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28889&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28889&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28889.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28889/head:pull/28889 PR: https://git.openjdk.org/jdk/pull/28889 From psadhukhan at openjdk.org Mon Jan 5 07:07:32 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 5 Jan 2026 07:07:32 GMT Subject: RFR: 8373650: Test javax/swing/JMenuItem/6458123/ManualBug6458123.java fails because the check icons are not aligned properly as expected [v2] In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 19:48:55 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Alignment fix > > src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 922: > >> 920: x + OFFSET, >> 921: (icon.getIconHeight() <= 16) ? y + OFFSET : (y + icon.getIconHeight() / 2), state); >> 922: } else if (icon.getIconWidth() <= 16) { > > I don't understand why painting an icon and check marks / radio bullets in RTL case depends on the width of the icon but there's no such dependency in LTR case. > > Shouldn't the performed menu layout handle these cases? As I see, MenuItemLayout handler's x position calculation for RTL depends on icon rect width https://github.com/openjdk/jdk/blob/6eaabed55ca4670d8c317f0a4323ccea4dd0b9ca/src/java.desktop/share/classes/sun/swing/MenuItemLayoutHelper.java#L737-L741 but LTR doesn't depend on rect width https://github.com/openjdk/jdk/blob/6eaabed55ca4670d8c317f0a4323ccea4dd0b9ca/src/java.desktop/share/classes/sun/swing/MenuItemLayoutHelper.java#L726-L730 > src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 923: > >> 921: (icon.getIconHeight() <= 16) ? y + OFFSET : (y + icon.getIconHeight() / 2), state); >> 922: } else if (icon.getIconWidth() <= 16) { >> 923: if ((c instanceof JMenuItem mi) && mi.getText().isEmpty()) { > > The condition `(c instanceof JMenuItem mi)` is always `true` according to the assert at line 881: > > https://github.com/openjdk/jdk/blob/2daf12edd24e641d4d7706d582994c2b3fe95e87/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java#L881 > > where `menuItem` is a field in `VistaMenuItemCheckIcon`, the type of the field is `JMenuItem`. > > This means, you can use `menuItem` and ignore the passed in parameter `c`. ok > src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 936: > >> 934: skin.paintSkin(g, >> 935: (type == JRadioButtonMenuItem.class) ? (x + 3 * OFFSET) : (x + 4 * OFFSET), >> 936: (icon.getIconHeight() <= 16) ? y + OFFSET : (y + icon.getIconHeight() / 2), state); > > I wonder why painting the skin for radio button menu requires such a fix up whereas it's not required for `JCheckBoxMenuItem`. it is taken care via ternary operator, width/spread of check mark is usually more than radio bullet so starting point of checkmark is considered a little ahead compared to radio bullet ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28889#discussion_r2660479443 PR Review Comment: https://git.openjdk.org/jdk/pull/28889#discussion_r2660478835 PR Review Comment: https://git.openjdk.org/jdk/pull/28889#discussion_r2660480432 From dgredler at openjdk.org Mon Jan 5 11:29:57 2026 From: dgredler at openjdk.org (Daniel Gredler) Date: Mon, 5 Jan 2026 11:29:57 GMT Subject: RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs [v3] In-Reply-To: <2DkgEa6Dp91-h-tFO1FoEq72Lw1HhhTvTIBC9kTvHJo=.aebcc163-96d9-4de3-81c6-cdc03b856a4c@github.com> References: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> <0zJ7el7WYzjTl4D8DRHZgBhGvAaOTPQh_oMaZaPOVcM=.10067a3c-7659-4c8f-922b-e7048273431d@github.com> <2DkgEa6Dp91-h-tFO1FoEq72Lw1HhhTvTIBC9kTvHJo=.aebcc163-96d9-4de3-81c6-cdc03b856a4c@github.com> Message-ID: On Sat, 3 Jan 2026 04:31:15 GMT, Jeremy Wood wrote: >> test/jdk/sun/awt/image/png/PngImageDecoder8BitTest.java line 174: >> >>> (failed to retrieve contents of file, check the PR for context) >> Am I correct in assuming that both models end up using `PNGImageDecoder` under the covers? If so, won't `expected` and `actual` always match, even if there is a bug in `PNGImageDecoder`? I wonder if it would be better to keep the original `BufferedImage` around (the one we draw on), use it as `expected`, and compare it to the two model-generated images. > >> Am I correct in assuming that both models end up using PNGImageDecoder under the covers? > > It'd make a lot of sense if they shared the same code, but no. It is my understanding we have two separate decoders. ImageIO uses the com.sun.imageio.plugins.png.PNGImageReader , and this PR modifies the sun.awt.image.PNGImageDecoder. > > The fact that the PNGImageDecoder is a little slower than the ImageIO classes came to my attention because I was comparing the two decoding models, and the older sun.awt classes [appear to be faster](https://docs.google.com/spreadsheets/d/1SoiqnDPSVALb4xraq5hBIGAQLrOQTzA-XuVDohZbCJs/edit?usp=sharing) than the newer ImageIO classes -- except for this one case. This PR will fix this discrepancy. > > (Separately: I've submitted a few other PRs that similarly focus on the older sun.awt decoding classes. See [JDK-8357034](https://github.com/openjdk/jdk/pull/25264) , [JDK-8356320](https://github.com/openjdk/jdk/pull/25076) , [JDK-8356137](https://github.com/openjdk/jdk/pull/25044) , [JDK-8351913](https://github.com/openjdk/jdk/pull/24271) . They generally compare the two models against each other for correctness. I also visually inspected the results at the time to triple-check, but in all of those cases ImageIO was already "doing the right thing". I guess I've made it my goal to bring the older sun.awt decoding classes up-to-date.) > >> I wonder if it would be better to keep the original BufferedImage around (the one we draw on), use it as expected, and compare it to the two model-generated images. > > Sure. I updated this test so it avoids decoding with ImageIO. I had no idea, thanks for clarifying! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29004#discussion_r2661180031 From prr at openjdk.org Mon Jan 5 21:00:21 2026 From: prr at openjdk.org (Phil Race) Date: Mon, 5 Jan 2026 21:00:21 GMT Subject: RFR: 8336654: [lworld] Tests depending on sun.awt.AppContext can fail when run with migrated classes [v2] In-Reply-To: <7_hiO6S4AOb-puw71FWgTLyXgCkz96jP0iQx_uQP7Q4=.1f0741e8-10b2-4216-b7cc-543174ea85a0@github.com> References: <7_hiO6S4AOb-puw71FWgTLyXgCkz96jP0iQx_uQP7Q4=.1f0741e8-10b2-4216-b7cc-543174ea85a0@github.com> Message-ID: > The problem is that Boolean will be a value type in the future (Project Valhalla) > and so it can't be the referent of a Reference. > > In this code, the abstract class that creates the Reference accepts a generic type so isn't in control of what it receives. > > The concrete class that extends the generic class has no idea what the super class implementation does, > so has no way to know that it might do something that is invalid for a value type. > > That's an interesting observation for Valhalla (that the code that does something inappropriate for a value type > isn't the source of the value type) but I don't think we need to be concerned > about that here because we can see reasons to do this anyway. > > The specific classes exist because a nominal singleton for the VM may need to be private to an AppContext. > This is a concept from applets but also from webstart where we have a single JVM that may be running code > from different origins that needs to be partitioned and sand boxed. > > This concept is obsolete now as applets and webstart are no longer supported, and the Security Manager > is disabled, further undermining any way to support partitioning. > > This specific case of a Boolean created from the value of a Java System Property looks like it never needed > this partitioning, so the minimal fix is to stop using RecyclableSingleton for it, and just cache the value of that. > > The next level of fix is to note that since AppContext is obsolete, there is no need for RecyclableSingleton > to use AppContext specific values, making RecyclableSingleton just a lazy initialization mechanism for the singleton. > > Given that removing the obsolete AppContext is on the TBD list - and some JDK components have already > removed per-AppContext code - and we'd probably come back to this in JDK 25 anyway it seems best > to get it over with. > > That does mean that one other place in sun.awt.ImageCache needed to be updated too. > > Also one test that explicitly checked that AppContexts were used for UI instances is obsolete and removed. > > Note that RecyclableSingleton also offers some lazy initialisation benefit, and is widely used in Aqua, > so going further and removing that probably isn't something we want to do at all, and certainly not here. Phil Race 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 - 8336654 ------------- Changes: https://git.openjdk.org/jdk/pull/22868/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22868&range=01 Stats: 129 lines in 3 files changed: 7 ins; 117 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/22868.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22868/head:pull/22868 PR: https://git.openjdk.org/jdk/pull/22868 From kcr at openjdk.org Mon Jan 5 21:16:05 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 5 Jan 2026 21:16:05 GMT Subject: Withdrawn: 8319880: JTextField text selection doesn't stop if ended during loss of window focus In-Reply-To: <8C7JlJLvlLU7h1xLroYjh-Ry5ozMVkeVPdoe4sAuRZo=.57f0780b-a58d-45ff-bd75-2881301c4b56@github.com> References: <8C7JlJLvlLU7h1xLroYjh-Ry5ozMVkeVPdoe4sAuRZo=.57f0780b-a58d-45ff-bd75-2881301c4b56@github.com> Message-ID: On Mon, 1 Dec 2025 16:07:56 GMT, Anass Baya wrote: > **Analysis :** > The issue is that on Win32, if the window is not active, we dont receive mouse events because we release the capture > So the problem is the following: > We start selecting text from the right to the extreme left. > Then we switch to another window( the window lose focus ), and we release the mouse > But when we return to the window, the caret drag is still active and does not stop. as the window did not recieved the mouse release event > > **Proposed fix:** > In the Caret class, we added a logic to ignore the drag if the focus was lost due to window switching unless a new mouse press happens This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/28582 From prr at openjdk.org Mon Jan 5 21:40:43 2026 From: prr at openjdk.org (Phil Race) Date: Mon, 5 Jan 2026 21:40:43 GMT Subject: RFR: 8336654: [lworld] Tests depending on sun.awt.AppContext can fail when run with migrated classes [v3] In-Reply-To: <7_hiO6S4AOb-puw71FWgTLyXgCkz96jP0iQx_uQP7Q4=.1f0741e8-10b2-4216-b7cc-543174ea85a0@github.com> References: <7_hiO6S4AOb-puw71FWgTLyXgCkz96jP0iQx_uQP7Q4=.1f0741e8-10b2-4216-b7cc-543174ea85a0@github.com> Message-ID: > The problem is that Boolean will be a value type in the future (Project Valhalla) > and so it can't be the referent of a Reference. > > In this code, the abstract class that creates the Reference accepts a generic type so isn't in control of what it receives. > > The concrete class that extends the generic class has no idea what the super class implementation does, > so has no way to know that it might do something that is invalid for a value type. > > That's an interesting observation for Valhalla (that the code that does something inappropriate for a value type > isn't the source of the value type) but I don't think we need to be concerned > about that here because we can see reasons to do this anyway. > > The specific classes exist because a nominal singleton for the VM may need to be private to an AppContext. > This is a concept from applets but also from webstart where we have a single JVM that may be running code > from different origins that needs to be partitioned and sand boxed. > > This concept is obsolete now as applets and webstart are no longer supported, and the Security Manager > is disabled, further undermining any way to support partitioning. > > This specific case of a Boolean created from the value of a Java System Property looks like it never needed > this partitioning, so the minimal fix is to stop using RecyclableSingleton for it, and just cache the value of that. > > The next level of fix is to note that since AppContext is obsolete, there is no need for RecyclableSingleton > to use AppContext specific values, making RecyclableSingleton just a lazy initialization mechanism for the singleton. > > Given that removing the obsolete AppContext is on the TBD list - and some JDK components have already > removed per-AppContext code - and we'd probably come back to this in JDK 25 anyway it seems best > to get it over with. > > That does mean that one other place in sun.awt.ImageCache needed to be updated too. > > Also one test that explicitly checked that AppContexts were used for UI instances is obsolete and removed. > > Note that RecyclableSingleton also offers some lazy initialisation benefit, and is widely used in Aqua, > so going further and removing that probably isn't something we want to do at all, and certainly not here. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8336654 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22868/files - new: https://git.openjdk.org/jdk/pull/22868/files/4b9f7914..6ca4a3e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22868&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22868&range=01-02 Stats: 18 lines in 1 file changed: 0 ins; 18 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22868.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22868/head:pull/22868 PR: https://git.openjdk.org/jdk/pull/22868 From tr at openjdk.org Tue Jan 6 05:55:46 2026 From: tr at openjdk.org (Tejesh R) Date: Tue, 6 Jan 2026 05:55:46 GMT Subject: RFR: 8369311: De-problemlist 8305915 since the issue is not reproducible In-Reply-To: References: <4LAh1FXUeqdb0B1nNWCmB7TDzBJp1wwH6h6X8FaddFw=.c1f92044-9389-4541-88b7-a7356e82abef@github.com> Message-ID: <_apD_k2e4GiiSimWsHFQgPe7dIteOg4f5sO0SSVif4g=.8fbf0662-b1e7-4d23-b35e-7e07cf9c9b93@github.com> On Sun, 4 Jan 2026 02:16:22 GMT, Sergey Bylokhov wrote: > Is this PR still active, or is there any ongoing work on it? Some verification pending, I'll move this one to draft. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27678#issuecomment-3713211980 From jdv at openjdk.org Tue Jan 6 06:25:32 2026 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 6 Jan 2026 06:25:32 GMT Subject: RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs In-Reply-To: References: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> Message-ID: On Sun, 28 Dec 2025 17:36:51 GMT, Daniel Gredler wrote: >> When decoding an uninterlaced 8-bit PNG image, the PNGImageDecoder is basically copying one byte at a time. >> >> This PR uses System.arraycopy instead, and it shows approx a 10% improvement. >> >> This graph shows the time it takes different decoders to convert a byte array into a BufferedImage as the size of the PNG image increases: >> >> Screenshot 2025-12-27 at 9 14 19?PM >> >> (This originally came to my attention when looking at an image in Java 1.8. There the ImageConsumer model took approx 400% longer than ImageIO. I was happy to see in recent JDKs that gap narrowed significantly, but there was still a noticeable 10% discrepancy.) >> >> I haven't tried submitting a performance enhancement PR before; I'm not sure if this issue meets this group's threshold for being worth addressing. And if it does: I'm not sure how to structure a unit test for it. > > Do you have a JMH test for the attached graph that can be used to replicate locally? If you've not used JMH before, or haven't used it in the context of OpenJDK, you can check existing performance tests in the `test/micro` directory, or see this example (not part of OpenJDK, just something I've used in the past to test things locally): https://gist.github.com/gredler/e8ff9d52440cd103cd5b7766defff5b8 > > @gredler Thanks. I'm not familiar with JMH. > > I used your example (and a lot of googling) to set up a basic benchmark that is now attached to this ticket. > > For a 2500x2500 px image, the time on my Mac went from approx 25.296 to 22.132. > > Is there any interest in me: A. Creating a graph as the image dimensions change? B. Contrasting this implementation against ImageIO? > > I'm not sure what the long-term usage of this benchmark .java would be. If this PR is accepted: the slower "before" time will not be relevant to anyone going forward. > > And the most important question (IMO): is there enough interest in this group to review/accept this proposal? (If not: I can stop spending time on it.) > > ## Before this PR > > ``` > > Benchmark Mode Cnt Score Error Units > > PNGImageDecoder_8bit_uninterlaced.measurePNGImageDecoder avgt 15 25.296 ? 0.521 ms/op > > ``` > > > > > > > > > > > > > > > > > > > > > > > > ## After this PR > > ``` > > Benchmark Mode Cnt Score Error Units > > PNGImageDecoder_8bit_uninterlaced.measurePNGImageDecoder avgt 15 22.132 ? 0.378 ms/op > > ``` > > I also see similar improvements when i run the newly added JMH test locally on my Macbook. > > Before PR: Benchmark Mode Cnt Score Error Units PNGImageDecoder_8bit_uninterlaced.measurePNGImageDecoder avgt 15 26.428 ? 0.127 ms/op > > After PR: After PR: Benchmark Mode Cnt Score Error Units PNGImageDecoder_8bit_uninterlaced.measurePNGImageDecoder avgt 15 22.930 ? 0.125 ms/op > > Its good that we are adding a JMH test for performance bench-marking. I am trying to get information on how frequently these JMH tests are run for Java performance bench-marking. This test will help in future if there are any perf regressions for this particular scenario. The JMH test needs to be moved under `java/awt/image` directory. We can add the JMH test in this instance but we run only a limited set of JMH tests for weekly/promoted builds. This test will not be maintained or run as part of weekly/promoted builds. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29004#issuecomment-3713285051 From jdv at openjdk.org Tue Jan 6 06:25:32 2026 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 6 Jan 2026 06:25:32 GMT Subject: RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs [v3] In-Reply-To: References: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> Message-ID: On Fri, 2 Jan 2026 08:27:45 GMT, Jayathirth D V wrote: > Product change looks good to me. Some changes are needed to make the JMH test run. > > I have also given full functional test run after this update. Will update once i have results. Full functional test is green. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29004#issuecomment-3713287139 From psadhukhan at openjdk.org Tue Jan 6 11:10:01 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 6 Jan 2026 11:10:01 GMT Subject: RFR: 4765299: componentResized() not always called with nested JSplitPanes Message-ID: If a component "comp" be nested inside a "inner" JSplitPane with VERTICAL_SPLIT mode and if then "inner" be nested inside a "outer" JSplitPane with HORIZONTAL_SPLIT mode and a component listener is added to "comp" then with this setup, componentResized() on the listener is called ONLY when the divider of "outer" is moved manually however, it is not called when the divider of "outer" is moved using "One touch expandable" left button at the top of the divider. This is because the `layoutContainer` bails out if the width or height is 0 which logically should be to bail out if both width and height is 0 and when "One touch expandable" left button is pressed, width becomes 0 so `layoutContainer` bails out without sending the event. With this fix, componentResized is called No regression is observed in CI. ------------- Commit messages: - 4765299: componentResized() not always called with nested JSplitPanes - 4765299: componentResized() not always called with nested JSplitPanes - 4765299: componentResized() not always called with nested JSplitPanes - 4765299: componentResized() not always called with nested JSplitPanes - 4765299: componentResized() not always called with nested JSplitPanes Changes: https://git.openjdk.org/jdk/pull/29063/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29063&range=00 Issue: https://bugs.openjdk.org/browse/JDK-4765299 Stats: 176 lines in 2 files changed: 174 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29063.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29063/head:pull/29063 PR: https://git.openjdk.org/jdk/pull/29063 From dgredler at openjdk.org Tue Jan 6 14:38:12 2026 From: dgredler at openjdk.org (Daniel Gredler) Date: Tue, 6 Jan 2026 14:38:12 GMT Subject: RFR: 8374340: FontRenderContext instance variables should be final [v3] In-Reply-To: References: Message-ID: <_iB9grZnwZL464YNI7qSC703i6ffAMK0Rauph1mgnk0=.00ab684e-11e8-46ad-a8e0-c6194037c2cb@github.com> On Thu, 25 Dec 2025 03:46:26 GMT, Sergey Bylokhov wrote: >> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year 2025 -> 2026 > > Marked as reviewed by serb (Reviewer). @mrserb @prrace This PR technically needs a re-review after the update to the copyright year (2025 -> 2026). The order of the keywords also changed since you had a look ("transient final" -> "final transient"). ------------- PR Comment: https://git.openjdk.org/jdk/pull/28981#issuecomment-3714934156 From jwood at openjdk.org Tue Jan 6 15:50:05 2026 From: jwood at openjdk.org (Jeremy Wood) Date: Tue, 6 Jan 2026 15:50:05 GMT Subject: RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs [v5] In-Reply-To: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> References: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> Message-ID: > When decoding an uninterlaced 8-bit PNG image, the PNGImageDecoder is basically copying one byte at a time. > > This PR uses System.arraycopy instead, and it shows approx a 10% improvement. > > This graph shows the time it takes different decoders to convert a byte array into a BufferedImage as the size of the PNG image increases: > > Screenshot 2025-12-27 at 9 14 19?PM > > (This originally came to my attention when looking at an image in Java 1.8. There the ImageConsumer model took approx 400% longer than ImageIO. I was happy to see in recent JDKs that gap narrowed significantly, but there was still a noticeable 10% discrepancy.) > > I haven't tried submitting a performance enhancement PR before; I'm not sure if this issue meets this group's threshold for being worth addressing. And if it does: I'm not sure how to structure a unit test for it. Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: 8374377: move jmh test to java/awt/image This is in response to: https://github.com/openjdk/jdk/pull/29004#issuecomment-3713285051 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29004/files - new: https://git.openjdk.org/jdk/pull/29004/files/c609b00e..fbc8dc62 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29004&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29004&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29004.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29004/head:pull/29004 PR: https://git.openjdk.org/jdk/pull/29004 From jwood at openjdk.org Tue Jan 6 15:58:21 2026 From: jwood at openjdk.org (Jeremy Wood) Date: Tue, 6 Jan 2026 15:58:21 GMT Subject: RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs [v5] In-Reply-To: References: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> Message-ID: <0vwHR4CLk_g-5rIXMWe5RdNnS5jvz5KCcqQAKKhBE7c=.b3df16bf-7879-4fb3-932e-e65b36ece725@github.com> On Tue, 6 Jan 2026 15:50:05 GMT, Jeremy Wood wrote: >> When decoding an uninterlaced 8-bit PNG image, the PNGImageDecoder is basically copying one byte at a time. >> >> This PR uses System.arraycopy instead, and it shows approx a 10% improvement. >> >> This graph shows the time it takes different decoders to convert a byte array into a BufferedImage as the size of the PNG image increases: >> >> Screenshot 2025-12-27 at 9 14 19?PM >> >> (This originally came to my attention when looking at an image in Java 1.8. There the ImageConsumer model took approx 400% longer than ImageIO. I was happy to see in recent JDKs that gap narrowed significantly, but there was still a noticeable 10% discrepancy.) >> >> I haven't tried submitting a performance enhancement PR before; I'm not sure if this issue meets this group's threshold for being worth addressing. And if it does: I'm not sure how to structure a unit test for it. > > Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: > > 8374377: move jmh test to java/awt/image > > This is in response to: > https://github.com/openjdk/jdk/pull/29004#issuecomment-3713285051 @ jayathirthrao , OK, I moved the JMH test to java/awt/image . (I'm still unfamiliar with how the JMH tests are used overall. For my part: I'm fine with discarding this JMH test altogether. I wanted it (or something like it) to verify that this PR improved performance. But now having proven that: keeping it around indefinitely may be overkill...?) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29004#issuecomment-3715243555 From aivanov at openjdk.org Tue Jan 6 16:03:35 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 6 Jan 2026 16:03:35 GMT Subject: RFR: 8374340: FontRenderContext instance variables should be final [v3] In-Reply-To: References: Message-ID: On Thu, 25 Dec 2025 03:46:26 GMT, Sergey Bylokhov wrote: >> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year 2025 -> 2026 > > Marked as reviewed by serb (Reviewer). > @mrserb @prrace This PR technically needs a re-review after the update to the copyright year (2025 -> 2026). The order of the keywords also changed since you had a look ("transient final" -> "final transient"). These are minor changes in my opinion, and these don't require re-approval. You've got two approvals for the latest version. Phil's and Sergey's approvals will be recorded in the commit message as seen in [the bot comment](https://github.com/openjdk/jdk/pull/28981#issuecomment-3689662703). ------------- PR Comment: https://git.openjdk.org/jdk/pull/28981#issuecomment-3715265206 From dgredler at openjdk.org Tue Jan 6 16:55:54 2026 From: dgredler at openjdk.org (Daniel Gredler) Date: Tue, 6 Jan 2026 16:55:54 GMT Subject: Integrated: 8374340: FontRenderContext instance variables should be final In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 12:17:47 GMT, Daniel Gredler wrote: > Instances of FontRenderContext are immutable, but its instance variables are not declared final. This pull request has now been integrated. Changeset: 3f652159 Author: Daniel Gredler URL: https://git.openjdk.org/jdk/commit/3f6521596014510b75318b53ef4aef6b01056545 Stats: 14 lines in 1 file changed: 7 ins; 2 del; 5 mod 8374340: FontRenderContext instance variables should be final Reviewed-by: aivanov, aturbanov, prr, serb ------------- PR: https://git.openjdk.org/jdk/pull/28981 From mickleness at gmail.com Tue Jan 6 16:59:50 2026 From: mickleness at gmail.com (Jeremy Wood) Date: Tue, 06 Jan 2026 16:59:50 +0000 Subject: Making ImageIO.read() 15% faster for JPEGs Message-ID: I?m exploring the performance of loading BufferedImages. I recently noticed that ImageIO.read() can be made ~15% faster by changing the BufferedImage type (so we'd avoid a RGB -> BGR conversion). IMO this wouldn?t be too hard to program, but it might be considered too invasive to accept. Is there any interest/support in exploring this idea if I submit a PR for it? Specifically this is the performance I?m observing on my MacBook: Benchmark Mode Cnt Score Error Units JPEG_Default_vs_RGB.measureDefaultImageType avgt 15 42.589 ? 0.137 ms/op JPEG_Default_vs_RGB.measureRGBImageType avgt 15 35.624 ? 0.589 ms/op The first ?default? approach uses ImageIO.read(inputStream). The second ?RGB? approach creates a BufferedImage target with a custom ColorModel that is similar to TYPE_3BYTE_BGR, except it reverse the colors so they are ordered RGB. This derives from the observation that in JPEGImageReader we create a one-line raster field that uses this 3-byte RGB model. Later in acceptPixels() we call target.setRect(x, y, raster) . Here target is the WritableRaster of the final BufferedImage. By default it will be a 3-byte BGR. So we?re spending 15+% of our time converting RGB-encoded data (from raster) to BGR-encoded data (for target). So the ?pros? of my proposal should include a faster loading time for many JPEG images. I?d argue ImageIO should always default to the fastest (reasonable) implementation possible. IMO the major ?con? is: target.getType() would change from BufferedImage.TYPE_3BYTE_BGR to BufferedImage.TYPE_CUSTOM . This doesn?t technically violate any documentation that I know of, but it seems (IMO) like something some clients will have made assumptions about, and therefore some downstream code may break. (And maybe other devs here can identify other problems I?m not anticipating.) Any thoughts / feedback? Regards, - Jeremy Below is the JMH code used to generate the output above: package org.sun.awt.image; import org.openjdk.jmh.annotations.*; import org.openjdk.jmh.infra.Blackhole; import javax.imageio.ImageIO; import javax.imageio.ImageReadParam; import javax.imageio.ImageReader; import java.awt.*; import java.awt.color.ColorSpace; import java.awt.image.*; import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; import java.util.Iterator; import java.util.Random; import java.util.concurrent.TimeUnit; @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.MILLISECONDS) @Warmup(iterations = 5, time = 1) @Measurement(iterations = 5, time = 20) @Fork(3) @State(Scope.Thread) public class JPEG_Default_vs_RGB { byte[] jpgImageData; @Setup public void setup() throws Exception { jpgImageData = createImageData(2_500); } @Benchmark public void measureDefaultImageType(Blackhole bh) throws Exception { BufferedImage bi = readJPG(false); bi.flush(); bh.consume(bi); } @Benchmark public void measureRGBImageType(Blackhole bh) throws Exception { BufferedImage bi = readJPG(true); bi.flush(); bh.consume(bi); } private BufferedImage readJPG(boolean useRGBTarget) throws Exception { Iterator readers; try (ByteArrayInputStream byteIn = new ByteArrayInputStream(jpgImageData)) { if (!useRGBTarget) return ImageIO.read(byteIn); readers = ImageIO.getImageReaders(ImageIO.createImageInputStream(byteIn)); if (!readers.hasNext()) { throw new IOException("No reader found for the given file.?); } } ImageReader reader = readers.next(); try (ByteArrayInputStream byteIn = new ByteArrayInputStream(jpgImageData)) { reader.setInput(ImageIO.createImageInputStream(byteIn)); int width = reader.getWidth(0); int height = reader.getHeight(0); // this is copied from how BufferedImage sets up a TYPE_3BYTE_BGR image, // except we use {0, 1, 2} to make it an RGB image: ColorSpace cs = ColorSpace.getInstance(ColorSpace.CS_sRGB); int[] nBits = {8, 8, 8}; int[] bOffs = {0, 1, 2}; ColorModel colorModel = new ComponentColorModel(cs, nBits, false, false, Transparency.OPAQUE, DataBuffer.TYPE_BYTE); WritableRaster raster = Raster.createInterleavedRaster(DataBuffer.TYPE_BYTE, width, height, width * 3, 3, bOffs, null); BufferedImage rgbImage = new BufferedImage(colorModel, raster, false, null); ImageReadParam param = reader.getDefaultReadParam(); param.setDestination(rgbImage); reader.read(0, param); return rgbImage; } finally { reader.dispose(); } } /** * Create a large sample image stored as a JPG * * @return the byte representation of the JPG image. */ private static byte[] createImageData(int squareSize) throws Exception { BufferedImage bi = new BufferedImage(squareSize, squareSize, BufferedImage.TYPE_INT_RGB); Random r = new Random(0); Graphics2D g = bi.createGraphics(); for (int a = 0; a < 20000; a++) { g.setColor(new Color(r.nextInt(0xffffff))); int radius = 10 + r.nextInt(90); g.fillOval(r.nextInt(bi.getWidth()), r.nextInt(bi.getHeight()), radius, radius); } g.dispose(); try (ByteArrayOutputStream out = new ByteArrayOutputStream()) { ImageIO.write(bi, "jpg", out); return out.toByteArray(); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgredler at openjdk.org Tue Jan 6 18:00:35 2026 From: dgredler at openjdk.org (Daniel Gredler) Date: Tue, 6 Jan 2026 18:00:35 GMT Subject: Integrated: 6562639: Wrong pixel bounds from TextLayout with white font In-Reply-To: <42XmY3f4QQ9W3we9fR70rzJpwdr0F5_vycMn610NRmw=.0952f2dc-04b1-4eea-88fd-7b3a85ba1118@github.com> References: <42XmY3f4QQ9W3we9fR70rzJpwdr0F5_vycMn610NRmw=.0952f2dc-04b1-4eea-88fd-7b3a85ba1118@github.com> Message-ID: <8B3BHDyCdR7G3eHfQcvUMrqb-wJK6wXG6hZF4WraH3o=.10a246ed-25e9-4982-b4f7-2fda2acd6b64@github.com> On Sat, 13 Dec 2025 00:33:30 GMT, Daniel Gredler wrote: > One of the possible code paths for `TextLayout.getPixelBounds(...)` actually draws the text on a `Graphics2D` and checks the image pixels afterwards. The text is drawn over a white background, so if the user sets the font's foreground color to white then the text pixels cannot be detected (white on white). > > This PR fixes the issue by removing the code that sets the background to white, leaving the background as the default ARGB color (0 = transparent black). This does not cause a new problem for users who might set their font foreground color to transparent black, because transparent font foreground colors always return an empty bounds anyway (by virtue of being transparent). > > The updated code should also be slightly faster since it's doing less work, though I haven't run any performance tests. This pull request has now been integrated. Changeset: 62181b63 Author: Daniel Gredler URL: https://git.openjdk.org/jdk/commit/62181b6363926968298ed37ac7780ee6d5ef0916 Stats: 107 lines in 2 files changed: 98 ins; 3 del; 6 mod 6562639: Wrong pixel bounds from TextLayout with white font Reviewed-by: serb, prr ------------- PR: https://git.openjdk.org/jdk/pull/28809 From prr at openjdk.org Tue Jan 6 18:17:41 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 6 Jan 2026 18:17:41 GMT Subject: RFR: 8336654: [lworld] Tests depending on sun.awt.AppContext can fail when run with migrated classes [v4] In-Reply-To: <7_hiO6S4AOb-puw71FWgTLyXgCkz96jP0iQx_uQP7Q4=.1f0741e8-10b2-4216-b7cc-543174ea85a0@github.com> References: <7_hiO6S4AOb-puw71FWgTLyXgCkz96jP0iQx_uQP7Q4=.1f0741e8-10b2-4216-b7cc-543174ea85a0@github.com> Message-ID: > The problem is that Boolean will be a value type in the future (Project Valhalla) > and so it can't be the referent of a Reference. > > In this code, the abstract class that creates the Reference accepts a generic type so isn't in control of what it receives. > > The concrete class that extends the generic class has no idea what the super class implementation does, > so has no way to know that it might do something that is invalid for a value type. > > That's an interesting observation for Valhalla (that the code that does something inappropriate for a value type > isn't the source of the value type) but I don't think we need to be concerned > about that here because we can see reasons to do this anyway. > > The specific classes exist because a nominal singleton for the VM may need to be private to an AppContext. > This is a concept from applets but also from webstart where we have a single JVM that may be running code > from different origins that needs to be partitioned and sand boxed. > > This concept is obsolete now as applets and webstart are no longer supported, and the Security Manager > is disabled, further undermining any way to support partitioning. > > This specific case of a Boolean created from the value of a Java System Property looks like it never needed > this partitioning, so the minimal fix is to stop using RecyclableSingleton for it, and just cache the value of that. > > The next level of fix is to note that since AppContext is obsolete, there is no need for RecyclableSingleton > to use AppContext specific values, making RecyclableSingleton just a lazy initialization mechanism for the singleton. > > Given that removing the obsolete AppContext is on the TBD list - and some JDK components have already > removed per-AppContext code - and we'd probably come back to this in JDK 25 anyway it seems best > to get it over with. > > That does mean that one other place in sun.awt.ImageCache needed to be updated too. > > Also one test that explicitly checked that AppContexts were used for UI instances is obsolete and removed. > > Note that RecyclableSingleton also offers some lazy initialisation benefit, and is widely used in Aqua, > so going further and removing that probably isn't something we want to do at all, and certainly not here. Phil Race has updated the pull request incrementally with two additional commits since the last revision: - 8336654 - 8336654 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22868/files - new: https://git.openjdk.org/jdk/pull/22868/files/6ca4a3e3..ad1271de Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22868&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22868&range=02-03 Stats: 24 lines in 2 files changed: 19 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22868.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22868/head:pull/22868 PR: https://git.openjdk.org/jdk/pull/22868 From prr at openjdk.org Tue Jan 6 18:17:42 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 6 Jan 2026 18:17:42 GMT Subject: RFR: 8336654: [lworld] Tests depending on sun.awt.AppContext can fail when run with migrated classes [v4] In-Reply-To: References: <7_hiO6S4AOb-puw71FWgTLyXgCkz96jP0iQx_uQP7Q4=.1f0741e8-10b2-4216-b7cc-543174ea85a0@github.com> Message-ID: On Tue, 31 Dec 2024 01:04:24 GMT, Sergey Bylokhov wrote: >> Phil Race has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8336654 >> - 8336654 > > src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java line 155: > >> 153: T instance; >> 154: >> 155: final T get() { > > It is used in a few places to cache the fonts/images/etc, so to be a "Recyclable" + "Singleton" it should store/return soft reference, and somehow handle the value types properly. All uses of this are stored in static final fields and typically it is a singleton or fixed size list/map I don't see anything that will grow without bounds, and SoftReference isn't a great way to manage such cases anyway. So I don't see any problem with doing away with SoftReference. If we keep it, I think it is just more overhead. And I don't see any way that isn't tricky and messy to do this whilst still allowing value types. It might be easier once Valhalla actually lands so we could check if it is an identity type. So if we keep the reference then a point fix of the Boolean case seems the practical solution. There's no great value to keeping a SoftRef to a Boolean so we can do without it. But it meant I had to look for any other similar cases by hand. I didn't find any. Doing this means no changes to the existing RecyclableSingleton class are necessary to resolve the specific issue. But I think we want to soon enough get rid of AppContext anyway, so I am moving the ref usage directly into RecyclableSingleton and keeping the deletion of the method from AppContext. The ImageCache doesn't need it. The cached images are managed by the cache code itself. The most recent commit implements the above but I don't see a problem with pushing without that commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22868#discussion_r2665820002 From prr at openjdk.org Tue Jan 6 18:25:50 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 6 Jan 2026 18:25:50 GMT Subject: RFR: 8336654: [lworld] Tests depending on sun.awt.AppContext can fail when run with migrated classes [v5] In-Reply-To: <7_hiO6S4AOb-puw71FWgTLyXgCkz96jP0iQx_uQP7Q4=.1f0741e8-10b2-4216-b7cc-543174ea85a0@github.com> References: <7_hiO6S4AOb-puw71FWgTLyXgCkz96jP0iQx_uQP7Q4=.1f0741e8-10b2-4216-b7cc-543174ea85a0@github.com> Message-ID: > The problem is that Boolean will be a value type in the future (Project Valhalla) > and so it can't be the referent of a Reference. > > In this code, the abstract class that creates the Reference accepts a generic type so isn't in control of what it receives. > > The concrete class that extends the generic class has no idea what the super class implementation does, > so has no way to know that it might do something that is invalid for a value type. > > That's an interesting observation for Valhalla (that the code that does something inappropriate for a value type > isn't the source of the value type) but I don't think we need to be concerned > about that here because we can see reasons to do this anyway. > > The specific classes exist because a nominal singleton for the VM may need to be private to an AppContext. > This is a concept from applets but also from webstart where we have a single JVM that may be running code > from different origins that needs to be partitioned and sand boxed. > > This concept is obsolete now as applets and webstart are no longer supported, and the Security Manager > is disabled, further undermining any way to support partitioning. > > This specific case of a Boolean created from the value of a Java System Property looks like it never needed > this partitioning, so the minimal fix is to stop using RecyclableSingleton for it, and just cache the value of that. > > The next level of fix is to note that since AppContext is obsolete, there is no need for RecyclableSingleton > to use AppContext specific values, making RecyclableSingleton just a lazy initialization mechanism for the singleton. > > Given that removing the obsolete AppContext is on the TBD list - and some JDK components have already > removed per-AppContext code - and we'd probably come back to this in JDK 25 anyway it seems best > to get it over with. > > That does mean that one other place in sun.awt.ImageCache needed to be updated too. > > Also one test that explicitly checked that AppContexts were used for UI instances is obsolete and removed. > > Note that RecyclableSingleton also offers some lazy initialisation benefit, and is widely used in Aqua, > so going further and removing that probably isn't something we want to do at all, and certainly not here. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8336654 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22868/files - new: https://git.openjdk.org/jdk/pull/22868/files/ad1271de..dc51767c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22868&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22868&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22868.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22868/head:pull/22868 PR: https://git.openjdk.org/jdk/pull/22868 From serb at openjdk.org Tue Jan 6 18:32:41 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 6 Jan 2026 18:32:41 GMT Subject: RFR: 8374493: Add missing @Override annotations in "com.sun.java.swing.plaf.motif" package Message-ID: This patch adds missing `@Override` annotations to methods in the `com.sun.java.swing.plaf.motif` package that override methods from a superclass or interface. Only source annotations are added; there are no behavioral changes. The previous patch for `com.sun.beans` can be found here: https://github.com/openjdk/jdk/pull/27887. ------------- Commit messages: - 8374493: Add missing @Override annotations in "com.sun.java.swing.plaf.motif" package Changes: https://git.openjdk.org/jdk/pull/29026/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29026&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374493 Stats: 377 lines in 37 files changed: 340 ins; 0 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/29026.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29026/head:pull/29026 PR: https://git.openjdk.org/jdk/pull/29026 From prr at openjdk.org Tue Jan 6 19:02:59 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 6 Jan 2026 19:02:59 GMT Subject: RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs [v5] In-Reply-To: References: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> Message-ID: On Tue, 6 Jan 2026 15:50:05 GMT, Jeremy Wood wrote: >> When decoding an uninterlaced 8-bit PNG image, the PNGImageDecoder is basically copying one byte at a time. >> >> This PR uses System.arraycopy instead, and it shows approx a 10% improvement. >> >> This graph shows the time it takes different decoders to convert a byte array into a BufferedImage as the size of the PNG image increases: >> >> Screenshot 2025-12-27 at 9 14 19?PM >> >> (This originally came to my attention when looking at an image in Java 1.8. There the ImageConsumer model took approx 400% longer than ImageIO. I was happy to see in recent JDKs that gap narrowed significantly, but there was still a noticeable 10% discrepancy.) >> >> I haven't tried submitting a performance enhancement PR before; I'm not sure if this issue meets this group's threshold for being worth addressing. And if it does: I'm not sure how to structure a unit test for it. > > Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: > > 8374377: move jmh test to java/awt/image > > This is in response to: > https://github.com/openjdk/jdk/pull/29004#issuecomment-3713285051 I have no objection to a performance improvement like this. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29004#pullrequestreview-3632118977 From prr at openjdk.org Tue Jan 6 21:34:23 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 6 Jan 2026 21:34:23 GMT Subject: RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs [v5] In-Reply-To: <0vwHR4CLk_g-5rIXMWe5RdNnS5jvz5KCcqQAKKhBE7c=.b3df16bf-7879-4fb3-932e-e65b36ece725@github.com> References: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> <0vwHR4CLk_g-5rIXMWe5RdNnS5jvz5KCcqQAKKhBE7c=.b3df16bf-7879-4fb3-932e-e65b36ece725@github.com> Message-ID: <_YqDRk82BHcN1ckmMAVvBbZ7EbRhnPj_RYGV_TYbZjE=.98b28461-62c4-4212-8794-252277632e9d@github.com> On Tue, 6 Jan 2026 15:54:34 GMT, Jeremy Wood wrote: > @ jayathirthrao , OK, I moved the JMH test to java/awt/image . > > (I'm still unfamiliar with how the JMH tests are used overall. For my part: I'm fine with discarding this JMH test altogether. I wanted it (or something like it) to verify that this PR improved performance. But now having proven that: keeping it around indefinitely may be overkill...?) Either way. Up to you. It has benefit as an example. Unless all other JMH benchmarks are run regularly, it won't be a completely odd case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29004#issuecomment-3716436678 From serb at openjdk.org Wed Jan 7 01:51:30 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 7 Jan 2026 01:51:30 GMT Subject: RFR: 8336654: [lworld] Tests depending on sun.awt.AppContext can fail when run with migrated classes [v5] In-Reply-To: References: <7_hiO6S4AOb-puw71FWgTLyXgCkz96jP0iQx_uQP7Q4=.1f0741e8-10b2-4216-b7cc-543174ea85a0@github.com> Message-ID: On Tue, 6 Jan 2026 18:13:38 GMT, Phil Race wrote: >> src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java line 155: >> >>> 153: T instance; >>> 154: >>> 155: final T get() { >> >> It is used in a few places to cache the fonts/images/etc, so to be a "Recyclable" + "Singleton" it should store/return soft reference, and somehow handle the value types properly. > > All uses of this are stored in static final fields and typically it is a singleton or fixed size list/map > I don't see anything that will grow without bounds, and SoftReference isn't a great way to manage > such cases anyway. > > So I don't see any problem with doing away with SoftReference. > If we keep it, I think it is just more overhead. > > And I don't see any way that isn't tricky and messy to do this whilst still allowing value types. > It might be easier once Valhalla actually lands so we could check if it is an identity type. > > So if we keep the reference then a point fix of the Boolean case seems the practical solution. > There's no great value to keeping a SoftRef to a Boolean so we can do without it. > But it meant I had to look for any other similar cases by hand. I didn't find any. > > Doing this means no changes to the existing RecyclableSingleton class are necessary to resolve the specific issue. > But I think we want to soon enough get rid of AppContext anyway, so I am moving the ref usage > directly into RecyclableSingleton and keeping the deletion of the method from AppContext. > The ImageCache doesn't need it. The cached images are managed by the cache code itself. > > The most recent commit implements the above but I don't see a problem with pushing without that commit. That looks fine. What about LazyConstant? It seems to have similar functionality to the new LazySingleton, aside from the name. Personally, I do not think LazyConstant is a great name.... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22868#discussion_r2666804936 From jdv at openjdk.org Wed Jan 7 04:51:04 2026 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 7 Jan 2026 04:51:04 GMT Subject: RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs [v5] In-Reply-To: References: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> Message-ID: On Tue, 6 Jan 2026 15:50:05 GMT, Jeremy Wood wrote: >> When decoding an uninterlaced 8-bit PNG image, the PNGImageDecoder is basically copying one byte at a time. >> >> This PR uses System.arraycopy instead, and it shows approx a 10% improvement. >> >> This graph shows the time it takes different decoders to convert a byte array into a BufferedImage as the size of the PNG image increases: >> >> Screenshot 2025-12-27 at 9 14 19?PM >> >> (This originally came to my attention when looking at an image in Java 1.8. There the ImageConsumer model took approx 400% longer than ImageIO. I was happy to see in recent JDKs that gap narrowed significantly, but there was still a noticeable 10% discrepancy.) >> >> I haven't tried submitting a performance enhancement PR before; I'm not sure if this issue meets this group's threshold for being worth addressing. And if it does: I'm not sure how to structure a unit test for it. > > Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: > > 8374377: move jmh test to java/awt/image > > This is in response to: > https://github.com/openjdk/jdk/pull/29004#issuecomment-3713285051 Marked as reviewed by jdv (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29004#pullrequestreview-3633330902 From jdv at openjdk.org Wed Jan 7 04:51:06 2026 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 7 Jan 2026 04:51:06 GMT Subject: RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs [v5] In-Reply-To: <_YqDRk82BHcN1ckmMAVvBbZ7EbRhnPj_RYGV_TYbZjE=.98b28461-62c4-4212-8794-252277632e9d@github.com> References: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> <0vwHR4CLk_g-5rIXMWe5RdNnS5jvz5KCcqQAKKhBE7c=.b3df16bf-7879-4fb3-932e-e65b36ece725@github.com> <_YqDRk82BHcN1ckmMAVvBbZ7EbRhnPj_RYGV_TYbZjE=.98b28461-62c4-4212-8794-252277632e9d@github.com> Message-ID: On Tue, 6 Jan 2026 21:30:15 GMT, Phil Race wrote: > @ jayathirthrao , OK, I moved the JMH test to java/awt/image . > > (I'm still unfamiliar with how the JMH tests are used overall. For my part: I'm fine with discarding this JMH test altogether. I wanted it (or something like it) to verify that this PR improved performance. But now having proven that: keeping it around indefinitely may be overkill...?) Its up to you to keep/remove the JMH test. As Phil mentioned it can serve as an example for client JMH tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29004#issuecomment-3717300951 From lkorinth at openjdk.org Wed Jan 7 12:35:42 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 7 Jan 2026 12:35:42 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 10:02:41 GMT, Leo Korinth wrote: >> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. >> >> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. >> >> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. >> >> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. > > Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision: > > - Merge branch 'master' into _8367993 > - 8366058: Outdated comment in WinCAPISeedGenerator > > Reviewed-by: mullan > - 8357258: x86: Improve receiver type profiling reliability > > Reviewed-by: kvn, vlivanov > - 8373704: Improve "SocketException: Protocol family unavailable" message > > Reviewed-by: lucy, jpai > - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently > > Reviewed-by: jiefu, jbhateja, erfang, qamai > - 8343809: Add requires tag to mark tests that are incompatible with exploded image > > Reviewed-by: alanb, dholmes > - 8374465: Spurious dot in documentation for JVMTI ClassLoad > > Reviewed-by: kbarrett > - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket > > Reviewed-by: djelinski, mpowers, ascarpino > - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings > > Reviewed-by: aboldtch > - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test > > Reviewed-by: serb, aivanov, dnguyen > - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767 I will redo the merge, I have done something strange. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3718660595 From lkorinth at openjdk.org Wed Jan 7 12:58:43 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 7 Jan 2026 12:58:43 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3] In-Reply-To: References: Message-ID: > This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. > > It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. > > This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. > > I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits: - Merge branch '8373253' into 8367993 - Merge branch 'master' into _8373253 - Merge branch 'master' into _8367993 - 8366058: Outdated comment in WinCAPISeedGenerator Reviewed-by: mullan - 8357258: x86: Improve receiver type profiling reliability Reviewed-by: kvn, vlivanov - 8373704: Improve "SocketException: Protocol family unavailable" message Reviewed-by: lucy, jpai - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently Reviewed-by: jiefu, jbhateja, erfang, qamai - 8343809: Add requires tag to mark tests that are incompatible with exploded image Reviewed-by: alanb, dholmes - 8374465: Spurious dot in documentation for JVMTI ClassLoad Reviewed-by: kbarrett - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket Reviewed-by: djelinski, mpowers, ascarpino - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68 ------------- Changes: https://git.openjdk.org/jdk/pull/28723/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=02 Stats: 130308 lines in 3967 files changed: 83803 ins; 29735 del; 16770 mod Patch: https://git.openjdk.org/jdk/pull/28723.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723 PR: https://git.openjdk.org/jdk/pull/28723 From prr at openjdk.org Wed Jan 7 20:23:52 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 7 Jan 2026 20:23:52 GMT Subject: RFR: 8336654: [lworld] Tests depending on sun.awt.AppContext can fail when run with migrated classes [v5] In-Reply-To: References: <7_hiO6S4AOb-puw71FWgTLyXgCkz96jP0iQx_uQP7Q4=.1f0741e8-10b2-4216-b7cc-543174ea85a0@github.com> Message-ID: On Wed, 7 Jan 2026 01:48:31 GMT, Sergey Bylokhov wrote: >> All uses of this are stored in static final fields and typically it is a singleton or fixed size list/map >> I don't see anything that will grow without bounds, and SoftReference isn't a great way to manage >> such cases anyway. >> >> So I don't see any problem with doing away with SoftReference. >> If we keep it, I think it is just more overhead. >> >> And I don't see any way that isn't tricky and messy to do this whilst still allowing value types. >> It might be easier once Valhalla actually lands so we could check if it is an identity type. >> >> So if we keep the reference then a point fix of the Boolean case seems the practical solution. >> There's no great value to keeping a SoftRef to a Boolean so we can do without it. >> But it meant I had to look for any other similar cases by hand. I didn't find any. >> >> Doing this means no changes to the existing RecyclableSingleton class are necessary to resolve the specific issue. >> But I think we want to soon enough get rid of AppContext anyway, so I am moving the ref usage >> directly into RecyclableSingleton and keeping the deletion of the method from AppContext. >> The ImageCache doesn't need it. The cached images are managed by the cache code itself. >> >> The most recent commit implements the above but I don't see a problem with pushing without that commit. > > That looks fine. What about LazyConstant? It seems to have similar functionality to the new LazySingleton, aside from the name. Personally, I do not think LazyConstant is a great name.... You mean the new incarnation of StableValue ? That crossed my mind, but I don't think this case is important enough to bring in that preview feature. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22868#discussion_r2669956234 From prr at openjdk.org Wed Jan 7 20:39:16 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 7 Jan 2026 20:39:16 GMT Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v29] In-Reply-To: References: Message-ID: On Wed, 31 Dec 2025 17:53:39 GMT, Khalid Boulanouare wrote: >> This PR will consolidate fixes of the following bugs: >> >> https://bugs.openjdk.org/browse/JDK-8361188 >> https://bugs.openjdk.org/browse/JDK-8361189 >> https://bugs.openjdk.org/browse/JDK-8361190 >> https://bugs.openjdk.org/browse/JDK-8361191 >> https://bugs.openjdk.org/browse/JDK-8361192 >> https://bugs.openjdk.org/browse/JDK-8361193 >> https://bugs.openjdk.org/browse/JDK-8361195 >> >> This PR depends on https://github.com/openjdk/jdk/pull/25971 >> >> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188) >> >> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193 >> >> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192 >> >> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191 >> >> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190 > > Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: > > Removes some mixing tests from problem list test/jdk/ProblemList.txt line 157: > 155: java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java 8370584 windows-x64 > 156: java/awt/Mixing/AWT_Mixing/OpaqueOverlappingChoice.java 8048171 generic-all > 157: java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java 8159451 linux-all,windows-all,macosx-all 8159451 is about specifically this test, so I don't know why we needed JDK-8361190 to be filed. And 8159451 is now no longer used in the problem list. So one way or another it should be closed via this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2669995797 From aivanov at openjdk.org Wed Jan 7 22:33:16 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 7 Jan 2026 22:33:16 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v5] In-Reply-To: References: Message-ID: On Wed, 26 Nov 2025 16:25:04 GMT, Christian Heilmann wrote: >> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS. >> >> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m. > > Christian Heilmann has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'pr/8297191' of https://github.com/christianheilmann/jdk into pr/11266 > - added 8297191 to @bug Since this PR wasn't integrated in 2025, we should bump the copyright years to 2026. I ran all the client tests through Oracle CI, and no failures are reported. I ran printer tests on my Mac, and I couldn't see any failures. Thus, there are no showstoppers. @prrace Do you have any other comments? Would you approve the PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3721089803 From kizune at openjdk.org Wed Jan 7 22:54:04 2026 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 7 Jan 2026 22:54:04 GMT Subject: RFR: 6441373: Editing JTable is not Serializable [v7] In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 10:05:57 GMT, Prasanta Sadhukhan wrote: >> Issue is when JTable is in editing mode, it is not Serializable as it gives exception >> >> java.io.NotSerializableException: java.lang.reflect.Constructor >> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1149) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1502) >> at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1467) >> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1385) >> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1143) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1502) >> ....... >> >> >> It is caused by creation of `GenericEditor` class which uses a non-serializable Constructor field. >> This is fixed by making the field transient.. >> Also, `editorRemover` field is made transient as it is object of `CellEditorRemover` class which is not Serializable.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Component count leakage fix Marked as reviewed by kizune (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28627#pullrequestreview-3637091859 From serb at openjdk.org Thu Jan 8 00:36:53 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 8 Jan 2026 00:36:53 GMT Subject: RFR: 6441373: Editing JTable is not Serializable [v7] In-Reply-To: References: Message-ID: <5MxYeGqkIlIN1t8-Rtql1Do3MsZcYlUUCStmzVYCOio=.5e8b7079-1a4a-4682-9416-78b26a8603b1@github.com> On Fri, 2 Jan 2026 10:05:57 GMT, Prasanta Sadhukhan wrote: >> Issue is when JTable is in editing mode, it is not Serializable as it gives exception >> >> java.io.NotSerializableException: java.lang.reflect.Constructor >> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1149) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1502) >> at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1467) >> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1385) >> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1143) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1502) >> ....... >> >> >> It is caused by creation of `GenericEditor` class which uses a non-serializable Constructor field. >> This is fixed by making the field transient.. >> Also, `editorRemover` field is made transient as it is object of `CellEditorRemover` class which is not Serializable.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Component count leakage fix src/java.desktop/share/classes/javax/swing/JTable.java line 5965: > 5963: throws IOException, ClassNotFoundException > 5964: { > 5965: this.removeAll(); This will remove all children from the JTable, including those added by the app. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28627#discussion_r2670487927 From serb at openjdk.org Thu Jan 8 00:40:02 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 8 Jan 2026 00:40:02 GMT Subject: RFR: 8336654: [lworld] Tests depending on sun.awt.AppContext can fail when run with migrated classes [v5] In-Reply-To: References: <7_hiO6S4AOb-puw71FWgTLyXgCkz96jP0iQx_uQP7Q4=.1f0741e8-10b2-4216-b7cc-543174ea85a0@github.com> Message-ID: <6KRYQ1_MSxpvQGMHd9BR1OwmGF48K5HN28QN7AWxJKo=.7417ebe3-09c8-4359-8f3a-033d5ff496a8@github.com> On Tue, 6 Jan 2026 18:25:50 GMT, Phil Race wrote: >> The problem is that Boolean will be a value type in the future (Project Valhalla) >> and so it can't be the referent of a Reference. >> >> In this code, the abstract class that creates the Reference accepts a generic type so isn't in control of what it receives. >> >> The concrete class that extends the generic class has no idea what the super class implementation does, >> so has no way to know that it might do something that is invalid for a value type. >> >> That's an interesting observation for Valhalla (that the code that does something inappropriate for a value type >> isn't the source of the value type) but I don't think we need to be concerned >> about that here because we can see reasons to do this anyway. >> >> The specific classes exist because a nominal singleton for the VM may need to be private to an AppContext. >> This is a concept from applets but also from webstart where we have a single JVM that may be running code >> from different origins that needs to be partitioned and sand boxed. >> >> This concept is obsolete now as applets and webstart are no longer supported, and the Security Manager >> is disabled, further undermining any way to support partitioning. >> >> This specific case of a Boolean created from the value of a Java System Property looks like it never needed >> this partitioning, so the minimal fix is to stop using RecyclableSingleton for it, and just cache the value of that. >> >> The next level of fix is to note that since AppContext is obsolete, there is no need for RecyclableSingleton >> to use AppContext specific values, making RecyclableSingleton just a lazy initialization mechanism for the singleton. >> >> Given that removing the obsolete AppContext is on the TBD list - and some JDK components have already >> removed per-AppContext code - and we'd probably come back to this in JDK 25 anyway it seems best >> to get it over with. >> >> That does mean that one other place in sun.awt.ImageCache needed to be updated too. >> >> Also one test that explicitly checked that AppContexts were used for UI instances is obsolete and removed. >> >> Note that RecyclableSingleton also offers some lazy initialisation benefit, and is widely used in Aqua, >> so going further and removing that probably isn't something we want to do at all, and certainly not here. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8336654 Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22868#pullrequestreview-3637285154 From serb at openjdk.org Thu Jan 8 00:40:03 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 8 Jan 2026 00:40:03 GMT Subject: RFR: 8336654: [lworld] Tests depending on sun.awt.AppContext can fail when run with migrated classes [v5] In-Reply-To: References: <7_hiO6S4AOb-puw71FWgTLyXgCkz96jP0iQx_uQP7Q4=.1f0741e8-10b2-4216-b7cc-543174ea85a0@github.com> Message-ID: On Wed, 7 Jan 2026 20:20:19 GMT, Phil Race wrote: >You mean the new incarnation of StableValue ? Correct > That crossed my mind, but I don't think this case is important enough to bring in that preview feature. >From another view, it is quite simple to prepare and test the infrastructure to bring that API to the desktop module, and it fits well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22868#discussion_r2670492684 From mbaesken at openjdk.org Thu Jan 8 10:21:53 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 8 Jan 2026 10:21:53 GMT Subject: RFR: 8374727: Audio configuration Platform class - use nio for getting endianness of the underlying platform Message-ID: <6sqOUNxD-689bHTF0K0ylAEXcYLOFRtdLH2j8UFq2XY=.03449816-fe5d-4dad-8bdb-44cebf01e17f@github.com> Currently Platform.java from the audio coding uses its own native code to get the endianness info of the underlying hardware it runs on. See https://github.com/openjdk/jdk/blob/da14813a5bdadaf0a1f81fa57ff6e1b103eaf113/src/java.desktop/share/classes/com/sun/media/sound/Platform.java#L86 But we can reuse existing Java JDK code e.g. from nio. ------------- Commit messages: - JDK-8374727 Changes: https://git.openjdk.org/jdk/pull/29113/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29113&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374727 Stats: 79 lines in 5 files changed: 3 ins; 69 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29113.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29113/head:pull/29113 PR: https://git.openjdk.org/jdk/pull/29113 From mbaesken at openjdk.org Thu Jan 8 13:04:44 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 8 Jan 2026 13:04:44 GMT Subject: RFR: 8374727: Audio configuration Platform class - use nio for getting endianness of the underlying platform In-Reply-To: <6sqOUNxD-689bHTF0K0ylAEXcYLOFRtdLH2j8UFq2XY=.03449816-fe5d-4dad-8bdb-44cebf01e17f@github.com> References: <6sqOUNxD-689bHTF0K0ylAEXcYLOFRtdLH2j8UFq2XY=.03449816-fe5d-4dad-8bdb-44cebf01e17f@github.com> Message-ID: On Thu, 8 Jan 2026 10:13:54 GMT, Matthias Baesken wrote: > Currently Platform.java from the audio coding uses its own native code to get the endianness info of the underlying hardware it runs on. > See https://github.com/openjdk/jdk/blob/da14813a5bdadaf0a1f81fa57ff6e1b103eaf113/src/java.desktop/share/classes/com/sun/media/sound/Platform.java#L86 > But we can reuse existing Java JDK code e.g. from nio. `ByteOrder.nativeOrder()` is already used for the BE/LE checks across the JDK, see https://github.com/search?q=repo%3Aopenjdk%2Fjdk++%22ByteOrder.nativeOrder%28%29+%3D%3D%22&type=code (maybe we should also have something like `public static boolean ByteOrder.isLittleEndian() `/ `public static boolean ByteOrder.isBigEndian()` to shorten those checks a bit, but this is out of the scope of this PR) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29113#issuecomment-3723781253 From dnguyen at openjdk.org Thu Jan 8 17:17:28 2026 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 8 Jan 2026 17:17:28 GMT Subject: RFR: 8373727: New XBM images parser regression: only the first line of the bitmap array is parsed Message-ID: There were three concerns with the previous changes to `XbmImageDecoder`. 1. Only the first line of the bit array was read. 2. The regex was incorrect because it used `[]` instead of `()` for some grouping. 3. The ordering of the width and height in the xbm file was too strict and had to be width first, then height. To fix these issues, I have: 1. Used a StringBuilder to append lines of the bit array to parse the entire array at once. 2. Updated the regex to capture starting whitespace, optionally start with `0x`, include all chars/digits/punctuation (minus `,` and `};`) instead of just valid hex digits, and end with either `,` or `};`. This also allows for incorrect hex values such as `0x12345abcde` to be detected since the new regex allows for multiple chars after the `0x` until the next delimiter is found. This is accounted for in the test xbm files. 3. Determined width or height based off of ending letters (`th` or `t`). This is similar to https://github.com/openjdk/jdk/blob/jdk-26+10/src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java#L109-L112. A new method is added to `XBMDecoderTest.java` to better check that the bit array parsing works. This method checks for non-empty pixel data. A new xbm file is also added to check for the case where `0xAB+` exists in the bit array. This should be invalid, and the previous regex would allow this to pass. All tests pass with the new changes made here. ------------- Commit messages: - Update copyright year - Initial commit Changes: https://git.openjdk.org/jdk/pull/29120/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29120&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373727 Stats: 123 lines in 4 files changed: 70 ins; 16 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/29120.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29120/head:pull/29120 PR: https://git.openjdk.org/jdk/pull/29120 From duke at openjdk.org Thu Jan 8 18:52:14 2026 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 8 Jan 2026 18:52:14 GMT Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v30] In-Reply-To: References: Message-ID: > This PR will consolidate fixes of the following bugs: > > https://bugs.openjdk.org/browse/JDK-8361188 > https://bugs.openjdk.org/browse/JDK-8361189 > https://bugs.openjdk.org/browse/JDK-8361190 > https://bugs.openjdk.org/browse/JDK-8361191 > https://bugs.openjdk.org/browse/JDK-8361192 > https://bugs.openjdk.org/browse/JDK-8361193 > https://bugs.openjdk.org/browse/JDK-8361195 > > This PR depends on https://github.com/openjdk/jdk/pull/25971 > > For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188) > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193 > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190 Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 122 commits: - Merge branch 'openjdk:master' into jdk-8360498 - Removes some mixing tests from problem list - Fixes few issues when sorting formatting ... - Updates formatting and removes extra blank line - Removes blank lines - Removes blank lines - Applies suggested change - Simplifies return expression - Removes previously added white line - Removes previously added white line - ... and 112 more: https://git.openjdk.org/jdk/compare/9fd86e37...614c8bc7 ------------- Changes: https://git.openjdk.org/jdk/pull/26625/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=29 Stats: 129 lines in 9 files changed: 95 ins; 11 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/26625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625 PR: https://git.openjdk.org/jdk/pull/26625 From azvegint at openjdk.org Thu Jan 8 19:42:28 2026 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 8 Jan 2026 19:42:28 GMT Subject: RFR: 8336654: [lworld] Tests depending on sun.awt.AppContext can fail when run with migrated classes [v5] In-Reply-To: References: <7_hiO6S4AOb-puw71FWgTLyXgCkz96jP0iQx_uQP7Q4=.1f0741e8-10b2-4216-b7cc-543174ea85a0@github.com> Message-ID: On Tue, 6 Jan 2026 18:25:50 GMT, Phil Race wrote: >> The problem is that Boolean will be a value type in the future (Project Valhalla) >> and so it can't be the referent of a Reference. >> >> In this code, the abstract class that creates the Reference accepts a generic type so isn't in control of what it receives. >> >> The concrete class that extends the generic class has no idea what the super class implementation does, >> so has no way to know that it might do something that is invalid for a value type. >> >> That's an interesting observation for Valhalla (that the code that does something inappropriate for a value type >> isn't the source of the value type) but I don't think we need to be concerned >> about that here because we can see reasons to do this anyway. >> >> The specific classes exist because a nominal singleton for the VM may need to be private to an AppContext. >> This is a concept from applets but also from webstart where we have a single JVM that may be running code >> from different origins that needs to be partitioned and sand boxed. >> >> This concept is obsolete now as applets and webstart are no longer supported, and the Security Manager >> is disabled, further undermining any way to support partitioning. >> >> This specific case of a Boolean created from the value of a Java System Property looks like it never needed >> this partitioning, so the minimal fix is to stop using RecyclableSingleton for it, and just cache the value of that. >> >> The next level of fix is to note that since AppContext is obsolete, there is no need for RecyclableSingleton >> to use AppContext specific values, making RecyclableSingleton just a lazy initialization mechanism for the singleton. >> >> Given that removing the obsolete AppContext is on the TBD list - and some JDK components have already >> removed per-AppContext code - and we'd probably come back to this in JDK 25 anyway it seems best >> to get it over with. >> >> That does mean that one other place in sun.awt.ImageCache needed to be updated too. >> >> Also one test that explicitly checked that AppContexts were used for UI instances is obsolete and removed. >> >> Note that RecyclableSingleton also offers some lazy initialisation benefit, and is widely used in Aqua, >> so going further and removing that probably isn't something we want to do at all, and certainly not here. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8336654 Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22868#pullrequestreview-3640969393 From prr at openjdk.org Thu Jan 8 19:50:37 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 8 Jan 2026 19:50:37 GMT Subject: Integrated: 8336654: [lworld] Tests depending on sun.awt.AppContext can fail when run with migrated classes In-Reply-To: <7_hiO6S4AOb-puw71FWgTLyXgCkz96jP0iQx_uQP7Q4=.1f0741e8-10b2-4216-b7cc-543174ea85a0@github.com> References: <7_hiO6S4AOb-puw71FWgTLyXgCkz96jP0iQx_uQP7Q4=.1f0741e8-10b2-4216-b7cc-543174ea85a0@github.com> Message-ID: On Mon, 23 Dec 2024 17:18:15 GMT, Phil Race wrote: > The problem is that Boolean will be a value type in the future (Project Valhalla) > and so it can't be the referent of a Reference. > > In this code, the abstract class that creates the Reference accepts a generic type so isn't in control of what it receives. > > The concrete class that extends the generic class has no idea what the super class implementation does, > so has no way to know that it might do something that is invalid for a value type. > > That's an interesting observation for Valhalla (that the code that does something inappropriate for a value type > isn't the source of the value type) but I don't think we need to be concerned > about that here because we can see reasons to do this anyway. > > The specific classes exist because a nominal singleton for the VM may need to be private to an AppContext. > This is a concept from applets but also from webstart where we have a single JVM that may be running code > from different origins that needs to be partitioned and sand boxed. > > This concept is obsolete now as applets and webstart are no longer supported, and the Security Manager > is disabled, further undermining any way to support partitioning. > > This specific case of a Boolean created from the value of a Java System Property looks like it never needed > this partitioning, so the minimal fix is to stop using RecyclableSingleton for it, and just cache the value of that. > > The next level of fix is to note that since AppContext is obsolete, there is no need for RecyclableSingleton > to use AppContext specific values, making RecyclableSingleton just a lazy initialization mechanism for the singleton. > > Given that removing the obsolete AppContext is on the TBD list - and some JDK components have already > removed per-AppContext code - and we'd probably come back to this in JDK 25 anyway it seems best > to get it over with. > > That does mean that one other place in sun.awt.ImageCache needed to be updated too. > > Also one test that explicitly checked that AppContexts were used for UI instances is obsolete and removed. > > Note that RecyclableSingleton also offers some lazy initialisation benefit, and is widely used in Aqua, > so going further and removing that probably isn't something we want to do at all, and certainly not here. This pull request has now been integrated. Changeset: 982aa3f8 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/982aa3f8ead84817be5373c3257d48feab1758d3 Stats: 168 lines in 4 files changed: 26 ins; 136 del; 6 mod 8336654: [lworld] Tests depending on sun.awt.AppContext can fail when run with migrated classes Reviewed-by: serb, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/22868 From prr at openjdk.org Thu Jan 8 20:01:01 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 8 Jan 2026 20:01:01 GMT Subject: RFR: 8374727: Audio configuration Platform class - use nio for getting endianness of the underlying platform In-Reply-To: <6sqOUNxD-689bHTF0K0ylAEXcYLOFRtdLH2j8UFq2XY=.03449816-fe5d-4dad-8bdb-44cebf01e17f@github.com> References: <6sqOUNxD-689bHTF0K0ylAEXcYLOFRtdLH2j8UFq2XY=.03449816-fe5d-4dad-8bdb-44cebf01e17f@github.com> Message-ID: On Thu, 8 Jan 2026 10:13:54 GMT, Matthias Baesken wrote: > Currently Platform.java from the audio coding uses its own native code to get the endianness info of the underlying hardware it runs on. > See https://github.com/openjdk/jdk/blob/da14813a5bdadaf0a1f81fa57ff6e1b103eaf113/src/java.desktop/share/classes/com/sun/media/sound/Platform.java#L86 > But we can reuse existing Java JDK code e.g. from nio. src/java.desktop/share/classes/com/sun/media/sound/Platform.java line 63: > 61: */ > 62: static boolean isBigEndian() { > 63: if (java.nio.ByteOrder.nativeOrder().equals(java.nio.ByteOrder.BIG_ENDIAN)) { stylistically, this would look better as a single line return java.nio.ByteOrder.nativeOrder().equals(java.nio.ByteOrder.BIG_ENDIAN); or return java.nio.ByteOrder.BIG_ENDIAN.equals( java.nio.ByteOrder.nativeOrder()); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29113#discussion_r2673689753 From psadhukhan at openjdk.org Fri Jan 9 06:58:15 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 9 Jan 2026 06:58:15 GMT Subject: RFR: 6441373: Editing JTable is not Serializable [v7] In-Reply-To: <5MxYeGqkIlIN1t8-Rtql1Do3MsZcYlUUCStmzVYCOio=.5e8b7079-1a4a-4682-9416-78b26a8603b1@github.com> References: <5MxYeGqkIlIN1t8-Rtql1Do3MsZcYlUUCStmzVYCOio=.5e8b7079-1a4a-4682-9416-78b26a8603b1@github.com> Message-ID: On Thu, 8 Jan 2026 00:33:39 GMT, Sergey Bylokhov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Component count leakage fix > > src/java.desktop/share/classes/javax/swing/JTable.java line 5965: > >> 5963: throws IOException, ClassNotFoundException >> 5964: { >> 5965: this.removeAll(); > > This will remove all children from the JTable, including those added by the app. This is done before deserialization process kicks in via readFields() so JTable is not reconstructed yet from serialized object, so I think it's alright to do this at this step to remove the rogue components not cleaned up. There doesn't seem to be good way to prevent this without this `removeAll` call and I didn't see any issue with our JTable CI tests. If a testcase be provided showing it is affecting apps, we can take a look but at the meantime this is the only fix for leakage count. Basically, To make the fields of GenericEditor to not participate in serialization process as was the ask earlier, it is made an Externalizable class. By definition, Externalizable objects are reconstructed by calling the public no-arg constructor first, followed by the readExternal method. Since GenericEditor is still a serializable class, the no-arg constructor of GenericEditor is called from readObject and since the constructor contains "new JTextField()" a new JTextField component is created every time it is reconstructed which is seen incrementing in getComponentCount() I tried passing JTextField object to GenericEditor from JTable when editor is created but that has other issues and I did not want to jeopardise normal operation for serialization corner case fix.. If you can provide any other suggestion for a fix, I will see on that.. Alternatively, we can just fix the serialization exception issue as mentioned in the JBS report and handle this leakage issue separately which anyway has not been complained of since Java inception ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28627#discussion_r2675065910 From serb at openjdk.org Fri Jan 9 08:33:22 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 9 Jan 2026 08:33:22 GMT Subject: RFR: 6441373: Editing JTable is not Serializable [v7] In-Reply-To: References: <5MxYeGqkIlIN1t8-Rtql1Do3MsZcYlUUCStmzVYCOio=.5e8b7079-1a4a-4682-9416-78b26a8603b1@github.com> Message-ID: On Fri, 9 Jan 2026 06:54:35 GMT, Prasanta Sadhukhan wrote: >This is done before deserialization process kicks in via readFields() so JTable is not reconstructed yet from serialized object, so I think it's alright to do this at this step to remove the rogue components not cleaned up. That call simply drops all subcomponents added by the App to the JTable before serialization, right? >Alternatively, we can just fix the serialization exception issue as mentioned in the JBS report and handle this leakage issue separately which anyway has not been complained of since Java inception This is not just a memory leak caused by objects being referenced from uncleaned or suspicious places. It is the accumulation of subcomponents in the JTable after deserialization, so JTable just becomes broken. >I did not want to jeopardise normal operation for serialization corner case fix.. The patch attempts to fix the serialization of the "Editing JTable", but the current version produces a broken object. This is not just a corner case, it is a primary case. Leaving all subcomponents to accumulate is not correct, and deleting all of them is also wrong. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28627#discussion_r2675298095 From psadhukhan at openjdk.org Fri Jan 9 08:46:54 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 9 Jan 2026 08:46:54 GMT Subject: RFR: 6441373: Editing JTable is not Serializable [v7] In-Reply-To: References: <5MxYeGqkIlIN1t8-Rtql1Do3MsZcYlUUCStmzVYCOio=.5e8b7079-1a4a-4682-9416-78b26a8603b1@github.com> Message-ID: <-KmQgMxG5nscdqYlEAKRDVsKXVdM-Qcxg57F-wcTB_s=.d543f321-efcb-4274-b2d8-e89bd00469e0@github.com> On Fri, 9 Jan 2026 08:30:37 GMT, Sergey Bylokhov wrote: > That call simply drops all subcomponents added by the App to the JTable before serialization, right? But JTable is not reconstructed yet so I dont think it matters if we remove the object from pre-serialized instance of JTable..It is going to be reconstructed after this call as I see.. If you see issues then please suggest some alternative.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28627#discussion_r2675330270 From jwood at openjdk.org Fri Jan 9 08:47:00 2026 From: jwood at openjdk.org (Jeremy Wood) Date: Fri, 9 Jan 2026 08:47:00 GMT Subject: RFR: 4197755: Arc2D.getBounds() returns an unnecessarily large bounding box [v2] In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 02:42:50 GMT, Jeremy Wood wrote: >> 4197755 is marked as a duplicate of [JDK-8176501](https://bugs.openjdk.org/browse/JDK-8176501) , but I think that is a mistake. The complaint in that ticket still reproduces, and it is resolved in this PR. >> >> The complaint is: Arc2D.getBounds() is too large. If an Arc2D represents a small slice of an ellipse, then Arc2D.getBounds() always returns the size of the total ellipse. Arc2D.getBounds2D(), by contrast, has been "high-precision" for decades. >> >> This PR makes Arc2D.getBounds() resemble the same implementation already used in Area, CubicCurve2D, Line2D, Path2D, and QuadCurve2D: >> >> public Rectangle getBounds() { >> return getBounds2D().getBounds(); >> } >> >> >> This modifies (simplifies) the javadoc for Arc2D.getBounds2D(). If we generally like this PR I assume we'll need a CSR to approve the javadoc change. > > Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: > > 4197755: Updating copyright year I'm not very familiar with CSR's, so please let me know if this needs improvement/rewriting: https://bugs.openjdk.org/browse/JDK-8374859 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26715#issuecomment-3727835732 From duke at openjdk.org Fri Jan 9 08:53:55 2026 From: duke at openjdk.org (duke) Date: Fri, 9 Jan 2026 08:53:55 GMT Subject: RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs [v5] In-Reply-To: References: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> Message-ID: On Tue, 6 Jan 2026 15:50:05 GMT, Jeremy Wood wrote: >> When decoding an uninterlaced 8-bit PNG image, the PNGImageDecoder is basically copying one byte at a time. >> >> This PR uses System.arraycopy instead, and it shows approx a 10% improvement. >> >> This graph shows the time it takes different decoders to convert a byte array into a BufferedImage as the size of the PNG image increases: >> >> Screenshot 2025-12-27 at 9 14 19?PM >> >> (This originally came to my attention when looking at an image in Java 1.8. There the ImageConsumer model took approx 400% longer than ImageIO. I was happy to see in recent JDKs that gap narrowed significantly, but there was still a noticeable 10% discrepancy.) >> >> I haven't tried submitting a performance enhancement PR before; I'm not sure if this issue meets this group's threshold for being worth addressing. And if it does: I'm not sure how to structure a unit test for it. > > Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: > > 8374377: move jmh test to java/awt/image > > This is in response to: > https://github.com/openjdk/jdk/pull/29004#issuecomment-3713285051 @mickleness Your change (at version fbc8dc62cbe65c6c9011d49298b0bec0599913fc) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29004#issuecomment-3727861831 From jwood at openjdk.org Fri Jan 9 09:59:11 2026 From: jwood at openjdk.org (Jeremy Wood) Date: Fri, 9 Jan 2026 09:59:11 GMT Subject: Integrated: 8374377: PNGImageDecoder Slow For 8-bit PNGs In-Reply-To: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> References: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com> Message-ID: <-8ExSQV02P3C73r0Xb9CzvlPvr6nMXUa4TLabk9i0U0=.fe4d1f65-ceaf-4c81-bb1a-9d94e3f3db8a@github.com> On Sun, 28 Dec 2025 02:22:16 GMT, Jeremy Wood wrote: > When decoding an uninterlaced 8-bit PNG image, the PNGImageDecoder is basically copying one byte at a time. > > This PR uses System.arraycopy instead, and it shows approx a 10% improvement. > > This graph shows the time it takes different decoders to convert a byte array into a BufferedImage as the size of the PNG image increases: > > Screenshot 2025-12-27 at 9 14 19?PM > > (This originally came to my attention when looking at an image in Java 1.8. There the ImageConsumer model took approx 400% longer than ImageIO. I was happy to see in recent JDKs that gap narrowed significantly, but there was still a noticeable 10% discrepancy.) > > I haven't tried submitting a performance enhancement PR before; I'm not sure if this issue meets this group's threshold for being worth addressing. And if it does: I'm not sure how to structure a unit test for it. This pull request has now been integrated. Changeset: 2a965dff Author: Jeremy Wood Committer: Jayathirth D V URL: https://git.openjdk.org/jdk/commit/2a965dffdd2791ab87a2dbfba8ed44f8adb996c7 Stats: 400 lines in 3 files changed: 396 ins; 0 del; 4 mod 8374377: PNGImageDecoder Slow For 8-bit PNGs Reviewed-by: jdv, prr ------------- PR: https://git.openjdk.org/jdk/pull/29004 From mbaesken at openjdk.org Fri Jan 9 11:42:51 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 9 Jan 2026 11:42:51 GMT Subject: RFR: 8374727: Audio configuration Platform class - use nio for getting endianness of the underlying platform [v2] In-Reply-To: <6sqOUNxD-689bHTF0K0ylAEXcYLOFRtdLH2j8UFq2XY=.03449816-fe5d-4dad-8bdb-44cebf01e17f@github.com> References: <6sqOUNxD-689bHTF0K0ylAEXcYLOFRtdLH2j8UFq2XY=.03449816-fe5d-4dad-8bdb-44cebf01e17f@github.com> Message-ID: <3glGJ8-cTg5TXNnC4OlGZBtxKwGa7J6FdVqTAtx90cc=.ca52b952-288d-4279-9686-c6f5be13851b@github.com> > Currently Platform.java from the audio coding uses its own native code to get the endianness info of the underlying hardware it runs on. > See https://github.com/openjdk/jdk/blob/da14813a5bdadaf0a1f81fa57ff6e1b103eaf113/src/java.desktop/share/classes/com/sun/media/sound/Platform.java#L86 > But we can reuse existing Java JDK code e.g. from nio. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Simplify isBigEndian ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29113/files - new: https://git.openjdk.org/jdk/pull/29113/files/4d341769..90202d64 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29113&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29113&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29113.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29113/head:pull/29113 PR: https://git.openjdk.org/jdk/pull/29113 From vdyakov at openjdk.org Fri Jan 9 16:34:58 2026 From: vdyakov at openjdk.org (Victor Dyakov) Date: Fri, 9 Jan 2026 16:34:58 GMT Subject: RFR: 8373727: New XBM images parser regression: only the first line of the bitmap array is parsed In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 17:09:24 GMT, Damon Nguyen wrote: > There were three concerns with the previous changes to `XbmImageDecoder`. > 1. Only the first line of the bit array was read. > 2. The regex was incorrect because it used `[]` instead of `()` for some grouping. > 3. The ordering of the width and height in the xbm file was too strict and had to be width first, then height. > > To fix these issues, I have: > 1. Used a StringBuilder to append lines of the bit array to parse the entire array at once. This required changing the parsing loop and moving some code. > 2. Updated the regex to capture starting whitespace, optionally start with `0x`, include all chars/digits/punctuation (minus `,` and `};`) instead of just valid hex digits, and end with either `,` or `};`. This also allows for incorrect hex values such as `0x12345abcde` to be detected since the new regex allows for multiple chars after the `0x` until the next delimiter is found. This is accounted for in the test xbm files. > 3. Determined width or height based off of ending letters (`th` or `t`). This is similar to https://github.com/openjdk/jdk/blob/jdk-26+10/src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java#L109-L112. > > A new method is added to `XBMDecoderTest.java` to better check that the bit array parsing works. This method checks for non-empty pixel data. > > A new xbm file is also added to check for the case where `0xAB+` exists in the bit array. This should be invalid, and the previous regex would allow this to pass. > > All tests pass with the new changes made here. @jayathirthrao @prrace please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/29120#issuecomment-3729701023 From prr at openjdk.org Fri Jan 9 17:03:30 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 9 Jan 2026 17:03:30 GMT Subject: RFR: 8374727: Audio configuration Platform class - use nio for getting endianness of the underlying platform [v2] In-Reply-To: <3glGJ8-cTg5TXNnC4OlGZBtxKwGa7J6FdVqTAtx90cc=.ca52b952-288d-4279-9686-c6f5be13851b@github.com> References: <6sqOUNxD-689bHTF0K0ylAEXcYLOFRtdLH2j8UFq2XY=.03449816-fe5d-4dad-8bdb-44cebf01e17f@github.com> <3glGJ8-cTg5TXNnC4OlGZBtxKwGa7J6FdVqTAtx90cc=.ca52b952-288d-4279-9686-c6f5be13851b@github.com> Message-ID: On Fri, 9 Jan 2026 11:42:51 GMT, Matthias Baesken wrote: >> Currently Platform.java from the audio coding uses its own native code to get the endianness info of the underlying hardware it runs on. >> See https://github.com/openjdk/jdk/blob/da14813a5bdadaf0a1f81fa57ff6e1b103eaf113/src/java.desktop/share/classes/com/sun/media/sound/Platform.java#L86 >> But we can reuse existing Java JDK code e.g. from nio. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Simplify isBigEndian Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29113#pullrequestreview-3644796521 From kizune at openjdk.org Fri Jan 9 20:26:22 2026 From: kizune at openjdk.org (Alexander Zuev) Date: Fri, 9 Jan 2026 20:26:22 GMT Subject: RFR: 8374727: Audio configuration Platform class - use nio for getting endianness of the underlying platform [v2] In-Reply-To: <3glGJ8-cTg5TXNnC4OlGZBtxKwGa7J6FdVqTAtx90cc=.ca52b952-288d-4279-9686-c6f5be13851b@github.com> References: <6sqOUNxD-689bHTF0K0ylAEXcYLOFRtdLH2j8UFq2XY=.03449816-fe5d-4dad-8bdb-44cebf01e17f@github.com> <3glGJ8-cTg5TXNnC4OlGZBtxKwGa7J6FdVqTAtx90cc=.ca52b952-288d-4279-9686-c6f5be13851b@github.com> Message-ID: On Fri, 9 Jan 2026 11:42:51 GMT, Matthias Baesken wrote: >> Currently Platform.java from the audio coding uses its own native code to get the endianness info of the underlying hardware it runs on. >> See https://github.com/openjdk/jdk/blob/da14813a5bdadaf0a1f81fa57ff6e1b103eaf113/src/java.desktop/share/classes/com/sun/media/sound/Platform.java#L86 >> But we can reuse existing Java JDK code e.g. from nio. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Simplify isBigEndian Marked as reviewed by kizune (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29113#pullrequestreview-3645462092 From serb at openjdk.org Mon Jan 12 06:34:31 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 12 Jan 2026 06:34:31 GMT Subject: RFR: 8374727: Audio configuration Platform class - use nio for getting endianness of the underlying platform [v2] In-Reply-To: <3glGJ8-cTg5TXNnC4OlGZBtxKwGa7J6FdVqTAtx90cc=.ca52b952-288d-4279-9686-c6f5be13851b@github.com> References: <6sqOUNxD-689bHTF0K0ylAEXcYLOFRtdLH2j8UFq2XY=.03449816-fe5d-4dad-8bdb-44cebf01e17f@github.com> <3glGJ8-cTg5TXNnC4OlGZBtxKwGa7J6FdVqTAtx90cc=.ca52b952-288d-4279-9686-c6f5be13851b@github.com> Message-ID: On Fri, 9 Jan 2026 11:42:51 GMT, Matthias Baesken wrote: >> Currently Platform.java from the audio coding uses its own native code to get the endianness info of the underlying hardware it runs on. >> See https://github.com/openjdk/jdk/blob/da14813a5bdadaf0a1f81fa57ff6e1b103eaf113/src/java.desktop/share/classes/com/sun/media/sound/Platform.java#L86 >> But we can reuse existing Java JDK code e.g. from nio. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Simplify isBigEndian src/java.desktop/share/classes/com/sun/media/sound/Platform.java line 63: > 61: */ > 62: static boolean isBigEndian() { > 63: return java.nio.ByteOrder.nativeOrder().equals(java.nio.ByteOrder.BIG_ENDIAN); what is a purpose to use fqdn for ByteOrder class here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29113#discussion_r2681013670 From serb at openjdk.org Mon Jan 12 06:37:06 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 12 Jan 2026 06:37:06 GMT Subject: RFR: 6441373: Editing JTable is not Serializable [v7] In-Reply-To: <-KmQgMxG5nscdqYlEAKRDVsKXVdM-Qcxg57F-wcTB_s=.d543f321-efcb-4274-b2d8-e89bd00469e0@github.com> References: <5MxYeGqkIlIN1t8-Rtql1Do3MsZcYlUUCStmzVYCOio=.5e8b7079-1a4a-4682-9416-78b26a8603b1@github.com> <-KmQgMxG5nscdqYlEAKRDVsKXVdM-Qcxg57F-wcTB_s=.d543f321-efcb-4274-b2d8-e89bd00469e0@github.com> Message-ID: On Fri, 9 Jan 2026 08:42:44 GMT, Prasanta Sadhukhan wrote: >If you see issues then please suggest some alternative.. let me take a look. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28627#discussion_r2681017094 From mbaesken at openjdk.org Mon Jan 12 08:06:40 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 12 Jan 2026 08:06:40 GMT Subject: RFR: 8374727: Audio configuration Platform class - use nio for getting endianness of the underlying platform [v2] In-Reply-To: References: <6sqOUNxD-689bHTF0K0ylAEXcYLOFRtdLH2j8UFq2XY=.03449816-fe5d-4dad-8bdb-44cebf01e17f@github.com> <3glGJ8-cTg5TXNnC4OlGZBtxKwGa7J6FdVqTAtx90cc=.ca52b952-288d-4279-9686-c6f5be13851b@github.com> Message-ID: On Mon, 12 Jan 2026 06:31:03 GMT, Sergey Bylokhov wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Simplify isBigEndian > > src/java.desktop/share/classes/com/sun/media/sound/Platform.java line 63: > >> 61: */ >> 62: static boolean isBigEndian() { >> 63: return java.nio.ByteOrder.nativeOrder().equals(java.nio.ByteOrder.BIG_ENDIAN); > > what is a purpose to use fqdn for ByteOrder class here? Just checked how other JDK coding is doing the LE/BE test, then copied it from here https://github.com/openjdk/jdk/blob/7cf7f01fb339bf3c5b81d946be8afa71ec267e42/src/java.security.jgss/share/classes/sun/security/krb5/internal/util/KrbDataInputStream.java#L49 Should I instead import `java.nio.ByteOrder` ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29113#discussion_r2681201247 From tr at openjdk.org Mon Jan 12 09:45:38 2026 From: tr at openjdk.org (Tejesh R) Date: Mon, 12 Jan 2026 09:45:38 GMT Subject: RFR: 8374493: Add missing @Override annotations in "com.sun.java.swing.plaf.motif" package In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 01:39:18 GMT, Sergey Bylokhov wrote: > This patch adds missing `@Override` annotations to methods in the `com.sun.java.swing.plaf.motif` package that override methods from a superclass or interface. > Only source annotations are added; there are no behavioral changes. > > The previous patch for `com.sun.beans` can be found here: https://github.com/openjdk/jdk/pull/27887. LGTM ------------- Marked as reviewed by tr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29026#pullrequestreview-3649896728 From tr at openjdk.org Mon Jan 12 11:01:58 2026 From: tr at openjdk.org (Tejesh R) Date: Mon, 12 Jan 2026 11:01:58 GMT Subject: RFR: 4765299: componentResized() not always called with nested JSplitPanes In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 10:53:31 GMT, Prasanta Sadhukhan wrote: > If a component "comp" be nested inside a "inner" JSplitPane with VERTICAL_SPLIT mode and if then "inner" be nested inside a > "outer" JSplitPane with HORIZONTAL_SPLIT mode and a component listener is added to "comp" > then with this setup, componentResized() on the listener is called ONLY when the divider of "outer" is moved manually > however, it is not called when the divider of "outer" is moved using "One touch expandable" left button at the top of the divider. > > This is because the `layoutContainer` bails out if the width or height is 0 which logically should be to bail out if both width and height is 0 and when "One touch expandable" left button is pressed, width becomes 0 so `layoutContainer` bails out without sending the event. > > With this fix, componentResized is called > > No regression is observed in CI. I hope you have tested manual tests too. I verified the changes in Swingset2 and no regressions found. test/jdk/javax/swing/JSplitPane/TestSplitPaneCompResize.java line 55: > 53: private JSplitPane outer; > 54: private static JButton leftOneTouchButton; > 55: private static JButton rightOneTouchButton; `rightOneTouchButton` can be local variable. test/jdk/javax/swing/JSplitPane/TestSplitPaneCompResize.java line 135: > 133: > 134: if (!resized) { > 135: throw new RuntimeException("ComponetResized not called"); Suggestion: throw new RuntimeException("ComponentResized not called"); ------------- PR Review: https://git.openjdk.org/jdk/pull/29063#pullrequestreview-3650179930 PR Review Comment: https://git.openjdk.org/jdk/pull/29063#discussion_r2681756844 PR Review Comment: https://git.openjdk.org/jdk/pull/29063#discussion_r2681760297 From psadhukhan at openjdk.org Mon Jan 12 11:55:42 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 12 Jan 2026 11:55:42 GMT Subject: RFR: 4765299: componentResized() not always called with nested JSplitPanes [v2] In-Reply-To: References: Message-ID: > If a component "comp" be nested inside a "inner" JSplitPane with VERTICAL_SPLIT mode and if then "inner" be nested inside a > "outer" JSplitPane with HORIZONTAL_SPLIT mode and a component listener is added to "comp" > then with this setup, componentResized() on the listener is called ONLY when the divider of "outer" is moved manually > however, it is not called when the divider of "outer" is moved using "One touch expandable" left button at the top of the divider. > > This is because the `layoutContainer` bails out if the width or height is 0 which logically should be to bail out if both width and height is 0 and when "One touch expandable" left button is pressed, width becomes 0 so `layoutContainer` bails out without sending the event. > > With this fix, componentResized is called > > No regression is observed in CI. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: test fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29063/files - new: https://git.openjdk.org/jdk/pull/29063/files/99e094c8..54a5414c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29063&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29063&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29063.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29063/head:pull/29063 PR: https://git.openjdk.org/jdk/pull/29063 From serb at openjdk.org Mon Jan 12 17:38:02 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 12 Jan 2026 17:38:02 GMT Subject: RFR: 8374727: Audio configuration Platform class - use nio for getting endianness of the underlying platform [v2] In-Reply-To: References: <6sqOUNxD-689bHTF0K0ylAEXcYLOFRtdLH2j8UFq2XY=.03449816-fe5d-4dad-8bdb-44cebf01e17f@github.com> <3glGJ8-cTg5TXNnC4OlGZBtxKwGa7J6FdVqTAtx90cc=.ca52b952-288d-4279-9686-c6f5be13851b@github.com> Message-ID: On Mon, 12 Jan 2026 08:02:21 GMT, Matthias Baesken wrote: >> src/java.desktop/share/classes/com/sun/media/sound/Platform.java line 63: >> >>> 61: */ >>> 62: static boolean isBigEndian() { >>> 63: return java.nio.ByteOrder.nativeOrder().equals(java.nio.ByteOrder.BIG_ENDIAN); >> >> what is a purpose to use fqdn for ByteOrder class here? > > Just checked how other JDK coding is doing the LE/BE test, then copied it from here > https://github.com/openjdk/jdk/blob/7cf7f01fb339bf3c5b81d946be8afa71ec267e42/src/java.security.jgss/share/classes/sun/security/krb5/internal/util/KrbDataInputStream.java#L49 > Should I instead import `java.nio.ByteOrder` ? yes this is how it is used in desktop module. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29113#discussion_r2683237579 From dnguyen at openjdk.org Mon Jan 12 19:43:57 2026 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 12 Jan 2026 19:43:57 GMT Subject: RFR: 8373727: New XBM images parser regression: only the first line of the bitmap array is parsed [v2] In-Reply-To: References: Message-ID: > There were three concerns with the previous changes to `XbmImageDecoder`. > 1. Only the first line of the bit array was read. > 2. The regex was incorrect because it used `[]` instead of `()` for some grouping. > 3. The ordering of the width and height in the xbm file was too strict and had to be width first, then height. > > To fix these issues, I have: > 1. Used a StringBuilder to append lines of the bit array to parse the entire array at once. This required changing the parsing loop and moving some code. > 2. Updated the regex to capture starting whitespace, optionally start with `0x`, include all chars/digits/punctuation (minus `,` and `};`) instead of just valid hex digits, and end with either `,` or `};`. This also allows for incorrect hex values such as `0x12345abcde` to be detected since the new regex allows for multiple chars after the `0x` until the next delimiter is found. This is accounted for in the test xbm files. > 3. Determined width or height based off of ending letters (`th` or `t`). This is similar to https://github.com/openjdk/jdk/blob/jdk-26+10/src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java#L109-L112. > > A new method is added to `XBMDecoderTest.java` to better check that the bit array parsing works. This method checks for non-empty pixel data. > > A new xbm file is also added to check for the case where `0xAB+` exists in the bit array. This should be invalid, and the previous regex would allow this to pass. > > All tests pass with the new changes made here. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Add test for empty bit array ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29120/files - new: https://git.openjdk.org/jdk/pull/29120/files/8e4826c5..a7542524 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29120&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29120&range=00-01 Stats: 16 lines in 2 files changed: 9 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29120.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29120/head:pull/29120 PR: https://git.openjdk.org/jdk/pull/29120 From dnguyen at openjdk.org Mon Jan 12 20:00:52 2026 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 12 Jan 2026 20:00:52 GMT Subject: RFR: 8373727: New XBM images parser regression: only the first line of the bitmap array is parsed [v3] In-Reply-To: References: Message-ID: <2z_rf5DfYIl4DYFm58a35_oJK-PGoONVdnGyAlsGmYc=.772a0f35-7f1c-42c2-be49-17683f32003b@github.com> > There were three concerns with the previous changes to `XbmImageDecoder`. > 1. Only the first line of the bit array was read. > 2. The regex was incorrect because it used `[]` instead of `()` for some grouping. > 3. The ordering of the width and height in the xbm file was too strict and had to be width first, then height. > > To fix these issues, I have: > 1. Used a StringBuilder to append lines of the bit array to parse the entire array at once. This required changing the parsing loop and moving some code. > 2. Updated the regex to capture starting whitespace, optionally start with `0x`, include all chars/digits/punctuation (minus `,` and `};`) instead of just valid hex digits, and end with either `,` or `};`. This also allows for incorrect hex values such as `0x12345abcde` to be detected since the new regex allows for multiple chars after the `0x` until the next delimiter is found. This is accounted for in the test xbm files. > 3. Determined width or height based off of ending letters (`th` or `t`). This is similar to https://github.com/openjdk/jdk/blob/jdk-26+10/src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java#L109-L112. > > A new method is added to `XBMDecoderTest.java` to better check that the bit array parsing works. This method checks for non-empty pixel data. > > A new xbm file is also added to check for the case where `0xAB+` exists in the bit array. This should be invalid, and the previous regex would allow this to pass. > > All tests pass with the new changes made here. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Add new xbm file to test for multiple lines in bit array ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29120/files - new: https://git.openjdk.org/jdk/pull/29120/files/a7542524..4e6624d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29120&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29120&range=01-02 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29120.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29120/head:pull/29120 PR: https://git.openjdk.org/jdk/pull/29120 From prr at openjdk.org Mon Jan 12 20:00:53 2026 From: prr at openjdk.org (Phil Race) Date: Mon, 12 Jan 2026 20:00:53 GMT Subject: RFR: 8373727: New XBM images parser regression: only the first line of the bitmap array is parsed [v3] In-Reply-To: <2z_rf5DfYIl4DYFm58a35_oJK-PGoONVdnGyAlsGmYc=.772a0f35-7f1c-42c2-be49-17683f32003b@github.com> References: <2z_rf5DfYIl4DYFm58a35_oJK-PGoONVdnGyAlsGmYc=.772a0f35-7f1c-42c2-be49-17683f32003b@github.com> Message-ID: On Mon, 12 Jan 2026 19:56:53 GMT, Damon Nguyen wrote: >> There were three concerns with the previous changes to `XbmImageDecoder`. >> 1. Only the first line of the bit array was read. >> 2. The regex was incorrect because it used `[]` instead of `()` for some grouping. >> 3. The ordering of the width and height in the xbm file was too strict and had to be width first, then height. >> >> To fix these issues, I have: >> 1. Used a StringBuilder to append lines of the bit array to parse the entire array at once. This required changing the parsing loop and moving some code. >> 2. Updated the regex to capture starting whitespace, optionally start with `0x`, include all chars/digits/punctuation (minus `,` and `};`) instead of just valid hex digits, and end with either `,` or `};`. This also allows for incorrect hex values such as `0x12345abcde` to be detected since the new regex allows for multiple chars after the `0x` until the next delimiter is found. This is accounted for in the test xbm files. >> 3. Determined width or height based off of ending letters (`th` or `t`). This is similar to https://github.com/openjdk/jdk/blob/jdk-26+10/src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java#L109-L112. >> >> A new method is added to `XBMDecoderTest.java` to better check that the bit array parsing works. This method checks for non-empty pixel data. >> >> A new xbm file is also added to check for the case where `0xAB+` exists in the bit array. This should be invalid, and the previous regex would allow this to pass. >> >> All tests pass with the new changes made here. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Add new xbm file to test for multiple lines in bit array Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29120#pullrequestreview-3652514503 From dnguyen at openjdk.org Mon Jan 12 20:00:54 2026 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 12 Jan 2026 20:00:54 GMT Subject: RFR: 8373727: New XBM images parser regression: only the first line of the bitmap array is parsed [v2] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 19:43:57 GMT, Damon Nguyen wrote: >> There were three concerns with the previous changes to `XbmImageDecoder`. >> 1. Only the first line of the bit array was read. >> 2. The regex was incorrect because it used `[]` instead of `()` for some grouping. >> 3. The ordering of the width and height in the xbm file was too strict and had to be width first, then height. >> >> To fix these issues, I have: >> 1. Used a StringBuilder to append lines of the bit array to parse the entire array at once. This required changing the parsing loop and moving some code. >> 2. Updated the regex to capture starting whitespace, optionally start with `0x`, include all chars/digits/punctuation (minus `,` and `};`) instead of just valid hex digits, and end with either `,` or `};`. This also allows for incorrect hex values such as `0x12345abcde` to be detected since the new regex allows for multiple chars after the `0x` until the next delimiter is found. This is accounted for in the test xbm files. >> 3. Determined width or height based off of ending letters (`th` or `t`). This is similar to https://github.com/openjdk/jdk/blob/jdk-26+10/src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java#L109-L112. >> >> A new method is added to `XBMDecoderTest.java` to better check that the bit array parsing works. This method checks for non-empty pixel data. >> >> A new xbm file is also added to check for the case where `0xAB+` exists in the bit array. This should be invalid, and the previous regex would allow this to pass. >> >> All tests pass with the new changes made here. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Add test for empty bit array New xbm files added to explicitly test for an invalid empty bit array as well as a valid bit array where there are additional newlines beyond the initial newline stated in the original bug. The test correctly fails the invalid empty file and passes the new valid multiline xbm file. The overall test passes after the changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29120#issuecomment-3740249196 From kizune at openjdk.org Mon Jan 12 22:32:53 2026 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 12 Jan 2026 22:32:53 GMT Subject: RFR: 4765299: componentResized() not always called with nested JSplitPanes [v2] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 11:55:42 GMT, Prasanta Sadhukhan wrote: >> If a component "comp" be nested inside a "inner" JSplitPane with VERTICAL_SPLIT mode and if then "inner" be nested inside a >> "outer" JSplitPane with HORIZONTAL_SPLIT mode and a component listener is added to "comp" >> then with this setup, componentResized() on the listener is called ONLY when the divider of "outer" is moved manually >> however, it is not called when the divider of "outer" is moved using "One touch expandable" left button at the top of the divider. >> >> This is because the `layoutContainer` bails out if the width or height is 0 which logically should be to bail out if both width and height is 0 and when "One touch expandable" left button is pressed, width becomes 0 so `layoutContainer` bails out without sending the event. >> >> With this fix, componentResized is called >> >> No regression is observed in CI. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > test fix Latest version looks fine. ------------- Marked as reviewed by kizune (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29063#pullrequestreview-3652985926 From tr at openjdk.org Tue Jan 13 04:30:38 2026 From: tr at openjdk.org (Tejesh R) Date: Tue, 13 Jan 2026 04:30:38 GMT Subject: RFR: 4765299: componentResized() not always called with nested JSplitPanes [v2] In-Reply-To: References: Message-ID: <2gasw0z2fnyJk_70skWEmJaHw0KGfVBJNAeF8x5s41U=.f14b2c41-9d41-4224-922d-85960e6330ac@github.com> On Mon, 12 Jan 2026 11:55:42 GMT, Prasanta Sadhukhan wrote: >> If a component "comp" be nested inside a "inner" JSplitPane with VERTICAL_SPLIT mode and if then "inner" be nested inside a >> "outer" JSplitPane with HORIZONTAL_SPLIT mode and a component listener is added to "comp" >> then with this setup, componentResized() on the listener is called ONLY when the divider of "outer" is moved manually >> however, it is not called when the divider of "outer" is moved using "One touch expandable" left button at the top of the divider. >> >> This is because the `layoutContainer` bails out if the width or height is 0 which logically should be to bail out if both width and height is 0 and when "One touch expandable" left button is pressed, width becomes 0 so `layoutContainer` bails out without sending the event. >> >> With this fix, componentResized is called >> >> No regression is observed in CI. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > test fix LGTM ------------- Marked as reviewed by tr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29063#pullrequestreview-3653755861 From psadhukhan at openjdk.org Tue Jan 13 04:32:25 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 13 Jan 2026 04:32:25 GMT Subject: Integrated: 4765299: componentResized() not always called with nested JSplitPanes In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 10:53:31 GMT, Prasanta Sadhukhan wrote: > If a component "comp" be nested inside a "inner" JSplitPane with VERTICAL_SPLIT mode and if then "inner" be nested inside a > "outer" JSplitPane with HORIZONTAL_SPLIT mode and a component listener is added to "comp" > then with this setup, componentResized() on the listener is called ONLY when the divider of "outer" is moved manually > however, it is not called when the divider of "outer" is moved using "One touch expandable" left button at the top of the divider. > > This is because the `layoutContainer` bails out if the width or height is 0 which logically should be to bail out if both width and height is 0 and when "One touch expandable" left button is pressed, width becomes 0 so `layoutContainer` bails out without sending the event. > > With this fix, componentResized is called > > No regression is observed in CI. This pull request has now been integrated. Changeset: 0b9d4c02 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/0b9d4c02e39191e9dba721115f422e28ee5b9869 Stats: 175 lines in 2 files changed: 173 ins; 0 del; 2 mod 4765299: componentResized() not always called with nested JSplitPanes Reviewed-by: tr, kizune ------------- PR: https://git.openjdk.org/jdk/pull/29063 From jdv at openjdk.org Tue Jan 13 05:26:34 2026 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 13 Jan 2026 05:26:34 GMT Subject: RFR: 8373727: New XBM images parser regression: only the first line of the bitmap array is parsed [v3] In-Reply-To: <2z_rf5DfYIl4DYFm58a35_oJK-PGoONVdnGyAlsGmYc=.772a0f35-7f1c-42c2-be49-17683f32003b@github.com> References: <2z_rf5DfYIl4DYFm58a35_oJK-PGoONVdnGyAlsGmYc=.772a0f35-7f1c-42c2-be49-17683f32003b@github.com> Message-ID: On Mon, 12 Jan 2026 20:00:52 GMT, Damon Nguyen wrote: >> There were three concerns with the previous changes to `XbmImageDecoder`. >> 1. Only the first line of the bit array was read. >> 2. The regex was incorrect because it used `[]` instead of `()` for some grouping. >> 3. The ordering of the width and height in the xbm file was too strict and had to be width first, then height. >> >> To fix these issues, I have: >> 1. Used a StringBuilder to append lines of the bit array to parse the entire array at once. This required changing the parsing loop and moving some code. >> 2. Updated the regex to capture starting whitespace, optionally start with `0x`, include all chars/digits/punctuation (minus `,` and `};`) instead of just valid hex digits, and end with either `,` or `};`. This also allows for incorrect hex values such as `0x12345abcde` to be detected since the new regex allows for multiple chars after the `0x` until the next delimiter is found. This is accounted for in the test xbm files. >> 3. Determined width or height based off of ending letters (`th` or `t`). This is similar to https://github.com/openjdk/jdk/blob/jdk-26+10/src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java#L109-L112. >> >> A new method is added to `XBMDecoderTest.java` to better check that the bit array parsing works. This method checks for non-empty pixel data. >> >> A new xbm file is also added to check for the case where `0xAB+` exists in the bit array. This should be invalid, and the previous regex would allow this to pass. >> >> All tests pass with the new changes made here. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Add new xbm file to test for multiple lines in bit array LGTM. Nice to have better test coverage. ------------- Marked as reviewed by jdv (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29120#pullrequestreview-3653884345 From tr at openjdk.org Tue Jan 13 07:43:05 2026 From: tr at openjdk.org (Tejesh R) Date: Tue, 13 Jan 2026 07:43:05 GMT Subject: RFR: 6441373: Editing JTable is not Serializable [v7] In-Reply-To: References: Message-ID: <5qeVbM7BL1FrciOR5YKZh2u9ahsytSa54dKJN45LhDo=.1681c0f5-d5fb-4d86-9566-5da36d7fcf19@github.com> On Fri, 2 Jan 2026 10:05:57 GMT, Prasanta Sadhukhan wrote: >> Issue is when JTable is in editing mode, it is not Serializable as it gives exception >> >> java.io.NotSerializableException: java.lang.reflect.Constructor >> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1149) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1502) >> at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1467) >> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1385) >> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1143) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1502) >> ....... >> >> >> It is caused by creation of `GenericEditor` class which uses a non-serializable Constructor field. >> This is fixed by making the field transient.. >> Also, `editorRemover` field is made transient as it is object of `CellEditorRemover` class which is not Serializable.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Component count leakage fix src/java.desktop/share/classes/javax/swing/JTable.java line 5610: > 5608: } > 5609: > 5610: public void writeExternal(java.io.ObjectOutput out) throws IOException {} Can add @Override here ? src/java.desktop/share/classes/javax/swing/JTable.java line 5612: > 5610: public void writeExternal(java.io.ObjectOutput out) throws IOException {} > 5611: > 5612: public void readExternal(java.io.ObjectInput in) throws IOException {} I suggest adding `java.io.ObjectInput/ObjectOutput` imports would be better rather than expanding here. test/jdk/javax/swing/JTable/EditingJTableNotSerializable.java line 64: > 62: private static void testSerializeEditingTable(StringBuilder str) { > 63: try { > 64: Object[][] data = new Object[][]{ new Object[]{ 1,2,3,4,5}}; Suggestion: Object[][] data = new Object[][]{ new Object[]{1, 2, 3, 4, 5}}; test/jdk/javax/swing/JTable/EditingJTableNotSerializable.java line 65: > 63: try { > 64: Object[][] data = new Object[][]{ new Object[]{ 1,2,3,4,5}}; > 65: Object[] names = new Object[]{ 1,2,3,4,5}; Suggestion: Object[] names = new Object[]{1, 2, 3, 4, 5}; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28627#discussion_r2685033972 PR Review Comment: https://git.openjdk.org/jdk/pull/28627#discussion_r2685038227 PR Review Comment: https://git.openjdk.org/jdk/pull/28627#discussion_r2685216548 PR Review Comment: https://git.openjdk.org/jdk/pull/28627#discussion_r2685217523 From duke at openjdk.org Tue Jan 13 13:23:56 2026 From: duke at openjdk.org (ANUPAM DEV) Date: Tue, 13 Jan 2026 13:23:56 GMT Subject: RFR: 8375013: J2DdemoTest.java - Platform default encoding used for process output Message-ID: <-LVPS8DoA6A0MQfINvy6CuhpYQKlAb5hvVULUu8wUVg=.6f57bf8a-94e2-4b55-81ca-048308bedf1d@github.com> Hi, new String(b, 0, n) looks at the operating system's default locale. If these differ between the build machine and the test runner, tests can fail. StandardCharsets.UTF_8 is guaranteed to be available on all Java platforms. Since "ERROR" and "Exception" are ASCII characters, and ASCII is a subset of UTF-8, this will correctly match the tokens regardless of the underlying platform's obscure defaults. Kindly review. Regards, Anupam ------------- Commit messages: - 8375013: J2DdemoTest.java - Platform default encoding used for process output Changes: https://git.openjdk.org/jdk/pull/29190/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29190&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375013 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29190.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29190/head:pull/29190 PR: https://git.openjdk.org/jdk/pull/29190 From mbaesken at openjdk.org Tue Jan 13 14:12:11 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 13 Jan 2026 14:12:11 GMT Subject: RFR: 8374727: Audio configuration Platform class - use nio for getting endianness of the underlying platform [v3] In-Reply-To: <6sqOUNxD-689bHTF0K0ylAEXcYLOFRtdLH2j8UFq2XY=.03449816-fe5d-4dad-8bdb-44cebf01e17f@github.com> References: <6sqOUNxD-689bHTF0K0ylAEXcYLOFRtdLH2j8UFq2XY=.03449816-fe5d-4dad-8bdb-44cebf01e17f@github.com> Message-ID: > Currently Platform.java from the audio coding uses its own native code to get the endianness info of the underlying hardware it runs on. > See https://github.com/openjdk/jdk/blob/da14813a5bdadaf0a1f81fa57ff6e1b103eaf113/src/java.desktop/share/classes/com/sun/media/sound/Platform.java#L86 > But we can reuse existing Java JDK code e.g. from nio. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Add import ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29113/files - new: https://git.openjdk.org/jdk/pull/29113/files/90202d64..382e8aef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29113&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29113&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29113.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29113/head:pull/29113 PR: https://git.openjdk.org/jdk/pull/29113 From mbaesken at openjdk.org Tue Jan 13 14:12:13 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 13 Jan 2026 14:12:13 GMT Subject: RFR: 8374727: Audio configuration Platform class - use nio for getting endianness of the underlying platform [v2] In-Reply-To: References: <6sqOUNxD-689bHTF0K0ylAEXcYLOFRtdLH2j8UFq2XY=.03449816-fe5d-4dad-8bdb-44cebf01e17f@github.com> <3glGJ8-cTg5TXNnC4OlGZBtxKwGa7J6FdVqTAtx90cc=.ca52b952-288d-4279-9686-c6f5be13851b@github.com> Message-ID: On Mon, 12 Jan 2026 17:34:32 GMT, Sergey Bylokhov wrote: >> Just checked how other JDK coding is doing the LE/BE test, then copied it from here >> https://github.com/openjdk/jdk/blob/7cf7f01fb339bf3c5b81d946be8afa71ec267e42/src/java.security.jgss/share/classes/sun/security/krb5/internal/util/KrbDataInputStream.java#L49 >> Should I instead import `java.nio.ByteOrder` ? > > yes this is how it is used in desktop module. I added the import. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29113#discussion_r2686579614 From prr at openjdk.org Tue Jan 13 16:50:16 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 13 Jan 2026 16:50:16 GMT Subject: RFR: 8374727: Audio configuration Platform class - use nio for getting endianness of the underlying platform [v3] In-Reply-To: References: <6sqOUNxD-689bHTF0K0ylAEXcYLOFRtdLH2j8UFq2XY=.03449816-fe5d-4dad-8bdb-44cebf01e17f@github.com> Message-ID: On Tue, 13 Jan 2026 14:12:11 GMT, Matthias Baesken wrote: >> Currently Platform.java from the audio coding uses its own native code to get the endianness info of the underlying hardware it runs on. >> See https://github.com/openjdk/jdk/blob/da14813a5bdadaf0a1f81fa57ff6e1b103eaf113/src/java.desktop/share/classes/com/sun/media/sound/Platform.java#L86 >> But we can reuse existing Java JDK code e.g. from nio. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Add import Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29113#pullrequestreview-3656816481 From prr at openjdk.org Tue Jan 13 16:56:24 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 13 Jan 2026 16:56:24 GMT Subject: RFR: 8375013: J2DdemoTest.java - Platform default encoding used for process output In-Reply-To: <-LVPS8DoA6A0MQfINvy6CuhpYQKlAb5hvVULUu8wUVg=.6f57bf8a-94e2-4b55-81ca-048308bedf1d@github.com> References: <-LVPS8DoA6A0MQfINvy6CuhpYQKlAb5hvVULUu8wUVg=.6f57bf8a-94e2-4b55-81ca-048308bedf1d@github.com> Message-ID: On Tue, 13 Jan 2026 13:15:00 GMT, ANUPAM DEV wrote: > If these differ between the build machine and the test runner, tests can fail. How does the build machine locale matter ? Is something caching encoded output at compile time ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29190#issuecomment-3745381986 From dnguyen at openjdk.org Tue Jan 13 16:58:05 2026 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 13 Jan 2026 16:58:05 GMT Subject: Integrated: 8373727: New XBM images parser regression: only the first line of the bitmap array is parsed In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 17:09:24 GMT, Damon Nguyen wrote: > There were three concerns with the previous changes to `XbmImageDecoder`. > 1. Only the first line of the bit array was read. > 2. The regex was incorrect because it used `[]` instead of `()` for some grouping. > 3. The ordering of the width and height in the xbm file was too strict and had to be width first, then height. > > To fix these issues, I have: > 1. Used a StringBuilder to append lines of the bit array to parse the entire array at once. This required changing the parsing loop and moving some code. > 2. Updated the regex to capture starting whitespace, optionally start with `0x`, include all chars/digits/punctuation (minus `,` and `};`) instead of just valid hex digits, and end with either `,` or `};`. This also allows for incorrect hex values such as `0x12345abcde` to be detected since the new regex allows for multiple chars after the `0x` until the next delimiter is found. This is accounted for in the test xbm files. > 3. Determined width or height based off of ending letters (`th` or `t`). This is similar to https://github.com/openjdk/jdk/blob/jdk-26+10/src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java#L109-L112. > > A new method is added to `XBMDecoderTest.java` to better check that the bit array parsing works. This method checks for non-empty pixel data. > > A new xbm file is also added to check for the case where `0xAB+` exists in the bit array. This should be invalid, and the previous regex would allow this to pass. > > All tests pass with the new changes made here. This pull request has now been integrated. Changeset: 7f707ba8 Author: Damon Nguyen URL: https://git.openjdk.org/jdk/commit/7f707ba8e746d859ac171d71ef8f731953a92e6a Stats: 141 lines in 6 files changed: 86 ins; 17 del; 38 mod 8373727: New XBM images parser regression: only the first line of the bitmap array is parsed Reviewed-by: prr, jdv ------------- PR: https://git.openjdk.org/jdk/pull/29120 From mbaesken at openjdk.org Tue Jan 13 17:01:50 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 13 Jan 2026 17:01:50 GMT Subject: RFR: 8374727: Audio configuration Platform class - use nio for getting endianness of the underlying platform [v3] In-Reply-To: References: <6sqOUNxD-689bHTF0K0ylAEXcYLOFRtdLH2j8UFq2XY=.03449816-fe5d-4dad-8bdb-44cebf01e17f@github.com> Message-ID: On Tue, 13 Jan 2026 14:12:11 GMT, Matthias Baesken wrote: >> Currently Platform.java from the audio coding uses its own native code to get the endianness info of the underlying hardware it runs on. >> See https://github.com/openjdk/jdk/blob/da14813a5bdadaf0a1f81fa57ff6e1b103eaf113/src/java.desktop/share/classes/com/sun/media/sound/Platform.java#L86 >> But we can reuse existing Java JDK code e.g. from nio. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Add import Thanks for the reviews ! Btw. what do you think about having direct helper methods in ByteOrder, like `ByteOrder.nativeOrderIsBigEndian()` to shorten the coding a bit (here and also at other places) ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29113#issuecomment-3745399160 PR Comment: https://git.openjdk.org/jdk/pull/29113#issuecomment-3745409130 From mbaesken at openjdk.org Tue Jan 13 17:01:52 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 13 Jan 2026 17:01:52 GMT Subject: Integrated: 8374727: Audio configuration Platform class - use nio for getting endianness of the underlying platform In-Reply-To: <6sqOUNxD-689bHTF0K0ylAEXcYLOFRtdLH2j8UFq2XY=.03449816-fe5d-4dad-8bdb-44cebf01e17f@github.com> References: <6sqOUNxD-689bHTF0K0ylAEXcYLOFRtdLH2j8UFq2XY=.03449816-fe5d-4dad-8bdb-44cebf01e17f@github.com> Message-ID: On Thu, 8 Jan 2026 10:13:54 GMT, Matthias Baesken wrote: > Currently Platform.java from the audio coding uses its own native code to get the endianness info of the underlying hardware it runs on. > See https://github.com/openjdk/jdk/blob/da14813a5bdadaf0a1f81fa57ff6e1b103eaf113/src/java.desktop/share/classes/com/sun/media/sound/Platform.java#L86 > But we can reuse existing Java JDK code e.g. from nio. This pull request has now been integrated. Changeset: 07403843 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/074038438f5b8b91e9390430b4fa58ff53e5df26 Stats: 77 lines in 5 files changed: 1 ins; 69 del; 7 mod 8374727: Audio configuration Platform class - use nio for getting endianness of the underlying platform Reviewed-by: prr, kizune ------------- PR: https://git.openjdk.org/jdk/pull/29113 From prr at openjdk.org Tue Jan 13 17:04:23 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 13 Jan 2026 17:04:23 GMT Subject: RFR: 8374493: Add missing @Override annotations in "com.sun.java.swing.plaf.motif" package In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 01:39:18 GMT, Sergey Bylokhov wrote: > This patch adds missing `@Override` annotations to methods in the `com.sun.java.swing.plaf.motif` package that override methods from a superclass or interface. > Only source annotations are added; there are no behavioral changes. > > The previous patch for `com.sun.beans` can be found here: https://github.com/openjdk/jdk/pull/27887. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29026#pullrequestreview-3656882230 From prr at openjdk.org Tue Jan 13 17:20:14 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 13 Jan 2026 17:20:14 GMT Subject: RFR: 4197755: Arc2D.getBounds() returns an unnecessarily large bounding box [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 08:44:26 GMT, Jeremy Wood wrote: > I'm not very familiar with CSR's, so please let me know if this needs improvement/rewriting: https://bugs.openjdk.org/browse/JDK-8374859 I've modified it and marked it as reviewed. You may now "finalize" it - ie move it to the finalized state. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26715#issuecomment-3745500689 From dnguyen at openjdk.org Tue Jan 13 18:31:37 2026 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 13 Jan 2026 18:31:37 GMT Subject: [jdk26] RFR: 8373727: New XBM images parser regression: only the first line of the bitmap array is parsed Message-ID: <1LSaYxCj2N1LMD9ZSbNRnk2QdfYCMz7nyoQGViLmQpc=.c979e2d3-8085-4c4c-bf6a-445ecc54d789@github.com> Hi all, This pull request contains a backport of commit [7f707ba8](https://github.com/openjdk/jdk/commit/7f707ba8e746d859ac171d71ef8f731953a92e6a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Damon Nguyen on 13 Jan 2026 and was reviewed by Phil Race and Jayathirth D V. Thanks! ------------- Commit messages: - Backport 7f707ba8e746d859ac171d71ef8f731953a92e6a Changes: https://git.openjdk.org/jdk/pull/29204/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29204&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373727 Stats: 141 lines in 6 files changed: 86 ins; 17 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/29204.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29204/head:pull/29204 PR: https://git.openjdk.org/jdk/pull/29204 From prr at openjdk.org Tue Jan 13 19:50:40 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 13 Jan 2026 19:50:40 GMT Subject: [jdk26] RFR: 8373727: New XBM images parser regression: only the first line of the bitmap array is parsed In-Reply-To: <1LSaYxCj2N1LMD9ZSbNRnk2QdfYCMz7nyoQGViLmQpc=.c979e2d3-8085-4c4c-bf6a-445ecc54d789@github.com> References: <1LSaYxCj2N1LMD9ZSbNRnk2QdfYCMz7nyoQGViLmQpc=.c979e2d3-8085-4c4c-bf6a-445ecc54d789@github.com> Message-ID: On Tue, 13 Jan 2026 18:22:39 GMT, Damon Nguyen wrote: > Hi all, > > This pull request contains a backport of commit [7f707ba8](https://github.com/openjdk/jdk/commit/7f707ba8e746d859ac171d71ef8f731953a92e6a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Damon Nguyen on 13 Jan 2026 and was reviewed by Phil Race and Jayathirth D V. > > Thanks! Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29204#pullrequestreview-3657642027 From aivanov at openjdk.org Tue Jan 13 20:06:55 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 13 Jan 2026 20:06:55 GMT Subject: RFR: 8374493: Add missing @Override annotations in "com.sun.java.swing.plaf.motif" package In-Reply-To: References: Message-ID: <5B0l_T7osb8j0bmVZIUXgrIj1Fcv0cB6hK_dtXmeTGs=.4a9d8c8d-84e8-4ea7-88d1-84ec5ac7216d@github.com> On Mon, 5 Jan 2026 01:39:18 GMT, Sergey Bylokhov wrote: > This patch adds missing `@Override` annotations to methods in the `com.sun.java.swing.plaf.motif` package that override methods from a superclass or interface. > Only source annotations are added; there are no behavioral changes. > > The previous patch for `com.sun.beans` can be found here: https://github.com/openjdk/jdk/pull/27887. Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29026#pullrequestreview-3657738354 From prr at openjdk.org Tue Jan 13 20:57:56 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 13 Jan 2026 20:57:56 GMT Subject: RFR: 8375221: Update code to get PrinterResolution from CUPS/IPP print service Message-ID: Previous to this fix, no resolution was being found via CUPS/IPP and when the test case for printer resolution was falling back to the made up 300dpi setting. With this fix it finds the 600dpi from CUPS/IPP. ------------- Commit messages: - 8375221 Changes: https://git.openjdk.org/jdk/pull/29208/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29208&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375221 Stats: 112 lines in 3 files changed: 77 ins; 22 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/29208.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29208/head:pull/29208 PR: https://git.openjdk.org/jdk/pull/29208 From serb at openjdk.org Wed Jan 14 04:57:29 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 14 Jan 2026 04:57:29 GMT Subject: RFR: 8375221: Update code to get PrinterResolution from CUPS/IPP print service In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 20:51:35 GMT, Phil Race wrote: > Previous to this fix, no resolution was being found via CUPS/IPP and when the test case for printer resolution was falling back to the made up 300dpi setting. With this fix it finds the 600dpi from CUPS/IPP. src/java.desktop/unix/classes/sun/print/IPPPrintService.java line 1718: > 1716: PrinterResolution []arr = new PrinterResolution[printerResolutions.length]; > 1717: System.arraycopy(printerResolutions, 0, arr, 0, printerResolutions.length); > 1718: return arr; Can this be simplified to just "return printerResolutions.clone()"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29208#discussion_r2688941209 From duke at openjdk.org Wed Jan 14 05:04:07 2026 From: duke at openjdk.org (ANUPAM DEV) Date: Wed, 14 Jan 2026 05:04:07 GMT Subject: RFR: 8375013: J2DdemoTest.java - Platform default encoding used for process output In-Reply-To: References: <-LVPS8DoA6A0MQfINvy6CuhpYQKlAb5hvVULUu8wUVg=.6f57bf8a-94e2-4b55-81ca-048308bedf1d@github.com> Message-ID: On Tue, 13 Jan 2026 16:52:30 GMT, Phil Race wrote: >> Hi, >> >> new String(b, 0, n) looks at the operating system's default locale. If these differ between the build machine and the test runner, tests can fail. >> StandardCharsets.UTF_8 is guaranteed to be available on all Java platforms. >> >> Since "ERROR" and "Exception" are ASCII characters, and ASCII is a subset of UTF-8, this will correctly match the tokens regardless of the underlying platform's obscure defaults. >> >> Kindly review. >> >> Regards, >> Anupam > >> If these differ between the build machine and the test runner, tests can fail. > > How does the build machine locale matter ? Is something caching encoded output at compile time ? Hi @prrace , No, there is no caching at compile time. I referred the test environment as build machine for the class J2DdemoTest. The test runner can be any IDE or different shell with ANSI. If J2Ddemo outputs a special character (for example a non-standard character in a file path) that doesn't map correctly in ANSI, the decoding might fail or garble the text surrounding it. So in spite of the error, the below two will never be true: `if (test.output_contains("ERROR")) ` `if (test.output_contains("Exception")) ` Regards, Anupam ------------- PR Comment: https://git.openjdk.org/jdk/pull/29190#issuecomment-3747737943 From serb at openjdk.org Wed Jan 14 06:21:05 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 14 Jan 2026 06:21:05 GMT Subject: RFR: 8374493: Add missing @Override annotations in "com.sun.java.swing.plaf.motif" package [v2] In-Reply-To: References: Message-ID: > This patch adds missing `@Override` annotations to methods in the `com.sun.java.swing.plaf.motif` package that override methods from a superclass or interface. > Only source annotations are added; there are no behavioral changes. > > The previous patch for `com.sun.beans` can be found here: https://github.com/openjdk/jdk/pull/27887. Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'openjdk:master' into motif_over - 8374493: Add missing @Override annotations in "com.sun.java.swing.plaf.motif" package ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29026/files - new: https://git.openjdk.org/jdk/pull/29026/files/916d0f41..b4760423 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29026&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29026&range=00-01 Stats: 51983 lines in 954 files changed: 25699 ins; 10348 del; 15936 mod Patch: https://git.openjdk.org/jdk/pull/29026.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29026/head:pull/29026 PR: https://git.openjdk.org/jdk/pull/29026 From duke at openjdk.org Wed Jan 14 10:29:23 2026 From: duke at openjdk.org (ANUPAM DEV) Date: Wed, 14 Jan 2026 10:29:23 GMT Subject: RFR: 8375011: OldJTable.java - NullPointerException when columnData is null Message-ID: Hi, This is a fix for NPE in OldJTable.addColumn The addColumn method in OldJTable.java was unconditionally calling columnData.toArray(), which caused a NullPointerException when columnData was null (e.g., when called from addColumn(Object, int)). This commit adds a null check to safe-guard against this NPE, passing null to the underlying DefaultTableModel when columnData is missing. Kindly review. Regards, Anupam ------------- Commit messages: - Modified code for null check Changes: https://git.openjdk.org/jdk/pull/29226/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29226&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375011 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29226/head:pull/29226 PR: https://git.openjdk.org/jdk/pull/29226 From duke at openjdk.org Wed Jan 14 10:40:57 2026 From: duke at openjdk.org (ANUPAM DEV) Date: Wed, 14 Jan 2026 10:40:57 GMT Subject: RFR: 8375011: OldJTable.java - NullPointerException when columnData is null [v2] In-Reply-To: References: Message-ID: > Hi, > > This is a fix for NPE in OldJTable.addColumn > > The addColumn method in OldJTable.java was unconditionally calling columnData.toArray(), which caused a NullPointerException when columnData was null (e.g., when called from addColumn(Object, int)). > > This commit adds a null check to safe-guard against this NPE, passing null to the underlying DefaultTableModel when columnData is missing. > > Kindly review. > > Regards, > Anupam ANUPAM DEV has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Modified code for null check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29226/files - new: https://git.openjdk.org/jdk/pull/29226/files/24fa42b2..b62c23b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29226&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29226&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29226/head:pull/29226 PR: https://git.openjdk.org/jdk/pull/29226 From duke at openjdk.org Wed Jan 14 12:47:08 2026 From: duke at openjdk.org (Christian Heilmann) Date: Wed, 14 Jan 2026 12:47:08 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v6] In-Reply-To: References: Message-ID: <3H5ISsD05LkKkWQ5zVPtZeJDilAVHrRdJuoOFqj3Hso=.3fece139-170d-41d6-97db-f9e75f723978@github.com> > This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS. > > The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m. Christian Heilmann has updated the pull request incrementally with one additional commit since the last revision: Changed copyright year to 2026 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11266/files - new: https://git.openjdk.org/jdk/pull/11266/files/845d55e7..64fbbd84 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11266&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11266&range=04-05 Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/11266.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/11266/head:pull/11266 PR: https://git.openjdk.org/jdk/pull/11266 From duke at openjdk.org Wed Jan 14 12:47:10 2026 From: duke at openjdk.org (Christian Heilmann) Date: Wed, 14 Jan 2026 12:47:10 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v2] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 14:55:55 GMT, Christian Heilmann wrote: >> src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m line 1: >> >>> 1: /* >> >> Bump the copyright year to 2025. > > done. Changed the copyright year now to 2026. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11266#discussion_r2690280465 From duke at openjdk.org Wed Jan 14 13:28:19 2026 From: duke at openjdk.org (GennadiyKrivoshein) Date: Wed, 14 Jan 2026 13:28:19 GMT Subject: RFR: 8375221: Update code to get PrinterResolution from CUPS/IPP print service In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 20:51:35 GMT, Phil Race wrote: > Previous to this fix, no resolution was being found via CUPS/IPP and when the test case for printer resolution was falling back to the made up 300dpi setting. With this fix it finds the 600dpi from CUPS/IPP. src/java.desktop/unix/classes/sun/print/IPPPrintService.java line 1699: > 1697: : null; > 1698: if (attribClass != null) { > 1699: rawResolutions = attribClass.getIntRangeValue(); Regarding to the RFC8011, section 5.1.16 (https://datatracker.ietf.org/doc/html/rfc8011#section-5.1.16), the IPP 'resoltion' attribute consists of three values. >The 'resolution' attribute syntax specifies a two-dimensional resolution in the indicated units. It consists of three values: a cross-feed direction resolution (positive integer value), a feed direction resolution (positive integer value), and a units value. For example, '300','600','3' indicates a 300-dpi cross-feed direction resolution and a 600-dpi feed direction resolution, since a '3' indicates dots per inch (dpi). So the `rawResolutions = attribClass.getIntRangeValue();` and subsequent `int numRes = rawResolutions.length / 2;` looks wrong. I checked the "attribClass" value with my printer and it contains three values per resolution. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29208#discussion_r2690423658 From aivanov at openjdk.org Wed Jan 14 16:38:02 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 14 Jan 2026 16:38:02 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v6] In-Reply-To: <3H5ISsD05LkKkWQ5zVPtZeJDilAVHrRdJuoOFqj3Hso=.3fece139-170d-41d6-97db-f9e75f723978@github.com> References: <3H5ISsD05LkKkWQ5zVPtZeJDilAVHrRdJuoOFqj3Hso=.3fece139-170d-41d6-97db-f9e75f723978@github.com> Message-ID: On Wed, 14 Jan 2026 12:47:08 GMT, Christian Heilmann wrote: >> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS. >> >> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m. > > Christian Heilmann has updated the pull request incrementally with one additional commit since the last revision: > > Changed copyright year to 2026 Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/11266#pullrequestreview-3661661278 From dnguyen at openjdk.org Wed Jan 14 17:06:44 2026 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 14 Jan 2026 17:06:44 GMT Subject: [jdk26] Integrated: 8373727: New XBM images parser regression: only the first line of the bitmap array is parsed In-Reply-To: <1LSaYxCj2N1LMD9ZSbNRnk2QdfYCMz7nyoQGViLmQpc=.c979e2d3-8085-4c4c-bf6a-445ecc54d789@github.com> References: <1LSaYxCj2N1LMD9ZSbNRnk2QdfYCMz7nyoQGViLmQpc=.c979e2d3-8085-4c4c-bf6a-445ecc54d789@github.com> Message-ID: On Tue, 13 Jan 2026 18:22:39 GMT, Damon Nguyen wrote: > Hi all, > > This pull request contains a backport of commit [7f707ba8](https://github.com/openjdk/jdk/commit/7f707ba8e746d859ac171d71ef8f731953a92e6a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Damon Nguyen on 13 Jan 2026 and was reviewed by Phil Race and Jayathirth D V. > > Thanks! This pull request has now been integrated. Changeset: d011d7c7 Author: Damon Nguyen URL: https://git.openjdk.org/jdk/commit/d011d7c7cc191db47791ff642d4c5c7d1ba8eec0 Stats: 141 lines in 6 files changed: 86 ins; 17 del; 38 mod 8373727: New XBM images parser regression: only the first line of the bitmap array is parsed Reviewed-by: prr Backport-of: 7f707ba8e746d859ac171d71ef8f731953a92e6a ------------- PR: https://git.openjdk.org/jdk/pull/29204 From kizune at openjdk.org Wed Jan 14 20:51:25 2026 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 14 Jan 2026 20:51:25 GMT Subject: RFR: 8286258: [Accessibility,macOS,VoiceOver] VoiceOver reads the spinner value wrong and sometime partially Message-ID: The issue with the announcement of the custom spin boxes is that the text field inside when the value is being changed by the spinbox data model generates some events that are being interpreted by the accessibility subsystem as if text is being actively edited and the system tries to announce it accordingly. In order to stop it from happening we are going to generate correct events and temporarily suppress the text field's methods that reporting the editing-related changes until the actual editing is happened. Make embedded text field not to generate random edit-related events; Add manual test case; ------------- Commit messages: - Remove whitespaces - 8286258: [Accessibility,macOS,VoiceOver] VoiceOver reads the spinner value wrong and sometime partially Changes: https://git.openjdk.org/jdk/pull/29235/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29235&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8286258 Stats: 141 lines in 4 files changed: 136 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29235.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29235/head:pull/29235 PR: https://git.openjdk.org/jdk/pull/29235 From serb at openjdk.org Wed Jan 14 21:30:56 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 14 Jan 2026 21:30:56 GMT Subject: Integrated: 8374493: Add missing @Override annotations in "com.sun.java.swing.plaf.motif" package In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 01:39:18 GMT, Sergey Bylokhov wrote: > This patch adds missing `@Override` annotations to methods in the `com.sun.java.swing.plaf.motif` package that override methods from a superclass or interface. > Only source annotations are added; there are no behavioral changes. > > The previous patch for `com.sun.beans` can be found here: https://github.com/openjdk/jdk/pull/27887. This pull request has now been integrated. Changeset: 6ad9f4ef Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/6ad9f4ef6826bb031db7840ba3f689b0bde47775 Stats: 377 lines in 37 files changed: 340 ins; 0 del; 37 mod 8374493: Add missing @Override annotations in "com.sun.java.swing.plaf.motif" package Reviewed-by: tr, prr, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/29026 From prr at openjdk.org Wed Jan 14 21:48:19 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 14 Jan 2026 21:48:19 GMT Subject: RFR: 8375350: Remove usage of AppContext from javax.imageio implementation Message-ID: Remove usage of AppContext from Image IO ------------- Commit messages: - 8375350 Changes: https://git.openjdk.org/jdk/pull/29236/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29236&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375350 Stats: 14 lines in 1 file changed: 2 ins; 10 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29236.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29236/head:pull/29236 PR: https://git.openjdk.org/jdk/pull/29236 From prr at openjdk.org Wed Jan 14 21:51:21 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 14 Jan 2026 21:51:21 GMT Subject: RFR: 8375351: Remove usage of AppContext from print implementation Message-ID: Remove AppContext from javax.print ------------- Commit messages: - 8375351 Changes: https://git.openjdk.org/jdk/pull/29237/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29237&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375351 Stats: 15 lines in 1 file changed: 1 ins; 7 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29237/head:pull/29237 PR: https://git.openjdk.org/jdk/pull/29237 From kizune at openjdk.org Wed Jan 14 22:50:09 2026 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 14 Jan 2026 22:50:09 GMT Subject: RFR: 8375350: Remove usage of AppContext from javax.imageio implementation In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 21:41:21 GMT, Phil Race wrote: > Remove usage of AppContext from Image IO Looks reasonable. ------------- Marked as reviewed by kizune (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29236#pullrequestreview-3663170793 From dnguyen at openjdk.org Wed Jan 14 23:56:18 2026 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 14 Jan 2026 23:56:18 GMT Subject: RFR: 8375350: Remove usage of AppContext from javax.imageio implementation In-Reply-To: References: Message-ID: <4LJtzjlN_NxuEEH2xOz7DSQ7IFAAkKEZFansZs9VZns=.6f8c0e50-8b1c-47fd-b8cd-932506b302d2@github.com> On Wed, 14 Jan 2026 21:41:21 GMT, Phil Race wrote: > Remove usage of AppContext from Image IO LGTM but does the Copyright year need to be updated to 2026 as well? ------------- Changes requested by dnguyen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29236#pullrequestreview-3663339143 From dnguyen at openjdk.org Thu Jan 15 00:43:51 2026 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 15 Jan 2026 00:43:51 GMT Subject: RFR: 8373650: Test javax/swing/JMenuItem/6458123/ManualBug6458123.java fails because the check icons are not aligned properly as expected [v3] In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 07:07:28 GMT, Prasanta Sadhukhan wrote: >> Check/radiobutton icon are not aligned properly in RTL. `WindowsMenuItemUI `uses `MenuItemLayoutHelper.layoutMenuItem` to do the layout which calls `doRTLColumnLayout `which calculates x positions in `calcXPositionsRTL `and then again aligns in `alignRects`. However, since in Windows historically radiobutton/check icon was not drawn or drawn below the menuitem image icon (since image icon and check icon was drawn in the same layout space and not separately) the aligned x position of check icons returned from `MenuItemLayoutHelper` was not correct but since `MenuItemLayoutHelper` alignment is used in other L&Fs also so we need to realign it in windows specific class i.e in WindowsIconFactory in paintIcon >> >> Before fix >> >> image >> >> After fix >> >> image > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Use menuItem var Although the if/else branches look strange, it works. I don't see a clear way to clean up and condense the conditionals so lgtm unless someone else has an idea. Also I guess this Copyright year needs to be updated to 2026 now as well. ------------- Marked as reviewed by dnguyen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28889#pullrequestreview-3663417638 PR Comment: https://git.openjdk.org/jdk/pull/28889#issuecomment-3752341607 From syan at openjdk.org Thu Jan 15 07:43:29 2026 From: syan at openjdk.org (SendaoYan) Date: Thu, 15 Jan 2026 07:43:29 GMT Subject: RFR: 8375370: XRBackendNative.c reported variable uninitialized by clang23 Message-ID: Hi all, The local variable `pict_attr` in function `JNIEXPORT jint JNICALL Java_sun_java2d_xr_XRBackendNative_createPictureNative (JNIEnv *env, jclass cls, jint drawable, jlong formatPtr)` reported variable uninitialized by clang23. This PR initial `pict_attr.repeat` to `RepeatNone` which will avoid compiler warning by clang23. This mofication references another `XRenderCreatePicture` call at file [XRSurfaceData.c](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libawt_xawt/java2d/x11/XRSurfaceData.c#L72), they are all call the same function `XRenderCreatePicture`. ------------- Commit messages: - 8375370: XRBackendNative.c reported variable uninitialized by clang23 Changes: https://git.openjdk.org/jdk/pull/29248/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29248&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375370 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29248.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29248/head:pull/29248 PR: https://git.openjdk.org/jdk/pull/29248 From aivanov at openjdk.org Thu Jan 15 12:34:41 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 15 Jan 2026 12:34:41 GMT Subject: RFR: 8373650: Test javax/swing/JMenuItem/6458123/ManualBug6458123.java fails because the check icons are not aligned properly as expected [v2] In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 07:01:34 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 922: >> >>> 920: x + OFFSET, >>> 921: (icon.getIconHeight() <= 16) ? y + OFFSET : (y + icon.getIconHeight() / 2), state); >>> 922: } else if (icon.getIconWidth() <= 16) { >> >> I don't understand why painting an icon and check marks / radio bullets in RTL case depends on the width of the icon but there's no such dependency in LTR case. >> >> Shouldn't the performed menu layout handle these cases? > > As I see, MenuItemLayout handler's x position calculation for RTL depends on icon rect width > https://github.com/openjdk/jdk/blob/6eaabed55ca4670d8c317f0a4323ccea4dd0b9ca/src/java.desktop/share/classes/sun/swing/MenuItemLayoutHelper.java#L737-L741 > but LTR doesn't depend on rect width > https://github.com/openjdk/jdk/blob/6eaabed55ca4670d8c317f0a4323ccea4dd0b9ca/src/java.desktop/share/classes/sun/swing/MenuItemLayoutHelper.java#L726-L730 Okay, but why do you have tweak the layout produced by `MenuItemLayoutHelper`? Do Metal and Nimbus have to tweak the layout too? Is it because Windows icons used to be special and combined the icon and check mark / bullet mark, or rather replaced the check mark / bullet mark with the icon? Should we get rid of that special treatment? I'd like to have answers to these questions. To be clear, I'm not opposing this approach, it seems to work, yet it seems superfluous, the code kind of repeats calculations. Both Metal and Nimbus L&F have similar column layouts where a separate column is allocated for marks and icons, Windows L&F should re-use that code. >> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 936: >> >>> 934: skin.paintSkin(g, >>> 935: (type == JRadioButtonMenuItem.class) ? (x + 3 * OFFSET) : (x + 4 * OFFSET), >>> 936: (icon.getIconHeight() <= 16) ? y + OFFSET : (y + icon.getIconHeight() / 2), state); >> >> I wonder why painting the skin for radio button menu requires such a fix up whereas it's not required for `JCheckBoxMenuItem`. > > it is taken care via ternary operator, width/spread of check mark is usually more than radio bullet so starting point of checkmark is considered a little ahead compared to radio bullet I see that it's taken care by the ternary operator. Why is it needed, though? The skin for both check mark and radio bullet have the same size, and the mark is positioned accordingly inside the rectangle. This works well for the LTR layout, both marks are rendered at the same location and appear aligned in the end. Why does RTL layout treat these marks differently? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28889#discussion_r2694197701 PR Review Comment: https://git.openjdk.org/jdk/pull/28889#discussion_r2694204711 From aivanov at openjdk.org Thu Jan 15 12:41:49 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 15 Jan 2026 12:41:49 GMT Subject: RFR: 8373650: Test javax/swing/JMenuItem/6458123/ManualBug6458123.java fails because the check icons are not aligned properly as expected [v3] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 00:39:24 GMT, Damon Nguyen wrote: > Although the if/else branches look strange, it works. I don't see a clear way to clean up and condense the conditionals so lgtm unless someone else has an idea. I haven't looked at the updated code yet. I wonder why the logic in `MenuItemLayoutHelper.java` isn't enough, why adjustments are needed. As I posted in [my previous comment](https://github.com/openjdk/jdk/pull/28889#discussion_r2694197701), I'm not against this approach as long as it works and fixes the layout, yet I'd like to clean up the code if possible? in a follow-up issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28889#issuecomment-3754543967 From prr at openjdk.org Thu Jan 15 17:30:02 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 15 Jan 2026 17:30:02 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v6] In-Reply-To: <3H5ISsD05LkKkWQ5zVPtZeJDilAVHrRdJuoOFqj3Hso=.3fece139-170d-41d6-97db-f9e75f723978@github.com> References: <3H5ISsD05LkKkWQ5zVPtZeJDilAVHrRdJuoOFqj3Hso=.3fece139-170d-41d6-97db-f9e75f723978@github.com> Message-ID: <_eb3xa20l06fjq85jnWVcqEBtB3DTena6JOQrqxaoBE=.16a94893-d12b-4677-bcf4-900c87cf172a@github.com> On Wed, 14 Jan 2026 12:47:08 GMT, Christian Heilmann wrote: >> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS. >> >> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m. > > Christian Heilmann has updated the pull request incrementally with one additional commit since the last revision: > > Changed copyright year to 2026 Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/11266#pullrequestreview-3666741972 From prr at openjdk.org Thu Jan 15 17:29:59 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 15 Jan 2026 17:29:59 GMT Subject: RFR: 8375221: Update code to get PrinterResolution from CUPS/IPP print service [v2] In-Reply-To: References: Message-ID: > Previous to this fix, no resolution was being found via CUPS/IPP and when the test case for printer resolution was falling back to the made up 300dpi setting. With this fix it finds the 600dpi from CUPS/IPP. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8375221 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29208/files - new: https://git.openjdk.org/jdk/pull/29208/files/b5dd0fba..644c8f11 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29208&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29208&range=00-01 Stats: 41 lines in 3 files changed: 31 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29208.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29208/head:pull/29208 PR: https://git.openjdk.org/jdk/pull/29208 From prr at openjdk.org Thu Jan 15 17:30:10 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 15 Jan 2026 17:30:10 GMT Subject: RFR: 8375221: Update code to get PrinterResolution from CUPS/IPP print service [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 04:53:35 GMT, Sergey Bylokhov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8375221 > > src/java.desktop/unix/classes/sun/print/IPPPrintService.java line 1718: > >> 1716: PrinterResolution []arr = new PrinterResolution[printerResolutions.length]; >> 1717: System.arraycopy(printerResolutions, 0, arr, 0, printerResolutions.length); >> 1718: return arr; > > Can this be simplified to just "return printerResolutions.clone()"? Done. Later I'll take a look if we can do the same in other places in javax.print. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29208#discussion_r2695300242 From prr at openjdk.org Thu Jan 15 17:51:00 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 15 Jan 2026 17:51:00 GMT Subject: RFR: 8375221: Update code to get PrinterResolution from CUPS/IPP print service [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 13:25:14 GMT, GennadiyKrivoshein wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8375221 > > src/java.desktop/unix/classes/sun/print/IPPPrintService.java line 1699: > >> 1697: : null; >> 1698: if (attribClass != null) { >> 1699: rawResolutions = attribClass.getIntRangeValue(); > > Regarding to the RFC8011, section 5.1.16 (https://datatracker.ietf.org/doc/html/rfc8011#section-5.1.16), the IPP 'resoltion' attribute consists of three values. > >>The 'resolution' attribute syntax specifies a two-dimensional resolution in the indicated units. It consists of three values: a cross-feed direction resolution (positive integer value), a feed direction resolution (positive integer value), and a units value. For example, '300','600','3' indicates a 300-dpi cross-feed direction resolution and a 600-dpi feed direction resolution, since a '3' indicates dots per inch (dpi). > > So the `rawResolutions = attribClass.getIntRangeValue();` and subsequent `int numRes = rawResolutions.length / 2;` looks wrong. I checked the "attribClass" value with my printer and it contains three values per resolution. Right. The 3rd value is the resolution unit ID (3 for DPI, 4 for DPCM). Since the AttributeClass method wasn't reading it, I assumed DPI which seems to be the general case, and FWIW is all the PPDs seem to support. The units ID is a byte, so I had to add a special method to AttributeClass. Then now that it returns 3 values, I decided to make the PPD code also return a units ID, so all cases could be processed similarly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29208#discussion_r2695361406 From prr at openjdk.org Thu Jan 15 18:11:12 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 15 Jan 2026 18:11:12 GMT Subject: RFR: 8375370: XRBackendNative.c reported variable uninitialized by clang23 In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 07:36:05 GMT, SendaoYan wrote: > Hi all, > > The local variable `pict_attr` in function `JNIEXPORT jint JNICALL Java_sun_java2d_xr_XRBackendNative_createPictureNative (JNIEnv *env, jclass cls, jint drawable, jlong formatPtr)` reported variable uninitialized by clang23. This PR initial `pict_attr.repeat` to `RepeatNone` which will avoid compiler warning by clang23. This mofication references another `XRenderCreatePicture` call at file [XRSurfaceData.c](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libawt_xawt/java2d/x11/XRSurfaceData.c#L72), they are all call the same function `XRenderCreatePicture`. src/java.desktop/unix/native/libawt_xawt/java2d/x11/XRBackendNative.c line 342: > 340: Java_sun_java2d_xr_XRBackendNative_createPictureNative > 341: (JNIEnv *env, jclass cls, jint drawable, jlong formatPtr) { > 342: XRenderPictureAttributes pict_attr; This looks like an on-stack struct. It should be entirely initialized, not just one field, else it could be all sorts of random garbage. Zeroing it out would be a good start. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29248#discussion_r2695438749 From prr at openjdk.org Thu Jan 15 18:19:01 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 15 Jan 2026 18:19:01 GMT Subject: RFR: 8375351: Remove usage of AppContext from print implementation [v2] In-Reply-To: References: Message-ID: > Remove AppContext from javax.print Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8375351 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29237/files - new: https://git.openjdk.org/jdk/pull/29237/files/1fb2b161..bb456985 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29237&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29237&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29237/head:pull/29237 PR: https://git.openjdk.org/jdk/pull/29237 From prr at openjdk.org Thu Jan 15 18:20:46 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 15 Jan 2026 18:20:46 GMT Subject: RFR: 8375350: Remove usage of AppContext from javax.imageio implementation [v2] In-Reply-To: References: Message-ID: > Remove usage of AppContext from Image IO Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8375350 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29236/files - new: https://git.openjdk.org/jdk/pull/29236/files/d8814466..37d255b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29236&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29236&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29236.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29236/head:pull/29236 PR: https://git.openjdk.org/jdk/pull/29236 From prr at openjdk.org Thu Jan 15 19:57:45 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 15 Jan 2026 19:57:45 GMT Subject: RFR: 8373626: [asan] read past end of buffer in sun.awt.image.ImagingLib.convolveBI In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 19:50:47 GMT, Phil Race wrote: > Some of the medialib native functions implementing Convolve read data from arrays when it is not needed or used instead of reading just what is needed and used. > This is detected as a read out of bounds. It is limited and hasn't been seen to result in any crashes without ASAN, and the OOB values that are read are never used so there's a very limited problem. > The changes here make the mlib_ImageConv_*nw.c files match what happens in the mlib_ImageConv_*ext.c files which read just the data they need. > The changes are fairly mechanical but there could be copy/paste errors for a reviewer to find. > > Not easy to provide a test case, building with --enable-asan is needed and for me it works only on macOS. > I did that and ran all our existing automated tests on our CI systems. src/java.desktop/share/native/libmlib_image/mlib_c_ImageConvVersion.c line 54: > 52: mlib_type type) > 53: { > 54: mlib_d64 dscale = 1.0 / (((mlib_s64)1) << scale); /* 16 < scale <= 31 */ This isn't the same as the rest of the changes but when looking at code paths I saw this fn called with a scale of 31. But (1 << 31) is negative. I don't think that was intended here ! So by making this a 64 bit int we avoid that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29257#discussion_r2695745435 From prr at openjdk.org Thu Jan 15 19:57:43 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 15 Jan 2026 19:57:43 GMT Subject: RFR: 8373626: [asan] read past end of buffer in sun.awt.image.ImagingLib.convolveBI Message-ID: Some of the medialib native functions implementing Convolve read data from arrays when it is not needed or used instead of reading just what is needed and used. This is detected as a read out of bounds. It is limited and hasn't been seen to result in any crashes without ASAN, and the OOB values that are read are never used so there's a very limited problem. The changes here make the mlib_ImageConv_*nw.c files match what happens in the mlib_ImageConv_*ext.c files which read just the data they need. The changes are fairly mechanical but there could be copy/paste errors for a reviewer to find. Not easy to provide a test case, building with --enable-asan is needed and for me it works only on macOS. I did that and ran all our existing automated tests on our CI systems. ------------- Commit messages: - 8373626 Changes: https://git.openjdk.org/jdk/pull/29257/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29257&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373626 Stats: 435 lines in 7 files changed: 357 ins; 54 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/29257.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29257/head:pull/29257 PR: https://git.openjdk.org/jdk/pull/29257 From kizune at openjdk.org Thu Jan 15 21:26:04 2026 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 15 Jan 2026 21:26:04 GMT Subject: RFR: 8375350: Remove usage of AppContext from javax.imageio implementation [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 18:20:46 GMT, Phil Race wrote: >> Remove usage of AppContext from Image IO > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8375350 Marked as reviewed by kizune (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29236#pullrequestreview-3667636746 From dnguyen at openjdk.org Thu Jan 15 22:00:34 2026 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 15 Jan 2026 22:00:34 GMT Subject: RFR: 8375350: Remove usage of AppContext from javax.imageio implementation [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 18:20:46 GMT, Phil Race wrote: >> Remove usage of AppContext from Image IO > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8375350 Marked as reviewed by dnguyen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29236#pullrequestreview-3667772547 From prr at openjdk.org Fri Jan 16 00:51:14 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 16 Jan 2026 00:51:14 GMT Subject: Integrated: 8375350: Remove usage of AppContext from javax.imageio implementation In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 21:41:21 GMT, Phil Race wrote: > Remove usage of AppContext from Image IO This pull request has now been integrated. Changeset: fddba3b7 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/fddba3b7ecb11136e9699861b5d86aeb3d481be6 Stats: 15 lines in 1 file changed: 2 ins; 10 del; 3 mod 8375350: Remove usage of AppContext from javax.imageio implementation Reviewed-by: kizune, dnguyen ------------- PR: https://git.openjdk.org/jdk/pull/29236 From prr at openjdk.org Fri Jan 16 01:14:54 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 16 Jan 2026 01:14:54 GMT Subject: RFR: 8375350: Remove usage of AppContext from javax.imageio implementation Message-ID: This PR removes usage of AppContext from classes under javax/swing/text. Most of the uses were added in specific bug fixes 10-15 years ago but are now obsolete and the tests for those bugs need to be deleted too. ------------- Commit messages: - 8375350 Changes: https://git.openjdk.org/jdk/pull/29259/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29259&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375350 Stats: 387 lines in 9 files changed: 8 ins; 351 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/29259.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29259/head:pull/29259 PR: https://git.openjdk.org/jdk/pull/29259 From syan at openjdk.org Fri Jan 16 03:15:19 2026 From: syan at openjdk.org (SendaoYan) Date: Fri, 16 Jan 2026 03:15:19 GMT Subject: RFR: 8375370: XRBackendNative.c reported variable uninitialized by clang23 [v2] In-Reply-To: References: Message-ID: > Hi all, > > The local variable `pict_attr` in function `JNIEXPORT jint JNICALL Java_sun_java2d_xr_XRBackendNative_createPictureNative (JNIEnv *env, jclass cls, jint drawable, jlong formatPtr)` reported variable uninitialized by clang23. This PR initial all the fields of`pict_attr` to zero which will avoid compiler warning by clang23. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Initial all the fields of pict_attr to zero ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29248/files - new: https://git.openjdk.org/jdk/pull/29248/files/1380681c..f6949885 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29248&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29248&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29248.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29248/head:pull/29248 PR: https://git.openjdk.org/jdk/pull/29248 From syan at openjdk.org Fri Jan 16 03:15:21 2026 From: syan at openjdk.org (SendaoYan) Date: Fri, 16 Jan 2026 03:15:21 GMT Subject: RFR: 8375370: XRBackendNative.c reported variable uninitialized by clang23 [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 18:08:07 GMT, Phil Race wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Initial all the fields of pict_attr to zero > > src/java.desktop/unix/native/libawt_xawt/java2d/x11/XRBackendNative.c line 342: > >> 340: Java_sun_java2d_xr_XRBackendNative_createPictureNative >> 341: (JNIEnv *env, jclass cls, jint drawable, jlong formatPtr) { >> 342: XRenderPictureAttributes pict_attr; > > This looks like an on-stack struct. It should be entirely initialized, not just one field, else it could be all sorts of random garbage. > Zeroing it out would be a good start. Thanks. The struct variable `pict_attr` has been initialed to {0}. this will initial all the fields to zero. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29248#discussion_r2696698192 From psadhukhan at openjdk.org Fri Jan 16 04:03:58 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 16 Jan 2026 04:03:58 GMT Subject: RFR: 8373650: Test "javax/swing/JMenuItem/6458123/ManualBug6458123.java" fails because the check icons are not aligned properly as expected [v4] In-Reply-To: References: Message-ID: > Check/radiobutton icon are not aligned properly in RTL. `WindowsMenuItemUI `uses `MenuItemLayoutHelper.layoutMenuItem` to do the layout which calls `doRTLColumnLayout `which calculates x positions in `calcXPositionsRTL `and then again aligns in `alignRects`. However, since in Windows historically radiobutton/check icon was not drawn or drawn below the menuitem image icon (since image icon and check icon was drawn in the same layout space and not separately) the aligned x position of check icons returned from `MenuItemLayoutHelper` was not correct but since `MenuItemLayoutHelper` alignment is used in other L&Fs also so we need to realign it in windows specific class i.e in WindowsIconFactory in paintIcon > > Before fix > > image > > After fix > > image Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: copyright year updated ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28889/files - new: https://git.openjdk.org/jdk/pull/28889/files/c4bda416..7a0683a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28889&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28889&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28889.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28889/head:pull/28889 PR: https://git.openjdk.org/jdk/pull/28889 From psadhukhan at openjdk.org Fri Jan 16 04:03:59 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 16 Jan 2026 04:03:59 GMT Subject: RFR: 8373650: Test "javax/swing/JMenuItem/6458123/ManualBug6458123.java" fails because the check icons are not aligned properly as expected [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 12:29:59 GMT, Alexey Ivanov wrote: > Is it because Windows icons used to be special and combined the icon and check mark / bullet mark, or rather replaced the check mark / bullet mark with the icon? Should we get rid of that special treatment? I am reusing the VistaMenuItemCheckIcon to render the RadioButtonMenuItem and CheckBoxMenuItem icons and getting rid of the working/treatment made in that class (and rewriting) might result in more regressions which I am avoiding.. There are many factors apart from normal that is affecting the icon position like `menuItem.setHorizontalTextPosition(LEADING/TRAILING/LEFT/RIGHT etc)`, `menuItem.setHorizontalTextPosition(RIGHT/CENTER etc)` which can cause issues like what we are seeing in https://github.com/openjdk/jdk/pull/28210 which atleast is working now for Windows L&F without any rework. Metal L&F seems to hardcode the icon position to (0,0) or (2,2) https://github.com/openjdk/jdk/blob/e4474ad8ae250771e031b8c18809d3e461970365/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalIconFactory.java#L2268-L2302 whereas I am reusing the methodology in VistaMenuItemIcon using OFFSET and it seems to work for cases seen till now.. >> it is taken care via ternary operator, width/spread of check mark is usually more than radio bullet so starting point of checkmark is considered a little ahead compared to radio bullet > > I see that it's taken care by the ternary operator. Why is it needed, though? > > The skin for both check mark and radio bullet have the same size, and the mark is positioned accordingly inside the rectangle. This works well for the LTR layout, both marks are rendered at the same location and appear aligned in the end. Why does RTL layout treat these marks differently? As told and code shown earlier, the RTL oversees overall rectangle width using all text rect, image icon rect, icon rect etc to calculate icon x position unlike LTR and it seemed a bit off for checkmark as compared to bullet by 1 or 2 pixel or so I catered to it by this logic ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28889#discussion_r2696785303 PR Review Comment: https://git.openjdk.org/jdk/pull/28889#discussion_r2696788855 From prr at openjdk.org Fri Jan 16 05:27:56 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 16 Jan 2026 05:27:56 GMT Subject: RFR: 8375351: Remove usage of AppContext from print implementation [v3] In-Reply-To: References: Message-ID: > Remove AppContext from javax.print Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8375351 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29237/files - new: https://git.openjdk.org/jdk/pull/29237/files/bb456985..559e8b53 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29237&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29237&range=01-02 Stats: 14 lines in 1 file changed: 2 ins; 8 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29237/head:pull/29237 PR: https://git.openjdk.org/jdk/pull/29237 From asemenov at openjdk.org Fri Jan 16 10:20:34 2026 From: asemenov at openjdk.org (Artem Semenov) Date: Fri, 16 Jan 2026 10:20:34 GMT Subject: RFR: 8286258: [Accessibility, macOS, VoiceOver] VoiceOver reads the spinner value wrong and sometime partially In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 20:18:08 GMT, Alexander Zuev wrote: > The issue with the announcement of the custom spin boxes is that the text field inside when the value is being changed by the spinbox data model generates some events that are being interpreted by the accessibility subsystem as if text is being actively edited and the system tries to announce it accordingly. In order to stop it from happening we are going to generate correct events and temporarily suppress the text field's methods that reporting the editing-related changes until the actual editing is happened. > > Make embedded text field not to generate random edit-related events; > Add manual test case; src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SpinboxAccessibility.m line 1: > 1: /* I'm a bit confused that you iterate through all the children in `accessibilityValue` and select the value of the last one. And in `postValueChanged`, you post a whole stack of notifications for all the children. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29235#discussion_r2697878728 From prr at openjdk.org Fri Jan 16 17:52:42 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 16 Jan 2026 17:52:42 GMT Subject: RFR: 8375370: XRBackendNative.c reported variable uninitialized by clang23 [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 03:15:19 GMT, SendaoYan wrote: >> Hi all, >> >> The local variable `pict_attr` in function `JNIEXPORT jint JNICALL Java_sun_java2d_xr_XRBackendNative_createPictureNative (JNIEnv *env, jclass cls, jint drawable, jlong formatPtr)` reported variable uninitialized by clang23. This PR initial all the fields of`pict_attr` to zero which will avoid compiler warning by clang23. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Initial all the fields of pict_attr to zero Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29248#pullrequestreview-3672030718 From prr at openjdk.org Fri Jan 16 23:04:32 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 16 Jan 2026 23:04:32 GMT Subject: RFR: 8375567: Remove AppContext usage from Swing Motif L&F classes Message-ID: Remove AppContext from the Swing Motif L&F implementation. ------------- Commit messages: - 8375567 Changes: https://git.openjdk.org/jdk/pull/29282/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29282&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375567 Stats: 45 lines in 5 files changed: 0 ins; 36 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/29282.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29282/head:pull/29282 PR: https://git.openjdk.org/jdk/pull/29282 From syan at openjdk.org Sat Jan 17 04:33:35 2026 From: syan at openjdk.org (SendaoYan) Date: Sat, 17 Jan 2026 04:33:35 GMT Subject: RFR: 8375370: XRBackendNative.c reported variable uninitialized by clang23 [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 17:49:10 GMT, Phil Race wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Initial all the fields of pict_attr to zero > > Marked as reviewed by prr (Reviewer). Thanks for the suggestion and review @prrace ------------- PR Comment: https://git.openjdk.org/jdk/pull/29248#issuecomment-3762637705 From syan at openjdk.org Sat Jan 17 04:33:35 2026 From: syan at openjdk.org (SendaoYan) Date: Sat, 17 Jan 2026 04:33:35 GMT Subject: Integrated: 8375370: XRBackendNative.c reported variable uninitialized by clang23 In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 07:36:05 GMT, SendaoYan wrote: > Hi all, > > The local variable `pict_attr` in function `JNIEXPORT jint JNICALL Java_sun_java2d_xr_XRBackendNative_createPictureNative (JNIEnv *env, jclass cls, jint drawable, jlong formatPtr)` reported variable uninitialized by clang23. This PR initial all the fields of`pict_attr` to zero which will avoid compiler warning by clang23. This pull request has now been integrated. Changeset: 0dd5b591 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/0dd5b59194f32f54c2ec6572833f45e1402515ba Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8375370: XRBackendNative.c reported variable uninitialized by clang23 Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/29248 From prr at openjdk.org Sat Jan 17 17:49:44 2026 From: prr at openjdk.org (Phil Race) Date: Sat, 17 Jan 2026 17:49:44 GMT Subject: RFR: 8375351: Remove usage of AppContext from print implementation [v4] In-Reply-To: References: Message-ID: > Remove AppContext from javax.print Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8375351 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29237/files - new: https://git.openjdk.org/jdk/pull/29237/files/559e8b53..d8897fca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29237&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29237&range=02-03 Stats: 11 lines in 1 file changed: 0 ins; 11 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29237/head:pull/29237 PR: https://git.openjdk.org/jdk/pull/29237 From serb at openjdk.org Mon Jan 19 00:07:58 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 19 Jan 2026 00:07:58 GMT Subject: RFR: 8375567: Remove AppContext usage from Swing Motif L&F classes In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 22:57:55 GMT, Phil Race wrote: > Remove AppContext from the Swing Motif L&F implementation. src/java.desktop/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java line 153: > 151: * Returns the ideal font style for the font identified by key. > 152: */ > 153: public static int getDefaultFontStyle(int key) { This broke the build. It is part of public api now, is it intentional change? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29282#discussion_r2702884736 From psadhukhan at openjdk.org Mon Jan 19 02:25:47 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 19 Jan 2026 02:25:47 GMT Subject: RFR: 6441373: Editing JTable is not Serializable [v8] In-Reply-To: References: Message-ID: <2d8QOqzgYIbJifXBHlTuwpDkHzzszaAjG36377ef8fQ=.495ce301-d304-4214-a81a-ec107444bae3@github.com> > Issue is when JTable is in editing mode, it is not Serializable as it gives exception > > java.io.NotSerializableException: java.lang.reflect.Constructor > at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1149) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1502) > at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1467) > at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1385) > at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1143) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1502) > ....... > > > It is caused by creation of `GenericEditor` class which uses a non-serializable Constructor field. > This is fixed by making the field transient.. > Also, `editorRemover` field is made transient as it is object of `CellEditorRemover` class which is not Serializable.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Review comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28627/files - new: https://git.openjdk.org/jdk/pull/28627/files/d4cf50ff..be309cde Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28627&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28627&range=06-07 Stats: 8 lines in 2 files changed: 2 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/28627.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28627/head:pull/28627 PR: https://git.openjdk.org/jdk/pull/28627 From tr at openjdk.org Mon Jan 19 03:22:06 2026 From: tr at openjdk.org (Tejesh R) Date: Mon, 19 Jan 2026 03:22:06 GMT Subject: RFR: 6441373: Editing JTable is not Serializable [v8] In-Reply-To: <2d8QOqzgYIbJifXBHlTuwpDkHzzszaAjG36377ef8fQ=.495ce301-d304-4214-a81a-ec107444bae3@github.com> References: <2d8QOqzgYIbJifXBHlTuwpDkHzzszaAjG36377ef8fQ=.495ce301-d304-4214-a81a-ec107444bae3@github.com> Message-ID: On Mon, 19 Jan 2026 02:25:47 GMT, Prasanta Sadhukhan wrote: >> Issue is when JTable is in editing mode, it is not Serializable as it gives exception >> >> java.io.NotSerializableException: java.lang.reflect.Constructor >> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1149) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1502) >> at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1467) >> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1385) >> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1143) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1502) >> ....... >> >> >> It is caused by creation of `GenericEditor` class which uses a non-serializable Constructor field. >> This is fixed by making the field transient.. >> Also, `editorRemover` field is made transient as it is object of `CellEditorRemover` class which is not Serializable.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Review comment Marked as reviewed by tr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28627#pullrequestreview-3676115385 From jdv at openjdk.org Mon Jan 19 03:49:00 2026 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 19 Jan 2026 03:49:00 GMT Subject: RFR: 8375063: Update Libpng to 1.6.54 Message-ID: Upgrade libpng used for Splashscreen from 1.6.51 to 1.6.54 version. Testing is green with this update. ------------- Commit messages: - 8375063: Update Libpng to 1.6.54 Changes: https://git.openjdk.org/jdk/pull/29292/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29292&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375063 Stats: 1406 lines in 16 files changed: 443 ins; 7 del; 956 mod Patch: https://git.openjdk.org/jdk/pull/29292.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29292/head:pull/29292 PR: https://git.openjdk.org/jdk/pull/29292 From psadhukhan at openjdk.org Mon Jan 19 05:17:55 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 19 Jan 2026 05:17:55 GMT Subject: RFR: 8375573: JTable ignores setPreferredWidth during initial layout when AUTO_RESIZE_LAST_COLUMN is enabled Message-ID: AUTO_RESIZE_LAST_COLUMN handling was done in [JDK-8234071](https://bugs.openjdk.org/browse/JDK-8234071) but it didn't honour the preferred width if it is already been set for each column so when layouting is done, it only sees the `resizingColumn` is set to AUTO_RESIZE_LAST_COLUMN and adjust only the last column and distribute width equally to all other column. Fix is made to honour the user-set preferred column width even if auto-resize mode is set to LAST_COLUMN ------------- Commit messages: - jcheck - 8375573: JTable ignores setPreferredWidth during initial layout when AUTO_RESIZE_LAST_COLUMN is enabled - 8375573: JTable ignores setPreferredWidth during initial layout when AUTO_RESIZE_LAST_COLUMN is enabled Changes: https://git.openjdk.org/jdk/pull/29291/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29291&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375573 Stats: 102 lines in 2 files changed: 100 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29291.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29291/head:pull/29291 PR: https://git.openjdk.org/jdk/pull/29291 From tr at openjdk.org Mon Jan 19 05:55:44 2026 From: tr at openjdk.org (Tejesh R) Date: Mon, 19 Jan 2026 05:55:44 GMT Subject: RFR: 8375351: Remove usage of AppContext from print implementation [v4] In-Reply-To: References: Message-ID: <7h_-cFp4d10_5fq_IA0cWTdoej4DNe9OMI84JmpBqE0=.19381b20-e928-48b8-a9c0-f4aff96c10fe@github.com> On Sat, 17 Jan 2026 17:49:44 GMT, Phil Race wrote: >> Remove AppContext from javax.print > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8375351 LGTM ------------- Marked as reviewed by tr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29237#pullrequestreview-3676360953 From psadhukhan at openjdk.org Mon Jan 19 06:38:30 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 19 Jan 2026 06:38:30 GMT Subject: RFR: 8375011: OldJTable.java - NullPointerException when columnData is null [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 10:40:57 GMT, ANUPAM DEV wrote: >> Hi, >> >> This is a fix for NPE in OldJTable.addColumn >> >> The addColumn method in OldJTable.java was unconditionally calling columnData.toArray(), which caused a NullPointerException when columnData was null (e.g., when called from addColumn(Object, int)). >> >> This commit adds a null check to safe-guard against this NPE, passing null to the underlying DefaultTableModel when columnData is missing. >> >> Kindly review. >> >> Regards, >> Anupam > > ANUPAM DEV has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Modified code for null check Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29226#pullrequestreview-3676476988 From psadhukhan at openjdk.org Mon Jan 19 06:47:36 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 19 Jan 2026 06:47:36 GMT Subject: RFR: 8375351: Remove usage of AppContext from print implementation [v4] In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 17:49:44 GMT, Phil Race wrote: >> Remove AppContext from javax.print > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8375351 src/java.desktop/share/classes/javax/print/PrintServiceLookup.java line 82: > 80: */ > 81: private static Services getServices() { > 82: return SERVICES; Dont we need to implement singleton instance like this? private static volatile Services SERVICES = null; private static Services getServices() { if (SERVICES== null) { // Synchronized block for thread safety during first creation synchronized (Services.class) { if (SERVICES == null) { SERVICES = new Services(); } } } return SERVICES; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29237#discussion_r2703419127 From duke at openjdk.org Mon Jan 19 07:02:12 2026 From: duke at openjdk.org (ANUPAM DEV) Date: Mon, 19 Jan 2026 07:02:12 GMT Subject: RFR: 8375011: OldJTable.java - NullPointerException when columnData is null [v3] In-Reply-To: References: Message-ID: > Hi, > > This is a fix for NPE in OldJTable.addColumn > > The addColumn method in OldJTable.java was unconditionally calling columnData.toArray(), which caused a NullPointerException when columnData was null (e.g., when called from addColumn(Object, int)). > > This commit adds a null check to safe-guard against this NPE, passing null to the underlying DefaultTableModel when columnData is missing. > > Kindly review. > > Regards, > Anupam ANUPAM DEV has updated the pull request incrementally with one additional commit since the last revision: Update full name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29226/files - new: https://git.openjdk.org/jdk/pull/29226/files/b62c23b1..0605ac5b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29226&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29226&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29226/head:pull/29226 PR: https://git.openjdk.org/jdk/pull/29226 From psadhukhan at openjdk.org Mon Jan 19 07:11:34 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 19 Jan 2026 07:11:34 GMT Subject: RFR: 8375480: Remove usage of AppContext from javax/swing/text In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 01:08:27 GMT, Phil Race wrote: > This PR removes usage of AppContext from classes under javax/swing/text. > Most of the uses were added in specific bug fixes 10-15 years ago but are now obsolete and the tests for those bugs need to be deleted too. src/java.desktop/share/classes/javax/swing/text/LayoutQueue.java line 58: > 56: public static LayoutQueue getDefaultQueue() { > 57: if (defaultQueue == null) { > 58: defaultQueue = new LayoutQueue(); synchronized not needed? src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 434: > 432: */ > 433: public void setStyleSheet(StyleSheet s) { > 434: defaultStyles = s; Dont we need to add `synchronized` for setter and getter? getAppContext used to use getAppContextLock!! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29259#discussion_r2703481945 PR Review Comment: https://git.openjdk.org/jdk/pull/29259#discussion_r2703478833 From tr at openjdk.org Mon Jan 19 08:45:25 2026 From: tr at openjdk.org (Tejesh R) Date: Mon, 19 Jan 2026 08:45:25 GMT Subject: RFR: 8375351: Remove usage of AppContext from print implementation [v4] In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 17:49:44 GMT, Phil Race wrote: >> Remove AppContext from javax.print > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8375351 src/java.desktop/share/classes/javax/print/PrintServiceLookup.java line 81: > 79: * @return the services > 80: */ > 81: private static Services getServices() { I guess making `Services` constructor as private is missing here ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29237#discussion_r2703775313 From tr at openjdk.org Mon Jan 19 08:45:26 2026 From: tr at openjdk.org (Tejesh R) Date: Mon, 19 Jan 2026 08:45:26 GMT Subject: RFR: 8375351: Remove usage of AppContext from print implementation [v4] In-Reply-To: References: Message-ID: <2-b4C7__ksV-bjVFNaXytnpj8j68LSM8Pp9-jOJ-JvY=.5ac1e384-ae39-4ddb-b977-d375b9e98dec@github.com> On Mon, 19 Jan 2026 08:41:44 GMT, Tejesh R wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8375351 > > src/java.desktop/share/classes/javax/print/PrintServiceLookup.java line 81: > >> 79: * @return the services >> 80: */ >> 81: private static Services getServices() { > > I guess making `Services` constructor as private is missing here ? > I guess making `Services` constructor as private is missing here ? As of now it's default in this case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29237#discussion_r2703777665 From tr at openjdk.org Mon Jan 19 08:59:00 2026 From: tr at openjdk.org (Tejesh R) Date: Mon, 19 Jan 2026 08:59:00 GMT Subject: RFR: 8373650: Test "javax/swing/JMenuItem/6458123/ManualBug6458123.java" fails because the check icons are not aligned properly as expected [v4] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 04:03:58 GMT, Prasanta Sadhukhan wrote: >> Check/radiobutton icon are not aligned properly in RTL. `WindowsMenuItemUI `uses `MenuItemLayoutHelper.layoutMenuItem` to do the layout which calls `doRTLColumnLayout `which calculates x positions in `calcXPositionsRTL `and then again aligns in `alignRects`. However, since in Windows historically radiobutton/check icon was not drawn or drawn below the menuitem image icon (since image icon and check icon was drawn in the same layout space and not separately) the aligned x position of check icons returned from `MenuItemLayoutHelper` was not correct but since `MenuItemLayoutHelper` alignment is used in other L&Fs also so we need to realign it in windows specific class i.e in WindowsIconFactory in paintIcon >> >> Before fix >> >> image >> >> After fix >> >> image > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > copyright year updated Should we update the bugid in test too ? src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 938: > 936: (icon.getIconHeight() <= 16) ? y + OFFSET : (y + icon.getIconHeight() / 2), state); > 937: } else { > 938: skin.paintSkin(g, Can we optimize the code here, since mostly `x` is changing here based on conditions. It'll help in readability and review too. ------------- PR Review: https://git.openjdk.org/jdk/pull/28889#pullrequestreview-3676963759 PR Review Comment: https://git.openjdk.org/jdk/pull/28889#discussion_r2703811112 From psadhukhan at openjdk.org Mon Jan 19 08:59:01 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 19 Jan 2026 08:59:01 GMT Subject: RFR: 8373650: Test "javax/swing/JMenuItem/6458123/ManualBug6458123.java" fails because the check icons are not aligned properly as expected [v4] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 08:52:33 GMT, Tejesh R wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> copyright year updated > > src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 938: > >> 936: (icon.getIconHeight() <= 16) ? y + OFFSET : (y + icon.getIconHeight() / 2), state); >> 937: } else { >> 938: skin.paintSkin(g, > > Can we optimize the code here, since mostly `x` is changing here based on conditions. It'll help in readability and review too. No, y is also changing depending on icon height... As of now, any more optimization is not possible, it can be done as followup if it is needed.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28889#discussion_r2703826079 From duke at openjdk.org Mon Jan 19 09:03:31 2026 From: duke at openjdk.org (Christian Heilmann) Date: Mon, 19 Jan 2026 09:03:31 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v7] In-Reply-To: References: Message-ID: > This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS. > > The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m. Christian Heilmann 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' of https://github.com/christianheilmann/jdk into pr/11266 # Conflicts: # src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m - Changed copyright year to 2026 - Merge branch 'pr/8297191' of https://github.com/christianheilmann/jdk into pr/11266 - Merge branch 'openjdk:master' into pr/8297191 - added 8297191 to @bug - Update PrinterView.m - Update PrinterView.h - Update CPrinterJob.m - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS - ... and 3 more: https://git.openjdk.org/jdk/compare/1d4bb75b...4de8582f ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11266/files - new: https://git.openjdk.org/jdk/pull/11266/files/64fbbd84..4de8582f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11266&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11266&range=05-06 Stats: 137693 lines in 4317 files changed: 78048 ins; 31140 del; 28505 mod Patch: https://git.openjdk.org/jdk/pull/11266.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/11266/head:pull/11266 PR: https://git.openjdk.org/jdk/pull/11266 From tr at openjdk.org Mon Jan 19 11:07:58 2026 From: tr at openjdk.org (Tejesh R) Date: Mon, 19 Jan 2026 11:07:58 GMT Subject: RFR: 8373650: Test "javax/swing/JMenuItem/6458123/ManualBug6458123.java" fails because the check icons are not aligned properly as expected [v4] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 08:56:32 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 938: >> >>> 936: (icon.getIconHeight() <= 16) ? y + OFFSET : (y + icon.getIconHeight() / 2), state); >>> 937: } else { >>> 938: skin.paintSkin(g, >> >> Can we optimize the code here, since mostly `x` is changing here based on conditions. It'll help in readability and review too. > > No, y is also changing depending on icon height... > As of now, any more optimization is not possible, it can be done as followup if it is needed.. Line 926, 930, 936 and 940 looks same to me. I'm referring to these lines. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28889#discussion_r2704292249 From aivanov at openjdk.org Mon Jan 19 13:28:30 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 19 Jan 2026 13:28:30 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v7] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 09:03:31 GMT, Christian Heilmann wrote: >> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS. >> >> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m. > > Christian Heilmann 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' of https://github.com/christianheilmann/jdk into pr/11266 > > # Conflicts: > # src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m > - Changed copyright year to 2026 > - Merge branch 'pr/8297191' of https://github.com/christianheilmann/jdk into pr/11266 > - Merge branch 'openjdk:master' into pr/8297191 > - added 8297191 to @bug > - Update PrinterView.m > - Update PrinterView.h > - Update CPrinterJob.m > - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS > - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS > - ... and 3 more: https://git.openjdk.org/jdk/compare/c0fb6bc9...4de8582f Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/11266#pullrequestreview-3678090034 From aturbanov at openjdk.org Mon Jan 19 15:14:20 2026 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 19 Jan 2026 15:14:20 GMT Subject: RFR: 8375221: Update code to get PrinterResolution from CUPS/IPP print service [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 17:29:59 GMT, Phil Race wrote: >> Previous to this fix, no resolution was being found via CUPS/IPP and when the test case for printer resolution was falling back to the made up 300dpi setting. With this fix it finds the 600dpi from CUPS/IPP. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8375221 src/java.desktop/unix/classes/sun/print/IPPPrintService.java line 1711: > 1709: for (int i = 0; i < numRes; i++) { > 1710: int units = (rawResolutions[i*3+2] == 4) ? PrinterResolution.DPCM : PrinterResolution.DPI; > 1711: pres[i] = new PrinterResolution(rawResolutions[i*3], Suggestion: pres[i] = new PrinterResolution(rawResolutions[i*3], ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29208#discussion_r2705154554 From prr at openjdk.org Mon Jan 19 19:08:38 2026 From: prr at openjdk.org (Phil Race) Date: Mon, 19 Jan 2026 19:08:38 GMT Subject: RFR: 8375567: Remove AppContext usage from Swing Motif L&F classes [v2] In-Reply-To: References: Message-ID: > Remove AppContext from the Swing Motif L&F implementation. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8375567 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29282/files - new: https://git.openjdk.org/jdk/pull/29282/files/d26d9655..4cfc2c54 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29282&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29282&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29282.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29282/head:pull/29282 PR: https://git.openjdk.org/jdk/pull/29282 From prr at openjdk.org Mon Jan 19 19:08:39 2026 From: prr at openjdk.org (Phil Race) Date: Mon, 19 Jan 2026 19:08:39 GMT Subject: RFR: 8375567: Remove AppContext usage from Swing Motif L&F classes [v2] In-Reply-To: References: Message-ID: <0GufaOH9FmU5Ce8t1_S7SC8xa3P3hcYfIy3ozqskEiU=.ab2fccc7-2409-447d-93d3-01db7596a80c@github.com> On Mon, 19 Jan 2026 00:03:42 GMT, Sergey Bylokhov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8375567 > > src/java.desktop/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java line 153: > >> 151: * Returns the ideal font style for the font identified by key. >> 152: */ >> 153: public static int getDefaultFontStyle(int key) { > > This broke the build. It is part of public api now, is it intentional change? whoops, that was NOT supposed to be part of this PR. I'll revert this file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29282#discussion_r2705829341 From aivanov at openjdk.org Mon Jan 19 20:13:05 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 19 Jan 2026 20:13:05 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v5] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 15:02:30 GMT, Christian Heilmann wrote: >> Christian Heilmann has updated the pull request incrementally with two additional commits since the last revision: >> >> - Merge branch 'pr/8297191' of https://github.com/christianheilmann/jdk into pr/11266 >> - added 8297191 to @bug > > I run on macOS Tahoe 26.1 on an MacBook Air M3 all tests containing PageRanges: > > > make test TEST="jtreg:test/jdk/java/awt/print/Dialog/DestinationTest.java jtreg:test/jdk/java/awt/print/PrinterJob/DlgAttrsBug.java jtreg:test/jdk/java/awt/print/PrinterJob/PageRanges.java jtreg:test/jdk/java/awt/print/PrinterJob/PageRangesDlgTest.java jtreg:test/jdk/javax/print/attribute/PageRangesException.java jtreg:test/jdk/java/awt/print/PrinterJob/PrintAttributeUpdateTest.java jtreg:test/jdk/java/awt/print/PrinterJob/PrintDlgPageable.java jtreg:test/jdk/java/awt/PrintJob/SaveDialogTitleTest.java jtreg:test/jdk/javax/print/attribute/ServiceDlgPageRangeTest.java jtreg:test/jdk/javax/print/attribute/SidesPageRangesTest.java" JTREG="MANUAL=true" > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR SKIP > jtreg:test/jdk/java/awt/print/Dialog/DestinationTest.java > 1 1 0 0 0 > jtreg:test/jdk/java/awt/print/PrinterJob/DlgAttrsBug.java > 1 1 0 0 0 > jtreg:test/jdk/java/awt/print/PrinterJob/PageRanges.java > 1 1 0 0 0 > jtreg:test/jdk/java/awt/print/PrinterJob/PageRangesDlgTest.java > 1 1 0 0 0 > jtreg:test/jdk/java/awt/print/PrinterJob/PrintAttributeUpdateTest.java > 1 1 0 0 0 > jtreg:test/jdk/java/awt/print/PrinterJob/PrintDlgPageable.java > 1 1 0 0 0 > jtreg:test/jdk/java/awt/PrintJob/SaveDialogTitleTest.java >>> 1 0 0 1 0 << > jtreg:test/jdk/javax/print/attribute/ServiceDlgPageRangeTest.java > 1 1 0 0 0 > ============================== > TEST FAILURE > > > make test TEST="jtreg:test/jdk/java/awt/print/PrinterJob/PageRanges.java jtreg:test/jdk/javax/print/attribute/SidesPageRangesTest.java" > > ============================== > TEST FAILURE > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR SKIP > j... @christianheilmann You can issue the `/integrate` command now. Your recent change that merged master didn't bring in any new changes... Phil's review remains valid. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3769962216 From duke at openjdk.org Mon Jan 19 20:47:16 2026 From: duke at openjdk.org (altrisi) Date: Mon, 19 Jan 2026 20:47:16 GMT Subject: RFR: 8375351: Remove usage of AppContext from print implementation [v4] In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 17:49:44 GMT, Phil Race wrote: >> Remove AppContext from javax.print > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8375351 Considering both Services classes are just field holders, I think it'd make sense to make them static fields of the outer classes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29237#issuecomment-3770067997 From kizune at openjdk.org Tue Jan 20 01:25:00 2026 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 20 Jan 2026 01:25:00 GMT Subject: RFR: 8286258: [Accessibility, macOS, VoiceOver] VoiceOver reads the spinner value wrong and sometime partially In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 10:16:43 GMT, Artem Semenov wrote: >> The issue with the announcement of the custom spin boxes is that the text field inside when the value is being changed by the spinbox data model generates some events that are being interpreted by the accessibility subsystem as if text is being actively edited and the system tries to announce it accordingly. In order to stop it from happening we are going to generate correct events and temporarily suppress the text field's methods that reporting the editing-related changes until the actual editing is happened. >> >> Make embedded text field not to generate random edit-related events; >> Add manual test case; > > src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SpinboxAccessibility.m line 1: > >> 1: /* > > I'm a bit confused that you iterate through all the children in `accessibilityValue` and select the value of the last one. > And in `postValueChanged`, you post a whole stack of notifications for all the children. I am only getting value from a child that conforms to the specific protocol - basically i get the last child that is a text editor and retrieve a value from it. If no text elements are in the child list then i am using the value from the spinner itself. Same with the sending extra notifications - i am only send them to the text elements and the notification is to assume that the entire internal structure of text element was updated - not just an incremental edit happened - and to ask VoiceOver to do announcement if it is not scheduled yet. There is a test attached - just try this test case with and without the changes and you will hear the difference. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29235#discussion_r2706442875 From psadhukhan at openjdk.org Tue Jan 20 02:53:18 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 20 Jan 2026 02:53:18 GMT Subject: RFR: 8373650: Test "javax/swing/JMenuItem/6458123/ManualBug6458123.java" fails because the check icons are not aligned properly as expected [v5] In-Reply-To: References: Message-ID: > Check/radiobutton icon are not aligned properly in RTL. `WindowsMenuItemUI `uses `MenuItemLayoutHelper.layoutMenuItem` to do the layout which calls `doRTLColumnLayout `which calculates x positions in `calcXPositionsRTL `and then again aligns in `alignRects`. However, since in Windows historically radiobutton/check icon was not drawn or drawn below the menuitem image icon (since image icon and check icon was drawn in the same layout space and not separately) the aligned x position of check icons returned from `MenuItemLayoutHelper` was not correct but since `MenuItemLayoutHelper` alignment is used in other L&Fs also so we need to realign it in windows specific class i.e in WindowsIconFactory in paintIcon > > Before fix > > image > > After fix > > image Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Review comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28889/files - new: https://git.openjdk.org/jdk/pull/28889/files/7a0683a4..d0d8fdca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28889&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28889&range=03-04 Stats: 20 lines in 1 file changed: 7 ins; 3 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/28889.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28889/head:pull/28889 PR: https://git.openjdk.org/jdk/pull/28889 From psadhukhan at openjdk.org Tue Jan 20 02:53:19 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 20 Jan 2026 02:53:19 GMT Subject: RFR: 8373650: Test "javax/swing/JMenuItem/6458123/ManualBug6458123.java" fails because the check icons are not aligned properly as expected [v4] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 11:04:59 GMT, Tejesh R wrote: >> No, y is also changing depending on icon height... >> As of now, any more optimization is not possible, it can be done as followup if it is needed.. > > Line 926, 930, 936 and 940 looks same to me. I'm referring to these lines. ok.. optimized.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28889#discussion_r2706569724 From tr at openjdk.org Tue Jan 20 04:34:30 2026 From: tr at openjdk.org (Tejesh R) Date: Tue, 20 Jan 2026 04:34:30 GMT Subject: RFR: 8373650: Test "javax/swing/JMenuItem/6458123/ManualBug6458123.java" fails because the check icons are not aligned properly as expected [v4] In-Reply-To: References: Message-ID: <7MUUTJwrNtgdaDgcyElMpH60o8zCgp39Lqh_PiW95Gs=.35b97678-df1d-4cb6-af5e-5beafacfe1b9@github.com> On Mon, 19 Jan 2026 08:53:07 GMT, Tejesh R wrote: > Should we update the bugid in test too ? @prsadhuk ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28889#issuecomment-3770992080 From tr at openjdk.org Tue Jan 20 04:43:07 2026 From: tr at openjdk.org (Tejesh R) Date: Tue, 20 Jan 2026 04:43:07 GMT Subject: RFR: 8375011: OldJTable.java - NullPointerException when columnData is null [v3] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 07:02:12 GMT, ANUPAM DEV wrote: >> Hi, >> >> This is a fix for NPE in OldJTable.addColumn >> >> The addColumn method in OldJTable.java was unconditionally calling columnData.toArray(), which caused a NullPointerException when columnData was null (e.g., when called from addColumn(Object, int)). >> >> This commit adds a null check to safe-guard against this NPE, passing null to the underlying DefaultTableModel when columnData is missing. >> >> Kindly review. >> >> Regards, >> Anupam > > ANUPAM DEV has updated the pull request incrementally with one additional commit since the last revision: > > Update full name LGTM ------------- Marked as reviewed by tr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29226#pullrequestreview-3680319776 From psadhukhan at openjdk.org Tue Jan 20 04:46:43 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 20 Jan 2026 04:46:43 GMT Subject: RFR: 8373650: Test "javax/swing/JMenuItem/6458123/ManualBug6458123.java" fails because the check icons are not aligned properly as expected [v4] In-Reply-To: <7MUUTJwrNtgdaDgcyElMpH60o8zCgp39Lqh_PiW95Gs=.35b97678-df1d-4cb6-af5e-5beafacfe1b9@github.com> References: <7MUUTJwrNtgdaDgcyElMpH60o8zCgp39Lqh_PiW95Gs=.35b97678-df1d-4cb6-af5e-5beafacfe1b9@github.com> Message-ID: <_kbIPRoCWst4lVTYTxAl2HIDmxPfteslhjmqMnb6gus=.3dbb616a-4f6a-4bf8-8e2a-17855d8871d7@github.com> On Tue, 20 Jan 2026 04:31:10 GMT, Tejesh R wrote: > > Should we update the bugid in test too ? > > @prsadhuk ? Its in closed...it shouldn't affect this open review.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28889#issuecomment-3771015081 From tr at openjdk.org Tue Jan 20 04:53:50 2026 From: tr at openjdk.org (Tejesh R) Date: Tue, 20 Jan 2026 04:53:50 GMT Subject: RFR: 8373650: Test "javax/swing/JMenuItem/6458123/ManualBug6458123.java" fails because the check icons are not aligned properly as expected [v5] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 02:53:18 GMT, Prasanta Sadhukhan wrote: >> Check/radiobutton icon are not aligned properly in RTL. `WindowsMenuItemUI `uses `MenuItemLayoutHelper.layoutMenuItem` to do the layout which calls `doRTLColumnLayout `which calculates x positions in `calcXPositionsRTL `and then again aligns in `alignRects`. However, since in Windows historically radiobutton/check icon was not drawn or drawn below the menuitem image icon (since image icon and check icon was drawn in the same layout space and not separately) the aligned x position of check icons returned from `MenuItemLayoutHelper` was not correct but since `MenuItemLayoutHelper` alignment is used in other L&Fs also so we need to realign it in windows specific class i.e in WindowsIconFactory in paintIcon >> >> Before fix >> >> image >> >> After fix >> >> image > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Review comment LGTM ------------- Marked as reviewed by tr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28889#pullrequestreview-3680337454 From psadhukhan at openjdk.org Tue Jan 20 07:15:08 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 20 Jan 2026 07:15:08 GMT Subject: Integrated: 8373650: Test "javax/swing/JMenuItem/6458123/ManualBug6458123.java" fails because the check icons are not aligned properly as expected In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 07:34:36 GMT, Prasanta Sadhukhan wrote: > Check/radiobutton icon are not aligned properly in RTL. `WindowsMenuItemUI `uses `MenuItemLayoutHelper.layoutMenuItem` to do the layout which calls `doRTLColumnLayout `which calculates x positions in `calcXPositionsRTL `and then again aligns in `alignRects`. However, since in Windows historically radiobutton/check icon was not drawn or drawn below the menuitem image icon (since image icon and check icon was drawn in the same layout space and not separately) the aligned x position of check icons returned from `MenuItemLayoutHelper` was not correct but since `MenuItemLayoutHelper` alignment is used in other L&Fs also so we need to realign it in windows specific class i.e in WindowsIconFactory in paintIcon > > Before fix > > image > > After fix > > image This pull request has now been integrated. Changeset: e45f5656 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/e45f5656bc90421c9acb0cbf87164162039ddf81 Stats: 40 lines in 1 file changed: 36 ins; 0 del; 4 mod 8373650: Test "javax/swing/JMenuItem/6458123/ManualBug6458123.java" fails because the check icons are not aligned properly as expected Reviewed-by: tr, dnguyen ------------- PR: https://git.openjdk.org/jdk/pull/28889 From duke at openjdk.org Tue Jan 20 09:17:04 2026 From: duke at openjdk.org (duke) Date: Tue, 20 Jan 2026 09:17:04 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v7] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 09:03:31 GMT, Christian Heilmann wrote: >> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS. >> >> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m. > > Christian Heilmann 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' of https://github.com/christianheilmann/jdk into pr/11266 > > # Conflicts: > # src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m > - Changed copyright year to 2026 > - Merge branch 'pr/8297191' of https://github.com/christianheilmann/jdk into pr/11266 > - Merge branch 'openjdk:master' into pr/8297191 > - added 8297191 to @bug > - Update PrinterView.m > - Update PrinterView.h > - Update CPrinterJob.m > - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS > - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS > - ... and 3 more: https://git.openjdk.org/jdk/compare/5cfce3c6...4de8582f @christianheilmann Your change (at version 4de8582f9e983a2bfc3cb7075f120860d53d9705) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3771815363 From psadhukhan at openjdk.org Tue Jan 20 09:20:22 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 20 Jan 2026 09:20:22 GMT Subject: RFR: 8373239: Test java/awt/print/PrinterJob/PageRanges.java fails with incorrect selection of printed pages Message-ID: <7V3UT7_3iCEk6MDbvc7DHJo4gt013_GpkwApQSAVisk=.cb6f417c-79d7-4df2-babf-83c756a11178@github.com> If same `PrinterJob `is reused to first print user-set `PageRange `pages and then print ALL pages, it prints the first print job correctly as the page range is set but 2nd job doesn't print ALL pages and reprint the same page range as `from` and `to` page are not reset and reused Fix is made to check if page range is not set then print all pages ------------- Commit messages: - 8373239: Test java/awt/print/PrinterJob/PageRanges.java fails with incorrect selection of printed pages Changes: https://git.openjdk.org/jdk/pull/29312/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29312&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373239 Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29312.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29312/head:pull/29312 PR: https://git.openjdk.org/jdk/pull/29312 From serb at openjdk.org Tue Jan 20 09:23:19 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 20 Jan 2026 09:23:19 GMT Subject: RFR: 6441373: Editing JTable is not Serializable [v7] In-Reply-To: References: <5MxYeGqkIlIN1t8-Rtql1Do3MsZcYlUUCStmzVYCOio=.5e8b7079-1a4a-4682-9416-78b26a8603b1@github.com> <-KmQgMxG5nscdqYlEAKRDVsKXVdM-Qcxg57F-wcTB_s=.d543f321-efcb-4274-b2d8-e89bd00469e0@github.com> Message-ID: On Mon, 12 Jan 2026 06:33:03 GMT, Sergey Bylokhov wrote: > If you see issues then please suggest some alternative.. My proposal is here: https://github.com/openjdk/jdk/pull/29313 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28627#discussion_r2707465991 From serb at openjdk.org Tue Jan 20 09:25:26 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 20 Jan 2026 09:25:26 GMT Subject: RFR: 6441373: Editing JTable is not Serializable Message-ID: <24EVy67ZyIy7uxUtvIUDB1v-9j1q6vdDl88LoS9K5WY=.37595035-7c7e-4f6e-9554-9276225d608b@github.com> The patch implements serialization for editable JTables. Currently, most classes responsible for JTable editing are not serializable, so trying to serialize them causes an exception. The patch has two parts: - The editable JTable is reset to non-editable using the common pattern stopCellEditing + cancelCellEditing. This is added to the compWriteObjectNotify method, which acts as an entry point for serialization of Swing components. It allows actions to be performed before the parent classes are serialized. - The editing coordinates for all JTables are reset to -1. Before this patch, even non-editable JTables had their coordinates reset to 0 from -1 because the fields were transient. ------------- Commit messages: - 6441373: Editing JTable is not Serializable Changes: https://git.openjdk.org/jdk/pull/29313/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29313&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6441373 Stats: 176 lines in 2 files changed: 175 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29313.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29313/head:pull/29313 PR: https://git.openjdk.org/jdk/pull/29313 From serb at openjdk.org Tue Jan 20 09:32:13 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 20 Jan 2026 09:32:13 GMT Subject: RFR: 8375567: Remove AppContext usage from Swing Motif L&F classes [v2] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 19:08:38 GMT, Phil Race wrote: >> Remove AppContext from the Swing Motif L&F implementation. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8375567 src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifToggleButtonUI.java line 49: > 47: public class MotifToggleButtonUI extends BasicToggleButtonUI > 48: { > 49: private static final MotifToggleButtonUI MOTIF_TOGGLE_BUTTON_UI = new MotifToggleButtonUI(); Isn't it too repetitive? Motif? motif? motif? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29282#discussion_r2707507016 From serb at openjdk.org Tue Jan 20 09:35:57 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 20 Jan 2026 09:35:57 GMT Subject: RFR: 8375063: Update Libpng to 1.6.54 In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 03:42:50 GMT, Jayathirth D V wrote: > Upgrade libpng used for Splashscreen from 1.6.51 to 1.6.54 version. > Testing is green with this update. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29292#pullrequestreview-3681218571 From serb at openjdk.org Tue Jan 20 09:45:02 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 20 Jan 2026 09:45:02 GMT Subject: RFR: 8375480: Remove usage of AppContext from javax/swing/text In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 07:06:53 GMT, Prasanta Sadhukhan wrote: >> This PR removes usage of AppContext from classes under javax/swing/text. >> Most of the uses were added in specific bug fixes 10-15 years ago but are now obsolete and the tests for those bugs need to be deleted too. > > src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 434: > >> 432: */ >> 433: public void setStyleSheet(StyleSheet s) { >> 434: defaultStyles = s; > > Dont we need to add `synchronized` for setter and getter? getAppContext used to use getAppContextLock!! Some consideration might be needed. It should be taken into account that using AppContext.get/put/remove indirectly causes synchronization points, so everything written before getAppContext becomes visible after. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29259#discussion_r2707549844 From duke at openjdk.org Tue Jan 20 15:02:54 2026 From: duke at openjdk.org (Christian Heilmann) Date: Tue, 20 Jan 2026 15:02:54 GMT Subject: Integrated: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 14:32:50 GMT, Christian Heilmann wrote: > This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS. > > The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m. This pull request has now been integrated. Changeset: 5ba91fed Author: Christian Heilmann Committer: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/5ba91fed345b078a67ad6bead1d8893bd9289f58 Stats: 34 lines in 5 files changed: 0 ins; 13 del; 21 mod 8297191: [macos] Printing a page range with starting page > 1 results in missing pages Reviewed-by: aivanov, prr ------------- PR: https://git.openjdk.org/jdk/pull/11266 From serb at openjdk.org Tue Jan 20 17:03:34 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 20 Jan 2026 17:03:34 GMT Subject: RFR: 8375480: Remove usage of AppContext from javax/swing/text In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 09:41:09 GMT, Sergey Bylokhov wrote: >> src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 434: >> >>> 432: */ >>> 433: public void setStyleSheet(StyleSheet s) { >>> 434: defaultStyles = s; >> >> Dont we need to add `synchronized` for setter and getter? getAppContext used to use getAppContextLock!! > > Some consideration might be needed. It should be taken into account that using AppContext.get/put/remove indirectly causes synchronization points, so everything written before getAppContext becomes visible after. It would probably be better to use LazyConstants for all of this instead of moving everything into a static block and loading everything eagerly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29259#discussion_r2709254708 From serb at openjdk.org Tue Jan 20 17:10:34 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 20 Jan 2026 17:10:34 GMT Subject: RFR: 8375011: OldJTable.java - NullPointerException when columnData is null [v3] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 07:02:12 GMT, ANUPAM DEV wrote: >> Hi, >> >> This is a fix for NPE in OldJTable.addColumn >> >> The addColumn method in OldJTable.java was unconditionally calling columnData.toArray(), which caused a NullPointerException when columnData was null (e.g., when called from addColumn(Object, int)). >> >> This commit adds a null check to safe-guard against this NPE, passing null to the underlying DefaultTableModel when columnData is missing. >> >> Kindly review. >> >> Regards, >> Anupam > > ANUPAM DEV has updated the pull request incrementally with one additional commit since the last revision: > > Update full name Any steps on how to reproduce this bug in the demo? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29226#issuecomment-3773996721 From vdyakov at openjdk.org Tue Jan 20 19:11:51 2026 From: vdyakov at openjdk.org (Victor Dyakov) Date: Tue, 20 Jan 2026 19:11:51 GMT Subject: RFR: 8286258: [Accessibility, macOS, VoiceOver] VoiceOver reads the spinner value wrong and sometime partially In-Reply-To: References: Message-ID: <2szqQC5IDfmtp2XNRFV-O-wfPVKKVZhZWpVySu-VnNM=.b955e168-2e14-4f3f-b646-906a0e67139d@github.com> On Wed, 14 Jan 2026 20:18:08 GMT, Alexander Zuev wrote: > The issue with the announcement of the custom spin boxes is that the text field inside when the value is being changed by the spinbox data model generates some events that are being interpreted by the accessibility subsystem as if text is being actively edited and the system tries to announce it accordingly. In order to stop it from happening we are going to generate correct events and temporarily suppress the text field's methods that reporting the editing-related changes until the actual editing is happened. > > Make embedded text field not to generate random edit-related events; > Add manual test case; @prsadhuk please review from Swing functionality point of view ------------- PR Comment: https://git.openjdk.org/jdk/pull/29235#issuecomment-3774505515 From prr at openjdk.org Tue Jan 20 19:48:02 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 20 Jan 2026 19:48:02 GMT Subject: RFR: 8375567: Remove AppContext usage from Swing Motif L&F classes [v2] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 09:30:09 GMT, Sergey Bylokhov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8375567 > > src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifToggleButtonUI.java line 49: > >> 47: public class MotifToggleButtonUI extends BasicToggleButtonUI >> 48: { >> 49: private static final MotifToggleButtonUI MOTIF_TOGGLE_BUTTON_UI = new MotifToggleButtonUI(); > > Isn't it too repetitive? Motif? motif? motif? I don't think so. The var name is the only one that could be changed and it seems fine to me to keep the name similar to the previous var. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29282#discussion_r2709829713 From prr at openjdk.org Tue Jan 20 19:59:30 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 20 Jan 2026 19:59:30 GMT Subject: RFR: 8375063: Update Libpng to 1.6.54 In-Reply-To: References: Message-ID: <72gaMTRK2OO-cgj3Cg6gtg6AxYsssQiMFTaclmNB7V8=.dd2bc3f7-846a-4613-bfdf-b4f9dfc95148@github.com> On Mon, 19 Jan 2026 03:42:50 GMT, Jayathirth D V wrote: > Upgrade libpng used for Splashscreen from 1.6.51 to 1.6.54 version. > Testing is green with this update. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29292#pullrequestreview-3684027411 From serb at openjdk.org Tue Jan 20 20:23:46 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 20 Jan 2026 20:23:46 GMT Subject: RFR: 8375567: Remove AppContext usage from Swing Motif L&F classes [v2] In-Reply-To: References: Message-ID: <1T4-MAD5t_Kq-DpekGy8U_HmPjpMsfqrEm5QkYuwfZ0=.cfa3f70c-a94c-4893-836b-e9c1cb02b344@github.com> On Tue, 20 Jan 2026 19:44:36 GMT, Phil Race wrote: >> src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifToggleButtonUI.java line 49: >> >>> 47: public class MotifToggleButtonUI extends BasicToggleButtonUI >>> 48: { >>> 49: private static final MotifToggleButtonUI MOTIF_TOGGLE_BUTTON_UI = new MotifToggleButtonUI(); >> >> Isn't it too repetitive? Motif? motif? motif? > > I don't think so. The var name is the only one that could be changed and it seems fine to me to keep the name similar to the previous var. The type of the var MotifToggleButtonUI can be changed to the ComponentUI, and the name can be simplified to TOGGLE_BUTTON_UI or even just UI similar to how it is named in JComponent where it is saved, or just "INSTANCE"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29282#discussion_r2709940835 From prr at openjdk.org Tue Jan 20 20:25:24 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 20 Jan 2026 20:25:24 GMT Subject: RFR: 8375480: Remove usage of AppContext from javax/swing/text [v2] In-Reply-To: References: Message-ID: > This PR removes usage of AppContext from classes under javax/swing/text. > Most of the uses were added in specific bug fixes 10-15 years ago but are now obsolete and the tests for those bugs need to be deleted too. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8375350 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29259/files - new: https://git.openjdk.org/jdk/pull/29259/files/5a03fd34..8e0fde74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29259&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29259&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29259.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29259/head:pull/29259 PR: https://git.openjdk.org/jdk/pull/29259 From bchristi at openjdk.org Tue Jan 20 20:31:18 2026 From: bchristi at openjdk.org (Brent Christian) Date: Tue, 20 Jan 2026 20:31:18 GMT Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325 Message-ID: This brings in cpu26_01 changes. ------------- Commit messages: - 8368032: Enhance Certificate Checking - 8365280: Enhance JOptionPane - 8359501: Enhance Handling of URIs - 8362632: Improve HttpServer Request handling - 8367277: Fix copyright header in JMXInterfaceBindingTest.java - 8366446: Test java/awt/geom/ConcurrentDrawPolygonTest.java fails intermittently - 8341496: Improve JMX connections - 8365058: Enhance CopyOnWriteArraySet - 8365271: Improve Swing supports - 8362308: Enhance Bitmap operations - ... and 2 more: https://git.openjdk.org/jdk/compare/a67979c4...07f981f6 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jdk/pull/29331/files Stats: 1268 lines in 37 files changed: 965 ins; 148 del; 155 mod Patch: https://git.openjdk.org/jdk/pull/29331.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29331/head:pull/29331 PR: https://git.openjdk.org/jdk/pull/29331 From bchristi at openjdk.org Tue Jan 20 20:34:55 2026 From: bchristi at openjdk.org (Brent Christian) Date: Tue, 20 Jan 2026 20:34:55 GMT Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284 Message-ID: This brings in cpu26_01 changes. ------------- Commit messages: - 8368032: Enhance Certificate Checking - 8365280: Enhance JOptionPane - 8359501: Enhance Handling of URIs - 8362632: Improve HttpServer Request handling - 8367277: Fix copyright header in JMXInterfaceBindingTest.java - 8366446: Test java/awt/geom/ConcurrentDrawPolygonTest.java fails intermittently - 8341496: Improve JMX connections - 8365058: Enhance CopyOnWriteArraySet - 8365271: Improve Swing supports - 8362308: Enhance Bitmap operations - ... and 2 more: https://git.openjdk.org/jdk/compare/f4ddafcd...4b0189c4 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jdk/pull/29332/files Stats: 1268 lines in 37 files changed: 965 ins; 148 del; 155 mod Patch: https://git.openjdk.org/jdk/pull/29332.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29332/head:pull/29332 PR: https://git.openjdk.org/jdk/pull/29332 From prr at openjdk.org Tue Jan 20 20:44:33 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 20 Jan 2026 20:44:33 GMT Subject: RFR: 8375480: Remove usage of AppContext from javax/swing/text [v2] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 07:08:10 GMT, Prasanta Sadhukhan wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8375350 > > src/java.desktop/share/classes/javax/swing/text/LayoutQueue.java line 58: > >> 56: public static LayoutQueue getDefaultQueue() { >> 57: if (defaultQueue == null) { >> 58: defaultQueue = new LayoutQueue(); > > synchronized not needed? like the other case, I looked at the change that introduced AppContext here and I simply reverted it. https://hg.openjdk.org/jdk7/jdk7/jdk/rev/442b563e57c6 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29259#discussion_r2709999542 From prr at openjdk.org Tue Jan 20 20:44:34 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 20 Jan 2026 20:44:34 GMT Subject: RFR: 8375480: Remove usage of AppContext from javax/swing/text [v2] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 17:00:29 GMT, Sergey Bylokhov wrote: >> Some consideration might be needed. It should be taken into account that using AppContext.get/put/remove indirectly causes synchronization points, so everything written before getAppContext becomes visible after. > > It would probably be better to use LazyConstants for all of this instead of moving everything into a static block and loading everything eagerly. I looked at the change that introduced AppContext here and I simply reverted it. https://hg.openjdk.org/jdk7/jdk7/jdk/rev/9ed7ae1e911c So as far as I can tell, thread safety was never a guarantee here. And the containing package doc https://docs.oracle.com/en/java/javase/25/docs/api/java.desktop/javax/swing/text/html/package-summary.html Says "Most of the Swing API is not thread safe...." I don't understaand the comment about LazyConstants. The Stylesheet is not being eagerly created. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29259#discussion_r2709997875 From kcr at openjdk.org Tue Jan 20 21:34:45 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 20 Jan 2026 21:34:45 GMT Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. LGTM ------------- Marked as reviewed by kcr (Author). PR Review: https://git.openjdk.org/jdk/pull/29331#pullrequestreview-3684377505 From kcr at openjdk.org Tue Jan 20 21:35:46 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 20 Jan 2026 21:35:46 GMT Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. LGTM ------------- Marked as reviewed by kcr (Author). PR Review: https://git.openjdk.org/jdk/pull/29332#pullrequestreview-3684378038 From prr at openjdk.org Tue Jan 20 22:05:29 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 20 Jan 2026 22:05:29 GMT Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29331#pullrequestreview-3684486562 From serb at openjdk.org Tue Jan 20 22:08:36 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 20 Jan 2026 22:08:36 GMT Subject: RFR: 8375480: Remove usage of AppContext from javax/swing/text [v2] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:25:24 GMT, Phil Race wrote: >> This PR removes usage of AppContext from classes under javax/swing/text. >> Most of the uses were added in specific bug fixes 10-15 years ago but are now obsolete and the tests for those bugs need to be deleted too. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8375350 Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29259#pullrequestreview-3684493243 From serb at openjdk.org Tue Jan 20 22:08:38 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 20 Jan 2026 22:08:38 GMT Subject: RFR: 8375480: Remove usage of AppContext from javax/swing/text [v2] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:40:30 GMT, Phil Race wrote: > And the containing package doc >https://docs.oracle.com/en/java/javase/25/docs/api/java.desktop/javax/swing/text/html/package-summary.html >Says "Most of the Swing API is not thread safe...." This is mostly correct, except for cases where some parts of the API may be used by the lightweight AWT. >I don't understaand the comment about LazyConstants. >The Stylesheet is not being eagerly created. That comment referred to a task of removing the AppContext as a whole, where many things are now being moved into static blocks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29259#discussion_r2710226105 From prr at openjdk.org Tue Jan 20 22:08:39 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 20 Jan 2026 22:08:39 GMT Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29332#pullrequestreview-3684495706 From prr at openjdk.org Tue Jan 20 22:52:21 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 20 Jan 2026 22:52:21 GMT Subject: RFR: 8373239: Test java/awt/print/PrinterJob/PageRanges.java fails with incorrect selection of printed pages In-Reply-To: <7V3UT7_3iCEk6MDbvc7DHJo4gt013_GpkwApQSAVisk=.cb6f417c-79d7-4df2-babf-83c756a11178@github.com> References: <7V3UT7_3iCEk6MDbvc7DHJo4gt013_GpkwApQSAVisk=.cb6f417c-79d7-4df2-babf-83c756a11178@github.com> Message-ID: <_cZkUC49yexwgnqI0L3780NeY7Fs5tdVI8MqzC_HO4I=.06d78502-2b97-4d12-b3ca-407756809b59@github.com> On Tue, 20 Jan 2026 09:11:06 GMT, Prasanta Sadhukhan wrote: > If same `PrinterJob `is reused to first print user-set `PageRange `pages and then print ALL pages, it prints the first print job correctly as the page range is set but 2nd job doesn't print ALL pages and reprint the same page range as `from` and `to` page are not reset and reused > > Fix is made to check if page range is not set then print all pages src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java line 1737: > 1735: setPageRange(from, to); > 1736: } else { > 1737: attributes.add(new PageRanges(1, 9999)); Win32PrintService uses new PageRanges(1, Integer.MAX_VALUE); But in this case, don't you just want to remove the attribute (?) if it exists that is. src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java line 1738: > 1736: } else { > 1737: attributes.add(new PageRanges(1, 9999)); > 1738: setPageRange(1, 9999); If you want to clear this, I think it should be setPageRange(Pageable.UNKNOWN_NUMBER_OF_PAGES, Pageable.UNKNOWN_NUMBER_OF_PAGES) those are the initial values set in RasterPrinterJob. Basically you want to re-set things to exactly as if PageRanges were never set. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29312#discussion_r2710315794 PR Review Comment: https://git.openjdk.org/jdk/pull/29312#discussion_r2710345208 From prr at openjdk.org Tue Jan 20 23:00:30 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 20 Jan 2026 23:00:30 GMT Subject: RFR: 8375567: Remove AppContext usage from Swing Motif L&F classes [v2] In-Reply-To: <1T4-MAD5t_Kq-DpekGy8U_HmPjpMsfqrEm5QkYuwfZ0=.cfa3f70c-a94c-4893-836b-e9c1cb02b344@github.com> References: <1T4-MAD5t_Kq-DpekGy8U_HmPjpMsfqrEm5QkYuwfZ0=.cfa3f70c-a94c-4893-836b-e9c1cb02b344@github.com> Message-ID: On Tue, 20 Jan 2026 20:20:07 GMT, Sergey Bylokhov wrote: >> I don't think so. The var name is the only one that could be changed and it seems fine to me to keep the name similar to the previous var. > > The type of the var MotifToggleButtonUI can be changed to the ComponentUI, and the name can be simplified to TOGGLE_BUTTON_UI or even just UI similar to how it is named in JComponent where it is saved, or just "INSTANCE"? True that createUI returns a ComponentUI, but the proposed code makes it clear what is the actual type, and the removed code used MotifToggleButtonUI too, even thought it could have used ComponentUI No extra cost to this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29282#discussion_r2710365398 From serb at openjdk.org Tue Jan 20 23:52:03 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 20 Jan 2026 23:52:03 GMT Subject: RFR: 8375567: Remove AppContext usage from Swing Motif L&F classes [v2] In-Reply-To: References: <1T4-MAD5t_Kq-DpekGy8U_HmPjpMsfqrEm5QkYuwfZ0=.cfa3f70c-a94c-4893-836b-e9c1cb02b344@github.com> Message-ID: On Tue, 20 Jan 2026 22:58:23 GMT, Phil Race wrote: >No extra cost to this. The cost is the size of the monitor =( `private static final ComponentUI INSTANCE = new MotifToggleButtonUI();` fits well into the 80 chars per line, without loosing much information. And it seems that the object should always be used via createUI method anyway, in this class specifically and in all UI delegates. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29282#discussion_r2710459854 From serb at openjdk.org Wed Jan 21 00:04:59 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 21 Jan 2026 00:04:59 GMT Subject: RFR: 8375351: Remove usage of AppContext from print implementation [v4] In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 17:49:44 GMT, Phil Race wrote: >> Remove AppContext from javax.print > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8375351 src/java.desktop/share/classes/javax/print/StreamPrintServiceFactory.java line 77: > 75: */ > 76: private static Services getServices() { > 77: return SERVICES; Can SERVICES be eliminated completely? Previously, services acted as a bridge between the client and listOfFactories (via the per-app context). Now there is a 1-to-1 mapping. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29237#discussion_r2710485534 From smarks at openjdk.org Wed Jan 21 01:16:18 2026 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 21 Jan 2026 01:16:18 GMT Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284 In-Reply-To: References: Message-ID: <16L6cSilYiC8tbhpmKW2g3X19hE5-A0jHERAtsCJ9S4=.3211d9ae-c184-4ec9-823f-43b77fd49d68@github.com> On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. The changes in this PR match the list of approved changes for this release. ------------- Marked as reviewed by smarks (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29332#pullrequestreview-3684928489 From smarks at openjdk.org Wed Jan 21 01:16:22 2026 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 21 Jan 2026 01:16:22 GMT Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. The changes in this PR match the list of approved changes for this release. ------------- Marked as reviewed by smarks (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29331#pullrequestreview-3684928880 From bchristi at openjdk.org Wed Jan 21 01:33:46 2026 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 21 Jan 2026 01:33:46 GMT Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284 [v2] In-Reply-To: References: Message-ID: > This brings in cpu26_01 changes. Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29332/files - new: https://git.openjdk.org/jdk/pull/29332/files/4b0189c4..4b0189c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29332&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29332&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29332.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29332/head:pull/29332 PR: https://git.openjdk.org/jdk/pull/29332 From bchristi at openjdk.org Wed Jan 21 01:33:48 2026 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 21 Jan 2026 01:33:48 GMT Subject: [jdk26] Integrated: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. This pull request has now been integrated. Changeset: 7ac780da Author: Brent Christian URL: https://git.openjdk.org/jdk/commit/7ac780da7b98d1a44effc86e75b62a1bedc7954b Stats: 1268 lines in 37 files changed: 965 ins; 148 del; 155 mod Merge Reviewed-by: kcr, prr, smarks ------------- PR: https://git.openjdk.org/jdk/pull/29332 From bchristi at openjdk.org Wed Jan 21 01:34:06 2026 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 21 Jan 2026 01:34:06 GMT Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325 [v2] In-Reply-To: References: Message-ID: <_R8gyRrfwT8U_cL4_T9ImlWVN5Q3zLKoa61ZVBXQP5E=.8fbf5d4d-4be3-46a9-94c2-b14c0ddef43d@github.com> > This brings in cpu26_01 changes. Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29331/files - new: https://git.openjdk.org/jdk/pull/29331/files/07f981f6..07f981f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29331&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29331&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29331.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29331/head:pull/29331 PR: https://git.openjdk.org/jdk/pull/29331 From bchristi at openjdk.org Wed Jan 21 01:34:09 2026 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 21 Jan 2026 01:34:09 GMT Subject: Integrated: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. This pull request has now been integrated. Changeset: e25a5a48 Author: Brent Christian URL: https://git.openjdk.org/jdk/commit/e25a5a4821d03680d00ab6bdbec727732add8206 Stats: 1268 lines in 37 files changed: 965 ins; 148 del; 155 mod Merge Reviewed-by: kcr, prr, smarks ------------- PR: https://git.openjdk.org/jdk/pull/29331 From jdv at openjdk.org Wed Jan 21 03:17:30 2026 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 21 Jan 2026 03:17:30 GMT Subject: Integrated: 8375063: Update Libpng to 1.6.54 In-Reply-To: References: Message-ID: <5HBZ8xZUZBNv0ntcAuz8B0ePkpFp6XbFQ6Wwz6H1HRk=.abb088c4-a9b0-491d-9114-0b9ea4c330ee@github.com> On Mon, 19 Jan 2026 03:42:50 GMT, Jayathirth D V wrote: > Upgrade libpng used for Splashscreen from 1.6.51 to 1.6.54 version. > Testing is green with this update. This pull request has now been integrated. Changeset: a2e74957 Author: Jayathirth D V URL: https://git.openjdk.org/jdk/commit/a2e749572e03dd394d123b701e163e3837472dd0 Stats: 1406 lines in 16 files changed: 443 ins; 7 del; 956 mod 8375063: Update Libpng to 1.6.54 Reviewed-by: serb, prr ------------- PR: https://git.openjdk.org/jdk/pull/29292 From tr at openjdk.org Wed Jan 21 05:20:03 2026 From: tr at openjdk.org (Tejesh R) Date: Wed, 21 Jan 2026 05:20:03 GMT Subject: RFR: 8375573: JTable ignores setPreferredWidth during initial layout when AUTO_RESIZE_LAST_COLUMN is enabled In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 02:18:06 GMT, Prasanta Sadhukhan wrote: > AUTO_RESIZE_LAST_COLUMN handling was done in [JDK-8234071](https://bugs.openjdk.org/browse/JDK-8234071) but it didn't honour the preferred width if it is already been set for each column so when layouting is done, it only sees the `resizingColumn` > is set to AUTO_RESIZE_LAST_COLUMN and adjust only the last column and distribute width equally to all other column. > > Fix is made to honour the user-set preferred column width even if auto-resize mode is set to LAST_COLUMN src/java.desktop/share/classes/javax/swing/JTable.java line 3204: > 3202: // AUTO_RESIZE_LAST_COLUMN autoResizeMode > 3203: for (int i = 0; i < columnModel.getColumnCount(); i++) { > 3204: if (columnModel.getColumn(i).getPreferredWidth() != 75 Why are we using hardcoded value here ? Any particular reason for checking width against value `75` ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29291#discussion_r2711000558 From psadhukhan at openjdk.org Wed Jan 21 06:14:07 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 21 Jan 2026 06:14:07 GMT Subject: RFR: 8375573: JTable ignores setPreferredWidth during initial layout when AUTO_RESIZE_LAST_COLUMN is enabled In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 05:16:35 GMT, Tejesh R wrote: >> AUTO_RESIZE_LAST_COLUMN handling was done in [JDK-8234071](https://bugs.openjdk.org/browse/JDK-8234071) but it didn't honour the preferred width if it is already been set for each column so when layouting is done, it only sees the `resizingColumn` >> is set to AUTO_RESIZE_LAST_COLUMN and adjust only the last column and distribute width equally to all other column. >> >> Fix is made to honour the user-set preferred column width even if auto-resize mode is set to LAST_COLUMN > > src/java.desktop/share/classes/javax/swing/JTable.java line 3204: > >> 3202: // AUTO_RESIZE_LAST_COLUMN autoResizeMode >> 3203: for (int i = 0; i < columnModel.getColumnCount(); i++) { >> 3204: if (columnModel.getColumn(i).getPreferredWidth() != 75 > > Why are we using hardcoded value here ? Any particular reason for checking width against value `75` ? Because default width is such and there is no way to ascertain default width.. https://github.com/openjdk/jdk/blob/b5727d27622e1e321733f8d0e606b366984104be/src/java.desktop/share/classes/javax/swing/table/TableColumn.java#L523-L524 https://github.com/openjdk/jdk/blob/b5727d27622e1e321733f8d0e606b366984104be/src/java.desktop/share/classes/javax/swing/table/TableColumn.java#L556-L557 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29291#discussion_r2711110938 From psadhukhan at openjdk.org Wed Jan 21 06:27:42 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 21 Jan 2026 06:27:42 GMT Subject: RFR: 8373239: Test java/awt/print/PrinterJob/PageRanges.java fails with incorrect selection of printed pages [v2] In-Reply-To: <7V3UT7_3iCEk6MDbvc7DHJo4gt013_GpkwApQSAVisk=.cb6f417c-79d7-4df2-babf-83c756a11178@github.com> References: <7V3UT7_3iCEk6MDbvc7DHJo4gt013_GpkwApQSAVisk=.cb6f417c-79d7-4df2-babf-83c756a11178@github.com> Message-ID: > If same `PrinterJob `is reused to first print user-set `PageRange `pages and then print ALL pages, it prints the first print job correctly as the page range is set but 2nd job doesn't print ALL pages and reprint the same page range as `from` and `to` page are not reset and reused > > Fix is made to check if page range is not set then print all pages Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Remove PageRange attribute if range is not set ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29312/files - new: https://git.openjdk.org/jdk/pull/29312/files/fe390b84..15017ef8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29312&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29312&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29312.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29312/head:pull/29312 PR: https://git.openjdk.org/jdk/pull/29312 From psadhukhan at openjdk.org Wed Jan 21 06:27:43 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 21 Jan 2026 06:27:43 GMT Subject: RFR: 8373239: Test java/awt/print/PrinterJob/PageRanges.java fails with incorrect selection of printed pages [v2] In-Reply-To: <_cZkUC49yexwgnqI0L3780NeY7Fs5tdVI8MqzC_HO4I=.06d78502-2b97-4d12-b3ca-407756809b59@github.com> References: <7V3UT7_3iCEk6MDbvc7DHJo4gt013_GpkwApQSAVisk=.cb6f417c-79d7-4df2-babf-83c756a11178@github.com> <_cZkUC49yexwgnqI0L3780NeY7Fs5tdVI8MqzC_HO4I=.06d78502-2b97-4d12-b3ca-407756809b59@github.com> Message-ID: On Tue, 20 Jan 2026 22:36:02 GMT, Phil Race wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove PageRange attribute if range is not set > > src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java line 1737: > >> 1735: setPageRange(from, to); >> 1736: } else { >> 1737: attributes.add(new PageRanges(1, 9999)); > > Win32PrintService uses > new PageRanges(1, Integer.MAX_VALUE); > > But in this case, don't you just want to remove the attribute (?) if it exists that is. Yes, I guess it's more apt..Updated.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29312#discussion_r2711133712 From tr at openjdk.org Wed Jan 21 06:40:03 2026 From: tr at openjdk.org (Tejesh R) Date: Wed, 21 Jan 2026 06:40:03 GMT Subject: RFR: 8375573: JTable ignores setPreferredWidth during initial layout when AUTO_RESIZE_LAST_COLUMN is enabled In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 06:11:50 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/share/classes/javax/swing/JTable.java line 3204: >> >>> 3202: // AUTO_RESIZE_LAST_COLUMN autoResizeMode >>> 3203: for (int i = 0; i < columnModel.getColumnCount(); i++) { >>> 3204: if (columnModel.getColumn(i).getPreferredWidth() != 75 >> >> Why are we using hardcoded value here ? Any particular reason for checking width against value `75` ? > > Because default width is such and there is no way to ascertain default width.. > https://github.com/openjdk/jdk/blob/b5727d27622e1e321733f8d0e606b366984104be/src/java.desktop/share/classes/javax/swing/table/TableColumn.java#L523-L524 > > https://github.com/openjdk/jdk/blob/b5727d27622e1e321733f8d0e606b366984104be/src/java.desktop/share/classes/javax/swing/table/TableColumn.java#L556-L557 Got it, it's been set here - https://github.com/openjdk/jdk/blob/b5727d27622e1e321733f8d0e606b366984104be/src/java.desktop/share/classes/javax/swing/table/TableColumn.java#L211 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29291#discussion_r2711169026 From psadhukhan at openjdk.org Wed Jan 21 07:26:38 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 21 Jan 2026 07:26:38 GMT Subject: RFR: 8373239: Test java/awt/print/PrinterJob/PageRanges.java fails with incorrect selection of printed pages [v3] In-Reply-To: <7V3UT7_3iCEk6MDbvc7DHJo4gt013_GpkwApQSAVisk=.cb6f417c-79d7-4df2-babf-83c756a11178@github.com> References: <7V3UT7_3iCEk6MDbvc7DHJo4gt013_GpkwApQSAVisk=.cb6f417c-79d7-4df2-babf-83c756a11178@github.com> Message-ID: > If same `PrinterJob `is reused to first print user-set `PageRange `pages and then print ALL pages, it prints the first print job correctly as the page range is set but 2nd job doesn't print ALL pages and reprint the same page range as `from` and `to` page are not reset and reused > > Fix is made to check if page range is not set then print all pages Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge master - Merge master - Remove PageRange attribute if range is not set - 8373239: Test java/awt/print/PrinterJob/PageRanges.java fails with incorrect selection of printed pages ------------- Changes: https://git.openjdk.org/jdk/pull/29312/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29312&range=02 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29312.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29312/head:pull/29312 PR: https://git.openjdk.org/jdk/pull/29312 From psadhukhan at openjdk.org Wed Jan 21 08:32:48 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 21 Jan 2026 08:32:48 GMT Subject: RFR: 8286258: [Accessibility, macOS, VoiceOver] VoiceOver reads the spinner value wrong and sometime partially In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 20:18:08 GMT, Alexander Zuev wrote: > The issue with the announcement of the custom spin boxes is that the text field inside when the value is being changed by the spinbox data model generates some events that are being interpreted by the accessibility subsystem as if text is being actively edited and the system tries to announce it accordingly. In order to stop it from happening we are going to generate correct events and temporarily suppress the text field's methods that reporting the editing-related changes until the actual editing is happened. > > Make embedded text field not to generate random edit-related events; > Add manual test case; src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/NavigableTextAccessibility.m line 19: > 17: * > 18: * You should have received a copy of the GNU General Public License version > 19: * 2 along with this work; if not, write to the Free Software Foundation, line deleted by mistake? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29235#discussion_r2711483634 From tr at openjdk.org Wed Jan 21 08:38:17 2026 From: tr at openjdk.org (Tejesh R) Date: Wed, 21 Jan 2026 08:38:17 GMT Subject: Withdrawn: 8369311: De-problemlist 8305915 since the issue is not reproducible In-Reply-To: <4LAh1FXUeqdb0B1nNWCmB7TDzBJp1wwH6h6X8FaddFw=.c1f92044-9389-4541-88b7-a7356e82abef@github.com> References: <4LAh1FXUeqdb0B1nNWCmB7TDzBJp1wwH6h6X8FaddFw=.c1f92044-9389-4541-88b7-a7356e82abef@github.com> Message-ID: On Tue, 7 Oct 2025 16:43:08 GMT, Tejesh R wrote: > [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915) is not reproducible with multiple CI checks. The main test java/awt/Frame/FrameLocation/FrameLocation.java which was failing is been missed in the Problem-List file, rather java/awt/Frame/SizeMinimizedTest.java is been added which still doesn't fail. So de-problemlisting with a sub-task and closing the main bug as "Not-reproducible". This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27678 From psadhukhan at openjdk.org Wed Jan 21 09:32:31 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 21 Jan 2026 09:32:31 GMT Subject: RFR: 8375480: Remove usage of AppContext from javax/swing/text [v2] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:25:24 GMT, Phil Race wrote: >> This PR removes usage of AppContext from classes under javax/swing/text. >> Most of the uses were added in specific bug fixes 10-15 years ago but are now obsolete and the tests for those bugs need to be deleted too. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8375350 src/java.desktop/share/classes/javax/swing/text/html/parser/Element.java line 109: > 107: this.index = index; > 108: if (index > getMaxIndex()) { > 109: maxIndex = index; guess before AppContext was added the code was `maxIndex = Math.max(maxIndex, index);` https://hg.openjdk.org/jdk8/jdk8/jdk/rev/0967103c1b65 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29259#discussion_r2711703592 From duke at openjdk.org Wed Jan 21 10:49:10 2026 From: duke at openjdk.org (ANUPAM DEV) Date: Wed, 21 Jan 2026 10:49:10 GMT Subject: RFR: 8375011: OldJTable.java - NullPointerException when columnData is null [v3] In-Reply-To: References: Message-ID: <2BFY6UyiqDJefZ_YQPaQkkfZGSg1df0seX3fpvl0-eo=.9161ebb1-a9b5-404b-9aa4-016fd0862276@github.com> On Tue, 20 Jan 2026 17:06:34 GMT, Sergey Bylokhov wrote: >> ANUPAM DEV has updated the pull request incrementally with one additional commit since the last revision: >> >> Update full name > > Any steps on how to reproduce this bug in the demo? Hi @mrserb, The following reproducer will throw NPE, although demo itself does not have any such calls: OldJTable table = new OldJTable(); table.addColumn("TestColumn", 100); Regards, Anupam ------------- PR Comment: https://git.openjdk.org/jdk/pull/29226#issuecomment-3777412499 From duke at openjdk.org Wed Jan 21 13:53:38 2026 From: duke at openjdk.org (Dmitry Drobotov) Date: Wed, 21 Jan 2026 13:53:38 GMT Subject: RFR: 8286258: [Accessibility, macOS, VoiceOver] VoiceOver reads the spinner value wrong and sometime partially In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 20:18:08 GMT, Alexander Zuev wrote: > The issue with the announcement of the custom spin boxes is that the text field inside when the value is being changed by the spinbox data model generates some events that are being interpreted by the accessibility subsystem as if text is being actively edited and the system tries to announce it accordingly. In order to stop it from happening we are going to generate correct events and temporarily suppress the text field's methods that reporting the editing-related changes until the actual editing is happened. > > Make embedded text field not to generate random edit-related events; > Add manual test case; I also checked this patch in IntelliJ and it fixed this issue with our spinners as well. src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SpinboxAccessibility.m line 89: > 87: if ([child conformsToProtocol:@protocol(NSAccessibilityNavigableStaticText)]) { > 88: NSAccessibilityPostNotification(child, NSAccessibilityLayoutChangedNotification); > 89: NSAccessibilityPostNotification(child, NSAccessibilityAnnouncementRequestedNotification); I assume this line is not necessary, `NSAccessibilityAnnouncementRequestedNotification` is used to make VoiceOver announce an arbitrary string, which would be passed in `userInfo` argument for `NSAccessibilityPostNotificationWithUserInfo`. ------------- PR Review: https://git.openjdk.org/jdk/pull/29235#pullrequestreview-3687337651 PR Review Comment: https://git.openjdk.org/jdk/pull/29235#discussion_r2712651332 From prr at openjdk.org Wed Jan 21 18:46:12 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 21 Jan 2026 18:46:12 GMT Subject: RFR: 8373239: Test java/awt/print/PrinterJob/PageRanges.java fails with incorrect selection of printed pages [v3] In-Reply-To: References: <7V3UT7_3iCEk6MDbvc7DHJo4gt013_GpkwApQSAVisk=.cb6f417c-79d7-4df2-babf-83c756a11178@github.com> Message-ID: <5oA_LmiQ1TSkLJ-VLMGGHfINhmyMnMGUq1vAeHs6avk=.2a1fadcb-b397-4dd7-ba89-7c6842c2ef5e@github.com> On Wed, 21 Jan 2026 07:26:38 GMT, Prasanta Sadhukhan wrote: >> If same `PrinterJob `is reused to first print user-set `PageRange `pages and then print ALL pages, it prints the first print job correctly as the page range is set but 2nd job doesn't print ALL pages and reprint the same page range as `from` and `to` page are not reset and reused >> >> Fix is made to check if page range is not set then print all pages > > Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge master > - Merge master > - Remove PageRange attribute if range is not set > - 8373239: Test java/awt/print/PrinterJob/PageRanges.java fails with incorrect selection of printed pages src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java line 1737: > 1735: setPageRange(from, to); > 1736: } else { > 1737: attributes.remove(PageRanges.class); I'm a bit surprised you didn't need to still reset the page range ... is something else re-setting it ? setPageRange(Pageable.UNKNOWN_NUMBER_OF_PAGES, Pageable.UNKNOWN_NUMBER_OF_PAGES) src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java line 1737: > 1735: setPageRange(from, to); > 1736: } else { > 1737: attributes.remove(PageRanges.class); I'm a bit surprised you didn't need to still reset the page range ... is something else re-setting it ? setPageRange(Pageable.UNKNOWN_NUMBER_OF_PAGES, Pageable.UNKNOWN_NUMBER_OF_PAGES) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29312#discussion_r2713845703 PR Review Comment: https://git.openjdk.org/jdk/pull/29312#discussion_r2713846544 From prr at openjdk.org Wed Jan 21 18:48:03 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 21 Jan 2026 18:48:03 GMT Subject: RFR: 8375480: Remove usage of AppContext from javax/swing/text [v2] In-Reply-To: References: Message-ID: <7VbnMPnMKm5ETHmzJkCguPRw7rJxeknfdwaPHqaEmbs=.17f55d2b-5592-4fbe-88e3-40cfd9c0e75a@github.com> On Wed, 21 Jan 2026 09:29:15 GMT, Prasanta Sadhukhan wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8375350 > > src/java.desktop/share/classes/javax/swing/text/html/parser/Element.java line 109: > >> 107: this.index = index; >> 108: if (index > getMaxIndex()) { >> 109: maxIndex = index; > > guess before AppContext was added the code was > `maxIndex = Math.max(maxIndex, index);` > > https://hg.openjdk.org/jdk8/jdk8/jdk/rev/0967103c1b65 I prefer it as I have it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29259#discussion_r2713879933 From prr at openjdk.org Wed Jan 21 18:48:58 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 21 Jan 2026 18:48:58 GMT Subject: RFR: 8373626: [asan] read past end of buffer in sun.awt.image.ImagingLib.convolveBI [v2] In-Reply-To: References: Message-ID: > Some of the medialib native functions implementing Convolve read data from arrays when it is not needed or used instead of reading just what is needed and used. > This is detected as a read out of bounds. It is limited and hasn't been seen to result in any crashes without ASAN, and the OOB values that are read are never used so there's a very limited problem. > The changes here make the mlib_ImageConv_*nw.c files match what happens in the mlib_ImageConv_*ext.c files which read just the data they need. > The changes are fairly mechanical but there could be copy/paste errors for a reviewer to find. > > Not easy to provide a test case, building with --enable-asan is needed and for me it works only on macOS. > I did that and ran all our existing automated tests on our CI systems. Phil Race 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 - 8373626 ------------- Changes: https://git.openjdk.org/jdk/pull/29257/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29257&range=01 Stats: 435 lines in 7 files changed: 357 ins; 54 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/29257.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29257/head:pull/29257 PR: https://git.openjdk.org/jdk/pull/29257 From prr at openjdk.org Wed Jan 21 18:52:00 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 21 Jan 2026 18:52:00 GMT Subject: RFR: 8375221: Update code to get PrinterResolution from CUPS/IPP print service [v3] In-Reply-To: References: Message-ID: > Previous to this fix, no resolution was being found via CUPS/IPP and when the test case for printer resolution was falling back to the made up 300dpi setting. With this fix it finds the 600dpi from CUPS/IPP. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8375221 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29208/files - new: https://git.openjdk.org/jdk/pull/29208/files/644c8f11..3764321b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29208&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29208&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29208.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29208/head:pull/29208 PR: https://git.openjdk.org/jdk/pull/29208 From prr at openjdk.org Wed Jan 21 19:22:55 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 21 Jan 2026 19:22:55 GMT Subject: RFR: 8373931: Test javax/sound/sampled/Clip/AutoCloseTimeCheck.java timed out Message-ID: This test needs the jtreg tag "@key sound" so that it can be properly directed to run only on systems with sound support. ------------- Commit messages: - 8373931 - 8373931 Changes: https://git.openjdk.org/jdk/pull/29353/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29353&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373931 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29353/head:pull/29353 PR: https://git.openjdk.org/jdk/pull/29353 From dholmes at openjdk.org Wed Jan 21 19:54:25 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Jan 2026 19:54:25 GMT Subject: RFR: 8373931: Test javax/sound/sampled/Clip/AutoCloseTimeCheck.java timed out In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 19:12:10 GMT, Phil Race wrote: > This test needs the jtreg tag "@key sound" so that it can be properly directed to run only on systems with sound support. Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29353#pullrequestreview-3689120813 From dnguyen at openjdk.org Wed Jan 21 19:58:23 2026 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 21 Jan 2026 19:58:23 GMT Subject: RFR: 8373931: Test javax/sound/sampled/Clip/AutoCloseTimeCheck.java timed out In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 19:12:10 GMT, Phil Race wrote: > This test needs the jtreg tag "@key sound" so that it can be properly directed to run only on systems with sound support. Marked as reviewed by dnguyen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29353#pullrequestreview-3689135015 From serb at openjdk.org Wed Jan 21 20:00:47 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 21 Jan 2026 20:00:47 GMT Subject: RFR: 8375221: Update code to get PrinterResolution from CUPS/IPP print service [v3] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 18:52:00 GMT, Phil Race wrote: >> Previous to this fix, no resolution was being found via CUPS/IPP and when the test case for printer resolution was falling back to the made up 300dpi setting. With this fix it finds the 600dpi from CUPS/IPP. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8375221 Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29208#pullrequestreview-3689142159 From kizune at openjdk.org Wed Jan 21 20:03:21 2026 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 21 Jan 2026 20:03:21 GMT Subject: RFR: 8286258: [Accessibility, macOS, VoiceOver] VoiceOver reads the spinner value wrong and sometime partially In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 13:46:46 GMT, Dmitry Drobotov wrote: >> The issue with the announcement of the custom spin boxes is that the text field inside when the value is being changed by the spinbox data model generates some events that are being interpreted by the accessibility subsystem as if text is being actively edited and the system tries to announce it accordingly. In order to stop it from happening we are going to generate correct events and temporarily suppress the text field's methods that reporting the editing-related changes until the actual editing is happened. >> >> Make embedded text field not to generate random edit-related events; >> Add manual test case; > > src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SpinboxAccessibility.m line 89: > >> 87: if ([child conformsToProtocol:@protocol(NSAccessibilityNavigableStaticText)]) { >> 88: NSAccessibilityPostNotification(child, NSAccessibilityLayoutChangedNotification); >> 89: NSAccessibilityPostNotification(child, NSAccessibilityAnnouncementRequestedNotification); > > I assume this line is not necessary, `NSAccessibilityAnnouncementRequestedNotification` is used to make VoiceOver announce an arbitrary string, which would be passed in `userInfo` argument for `NSAccessibilityPostNotificationWithUserInfo`. I added it just to ping the a11y subsystem in non-disruptive manner, if i remember correctly without this notification rapid change back and forth resulted in not announcing the last selected value. Let me try to remove it and re-test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29235#discussion_r2714130874 From kizune at openjdk.org Wed Jan 21 20:00:49 2026 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 21 Jan 2026 20:00:49 GMT Subject: RFR: 8286258: [Accessibility, macOS, VoiceOver] VoiceOver reads the spinner value wrong and sometime partially In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 08:30:29 GMT, Prasanta Sadhukhan wrote: >> The issue with the announcement of the custom spin boxes is that the text field inside when the value is being changed by the spinbox data model generates some events that are being interpreted by the accessibility subsystem as if text is being actively edited and the system tries to announce it accordingly. In order to stop it from happening we are going to generate correct events and temporarily suppress the text field's methods that reporting the editing-related changes until the actual editing is happened. >> >> Make embedded text field not to generate random edit-related events; >> Add manual test case; > > src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/NavigableTextAccessibility.m line 19: > >> 17: * >> 18: * You should have received a copy of the GNU General Public License version >> 19: * 2 along with this work; if not, write to the Free Software Foundation, > > line deleted by mistake? Oops... Thanks for pointing it out, restoring. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29235#discussion_r2714120932 From serb at openjdk.org Wed Jan 21 20:00:38 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 21 Jan 2026 20:00:38 GMT Subject: RFR: 8375011: OldJTable.java - NullPointerException when columnData is null [v3] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 07:02:12 GMT, ANUPAM DEV wrote: >> Hi, >> >> This is a fix for NPE in OldJTable.addColumn >> >> The addColumn method in OldJTable.java was unconditionally calling columnData.toArray(), which caused a NullPointerException when columnData was null (e.g., when called from addColumn(Object, int)). >> >> This commit adds a null check to safe-guard against this NPE, passing null to the underlying DefaultTableModel when columnData is missing. >> >> Kindly review. >> >> Regards, >> Anupam > > ANUPAM DEV has updated the pull request incrementally with one additional commit since the last revision: > > Update full name But this is just a demo, right? Is it possible to trigger an exception by running the app? Are these addColumn methods actually used by the application? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29226#issuecomment-3780879474 From serb at openjdk.org Wed Jan 21 20:04:45 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 21 Jan 2026 20:04:45 GMT Subject: RFR: 8373931: Test javax/sound/sampled/Clip/AutoCloseTimeCheck.java timed out In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 19:12:10 GMT, Phil Race wrote: > This test needs the jtreg tag "@key sound" so that it can be properly directed to run only on systems with sound support. This test validates the functionality of SoundClip, which stated in the spec: * if the implementation does not find a suitable output device for the data, * playing the clip will be a no-op. So if it hangs then it is a product bug. If there is a known bug (even external), it should be reported in jbs, and the test should be added to the problem list with correct bugid until the bug is fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29353#issuecomment-3780890462 PR Comment: https://git.openjdk.org/jdk/pull/29353#issuecomment-3780896828 From kizune at openjdk.org Wed Jan 21 20:21:37 2026 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 21 Jan 2026 20:21:37 GMT Subject: RFR: 8286258: [Accessibility, macOS, VoiceOver] VoiceOver reads the spinner value wrong and sometime partially In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 20:00:48 GMT, Alexander Zuev wrote: >> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SpinboxAccessibility.m line 89: >> >>> 87: if ([child conformsToProtocol:@protocol(NSAccessibilityNavigableStaticText)]) { >>> 88: NSAccessibilityPostNotification(child, NSAccessibilityLayoutChangedNotification); >>> 89: NSAccessibilityPostNotification(child, NSAccessibilityAnnouncementRequestedNotification); >> >> I assume this line is not necessary, `NSAccessibilityAnnouncementRequestedNotification` is used to make VoiceOver announce an arbitrary string, which would be passed in `userInfo` argument for `NSAccessibilityPostNotificationWithUserInfo`. > > I added it just to ping the a11y subsystem in non-disruptive manner, if i remember correctly without this notification rapid change back and forth resulted in not announcing the last selected value. Let me try to remove it and re-test. Ok, i removed the second notification and it seems to work fine, looks like the glitch with fast switching was due to my previous version of the announcement suspension, i fixed it at the same time i added the second notification i thought that second notification was what corrected it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29235#discussion_r2714191282 From kizune at openjdk.org Wed Jan 21 20:30:28 2026 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 21 Jan 2026 20:30:28 GMT Subject: RFR: 8286258: [Accessibility, macOS, VoiceOver] VoiceOver reads the spinner value wrong and sometime partially [v2] In-Reply-To: References: Message-ID: > The issue with the announcement of the custom spin boxes is that the text field inside when the value is being changed by the spinbox data model generates some events that are being interpreted by the accessibility subsystem as if text is being actively edited and the system tries to announce it accordingly. In order to stop it from happening we are going to generate correct events and temporarily suppress the text field's methods that reporting the editing-related changes until the actual editing is happened. > > Make embedded text field not to generate random edit-related events; > Add manual test case; Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Restored accidentally damaged copyright header; Removed NSAccessibilityAnnouncementRequestedNotification ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29235/files - new: https://git.openjdk.org/jdk/pull/29235/files/1626eb27..81648a2e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29235&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29235&range=00-01 Stats: 2 lines in 2 files changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29235.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29235/head:pull/29235 PR: https://git.openjdk.org/jdk/pull/29235 From kizune at openjdk.org Wed Jan 21 20:46:47 2026 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 21 Jan 2026 20:46:47 GMT Subject: RFR: 8373931: Test javax/sound/sampled/Clip/AutoCloseTimeCheck.java timed out In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 19:12:10 GMT, Phil Race wrote: > This test needs the jtreg tag "@key sound" so that it can be properly directed to run only on systems with sound support. Marked as reviewed by kizune (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29353#pullrequestreview-3689331456 From prr at openjdk.org Wed Jan 21 21:09:36 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 21 Jan 2026 21:09:36 GMT Subject: RFR: 8373931: Test javax/sound/sampled/Clip/AutoCloseTimeCheck.java timed out In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 19:12:10 GMT, Phil Race wrote: > This test needs the jtreg tag "@key sound" so that it can be properly directed to run only on systems with sound support. T > This test validates the functionality of SoundClip, which stated in the spec: > > ``` > * if the implementation does not find a suitable output device for the data, > * playing the clip will be a no-op. > ``` > > So if it hangs then it is a product bug. That's not exactly the problem. The hang is intermittent. Run often but fails only sometimes, and always on an OL VM I'm looking at logs where a particular VM exhibited the hang 2 days ago but not long before that the test passed in a different run on that same VM in just 35 seconds, no problems. A hang one in 100 times doesn't sound like much until you know that it can get run 20 times a day .. so every few days you have a failure. Those numbers aren't exact but are in the ball park. I also think it doesn't help that without the sound keyword the test can be run concurrently with other (sound) tests. Which means there's perhaps others that might theoretically need the keyword too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29353#issuecomment-3781164981 From prr at openjdk.org Wed Jan 21 21:26:18 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 21 Jan 2026 21:26:18 GMT Subject: RFR: 4197755: Arc2D.getBounds() returns an unnecessarily large bounding box [v2] In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 17:17:54 GMT, Phil Race wrote: > > I'm not very familiar with CSR's, so please let me know if this needs improvement/rewriting: https://bugs.openjdk.org/browse/JDK-8374859 > > I've modified it and marked it as reviewed. You may now "finalize" it - ie move it to the finalized state. @mickleness you can finalize the CSR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26715#issuecomment-3781230313 From serb at openjdk.org Thu Jan 22 00:57:32 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 22 Jan 2026 00:57:32 GMT Subject: RFR: 8373626: [asan] read past end of buffer in sun.awt.image.ImagingLib.convolveBI [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 18:48:58 GMT, Phil Race wrote: >> Some of the medialib native functions implementing Convolve read data from arrays when it is not needed or used instead of reading just what is needed and used. >> This is detected as a read out of bounds. It is limited and hasn't been seen to result in any crashes without ASAN, and the OOB values that are read are never used so there's a very limited problem. >> The changes here make the mlib_ImageConv_*nw.c files match what happens in the mlib_ImageConv_*ext.c files which read just the data they need. >> The changes are fairly mechanical but there could be copy/paste errors for a reviewer to find. >> >> Not easy to provide a test case, building with --enable-asan is needed and for me it works only on macOS. >> I did that and ran all our existing automated tests on our CI systems. > > Phil Race 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 > - 8373626 src/java.desktop/share/native/libmlib_image/mlib_ImageConv_D64nw.c line 223: > 221: p2 = sp[0]; > 222: > 223: sp += 2*sll; Is this a copypaste error? The sp is incremented twice in a row? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29257#discussion_r2714908645 From psadhukhan at openjdk.org Thu Jan 22 01:33:23 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 22 Jan 2026 01:33:23 GMT Subject: RFR: 8373239: Test java/awt/print/PrinterJob/PageRanges.java fails with incorrect selection of printed pages [v3] In-Reply-To: <5oA_LmiQ1TSkLJ-VLMGGHfINhmyMnMGUq1vAeHs6avk=.2a1fadcb-b397-4dd7-ba89-7c6842c2ef5e@github.com> References: <7V3UT7_3iCEk6MDbvc7DHJo4gt013_GpkwApQSAVisk=.cb6f417c-79d7-4df2-babf-83c756a11178@github.com> <5oA_LmiQ1TSkLJ-VLMGGHfINhmyMnMGUq1vAeHs6avk=.2a1fadcb-b397-4dd7-ba89-7c6842c2ef5e@github.com> Message-ID: On Wed, 21 Jan 2026 18:32:25 GMT, Phil Race wrote: >> Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: >> >> - Merge master >> - Merge master >> - Remove PageRange attribute if range is not set >> - 8373239: Test java/awt/print/PrinterJob/PageRanges.java fails with incorrect selection of printed pages > > src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java line 1737: > >> 1735: setPageRange(from, to); >> 1736: } else { >> 1737: attributes.remove(PageRanges.class); > > I'm a bit surprised you didn't need to still reset the page range ... is something else re-setting it ? > setPageRange(Pageable.UNKNOWN_NUMBER_OF_PAGES, Pageable.UNKNOWN_NUMBER_OF_PAGES) Once PageRanges attribute is removed, the From/To Page range is not used As seen from the code read from native, it checks if pageRange attribute is null or not and then read the range and since we are deleting it, the `pageRangesAttr ` will be null. protected final int getFromPageAttrib() { if (attributes != null) { PageRanges pageRangesAttr = (PageRanges)attributes.get(PageRanges.class); if (pageRangesAttr != null) { int[][] range = pageRangesAttr.getMembers(); return range[0][0]; } } return getMinPageAttrib(); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29312#discussion_r2714979573 From psadhukhan at openjdk.org Thu Jan 22 02:41:34 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 22 Jan 2026 02:41:34 GMT Subject: RFR: 8375480: Remove usage of AppContext from javax/swing/text [v2] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:25:24 GMT, Phil Race wrote: >> This PR removes usage of AppContext from classes under javax/swing/text. >> Most of the uses were added in specific bug fixes 10-15 years ago but are now obsolete and the tests for those bugs need to be deleted too. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8375350 Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29259#pullrequestreview-3690314413 From psadhukhan at openjdk.org Thu Jan 22 02:51:54 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 22 Jan 2026 02:51:54 GMT Subject: RFR: 8286258: [Accessibility, macOS, VoiceOver] VoiceOver reads the spinner value wrong and sometime partially [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 20:30:28 GMT, Alexander Zuev wrote: >> The issue with the announcement of the custom spin boxes is that the text field inside when the value is being changed by the spinbox data model generates some events that are being interpreted by the accessibility subsystem as if text is being actively edited and the system tries to announce it accordingly. In order to stop it from happening we are going to generate correct events and temporarily suppress the text field's methods that reporting the editing-related changes until the actual editing is happened. >> >> Make embedded text field not to generate random edit-related events; >> Add manual test case; > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Restored accidentally damaged copyright header; > Removed NSAccessibilityAnnouncementRequestedNotification Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29235#pullrequestreview-3690340086 From psadhukhan at openjdk.org Thu Jan 22 07:18:22 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 22 Jan 2026 07:18:22 GMT Subject: RFR: 8375573: JTable ignores setPreferredWidth during initial layout when AUTO_RESIZE_LAST_COLUMN is enabled In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 06:36:30 GMT, Tejesh R wrote: >> Because default width is such and there is no way to ascertain default width.. >> https://github.com/openjdk/jdk/blob/b5727d27622e1e321733f8d0e606b366984104be/src/java.desktop/share/classes/javax/swing/table/TableColumn.java#L523-L524 >> >> https://github.com/openjdk/jdk/blob/b5727d27622e1e321733f8d0e606b366984104be/src/java.desktop/share/classes/javax/swing/table/TableColumn.java#L556-L557 > > Got it, it's been set here - https://github.com/openjdk/jdk/blob/b5727d27622e1e321733f8d0e606b366984104be/src/java.desktop/share/classes/javax/swing/table/TableColumn.java#L211 @TejeshR13 any other comments? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29291#discussion_r2715618064 From asemenov at openjdk.org Thu Jan 22 08:55:17 2026 From: asemenov at openjdk.org (Artem Semenov) Date: Thu, 22 Jan 2026 08:55:17 GMT Subject: RFR: 8286258: [Accessibility, macOS, VoiceOver] VoiceOver reads the spinner value wrong and sometime partially [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 20:30:28 GMT, Alexander Zuev wrote: >> The issue with the announcement of the custom spin boxes is that the text field inside when the value is being changed by the spinbox data model generates some events that are being interpreted by the accessibility subsystem as if text is being actively edited and the system tries to announce it accordingly. In order to stop it from happening we are going to generate correct events and temporarily suppress the text field's methods that reporting the editing-related changes until the actual editing is happened. >> >> Make embedded text field not to generate random edit-related events; >> Add manual test case; > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Restored accidentally damaged copyright header; > Removed NSAccessibilityAnnouncementRequestedNotification LGTM ------------- Marked as reviewed by asemenov (Committer). PR Review: https://git.openjdk.org/jdk/pull/29235#pullrequestreview-3691291297 From tr at openjdk.org Thu Jan 22 10:28:34 2026 From: tr at openjdk.org (Tejesh R) Date: Thu, 22 Jan 2026 10:28:34 GMT Subject: RFR: 8375573: JTable ignores setPreferredWidth during initial layout when AUTO_RESIZE_LAST_COLUMN is enabled In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 02:18:06 GMT, Prasanta Sadhukhan wrote: > AUTO_RESIZE_LAST_COLUMN handling was done in [JDK-8234071](https://bugs.openjdk.org/browse/JDK-8234071) but it didn't honour the preferred width if it is already been set for each column so when layouting is done, it only sees the `resizingColumn` > is set to AUTO_RESIZE_LAST_COLUMN and adjust only the last column and distribute width equally to all other column. > > Fix is made to honour the user-set preferred column width even if auto-resize mode is set to LAST_COLUMN src/java.desktop/share/classes/javax/swing/JTable.java line 3206: > 3204: if (columnModel.getColumn(i).getPreferredWidth() != 75 > 3205: && columnModel.getColumn(i).getWidth() == 75) { > 3206: prefWidthSet = true; Can break the loop for first true condition instead of iterating through all the columns ? test/jdk/javax/swing/JTable/TestJTableColWidth.java line 81: > 79: } > 80: } finally { > 81: if (frame != null) { Normally we do this inside EDT. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29291#discussion_r2716258542 PR Review Comment: https://git.openjdk.org/jdk/pull/29291#discussion_r2716261586 From kizune at openjdk.org Thu Jan 22 16:39:55 2026 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 22 Jan 2026 16:39:55 GMT Subject: Integrated: 8286258: [Accessibility, macOS, VoiceOver] VoiceOver reads the spinner value wrong and sometime partially In-Reply-To: References: Message-ID: <5uI1z7osa10hty7FJV2WxQ5qCzsjR48yBPYE6bnQKCo=.48704de9-7307-4c0d-8628-f3c82bea774b@github.com> On Wed, 14 Jan 2026 20:18:08 GMT, Alexander Zuev wrote: > The issue with the announcement of the custom spin boxes is that the text field inside when the value is being changed by the spinbox data model generates some events that are being interpreted by the accessibility subsystem as if text is being actively edited and the system tries to announce it accordingly. In order to stop it from happening we are going to generate correct events and temporarily suppress the text field's methods that reporting the editing-related changes until the actual editing is happened. > > Make embedded text field not to generate random edit-related events; > Add manual test case; This pull request has now been integrated. Changeset: 8c82b58d Author: Alexander Zuev URL: https://git.openjdk.org/jdk/commit/8c82b58db960a178566514731e1f8dcbc59b0161 Stats: 139 lines in 4 files changed: 135 ins; 0 del; 4 mod 8286258: [Accessibility,macOS,VoiceOver] VoiceOver reads the spinner value wrong and sometime partially Reviewed-by: psadhukhan, asemenov ------------- PR: https://git.openjdk.org/jdk/pull/29235 From prr at openjdk.org Thu Jan 22 17:45:25 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 22 Jan 2026 17:45:25 GMT Subject: RFR: 8375351: Remove usage of AppContext from print implementation [v5] In-Reply-To: References: Message-ID: > Remove AppContext from javax.print Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8375351 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29237/files - new: https://git.openjdk.org/jdk/pull/29237/files/d8897fca..a709bc73 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29237&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29237&range=03-04 Stats: 26 lines in 1 file changed: 0 ins; 18 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29237/head:pull/29237 PR: https://git.openjdk.org/jdk/pull/29237 From prr at openjdk.org Thu Jan 22 17:45:27 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 22 Jan 2026 17:45:27 GMT Subject: RFR: 8375351: Remove usage of AppContext from print implementation [v4] In-Reply-To: <2-b4C7__ksV-bjVFNaXytnpj8j68LSM8Pp9-jOJ-JvY=.5ac1e384-ae39-4ddb-b977-d375b9e98dec@github.com> References: <2-b4C7__ksV-bjVFNaXytnpj8j68LSM8Pp9-jOJ-JvY=.5ac1e384-ae39-4ddb-b977-d375b9e98dec@github.com> Message-ID: <4alCFD1iE1k0YlMkv8n3A0eDsRX4C6kUv-GxJ7oeH4M=.c3ebbc90-d1f3-4c4a-9d78-c578e8c07314@github.com> On Mon, 19 Jan 2026 08:42:34 GMT, Tejesh R wrote: >> src/java.desktop/share/classes/javax/print/PrintServiceLookup.java line 81: >> >>> 79: * @return the services >>> 80: */ >>> 81: private static Services getServices() { >> >> I guess making `Services` constructor as private is missing here ? > >> I guess making `Services` constructor as private is missing here ? As of now it's default in this case. So same as it was before. Doesn't matter. The Services class isn't public. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29237#discussion_r2709875403 From prr at openjdk.org Thu Jan 22 17:45:29 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 22 Jan 2026 17:45:29 GMT Subject: RFR: 8375351: Remove usage of AppContext from print implementation [v4] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 06:42:34 GMT, Prasanta Sadhukhan wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8375351 > > src/java.desktop/share/classes/javax/print/PrintServiceLookup.java line 82: > >> 80: */ >> 81: private static Services getServices() { >> 82: return SERVICES; > > Dont we need to implement singleton instance like this? > > > private static volatile Services SERVICES = null; > private static Services getServices() { > if (SERVICES== null) { > // Synchronized block for thread safety during first creation > synchronized (Services.class) { > if (SERVICES == null) { > SERVICES = new Services(); > } > } > } > return SERVICES; > } No. Because it is a static final. The VM specifically guarantees this as safe. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29237#discussion_r2709872132 From prr at openjdk.org Thu Jan 22 17:45:31 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 22 Jan 2026 17:45:31 GMT Subject: RFR: 8375351: Remove usage of AppContext from print implementation [v4] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 00:01:29 GMT, Sergey Bylokhov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8375351 > > src/java.desktop/share/classes/javax/print/StreamPrintServiceFactory.java line 77: > >> 75: */ >> 76: private static Services getServices() { >> 77: return SERVICES; > > Can SERVICES be eliminated completely? Previously, services acted as a bridge between the client and listOfFactories (via the per-app context). Now there is a 1-to-1 mapping. I had thought of that when doing the fix but I figured it was easier to review if I kept it and just got rid of the AppContext .. but since you are asking for it, I've done it. Please review :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29237#discussion_r2717954996 From prr at openjdk.org Thu Jan 22 17:57:42 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 22 Jan 2026 17:57:42 GMT Subject: RFR: 8373626: [asan] read past end of buffer in sun.awt.image.ImagingLib.convolveBI [v3] In-Reply-To: References: Message-ID: > Some of the medialib native functions implementing Convolve read data from arrays when it is not needed or used instead of reading just what is needed and used. > This is detected as a read out of bounds. It is limited and hasn't been seen to result in any crashes without ASAN, and the OOB values that are read are never used so there's a very limited problem. > The changes here make the mlib_ImageConv_*nw.c files match what happens in the mlib_ImageConv_*ext.c files which read just the data they need. > The changes are fairly mechanical but there could be copy/paste errors for a reviewer to find. > > Not easy to provide a test case, building with --enable-asan is needed and for me it works only on macOS. > I did that and ran all our existing automated tests on our CI systems. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8373626 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29257/files - new: https://git.openjdk.org/jdk/pull/29257/files/d7c258f0..97dc5cba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29257&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29257&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29257.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29257/head:pull/29257 PR: https://git.openjdk.org/jdk/pull/29257 From prr at openjdk.org Thu Jan 22 17:57:45 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 22 Jan 2026 17:57:45 GMT Subject: RFR: 8373626: [asan] read past end of buffer in sun.awt.image.ImagingLib.convolveBI [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 00:54:26 GMT, Sergey Bylokhov wrote: >> Phil Race 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 >> - 8373626 > > src/java.desktop/share/native/libmlib_image/mlib_ImageConv_D64nw.c line 223: > >> 221: p2 = sp[0]; >> 222: >> 223: sp += 2*sll; > > Is this a copypaste error? The sp is incremented twice in a row? Yes, that's the kind of copy/paste error I was worried might slip in. Fixing it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29257#discussion_r2717990856 From prr at openjdk.org Thu Jan 22 20:20:29 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 22 Jan 2026 20:20:29 GMT Subject: Integrated: 8373931: Test javax/sound/sampled/Clip/AutoCloseTimeCheck.java timed out In-Reply-To: References: Message-ID: <7-KbyksvtLdz_5zRnCTriXWc1s8nzfviVQkZgNs31wQ=.2e340f42-1c90-4e53-9f48-89a26e477289@github.com> On Wed, 21 Jan 2026 19:12:10 GMT, Phil Race wrote: > This test needs the jtreg tag "@key sound" so that it can be properly directed to run only on systems with sound support. This pull request has now been integrated. Changeset: f3121d10 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/f3121d10237a933087dde926f83a12ce826cde02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8373931: Test javax/sound/sampled/Clip/AutoCloseTimeCheck.java timed out Reviewed-by: dholmes, dnguyen, kizune ------------- PR: https://git.openjdk.org/jdk/pull/29353 From serb at openjdk.org Thu Jan 22 20:46:54 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 22 Jan 2026 20:46:54 GMT Subject: RFR: 8373931: Test javax/sound/sampled/Clip/AutoCloseTimeCheck.java timed out In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 21:06:44 GMT, Phil Race wrote: >A hang one in 100 times doesn't sound like much until you know that it can get run 20 times a day .. so every few days you have a failure. Those numbers aren't exact but are in the ball park. I do not agree with this approach. Adding the sound keyword to a test that is intended to run on systems with and without audio is the wrong solution. It does not address the underlying problem. Instead, it hides the issue and reduces test coverage. The hang in the "com.sun.media.sound.DirectAudioDevice.nOpen" seems like a generic code path, so it will not help. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29353#issuecomment-3786609620 From prr at openjdk.org Thu Jan 22 21:11:41 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 22 Jan 2026 21:11:41 GMT Subject: RFR: 8375338: sun/awt/image/ImageRepresentation/LUTCompareTest.java fails with -Xcheck:jni Message-ID: ReleasePrimitiveArrayCritical was being passed the wrong arg value so it was not copying back changes from the native array. See more info in the JBS issue. ------------- Commit messages: - 8375338 Changes: https://git.openjdk.org/jdk/pull/29373/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29373&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375338 Stats: 6 lines in 2 files changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29373.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29373/head:pull/29373 PR: https://git.openjdk.org/jdk/pull/29373 From jwood at openjdk.org Thu Jan 22 21:15:58 2026 From: jwood at openjdk.org (Jeremy Wood) Date: Thu, 22 Jan 2026 21:15:58 GMT Subject: RFR: 8303904: [macos]Transparent Windows Paint Wrong (Opaque, Pixelated) w/o Volatile Buffering [v6] In-Reply-To: References: Message-ID: > When "swing.volatileImageBufferEnabled" is false: we were mistakenly using an opaque image at 100% resolution. > > In hindsight the original ticket probably should be split up into two distinct issues: > 1. The window is opaque, so pixels that should be transparent are black. > 2. The window is the wrong resolution. On a 200% resolution monitor it renders as if it were 100% (so it looks pixelated). > > This PR started 2 years ago. I got stuck and abandoned it, and @anass-baya picked it back up again this year: https://github.com/openjdk/jdk/pull/23430/ > > In that PR @mrserb suggested we try to fix this problem in RepaintManager (see https://github.com/openjdk/jdk/pull/23430#discussion_r2089555453 ), so that's what this PR does. > > Also this refactors some existing code (the BackingStoreMultiResolutionImage) from JViewport to wrap a BufferedImage in a smaller (transformed) MultiResolutionImage. Jeremy Wood 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 34 additional commits since the last revision: - Merge branch 'master' into JDK-8303904 # Conflicts: # src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java # src/java.desktop/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java # src/java.desktop/share/classes/javax/swing/JViewport.java - 8303904: Updating copyright year - Merge branch 'master' into JDK-8303904 - Merge branch 'master' into JDK-8303904 - 8303904: comment cleanup - 8303904: designing around imagined edge cases I don't know if these will ever come up in the real world, but since this is critical infrastructure I want to be careful. (A Swing app may become unusable if this code fails.) Concern A: In the event our AffineTransform is a rotation or a flip: Now we'll use the c.createImage(virtualWidth, virtualHeight), which means we fall back to the code we've been using for over a decade. Concern B: In the event our AffineTransform scales to zero, we'll at least make the image 1x1. - 8303904: minor cleanup - 8303904: minor cleanup - 8303904: minor cleanup This makes this method ALWAYS return a BackingStoreMultiResolutionImage, even if the scaled size is the same as the virtual size. (Just because making this method return a BufferedImage OR a BackingStoreMultiResolutionImage seems like an unnecessary level of abstraction; and that could turn into a potential point of confusion for future devs.) - 8303904: use BackingStoreMultiResolutionImage It's functionally the same thing; this is just reusing code (and it avoids the hacky fake image involving getScaledInstance). - ... and 24 more: https://git.openjdk.org/jdk/compare/6f19417b...7dace983 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13196/files - new: https://git.openjdk.org/jdk/pull/13196/files/547b121e..7dace983 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13196&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13196&range=04-05 Stats: 149700 lines in 4537 files changed: 85362 ins; 33342 del; 30996 mod Patch: https://git.openjdk.org/jdk/pull/13196.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13196/head:pull/13196 PR: https://git.openjdk.org/jdk/pull/13196 From serb at openjdk.org Thu Jan 22 21:51:29 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 22 Jan 2026 21:51:29 GMT Subject: RFR: 8375351: Remove usage of AppContext from print implementation [v5] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 17:45:25 GMT, Phil Race wrote: >> Remove AppContext from javax.print > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8375351 src/java.desktop/share/classes/javax/print/PrintServiceLookup.java line 84: > 82: */ > 83: private static ArrayList initListOfLookupServices() { > 84: listOfLookupServices = new ArrayList<>(); Do we save much using this custom lazy created "new ArrayList<>()" now? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29237#discussion_r2718760078 From serb at openjdk.org Thu Jan 22 23:39:52 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 22 Jan 2026 23:39:52 GMT Subject: RFR: 8375338: sun/awt/image/ImageRepresentation/LUTCompareTest.java fails with -Xcheck:jni In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 20:57:53 GMT, Phil Race wrote: > ReleasePrimitiveArrayCritical was being passed the wrong arg value so it was not copying back changes from the native array. See more info in the JBS issue. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29373#pullrequestreview-3695091365 From duke at openjdk.org Thu Jan 22 23:46:55 2026 From: duke at openjdk.org (Michael Bien) Date: Thu, 22 Jan 2026 23:46:55 GMT Subject: RFR: 4938801: The popup does not go when the component is removed [v8] In-Reply-To: References: Message-ID: On Thu, 31 Jul 2025 02:20:45 GMT, Prasanta Sadhukhan wrote: >> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container. >> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation. >> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Rename listener class src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 963: > 961: oldInvoker.removePropertyChangeListener("ancestor", propListener); > 962: } > 963: invoker.addPropertyChangeListener("ancestor", propListener); fyi: this will now throw NPEs on `setInvoker(null)` when it enters this section. (https://github.com/apache/netbeans/issues/9155) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2719059513 From psadhukhan at openjdk.org Fri Jan 23 02:58:26 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 23 Jan 2026 02:58:26 GMT Subject: RFR: 8373239: Test java/awt/print/PrinterJob/PageRanges.java fails with incorrect selection of printed pages [v3] In-Reply-To: References: <7V3UT7_3iCEk6MDbvc7DHJo4gt013_GpkwApQSAVisk=.cb6f417c-79d7-4df2-babf-83c756a11178@github.com> <5oA_LmiQ1TSkLJ-VLMGGHfINhmyMnMGUq1vAeHs6avk=.2a1fadcb-b397-4dd7-ba89-7c6842c2ef5e@github.com> Message-ID: On Thu, 22 Jan 2026 01:30:33 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java line 1737: >> >>> 1735: setPageRange(from, to); >>> 1736: } else { >>> 1737: attributes.remove(PageRanges.class); >> >> I'm a bit surprised you didn't need to still reset the page range ... is something else re-setting it ? >> setPageRange(Pageable.UNKNOWN_NUMBER_OF_PAGES, Pageable.UNKNOWN_NUMBER_OF_PAGES) > > Once PageRanges attribute is removed, the From/To Page range is not used > As seen from the code read from native, it checks if pageRange attribute is null or not and then read the range and since we are deleting it, the `pageRangesAttr ` will be null. > > > protected final int getFromPageAttrib() { > if (attributes != null) { > PageRanges pageRangesAttr = > (PageRanges)attributes.get(PageRanges.class); > if (pageRangesAttr != null) { > int[][] range = pageRangesAttr.getMembers(); > return range[0][0]; > } > } > return getMinPageAttrib(); > } I added one more job to print page range 2-4 after 1st job of printing 2-3 and 2nd job of ALL pages which works so it seems just removing PageRanges attribute is enough and it will recreate PageRanges when range of pages is to be printed.. Let me know if you see any other problem.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29312#discussion_r2719394012 From duke at openjdk.org Fri Jan 23 03:09:29 2026 From: duke at openjdk.org (ANUPAM DEV) Date: Fri, 23 Jan 2026 03:09:29 GMT Subject: RFR: 8375011: OldJTable.java - NullPointerException when columnData is null [v3] In-Reply-To: References: Message-ID: <9Yp11O_HQB3INWuRkV22OIMcgkt7SQpls-fzS99eZBg=.b7812245-8d3f-42df-9940-3418ccc15c8b@github.com> On Mon, 19 Jan 2026 07:02:12 GMT, ANUPAM DEV wrote: >> Hi, >> >> This is a fix for NPE in OldJTable.addColumn >> >> The addColumn method in OldJTable.java was unconditionally calling columnData.toArray(), which caused a NullPointerException when columnData was null (e.g., when called from addColumn(Object, int)). >> >> This commit adds a null check to safe-guard against this NPE, passing null to the underlying DefaultTableModel when columnData is missing. >> >> Kindly review. >> >> Regards, >> Anupam > > ANUPAM DEV has updated the pull request incrementally with one additional commit since the last revision: > > Update full name No, there is no reference of OldJTable in the demo being used anywhere. Moreover, the comment at the beginning says, OldJTable is an unsupported class. If we need to keep that class for future, the above fix should be fine, or we may consider removing the class altogether. Please let me know. Regards, Anupam ------------- PR Comment: https://git.openjdk.org/jdk/pull/29226#issuecomment-3787921851 From psadhukhan at openjdk.org Fri Jan 23 03:26:47 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 23 Jan 2026 03:26:47 GMT Subject: RFR: 8375221: Update code to get PrinterResolution from CUPS/IPP print service [v3] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 18:52:00 GMT, Phil Race wrote: >> Previous to this fix, no resolution was being found via CUPS/IPP and when the test case for printer resolution was falling back to the made up 300dpi setting. With this fix it finds the 600dpi from CUPS/IPP. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8375221 LGTM src/java.desktop/unix/classes/sun/print/AttributeClass.java line 198: > 196: res[2] = (int)bufArray[9]; > 197: } > 198: return res; other files copyright year updated except this so pointing it out.. ------------- Marked as reviewed by psadhukhan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29208#pullrequestreview-3695513237 PR Review Comment: https://git.openjdk.org/jdk/pull/29208#discussion_r2719440086 From psadhukhan at openjdk.org Fri Jan 23 03:31:32 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 23 Jan 2026 03:31:32 GMT Subject: RFR: 8375573: JTable ignores setPreferredWidth during initial layout when AUTO_RESIZE_LAST_COLUMN is enabled [v2] In-Reply-To: References: Message-ID: > AUTO_RESIZE_LAST_COLUMN handling was done in [JDK-8234071](https://bugs.openjdk.org/browse/JDK-8234071) but it didn't honour the preferred width if it is already been set for each column so when layouting is done, it only sees the `resizingColumn` > is set to AUTO_RESIZE_LAST_COLUMN and adjust only the last column and distribute width equally to all other column. > > Fix is made to honour the user-set preferred column width even if auto-resize mode is set to LAST_COLUMN Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Bail out early if prefSize is set for a column ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29291/files - new: https://git.openjdk.org/jdk/pull/29291/files/521aa029..622fc1fb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29291&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29291&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29291.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29291/head:pull/29291 PR: https://git.openjdk.org/jdk/pull/29291 From psadhukhan at openjdk.org Fri Jan 23 03:31:36 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 23 Jan 2026 03:31:36 GMT Subject: RFR: 8375573: JTable ignores setPreferredWidth during initial layout when AUTO_RESIZE_LAST_COLUMN is enabled [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 10:24:10 GMT, Tejesh R wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Bail out early if prefSize is set for a column > > src/java.desktop/share/classes/javax/swing/JTable.java line 3206: > >> 3204: if (columnModel.getColumn(i).getPreferredWidth() != 75 >> 3205: && columnModel.getColumn(i).getWidth() == 75) { >> 3206: prefWidthSet = true; > > Can break the loop for first true condition instead of iterating through all the columns ? Yes, can do..Updated.. > test/jdk/javax/swing/JTable/TestJTableColWidth.java line 81: > >> 79: } >> 80: } finally { >> 81: if (frame != null) { > > Normally we do this inside EDT. its already under EDT ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29291#discussion_r2719444083 PR Review Comment: https://git.openjdk.org/jdk/pull/29291#discussion_r2719445082 From tr at openjdk.org Fri Jan 23 04:47:28 2026 From: tr at openjdk.org (Tejesh R) Date: Fri, 23 Jan 2026 04:47:28 GMT Subject: RFR: 8375573: JTable ignores setPreferredWidth during initial layout when AUTO_RESIZE_LAST_COLUMN is enabled [v2] In-Reply-To: References: Message-ID: <9pFh3DbqXgIuVNy37cN3l9QT9JxwNUJjzEzWhFJFk9o=.2bb38195-2830-45d0-8e3b-0e436624c021@github.com> On Fri, 23 Jan 2026 03:27:29 GMT, Prasanta Sadhukhan wrote: >> test/jdk/javax/swing/JTable/TestJTableColWidth.java line 81: >> >>> 79: } >>> 80: } finally { >>> 81: if (frame != null) { >> >> Normally we do this inside EDT. > > its already under EDT Ok, I see this is in EDT. But now this one will throw `InvocationTargetException` along with `RuntimeException` ? I guess it's better to move out the exception handling outside EDT. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29291#discussion_r2719580094 From psadhukhan at openjdk.org Fri Jan 23 04:52:41 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 23 Jan 2026 04:52:41 GMT Subject: RFR: 8375573: JTable ignores setPreferredWidth during initial layout when AUTO_RESIZE_LAST_COLUMN is enabled [v2] In-Reply-To: <9pFh3DbqXgIuVNy37cN3l9QT9JxwNUJjzEzWhFJFk9o=.2bb38195-2830-45d0-8e3b-0e436624c021@github.com> References: <9pFh3DbqXgIuVNy37cN3l9QT9JxwNUJjzEzWhFJFk9o=.2bb38195-2830-45d0-8e3b-0e436624c021@github.com> Message-ID: <-297d6jjYLJ9DFXJSRgxVsLAlZ2gyHAF-O80t8ykjlY=.be5da529-2ee2-4c41-8546-eda3a93fdb59@github.com> On Fri, 23 Jan 2026 04:44:51 GMT, Tejesh R wrote: >> its already under EDT > > Ok, I see this is in EDT. But now this one will throw `InvocationTargetException` along with `RuntimeException` ? I guess it's better to move out the exception handling outside EDT. Dont think it matters..There are many tests that follows this..throwing exception inside EDT.. additionally it will result in volatile usage of columnCount/width which we can avoid here.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29291#discussion_r2719593617 From tr at openjdk.org Fri Jan 23 05:08:48 2026 From: tr at openjdk.org (Tejesh R) Date: Fri, 23 Jan 2026 05:08:48 GMT Subject: RFR: 8375573: JTable ignores setPreferredWidth during initial layout when AUTO_RESIZE_LAST_COLUMN is enabled [v2] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 03:31:32 GMT, Prasanta Sadhukhan wrote: >> AUTO_RESIZE_LAST_COLUMN handling was done in [JDK-8234071](https://bugs.openjdk.org/browse/JDK-8234071) but it didn't honour the preferred width if it is already been set for each column so when layouting is done, it only sees the `resizingColumn` >> is set to AUTO_RESIZE_LAST_COLUMN and adjust only the last column and distribute width equally to all other column. >> >> Fix is made to honour the user-set preferred column width even if auto-resize mode is set to LAST_COLUMN > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Bail out early if prefSize is set for a column Marked as reviewed by tr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29291#pullrequestreview-3695705474 From psadhukhan at openjdk.org Fri Jan 23 05:20:54 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 23 Jan 2026 05:20:54 GMT Subject: RFR: 8374506: Incorrect positioning of arrow icon in parent JMenu in Windows L&F Message-ID: Arrow icon of JMenuItem in JMenu which is used to invoke the submenu overlaps with the menutext if the text is long. Fix is made to add a gap for arrow icon rect too similar to menu text and accelerator rects ------------- Commit messages: - 8374506: Incorrect positioning of arrow icon in parent JMenu in Windows L&F - 8374506: Incorrect positioning of arrow icon in parent JMenu in Windows L&F - 8374506: Incorrect positioning of arrow icon in parent JMenu in Windows L&F Changes: https://git.openjdk.org/jdk/pull/29375/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29375&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374506 Stats: 102 lines in 2 files changed: 101 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29375/head:pull/29375 PR: https://git.openjdk.org/jdk/pull/29375 From psadhukhan at openjdk.org Fri Jan 23 07:21:52 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 23 Jan 2026 07:21:52 GMT Subject: RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE Message-ID: Invoking `JPopupMenu.setInvoker(null)` causes NPE which is fixed in this PR ------------- Commit messages: - 8376169: JPopupMenu.setInvoker(null) causes NPE Changes: https://git.openjdk.org/jdk/pull/29377/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29377&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376169 Stats: 17 lines in 2 files changed: 5 ins; 2 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/29377.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29377/head:pull/29377 PR: https://git.openjdk.org/jdk/pull/29377 From psadhukhan at openjdk.org Fri Jan 23 12:00:20 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 23 Jan 2026 12:00:20 GMT Subject: RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE [v2] In-Reply-To: References: Message-ID: > Invoking `JPopupMenu.setInvoker(null)` causes NPE which is fixed in this PR Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: 8376169 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29377/files - new: https://git.openjdk.org/jdk/pull/29377/files/c47c5cb0..c78ede27 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29377&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29377&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29377.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29377/head:pull/29377 PR: https://git.openjdk.org/jdk/pull/29377 From aivanov at openjdk.org Fri Jan 23 13:41:18 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 23 Jan 2026 13:41:18 GMT Subject: RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE [v2] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 12:00:20 GMT, Prasanta Sadhukhan wrote: >> Invoking `JPopupMenu.setInvoker(null)` causes NPE which is fixed in this PR > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > 8376169 Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 957: > 955: if (invoker != null) { > 956: Component oldInvoker = this.invoker; > 957: this.invoker = invoker; This doesn't look right to me. Is `this.invoker == null` an invalid state? I believe the only thing that requires to be guarded by `if (invoker != null)` is `invoker.addPropertyChangeListener`; maybe `ui.installUI(this)`, however, I can't see why the former should be skipped in cases where `invoker` is `null`. test/jdk/javax/swing/JPopupMenu/TestPopupInvoker.java line 114: > 112: if (frame != null) { > 113: frame.dispose(); > 114: } This shouldn't be done in the clean-up code because `popupMenu.setInvoker` may throw NPE. You have to do it in the body of the test. ------------- PR Review: https://git.openjdk.org/jdk/pull/29377#pullrequestreview-3697486686 PR Review Comment: https://git.openjdk.org/jdk/pull/29377#discussion_r2721215627 PR Review Comment: https://git.openjdk.org/jdk/pull/29377#discussion_r2721204197 From aivanov at openjdk.org Fri Jan 23 13:43:47 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 23 Jan 2026 13:43:47 GMT Subject: RFR: 4938801: The popup does not go when the component is removed [v8] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 23:44:25 GMT, Michael Bien wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename listener class > > src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 963: > >> 961: oldInvoker.removePropertyChangeListener("ancestor", propListener); >> 962: } >> 963: invoker.addPropertyChangeListener("ancestor", propListener); > > fyi: this will now throw NPEs on `setInvoker(null)` when it enters this section. (https://github.com/apache/netbeans/issues/9155) Prasanta @prsadhuk created a JBS bug report, [JDK-8376169](https://bugs.openjdk.org/browse/JDK-8376169), the fix for which is being reviewed in #29377. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2721237138 From krk at openjdk.org Fri Jan 23 13:58:44 2026 From: krk at openjdk.org (Kerem Kat) Date: Fri, 23 Jan 2026 13:58:44 GMT Subject: RFR: 8375338: sun/awt/image/ImageRepresentation/LUTCompareTest.java fails with -Xcheck:jni In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 20:57:53 GMT, Phil Race wrote: > ReleasePrimitiveArrayCritical was being passed the wrong arg value so it was not copying back changes from the native array. See more info in the JBS issue. Marked as reviewed by krk (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/29373#pullrequestreview-3697606541 From aivanov at openjdk.org Fri Jan 23 14:20:17 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 23 Jan 2026 14:20:17 GMT Subject: RFR: 8375338: sun/awt/image/ImageRepresentation/LUTCompareTest.java fails with -Xcheck:jni In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 20:57:53 GMT, Phil Race wrote: > ReleasePrimitiveArrayCritical was being passed the wrong arg value so it was not copying back changes from the native array. See more info in the JBS issue. Changes requested by aivanov (Reviewer). test/jdk/sun/awt/image/ImageRepresentation/LUTCompareTest.java line 26: > 24: /* > 25: * @test > 26: * @bug 6570475 Suggestion: * @bug 6570475 8375338 Shouldn't the bug id be added to the list of issues reproduced by this test? ------------- PR Review: https://git.openjdk.org/jdk/pull/29373#pullrequestreview-3697732267 PR Review Comment: https://git.openjdk.org/jdk/pull/29373#discussion_r2721382930 From prr at openjdk.org Fri Jan 23 17:55:26 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Jan 2026 17:55:26 GMT Subject: RFR: 8375338: sun/awt/image/ImageRepresentation/LUTCompareTest.java fails with -Xcheck:jni [v2] In-Reply-To: References: Message-ID: <3SNkwRtoXv8B5BToHERmZckddaRzt8ZGRT5YC-RC8pI=.e7b72e8a-eea2-4fc8-9ce5-783a66400fa9@github.com> > ReleasePrimitiveArrayCritical was being passed the wrong arg value so it was not copying back changes from the native array. See more info in the JBS issue. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8375338 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29373/files - new: https://git.openjdk.org/jdk/pull/29373/files/9e095e65..a0057d04 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29373&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29373&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29373.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29373/head:pull/29373 PR: https://git.openjdk.org/jdk/pull/29373 From prr at openjdk.org Fri Jan 23 17:55:29 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Jan 2026 17:55:29 GMT Subject: RFR: 8375338: sun/awt/image/ImageRepresentation/LUTCompareTest.java fails with -Xcheck:jni [v2] In-Reply-To: References: Message-ID: <-8uu1N3CcgKlWCH-qHdOypD4QJ7QuQNaoa2gFnIQrOA=.bf881851-c0ff-4b98-b192-62d2c70ee598@github.com> On Fri, 23 Jan 2026 14:17:19 GMT, Alexey Ivanov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8375338 > > test/jdk/sun/awt/image/ImageRepresentation/LUTCompareTest.java line 26: > >> 24: /* >> 25: * @test >> 26: * @bug 6570475 > > Suggestion: > > * @bug 6570475 8375338 > > Shouldn't the bug id be added to the list of issues reproduced by this test? done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29373#discussion_r2722242499 From prr at openjdk.org Fri Jan 23 18:22:23 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Jan 2026 18:22:23 GMT Subject: Integrated: 8375221: Update code to get PrinterResolution from CUPS/IPP print service In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 20:51:35 GMT, Phil Race wrote: > Previous to this fix, no resolution was being found via CUPS/IPP and when the test case for printer resolution was falling back to the made up 300dpi setting. With this fix it finds the 600dpi from CUPS/IPP. This pull request has now been integrated. Changeset: e08fb3a9 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/e08fb3a914ac348dc691ae3fc46c6bdbc34faf46 Stats: 141 lines in 4 files changed: 106 ins; 22 del; 13 mod 8375221: Update code to get PrinterResolution from CUPS/IPP print service Reviewed-by: serb, psadhukhan ------------- PR: https://git.openjdk.org/jdk/pull/29208 From prr at openjdk.org Fri Jan 23 18:29:16 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Jan 2026 18:29:16 GMT Subject: RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE [v2] In-Reply-To: References: Message-ID: <_kHjUg6yuIqfSsnRbU05rwOPev6c7vFJyNG2GduH2Rw=.d8a32a50-dfe1-4ba3-b0af-46ba1bd4c61e@github.com> On Fri, 23 Jan 2026 13:34:27 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> 8376169 > > src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 957: > >> 955: if (invoker != null) { >> 956: Component oldInvoker = this.invoker; >> 957: this.invoker = invoker; > > This doesn't look right to me. Is `this.invoker == null` an invalid state? > > I believe the only thing that requires to be guarded by `if (invoker != null)` is `invoker.addPropertyChangeListener`; maybe `ui.installUI(this)`, however, I can't see why the latter should be skipped in cases where `invoker` is `null`. I'm also not sure it is right. It changes from an NPE to a no-op. Before the previous fix as well as with the current code, null will at least do uninstallUI() And because of this bug report it seems people expect null to be valid and presumably do something. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29377#discussion_r2722369832 From aivanov at openjdk.org Fri Jan 23 18:31:19 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 23 Jan 2026 18:31:19 GMT Subject: RFR: 8375338: sun/awt/image/ImageRepresentation/LUTCompareTest.java fails with -Xcheck:jni [v2] In-Reply-To: <3SNkwRtoXv8B5BToHERmZckddaRzt8ZGRT5YC-RC8pI=.e7b72e8a-eea2-4fc8-9ce5-783a66400fa9@github.com> References: <3SNkwRtoXv8B5BToHERmZckddaRzt8ZGRT5YC-RC8pI=.e7b72e8a-eea2-4fc8-9ce5-783a66400fa9@github.com> Message-ID: On Fri, 23 Jan 2026 17:55:26 GMT, Phil Race wrote: >> ReleasePrimitiveArrayCritical was being passed the wrong arg value so it was not copying back changes from the native array. See more info in the JBS issue. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8375338 Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29373#pullrequestreview-3699001112 From prr at openjdk.org Fri Jan 23 18:41:22 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Jan 2026 18:41:22 GMT Subject: RFR: 8375351: Remove usage of AppContext from print implementation [v5] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 21:48:20 GMT, Sergey Bylokhov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8375351 > > src/java.desktop/share/classes/javax/print/PrintServiceLookup.java line 84: > >> 82: */ >> 83: private static ArrayList initListOfLookupServices() { >> 84: listOfLookupServices = new ArrayList<>(); > > Do we save much using this custom lazy created "new ArrayList<>()" now? The cost is minimal but changing this gets into changing some logic in getAllLookupServices() that I didn't want to change in this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29237#discussion_r2722404834 From prr at openjdk.org Fri Jan 23 18:43:30 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Jan 2026 18:43:30 GMT Subject: RFR: 8373239: Test java/awt/print/PrinterJob/PageRanges.java fails with incorrect selection of printed pages [v3] In-Reply-To: References: <7V3UT7_3iCEk6MDbvc7DHJo4gt013_GpkwApQSAVisk=.cb6f417c-79d7-4df2-babf-83c756a11178@github.com> <5oA_LmiQ1TSkLJ-VLMGGHfINhmyMnMGUq1vAeHs6avk=.2a1fadcb-b397-4dd7-ba89-7c6842c2ef5e@github.com> Message-ID: On Fri, 23 Jan 2026 02:55:52 GMT, Prasanta Sadhukhan wrote: >> Once PageRanges attribute is removed, the From/To Page range is not used >> As seen from the code read from native, it checks if pageRange attribute is null or not and then read the range and since we are deleting it, the `pageRangesAttr ` will be null. >> >> >> protected final int getFromPageAttrib() { >> if (attributes != null) { >> PageRanges pageRangesAttr = >> (PageRanges)attributes.get(PageRanges.class); >> if (pageRangesAttr != null) { >> int[][] range = pageRangesAttr.getMembers(); >> return range[0][0]; >> } >> } >> return getMinPageAttrib(); >> } > > I added one more job to print page range 2-4 > after 1st job of printing 2-3 and 2nd job of ALL pages which works so it seems just removing PageRanges attribute is enough and it will recreate PageRanges when range of pages is to be printed.. > Let me know if you see any other problem.. Surely it is safer (and harmless) to reset these even if they aren't read today. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29312#discussion_r2722410387 From prr at openjdk.org Fri Jan 23 18:45:33 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Jan 2026 18:45:33 GMT Subject: RFR: 8372651: Remove unreachable code in sun.awt.geom.AreaOp::calculate In-Reply-To: References: Message-ID: On Thu, 27 Nov 2025 08:58:50 GMT, wb-zjp846396 wrote: > JBS: https://bugs.openjdk.org/browse/JDK-8372651 > > Summary: > - Fix a constant-condition `if` statement in `AreaOp.java` line 160. > - Clean up dead code and clarify control flow. > > Testing: > - No functional modification involved. @wb-zjp846396 this PR is waiting for you to type a comment with the text as below. Please type : ------------- PR Comment: https://git.openjdk.org/jdk/pull/28528#issuecomment-3791747202 From prr at openjdk.org Fri Jan 23 18:52:49 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Jan 2026 18:52:49 GMT Subject: RFR: 8375013: J2DdemoTest.java - Platform default encoding used for process output In-Reply-To: <-LVPS8DoA6A0MQfINvy6CuhpYQKlAb5hvVULUu8wUVg=.6f57bf8a-94e2-4b55-81ca-048308bedf1d@github.com> References: <-LVPS8DoA6A0MQfINvy6CuhpYQKlAb5hvVULUu8wUVg=.6f57bf8a-94e2-4b55-81ca-048308bedf1d@github.com> Message-ID: On Tue, 13 Jan 2026 13:15:00 GMT, ANUPAM DEV wrote: > Hi, > > new String(b, 0, n) looks at the operating system's default locale. If these differ between the build machine and the test runner, tests can fail. > StandardCharsets.UTF_8 is guaranteed to be available on all Java platforms. > > Since "ERROR" and "Exception" are ASCII characters, and ASCII is a subset of UTF-8, this will correctly match the tokens regardless of the underlying platform's obscure defaults. > > Kindly review. > > Regards, > Anupam Are you seeing any actual problems ? The default charset is UTF-8 anyway. I don't see how your change will matter. (https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/String.html#%3Cinit%3E(byte%5B%5D,int,int) Constructs a new String by decoding the specified subarray of bytes using the [default charset] https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/nio/charset/Charset.html#defaultCharset() The default charset is UTF-8 ------------- PR Comment: https://git.openjdk.org/jdk/pull/29190#issuecomment-3791780402 From prr at openjdk.org Fri Jan 23 18:56:59 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Jan 2026 18:56:59 GMT Subject: Integrated: 8375338: sun/awt/image/ImageRepresentation/LUTCompareTest.java fails with -Xcheck:jni In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 20:57:53 GMT, Phil Race wrote: > ReleasePrimitiveArrayCritical was being passed the wrong arg value so it was not copying back changes from the native array. See more info in the JBS issue. This pull request has now been integrated. Changeset: e88edd0b Author: Phil Race URL: https://git.openjdk.org/jdk/commit/e88edd0bc63e0a39f42a6a9e1ced61a79f84ad73 Stats: 7 lines in 2 files changed: 1 ins; 0 del; 6 mod 8375338: sun/awt/image/ImageRepresentation/LUTCompareTest.java fails with -Xcheck:jni Reviewed-by: aivanov, serb, krk ------------- PR: https://git.openjdk.org/jdk/pull/29373 From prr at openjdk.org Fri Jan 23 19:07:25 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Jan 2026 19:07:25 GMT Subject: RFR: 6441373: Editing JTable is not Serializable [v7] In-Reply-To: <-KmQgMxG5nscdqYlEAKRDVsKXVdM-Qcxg57F-wcTB_s=.d543f321-efcb-4274-b2d8-e89bd00469e0@github.com> References: <5MxYeGqkIlIN1t8-Rtql1Do3MsZcYlUUCStmzVYCOio=.5e8b7079-1a4a-4682-9416-78b26a8603b1@github.com> <-KmQgMxG5nscdqYlEAKRDVsKXVdM-Qcxg57F-wcTB_s=.d543f321-efcb-4274-b2d8-e89bd00469e0@github.com> Message-ID: On Fri, 9 Jan 2026 08:42:44 GMT, Prasanta Sadhukhan wrote: >>>This is done before deserialization process kicks in via readFields() so JTable is not reconstructed yet from serialized object, so I think it's alright to do this at this step to remove the rogue components not cleaned up. >> >> That call simply drops all subcomponents added by the App to the JTable before serialization, right? >> >>>Alternatively, we can just fix the serialization exception issue as mentioned in the JBS report and >> handle this leakage issue separately which anyway has not been complained of since Java inception >> >> This is not just a memory leak caused by objects being referenced from uncleaned or suspicious places. It is the accumulation of subcomponents in the JTable after deserialization, so JTable just becomes broken. >> >>>I did not want to jeopardise normal operation for serialization corner case fix.. >> >> The patch attempts to fix the serialization of the "Editing JTable", but the current version produces a broken object. This is not just a corner case, it is a primary case. Leaving all subcomponents to accumulate is not correct, and deleting all of them is also wrong. > >> That call simply drops all subcomponents added by the App to the JTable before serialization, right? > > But JTable is not reconstructed yet so I dont think it matters if we remove the object from pre-serialized instance of JTable..It is going to be reconstructed after this call as I see.. > > If you see issues then please suggest some alternative.. @prsadhuk @TejeshR13 please look at the proposal. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28627#discussion_r2722476901 From prr at openjdk.org Fri Jan 23 19:16:19 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Jan 2026 19:16:19 GMT Subject: Integrated: 8375480: Remove usage of AppContext from javax/swing/text In-Reply-To: References: Message-ID: <5wyI6t4DOBoqJvmHcZc9B9w-H_anEfNfSSV3vyF3DOE=.b63d2261-4c66-453e-ad35-0114935a885a@github.com> On Fri, 16 Jan 2026 01:08:27 GMT, Phil Race wrote: > This PR removes usage of AppContext from classes under javax/swing/text. > Most of the uses were added in specific bug fixes 10-15 years ago but are now obsolete and the tests for those bugs need to be deleted too. This pull request has now been integrated. Changeset: e617ccd5 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/e617ccd529657440eaf20ed68794fea6f6c07fee Stats: 389 lines in 9 files changed: 8 ins; 353 del; 28 mod 8375480: Remove usage of AppContext from javax/swing/text Reviewed-by: serb, psadhukhan ------------- PR: https://git.openjdk.org/jdk/pull/29259 From serb at openjdk.org Fri Jan 23 20:05:30 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 23 Jan 2026 20:05:30 GMT Subject: RFR: 8375351: Remove usage of AppContext from print implementation [v5] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 17:45:25 GMT, Phil Race wrote: >> Remove AppContext from javax.print > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8375351 Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29237#pullrequestreview-3699376327 From prr at openjdk.org Fri Jan 23 20:23:33 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Jan 2026 20:23:33 GMT Subject: Integrated: 8375351: Remove usage of AppContext from print implementation In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 21:43:20 GMT, Phil Race wrote: > Remove AppContext from javax.print This pull request has now been integrated. Changeset: 44b74e16 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/44b74e165e2d3ea79397d6f1ddbef94f51ac56c7 Stats: 58 lines in 3 files changed: 2 ins; 43 del; 13 mod 8375351: Remove usage of AppContext from print implementation Reviewed-by: serb, tr ------------- PR: https://git.openjdk.org/jdk/pull/29237 From prr at openjdk.org Fri Jan 23 21:05:14 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Jan 2026 21:05:14 GMT Subject: RFR: 8376232: Remove AppContext from Swing synth related classes Message-ID: Remove AppContext from Swing's synth related classes. 2 tests that check this code uses AppContext are removed. ------------- Commit messages: - 8376232 Changes: https://git.openjdk.org/jdk/pull/29394/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29394&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376232 Stats: 313 lines in 8 files changed: 6 ins; 283 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/29394.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29394/head:pull/29394 PR: https://git.openjdk.org/jdk/pull/29394 From dnguyen at openjdk.org Fri Jan 23 22:02:37 2026 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 23 Jan 2026 22:02:37 GMT Subject: RFR: 8376151: Test javax/swing/JFileChooser/4966171/bug4966171.java is failing with OOME Message-ID: This failing test has been untouched for years and has recently started failing with OOME. In addition, the test is failing pretty frequently and causing a lot of noise. It failed on multiple different machines as well. There seems to be a lot of byte arrays that looks like is causing the issue. To increase stability, I have gone ahead and reduced the `endTime` duration from 10 seconds to 5 seconds, which should be enough. I have run the test on all OS's with 100 repeats after the changes and the test passed on all runs. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/29395/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29395&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376151 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29395.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29395/head:pull/29395 PR: https://git.openjdk.org/jdk/pull/29395 From prr at openjdk.org Fri Jan 23 22:43:39 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Jan 2026 22:43:39 GMT Subject: RFR: 8376151: Test javax/swing/JFileChooser/4966171/bug4966171.java is failing with OOME In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 21:56:06 GMT, Damon Nguyen wrote: > This failing test has been untouched for years and has recently started failing with OOME. In addition, the test is failing pretty frequently and causing a lot of noise. It failed on multiple different machines as well. > > There seems to be a lot of byte arrays that looks like is causing the issue. To increase stability, I have gone ahead and reduced the `endTime` duration from 10 seconds to 5 seconds, which should be enough. > > I have run the test on all OS's with 100 repeats after the changes and the test passed on all runs. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29395#pullrequestreview-3700014215 From serb at openjdk.org Sat Jan 24 06:58:59 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 24 Jan 2026 06:58:59 GMT Subject: RFR: 8376151: Test javax/swing/JFileChooser/4966171/bug4966171.java is failing with OOME In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 21:56:06 GMT, Damon Nguyen wrote: >This failing test has been untouched for years and has recently started failing with OOME. If the test hasn?t been changed, does that mean this is a regression in the JDK? > There seems to be a lot of byte arrays that looks like is causing the issue. To increase stability, I have gone ahead and reduced the endTime duration from 10 seconds to 5 seconds, which should be enough. What is the root cause of the OOM? A large number of byte arrays are created because the test serializes and deserializes data, which then must be reclaimed by the GC. If the test fails, there are two possible explanations: either there is a memory leak in swing, or there is a bug in the GC. In both cases, the test should not be updated, since it catches a bug in the product. Instead, the root cause of the issue should be investigated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29395#issuecomment-3794004581 From serb at openjdk.org Sat Jan 24 07:07:52 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 24 Jan 2026 07:07:52 GMT Subject: RFR: 8376232: Remove AppContext from Swing synth related classes In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 20:58:53 GMT, Phil Race wrote: > Remove AppContext from Swing's synth related classes. > 2 tests that check this code uses AppContext are removed. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29394#pullrequestreview-3700906570 From azvegint at openjdk.org Mon Jan 26 15:51:54 2026 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 26 Jan 2026 15:51:54 GMT Subject: RFR: 8376232: Remove AppContext from Swing synth related classes In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 20:58:53 GMT, Phil Race wrote: > Remove AppContext from Swing's synth related classes. > 2 tests that check this code uses AppContext are removed. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29394#pullrequestreview-3706694023 From prr at openjdk.org Mon Jan 26 18:56:49 2026 From: prr at openjdk.org (Phil Race) Date: Mon, 26 Jan 2026 18:56:49 GMT Subject: Integrated: 8376232: Remove AppContext from Swing synth related classes In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 20:58:53 GMT, Phil Race wrote: > Remove AppContext from Swing's synth related classes. > 2 tests that check this code uses AppContext are removed. This pull request has now been integrated. Changeset: c69275dd Author: Phil Race URL: https://git.openjdk.org/jdk/commit/c69275ddfe8c1769ae82b4ba64b2d6d80bbd8683 Stats: 313 lines in 8 files changed: 6 ins; 283 del; 24 mod 8376232: Remove AppContext from Swing synth related classes Reviewed-by: serb, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/29394 From prr at openjdk.org Mon Jan 26 19:33:54 2026 From: prr at openjdk.org (Phil Race) Date: Mon, 26 Jan 2026 19:33:54 GMT Subject: RFR: 8376151: Test javax/swing/JFileChooser/4966171/bug4966171.java is failing with OOME In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 21:56:06 GMT, Damon Nguyen wrote: > This failing test has been untouched for years and has recently started failing with OOME. In addition, the test is failing pretty frequently and causing a lot of noise. It failed on multiple different machines as well. > > There seems to be a lot of byte arrays that looks like is causing the issue. To increase stability, I have gone ahead and reduced the `endTime` duration from 10 seconds to 5 seconds, which should be enough. > > I have run the test on all OS's with 100 repeats after the changes and the test passed on all runs. FWIW I asked a couple of VM/GC people about this as soon as it was observed because nothing changed in Swing around this time. The upshot is that although one G1 fix might have pushed things over the edge, this test was already tottering on the brink. The GC folks noted that if you increased the time, then it would OOM even before the G1 change and that OOME was also observed parallel GC also could cause an OOME. The obvious issue is that we generate a lot of byte[] data and that contributes to it but I think there's a more pertinent reason. Also they pointed out that there are a LOT of sun.awt.EventQueueItems. I took a look and so far as I can tell, this isn't a "leak", its just how JFileChooser works. This is because JFileChooser has FileLoader create file system events when JFileChooser is created. It is batched but even so there's lots of them when you see that the test also serializes / deserializes so it is done multiple times per iteration.I observed about 70 such events for each loop iteration. It seems the EventQueue can't process these events as fast as they are generated, so a back log builds up. And gets worse over time. Eventually because these haven't been processed, they can't be GC'd and we get OOME. Hundreds of thousands, or even millions of JFileChooser instances in a few seconds is not a real scenario. So I think it is quite legitimate to reduce the running time to reduce the likelihood of OOME. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29395#issuecomment-3801244484 From azvegint at openjdk.org Mon Jan 26 21:04:35 2026 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 26 Jan 2026 21:04:35 GMT Subject: RFR: 8376151: Test javax/swing/JFileChooser/4966171/bug4966171.java is failing with OOME In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 21:56:06 GMT, Damon Nguyen wrote: > This failing test has been untouched for years and has recently started failing with OOME. In addition, the test is failing pretty frequently and causing a lot of noise. It failed on multiple different machines as well. > > There seems to be a lot of byte arrays that looks like is causing the issue. To increase stability, I have gone ahead and reduced the `endTime` duration from 10 seconds to 5 seconds, which should be enough. > > I have run the test on all OS's with 100 repeats after the changes and the test passed on all runs. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29395#pullrequestreview-3707982573 From aivanov at openjdk.org Mon Jan 26 21:11:46 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 26 Jan 2026 21:11:46 GMT Subject: RFR: 8376151: Test javax/swing/JFileChooser/4966171/bug4966171.java is failing with OOME In-Reply-To: References: Message-ID: <3NSpVr2T_gQczYPZklCNiLHVhNtJ66xEeYY-zLSn98U=.e9bae82d-77cd-4c97-8d69-0a15c069a4bf@github.com> On Fri, 23 Jan 2026 21:56:06 GMT, Damon Nguyen wrote: > This failing test has been untouched for years and has recently started failing with OOME. In addition, the test is failing pretty frequently and causing a lot of noise. It failed on multiple different machines as well. > > There seems to be a lot of byte arrays that looks like is causing the issue. To increase stability, I have gone ahead and reduced the `endTime` duration from 10 seconds to 5 seconds, which should be enough. > > I have run the test on all OS's with 100 repeats after the changes and the test passed on all runs. Phil's explanation is reasonable, I agree to reduce the running time of the test to avoid ?false? failures. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29395#pullrequestreview-3708010467 From dnguyen at openjdk.org Mon Jan 26 21:16:20 2026 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 26 Jan 2026 21:16:20 GMT Subject: Integrated: 8376151: Test javax/swing/JFileChooser/4966171/bug4966171.java is failing with OOME In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 21:56:06 GMT, Damon Nguyen wrote: > This failing test has been untouched for years and has recently started failing with OOME. In addition, the test is failing pretty frequently and causing a lot of noise. It failed on multiple different machines as well. > > There seems to be a lot of byte arrays that looks like is causing the issue. To increase stability, I have gone ahead and reduced the `endTime` duration from 10 seconds to 5 seconds, which should be enough. > > I have run the test on all OS's with 100 repeats after the changes and the test passed on all runs. This pull request has now been integrated. Changeset: 12570be6 Author: Damon Nguyen URL: https://git.openjdk.org/jdk/commit/12570be64ae2114587e6de4ef79f79be961023b9 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8376151: Test javax/swing/JFileChooser/4966171/bug4966171.java is failing with OOME Reviewed-by: prr, azvegint, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/29395 From prr at openjdk.org Mon Jan 26 21:19:36 2026 From: prr at openjdk.org (Phil Race) Date: Mon, 26 Jan 2026 21:19:36 GMT Subject: RFR: 8375567: Remove AppContext usage from Swing Motif L&F classes [v3] In-Reply-To: References: Message-ID: > Remove AppContext from the Swing Motif L&F implementation. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8375567 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29282/files - new: https://git.openjdk.org/jdk/pull/29282/files/4cfc2c54..dd7b8459 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29282&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29282&range=01-02 Stats: 8 lines in 4 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29282.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29282/head:pull/29282 PR: https://git.openjdk.org/jdk/pull/29282 From prr at openjdk.org Mon Jan 26 21:19:38 2026 From: prr at openjdk.org (Phil Race) Date: Mon, 26 Jan 2026 21:19:38 GMT Subject: RFR: 8375567: Remove AppContext usage from Swing Motif L&F classes [v2] In-Reply-To: References: <1T4-MAD5t_Kq-DpekGy8U_HmPjpMsfqrEm5QkYuwfZ0=.cfa3f70c-a94c-4893-836b-e9c1cb02b344@github.com> Message-ID: On Tue, 20 Jan 2026 23:48:30 GMT, Sergey Bylokhov wrote: >> True that createUI returns a ComponentUI, but the proposed code makes it clear what is the actual type, and the removed code used MotifToggleButtonUI too, even thought it could have used ComponentUI >> No extra cost to this. > >>No extra cost to this. > > The cost is the size of the monitor =( > `private static final ComponentUI INSTANCE = new MotifToggleButtonUI();` > fits well into the 80 chars per line, without loosing much information. And it seems that the object should always be used via createUI method anyway, in this class specifically and in all UI delegates. Really, I don't see the problem, but if you want it shorter, now it is shorter. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29282#discussion_r2729271884 From serb at openjdk.org Mon Jan 26 21:40:07 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 26 Jan 2026 21:40:07 GMT Subject: RFR: 8376151: Test javax/swing/JFileChooser/4966171/bug4966171.java is failing with OOME In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 19:03:21 GMT, Phil Race wrote: >t seems the EventQueue can't process these events as fast as they are generated, so a back log builds up. >And gets worse over time. Eventually because these haven't been processed, they can't be GC'd and we get OOME. Then, instead of changing the execution time, the events should be flushed on the EDT using invokeAndWait or something similar. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29395#issuecomment-3801876339 From serb at openjdk.org Mon Jan 26 21:46:19 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 26 Jan 2026 21:46:19 GMT Subject: RFR: 8376151: Test javax/swing/JFileChooser/4966171/bug4966171.java is failing with OOME In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 21:56:06 GMT, Damon Nguyen wrote: > This failing test has been untouched for years and has recently started failing with OOME. In addition, the test is failing pretty frequently and causing a lot of noise. It failed on multiple different machines as well. > > There seems to be a lot of byte arrays that looks like is causing the issue. To increase stability, I have gone ahead and reduced the `endTime` duration from 10 seconds to 5 seconds, which should be enough. > > I have run the test on all OS's with 100 repeats after the changes and the test passed on all runs. The follow-up ticket [JDK-8376412](https://bugs.openjdk.org/browse/JDK-8376412) has been filed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29395#issuecomment-3801900654 From serb at openjdk.org Mon Jan 26 22:00:49 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 26 Jan 2026 22:00:49 GMT Subject: RFR: 8375567: Remove AppContext usage from Swing Motif L&F classes [v3] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 21:19:36 GMT, Phil Race wrote: >> Remove AppContext from the Swing Motif L&F implementation. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8375567 Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29282#pullrequestreview-3708202141 From prr at openjdk.org Mon Jan 26 23:06:17 2026 From: prr at openjdk.org (Phil Race) Date: Mon, 26 Jan 2026 23:06:17 GMT Subject: RFR: 8376420: Remove AppContext from javax/swing/ImageIcon.java Message-ID: Remove per-AppContext MediaTracker from ImageIcon.java ------------- Commit messages: - 8376420 Changes: https://git.openjdk.org/jdk/pull/29433/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29433&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376420 Stats: 20 lines in 1 file changed: 1 ins; 16 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29433.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29433/head:pull/29433 PR: https://git.openjdk.org/jdk/pull/29433 From serb at openjdk.org Mon Jan 26 23:27:23 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 26 Jan 2026 23:27:23 GMT Subject: RFR: 8376420: Remove AppContext from javax/swing/ImageIcon.java In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 23:00:16 GMT, Phil Race wrote: > Remove per-AppContext MediaTracker from ImageIcon.java src/java.desktop/share/classes/javax/swing/ImageIcon.java line 346: > 344: } > 345: > 346: private static final MediaTracker MEDIA_TRACKER = new MediaTracker(new Component() {}); This actually duplicates an existing declaration: `protected static final MediaTracker tracker = new MediaTracker(component);` I assume it was deprecated in Java 8 because of the AppContext issue? so now we can just uses that one? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29433#discussion_r2729655436 From psadhukhan at openjdk.org Tue Jan 27 03:42:23 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 27 Jan 2026 03:42:23 GMT Subject: RFR: 8373239: Test java/awt/print/PrinterJob/PageRanges.java fails with incorrect selection of printed pages [v4] In-Reply-To: <7V3UT7_3iCEk6MDbvc7DHJo4gt013_GpkwApQSAVisk=.cb6f417c-79d7-4df2-babf-83c756a11178@github.com> References: <7V3UT7_3iCEk6MDbvc7DHJo4gt013_GpkwApQSAVisk=.cb6f417c-79d7-4df2-babf-83c756a11178@github.com> Message-ID: > If same `PrinterJob `is reused to first print user-set `PageRange `pages and then print ALL pages, it prints the first print job correctly as the page range is set but 2nd job doesn't print ALL pages and reprint the same page range as `from` and `to` page are not reset and reused > > Fix is made to check if page range is not set then print all pages Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Reset page range ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29312/files - new: https://git.openjdk.org/jdk/pull/29312/files/6ddd69ec..9eb3a02e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29312&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29312&range=02-03 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29312.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29312/head:pull/29312 PR: https://git.openjdk.org/jdk/pull/29312 From psadhukhan at openjdk.org Tue Jan 27 03:42:23 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 27 Jan 2026 03:42:23 GMT Subject: RFR: 8373239: Test java/awt/print/PrinterJob/PageRanges.java fails with incorrect selection of printed pages [v3] In-Reply-To: References: <7V3UT7_3iCEk6MDbvc7DHJo4gt013_GpkwApQSAVisk=.cb6f417c-79d7-4df2-babf-83c756a11178@github.com> <5oA_LmiQ1TSkLJ-VLMGGHfINhmyMnMGUq1vAeHs6avk=.2a1fadcb-b397-4dd7-ba89-7c6842c2ef5e@github.com> Message-ID: On Fri, 23 Jan 2026 18:40:45 GMT, Phil Race wrote: >> I added one more job to print page range 2-4 >> after 1st job of printing 2-3 and 2nd job of ALL pages which works so it seems just removing PageRanges attribute is enough and it will recreate PageRanges when range of pages is to be printed.. >> Let me know if you see any other problem.. > > Surely it is safer (and harmless) to reset these even if they aren't read today. ok..updated PR.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29312#discussion_r2730099931 From prr at openjdk.org Tue Jan 27 04:17:02 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Jan 2026 04:17:02 GMT Subject: RFR: 8372651: Remove unreachable code in sun.awt.geom.AreaOp::calculate In-Reply-To: References: Message-ID: <8Vov-GzRoHXGRHnJShFNDyzBzbt1gHCZD_2HM4CFveQ=.7f7fc95e-61e5-4b77-84a0-de6de1015cd7@github.com> On Thu, 27 Nov 2025 08:58:50 GMT, wb-zjp846396 wrote: > JBS: https://bugs.openjdk.org/browse/JDK-8372651 > > Summary: > - Fix a constant-condition `if` statement in `AreaOp.java` line 160. > - Clean up dead code and clarify control flow. > > Testing: > - No functional modification involved. @wb-zjp846396 please do as requested above. I'd like this approved PR off the queue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28528#issuecomment-3803009407 From prr at openjdk.org Tue Jan 27 04:56:16 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Jan 2026 04:56:16 GMT Subject: RFR: 8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter Message-ID: AppContext is removed from Swing LAF state. Tests which require it are deleted. ------------- Commit messages: - v - 8376423 - 8376423 Changes: https://git.openjdk.org/jdk/pull/29437/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29437&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376423 Stats: 236 lines in 6 files changed: 36 ins; 192 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29437.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29437/head:pull/29437 PR: https://git.openjdk.org/jdk/pull/29437 From prr at openjdk.org Tue Jan 27 04:56:17 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Jan 2026 04:56:17 GMT Subject: RFR: 8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 04:23:33 GMT, Phil Race wrote: > AppContext is removed from Swing LAF state. Tests which require it are deleted. src/java.desktop/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java line 156: > 154: if (key != WINDOW_TITLE_FONT) { > 155: Object boldMetal = null; > 156: if (SwingAccessor.getLAFStateAccessor().lafStateIsInitialized()) { I'm sceptical that we can ever get here without the L&F initialized, but for now I'd prefer to try to keep the same behaviour. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29437#discussion_r2730191660 From prr at openjdk.org Tue Jan 27 05:22:12 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Jan 2026 05:22:12 GMT Subject: RFR: 8373239: Test java/awt/print/PrinterJob/PageRanges.java fails with incorrect selection of printed pages [v4] In-Reply-To: References: <7V3UT7_3iCEk6MDbvc7DHJo4gt013_GpkwApQSAVisk=.cb6f417c-79d7-4df2-babf-83c756a11178@github.com> Message-ID: <3ZtjqD0Ow9x4i6mcbGv50ZP-pvJ2YO6RtUvXWzlTSN8=.6994034e-1bb0-4684-a493-48dec8d93613@github.com> On Tue, 27 Jan 2026 03:42:23 GMT, Prasanta Sadhukhan wrote: >> If same `PrinterJob `is reused to first print user-set `PageRange `pages and then print ALL pages, it prints the first print job correctly as the page range is set but 2nd job doesn't print ALL pages and reprint the same page range as `from` and `to` page are not reset and reused >> >> Fix is made to check if page range is not set then print all pages > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Reset page range Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29312#pullrequestreview-3709164049 From prr at openjdk.org Tue Jan 27 05:25:05 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Jan 2026 05:25:05 GMT Subject: RFR: 6441373: Editing JTable is not Serializable In-Reply-To: <24EVy67ZyIy7uxUtvIUDB1v-9j1q6vdDl88LoS9K5WY=.37595035-7c7e-4f6e-9554-9276225d608b@github.com> References: <24EVy67ZyIy7uxUtvIUDB1v-9j1q6vdDl88LoS9K5WY=.37595035-7c7e-4f6e-9554-9276225d608b@github.com> Message-ID: On Tue, 20 Jan 2026 09:12:44 GMT, Sergey Bylokhov wrote: > The patch implements serialization for editable JTables. Currently, most classes responsible for JTable editing are not serializable, so trying to serialize them causes an exception. The patch has two parts: > > - The editable JTable is reset to non-editable using the common pattern stopCellEditing + cancelCellEditing. This is added to the compWriteObjectNotify method, which acts as an entry point for serialization of Swing components. It allows actions to be performed before the parent classes are serialized. > > - The editing coordinates for all JTables are reset to -1. Before this patch, even non-editable JTables had their coordinates reset to 0 from -1 because the fields were transient. @prsadhuk @TejeshR13 please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/29313#issuecomment-3803180225 From prr at openjdk.org Tue Jan 27 05:27:10 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Jan 2026 05:27:10 GMT Subject: RFR: 8373626: [asan] read past end of buffer in sun.awt.image.ImagingLib.convolveBI [v3] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 17:57:42 GMT, Phil Race wrote: >> Some of the medialib native functions implementing Convolve read data from arrays when it is not needed or used instead of reading just what is needed and used. >> This is detected as a read out of bounds. It is limited and hasn't been seen to result in any crashes without ASAN, and the OOB values that are read are never used so there's a very limited problem. >> The changes here make the mlib_ImageConv_*nw.c files match what happens in the mlib_ImageConv_*ext.c files which read just the data they need. >> The changes are fairly mechanical but there could be copy/paste errors for a reviewer to find. >> >> Not easy to provide a test case, building with --enable-asan is needed and for me it works only on macOS. >> I did that and ran all our existing automated tests on our CI systems. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8373626 @mrserb I updated last week. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29257#issuecomment-3803184282 From prr at openjdk.org Tue Jan 27 05:37:17 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Jan 2026 05:37:17 GMT Subject: RFR: 8376432: Remove AppContext from sun/swing/DefaultLookup.java Message-ID: Another removal of AppContext in Swing ------------- Commit messages: - 8376432 Changes: https://git.openjdk.org/jdk/pull/29439/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29439&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376432 Stats: 40 lines in 1 file changed: 1 ins; 28 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/29439.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29439/head:pull/29439 PR: https://git.openjdk.org/jdk/pull/29439 From prr at openjdk.org Tue Jan 27 05:42:13 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Jan 2026 05:42:13 GMT Subject: RFR: 8376433: Remove AppContext from Swing Windows L&F implementation Message-ID: Remove AppContext from the Windows L&F implementation ------------- Commit messages: - 8376433 Changes: https://git.openjdk.org/jdk/pull/29440/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29440&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376433 Stats: 66 lines in 6 files changed: 0 ins; 51 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/29440.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29440/head:pull/29440 PR: https://git.openjdk.org/jdk/pull/29440 From prr at openjdk.org Tue Jan 27 05:57:00 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Jan 2026 05:57:00 GMT Subject: RFR: 8374506: Incorrect positioning of arrow icon in parent JMenu in Windows L&F In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 05:11:37 GMT, Prasanta Sadhukhan wrote: > Arrow icon of JMenuItem in JMenu which is used to invoke the submenu overlaps with the menutext if the text is long. > > Fix is made to add a gap for arrow icon rect too similar to menu text and accelerator rects @TejeshR13 @DamonGuy @azuev-java please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/29375#issuecomment-3803259974 From prr at openjdk.org Tue Jan 27 05:58:06 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Jan 2026 05:58:06 GMT Subject: RFR: 8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 04:23:33 GMT, Phil Race wrote: > AppContext is removed from Swing LAF state. Tests which require it are deleted. @prsadhuk @TejeshR13 please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/29437#issuecomment-3803262786 From prr at openjdk.org Tue Jan 27 05:58:02 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Jan 2026 05:58:02 GMT Subject: RFR: 8376433: Remove AppContext from Swing Windows L&F implementation In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 05:35:16 GMT, Phil Race wrote: > Remove AppContext from the Windows L&F implementation @prsadhuk @TejeshR13 please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/29440#issuecomment-3803261898 From prr at openjdk.org Tue Jan 27 05:58:02 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Jan 2026 05:58:02 GMT Subject: RFR: 8376432: Remove AppContext from sun/swing/DefaultLookup.java In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 05:29:21 GMT, Phil Race wrote: > Another removal of AppContext in Swing @prsadhuk @TejeshR13 please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/29439#issuecomment-3803262376 From prr at openjdk.org Tue Jan 27 06:05:03 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Jan 2026 06:05:03 GMT Subject: RFR: 8376420: Remove AppContext from javax/swing/ImageIcon.java In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 23:24:43 GMT, Sergey Bylokhov wrote: >> Remove per-AppContext MediaTracker from ImageIcon.java > > src/java.desktop/share/classes/javax/swing/ImageIcon.java line 346: > >> 344: } >> 345: >> 346: private static final MediaTracker MEDIA_TRACKER = new MediaTracker(new Component() {}); > > This actually duplicates an existing declaration: > `protected static final MediaTracker tracker = new MediaTracker(component);` > I assume it was deprecated in Java 8 because of the AppContext issue? so now we can just uses that one? Not as far as I can see https://hg.openjdk.org/jdk8/jdk8/jdk/rev/54a6e22b749c I think that it was visible to apps was the issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29433#discussion_r2730397737 From serb at openjdk.org Tue Jan 27 06:11:10 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 27 Jan 2026 06:11:10 GMT Subject: RFR: 8376433: Remove AppContext from Swing Windows L&F implementation In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 05:35:16 GMT, Phil Race wrote: > Remove AppContext from the Windows L&F implementation src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/AnimationController.java line 312: > 310: timer.stop(); > 311: UIManager.removePropertyChangeListener(this); > 312: synchronized (AnimationController.class) { Just a note that this synchronization is still needed here (even for the updated version) because getAnimationController checks and returns the shared field instead of a local variable. What about possibility to simplify it(return local var there and volatile on field itself)? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29440#discussion_r2730411162 From prr at openjdk.org Tue Jan 27 06:13:49 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Jan 2026 06:13:49 GMT Subject: RFR: 8376434: Remove AppContext from awt ImageFetcher implementation Message-ID: Remove AppContext from ImageFetcher ------------- Commit messages: - 8376434 Changes: https://git.openjdk.org/jdk/pull/29441/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29441&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376434 Stats: 45 lines in 1 file changed: 2 ins; 27 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/29441.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29441/head:pull/29441 PR: https://git.openjdk.org/jdk/pull/29441 From prr at openjdk.org Tue Jan 27 06:13:49 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Jan 2026 06:13:49 GMT Subject: RFR: 8376434: Remove AppContext from awt ImageFetcher implementation In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 06:06:46 GMT, Phil Race wrote: > Remove AppContext from ImageFetcher @prsadhuk @azvegint please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/29441#issuecomment-3803296380 From prr at openjdk.org Tue Jan 27 06:20:02 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Jan 2026 06:20:02 GMT Subject: RFR: 8376433: Remove AppContext from Swing Windows L&F implementation In-Reply-To: References: Message-ID: <-smXN6MdP_Q_yuepeXo3ydloebr7Y02H7rJf6Rq2G_I=.94ad5363-5949-4f66-9bf5-ec7b3fa4e2fc@github.com> On Tue, 27 Jan 2026 06:08:30 GMT, Sergey Bylokhov wrote: >> Remove AppContext from the Windows L&F implementation > > src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/AnimationController.java line 312: > >> 310: timer.stop(); >> 311: UIManager.removePropertyChangeListener(this); >> 312: synchronized (AnimationController.class) { > > Just a note that this synchronization is still needed here (even for the updated version) because getAnimationController checks and returns the shared field instead of a local variable. What about possibility to simplify it(return local var there and volatile on field itself)? possible. But this change is simpler to understand and not likely to matter performance-wise. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29440#discussion_r2730430931 From psadhukhan at openjdk.org Tue Jan 27 09:49:32 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 27 Jan 2026 09:49:32 GMT Subject: RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE [v3] In-Reply-To: References: Message-ID: <3NeXqnAvhKti4-KGACJHdAV3NSJmbLlyBTBvueTyTms=.76d1ef32-b318-4f88-aeec-8321504de002@github.com> > Invoking `JPopupMenu.setInvoker(null)` causes NPE which is fixed in this PR Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Invoker null check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29377/files - new: https://git.openjdk.org/jdk/pull/29377/files/c78ede27..91151bce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29377&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29377&range=01-02 Stats: 15 lines in 2 files changed: 3 ins; 2 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/29377.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29377/head:pull/29377 PR: https://git.openjdk.org/jdk/pull/29377 From psadhukhan at openjdk.org Tue Jan 27 09:49:34 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 27 Jan 2026 09:49:34 GMT Subject: RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE [v2] In-Reply-To: <_kHjUg6yuIqfSsnRbU05rwOPev6c7vFJyNG2GduH2Rw=.d8a32a50-dfe1-4ba3-b0af-46ba1bd4c61e@github.com> References: <_kHjUg6yuIqfSsnRbU05rwOPev6c7vFJyNG2GduH2Rw=.d8a32a50-dfe1-4ba3-b0af-46ba1bd4c61e@github.com> Message-ID: On Fri, 23 Jan 2026 18:26:20 GMT, Phil Race wrote: >> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 957: >> >>> 955: if (invoker != null) { >>> 956: Component oldInvoker = this.invoker; >>> 957: this.invoker = invoker; >> >> This doesn't look right to me. Is `this.invoker == null` an invalid state? >> >> I believe the only thing that requires to be guarded by `if (invoker != null)` is `invoker.addPropertyChangeListener`; maybe `ui.installUI(this)`, however, I can't see why the latter should be skipped in cases where `invoker` is `null`. > > I'm also not sure it is right. It changes from an NPE to a no-op. > Before the previous fix as well as with the current code, null will at least do uninstallUI() > And because of this bug report it seems people expect null to be valid and presumably do something. I did what I did seeing the spec "the component in which the popup menu is to be displayed" which I construed as the popup menu should be displayed against a component be in JMenu, JLabel, JToolTip etc and it should not be an orphaned popupmenu as I was not sure of its usecase [Even the parent bug that popup doesn't go when component is removed seems to suggest that popup should be tied to a parent] but it seems the implementation can expect a orphaned/standalone popup and show it at set location https://github.com/openjdk/jdk/blob/cba7d88ca427984ebb27a1634aab10a62c9eede1/src/java.desktop/share/classes/javax/swing/JPopupMenu.java#L996-L1014 so I updated the PR accordingly to maintain a status-quo ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29377#discussion_r2731136926 From aivanov at openjdk.org Tue Jan 27 13:24:52 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 27 Jan 2026 13:24:52 GMT Subject: RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE [v3] In-Reply-To: <3NeXqnAvhKti4-KGACJHdAV3NSJmbLlyBTBvueTyTms=.76d1ef32-b318-4f88-aeec-8321504de002@github.com> References: <3NeXqnAvhKti4-KGACJHdAV3NSJmbLlyBTBvueTyTms=.76d1ef32-b318-4f88-aeec-8321504de002@github.com> Message-ID: On Tue, 27 Jan 2026 09:49:32 GMT, Prasanta Sadhukhan wrote: >> Invoking `JPopupMenu.setInvoker(null)` causes NPE which is fixed in this PR > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Invoker null check Now the fix looks good except for a couple of comments that I'd like to get an answer before I approve the PR. src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 970: > 968: invalidate(); > 969: > 970: } Does this newly added blank line right before the closing brace of the method serve any purpose? I'd rather not add it. test/jdk/javax/swing/JPopupMenu/TestPopupInvoker.java line 76: > 74: public void popupMenuWillBecomeInvisible(PopupMenuEvent e) { > 75: popupHidden.countDown(); > 76: popupMenu.setInvoker(null); You may add an assert that `popupMenu.getInvoker()` returns `null`. ------------- PR Review: https://git.openjdk.org/jdk/pull/29377#pullrequestreview-3711145159 PR Review Comment: https://git.openjdk.org/jdk/pull/29377#discussion_r2731967143 PR Review Comment: https://git.openjdk.org/jdk/pull/29377#discussion_r2731979046 From azvegint at openjdk.org Tue Jan 27 15:12:43 2026 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 27 Jan 2026 15:12:43 GMT Subject: RFR: 8376434: Remove AppContext from awt ImageFetcher implementation In-Reply-To: References: Message-ID: <2y7ngZTKuTvhhAtwf2ucQG3uYv4et42MNtvZPhbgeDc=.956ba887-4240-4efc-bf4d-95e4367d5d59@github.com> On Tue, 27 Jan 2026 06:06:46 GMT, Phil Race wrote: > Remove AppContext from ImageFetcher Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29441#pullrequestreview-3711768871 From aivanov at openjdk.org Tue Jan 27 16:34:18 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 27 Jan 2026 16:34:18 GMT Subject: RFR: 8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter In-Reply-To: References: Message-ID: <2cVt2MmRIzxtOeIjyh8GKeimKOsApA_85SmQzErKTlw=.994298c5-4335-4135-891d-536a7c87177b@github.com> On Tue, 27 Jan 2026 04:23:33 GMT, Phil Race wrote: > AppContext is removed from Swing LAF state. Tests which require it are deleted. Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/UIManager.java line 247: > 245: */ > 246: private static LAFState getLAFState() { > 247: return LAF_STATE; I think you still have to use `synchronized (classLock)`, otherwise `LAF_STATE.initialized` in `isLafStateInitialized` could return a stale value. src/java.desktop/share/classes/sun/swing/SwingAccessor.java line 136: > 134: } > 135: > 136: /* Suggestion: /** Should it be javadoc-style comment? src/java.desktop/share/classes/sun/swing/SwingAccessor.java line 137: > 135: > 136: /* > 137: * An accessor for the LAFState class state Suggestion: * An accessor for the LAFState class state. Full stop? src/java.desktop/share/classes/sun/swing/SwingAccessor.java line 152: > 150: > 151: /** > 152: * Retrieve the accessor object for the LAFState class Suggestion: * Retrieve the accessor object for the LAFState class. Full stop? ------------- PR Review: https://git.openjdk.org/jdk/pull/29437#pullrequestreview-3712170748 PR Review Comment: https://git.openjdk.org/jdk/pull/29437#discussion_r2732859461 PR Review Comment: https://git.openjdk.org/jdk/pull/29437#discussion_r2732823443 PR Review Comment: https://git.openjdk.org/jdk/pull/29437#discussion_r2732824817 PR Review Comment: https://git.openjdk.org/jdk/pull/29437#discussion_r2732826199 From prr at openjdk.org Tue Jan 27 18:13:14 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Jan 2026 18:13:14 GMT Subject: RFR: 8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter In-Reply-To: <2cVt2MmRIzxtOeIjyh8GKeimKOsApA_85SmQzErKTlw=.994298c5-4335-4135-891d-536a7c87177b@github.com> References: <2cVt2MmRIzxtOeIjyh8GKeimKOsApA_85SmQzErKTlw=.994298c5-4335-4135-891d-536a7c87177b@github.com> Message-ID: On Tue, 27 Jan 2026 16:31:23 GMT, Alexey Ivanov wrote: >> AppContext is removed from Swing LAF state. Tests which require it are deleted. > > src/java.desktop/share/classes/javax/swing/UIManager.java line 247: > >> 245: */ >> 246: private static LAFState getLAFState() { >> 247: return LAF_STATE; > > I think you still have to use `synchronized (classLock)`, otherwise `LAF_STATE.initialized` in `isLafStateInitialized` could return a stale value. The existing code only used that when creating the instance, not when retrieving an already created instance, so I don't see why we'd need to extend the lock to the retrieval. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29437#discussion_r2733242279 From prr at openjdk.org Tue Jan 27 18:19:25 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Jan 2026 18:19:25 GMT Subject: RFR: 8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter [v2] In-Reply-To: References: Message-ID: > AppContext is removed from Swing LAF state. Tests which require it are deleted. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8376423 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29437/files - new: https://git.openjdk.org/jdk/pull/29437/files/66c7d41b..8dcdc6fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29437&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29437&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29437.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29437/head:pull/29437 PR: https://git.openjdk.org/jdk/pull/29437 From prr at openjdk.org Tue Jan 27 18:19:29 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Jan 2026 18:19:29 GMT Subject: RFR: 8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter [v2] In-Reply-To: <2cVt2MmRIzxtOeIjyh8GKeimKOsApA_85SmQzErKTlw=.994298c5-4335-4135-891d-536a7c87177b@github.com> References: <2cVt2MmRIzxtOeIjyh8GKeimKOsApA_85SmQzErKTlw=.994298c5-4335-4135-891d-536a7c87177b@github.com> Message-ID: <71c38c79E7G1i5kuUPYaTk1cUmOEr4CO0ngJ3KZgxRI=.08c351ec-aca1-4688-9777-6d470a87ef5d@github.com> On Tue, 27 Jan 2026 16:22:39 GMT, Alexey Ivanov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8376423 > > src/java.desktop/share/classes/sun/swing/SwingAccessor.java line 136: > >> 134: } >> 135: >> 136: /* > > Suggestion: > > /** > > Should it be javadoc-style comment? I don't think it matters and there's inconsistency in the other interfaces, but I can add a "*" > src/java.desktop/share/classes/sun/swing/SwingAccessor.java line 137: > >> 135: >> 136: /* >> 137: * An accessor for the LAFState class state > > Suggestion: > > * An accessor for the LAFState class state. > > Full stop? also inconsistent. > src/java.desktop/share/classes/sun/swing/SwingAccessor.java line 152: > >> 150: >> 151: /** >> 152: * Retrieve the accessor object for the LAFState class > > Suggestion: > > * Retrieve the accessor object for the LAFState class. > > Full stop? ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29437#discussion_r2733251777 PR Review Comment: https://git.openjdk.org/jdk/pull/29437#discussion_r2733255153 PR Review Comment: https://git.openjdk.org/jdk/pull/29437#discussion_r2733259871 From prr at openjdk.org Tue Jan 27 19:13:35 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Jan 2026 19:13:35 GMT Subject: RFR: 8376510: Raster.createBandedRaster(int, int, int, int, int[], int[], Point) does not check for negative scanlineStride Message-ID: We specify that scanlineStride < 0 will throw IAE, but it was not checked up front in all cases, so sometimes would be IAE and sometimes NegativeArrayIndexException. Add an explicit check. ------------- Commit messages: - 8376510 Changes: https://git.openjdk.org/jdk/pull/29454/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29454&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376510 Stats: 7 lines in 2 files changed: 3 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29454.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29454/head:pull/29454 PR: https://git.openjdk.org/jdk/pull/29454 From kizune at openjdk.org Tue Jan 27 20:35:05 2026 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 27 Jan 2026 20:35:05 GMT Subject: RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE [v3] In-Reply-To: <3NeXqnAvhKti4-KGACJHdAV3NSJmbLlyBTBvueTyTms=.76d1ef32-b318-4f88-aeec-8321504de002@github.com> References: <3NeXqnAvhKti4-KGACJHdAV3NSJmbLlyBTBvueTyTms=.76d1ef32-b318-4f88-aeec-8321504de002@github.com> Message-ID: On Tue, 27 Jan 2026 09:49:32 GMT, Prasanta Sadhukhan wrote: >> Invoking `JPopupMenu.setInvoker(null)` causes NPE which is fixed in this PR > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Invoker null check Marked as reviewed by kizune (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29377#pullrequestreview-3713335845 From kizune at openjdk.org Tue Jan 27 20:35:07 2026 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 27 Jan 2026 20:35:07 GMT Subject: RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE [v3] In-Reply-To: References: <3NeXqnAvhKti4-KGACJHdAV3NSJmbLlyBTBvueTyTms=.76d1ef32-b318-4f88-aeec-8321504de002@github.com> Message-ID: On Tue, 27 Jan 2026 13:22:06 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Invoker null check > > Now the fix looks good except for a couple of comments that I'd like to get an answer before I approve the PR. Looks good aside of the minor issues pointed out by @aivanov-jdk ------------- PR Comment: https://git.openjdk.org/jdk/pull/29377#issuecomment-3807399862 From aivanov at openjdk.org Tue Jan 27 20:51:50 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 27 Jan 2026 20:51:50 GMT Subject: RFR: 8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter [v2] In-Reply-To: References: <2cVt2MmRIzxtOeIjyh8GKeimKOsApA_85SmQzErKTlw=.994298c5-4335-4135-891d-536a7c87177b@github.com> Message-ID: On Tue, 27 Jan 2026 18:09:57 GMT, Phil Race wrote: >> src/java.desktop/share/classes/javax/swing/UIManager.java line 247: >> >>> 245: */ >>> 246: private static LAFState getLAFState() { >>> 247: return LAF_STATE; >> >> I think you still have to use `synchronized (classLock)`, otherwise `LAF_STATE.initialized` in `isLafStateInitialized` could return a stale value. > > The existing code only used that when creating the instance, not when retrieving an already created instance, so I don't see why we'd need to extend the lock to the retrieval. Indeed, the existing code use the lock only when creating the instance. Yet there are quite a few places where `synchronized (classLock)` is used. In particular, `maybeInitialize` method. https://github.com/openjdk/jdk/blob/eb6e74b1fa794bf16f572d5dbce157d1cae4c505/src/java.desktop/share/classes/javax/swing/UIManager.java#L1461-L1468 The logic in `maybeInitialize` will remain thread-safe, yet `SwingAccessor.isLafStateInitialized` can return a stale value of `false`. Thus, `SwingAccessor.getLAFStateAccessor().lafStateIsInitialized()` in `DefaultMetalTheme` can return `false` even after `UIManager` was initialised. I guess this problem existed in the original code, too. To ensure thread-safe access to the `initialized` flag, the method `UIManager.isLafStateInitialized` has to access the flag inside the `synchronized (classLock)` block. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29437#discussion_r2733775328 From prr at openjdk.org Tue Jan 27 21:14:47 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Jan 2026 21:14:47 GMT Subject: RFR: 8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter [v3] In-Reply-To: References: Message-ID: <8bBXkiJAJAIxN_v13DKjGdVrQGYqiBWrP83z929xEr4=.e30fa39a-db22-4c2f-b453-a7e5180030be@github.com> > AppContext is removed from Swing LAF state. Tests which require it are deleted. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8376423 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29437/files - new: https://git.openjdk.org/jdk/pull/29437/files/8dcdc6fa..aeef9323 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29437&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29437&range=01-02 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29437.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29437/head:pull/29437 PR: https://git.openjdk.org/jdk/pull/29437 From aivanov at openjdk.org Tue Jan 27 21:14:47 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 27 Jan 2026 21:14:47 GMT Subject: RFR: 8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter [v3] In-Reply-To: <8bBXkiJAJAIxN_v13DKjGdVrQGYqiBWrP83z929xEr4=.e30fa39a-db22-4c2f-b453-a7e5180030be@github.com> References: <8bBXkiJAJAIxN_v13DKjGdVrQGYqiBWrP83z929xEr4=.e30fa39a-db22-4c2f-b453-a7e5180030be@github.com> Message-ID: On Tue, 27 Jan 2026 21:11:03 GMT, Phil Race wrote: >> AppContext is removed from Swing LAF state. Tests which require it are deleted. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8376423 Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29437#pullrequestreview-3713470478 From prr at openjdk.org Tue Jan 27 21:14:48 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Jan 2026 21:14:48 GMT Subject: RFR: 8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter [v3] In-Reply-To: References: <2cVt2MmRIzxtOeIjyh8GKeimKOsApA_85SmQzErKTlw=.994298c5-4335-4135-891d-536a7c87177b@github.com> Message-ID: On Tue, 27 Jan 2026 20:49:05 GMT, Alexey Ivanov wrote: >> The existing code only used that when creating the instance, not when retrieving an already created instance, so I don't see why we'd need to extend the lock to the retrieval. > > Indeed, the existing code use the lock only when creating the instance. > > Yet there are quite a few places where `synchronized (classLock)` is used. In particular, `maybeInitialize` method. > > https://github.com/openjdk/jdk/blob/eb6e74b1fa794bf16f572d5dbce157d1cae4c505/src/java.desktop/share/classes/javax/swing/UIManager.java#L1461-L1468 > > The logic in `maybeInitialize` will remain thread-safe, yet `SwingAccessor.isLafStateInitialized` can return a stale value of `false`. Thus, `SwingAccessor.getLAFStateAccessor().lafStateIsInitialized()` in `DefaultMetalTheme` can return `false` even after `UIManager` was initialised. I guess this problem existed in the original code, too. > > To ensure thread-safe access to the `initialized` flag, the method `UIManager.isLafStateInitialized` has to access the flag inside the `synchronized (classLock)` block. OK. I've updated it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29437#discussion_r2733831629 From aivanov at openjdk.org Tue Jan 27 21:23:45 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 27 Jan 2026 21:23:45 GMT Subject: RFR: 8373239: Test java/awt/print/PrinterJob/PageRanges.java fails with incorrect selection of printed pages [v4] In-Reply-To: References: <7V3UT7_3iCEk6MDbvc7DHJo4gt013_GpkwApQSAVisk=.cb6f417c-79d7-4df2-babf-83c756a11178@github.com> Message-ID: On Tue, 27 Jan 2026 03:42:23 GMT, Prasanta Sadhukhan wrote: >> If same `PrinterJob `is reused to first print user-set `PageRange `pages and then print ALL pages, it prints the first print job correctly as the page range is set but 2nd job doesn't print ALL pages and reprint the same page range as `from` and `to` page are not reset and reused >> >> Fix is made to check if page range is not set then print all pages > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Reset page range Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29312#pullrequestreview-3713512792 From aivanov at openjdk.org Tue Jan 27 22:25:02 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 27 Jan 2026 22:25:02 GMT Subject: RFR: 8374506: Incorrect positioning of arrow icon in parent JMenu in Windows L&F In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 05:11:37 GMT, Prasanta Sadhukhan wrote: > Arrow icon of JMenuItem in JMenu which is used to invoke the submenu overlaps with the menutext if the text is long. > > Fix is made to add a gap for arrow icon rect too similar to menu text and accelerator rects I'm not completely against this as an *interim* fix? Yet the submenu arrow now is nearly at the very edge of the menu ? there has to be a margin. When the submenu opens, it now covers the arrow, but it shouldn't. At least this is how it looks in native Win32 applications. This fix is yet another patch to fit more information into the same amount of space. The underlying problem remains unaddressed. In the fix for [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760) in #23324, you **added** *another column* into Windows L&F menu layout, but you didn't increase the width of the menu to accommodate for the new column. Instead, you're trying to tweak coordinates of each element in the menu layout to fit more information into the same space. I keep saying since that initial code review for #23324, for example [here](https://github.com/openjdk/jdk/pull/23324#issuecomment-3008665338), and I repeat it here: > *The popup menu has to become wider if both check marks / bullets and icons are rendered at the same time.* Unless you make the menu wider to accommodate the newly added column, the menu looks crammed with inconsistent margins between elements. ------------- PR Review: https://git.openjdk.org/jdk/pull/29375#pullrequestreview-3713721845 From prr at openjdk.org Tue Jan 27 23:10:48 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Jan 2026 23:10:48 GMT Subject: RFR: 8376297: ArrayIndexOutOfBoundsException Not Documented for SinglePixelPackedSampleModel.getSampleSize(int) Message-ID: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com> Update the specification of concrete SampleModel classes which over-ride getSampleSize(int band) to describe how the behave. It isn't entirely pretty because 2 of them ignore the band parameter and always have .. ------------- Commit messages: - 8376297 - 8376297 Changes: https://git.openjdk.org/jdk/pull/29457/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29457&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376297 Stats: 106 lines in 4 files changed: 100 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29457.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29457/head:pull/29457 PR: https://git.openjdk.org/jdk/pull/29457 From liach at openjdk.org Wed Jan 28 00:20:43 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 28 Jan 2026 00:20:43 GMT Subject: RFR: 8376297: ArrayIndexOutOfBoundsException Not Documented for SinglePixelPackedSampleModel.getSampleSize(int) In-Reply-To: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com> References: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com> Message-ID: On Tue, 27 Jan 2026 22:51:27 GMT, Phil Race wrote: > Update the specification of concrete SampleModel classes which over-ride getSampleSize(int band) to describe how the behave. > It isn't entirely pretty because 2 of them ignore the band parameter and always have .. I recommend specifying `IndexOutOfBoundsException` instead of AIOOBE: this allows implementation freedom in case an underlying storage is at some point changed to a `List` or some other non-array structure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29457#issuecomment-3808236881 From tr at openjdk.org Wed Jan 28 04:48:00 2026 From: tr at openjdk.org (Tejesh R) Date: Wed, 28 Jan 2026 04:48:00 GMT Subject: RFR: 8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter [v3] In-Reply-To: <8bBXkiJAJAIxN_v13DKjGdVrQGYqiBWrP83z929xEr4=.e30fa39a-db22-4c2f-b453-a7e5180030be@github.com> References: <8bBXkiJAJAIxN_v13DKjGdVrQGYqiBWrP83z929xEr4=.e30fa39a-db22-4c2f-b453-a7e5180030be@github.com> Message-ID: On Tue, 27 Jan 2026 21:14:47 GMT, Phil Race wrote: >> AppContext is removed from Swing LAF state. Tests which require it are deleted. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8376423 Test with same name [Test6657026.java](https://github.com/openjdk/jdk/pull/29437/changes#diff-d392211a6f8e0b0b65dbf68abd45ca2ddf89e6bd787be1cd1ed20d0c33eb9644) referring to same bug ID 6657026 exist in other places too, should we remove those test too ? Example : same file name referring to same bugid exists in path "open/test/jdk/javax/swing/ToolTipManager/ ", "open/test/jdk/javax/swing/plaf/metal/MetalBorders/ ", etc., ------------- PR Review: https://git.openjdk.org/jdk/pull/29437#pullrequestreview-3714560432 From tr at openjdk.org Wed Jan 28 06:56:01 2026 From: tr at openjdk.org (Tejesh R) Date: Wed, 28 Jan 2026 06:56:01 GMT Subject: RFR: 6441373: Editing JTable is not Serializable In-Reply-To: <24EVy67ZyIy7uxUtvIUDB1v-9j1q6vdDl88LoS9K5WY=.37595035-7c7e-4f6e-9554-9276225d608b@github.com> References: <24EVy67ZyIy7uxUtvIUDB1v-9j1q6vdDl88LoS9K5WY=.37595035-7c7e-4f6e-9554-9276225d608b@github.com> Message-ID: On Tue, 20 Jan 2026 09:12:44 GMT, Sergey Bylokhov wrote: > The patch implements serialization for editable JTables. Currently, most classes responsible for JTable editing are not serializable, so trying to serialize them causes an exception. The patch has two parts: > > - The editable JTable is reset to non-editable using the common pattern stopCellEditing + cancelCellEditing. This is added to the compWriteObjectNotify method, which acts as an entry point for serialization of Swing components. It allows actions to be performed before the parent classes are serialized. > > - The editing coordinates for all JTables are reset to -1. Before this patch, even non-editable JTables had their coordinates reset to 0 from -1 because the fields were transient. test/jdk/javax/swing/JTable/JTableSerialization.java line 50: > 48: > 49: private static JTable table; > 50: private static JLabel label; `label` cab be local variable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29313#discussion_r2735110639 From psadhukhan at openjdk.org Wed Jan 28 06:59:06 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 28 Jan 2026 06:59:06 GMT Subject: RFR: 8376434: Remove AppContext from awt ImageFetcher implementation In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 06:06:46 GMT, Phil Race wrote: > Remove AppContext from ImageFetcher copyright year not updated.. src/java.desktop/share/classes/sun/awt/image/ImageFetcher.java line 330: > 328: > 329: static FetcherInfo getFetcherInfo() { > 330: return FETCHER_INFO; Can you please refresh my memory as to why synchronization will not be required for this? I understand Swing is not thread-safe but there can be multiple images and this is called from `ImageFetcher.add`, `ImageFetcher.remove` etc and it can create "new FetcherInfo" instances, which is not desired, if access is not synchronized, or so I think.. ------------- PR Review: https://git.openjdk.org/jdk/pull/29441#pullrequestreview-3714872658 PR Review Comment: https://git.openjdk.org/jdk/pull/29441#discussion_r2735118342 From psadhukhan at openjdk.org Wed Jan 28 07:02:20 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 28 Jan 2026 07:02:20 GMT Subject: Integrated: 8373239: Test java/awt/print/PrinterJob/PageRanges.java fails with incorrect selection of printed pages In-Reply-To: <7V3UT7_3iCEk6MDbvc7DHJo4gt013_GpkwApQSAVisk=.cb6f417c-79d7-4df2-babf-83c756a11178@github.com> References: <7V3UT7_3iCEk6MDbvc7DHJo4gt013_GpkwApQSAVisk=.cb6f417c-79d7-4df2-babf-83c756a11178@github.com> Message-ID: <8EfFWKoVCJLpnR8io2G6GU24Mgq261Kd5V95Zn8RvXE=.fe8f022e-fffb-40e9-bc71-cff0c2cf1b49@github.com> On Tue, 20 Jan 2026 09:11:06 GMT, Prasanta Sadhukhan wrote: > If same `PrinterJob `is reused to first print user-set `PageRange `pages and then print ALL pages, it prints the first print job correctly as the page range is set but 2nd job doesn't print ALL pages and reprint the same page range as `from` and `to` page are not reset and reused > > Fix is made to check if page range is not set then print all pages This pull request has now been integrated. Changeset: 1161a640 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/1161a640abe454b47de95ed73452a78535160deb Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod 8373239: Test java/awt/print/PrinterJob/PageRanges.java fails with incorrect selection of printed pages Reviewed-by: prr, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/29312 From psadhukhan at openjdk.org Wed Jan 28 07:02:09 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 28 Jan 2026 07:02:09 GMT Subject: RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE [v4] In-Reply-To: References: Message-ID: > Invoking `JPopupMenu.setInvoker(null)` causes NPE which is fixed in this PR 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/29377/files - new: https://git.openjdk.org/jdk/pull/29377/files/91151bce..b588d51d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29377&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29377&range=02-03 Stats: 8 lines in 2 files changed: 7 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29377.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29377/head:pull/29377 PR: https://git.openjdk.org/jdk/pull/29377 From psadhukhan at openjdk.org Wed Jan 28 07:19:09 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 28 Jan 2026 07:19:09 GMT Subject: RFR: 8376432: Remove AppContext from sun/swing/DefaultLookup.java In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 05:29:21 GMT, Phil Race wrote: > Another removal of AppContext in Swing Marked as reviewed by psadhukhan (Reviewer). src/java.desktop/share/classes/sun/swing/DefaultLookup.java line 29: > 27: import java.awt.Color; > 28: import java.awt.Insets; > 29: import javax.swing.*; maybe expand the wildcard import since we are touching this file.. ------------- PR Review: https://git.openjdk.org/jdk/pull/29439#pullrequestreview-3714943522 PR Review Comment: https://git.openjdk.org/jdk/pull/29439#discussion_r2735176959 From aivanov at openjdk.org Wed Jan 28 11:27:28 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 28 Jan 2026 11:27:28 GMT Subject: RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE [v4] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 07:02:09 GMT, Prasanta Sadhukhan wrote: >> Invoking `JPopupMenu.setInvoker(null)` causes NPE which is fixed in this PR > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test update Changes requested by aivanov (Reviewer). test/jdk/javax/swing/JPopupMenu/TestPopupInvoker.java line 116: > 114: if (invoker != null) { > 115: throw new RuntimeException("Invoker is not null"); > 116: } Suggestion: SwingUtilities.invokeAndWait(() -> invoker = popupMenu.getInvoker()); if (invoker != null) { throw new RuntimeException("Invoker is not null"); } These lines comprise a single block. The `invokeAndWait` call has closer relation to the `if` below rather than to the one above. ------------- PR Review: https://git.openjdk.org/jdk/pull/29377#pullrequestreview-3716162327 PR Review Comment: https://git.openjdk.org/jdk/pull/29377#discussion_r2736188123 From psadhukhan at openjdk.org Wed Jan 28 12:10:38 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 28 Jan 2026 12:10:38 GMT Subject: RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE [v5] In-Reply-To: References: Message-ID: > Invoking `JPopupMenu.setInvoker(null)` causes NPE which is fixed in this PR 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/29377/files - new: https://git.openjdk.org/jdk/pull/29377/files/b588d51d..908bf782 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29377&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29377&range=03-04 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29377.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29377/head:pull/29377 PR: https://git.openjdk.org/jdk/pull/29377 From duke at openjdk.org Wed Jan 28 13:54:06 2026 From: duke at openjdk.org (Michael Bien) Date: Wed, 28 Jan 2026 13:54:06 GMT Subject: RFR: 4938801: The popup does not go when the component is removed [v8] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 13:40:21 GMT, Alexey Ivanov wrote: >> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 963: >> >>> 961: oldInvoker.removePropertyChangeListener("ancestor", propListener); >>> 962: } >>> 963: invoker.addPropertyChangeListener("ancestor", propListener); >> >> fyi: this will now throw NPEs on `setInvoker(null)` when it enters this section. (https://github.com/apache/netbeans/issues/9155) > > Prasanta @prsadhuk created a JBS bug report, [JDK-8376169](https://bugs.openjdk.org/browse/JDK-8376169), the fix for which is being reviewed in #29377. @aivanov-jdk Thanks! I built the PR you linked and can confirm that it resolves the NPE. Do you think the fix will be also backported to JDK 26? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2736736446 From aivanov at openjdk.org Wed Jan 28 14:25:35 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 28 Jan 2026 14:25:35 GMT Subject: RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE [v5] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 12:10:38 GMT, Prasanta Sadhukhan wrote: >> Invoking `JPopupMenu.setInvoker(null)` causes NPE which is fixed in this PR > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test update Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29377#pullrequestreview-3716989937 From aivanov at openjdk.org Wed Jan 28 14:28:49 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 28 Jan 2026 14:28:49 GMT Subject: RFR: 4938801: The popup does not go when the component is removed [v8] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 13:50:59 GMT, Michael Bien wrote: >> Prasanta @prsadhuk created a JBS bug report, [JDK-8376169](https://bugs.openjdk.org/browse/JDK-8376169), the fix for which is being reviewed in #29377. > > @aivanov-jdk Thanks! I built the PR you linked and can confirm that it resolves the NPE. Do you think the fix will be also backported to JDK 26? @mbien It's too late for JDK 26. I or someone else will backport the fix to 26.0.1. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2736891691 From azvegint at openjdk.org Wed Jan 28 15:18:02 2026 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 28 Jan 2026 15:18:02 GMT Subject: RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE [v5] In-Reply-To: References: Message-ID: <2pKpeBVhcEE7NrtpQK8wXSsaTbzxDxn-86_xS7hhuvM=.25486ad0-d4a9-4d38-8f1f-f41beaca8e1a@github.com> On Wed, 28 Jan 2026 12:10:38 GMT, Prasanta Sadhukhan wrote: >> Invoking `JPopupMenu.setInvoker(null)` causes NPE which is fixed in this PR > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test update Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29377#pullrequestreview-3717262332 From azvegint at openjdk.org Wed Jan 28 15:20:36 2026 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 28 Jan 2026 15:20:36 GMT Subject: RFR: 8376432: Remove AppContext from sun/swing/DefaultLookup.java In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 05:29:21 GMT, Phil Race wrote: > Another removal of AppContext in Swing Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29439#pullrequestreview-3717284928 From aivanov at openjdk.org Wed Jan 28 15:52:47 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 28 Jan 2026 15:52:47 GMT Subject: RFR: 8376420: Remove AppContext from javax/swing/ImageIcon.java In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 23:00:16 GMT, Phil Race wrote: > Remove per-AppContext MediaTracker from ImageIcon.java Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29433#pullrequestreview-3717494348 From aivanov at openjdk.org Wed Jan 28 15:57:37 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 28 Jan 2026 15:57:37 GMT Subject: RFR: 8376420: Remove AppContext from javax/swing/ImageIcon.java In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 06:02:15 GMT, Phil Race wrote: >> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 346: >> >>> 344: } >>> 345: >>> 346: private static final MediaTracker MEDIA_TRACKER = new MediaTracker(new Component() {}); >> >> This actually duplicates an existing declaration: >> `protected static final MediaTracker tracker = new MediaTracker(component);` >> I assume it was deprecated in Java 8 because of the AppContext issue? so now we can just uses that one? > > Not as far as I can see > https://hg.openjdk.org/jdk8/jdk8/jdk/rev/54a6e22b749c > I think that it was visible to apps was the issue. I agree it's safer not to use the deprecated field *that's visible to apps*. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29433#discussion_r2737319689 From aivanov at openjdk.org Wed Jan 28 16:00:25 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 28 Jan 2026 16:00:25 GMT Subject: RFR: 8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter [v3] In-Reply-To: References: <8bBXkiJAJAIxN_v13DKjGdVrQGYqiBWrP83z929xEr4=.e30fa39a-db22-4c2f-b453-a7e5180030be@github.com> Message-ID: On Wed, 28 Jan 2026 04:45:19 GMT, Tejesh R wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8376423 > > Test with same name [Test6657026.java](https://github.com/openjdk/jdk/pull/29437/changes#diff-d392211a6f8e0b0b65dbf68abd45ca2ddf89e6bd787be1cd1ed20d0c33eb9644) referring to same bug ID 6657026 exist in other places too, should we remove those test too ? > Example : same file name referring to same bugid exists in path "open/test/jdk/javax/swing/ToolTipManager/ ", "open/test/jdk/javax/swing/plaf/metal/MetalBorders/ ", etc., @TejeshR13, you're right, there are other tests which reference JDK-6657026: test/jdk/javax/swing/plaf/metal/MetalSliderUI/Test6657026.java test/jdk/javax/swing/plaf/metal/MetalInternalFrameUI/Test6657026.java test/jdk/javax/swing/plaf/metal/MetalBorders/Test6657026.java test/jdk/javax/swing/plaf/metal/MetalBumps/Test6657026.java test/jdk/javax/swing/plaf/basic/BasicSplitPaneUI/Test6657026.java test/jdk/javax/swing/ToolTipManager/Test6657026.java test/jdk/javax/swing/UIManager/Test6657026.java I looked at a few at the top. They test that the data are bound to `AppContext`. Yet none of these tests fails for me, even with the changes from this PR. Still, these tests should be removed sooner? or later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29437#issuecomment-3812146566 From aivanov at openjdk.org Wed Jan 28 16:13:58 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 28 Jan 2026 16:13:58 GMT Subject: RFR: 8376433: Remove AppContext from Swing Windows L&F implementation In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 05:35:16 GMT, Phil Race wrote: > Remove AppContext from the Windows L&F implementation Looks good. I should bump the copyright year in the updated files. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29440#pullrequestreview-3717614814 From aivanov at openjdk.org Wed Jan 28 16:17:34 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 28 Jan 2026 16:17:34 GMT Subject: RFR: 8376432: Remove AppContext from sun/swing/DefaultLookup.java In-Reply-To: References: Message-ID: <_GVtW4mjascgVVOxud2EC9Ol8QWMFrKo5L5BcSFrrsw=.8d0313b6-cbb9-4a81-8a48-91c28af20588@github.com> On Tue, 27 Jan 2026 05:29:21 GMT, Phil Race wrote: > Another removal of AppContext in Swing Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29439#pullrequestreview-3717629432 From aivanov at openjdk.org Wed Jan 28 16:47:41 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 28 Jan 2026 16:47:41 GMT Subject: RFR: 8376434: Remove AppContext from awt ImageFetcher implementation In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 06:06:46 GMT, Phil Race wrote: > Remove AppContext from ImageFetcher Looks good to me. You should bump the copyright year. src/java.desktop/share/classes/sun/awt/image/ImageFetcher.java line 320: > 318: int numFetchers; > 319: int numWaiting; > 320: Vector waitList; I'd mark the `fetchers` and `waitList` fields as final, however, it should rather be done under a separate PR. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29441#pullrequestreview-3717775577 PR Review Comment: https://git.openjdk.org/jdk/pull/29441#discussion_r2737538043 From aivanov at openjdk.org Wed Jan 28 16:47:43 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 28 Jan 2026 16:47:43 GMT Subject: RFR: 8376434: Remove AppContext from awt ImageFetcher implementation In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 06:56:15 GMT, Prasanta Sadhukhan wrote: >> Remove AppContext from ImageFetcher > > src/java.desktop/share/classes/sun/awt/image/ImageFetcher.java line 330: > >> 328: >> 329: static FetcherInfo getFetcherInfo() { >> 330: return FETCHER_INFO; > > Can you please refresh my memory as to why synchronization will not be required for this? > I understand Swing is not thread-safe but there can be multiple images and this is called from `ImageFetcher.add`, `ImageFetcher.remove` etc and it can create "new FetcherInfo" instances, which is not desired, if access is not synchronized, or so I think.. An interesting question? I think synchronisation is not required here because the method returns a static final field. Access to the fields needs synchronisation, though; and the synchronisation is present as far as I can see, the methods of the class use `synchronized(info.waitList)`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29441#discussion_r2737520438 From prr at openjdk.org Wed Jan 28 17:41:27 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 28 Jan 2026 17:41:27 GMT Subject: RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE [v5] In-Reply-To: References: Message-ID: <949j-Lo9erW2jA0GNhYBX9NJti8lup8fP6iyQ9oepKA=.de403e66-fe29-4c4e-b2cf-ecd409f544cb@github.com> On Wed, 28 Jan 2026 12:10:38 GMT, Prasanta Sadhukhan wrote: >> Invoking `JPopupMenu.setInvoker(null)` causes NPE which is fixed in this PR > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test update Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29377#pullrequestreview-3718085068 From prr at openjdk.org Wed Jan 28 18:01:06 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 28 Jan 2026 18:01:06 GMT Subject: Integrated: 8376432: Remove AppContext from sun/swing/DefaultLookup.java In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 05:29:21 GMT, Phil Race wrote: > Another removal of AppContext in Swing This pull request has now been integrated. Changeset: 89a18c01 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/89a18c0108e10dc4ca4a4fa9e8718d49036f8871 Stats: 40 lines in 1 file changed: 1 ins; 28 del; 11 mod 8376432: Remove AppContext from sun/swing/DefaultLookup.java Reviewed-by: psadhukhan, azvegint, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/29439 From prr at openjdk.org Wed Jan 28 18:04:46 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 28 Jan 2026 18:04:46 GMT Subject: Integrated: 8376434: Remove AppContext from awt ImageFetcher implementation In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 06:06:46 GMT, Phil Race wrote: > Remove AppContext from ImageFetcher This pull request has now been integrated. Changeset: 7efa3168 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/7efa3168b706c1d061c4ee65574427ef1f50fc7b Stats: 45 lines in 1 file changed: 2 ins; 27 del; 16 mod 8376434: Remove AppContext from awt ImageFetcher implementation Reviewed-by: azvegint, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/29441 From prr at openjdk.org Wed Jan 28 18:05:16 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 28 Jan 2026 18:05:16 GMT Subject: RFR: 8376433: Remove AppContext from Swing Windows L&F implementation [v2] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 16:11:05 GMT, Alexey Ivanov wrote: > Looks good. > > You should bump the copyright year in the updated files. done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29440#issuecomment-3812925656 From prr at openjdk.org Wed Jan 28 18:05:15 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 28 Jan 2026 18:05:15 GMT Subject: RFR: 8376433: Remove AppContext from Swing Windows L&F implementation [v2] In-Reply-To: References: Message-ID: > Remove AppContext from the Windows L&F implementation Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8376433 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29440/files - new: https://git.openjdk.org/jdk/pull/29440/files/fe0d424c..90b41e6d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29440&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29440&range=00-01 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29440.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29440/head:pull/29440 PR: https://git.openjdk.org/jdk/pull/29440 From prr at openjdk.org Wed Jan 28 18:25:03 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 28 Jan 2026 18:25:03 GMT Subject: RFR: 8376297: ArrayIndexOutOfBoundsException Not Documented for SinglePixelPackedSampleModel.getSampleSize(int) In-Reply-To: References: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com> Message-ID: On Wed, 28 Jan 2026 00:17:54 GMT, Chen Liang wrote: > I recommend specifying `IndexOutOfBoundsException` instead of AIOOBE: this allows implementation freedom in case an underlying storage is at some point changed to a `List` or some other non-array structure. This package has 152 specified cases of @throws ArrayIndexOutOfBoundsException and just one of * @throws IndexOutOfBoundsException and I don't think we are likely to change the implementation anyway. So I would prefer to leave it as it is. - However counting this I noticed one un-specified exception on an un-related class in the package. But that should be handled separately. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29457#issuecomment-3813040105 From prr at openjdk.org Wed Jan 28 18:40:59 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 28 Jan 2026 18:40:59 GMT Subject: RFR: 4938801: The popup does not go when the component is removed [v8] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 13:50:59 GMT, Michael Bien wrote: >> Prasanta @prsadhuk created a JBS bug report, [JDK-8376169](https://bugs.openjdk.org/browse/JDK-8376169), the fix for which is being reviewed in #29377. > > @aivanov-jdk Thanks! I built the PR you linked and can confirm that it resolves the NPE. Do you think the fix will be also backported to JDK 26? > @mbien It's too late for JDK 26. I or someone else will backport the fix to 26.0.1. A regression in JDK 26 seems like a 26 candidate to me, so I think it is worth asking anyway. This is why we have EAs. But it'll have to be VERY soon. Next week is the first RC and then it really will be too late. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2737989631 From azvegint at openjdk.org Wed Jan 28 18:53:20 2026 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 28 Jan 2026 18:53:20 GMT Subject: RFR: 8365313: GTK LaF does not respect system color scheme with Gnome Message-ID: On some systems with the GNOME desktop environment, the dark theme does not automatically apply to the GTK look and feel. This issue has been observed on Oracle Linux 10 (Gnome 47) and Fedora 42 (Gnome 48). However, Ubuntu with the same Gnome versions is not affected. To get it working, we should manually set the `gtk-application-prefer-dark-theme` setting on affected systems. These changes work fine on Ubuntu, too. --- However, with this fix, the JDK will not detect a color scheme change on the fly (e.g., from light to dark when GTK LaF is active). The theme change will only apply if you switch to a different LaF and then back to GTK. Normally we would subscribe to `changed::color-scheme` signal to detect this change: static void on_color_scheme_changed(GSettings *settings, gchar *key, gpointer user_data) { gchar *value = g_settings_get_string(settings, key); g_print("Color scheme changed: %s\n", value); g_free(value); } ... GSettings *settings = g_settings_new("org.gnome.desktop.interface"); g_signal_connect(settings, "changed::color-scheme", G_CALLBACK(on_color_scheme_changed), NULL); ... g_object_unref(settings); However, it requires a running GTK loop, which we do not have. As a workaround, we could try finding a place in our code where we can check for a color scheme change to avoid introducing the GTK loop. This issue is filed as [JDK-8376605](https://bugs.openjdk.org/browse/JDK-8376605) --- Testing looks good. ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/29469/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29469&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365313 Stats: 74 lines in 5 files changed: 74 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29469.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29469/head:pull/29469 PR: https://git.openjdk.org/jdk/pull/29469 From serb at openjdk.org Wed Jan 28 19:11:40 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 28 Jan 2026 19:11:40 GMT Subject: RFR: 8376434: Remove AppContext from awt ImageFetcher implementation In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 06:06:46 GMT, Phil Race wrote: > Remove AppContext from ImageFetcher src/java.desktop/share/classes/sun/awt/image/ImageFetcher.java line 290: > 288: } > 289: final ThreadGroup fetcherGroup = threadGroup; > 290: Why we want main TG the here? In most other places we use "RootThreadGroup" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29441#discussion_r2738143269 From serb at openjdk.org Wed Jan 28 19:23:07 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 28 Jan 2026 19:23:07 GMT Subject: RFR: 8376510: Raster.createBandedRaster(int, int, int, int, int[], int[], Point) does not check for negative scanlineStride In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 19:04:04 GMT, Phil Race wrote: > We specify that scanlineStride < 0 will throw IAE, but it was not checked up front in all cases, so sometimes would be IAE and sometimes NegativeArrayIndexException. > Add an explicit check. src/java.desktop/share/classes/java/awt/image/Raster.java line 458: > 456: throw new IllegalArgumentException("Scanline stride must be >= 0"); > 457: } > 458: if (bankIndices == null) { The JDK-8369129 changed some checks from "scanlineStride < 0" to "scanlineStride <= 0". Should not we do the same here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29454#discussion_r2738201423 From serb at openjdk.org Wed Jan 28 19:26:09 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 28 Jan 2026 19:26:09 GMT Subject: RFR: 8376297: ArrayIndexOutOfBoundsException Not Documented for SinglePixelPackedSampleModel.getSampleSize(int) In-Reply-To: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com> References: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com> Message-ID: On Tue, 27 Jan 2026 22:51:27 GMT, Phil Race wrote: > Update the specification of concrete SampleModel classes which over-ride getSampleSize(int band) to describe how the behave. > It isn't entirely pretty because 2 of them ignore the band parameter and always have .. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29457#pullrequestreview-3718662931 From prr at openjdk.org Wed Jan 28 19:41:34 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 28 Jan 2026 19:41:34 GMT Subject: RFR: 8376297: ArrayIndexOutOfBoundsException Not Documented for SinglePixelPackedSampleModel.getSampleSize(int) In-Reply-To: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com> References: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com> Message-ID: On Tue, 27 Jan 2026 22:51:27 GMT, Phil Race wrote: > Update the specification of concrete SampleModel classes which over-ride getSampleSize(int band) to describe how the behave. > It isn't entirely pretty because 2 of them ignore the band parameter and always have .. The CSR is ready for review : https://bugs.openjdk.org/browse/JDK-8376608 ------------- PR Comment: https://git.openjdk.org/jdk/pull/29457#issuecomment-3813474439 From serb at openjdk.org Wed Jan 28 19:41:35 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 28 Jan 2026 19:41:35 GMT Subject: RFR: 8376420: Remove AppContext from javax/swing/ImageIcon.java In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 15:54:55 GMT, Alexey Ivanov wrote: >> Not as far as I can see >> https://hg.openjdk.org/jdk8/jdk8/jdk/rev/54a6e22b749c >> I think that it was visible to apps was the issue. > > I agree it's safer not to use the deprecated field *that's visible to apps*. I am pretty sure this was AppContext related, since we could not return a MediaTracker stored in one AppContext to another AppContext and now we are doing exactly that, but ok not a big issue. The only difference between the two is that the old MediaTracker component was created using createComponent, which resets the AppContext, should we drop that AppContext usage there as well? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29433#discussion_r2738293304 From serb at openjdk.org Wed Jan 28 19:43:28 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 28 Jan 2026 19:43:28 GMT Subject: RFR: 8376433: Remove AppContext from Swing Windows L&F implementation [v2] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 18:05:15 GMT, Phil Race wrote: >> Remove AppContext from the Windows L&F implementation > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8376433 Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29440#pullrequestreview-3718762878 From prr at openjdk.org Wed Jan 28 19:56:32 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 28 Jan 2026 19:56:32 GMT Subject: Integrated: 8376433: Remove AppContext from Swing Windows L&F implementation In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 05:35:16 GMT, Phil Race wrote: > Remove AppContext from the Windows L&F implementation This pull request has now been integrated. Changeset: 0722ae92 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/0722ae926ff1327c47a922b1ca0b493a0d06526e Stats: 72 lines in 6 files changed: 0 ins; 51 del; 21 mod 8376433: Remove AppContext from Swing Windows L&F implementation Reviewed-by: serb, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/29440 From prr at openjdk.org Wed Jan 28 20:06:43 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 28 Jan 2026 20:06:43 GMT Subject: RFR: 8365313: GTK LaF does not respect system color scheme with Gnome In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 18:44:21 GMT, Alexander Zvegintsev wrote: > On some systems with the GNOME desktop environment, the dark theme does not automatically apply to the GTK look and feel. > This issue has been observed on Oracle Linux 10 (Gnome 47) and Fedora 42 (Gnome 48). However, Ubuntu with the same Gnome versions is not affected. > > To get it working, we should manually set the `gtk-application-prefer-dark-theme` setting on affected systems. These changes work fine on Ubuntu, too. > > > --- > > However, with this fix, the JDK will not detect a color scheme change on the fly (e.g., from light to dark when GTK LaF is active). The theme change will only apply if you switch to a different LaF and then back to GTK. > > Normally we would subscribe to `changed::color-scheme` signal to detect this change: > > > static void on_color_scheme_changed(GSettings *settings, gchar *key, gpointer user_data) { > gchar *value = g_settings_get_string(settings, key); > g_print("Color scheme changed: %s\n", value); > g_free(value); > } > ... > GSettings *settings = g_settings_new("org.gnome.desktop.interface"); > g_signal_connect(settings, "changed::color-scheme", G_CALLBACK(on_color_scheme_changed), NULL); > ... > g_object_unref(settings); > > > However, it requires a running GTK loop, which we do not have. > As a workaround, we could try finding a place in our code where we can check for a color scheme change to avoid introducing the GTK loop. > This issue is filed as [JDK-8376605](https://bugs.openjdk.org/browse/JDK-8376605) > > --- > > Testing looks good. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29469#pullrequestreview-3718904912 From aivanov at openjdk.org Wed Jan 28 20:12:38 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 28 Jan 2026 20:12:38 GMT Subject: RFR: 8376420: Remove AppContext from javax/swing/ImageIcon.java In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 19:39:21 GMT, Sergey Bylokhov wrote: > I am pretty sure this was AppContext related, since we could not return a MediaTracker stored in one AppContext to another AppContext and now we are doing exactly that, but ok not a big issue. Very much likely. Does an app need direct access to the `MediaTracker` that's used to download the image? Probably not, therefore a private member is better. > The only difference between the two is that the old MediaTracker component was created using createComponent, which resets the AppContext, should we drop that AppContext usage there as well? Indeed, the component created via `createComponent` doesn't store a reference to app context. https://github.com/prrace/jdk/blob/08f95226d2c638cae74f51836b7fc509ed5b0b8b/src/java.desktop/share/classes/javax/swing/ImageIcon.java#L116-L119 I guess it'll get removed when the `appContext` field gets removed from `Component`. On the other hand, the shared `MediaTracker` instance introduced in this PR could use `createComponent` to instead of creating a new instance of `Component`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29433#discussion_r2738423738 From aivanov at openjdk.org Wed Jan 28 20:22:46 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 28 Jan 2026 20:22:46 GMT Subject: RFR: 8376420: Remove AppContext from javax/swing/ImageIcon.java In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 23:00:16 GMT, Phil Race wrote: > Remove per-AppContext MediaTracker from ImageIcon.java src/java.desktop/share/classes/javax/swing/ImageIcon.java line 346: > 344: } > 345: > 346: private static final MediaTracker MEDIA_TRACKER = new MediaTracker(new Component() {}); Is there a particular reason to create a new anonymous class extending `Component` instead of simply instantiating? new MediaTracker(new Component()); Is it only to follow what `createComponent` does? With the removal of `AppContext` and `SecurityManager`, is the anonymous class still necessary? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29433#discussion_r2738456590 From prr at openjdk.org Wed Jan 28 20:25:48 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 28 Jan 2026 20:25:48 GMT Subject: RFR: 8376510: Raster.createBandedRaster(int, int, int, int, int[], int[], Point) does not check for negative scanlineStride In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 19:20:01 GMT, Sergey Bylokhov wrote: >> We specify that scanlineStride < 0 will throw IAE, but it was not checked up front in all cases, so sometimes would be IAE and sometimes NegativeArrayIndexException. >> Add an explicit check. > > src/java.desktop/share/classes/java/awt/image/Raster.java line 458: > >> 456: throw new IllegalArgumentException("Scanline stride must be >= 0"); >> 457: } >> 458: if (bankIndices == null) { > > The JDK-8369129 changed some checks from "scanlineStride < 0" to "scanlineStride <= 0". Should not we do the same here? This specific case (BandedSampleModel) was one of those noted in the PR for that bug https://github.com/openjdk/jdk/pull/27627#discussion_r2429979263 and as I noted they require careful consideration before changing. This change doesn't preclude also disallowing 0 at a later time, with proper consideration, but the sole goal here is to ensure that negative values are always disallowed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29454#discussion_r2738466119 From prr at openjdk.org Wed Jan 28 20:33:57 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 28 Jan 2026 20:33:57 GMT Subject: RFR: 8376420: Remove AppContext from javax/swing/ImageIcon.java In-Reply-To: References: Message-ID: <3EfuPEC0euZkOQ9wourgdcCZxgwM0xJ4-XpxKjf4uVQ=.d84b33c8-c4d9-4d6a-b5f6-ed1984209644@github.com> On Wed, 28 Jan 2026 20:19:42 GMT, Alexey Ivanov wrote: >> Remove per-AppContext MediaTracker from ImageIcon.java > > src/java.desktop/share/classes/javax/swing/ImageIcon.java line 346: > >> 344: } >> 345: >> 346: private static final MediaTracker MEDIA_TRACKER = new MediaTracker(new Component() {}); > > Is there a particular reason to create a new anonymous class extending `Component` instead of simply instantiating? > > > new MediaTracker(new Component()); > > > Is it only to follow what `createComponent` does? > > With the removal of `AppContext` and `SecurityManager`, is the anonymous class still necessary? Component is an abstract class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29433#discussion_r2738492964 From serb at openjdk.org Wed Jan 28 21:06:29 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 28 Jan 2026 21:06:29 GMT Subject: RFR: 8376510: Raster.createBandedRaster(int, int, int, int, int[], int[], Point) does not check for negative scanlineStride In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 19:04:04 GMT, Phil Race wrote: > We specify that scanlineStride < 0 will throw IAE, but it was not checked up front in all cases, so sometimes would be IAE and sometimes NegativeArrayIndexException. > Add an explicit check. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29454#pullrequestreview-3719145145 From serb at openjdk.org Wed Jan 28 21:09:18 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 28 Jan 2026 21:09:18 GMT Subject: RFR: 8373626: [asan] read past end of buffer in sun.awt.image.ImagingLib.convolveBI [v3] In-Reply-To: References: Message-ID: <4ZrSXtim1ImMl4KP_Avz9WX3jONUKPivbFZNH-QGr54=.ba513217-c01d-4723-b2aa-bad69d3c8806@github.com> On Tue, 27 Jan 2026 05:24:29 GMT, Phil Race wrote: > @mrserb I updated last week. Looking into this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29257#issuecomment-3813935988 From prr at openjdk.org Wed Jan 28 21:11:58 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 28 Jan 2026 21:11:58 GMT Subject: RFR: 8376420: Remove AppContext from javax/swing/ImageIcon.java [v2] In-Reply-To: References: Message-ID: > Remove per-AppContext MediaTracker from ImageIcon.java Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8376420 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29433/files - new: https://git.openjdk.org/jdk/pull/29433/files/08f95226..477de10f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29433&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29433&range=00-01 Stats: 12 lines in 1 file changed: 0 ins; 11 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29433.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29433/head:pull/29433 PR: https://git.openjdk.org/jdk/pull/29433 From prr at openjdk.org Wed Jan 28 21:12:00 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 28 Jan 2026 21:12:00 GMT Subject: RFR: 8376420: Remove AppContext from javax/swing/ImageIcon.java [v2] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 20:09:42 GMT, Alexey Ivanov wrote: > I am pretty sure this was AppContext related, since we could not return a MediaTracker stored in one AppContext to another AppContext and now we are doing exactly that, but ok not a big issue. > Not a big issue because only tests create 2 ACs now and the tests and AC itself will be removed as soon as I can get past these leaf issues. Going further back it still doesn't seem to be the case that it was an AC fix. It was actually due to a security issue with ACC (AccessControlContext). That fix is now no longer there because we removed SM code a couple of releases ago. Now we can simplify it even further. But it still doesn't seem like we need to resurrect using the visible field. > The only difference between the two is that the old MediaTracker component was created using createComponent, which resets the AppContext, should we drop that AppContext usage there as well? Yes, I don't know why I didn't do that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29433#discussion_r2738608359 From serb at openjdk.org Wed Jan 28 21:12:01 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 28 Jan 2026 21:12:01 GMT Subject: RFR: 8376420: Remove AppContext from javax/swing/ImageIcon.java [v2] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 21:05:50 GMT, Phil Race wrote: >>> I am pretty sure this was AppContext related, since we could not return a MediaTracker stored in one AppContext to another AppContext and now we are doing exactly that, but ok not a big issue. >> >> Very much likely. >> >> Does an app need direct access to the `MediaTracker` that's used to download the image? Probably not, therefore a private member is better. >> >>> The only difference between the two is that the old MediaTracker component was created using createComponent, which resets the AppContext, should we drop that AppContext usage there as well? >> >> Indeed, the component created via `createComponent` doesn't store a reference to app context. >> >> https://github.com/prrace/jdk/blob/08f95226d2c638cae74f51836b7fc509ed5b0b8b/src/java.desktop/share/classes/javax/swing/ImageIcon.java#L116-L119 >> >> I guess it'll get removed when the `appContext` field gets removed from `Component`. >> >> On the other hand, the shared `MediaTracker` instance introduced in this PR could use `createComponent` to instead of creating a new instance of `Component`. > >> I am pretty sure this was AppContext related, since we could not return a MediaTracker stored in one AppContext to another AppContext and now we are doing exactly that, but ok not a big issue. >> > > Not a big issue because only tests create 2 ACs now and the tests and AC itself will be removed as soon as I can get past these leaf issues. > > Going further back it still doesn't seem to be the case that it was an AC fix. > It was actually due to a security issue with ACC (AccessControlContext). > That fix is now no longer there because we removed SM code a couple of releases ago. > Now we can simplify it even further. > > But it still doesn't seem like we need to resurrect using the visible field. > >> The only difference between the two is that the old MediaTracker component was created using createComponent, which resets the AppContext, should we drop that AppContext usage there as well? > > Yes, I don't know why I didn't do that. > Does an app need direct access to the `MediaTracker` that's used to download the image? Probably not, therefore a private member is better. The application will have this access via getter already, the problematic part here is access to the Component which is mutable so we cannot use it via final field. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29433#discussion_r2738610762 From serb at openjdk.org Wed Jan 28 21:12:15 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 28 Jan 2026 21:12:15 GMT Subject: RFR: 8375011: OldJTable.java - NullPointerException when columnData is null [v3] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 07:02:12 GMT, Anupam Dev wrote: >> Hi, >> >> This is a fix for NPE in OldJTable.addColumn >> >> The addColumn method in OldJTable.java was unconditionally calling columnData.toArray(), which caused a NullPointerException when columnData was null (e.g., when called from addColumn(Object, int)). >> >> This commit adds a null check to safe-guard against this NPE, passing null to the underlying DefaultTableModel when columnData is missing. >> >> Kindly review. >> >> Regards, >> Anupam > > Anupam Dev has updated the pull request incrementally with one additional commit since the last revision: > > Update full name /** * The OldJTable is an unsupported class containing some methods that were * deleted from the JTable between releases 0.6 and 0.7 */ It might be better to just delete it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29226#issuecomment-3813945488 From prr at openjdk.org Wed Jan 28 21:20:26 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 28 Jan 2026 21:20:26 GMT Subject: RFR: 8375011: OldJTable.java - NullPointerException when columnData is null [v3] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 21:09:11 GMT, Sergey Bylokhov wrote: > ``` > /** > * The OldJTable is an unsupported class containing some methods that were > * deleted from the JTable between releases 0.6 and 0.7 > */ > ``` > > It might be better to just delete it. +1 to that. I'm amazed we didn't nix it years ago. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29226#issuecomment-3813981016 From prr at openjdk.org Wed Jan 28 21:58:33 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 28 Jan 2026 21:58:33 GMT Subject: RFR: 8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter [v3] In-Reply-To: References: <8bBXkiJAJAIxN_v13DKjGdVrQGYqiBWrP83z929xEr4=.e30fa39a-db22-4c2f-b453-a7e5180030be@github.com> Message-ID: On Wed, 28 Jan 2026 04:45:19 GMT, Tejesh R wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8376423 > > Test with same name [Test6657026.java](https://github.com/openjdk/jdk/pull/29437/changes#diff-d392211a6f8e0b0b65dbf68abd45ca2ddf89e6bd787be1cd1ed20d0c33eb9644) referring to same bug ID 6657026 exist in other places too, should we remove those test too ? > Example : same file name referring to same bugid exists in path "open/test/jdk/javax/swing/ToolTipManager/ ", "open/test/jdk/javax/swing/plaf/metal/MetalBorders/ ", etc., > @TejeshR13, you're right, there are other tests which reference JDK-6657026: > > ``` > test/jdk/javax/swing/plaf/metal/MetalSliderUI/Test6657026.java > test/jdk/javax/swing/plaf/metal/MetalInternalFrameUI/Test6657026.java > test/jdk/javax/swing/plaf/metal/MetalBorders/Test6657026.java > test/jdk/javax/swing/plaf/metal/MetalBumps/Test6657026.java > test/jdk/javax/swing/plaf/basic/BasicSplitPaneUI/Test6657026.java > test/jdk/javax/swing/ToolTipManager/Test6657026.java > test/jdk/javax/swing/UIManager/Test6657026.java > ``` > > I looked at a few at the top. They test that the data are bound to `AppContext`. Yet none of these tests fails for me, even with the changes from this PR. > > Still, these tests should be removed sooner? or later. A couple of these are on my short-term radar. > @TejeshR13, you're right, there are other tests which reference JDK-6657026: > > ``` > test/jdk/javax/swing/plaf/metal/MetalSliderUI/Test6657026.java > test/jdk/javax/swing/plaf/metal/MetalInternalFrameUI/Test6657026.java > test/jdk/javax/swing/plaf/metal/MetalBorders/Test6657026.java > test/jdk/javax/swing/plaf/metal/MetalBumps/Test6657026.java > test/jdk/javax/swing/plaf/basic/BasicSplitPaneUI/Test6657026.java > test/jdk/javax/swing/ToolTipManager/Test6657026.java > test/jdk/javax/swing/UIManager/Test6657026.java > ``` > > I looked at a few at the top. They test that the data are bound to `AppContext`. Yet none of these tests fails for me, even with the changes from this PR. > > Still, these tests should be removed sooner? or later. test/jdk/javax/swing/UIManager/Test6657026.java is removed as part of this PR because it does fail. as you say, the others do not fail although MetalBumps fails for me in a different (metal) fix I'm working on. So I'm not sure they are testing what they should be. I expect I'll remove all the metal tests in the Metal fix that'll be coming shortly. The tooltip one is not one I'd noticed at all, but in general rather than just removing all app context tests up front, I'm trying (as much as I can) to remove them only when they fail, so I can relate it closely to a specific place where AppContext is removed. So I'll not remove those additional tests here, but soon enough they'll go. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29437#issuecomment-3814135901 From prr at openjdk.org Wed Jan 28 22:54:33 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 28 Jan 2026 22:54:33 GMT Subject: RFR: 8376627: Remove AppContext from javax/swing/plaf/metal classes Message-ID: Remove AppContext from Metal L&F ------------- Commit messages: - 8376627 Changes: https://git.openjdk.org/jdk/pull/29474/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29474&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376627 Stats: 529 lines in 10 files changed: 2 ins; 505 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/29474.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29474/head:pull/29474 PR: https://git.openjdk.org/jdk/pull/29474 From prr at openjdk.org Wed Jan 28 23:14:17 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 28 Jan 2026 23:14:17 GMT Subject: RFR: 8376627: Remove AppContext from javax/swing/plaf/metal classes [v2] In-Reply-To: References: Message-ID: > Remove AppContext from Metal L&F Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8376627 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29474/files - new: https://git.openjdk.org/jdk/pull/29474/files/07221d3c..99a78477 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29474&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29474&range=00-01 Stats: 91 lines in 1 file changed: 91 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29474.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29474/head:pull/29474 PR: https://git.openjdk.org/jdk/pull/29474 From serb at openjdk.org Thu Jan 29 00:04:10 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 29 Jan 2026 00:04:10 GMT Subject: RFR: 8376627: Remove AppContext from javax/swing/plaf/metal classes [v2] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 23:14:17 GMT, Phil Race wrote: >> Remove AppContext from Metal L&F > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8376627 src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBumps.java line 52: > 50: protected Color backColor; > 51: > 52: private static final List BUMPS_LIST = new ArrayList(); This doesn?t seem to be a constant, does it? I think at some point we should implement some kind of cleanup logic for this list. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29474#discussion_r2739136972 From serb at openjdk.org Thu Jan 29 00:26:34 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 29 Jan 2026 00:26:34 GMT Subject: RFR: 8365313: GTK LaF does not respect system color scheme with Gnome In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 18:44:21 GMT, Alexander Zvegintsev wrote: > On some systems with the GNOME desktop environment, the dark theme does not automatically apply to the GTK look and feel. > This issue has been observed on Oracle Linux 10 (Gnome 47) and Fedora 42 (Gnome 48). However, Ubuntu with the same Gnome versions is not affected. > > To get it working, we should manually set the `gtk-application-prefer-dark-theme` setting on affected systems. These changes work fine on Ubuntu, too. > > > --- > > However, with this fix, the JDK will not detect a color scheme change on the fly (e.g., from light to dark when GTK LaF is active). The theme change will only apply if you switch to a different LaF and then back to GTK. > > Normally we would subscribe to `changed::color-scheme` signal to detect this change: > > > static void on_color_scheme_changed(GSettings *settings, gchar *key, gpointer user_data) { > gchar *value = g_settings_get_string(settings, key); > g_print("Color scheme changed: %s\n", value); > g_free(value); > } > ... > GSettings *settings = g_settings_new("org.gnome.desktop.interface"); > g_signal_connect(settings, "changed::color-scheme", G_CALLBACK(on_color_scheme_changed), NULL); > ... > g_object_unref(settings); > > > However, it requires a running GTK loop, which we do not have. > As a workaround, we could try finding a place in our code where we can check for a color scheme change to avoid introducing the GTK loop. > This issue is filed as [JDK-8376605](https://bugs.openjdk.org/browse/JDK-8376605) > > --- > > Testing looks good. maybe we should provide a way to set this by the application? similar to how we did on macOS? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29469#issuecomment-3814636643 From serb at openjdk.org Thu Jan 29 00:33:11 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 29 Jan 2026 00:33:11 GMT Subject: RFR: 6441373: Editing JTable is not Serializable [v2] In-Reply-To: <24EVy67ZyIy7uxUtvIUDB1v-9j1q6vdDl88LoS9K5WY=.37595035-7c7e-4f6e-9554-9276225d608b@github.com> References: <24EVy67ZyIy7uxUtvIUDB1v-9j1q6vdDl88LoS9K5WY=.37595035-7c7e-4f6e-9554-9276225d608b@github.com> Message-ID: > The patch implements serialization for editable JTables. Currently, most classes responsible for JTable editing are not serializable, so trying to serialize them causes an exception. The patch has two parts: > > - The editable JTable is reset to non-editable using the common pattern stopCellEditing + cancelCellEditing. This is added to the compWriteObjectNotify method, which acts as an entry point for serialization of Swing components. It allows actions to be performed before the parent classes are serialized. > > - The editing coordinates for all JTables are reset to -1. Before this patch, even non-editable JTables had their coordinates reset to 0 from -1 because the fields were transient. Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-6441373 - Update JTableSerialization.java - 6441373: Editing JTable is not Serializable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29313/files - new: https://git.openjdk.org/jdk/pull/29313/files/8da82657..c2fb2cd5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29313&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29313&range=00-01 Stats: 23529 lines in 736 files changed: 10299 ins; 4211 del; 9019 mod Patch: https://git.openjdk.org/jdk/pull/29313.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29313/head:pull/29313 PR: https://git.openjdk.org/jdk/pull/29313 From psadhukhan at openjdk.org Thu Jan 29 02:35:52 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 29 Jan 2026 02:35:52 GMT Subject: Integrated: 8376169: JPopupMenu.setInvoker(null) causes NPE In-Reply-To: References: Message-ID: <7epFhydrZXQgSAzs-Hm7R5awk4ETdOYkh-c-f2-q4Gc=.a747fc81-480c-4165-9258-8366e62f3f71@github.com> On Fri, 23 Jan 2026 07:13:42 GMT, Prasanta Sadhukhan wrote: > Invoking `JPopupMenu.setInvoker(null)` causes NPE which is fixed in this PR This pull request has now been integrated. Changeset: 2529e2fe Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/2529e2fe8dfe9685033bb0ae558266b8bc3cf95c Stats: 14 lines in 2 files changed: 10 ins; 0 del; 4 mod 8376169: JPopupMenu.setInvoker(null) causes NPE Reviewed-by: aivanov, azvegint, prr, kizune ------------- PR: https://git.openjdk.org/jdk/pull/29377 From psadhukhan at openjdk.org Thu Jan 29 02:40:28 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 29 Jan 2026 02:40:28 GMT Subject: [jdk26] RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE Message-ID: 8376169: JPopupMenu.setInvoker(null) causes NPE ------------- Commit messages: - Backport 2529e2fe8dfe9685033bb0ae558266b8bc3cf95c Changes: https://git.openjdk.org/jdk/pull/29477/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29477&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376169 Stats: 14 lines in 2 files changed: 10 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29477.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29477/head:pull/29477 PR: https://git.openjdk.org/jdk/pull/29477 From adev at openjdk.org Thu Jan 29 03:23:49 2026 From: adev at openjdk.org (Anupam Dev) Date: Thu, 29 Jan 2026 03:23:49 GMT Subject: RFR: 8375011: OldJTable.java - NullPointerException when columnData is null [v4] In-Reply-To: References: Message-ID: > Hi, > > This is a fix for NPE in OldJTable.addColumn > > The addColumn method in OldJTable.java was unconditionally calling columnData.toArray(), which caused a NullPointerException when columnData was null (e.g., when called from addColumn(Object, int)). > > This commit adds a null check to safe-guard against this NPE, passing null to the underlying DefaultTableModel when columnData is missing. > > Kindly review. > > Regards, > Anupam Anupam Dev has updated the pull request incrementally with one additional commit since the last revision: Removed obsolete OldJTable from demo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29226/files - new: https://git.openjdk.org/jdk/pull/29226/files/0605ac5b..7723e2b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29226&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29226&range=02-03 Stats: 264 lines in 1 file changed: 0 ins; 264 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29226/head:pull/29226 PR: https://git.openjdk.org/jdk/pull/29226 From adev at openjdk.org Thu Jan 29 03:23:51 2026 From: adev at openjdk.org (Anupam Dev) Date: Thu, 29 Jan 2026 03:23:51 GMT Subject: RFR: 8375011: OldJTable.java - NullPointerException when columnData is null [v3] In-Reply-To: References: Message-ID: <3Sd6Q9lKvv05CuyaV3eUbeeZmYtyYWGcZlf3kM_tPLc=.c855ff00-b128-4388-a804-591bd9e168c8@github.com> On Mon, 19 Jan 2026 07:02:12 GMT, Anupam Dev wrote: >> Hi, >> >> This is a fix for NPE in OldJTable.addColumn >> >> The addColumn method in OldJTable.java was unconditionally calling columnData.toArray(), which caused a NullPointerException when columnData was null (e.g., when called from addColumn(Object, int)). >> >> This commit adds a null check to safe-guard against this NPE, passing null to the underlying DefaultTableModel when columnData is missing. >> >> Kindly review. >> >> Regards, >> Anupam > > Anupam Dev has updated the pull request incrementally with one additional commit since the last revision: > > Update full name Deleted the file OldJTable.java from demo. Regards, Anupam ------------- PR Comment: https://git.openjdk.org/jdk/pull/29226#issuecomment-3815226890 From serb at openjdk.org Thu Jan 29 03:29:46 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 29 Jan 2026 03:29:46 GMT Subject: RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE [v3] In-Reply-To: References: <3NeXqnAvhKti4-KGACJHdAV3NSJmbLlyBTBvueTyTms=.76d1ef32-b318-4f88-aeec-8321504de002@github.com> Message-ID: On Tue, 27 Jan 2026 13:17:26 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Invoker null check > > src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 970: > >> 968: invalidate(); >> 969: >> 970: } > > Does this newly added blank line right before the closing brace of the method serve any purpose? I'd rather not add it. What happens if the new invoker is null, the old invoker is not null and the UI is null? Will we continue to receive events from the old invoker? Or this combination is not possible? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29377#discussion_r2739728205 From prr at openjdk.org Thu Jan 29 04:22:34 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 29 Jan 2026 04:22:34 GMT Subject: RFR: 8375011: OldJTable.java - NullPointerException when columnData is null [v4] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 03:23:49 GMT, Anupam Dev wrote: >> Hi, >> >> This is a fix for NPE in OldJTable.addColumn >> >> The addColumn method in OldJTable.java was unconditionally calling columnData.toArray(), which caused a NullPointerException when columnData was null (e.g., when called from addColumn(Object, int)). >> >> This commit adds a null check to safe-guard against this NPE, passing null to the underlying DefaultTableModel when columnData is missing. >> >> Kindly review. >> >> Regards, >> Anupam > > Anupam Dev has updated the pull request incrementally with one additional commit since the last revision: > > Removed obsolete OldJTable from demo Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29226#pullrequestreview-3720613869 From tr at openjdk.org Thu Jan 29 04:44:00 2026 From: tr at openjdk.org (Tejesh R) Date: Thu, 29 Jan 2026 04:44:00 GMT Subject: RFR: 8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter [v3] In-Reply-To: <8bBXkiJAJAIxN_v13DKjGdVrQGYqiBWrP83z929xEr4=.e30fa39a-db22-4c2f-b453-a7e5180030be@github.com> References: <8bBXkiJAJAIxN_v13DKjGdVrQGYqiBWrP83z929xEr4=.e30fa39a-db22-4c2f-b453-a7e5180030be@github.com> Message-ID: On Tue, 27 Jan 2026 21:14:47 GMT, Phil Race wrote: >> AppContext is removed from Swing LAF state. Tests which require it are deleted. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8376423 Marked as reviewed by tr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29437#pullrequestreview-3720657019 From tr at openjdk.org Thu Jan 29 04:44:52 2026 From: tr at openjdk.org (Tejesh R) Date: Thu, 29 Jan 2026 04:44:52 GMT Subject: RFR: 6441373: Editing JTable is not Serializable [v2] In-Reply-To: References: <24EVy67ZyIy7uxUtvIUDB1v-9j1q6vdDl88LoS9K5WY=.37595035-7c7e-4f6e-9554-9276225d608b@github.com> Message-ID: On Thu, 29 Jan 2026 00:33:11 GMT, Sergey Bylokhov wrote: >> The patch implements serialization for editable JTables. Currently, most classes responsible for JTable editing are not serializable, so trying to serialize them causes an exception. The patch has two parts: >> >> - The editable JTable is reset to non-editable using the common pattern stopCellEditing + cancelCellEditing. This is added to the compWriteObjectNotify method, which acts as an entry point for serialization of Swing components. It allows actions to be performed before the parent classes are serialized. >> >> - The editing coordinates for all JTables are reset to -1. Before this patch, even non-editable JTables had their coordinates reset to 0 from -1 because the fields were transient. > > Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-6441373 > - Update JTableSerialization.java > - 6441373: Editing JTable is not Serializable Fix is working fine. LGTM. ------------- PR Review: https://git.openjdk.org/jdk/pull/29313#pullrequestreview-3720658724 From prr at openjdk.org Thu Jan 29 04:53:11 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 29 Jan 2026 04:53:11 GMT Subject: Integrated: 8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 04:23:33 GMT, Phil Race wrote: > AppContext is removed from Swing LAF state. Tests which require it are deleted. This pull request has now been integrated. Changeset: 62c7e9ae Author: Phil Race URL: https://git.openjdk.org/jdk/commit/62c7e9aefd4320d9d0cd8fa10610f59abb4de670 Stats: 235 lines in 6 files changed: 36 ins; 190 del; 9 mod 8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter Reviewed-by: aivanov, tr ------------- PR: https://git.openjdk.org/jdk/pull/29437 From psadhukhan at openjdk.org Thu Jan 29 05:09:20 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 29 Jan 2026 05:09:20 GMT Subject: RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE [v3] In-Reply-To: References: <3NeXqnAvhKti4-KGACJHdAV3NSJmbLlyBTBvueTyTms=.76d1ef32-b318-4f88-aeec-8321504de002@github.com> Message-ID: On Thu, 29 Jan 2026 03:26:42 GMT, Sergey Bylokhov wrote: >> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 970: >> >>> 968: invalidate(); >>> 969: >>> 970: } >> >> Does this newly added blank line right before the closing brace of the method serve any purpose? I'd rather not add it. > > What happens if the new invoker is null, the old invoker is not null and the UI is null? Will we continue to receive events from the old invoker? Or this combination is not possible? It will not remove the old invoker listener nor it will add new invoker listener..it probably will receive events but I dont think the events will be acted upon because as per the code, It will just invalidate the container and the outcome is same as it was before [JDK-4938801](https://bugs.openjdk.org/browse/JDK-4938801) fix.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29377#discussion_r2739966839 From psadhukhan at openjdk.org Thu Jan 29 07:11:38 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 29 Jan 2026 07:11:38 GMT Subject: RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE [v3] In-Reply-To: References: <3NeXqnAvhKti4-KGACJHdAV3NSJmbLlyBTBvueTyTms=.76d1ef32-b318-4f88-aeec-8321504de002@github.com> Message-ID: <7-YyhClT0_NTFQoqGJ2AHx_Q9RgpdUxYsa96DS1WTbk=.4531b390-60e7-49a8-a4f8-043b26bed91d@github.com> On Thu, 29 Jan 2026 05:06:50 GMT, Prasanta Sadhukhan wrote: >> What happens if the new invoker is null, the old invoker is not null and the UI is null? Will we continue to receive events from the old invoker? Or this combination is not possible? > > It will not remove the old invoker listener nor it will add new invoker listener..it probably will receive events but I dont think the events will be acted upon because as per the code, It will just invalidate the container > and the outcome is same as it was before [JDK-4938801](https://bugs.openjdk.org/browse/JDK-4938801) fix.. Also, I dont think ui null is valid combination as it means the L&F delegate is not set yet which normally handles the listeners ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29377#discussion_r2740258054 From mkartashev at openjdk.org Thu Jan 29 08:17:59 2026 From: mkartashev at openjdk.org (Maxim Kartashev) Date: Thu, 29 Jan 2026 08:17:59 GMT Subject: RFR: 8365313: GTK LaF does not respect system color scheme with Gnome In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 18:44:21 GMT, Alexander Zvegintsev wrote: > On some systems with the GNOME desktop environment, the dark theme does not automatically apply to the GTK look and feel. > This issue has been observed on Oracle Linux 10 (Gnome 47) and Fedora 42 (Gnome 48). However, Ubuntu with the same Gnome versions is not affected. > > To get it working, we should manually set the `gtk-application-prefer-dark-theme` setting on affected systems. These changes work fine on Ubuntu, too. > > > --- > > However, with this fix, the JDK will not detect a color scheme change on the fly (e.g., from light to dark when GTK LaF is active). The theme change will only apply if you switch to a different LaF and then back to GTK. > > Normally we would subscribe to `changed::color-scheme` signal to detect this change: > > > static void on_color_scheme_changed(GSettings *settings, gchar *key, gpointer user_data) { > gchar *value = g_settings_get_string(settings, key); > g_print("Color scheme changed: %s\n", value); > g_free(value); > } > ... > GSettings *settings = g_settings_new("org.gnome.desktop.interface"); > g_signal_connect(settings, "changed::color-scheme", G_CALLBACK(on_color_scheme_changed), NULL); > ... > g_object_unref(settings); > > > However, it requires a running GTK loop, which we do not have. > As a workaround, we could try finding a place in our code where we can check for a color scheme change to avoid introducing the GTK loop. > This issue is filed as [JDK-8376605](https://bugs.openjdk.org/browse/JDK-8376605) > > --- > > Testing looks good. Marked as reviewed by mkartashev (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29469#pullrequestreview-3721275310 From duke at openjdk.org Thu Jan 29 10:12:11 2026 From: duke at openjdk.org (duke) Date: Thu, 29 Jan 2026 10:12:11 GMT Subject: RFR: 8375011: OldJTable.java - NullPointerException when columnData is null [v4] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 03:23:49 GMT, Anupam Dev wrote: >> Hi, >> >> This is a fix for NPE in OldJTable.addColumn >> >> The addColumn method in OldJTable.java was unconditionally calling columnData.toArray(), which caused a NullPointerException when columnData was null (e.g., when called from addColumn(Object, int)). >> >> This commit adds a null check to safe-guard against this NPE, passing null to the underlying DefaultTableModel when columnData is missing. >> >> Kindly review. >> >> Regards, >> Anupam > > Anupam Dev has updated the pull request incrementally with one additional commit since the last revision: > > Removed obsolete OldJTable from demo @anupamdev20 Your change (at version 7723e2b1e64d66a0f3664f65450238f6e94f3d23) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29226#issuecomment-3816680843 From aivanov at openjdk.org Thu Jan 29 12:53:05 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 29 Jan 2026 12:53:05 GMT Subject: [jdk26] RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 02:33:24 GMT, Prasanta Sadhukhan wrote: > 8376169: JPopupMenu.setInvoker(null) causes NPE Looks good to me. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29477#pullrequestreview-3722504366 From azvegint at openjdk.org Thu Jan 29 14:33:34 2026 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 29 Jan 2026 14:33:34 GMT Subject: [jdk26] RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 02:33:24 GMT, Prasanta Sadhukhan wrote: > 8376169: JPopupMenu.setInvoker(null) causes NPE Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29477#pullrequestreview-3723100921 From azvegint at openjdk.org Thu Jan 29 14:58:00 2026 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 29 Jan 2026 14:58:00 GMT Subject: RFR: 8365313: GTK LaF does not respect system color scheme with Gnome In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 00:24:01 GMT, Sergey Bylokhov wrote: > maybe we should provide a way to set this by the application? similar to how we did on macOS? In another fix - maybe. Currently, setting the `gtk-application-prefer-dark-theme` is not enough to override the theme on Ubuntu 25.04 with Gnome 48, it still uses the system theme. This differs from Fedora 42 with Gnome 48, where it is sufficient. More research is required, but not in this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29469#issuecomment-3818208261 From azvegint at openjdk.org Thu Jan 29 15:14:48 2026 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 29 Jan 2026 15:14:48 GMT Subject: RFR: 8376510: Raster.createBandedRaster(int, int, int, int, int[], int[], Point) does not check for negative scanlineStride In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 19:04:04 GMT, Phil Race wrote: > We specify that scanlineStride < 0 will throw IAE, but it was not checked up front in all cases, so sometimes would be IAE and sometimes NegativeArrayIndexException. > Add an explicit check. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29454#pullrequestreview-3723337153 From azvegint at openjdk.org Thu Jan 29 15:28:58 2026 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 29 Jan 2026 15:28:58 GMT Subject: RFR: 8376297: ArrayIndexOutOfBoundsException Not Documented for SinglePixelPackedSampleModel.getSampleSize(int) In-Reply-To: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com> References: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com> Message-ID: On Tue, 27 Jan 2026 22:51:27 GMT, Phil Race wrote: > Update the specification of concrete SampleModel classes which over-ride getSampleSize(int band) to describe how the behave. > It isn't entirely pretty because 2 of them ignore the band parameter and always have .. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29457#pullrequestreview-3723419051 From kizune at openjdk.org Thu Jan 29 16:35:10 2026 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 29 Jan 2026 16:35:10 GMT Subject: RFR: 8365313: GTK LaF does not respect system color scheme with Gnome In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 18:44:21 GMT, Alexander Zvegintsev wrote: > On some systems with the GNOME desktop environment, the dark theme does not automatically apply to the GTK look and feel. > This issue has been observed on Oracle Linux 10 (Gnome 47) and Fedora 42 (Gnome 48). However, Ubuntu with the same Gnome versions is not affected. > > To get it working, we should manually set the `gtk-application-prefer-dark-theme` setting on affected systems. These changes work fine on Ubuntu, too. > > > --- > > However, with this fix, the JDK will not detect a color scheme change on the fly (e.g., from light to dark when GTK LaF is active). The theme change will only apply if you switch to a different LaF and then back to GTK. > > Normally we would subscribe to `changed::color-scheme` signal to detect this change: > > > static void on_color_scheme_changed(GSettings *settings, gchar *key, gpointer user_data) { > gchar *value = g_settings_get_string(settings, key); > g_print("Color scheme changed: %s\n", value); > g_free(value); > } > ... > GSettings *settings = g_settings_new("org.gnome.desktop.interface"); > g_signal_connect(settings, "changed::color-scheme", G_CALLBACK(on_color_scheme_changed), NULL); > ... > g_object_unref(settings); > > > However, it requires a running GTK loop, which we do not have. > As a workaround, we could try finding a place in our code where we can check for a color scheme change to avoid introducing the GTK loop. > This issue is filed as [JDK-8376605](https://bugs.openjdk.org/browse/JDK-8376605) > > --- > > Testing looks good. Looks good ------------- Marked as reviewed by kizune (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29469#pullrequestreview-3723803543 From kizune at openjdk.org Thu Jan 29 16:42:42 2026 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 29 Jan 2026 16:42:42 GMT Subject: RFR: 8374506: Incorrect positioning of arrow icon in parent JMenu in Windows L&F In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 05:11:37 GMT, Prasanta Sadhukhan wrote: > Arrow icon of JMenuItem in JMenu which is used to invoke the submenu overlaps with the menutext if the text is long. > > Fix is made to add a gap for arrow icon rect too similar to menu text and accelerator rects Marked as reviewed by kizune (Reviewer). With the fix it is better than without the fix - that is for sure, but the overall layout looks strange and majority of the arrow icon is being hidden behind the submenu's popup which is wrong. I am approving it as a stopgap solution but the overall we might want to re-visit how we calculate layouts of menu items to make it look more like a OS native menus. ------------- PR Review: https://git.openjdk.org/jdk/pull/29375#pullrequestreview-3723843212 PR Comment: https://git.openjdk.org/jdk/pull/29375#issuecomment-3818883539 From kizune at openjdk.org Thu Jan 29 16:58:25 2026 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 29 Jan 2026 16:58:25 GMT Subject: RFR: 8376297: ArrayIndexOutOfBoundsException Not Documented for SinglePixelPackedSampleModel.getSampleSize(int) In-Reply-To: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com> References: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com> Message-ID: On Tue, 27 Jan 2026 22:51:27 GMT, Phil Race wrote: > Update the specification of concrete SampleModel classes which over-ride getSampleSize(int band) to describe how the behave. > It isn't entirely pretty because 2 of them ignore the band parameter and always have .. Looks good ------------- Marked as reviewed by kizune (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29457#pullrequestreview-3723921376 From aivanov at openjdk.org Thu Jan 29 17:19:53 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 29 Jan 2026 17:19:53 GMT Subject: RFR: 8374506: Incorrect positioning of arrow icon in parent JMenu in Windows L&F In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 05:11:37 GMT, Prasanta Sadhukhan wrote: > Arrow icon of JMenuItem in JMenu which is used to invoke the submenu overlaps with the menutext if the text is long. > > Fix is made to add a gap for arrow icon rect too similar to menu text and accelerator rects I agree with @azuev-java, it looks better this way. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29375#pullrequestreview-3724048205 From aivanov at openjdk.org Thu Jan 29 17:28:58 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 29 Jan 2026 17:28:58 GMT Subject: RFR: 8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter [v3] In-Reply-To: References: <8bBXkiJAJAIxN_v13DKjGdVrQGYqiBWrP83z929xEr4=.e30fa39a-db22-4c2f-b453-a7e5180030be@github.com> Message-ID: On Wed, 28 Jan 2026 21:56:14 GMT, Phil Race wrote: > I'm trying (as much as I can) to remove them only when they fail, so I can relate it closely to a specific place where AppContext is removed. > > So I'll not remove those additional tests here, but soon enough they'll go. Thanks! I'd follow the same approach. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29437#issuecomment-3819155513 From dnguyen at openjdk.org Thu Jan 29 17:38:42 2026 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 29 Jan 2026 17:38:42 GMT Subject: RFR: 8375057: Update HarfBuzz to 12.3.2 Message-ID: <4VKAIWM9Ud-2zdY7NhEw1dCek4mTTVPC3tx_6HAKARE=.e03f6f17-ff2a-408f-bd50-f071b296dce3@github.com> HarfBuzz updated to 12.3.2 2 new files 1 renamed file 170 updated files ------------- Commit messages: - Fix whitespace issues - Update md file - Initial commit - Initial commit Changes: https://git.openjdk.org/jdk/pull/29475/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29475&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375057 Stats: 14888 lines in 173 files changed: 5161 ins; 3058 del; 6669 mod Patch: https://git.openjdk.org/jdk/pull/29475.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29475/head:pull/29475 PR: https://git.openjdk.org/jdk/pull/29475 From aivanov at openjdk.org Thu Jan 29 17:40:50 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 29 Jan 2026 17:40:50 GMT Subject: RFR: 8376420: Remove AppContext from javax/swing/ImageIcon.java [v2] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 21:11:58 GMT, Phil Race wrote: >> Remove per-AppContext MediaTracker from ImageIcon.java > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8376420 Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29433#pullrequestreview-3724137660 From aivanov at openjdk.org Thu Jan 29 17:40:51 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 29 Jan 2026 17:40:51 GMT Subject: RFR: 8376420: Remove AppContext from javax/swing/ImageIcon.java [v2] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 21:06:27 GMT, Sergey Bylokhov wrote: > > Does an app need direct access to the `MediaTracker` that's used to download the image? Probably not, therefore a private member is better. > > The application will have this access via getter already I'm confused? Where's a getter in `ImageIcon` that an app can use to get a `MediaTracker` instance? The `getTracker` method is *private*. > the problematic part here is access to the Component which is mutable so we cannot use it via final field. The `component` field is *final*. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29433#discussion_r2742775613 From aivanov at openjdk.org Thu Jan 29 17:40:54 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 29 Jan 2026 17:40:54 GMT Subject: RFR: 8376420: Remove AppContext from javax/swing/ImageIcon.java [v2] In-Reply-To: <3EfuPEC0euZkOQ9wourgdcCZxgwM0xJ4-XpxKjf4uVQ=.d84b33c8-c4d9-4d6a-b5f6-ed1984209644@github.com> References: <3EfuPEC0euZkOQ9wourgdcCZxgwM0xJ4-XpxKjf4uVQ=.d84b33c8-c4d9-4d6a-b5f6-ed1984209644@github.com> Message-ID: <1v96V2xCs7ksCxruBZCdPuVT211T0fwnSAfAU6Klb74=.23d6149a-43cb-4396-a36b-f2bda87237c8@github.com> On Wed, 28 Jan 2026 20:31:00 GMT, Phil Race wrote: >> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 346: >> >>> 344: } >>> 345: >>> 346: private static final MediaTracker MEDIA_TRACKER = new MediaTracker(new Component() {}); >> >> Is there a particular reason to create a new anonymous class extending `Component` instead of simply instantiating? >> >> >> new MediaTracker(new Component()); >> >> >> Is it only to follow what `createComponent` does? >> >> With the removal of `AppContext` and `SecurityManager`, is the anonymous class still necessary? > > Component is an abstract class. Yeah, I missed it? I should've looked more thoroughly at the declaration of the `Component` class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29433#discussion_r2742778775 From aivanov at openjdk.org Thu Jan 29 17:57:54 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 29 Jan 2026 17:57:54 GMT Subject: RFR: 8376420: Remove AppContext from javax/swing/ImageIcon.java [v2] In-Reply-To: <1v96V2xCs7ksCxruBZCdPuVT211T0fwnSAfAU6Klb74=.23d6149a-43cb-4396-a36b-f2bda87237c8@github.com> References: <3EfuPEC0euZkOQ9wourgdcCZxgwM0xJ4-XpxKjf4uVQ=.d84b33c8-c4d9-4d6a-b5f6-ed1984209644@github.com> <1v96V2xCs7ksCxruBZCdPuVT211T0fwnSAfAU6Klb74=.23d6149a-43cb-4396-a36b-f2bda87237c8@github.com> Message-ID: On Thu, 29 Jan 2026 17:37:01 GMT, Alexey Ivanov wrote: >> Component is an abstract class. > > Yeah, I missed it? I should've looked more thoroughly at the declaration of the `Component` class. I wonder if creating a final static class extending `Component` is more efficient than creating two anonymous classes for the `component` file and for the media tracker. However, it's a micro-optimisation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29433#discussion_r2742844283 From dnguyen at openjdk.org Thu Jan 29 18:08:14 2026 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 29 Jan 2026 18:08:14 GMT Subject: RFR: 8375057: Update HarfBuzz to 12.3.2 In-Reply-To: <4VKAIWM9Ud-2zdY7NhEw1dCek4mTTVPC3tx_6HAKARE=.e03f6f17-ff2a-408f-bd50-f071b296dce3@github.com> References: <4VKAIWM9Ud-2zdY7NhEw1dCek4mTTVPC3tx_6HAKARE=.e03f6f17-ff2a-408f-bd50-f071b296dce3@github.com> Message-ID: <87D96VEIG_CZQSmidbIib0eje_Z7uQaI9kyuyZg1S_s=.65c4efb8-f099-44c6-b4ca-e99800003a98@github.com> On Thu, 29 Jan 2026 00:32:40 GMT, Damon Nguyen wrote: > HarfBuzz updated to 12.3.2 > > 2 new files > 1 renamed file > 170 updated files @jayathirthrao @azuev-java Could you please review this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29475#issuecomment-3819336450 From aivanov at openjdk.org Thu Jan 29 18:54:09 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 29 Jan 2026 18:54:09 GMT Subject: RFR: 8376297: ArrayIndexOutOfBoundsException Not Documented for SinglePixelPackedSampleModel.getSampleSize(int) In-Reply-To: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com> References: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com> Message-ID: On Tue, 27 Jan 2026 22:51:27 GMT, Phil Race wrote: > Update the specification of concrete SampleModel classes which over-ride getSampleSize(int band) to describe how the behave. > It isn't entirely pretty because 2 of them ignore the band parameter and always have .. Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/java/awt/image/MultiPixelPackedSampleModel.java line 242: > 240: * this method ignores the {@code band} parameter and returns > 241: * the sample size of the single band. > 242: * @param band the specified band (ignored). Suggestion: * @param band the specified band (ignored) For consistency with other methods which don't have the full stop in description of parameters. test/jdk/java/awt/image/GetSampleSizeTest.java line 1: > 1: /* I suggest creating `test-` methods rather than using a code block inside the `main` method and call the methods from main, it would make the code better structured and convey the intent clearer. test/jdk/java/awt/image/GetSampleSizeTest.java line 47: > 45: ComponentSampleModel csm = > 46: new ComponentSampleModel(DataBuffer.TYPE_BYTE, > 47: width, height, 1, width, bandOffsets); Suggestion: ComponentSampleModel csm = new ComponentSampleModel(DataBuffer.TYPE_BYTE, width, height, 1, width, bandOffsets); Indent the continuation lines by 8 spaces which is the standard indentation for continuation lines. test/jdk/java/awt/image/GetSampleSizeTest.java line 59: > 57: MultiPixelPackedSampleModel mppsm = > 58: new MultiPixelPackedSampleModel(DataBuffer.TYPE_BYTE, > 59: width, height, 4); Suggestion: MultiPixelPackedSampleModel mppsm = new MultiPixelPackedSampleModel(DataBuffer.TYPE_BYTE, width, height, 4); Indent the continuation lines by 8 spaces test/jdk/java/awt/image/GetSampleSizeTest.java line 72: > 70: new SinglePixelPackedSampleModel(DataBuffer.TYPE_BYTE, > 71: width, height, bitMask); > 72: int numBands = sppsm.getNumBands(); Suggestion: SinglePixelPackedSampleModel sppsm = new SinglePixelPackedSampleModel(DataBuffer.TYPE_BYTE, width, height, bitMask); int numBands = sppsm.getNumBands(); Indent the continuation lines by 8 spaces; `numBands` isn't a continuation line, and it should align to `SinglePixelPackedSampleModel` declaration. test/jdk/java/awt/image/GetSampleSizeTest.java line 76: > 74: if (numBands != 4) { > 75: throw new RuntimeException("Unexpected numBands"); > 76: } Suggestion: if (numBands != 4) { throw new RuntimeException("Unexpected numBands"); } Misaligned closing brace. ------------- PR Review: https://git.openjdk.org/jdk/pull/29457#pullrequestreview-3724404777 PR Review Comment: https://git.openjdk.org/jdk/pull/29457#discussion_r2743009235 PR Review Comment: https://git.openjdk.org/jdk/pull/29457#discussion_r2743039318 PR Review Comment: https://git.openjdk.org/jdk/pull/29457#discussion_r2743019932 PR Review Comment: https://git.openjdk.org/jdk/pull/29457#discussion_r2743024796 PR Review Comment: https://git.openjdk.org/jdk/pull/29457#discussion_r2743029588 PR Review Comment: https://git.openjdk.org/jdk/pull/29457#discussion_r2743031578 From prr at openjdk.org Thu Jan 29 18:57:10 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 29 Jan 2026 18:57:10 GMT Subject: Integrated: 8376510: Raster.createBandedRaster(int, int, int, int, int[], int[], Point) does not check for negative scanlineStride In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 19:04:04 GMT, Phil Race wrote: > We specify that scanlineStride < 0 will throw IAE, but it was not checked up front in all cases, so sometimes would be IAE and sometimes NegativeArrayIndexException. > Add an explicit check. This pull request has now been integrated. Changeset: 69c868d5 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/69c868d5b7fdeaf38d6a45b75d68bf51b6ee7188 Stats: 7 lines in 2 files changed: 3 ins; 0 del; 4 mod 8376510: Raster.createBandedRaster(int, int, int, int, int[], int[], Point) does not check for negative scanlineStride Reviewed-by: serb, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/29454 From adev at openjdk.org Thu Jan 29 19:02:14 2026 From: adev at openjdk.org (Anupam Dev) Date: Thu, 29 Jan 2026 19:02:14 GMT Subject: Integrated: 8375011: OldJTable.java - NullPointerException when columnData is null In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 10:21:40 GMT, Anupam Dev wrote: > Hi, > > This is a fix for NPE in OldJTable.addColumn > > The addColumn method in OldJTable.java was unconditionally calling columnData.toArray(), which caused a NullPointerException when columnData was null (e.g., when called from addColumn(Object, int)). > > This commit adds a null check to safe-guard against this NPE, passing null to the underlying DefaultTableModel when columnData is missing. > > Kindly review. > > Regards, > Anupam This pull request has now been integrated. Changeset: 9470aa31 Author: Anupam Dev Committer: Phil Race URL: https://git.openjdk.org/jdk/commit/9470aa31175b504fcef15a932825dbc9e0532234 Stats: 264 lines in 1 file changed: 0 ins; 264 del; 0 mod 8375011: OldJTable.java - NullPointerException when columnData is null Reviewed-by: prr, psadhukhan, tr ------------- PR: https://git.openjdk.org/jdk/pull/29226 From kizune at openjdk.org Thu Jan 29 20:05:45 2026 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 29 Jan 2026 20:05:45 GMT Subject: [jdk26] RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 02:33:24 GMT, Prasanta Sadhukhan wrote: > 8376169: JPopupMenu.setInvoker(null) causes NPE Marked as reviewed by kizune (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29477#pullrequestreview-3724758459 From prr at openjdk.org Thu Jan 29 20:08:06 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 29 Jan 2026 20:08:06 GMT Subject: RFR: 8376747: Remove AppContext from Swing LayoutStyle Message-ID: A small one. No tests fail with this removal. ------------- Commit messages: - 8376747 Changes: https://git.openjdk.org/jdk/pull/29492/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29492&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376747 Stats: 9 lines in 1 file changed: 3 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29492.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29492/head:pull/29492 PR: https://git.openjdk.org/jdk/pull/29492 From duke at openjdk.org Thu Jan 29 21:26:48 2026 From: duke at openjdk.org (Thomas Devoogdt) Date: Thu, 29 Jan 2026 21:26:48 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries Message-ID: This to support linux headless mode without X11. E.g. A headless server. ------------- Commit messages: - 8376684: doc: fix X11 description when compiling headless - 8376684: autoconf: libraries: drop the need for X11 in headless mode - 8376684: awt: fix HEADLESS compilation without X11 Changes: https://git.openjdk.org/jdk/pull/28310/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28310&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376684 Stats: 30 lines in 5 files changed: 14 ins; 5 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/28310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28310/head:pull/28310 PR: https://git.openjdk.org/jdk/pull/28310 From duke at openjdk.org Thu Jan 29 21:26:49 2026 From: duke at openjdk.org (Thomas Devoogdt) Date: Thu, 29 Jan 2026 21:26:49 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 22:17:23 GMT, Thomas Devoogdt wrote: > This to support linux headless mode without X11. E.g. A headless server. > Hi @ThomasDevoogdt, welcome to this OpenJDK project and thanks for contributing! > > We do not recognize you as [Contributor](https://openjdk.java.net/bylaws#contributor) and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow [the instructions](https://oca.opensource.oracle.com/). Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing `/signed` in a comment in this pull request. > > If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user ThomasDevoogdt" as summary for the issue. > > If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing `/covered` in a comment in this pull request. @zhaosongzs I don't know who to address here. I can't create an issue for this PR as I don't have an OpenJDK account. I'm also awaiting OCA. Hi all, the buildroot people have merged this functionality upstream (https://github.com/buildroot/buildroot/commit/3dd73c30d387b235589275bad729e66619d062c3). Is it also possible to handle this PR here? @tstuefe @magicus ------------- PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3531547157 PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3531574662 PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3710324642 From zsong at openjdk.org Thu Jan 29 21:26:49 2026 From: zsong at openjdk.org (Zhao Song) Date: Thu, 29 Jan 2026 21:26:49 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 22:17:23 GMT, Thomas Devoogdt wrote: > This to support linux headless mode without X11. E.g. A headless server. @robilad will handle your OCA when he is available. For the jbs issue, you need to ask someone with jbs account to create the issue for you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3533868907 From duke at openjdk.org Thu Jan 29 21:26:50 2026 From: duke at openjdk.org (Thomas Devoogdt) Date: Thu, 29 Jan 2026 21:26:50 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: References: Message-ID: On Fri, 14 Nov 2025 17:42:47 GMT, Zhao Song wrote: > @robilad will handle your OCA when he is available. > > For the jbs issue, you need to ask someone with jbs account to create the issue for you. @zhaosongzs And who is someone? I'm not affiliated with oracle, I don't know who to address. Ideally I could just leave it from here, and having someone who picks this up for me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3534081614 From kcr at openjdk.org Thu Jan 29 21:26:51 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 29 Jan 2026 21:26:51 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: References: Message-ID: On Fri, 14 Nov 2025 18:39:55 GMT, Thomas Devoogdt wrote: >> @robilad will handle your OCA when he is available. >> >> For the jbs issue, you need to ask someone with jbs account to create the issue for you. > >> @robilad will handle your OCA when he is available. >> >> For the jbs issue, you need to ask someone with jbs account to create the issue for you. > > @zhaosongzs And who is someone? I'm not affiliated with oracle, I don't know who to address. Ideally I could just leave it from here, and having someone who picks this up for me. @ThomasDevoogdt I recommend you read the OpenJDK Developers' guide, particularly [this section on proposing changes to the OpenJDK code](https://openjdk.org/guide/#things-to-consider-before-proposing-changes-to-openjdk-code). The mailing list on which to discuss this proposed change is [client-libs-dev at openjdk.org](mailto:client-libs-dev at openjdk.org). As for the OCA, if you work for an employer who is already an OCA signatory, which is what entering `/covered` means, no action is needed from you at this time. If you don't, you need to follow the instructions in the OpenJDK Developer's Guide to sign it as an individual contributor, and enter `/signed` in a comment. Either way, you will need to wait for your OCA to be processed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3534908960 From stuefe at openjdk.org Thu Jan 29 21:26:52 2026 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 29 Jan 2026 21:26:52 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 22:17:23 GMT, Thomas Devoogdt wrote: > This to support linux headless mode without X11. E.g. A headless server. ping @magicus Sorry, this keeps falling through the cracks. I opened https://bugs.openjdk.org/browse/JDK-8376684 - I guess Alexey was snowed in. But I am no expert in this area; @magicus and @prrace should look at this. If this gets pushed, downporting it to LTSes is possible. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3616561369 PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3816620358 From duke at openjdk.org Thu Jan 29 21:26:53 2026 From: duke at openjdk.org (Thomas Devoogdt) Date: Thu, 29 Jan 2026 21:26:53 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: References: Message-ID: On Fri, 5 Dec 2025 11:46:36 GMT, Thomas Stuefe wrote: >> This to support linux headless mode without X11. E.g. A headless server. > > ping @magicus @tstuefe @magicus ping ... And is it possible that someone already create an official issue number for it, so that I can finish all the formal stuff? > Sorry, this keeps falling through the cracks. I opened https://bugs.openjdk.org/browse/JDK-8376684 - I guess Alexey was snowed in. > > But I am no expert in this area; @magicus and @prrace should look at this. > > If this gets pushed, downporting it to LTSes is possible. Thanks for creating the issue. I've updated the commits with the issue tag. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3638535424 PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3820397618 From aivanov at openjdk.org Thu Jan 29 21:26:54 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 29 Jan 2026 21:26:54 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 12:59:31 GMT, Thomas Devoogdt wrote: >> This to support linux headless mode without X11. E.g. A headless server. > > Hi all, the buildroot people have merged this functionality upstream (https://github.com/buildroot/buildroot/commit/3dd73c30d387b235589275bad729e66619d062c3). Is it also possible to handle this PR here? > > @tstuefe @magicus @ThomasDevoogdt A PR isn't announced on the mailing list until it's *ready for review* which includes a valid JBS bug. I suggest you write an email to build-dev and client-libs-dev mailing lists to propose this change and discuss it. I haven't found an existing issue in JBS for not requiring X11 libraries in headless mode. I can submit one on your behalf. If I have time, I'll test your patch locally and run it in the Oracle CI. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3712001940 From duke at openjdk.org Thu Jan 29 21:26:55 2026 From: duke at openjdk.org (Thomas Devoogdt) Date: Thu, 29 Jan 2026 21:26:55 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 12:59:31 GMT, Thomas Devoogdt wrote: >> This to support linux headless mode without X11. E.g. A headless server. > > Hi all, the buildroot people have merged this functionality upstream (https://github.com/buildroot/buildroot/commit/3dd73c30d387b235589275bad729e66619d062c3). Is it also possible to handle this PR here? > > @tstuefe @magicus > @ThomasDevoogdt A PR isn't announced on the mailing list until it's *ready for review* which includes a valid JBS bug. > > I suggest you write an email to build-dev and client-libs-dev mailing lists to propose this change and discuss it. I haven't found an existing issue in JBS for not requiring X11 libraries in headless mode. I can submit one on your behalf. @aivanov-jdk Yes, please do so! > If I have time, I'll test your patch locally and run it in the Oracle CI. Yeah, sorry for all the spam, but I really really don't know how to get any attention here. I simply don't understand how to file a bug without account, how to announce a change and so on. So every little help is much appreciated! Thx! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3712135725 From duke at openjdk.org Thu Jan 29 21:26:55 2026 From: duke at openjdk.org (Thomas Devoogdt) Date: Thu, 29 Jan 2026 21:26:55 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 20:36:40 GMT, Alexey Ivanov wrote: >> Hi all, the buildroot people have merged this functionality upstream (https://github.com/buildroot/buildroot/commit/3dd73c30d387b235589275bad729e66619d062c3). Is it also possible to handle this PR here? >> >> @tstuefe @magicus > > @ThomasDevoogdt A PR isn't announced on the mailing list until it's *ready for review* which includes a valid JBS bug. > > I suggest you write an email to build-dev and client-libs-dev mailing lists to propose this change and discuss it. I haven't found an existing issue in JBS for not requiring X11 libraries in headless mode. I can submit one on your behalf. > > If I have time, I'll test your patch locally and run it in the Oracle CI. @aivanov-jdk ping ------------- PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3769989683 From dholmes at openjdk.org Thu Jan 29 21:49:24 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Jan 2026 21:49:24 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: References: Message-ID: <3REbDAeUgHla11SMvGGwt518wd1m1MEwXz-A48xRdcs=.28410df3-fb72-4185-b84c-1a90e4811483@github.com> On Thu, 13 Nov 2025 22:17:23 GMT, Thomas Devoogdt wrote: > This to support linux headless mode without X11. E.g. A headless server. I just updated the JBS issue with a couple of links. This is certainly not a new issue and there is an existing RFE to deal with the source code dependencies on X11. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3820573064 From aivanov at openjdk.org Thu Jan 29 22:14:09 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 29 Jan 2026 22:14:09 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: References: Message-ID: <9vC8xA88gjCkT7b2H1tjbNURPIGOqYRgqRxBZXoahWM=.59e0a718-c0d1-4329-bebf-af1267bc05bc@github.com> On Thu, 13 Nov 2025 22:17:23 GMT, Thomas Devoogdt wrote: > This to support linux headless mode without X11. E.g. A headless server. This looks like a regression then. [JDK-8255785](https://bugs.openjdk.org/browse/JDK-8255785) made it possible, see https://github.com/openjdk/jdk/commit/f97ec359 ------------- PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3820700275 From aivanov at openjdk.org Thu Jan 29 22:17:26 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 29 Jan 2026 22:17:26 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 21:18:42 GMT, Thomas Devoogdt wrote: >> Sorry, this keeps falling through the cracks. I opened https://bugs.openjdk.org/browse/JDK-8376684 - I guess Alexey was snowed in. >> >> But I am no expert in this area; @magicus and @prrace should look at this. >> >> If this gets pushed, downporting it to LTSes is possible. > >> Sorry, this keeps falling through the cracks. I opened https://bugs.openjdk.org/browse/JDK-8376684 - I guess Alexey was snowed in. >> >> But I am no expert in this area; @magicus and @prrace should look at this. >> >> If this gets pushed, downporting it to LTSes is possible. > > Thanks for creating the issue. I've updated the commits with the issue tag. @ThomasDevoogdt Please, *do not force-push any more*. Instead, pull changes from upstream master and *merge* master into your branch. Force-pushing invalidates comments left in the code review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3820709314 From prr at openjdk.org Thu Jan 29 22:35:36 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 29 Jan 2026 22:35:36 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 21:18:42 GMT, Thomas Devoogdt wrote: >> Sorry, this keeps falling through the cracks. I opened https://bugs.openjdk.org/browse/JDK-8376684 - I guess Alexey was snowed in. >> >> But I am no expert in this area; @magicus and @prrace should look at this. >> >> If this gets pushed, downporting it to LTSes is possible. > >> Sorry, this keeps falling through the cracks. I opened https://bugs.openjdk.org/browse/JDK-8376684 - I guess Alexey was snowed in. >> >> But I am no expert in this area; @magicus and @prrace should look at this. >> >> If this gets pushed, downporting it to LTSes is possible. > > Thanks for creating the issue. I've updated the commits with the issue tag. > @ThomasDevoogdt A PR isn't announced on the mailing list until it's _ready for review_ which includes a valid JBS bug. > > I suggest you write an email to build-dev and client-libs-dev mailing lists to propose this change and discuss it. I haven't found an existing issue in JBS for not requiring X11 libraries in headless mode. I can submit one on your behalf. > > If I have time, I'll test your patch locally and run it in the Oracle CI. All our build systems have X11. So a test build there doesn't prove much, and also it can easily regress. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3820768881 From prr at openjdk.org Thu Jan 29 23:14:30 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 29 Jan 2026 23:14:30 GMT Subject: RFR: 8376755: Remove AppContext from Swing javax/swing/plaf/basic classes Message-ID: <0AjFtP2_UXLP6zBNsu4hGWJHwOrD7Qit0klcwMtemWA=.e0d35933-90ad-456d-8313-bd9c18e954ca@github.com> Remove AppContext from the Swing basic plaf package One test is updated to use the now non-appcontext internal variables. ------------- Commit messages: - 8376755 - 8376755 Changes: https://git.openjdk.org/jdk/pull/29495/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29495&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376755 Stats: 156 lines in 10 files changed: 5 ins; 103 del; 48 mod Patch: https://git.openjdk.org/jdk/pull/29495.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29495/head:pull/29495 PR: https://git.openjdk.org/jdk/pull/29495 From prr at openjdk.org Thu Jan 29 23:36:08 2026 From: prr at openjdk.org (Phil Race) Date: Thu, 29 Jan 2026 23:36:08 GMT Subject: RFR: 8376297: ArrayIndexOutOfBoundsException Not Documented for SinglePixelPackedSampleModel.getSampleSize(int) [v2] In-Reply-To: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com> References: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com> Message-ID: > Update the specification of concrete SampleModel classes which over-ride getSampleSize(int band) to describe how the behave. > It isn't entirely pretty because 2 of them ignore the band parameter and always have .. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8376297 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29457/files - new: https://git.openjdk.org/jdk/pull/29457/files/b936635c..ebde5c8a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29457&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29457&range=00-01 Stats: 9 lines in 2 files changed: 0 ins; 2 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29457.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29457/head:pull/29457 PR: https://git.openjdk.org/jdk/pull/29457 From duke at openjdk.org Fri Jan 30 00:34:41 2026 From: duke at openjdk.org (duke) Date: Fri, 30 Jan 2026 00:34:41 GMT Subject: Withdrawn: 4617681: constructor of BufferedImage throws unexpected IllegalArgumentException In-Reply-To: References: Message-ID: On Sun, 5 Oct 2025 20:33:26 GMT, Phil Race wrote: > Specifying the behaviour of BufferedImage constructors for invalid dimensions is long overdue. > > The behaviour for image types and sizes <= 0 is unchanged by this PR. > Also in many cases the behaviour for sizes that are too large is also unchanged. > In some cases, the behaviour is changed from "accidental" NegativeArraySizeException to a consistent IllegalArgumentException. > > In no case is anything changed that would affect the possibility to construct a BufferedImage. > > A test is provided to ensure the behaviour. > > A CSR is provided too : https://bugs.openjdk.org/browse/JDK-8369155 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27640 From serb at openjdk.org Fri Jan 30 02:33:42 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 30 Jan 2026 02:33:42 GMT Subject: RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE [v3] In-Reply-To: <7-YyhClT0_NTFQoqGJ2AHx_Q9RgpdUxYsa96DS1WTbk=.4531b390-60e7-49a8-a4f8-043b26bed91d@github.com> References: <3NeXqnAvhKti4-KGACJHdAV3NSJmbLlyBTBvueTyTms=.76d1ef32-b318-4f88-aeec-8321504de002@github.com> <7-YyhClT0_NTFQoqGJ2AHx_Q9RgpdUxYsa96DS1WTbk=.4531b390-60e7-49a8-a4f8-043b26bed91d@github.com> Message-ID: On Thu, 29 Jan 2026 07:08:37 GMT, Prasanta Sadhukhan wrote: >> It will not remove the old invoker listener nor it will add new invoker listener..it probably will receive events but I dont think the events will be acted upon because as per the code, It will just invalidate the container >> and the outcome is same as it was before [JDK-4938801](https://bugs.openjdk.org/browse/JDK-4938801) fix.. > > Also, I dont think ui null is valid combination as it means the L&F delegate is not set yet which normally handles the listeners But the check for ui != null is there, and it should be possible to call this code when its null, no? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29377#discussion_r2744352084 From azvegint at openjdk.org Fri Jan 30 02:47:19 2026 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 30 Jan 2026 02:47:19 GMT Subject: Integrated: 8365313: GTK LaF does not respect system color scheme with Gnome In-Reply-To: References: Message-ID: <1_W0YKv6rmiCCXIxARlFNDVxLvg6IHwJHLj7HT06e5U=.53db05b5-374b-4e79-a5e5-cc5d1f1af9d4@github.com> On Wed, 28 Jan 2026 18:44:21 GMT, Alexander Zvegintsev wrote: > On some systems with the GNOME desktop environment, the dark theme does not automatically apply to the GTK look and feel. > This issue has been observed on Oracle Linux 10 (Gnome 47) and Fedora 42 (Gnome 48). However, Ubuntu with the same Gnome versions is not affected. > > To get it working, we should manually set the `gtk-application-prefer-dark-theme` setting on affected systems. These changes work fine on Ubuntu, too. > > > --- > > However, with this fix, the JDK will not detect a color scheme change on the fly (e.g., from light to dark when GTK LaF is active). The theme change will only apply if you switch to a different LaF and then back to GTK. > > Normally we would subscribe to `changed::color-scheme` signal to detect this change: > > > static void on_color_scheme_changed(GSettings *settings, gchar *key, gpointer user_data) { > gchar *value = g_settings_get_string(settings, key); > g_print("Color scheme changed: %s\n", value); > g_free(value); > } > ... > GSettings *settings = g_settings_new("org.gnome.desktop.interface"); > g_signal_connect(settings, "changed::color-scheme", G_CALLBACK(on_color_scheme_changed), NULL); > ... > g_object_unref(settings); > > > However, it requires a running GTK loop, which we do not have. > As a workaround, we could try finding a place in our code where we can check for a color scheme change to avoid introducing the GTK loop. > This issue is filed as [JDK-8376605](https://bugs.openjdk.org/browse/JDK-8376605) > > --- > > Testing looks good. This pull request has now been integrated. Changeset: 379dcb02 Author: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/379dcb0266bc90fac740eaa56b8027c7273e6d76 Stats: 74 lines in 5 files changed: 74 ins; 0 del; 0 mod 8365313: GTK LaF does not respect system color scheme with Gnome Reviewed-by: prr, mkartashev, kizune ------------- PR: https://git.openjdk.org/jdk/pull/29469 From psadhukhan at openjdk.org Fri Jan 30 03:20:38 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 30 Jan 2026 03:20:38 GMT Subject: RFR: 8376169: JPopupMenu.setInvoker(null) causes NPE [v3] In-Reply-To: References: <3NeXqnAvhKti4-KGACJHdAV3NSJmbLlyBTBvueTyTms=.76d1ef32-b318-4f88-aeec-8321504de002@github.com> <7-YyhClT0_NTFQoqGJ2AHx_Q9RgpdUxYsa96DS1WTbk=.4531b390-60e7-49a8-a4f8-043b26bed91d@github.com> Message-ID: On Fri, 30 Jan 2026 02:30:35 GMT, Sergey Bylokhov wrote: >> Also, I dont think ui null is valid combination as it means the L&F delegate is not set yet which normally handles the listeners > > But the check for ui != null is there, and it should be possible to call this code when its null, no? I didnt say setInvoker cannot be called with ui null..As I see and mentioned it probably will receive the events but it will not be acted upon as container is invalid and UI delegate handling the listener is not set yet and lastly whatever the course is, it is same now as it is before JDK-4938801 fix.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29377#discussion_r2744441521 From psadhukhan at openjdk.org Fri Jan 30 03:25:01 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 30 Jan 2026 03:25:01 GMT Subject: Integrated: 8374506: Incorrect positioning of arrow icon in parent JMenu in Windows L&F In-Reply-To: References: Message-ID: <-cB1GmijTHWO22UgFKXCgjj_oX8s6A2EHaWlPO_WKrw=.f82bbb4a-3987-4a37-a3e7-03678104e5df@github.com> On Fri, 23 Jan 2026 05:11:37 GMT, Prasanta Sadhukhan wrote: > Arrow icon of JMenuItem in JMenu which is used to invoke the submenu overlaps with the menutext if the text is long. > > Fix is made to add a gap for arrow icon rect too similar to menu text and accelerator rects This pull request has now been integrated. Changeset: 9a10ccee Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/9a10cceeafa5d332aa571f0d62acf50032a597d4 Stats: 102 lines in 2 files changed: 101 ins; 0 del; 1 mod 8374506: Incorrect positioning of arrow icon in parent JMenu in Windows L&F Reviewed-by: aivanov, kizune ------------- PR: https://git.openjdk.org/jdk/pull/29375 From duke at openjdk.org Fri Jan 30 07:44:10 2026 From: duke at openjdk.org (Thomas Devoogdt) Date: Fri, 30 Jan 2026 07:44:10 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: <3REbDAeUgHla11SMvGGwt518wd1m1MEwXz-A48xRdcs=.28410df3-fb72-4185-b84c-1a90e4811483@github.com> References: <3REbDAeUgHla11SMvGGwt518wd1m1MEwXz-A48xRdcs=.28410df3-fb72-4185-b84c-1a90e4811483@github.com> Message-ID: On Thu, 29 Jan 2026 21:46:17 GMT, David Holmes wrote: >> This to support linux headless mode without X11. E.g. A headless server. > > I just updated the JBS issue with a couple of links. This is certainly not a new issue and there is an existing RFE to deal with the source code dependencies on X11. @dholmes-ora @aivanov-jdk @prrace I can see that there are duplicated issues on this topic, and that regression is easy without proper testing, but is that a reason to not merge this kind of code? If new regressions occurs, then chances are big that someone will notice them, and push a new fix for it. Yes, buildroot is a bit behind upstream JDK, but at least there we will see it. https://github.com/buildroot/buildroot/commit/3dd73c30d387b235589275bad729e66619d062c3 Other distributions might also be interested. Are there actions needed on my side? Because that is not clear out of the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3822314701 From psadhukhan at openjdk.org Fri Jan 30 08:33:24 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 30 Jan 2026 08:33:24 GMT Subject: RFR: 8376747: Remove AppContext from Swing LayoutStyle In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 20:02:15 GMT, Phil Race wrote: > A small one. No tests fail with this removal. Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29492#pullrequestreview-3726998480 From psadhukhan at openjdk.org Fri Jan 30 08:34:47 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 30 Jan 2026 08:34:47 GMT Subject: Integrated: 8375573: JTable ignores setPreferredWidth during initial layout when AUTO_RESIZE_LAST_COLUMN is enabled In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 02:18:06 GMT, Prasanta Sadhukhan wrote: > AUTO_RESIZE_LAST_COLUMN handling was done in [JDK-8234071](https://bugs.openjdk.org/browse/JDK-8234071) but it didn't honour the preferred width if it is already been set for each column so when layouting is done, it only sees the `resizingColumn` > is set to AUTO_RESIZE_LAST_COLUMN and adjust only the last column and distribute width equally to all other column. > > Fix is made to honour the user-set preferred column width even if auto-resize mode is set to LAST_COLUMN This pull request has now been integrated. Changeset: 55375e98 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/55375e98ae1672badeacaaf2f8b6f2f21ad03437 Stats: 103 lines in 2 files changed: 101 ins; 0 del; 2 mod 8375573: JTable ignores setPreferredWidth during initial layout when AUTO_RESIZE_LAST_COLUMN is enabled Reviewed-by: tr ------------- PR: https://git.openjdk.org/jdk/pull/29291 From psadhukhan at openjdk.org Fri Jan 30 08:37:38 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 30 Jan 2026 08:37:38 GMT Subject: RFR: 8375567: Remove AppContext usage from Swing Motif L&F classes [v3] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 21:19:36 GMT, Phil Race wrote: >> Remove AppContext from the Swing Motif L&F implementation. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8375567 Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29282#pullrequestreview-3727013694 From psadhukhan at openjdk.org Fri Jan 30 09:12:48 2026 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 30 Jan 2026 09:12:48 GMT Subject: RFR: 8376420: Remove AppContext from javax/swing/ImageIcon.java [v2] In-Reply-To: References: Message-ID: <1kSr5A0eUzdFhr3waIX5a_VlsZEd1aNVKZS-Yhafm0Y=.0008964d-d065-4367-8f5a-14be5c9fd843@github.com> On Wed, 28 Jan 2026 21:11:58 GMT, Phil Race wrote: >> Remove per-AppContext MediaTracker from ImageIcon.java > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8376420 Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29433#pullrequestreview-3727161366 From aivanov at openjdk.org Fri Jan 30 12:56:09 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 30 Jan 2026 12:56:09 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: References: Message-ID: <4T5cSAaROTH9gsM3k0xeQxujShyN7JaW_E6TCewGTjY=.0349f633-1b2f-439b-a09d-7de741f794ac@github.com> On Thu, 29 Jan 2026 22:32:46 GMT, Phil Race wrote: > > If I have time, I'll test your patch locally and run it in the Oracle CI. > > All our build systems have X11. So a test build there doesn't prove much, and also it can easily regress. This is why I'm going to use a VM which doesn't have X11 headers installed. > is that a reason to not merge this kind of code? I think it's a good change. Looking at the history at which @dholmes-ora pointed, building headless JDK without X11 was supported, but it has become broken again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3823612106 From aivanov at openjdk.org Fri Jan 30 13:07:08 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 30 Jan 2026 13:07:08 GMT Subject: RFR: 8376297: ArrayIndexOutOfBoundsException Not Documented for SinglePixelPackedSampleModel.getSampleSize(int) [v2] In-Reply-To: References: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com> Message-ID: On Thu, 29 Jan 2026 23:36:08 GMT, Phil Race wrote: >> Update the specification of concrete SampleModel classes which over-ride getSampleSize(int band) to describe how the behave. >> It isn't entirely pretty because 2 of them ignore the band parameter and always have .. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8376297 Changes requested by aivanov (Reviewer). test/jdk/java/awt/image/GetSampleSizeTest.java line 47: > 45: ComponentSampleModel csm = > 46: new ComponentSampleModel(DataBuffer.TYPE_BYTE, > 47: width, height, 1, width, bandOffsets); I still think the lines 46?47 should be indented by 4 more spaces: either is a continuation line of the line above. Suggestion: ComponentSampleModel csm = new ComponentSampleModel(DataBuffer.TYPE_BYTE, width, height, 1, width, bandOffsets); However, the indentation is somewhat consistent now: lines 58 and 69 are also indented by 4 spaces only. Yet they should be indented by 8 spaces. test/jdk/java/awt/image/GetSampleSizeTest.java line 75: > 73: throw new RuntimeException("Unexpected numBands"); > 74: } > 75: try { Suggestion: if (numBands != 4) { throw new RuntimeException("Unexpected numBands"); } try { The brace that closes the `if` block is still indented incorrectly, it should be in the same column as `i` and `t` of `if` above and `try` below. ------------- PR Review: https://git.openjdk.org/jdk/pull/29457#pullrequestreview-3728155545 PR Review Comment: https://git.openjdk.org/jdk/pull/29457#discussion_r2746158825 PR Review Comment: https://git.openjdk.org/jdk/pull/29457#discussion_r2746164592 From erikj at openjdk.org Fri Jan 30 14:49:35 2026 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 30 Jan 2026 14:49:35 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 22:17:23 GMT, Thomas Devoogdt wrote: > This to support linux headless mode without X11. E.g. A headless server. >From a build point of view, this looks fine. Someone from client will need to review it too. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28310#pullrequestreview-3728768954 From azvegint at openjdk.org Fri Jan 30 16:39:21 2026 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 30 Jan 2026 16:39:21 GMT Subject: RFR: 8376747: Remove AppContext from Swing LayoutStyle In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 20:02:15 GMT, Phil Race wrote: > A small one. No tests fail with this removal. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29492#pullrequestreview-3729323613 From prr at openjdk.org Fri Jan 30 19:11:28 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 30 Jan 2026 19:11:28 GMT Subject: Integrated: 8375567: Remove AppContext usage from Swing Motif L&F classes In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 22:57:55 GMT, Phil Race wrote: > Remove AppContext from the Swing Motif L&F implementation. This pull request has now been integrated. Changeset: 32e00ff3 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/32e00ff33785f0756cb320cd8c0ffad8eda76153 Stats: 44 lines in 4 files changed: 0 ins; 36 del; 8 mod 8375567: Remove AppContext usage from Swing Motif L&F classes Reviewed-by: serb, psadhukhan ------------- PR: https://git.openjdk.org/jdk/pull/29282 From prr at openjdk.org Fri Jan 30 19:11:28 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 30 Jan 2026 19:11:28 GMT Subject: Integrated: 8376747: Remove AppContext from Swing LayoutStyle In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 20:02:15 GMT, Phil Race wrote: > A small one. No tests fail with this removal. This pull request has now been integrated. Changeset: 9ef98a5f Author: Phil Race URL: https://git.openjdk.org/jdk/commit/9ef98a5fb194eec3024b87ea9f9c9acee952dcf6 Stats: 9 lines in 1 file changed: 3 ins; 2 del; 4 mod 8376747: Remove AppContext from Swing LayoutStyle Reviewed-by: psadhukhan, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/29492 From prr at openjdk.org Fri Jan 30 19:32:18 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 30 Jan 2026 19:32:18 GMT Subject: Integrated: 8376420: Remove AppContext from javax/swing/ImageIcon.java In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 23:00:16 GMT, Phil Race wrote: > Remove per-AppContext MediaTracker from ImageIcon.java This pull request has now been integrated. Changeset: c62c82d5 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/c62c82d5e0485b8570bb1c61805e518fe05f3ec4 Stats: 32 lines in 1 file changed: 1 ins; 27 del; 4 mod 8376420: Remove AppContext from javax/swing/ImageIcon.java Reviewed-by: aivanov, psadhukhan ------------- PR: https://git.openjdk.org/jdk/pull/29433 From aivanov at openjdk.org Fri Jan 30 20:20:10 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 30 Jan 2026 20:20:10 GMT Subject: RFR: 8374506: Incorrect positioning of arrow icon in parent JMenu in Windows L&F In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 05:11:37 GMT, Prasanta Sadhukhan wrote: > Arrow icon of JMenuItem in JMenu which is used to invoke the submenu overlaps with the menutext if the text is long. > > Fix is made to add a gap for arrow icon rect too similar to menu text and accelerator rects > > The popup menu has to become wider if both check marks / bullets and icons are rendered at the same time. > > I am approving it as a stopgap solution but the overall we might want to re-visit how we calculate layouts of menu items to make it look more like a OS native menus. I've now submitted [JDK-8376828](https://bugs.openjdk.org/browse/JDK-8376828): *Improve JMenuItem layout in Windows L&F*. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29375#issuecomment-3825552367 From serb at openjdk.org Fri Jan 30 20:33:46 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 30 Jan 2026 20:33:46 GMT Subject: RFR: 8373626: [asan] read past end of buffer in sun.awt.image.ImagingLib.convolveBI [v3] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 17:57:42 GMT, Phil Race wrote: >> Some of the medialib native functions implementing Convolve read data from arrays when it is not needed or used instead of reading just what is needed and used. >> This is detected as a read out of bounds. It is limited and hasn't been seen to result in any crashes without ASAN, and the OOB values that are read are never used so there's a very limited problem. >> The changes here make the mlib_ImageConv_*nw.c files match what happens in the mlib_ImageConv_*ext.c files which read just the data they need. >> The changes are fairly mechanical but there could be copy/paste errors for a reviewer to find. >> >> Not easy to provide a test case, building with --enable-asan is needed and for me it works only on macOS. >> I did that and ran all our existing automated tests on our CI systems. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8373626 I?m trying to understand if it?s possible to create a test that catches that typo. It looks like this code path is not covered. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29257#issuecomment-3825601044 From serb at openjdk.org Fri Jan 30 20:53:00 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 30 Jan 2026 20:53:00 GMT Subject: RFR: 8376420: Remove AppContext from javax/swing/ImageIcon.java [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 17:36:04 GMT, Alexey Ivanov wrote: >>> Does an app need direct access to the `MediaTracker` that's used to download the image? Probably not, therefore a private member is better. >> >> The application will have this access via getter already, the problematic part here is access to the Component which is mutable so we cannot use it via final field. > >> > Does an app need direct access to the `MediaTracker` that's used to download the image? Probably not, therefore a private member is better. >> >> The application will have this access via getter already > > I'm confused? Where's a getter in `ImageIcon` that an app can use to get a `MediaTracker` instance? > > The `getTracker` method is *private*. > >> the problematic part here is access to the Component which is mutable so we cannot use it via final field. > > The `component` field is *final*. The field yes, but the component itself is not a constant. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29433#discussion_r2747942137 From prr at openjdk.org Fri Jan 30 20:56:01 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 30 Jan 2026 20:56:01 GMT Subject: RFR: 8375057: Update HarfBuzz to 12.3.2 In-Reply-To: <4VKAIWM9Ud-2zdY7NhEw1dCek4mTTVPC3tx_6HAKARE=.e03f6f17-ff2a-408f-bd50-f071b296dce3@github.com> References: <4VKAIWM9Ud-2zdY7NhEw1dCek4mTTVPC3tx_6HAKARE=.e03f6f17-ff2a-408f-bd50-f071b296dce3@github.com> Message-ID: On Thu, 29 Jan 2026 00:32:40 GMT, Damon Nguyen wrote: > HarfBuzz updated to 12.3.2 > > 2 new files > 1 renamed file > 170 updated files No deleted files ? Meaning are all files we have in the current version are in the new version too ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29475#issuecomment-3825686567 From dnguyen at openjdk.org Fri Jan 30 23:06:47 2026 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 30 Jan 2026 23:06:47 GMT Subject: RFR: 8375057: Update HarfBuzz to 12.3.2 In-Reply-To: References: <4VKAIWM9Ud-2zdY7NhEw1dCek4mTTVPC3tx_6HAKARE=.e03f6f17-ff2a-408f-bd50-f071b296dce3@github.com> Message-ID: On Fri, 30 Jan 2026 20:53:41 GMT, Phil Race wrote: > No deleted files ? Meaning are all files we have in the current version are in the new version too ? Correct. The only "deleted" file turned out to be renamed. Checked each file name manually between the current and the source files from 12.3.2's zip. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29475#issuecomment-3826274605 From prr at openjdk.org Fri Jan 30 23:22:29 2026 From: prr at openjdk.org (Phil Race) Date: Fri, 30 Jan 2026 23:22:29 GMT Subject: RFR: 8375057: Update HarfBuzz to 12.3.2 In-Reply-To: <4VKAIWM9Ud-2zdY7NhEw1dCek4mTTVPC3tx_6HAKARE=.e03f6f17-ff2a-408f-bd50-f071b296dce3@github.com> References: <4VKAIWM9Ud-2zdY7NhEw1dCek4mTTVPC3tx_6HAKARE=.e03f6f17-ff2a-408f-bd50-f071b296dce3@github.com> Message-ID: On Thu, 29 Jan 2026 00:32:40 GMT, Damon Nguyen wrote: > HarfBuzz updated to 12.3.2 > > 2 new files > 1 renamed file > 170 updated files Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29475#pullrequestreview-3730884780 From dnguyen at openjdk.org Sat Jan 31 11:12:59 2026 From: dnguyen at openjdk.org (Damon Nguyen) Date: Sat, 31 Jan 2026 11:12:59 GMT Subject: RFR: 8376755: Remove AppContext from Swing javax/swing/plaf/basic classes In-Reply-To: <0AjFtP2_UXLP6zBNsu4hGWJHwOrD7Qit0klcwMtemWA=.e0d35933-90ad-456d-8313-bd9c18e954ca@github.com> References: <0AjFtP2_UXLP6zBNsu4hGWJHwOrD7Qit0klcwMtemWA=.e0d35933-90ad-456d-8313-bd9c18e954ca@github.com> Message-ID: On Thu, 29 Jan 2026 23:02:45 GMT, Phil Race wrote: > Remove AppContext from the Swing basic plaf package > One test is updated to use the now non-appcontext internal variables. Built and tested the changes. LGTM. ------------- Marked as reviewed by dnguyen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29495#pullrequestreview-3732310281 From acobbs at openjdk.org Sat Jan 31 20:03:49 2026 From: acobbs at openjdk.org (Archie Cobbs) Date: Sat, 31 Jan 2026 20:03:49 GMT Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression [v7] In-Reply-To: References: Message-ID: <3VvHHah7TVMP4_puXRq4urxiwR8UMSJugMQ3yQZdPJo=.cae130ee-beb0-448f-87f6-a3772894f618@github.com> > This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings. > > Summary of code changes: > > * Add new warning and associated lint category `"suppression"` > * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ? > * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect. > * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression. > * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations. > * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break > > ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 140 commits: - Merge branch 'master' into JDK-8344159 to fix conflicts. - Update copyrights to 2026. - Merge branch 'master' into JDK-8344159 - Merge branch 'master' into JDK-8344159 - Merge branch 'master' into JDK-8344159 - Suppress new unnecessary suppresion warnings created by recent commits. - Merge branch 'master' into JDK-8344159 - Merge branch 'master' into JDK-8344159 to fix conflict. - Merge branch 'master' into JDK-8344159 to fix conflict. - Merge branch 'master' into JDK-8344159 to fix conflicts. - ... and 130 more: https://git.openjdk.org/jdk/compare/6ce2f3e1...ab9af044 ------------- Changes: https://git.openjdk.org/jdk/pull/25167/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=06 Stats: 1696 lines in 35 files changed: 1494 ins; 49 del; 153 mod Patch: https://git.openjdk.org/jdk/pull/25167.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25167/head:pull/25167 PR: https://git.openjdk.org/jdk/pull/25167