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