From duke at openjdk.org Sat Nov 1 14:31:41 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Sat, 1 Nov 2025 14:31:41 GMT Subject: RFR: 8251928: [macos] the printer DPI always be 72, cause some content lost when print out [v9] In-Reply-To: References: Message-ID: > The fix for the https://bugs.openjdk.org/browse/JDK-8251928. > > **Description**. > This PR contains changes to be able to print with DPI higher than 72 on macOS, set default CPrinterJob DPI is 300 like in the PSPrinterJob. > > As described in the macOS drawing guide, the following steps are required to draw with high DPI (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html#//apple_ref/doc/uid/TP40003290-CH204-BCICIJAJ): > 1. Convert the user-space point, size, or rectangle value to device space coordinates; > 2. Normalize the value in device space so that it is aligned to the appropriate pixel boundary; > 3. Convert the normalized value back to user space; > 4. Draw your content using the adjusted value. > > The 1-st step is now implemented in the CPrinterJob, a Graphics provided to the print method adjusted to a printer's DPI. > The 2-nd step is a drawing process in the java code (without changes). > The 3-rd step is now implemented in the PrinterView.m, the drawing scaled back to the 72 DPI. > The 4-th step is a drawing process in the native code (without changes). > > **Tests**. > I run all tests from javax.print package and there is no any regression. > New test covers macOS and Linux only because we know its default DPI - 300. GennadiyKrivoshein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: - Merge branch 'openjdk:master' into macOS_printing_DPI - Revert PeekGraphics - Merge branch 'openjdk:master' into macOS_printing_DPI - move scaling to GraphicsConfig, update PeekGraphics - revert CGraphicsDevice.m constants. Update orientation constant usage - remove setDevClip usage. Update names. Handle page format orientation. - Merge branch 'openjdk:master' into macOS_printing_DPI - Merge branch 'openjdk:master' into macOS_printing_DPI - [macos] the printer DPI always be 72 ------------- Changes: https://git.openjdk.org/jdk/pull/25489/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25489&range=08 Stats: 379 lines in 5 files changed: 367 ins; 1 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/25489.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25489/head:pull/25489 PR: https://git.openjdk.org/jdk/pull/25489 From prr at openjdk.org Sun Nov 2 17:29:07 2025 From: prr at openjdk.org (Phil Race) Date: Sun, 2 Nov 2025 17:29:07 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v11] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 16:17:10 GMT, Damon Nguyen wrote: >> Some useful methods (click, glide, waitForIdle, type) in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using these ExtendedRobot methods will be handled separately. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Update changes to adhere to line limit Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26969#pullrequestreview-3408883664 From prr at openjdk.org Sun Nov 2 17:31:01 2025 From: prr at openjdk.org (Phil Race) Date: Sun, 2 Nov 2025 17:31:01 GMT Subject: RFR: 8364583: ColorConvertOp fails for CMYK =?UTF-8?B?4oaS?= RGB conversion In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 05:25:44 GMT, Phil Race wrote: > color is initially returned as 4 element array but we over-write with 3 element and so next time through the loop it is used by but is too short. > More details in JBS. @prsadhuk @honkar-jdk please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27785#issuecomment-3478129032 From prr at openjdk.org Sun Nov 2 17:31:08 2025 From: prr at openjdk.org (Phil Race) Date: Sun, 2 Nov 2025 17:31:08 GMT Subject: RFR: 4954405: Data buffers created with an offset are unusable [v2] In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 21:01:35 GMT, Phil Race wrote: >> ByteInterleavedRaster is not including the DataBuffer offset in returns from getDataElements >> The super-class sets it in the constructor which runs very much like this subclass except it omits this. >> The parent class of ByteInterleavedRaster is ByteComponentRaster and it uses the DataBuffer offset >> to adjust dataOffsets values used in all calculations. >> >> Instead ByteInterleavedRaster does something a bit different than other classes where it includes it in some instance vars >> that also have additional offsets that apply for getPixels and getSamples but aren't used in getDataElements. >> >> It looks to me as if this is what ByteInterleavedRaster should also do instead. >> All existing tests pass, and this resolves the specific complaint in the bug report. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 4954405 @prsadhuk @jayathirthrao please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27782#issuecomment-3478128792 From prr at openjdk.org Sun Nov 2 17:32:04 2025 From: prr at openjdk.org (Phil Race) Date: Sun, 2 Nov 2025 17:32:04 GMT Subject: RFR: 8298432: Investigate the benefits of usage of GetPrimitiveArrayCritical in the cmm code In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 09:29:48 GMT, Sergey Bylokhov wrote: > The LCMS JNI code currently uses GetByteArrayElements, GetShortArrayElements, GetIntArrayElements. These can be replaced by GetPrimitiveArrayCritical, which avoids unnecessary copying of array data and provides measurable performance improvements. > > This optimization was postponed earlier due to several reasons: > > - At that time, G1 did not support pinning, so critical sections could interfere with GC (see [JEP 423](https://openjdk.org/jeps/423)). Also note that this API is already used safely in many parts of java2d/awt. > - There was a plan to migrate to panama, but cold-startup issues ([JDK-8313344](https://bugs.openjdk.org/browse/JDK-8313344)) remain unresolved. > - GetPrimitiveArrayCritical forbids many JNI operations inside the critical region, including allocations and java callbacks, which could be unsafe for LCMS error handlers. However, LCMS color conversions do not trigger such callbacks (see [LittleCMS #516](https://github.com/mm2/Little-CMS/issues/516)). > > Performance data of various [combinations](https://bugs.openjdk.org/secure/attachment/114273/OnePixelConvert-1.java) for ColorSpace.toXX/fromXX in single-threaded and multi-threaded (64 threads) modes: > https://jmh.morethan.io/?gists=b1440355577dc48f2b19b976b67f1120,d31c6a585330c9167b462e377445ad2f > Example: > image @prsadhuk @honkar-jdk please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27841#issuecomment-3478129315 From prr at openjdk.org Sun Nov 2 17:33:04 2025 From: prr at openjdk.org (Phil Race) Date: Sun, 2 Nov 2025 17:33:04 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v3] In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 03:30:45 GMT, Prasanta Sadhukhan wrote: >> If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder` >> it throws NPE which is not mentioned in the spec as the expected outcome. >> Fixed the NPE and the spec > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test update @TejeshR13 please review (in addition to @honkar-jdk ) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27949#issuecomment-3478129772 From prr at openjdk.org Sun Nov 2 17:34:04 2025 From: prr at openjdk.org (Phil Race) Date: Sun, 2 Nov 2025 17:34:04 GMT Subject: RFR: 8370637: [Windows] Crash if use Graphics after PrintJob.end [v2] In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 21:17:50 GMT, Phil Race wrote: >> Synchronize WPrinterJob calls which use the printDC to avoid crash in case of mis-use. >> The printerDC is released when the job ends. >> It is zero-ed out in the handle in which it is stored >> The calls which expect it to be valid now all check for zero and return if it is zero. >> The calls are made synchronized as is the call to endDoc which zeroes it, so that they cannot have it zeroed out whilst using it. >> >> The tests are the same as in the fix for JDK-8370141 which is also under review. >> Which ever is 2nd to be pushed will have to merge in the changes from the first > > Phil Race has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - 8370637 > - 8370637 > - Merge > - 8370637 @prsadhuk @azvegint please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27984#issuecomment-3478130339 From prr at openjdk.org Sun Nov 2 17:35:00 2025 From: prr at openjdk.org (Phil Race) Date: Sun, 2 Nov 2025 17:35:00 GMT Subject: RFR: 8357252: sun/awt/font/TestArabicHebrew.java fails in OEL 9 and 10 x64 In-Reply-To: <2DGbd1T9g477NOXI2G6bIcP7dYyM1-ur745qYQA69_o=.e5c976f6-b72d-4688-b8cc-3e9f68db192b@github.com> References: <2DGbd1T9g477NOXI2G6bIcP7dYyM1-ur745qYQA69_o=.e5c976f6-b72d-4688-b8cc-3e9f68db192b@github.com> Message-ID: On Thu, 30 Oct 2025 18:52:53 GMT, Phil Race wrote: > A long time ago (JDK 7) when the linux font properties were largely replaced by using fontconfig logic was included to try to limit the number of slots used for composite fonts by requiring that fonts add sufficient code points. > In practice today this limitation seems to be reductions like having 40 slots instead of 50. > Except for keeping it for debugging, this fix removes that limitation which had a bad consequence on some recent Linuxes where the primary Hebrew font (Noto Sans Hebrew) came after another font (DejaVu Sans) that provided some Hebrew accents and punctuation but not the alphabet and was also far enough down the list (14th) to be where we require 50 new code points to be worthy of inclusion and it only added 33. @prsadhuk @azuev-java please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/28072#issuecomment-3478131284 From prr at openjdk.org Sun Nov 2 17:36:03 2025 From: prr at openjdk.org (Phil Race) Date: Sun, 2 Nov 2025 17:36:03 GMT Subject: RFR: 8370719: [Linux] Use /etc/os-release values for font configuration file names In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 21:54:17 GMT, Alexander Zuev wrote: >> The JBS issue has a long discussion and explanation but here's a short version. >> Instead of having baked in names of distros in the code that figures out names for font configuration files for Linux >> use the standard ID and VERSION_ID fields in /etc/os-release which is now standard. >> even systemd doesn't work if it does not exist https://0pointer.de/blog/projects/os-release >> And if it doesn't we just use "Linux" as the name. > > Changes looks reasonable and i checked that there is no usage of osVersion not guarded by the null check because right now of the /etc/os-release is not readable the value i think will be left as null? But anyways the code that uses it assumes that it can be null so all is well in this department. At the time i wrote this comment the CSR issue is still being filled in - i will take another look tomorrow. @azuev-java please review the CSR too. @prsadhuk please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/28073#issuecomment-3478132216 From prr at openjdk.org Sun Nov 2 17:38:07 2025 From: prr at openjdk.org (Phil Race) Date: Sun, 2 Nov 2025 17:38:07 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v3] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 14:35:46 GMT, Matthias Baesken wrote: >> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. >> But for other JDK native libs, we do not have support for this feature. >> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust comment @azvegint please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3478133421 From prr at openjdk.org Sun Nov 2 17:38:06 2025 From: prr at openjdk.org (Phil Race) Date: Sun, 2 Nov 2025 17:38:06 GMT Subject: RFR: 8371066: Remove unused class TextSourceLabel and associated class hierarchy In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 17:17:06 GMT, Daniel Gredler wrote: > The class `TextSourceLabel` is unused, as is the associated factory method `TextLabelFactory.createSimple(...)`. > > The abstractions provided by the abstract classes `TextLabel` and `ExtendedTextLabel` only make sense when there are two types of text labels (`TextSourceLabel` and `ExtendedTextSourceLabel`). With the deletion of `TextSourceLabel`, both `TextLabel` and `ExtendedTextLabel` can also be removed. > > The JavaDoc for the abstract methods in `TextLabel` and `ExtendedTextLabel`, which are implemented in `ExtendedTextSourceLabel`, was moved to `ExtendedTextSourceLabel` prior to the deletion of these two classes. > > The few small convenience methods in `TextLabel` and `ExtendedTextLabel` were also moved to `ExtendedTextSourceLabel` prior to the deletion of these two classes. > > I would have liked to give the combined `TextLabel` + `ExtendedTextLabel` + `ExtendedTextSourceLabel` class the name `TextLabel`, but I've used `ExtendedTextSourceLabel` instead because it makes the diff much smaller and maximizes code history traceability. > > See initial mailing list discussion: https://mail.openjdk.org/pipermail/client-libs-dev/2025-September/032302.html @prsadhuk please review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28090#issuecomment-3478133064 From prr at openjdk.org Sun Nov 2 17:39:06 2025 From: prr at openjdk.org (Phil Race) Date: Sun, 2 Nov 2025 17:39:06 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v2] In-Reply-To: References: Message-ID: <-FGLKrIhVBseAbxsc1VJaDnRIGCpiNlKqdb9RnLpjMY=.2a0a03f3-d536-4741-8504-037aef57a972@github.com> On Thu, 23 Oct 2025 21:02:07 GMT, Harshitha Onkar wrote: >> `findComponent(final Container container, final Predicate predicate)` is a useful utility method and thus added to` javax/swing/regtesthelpers/Util.java` instead of having redundant code in tests. It can be used to find a component by label name. >> >> PS: Existing `Util.findSubComponent()` finds component by class name but `findComponent()` can be used to search for a particular component by label name/title when there are multiple subcomponents of same type by applying a predicate logic. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > review update @TejeshR13 please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27944#issuecomment-3478133739 From prr at openjdk.org Sun Nov 2 17:40:04 2025 From: prr at openjdk.org (Phil Race) Date: Sun, 2 Nov 2025 17:40:04 GMT Subject: RFR: 4690476: NegativeArraySizeException from AffineTransformOp with shear In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 22:05:05 GMT, Phil Race wrote: > This fix does a couple of things > > 1) AffineTransformOp.createCompatibleDestImage() and AffineTransformOp.createCompatibleDestRaster() now specify that they will throw RasterFormatException if the transformed size is too large. They were already getting an exception. > Note that inside the JDK only the imaging API implementation itself uses these APIs and I suspect they are rarely used by applications. > > 2) AffineTransformOp.filter(src, null) will not throw an exception if it cannot create a destination image or raster of the required size and instead will use the source image size. This means applications which simply filter() will not need to carefully examine the transform. Sophisticated applications which want to do this can use the above "create*" methods to explicitly create the destination to find this out. > > So some inconsistency but I think it is a user-friendly trade-off. > > A CSR will be needed but I want to get past initial review first. > Update : CSR is now created https://bugs.openjdk.org/browse/JDK-8370162 @prsadhuk please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27707#issuecomment-3478134682 From prr at openjdk.org Sun Nov 2 17:40:07 2025 From: prr at openjdk.org (Phil Race) Date: Sun, 2 Nov 2025 17:40:07 GMT Subject: RFR: 6185110: Undefined behaviour of SampleModel for width, height < 0 In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 22:30:53 GMT, Phil Race wrote: > The only significant change here is to ensure that all SampleModel types throw a specified exception if a client > calls any of the following methods with a negative width or height. > getPixels(..) > setPixels(..) > getSamples(..) > setSamples(..) > > The rest is fixing the javadoc to properly describe what happens and some minor cleanup. > I use {@inheritDoc} to avoid repeating the super-class doc. And no one now has to tediously compare them. > I could just delete the javadoc but that would cause no javadoc to be generated for an overridden method. > There were a couple of surprises with {@inheritDoc} and the one I had to deal with is that declared RuntimeExceptions > are not inherited. You need to explicitly re-add them. This because if it isn't an exception in the method signature (as in foo() throws BarException), and instead you only have "@throws BarException" it will not be inherited. > > I added a test which verifies the behaviour for illegal arguments. > > CSR is here https://bugs.openjdk.org/browse/JDK-8369623 @jayathirthrao please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27754#issuecomment-3478134313 From prr at openjdk.org Sun Nov 2 17:41:04 2025 From: prr at openjdk.org (Phil Race) Date: Sun, 2 Nov 2025 17:41:04 GMT Subject: RFR: 8369327: On macOS List may loses selection when added to Frame In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 01:20:41 GMT, Sergey Bylokhov wrote: > The bug happens when List.select(int) is used in multiple selection mode. It only appears when the List is added to a Frame, because in that case, the selection is handled by the platform peer, and the internal logic in the List class is skipped. > > To fix this, the code now uses [addSelectionInterval](https://github.com/openjdk/jdk/blob/910bb68e5191f830ff6f3dff5753e4e5f6214a7b/src/java.desktop/share/classes/javax/swing/ListSelectionModel.java#L93) instead of setSelectedIndex. This method works correctly for multiple selection mode when using JList as the delegate on macOS. > > I added DeselectionUnitTest and SelectionUnitTest tests for some selection and deselection cases. At first, it was one big test, but I split it because it got too large. > > **Notes on invalid index handling** > According to the java.awt.List [spec](https://github.com/openjdk/jdk/blob/0e5655e6680762a99b5aecb58369b880ea913565/src/java.desktop/share/classes/java/awt/List.java#L573), using invalid indexes is undefined behavior. For now, I have decided not to validate these cases fully in this patch, but I did add a check in the `LWListPeer.select()` to handle them more safely. > > The previously used setSelectedIndex method [ignored](https://github.com/openjdk/jdk/blob/0e5655e6680762a99b5aecb58369b880ea913565/src/java.desktop/share/classes/javax/swing/JList.java#L2229) indexes greater than the list size, unlike addSelectionInterval. So I added an explicit check to skip all indexes larger than the list size. > > Later, I discovered that passing a negative index not only causes an exception (which is acceptable, since it's undefined behavior), but also leaves the peer in an inconsistent state. This happens because setSkipStateChangedEvent(false) at the end of LWListPeer.select() is not called if an exception is thrown. > > To prevent this, I added a check to skip all negative values as well. As a result, the peer now cleanly ignores all out-of-range indexes. > > **Description of how invalid indexes are handled on other platforms:** > - The shared code in java.awt.List stores elements and selection separately, so it accepts invalid indexes. This can cause exceptions if the selection and data become out of sync. > - On Windows, all invalid indexes are ignored, except for the special value -1, which is used to select or deselect all elements. This happens because the indexes are passed to the win api without validation. > - XAWT uses the same logic as the shared code, so it can throw the same exceptions if the data... @azvegint @azuev-java please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27682#issuecomment-3478135155 From prr at openjdk.org Sun Nov 2 17:42:01 2025 From: prr at openjdk.org (Phil Race) Date: Sun, 2 Nov 2025 17:42:01 GMT Subject: RFR: 8369129: Raster createPackedRaster methods specification clean up [v6] In-Reply-To: References: Message-ID: On Mon, 27 Oct 2025 17:23:42 GMT, Phil Race wrote: >> Updates the specification of Raster.createPackedRaster(..) methods and also the implementation of these to explicitly check the specified conditions rather than relying on them being passed up from some other API. >> >> Also one each of the createInterleavedRaster(..) and createBandedRaster(..) methods have an update >> >> createInterleavedRaster(...) to address that even if WxH does not exceed Integer.MAX_VALUE, the storage needed still might. >> >> createBandedRaster(..) to address >> - a not explicitly specified or tested case that WxH must not overflow >> - a not explicitly tested NPE case if bandMasks is null. This was relying on a de-reference and the actual check for it being null would have thrown the wrong exception type (AIOBE) - meaning not the one NPE actually specified and thrown. >> There's an unfortunate oddity with this that of bankIndices is null it specifies and throws AIOBE, but I didn't think it worth changing either of these to make them consistent. >> >> The existing CreateRasterExceptionTest.java is updated to verify all these assertions. >> In almost all cases the behaviour is unchanged, it is just now properly specified and verified up front. >> >> There are only 2 sub-tests which would fail on JDK 25 >> The test can also be run (and pass) there without this fix because it explicitly handles those 2 cases which are reasonable behavioral changes >> - One for the createInterleavedRaster() update where the unchecked case could end up causing a NegativeArraySizeException. This seems like a merited change. >> - One for an unlikely case where if an app specified 0 app to createPackedRaster, divide by zero would happen. >> >> The CSR is now ready for review https://bugs.openjdk.org/browse/JDK-8369131 > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8369129 @prsadhuk please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27627#issuecomment-3478136153 From prr at openjdk.org Sun Nov 2 17:43:03 2025 From: prr at openjdk.org (Phil Race) Date: Sun, 2 Nov 2025 17:43:03 GMT Subject: RFR: JDK-8017182 : [macosx] MouseClickCount.java produces click count greater than 1 when left-button click is followed by quick right button click In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 23:59:05 GMT, Harshitha Onkar wrote: > On macOS mouse sensitivity setting play a role in click count increment. By increasing the double-click speed under > (Settings > Mouse Sensitivity > Double click speed), the click count no longer shows as 1,2. > > image @honkar-jdk what is happening with this PR ? Once updated, @TejeshR13 and @prsadhuk please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27379#issuecomment-3478136931 From markyag at gmail.com Mon Nov 3 01:43:09 2025 From: markyag at gmail.com (Mark Yagnatinsky) Date: Sun, 2 Nov 2025 20:43:09 -0500 Subject: a last-minute plea to reconsider JEP 504: removing the applet API breaks non-applets In-Reply-To: References: Message-ID: Did I send this to the wrong list? If so, could someone please redirect me? On Fri, Oct 31, 2025 at 2:34?PM Mark Yagnatinsky wrote: > In the olden days, it was pretty common to make apps that supported two > launch modes: > 1. entry point in main() created its own window using JFrame or whatever. > 2. But also extend Applet so as to run in the browser. > > These days, the second mode no longer works because no browser supports > applets. > But the first mode still works fine. It would STOP working if the applet > API were removed. > (In particular, class loading would fail if the JVM can't find the parent > class.) > > Normally, when we talk about removing APIs, there is a simple bit of > messaging that goes something like this: > 1. This is hopefully a simple code change (e.g., stop extending Applet, > since it does you no good anyway). > 2. If you're not ready to make the code change, stay on an old version for > now > 3. If you're not going to be ready soon, use an LTS release. > > There's a cluster of vague implicit assumptions buried in such messaging, > such as: > 1. The application is actively maintained, or at least there exists a > person or group of people nominally in charge of maintaining it. > 2. The user and developer of the application are one and the same person, > or at least know each other or have some sort of business relationship or > SOMETHING. > 3. In short, it assumes that if the application doesn't run, the developer > has some reason to care. If the developer doesn't care, it's presumably > because the app has no users and hence nobody cares. > > In the case of the applet API, this is all largely false. > There are people who once upon a time put a cute little applet on the web, > and also made it runnable standalone. > If anyone happens to find this useful to them, then all the better, but > those people are not customers, just like someone is not your customer just > because they happen to read your blog. > In other words, if these cute little former applets stop working, the > original author has no incentive to care and might not even notice for many > years. > > But even though these are all unmaintained, it does not mean they are > unused! > They may indeed have users, possibly users who find them indispensable! > But those users may not have access to the code, and may not be > programmers even if they did have access. > To those users, removing the applet API means that these apps no longer > work on the latest JDK, and they have no one to complain to. > > For a while, they can stay on old JDK, but eventually this becomes harder > and harder as old JDK versions may not support new operating systems and > CPUs and stuff. > (Not everyone knows how to set up a VM and an emulator and stuff.) > Also, some people may be too nervous to run an old JVM that hasn't gotten > security updates in a long time. > > Conversely, consider the cost of keeping these APIs. They would still be > deprecated. > Nobody is filing bug reports against them, since they are unusable anyway. > They are not "literally free" but the maintenance burden for the OpenJDK > team should be only marginally higher than the maintenance burden of dead > code. > > Thoughts? > > Thanks, > Mark. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Mon Nov 3 01:55:00 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Sun, 2 Nov 2025 20:55:00 -0500 Subject: a last-minute plea to reconsider JEP 504: removing the applet API breaks non-applets In-Reply-To: References: Message-ID: No, you are on the right mailing list. Let me start by saying -- I know how you feel. The way you feel about Applets is exactly how I felt about Java WebStart . I'm still cranky about it's removal. But to jump right into the point -- Deprecation for Removal means that the OpenJDK will no longer support this API, and thus, are removing it from the SDK. But that doesn't mean that the functionality is dead, just means that it won't be supported by the OpenJDK. My WebStart has found new life under OpenWebStart . I guarantee you that a similar thing will be made for Applets, as Applets went way further than Java WebStart ever did. And as for the reason, please remember that the existence of a feature means that it adds weight to the load. Java Applets could receive no changes whatsoever for the next 10 years, and yet *their mere existence* in the SDK contributes a large amount to the maintenance effort. And the reason why it adds so much to the maintenance effort is because Java must ensure that each feature or library they introduce is cohesive with the SDK. By keeping Applets in, that's one more thing that needs to be checked against. And Applets are large enough that this checking is non-trivial. I would encourage you (and those you come across) to look to Open Source Software solutions to the removal of Applets. You might be surprised how easy it is to achieve. On Fri, Oct 31, 2025 at 2:35?PM Mark Yagnatinsky wrote: > In the olden days, it was pretty common to make apps that supported two > launch modes: > 1. entry point in main() created its own window using JFrame or whatever. > 2. But also extend Applet so as to run in the browser. > > These days, the second mode no longer works because no browser supports > applets. > But the first mode still works fine. It would STOP working if the applet > API were removed. > (In particular, class loading would fail if the JVM can't find the parent > class.) > > Normally, when we talk about removing APIs, there is a simple bit of > messaging that goes something like this: > 1. This is hopefully a simple code change (e.g., stop extending Applet, > since it does you no good anyway). > 2. If you're not ready to make the code change, stay on an old version for > now > 3. If you're not going to be ready soon, use an LTS release. > > There's a cluster of vague implicit assumptions buried in such messaging, > such as: > 1. The application is actively maintained, or at least there exists a > person or group of people nominally in charge of maintaining it. > 2. The user and developer of the application are one and the same person, > or at least know each other or have some sort of business relationship or > SOMETHING. > 3. In short, it assumes that if the application doesn't run, the developer > has some reason to care. If the developer doesn't care, it's presumably > because the app has no users and hence nobody cares. > > In the case of the applet API, this is all largely false. > There are people who once upon a time put a cute little applet on the web, > and also made it runnable standalone. > If anyone happens to find this useful to them, then all the better, but > those people are not customers, just like someone is not your customer just > because they happen to read your blog. > In other words, if these cute little former applets stop working, the > original author has no incentive to care and might not even notice for many > years. > > But even though these are all unmaintained, it does not mean they are > unused! > They may indeed have users, possibly users who find them indispensable! > But those users may not have access to the code, and may not be > programmers even if they did have access. > To those users, removing the applet API means that these apps no longer > work on the latest JDK, and they have no one to complain to. > > For a while, they can stay on old JDK, but eventually this becomes harder > and harder as old JDK versions may not support new operating systems and > CPUs and stuff. > (Not everyone knows how to set up a VM and an emulator and stuff.) > Also, some people may be too nervous to run an old JVM that hasn't gotten > security updates in a long time. > > Conversely, consider the cost of keeping these APIs. They would still be > deprecated. > Nobody is filing bug reports against them, since they are unusable anyway. > They are not "literally free" but the maintenance burden for the OpenJDK > team should be only marginally higher than the maintenance burden of dead > code. > > Thoughts? > > Thanks, > Mark. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdv at openjdk.org Mon Nov 3 03:46:09 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 3 Nov 2025 03:46:09 GMT Subject: RFR: 8357034: GifImageDecoder can produce wrong transparent pixels [v8] In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 21:26:45 GMT, Jeremy Wood wrote: >> If there are two consecutive frames that use DISPOSAL_SAVE, but the transparent pixel index changed: we might accidentally send the wrong data to the ImageConsumer. >> >> We already had logic that submits info "the hard way" (see comment in code); this PR just makes sure we trigger that block. >> >> There are a cluster of four related PRs that share the GifComparison class in this PR. >> >> 1. [8357034](https://github.com/openjdk/jdk/pull/25264) (this one) >> 2. ~~[8356137](https://github.com/openjdk/jdk/pull/25044)~~ (integrated) >> 3. [8356320](https://github.com/openjdk/jdk/pull/25076) >> 4. [8351913](https://github.com/openjdk/jdk/pull/24271) >> >> This bug can be observed reading these gif animations: >> >> https://giphy.com/gifs/fomoduck-duck-fomo-ZUlzR40oGACqNmy0q8 >> https://media4.giphy.com/media/Zbf4JQzcDhzeraQvk9/giphy.gif >> https://giphy.com/gifs/computer-working-cat-LHZyixOnHwDDy >> https://giphy.com/gifs/90s-fgfgif-r4BmI9xUaDuKJQdd3l >> >> ### Describing This Bug >> >> The steps/explanation that lead to this failure are a little complicated. I'll try to summarize the original bug here. >> >> All three frames in the unit test's GIF use disposal code doNotDispose, meaning the frames are layered one on top of the previous. >> >> The first frame produces 3 circles from left to right using these colors: >> 0xff0000 (red) 0xffff00 (yellow) 0x00ff00 (green) >> >> The background is 0x00ffff (cyan). It is the transparent pixel, so the first frame is: >> >> frame_0 >> >> Now we start processing the second frame. The pixels are the same, but the color model has changed so the zeroeth color (red) is the transparent index. >> >> When the GifImageDecoder layers the 2nd frame on top of the 1st frame, it notices that `model.equals(saved_model)` is `false`. This means it enter a block of code that refers to "the hard way" of passing new pixel information to the ImageConsumers. >> >> The 2nd frame, after being painted on the 1st frame, looks like: >> frame_1 >> ? >> The 3rd frame is exactly the same as the 2nd. But here's where the bug is: now `model.equals(saved_model)` is `true`, so GifImageDecoder tries to pass the pixel information the easy way. The result is: >> >> frame_2_awt > This is in response to: > https://github.com/openjdk/jdk/pull/25264/files#r2292318270 > - Merge branch 'master' into JDK-8357034 > - 8357034: re-wrapping line breaks > - 8356137, 8357034: add debug option to dump PNGs of frames > > This is in response to: > https://github.com/openjdk/jdk/pull/25044#pullrequestreview-3007487527 > - Merge branch 'master' into JDK-8357034 > > # Conflicts: > # test/jdk/sun/awt/image/gif/GifBuilder.java > # test/jdk/sun/awt/image/gif/GifComparison.java > - 8357034: avoid recalculating isSimpleSavedImageComparison for every line > > This is in response to: > https://github.com/openjdk/jdk/pull/25264#discussion_r2197097522 > - Merge branch 'master' into JDK-8357034 > - 8356320: Use new GifBuilder and remove ukraine-flag.gif > > This is an extension of work for this PR: > https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750 > - 8356137: adding copyright > - ... and 25 more: https://git.openjdk.org/jdk/compare/1781b186...ece8707a Code change looks good to me. I am giving full test run with latest update. If it is green i will re-approve it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25264#issuecomment-3478803726 From markyag at gmail.com Mon Nov 3 04:20:12 2025 From: markyag at gmail.com (Mark Yagnatinsky) Date: Sun, 2 Nov 2025 23:20:12 -0500 Subject: a last-minute plea to reconsider JEP 504: removing the applet API breaks non-applets In-Reply-To: References: Message-ID: Thanks for replying! I guess I'm not convinced that their "mere existence" means that each feature needs to take them into account. For one thing, they already don't work, and they are already deprecated. They are also "well contained": the bulk of the API surface lives in just one package (java.applet). (Compare this to, say, the Security Manager, which really did have its tendrils all over the place, or serialization, which still does.) I'm also not sure WebStart is quite analogous here. (Disclaimer: I know roughly nothing about webstart; this may all be wrong.) As far as I understand, all you need for web start to work is that some program on your computer knows what to do with JNLP files. Thus, it's perfectly practical for a third party to write such a program. The only "tricky" part that I can think of is to ensure that the javax.jnlp package exists even when running on newer versions of the JDK, But since the JNLP launcher has full control of the classpath of the JVM, it can indeed arrange for this. In the case of desktop apps that also happen to be applets, it's not clear to me what to do; we no longer have a separate launcher. Is the idea to create a jar file with the contents of the java.applet package, and then tell people to always add it to their classpath? Either way, thanks for confirming the mailing list! Mark. On Sun, Nov 2, 2025 at 8:55?PM David Alayachew wrote: > No, you are on the right mailing list. > > Let me start by saying -- I know how you feel. The way you feel about > Applets is exactly how I felt about Java WebStart > . I'm still cranky about > it's removal. > > But to jump right into the point -- Deprecation for Removal means that the > OpenJDK will no longer support this API, and thus, are removing it from the > SDK. > > But that doesn't mean that the functionality is dead, just means that it > won't be supported by the OpenJDK. My WebStart has found new life under > OpenWebStart . I guarantee you that a similar > thing will be made for Applets, as Applets went way further than Java > WebStart ever did. > > And as for the reason, please remember that the existence of a feature > means that it adds weight to the load. Java Applets could receive no > changes whatsoever for the next 10 years, and yet *their mere existence* in > the SDK contributes a large amount to the maintenance effort. And the > reason why it adds so much to the maintenance effort is because Java must > ensure that each feature or library they introduce is cohesive with the > SDK. By keeping Applets in, that's one more thing that needs to be checked > against. And Applets are large enough that this checking is non-trivial. > > I would encourage you (and those you come across) to look to Open Source > Software solutions to the removal of Applets. You might be surprised how > easy it is to achieve. > > On Fri, Oct 31, 2025 at 2:35?PM Mark Yagnatinsky > wrote: > >> In the olden days, it was pretty common to make apps that supported two >> launch modes: >> 1. entry point in main() created its own window using JFrame or whatever. >> 2. But also extend Applet so as to run in the browser. >> >> These days, the second mode no longer works because no browser supports >> applets. >> But the first mode still works fine. It would STOP working if the applet >> API were removed. >> (In particular, class loading would fail if the JVM can't find the parent >> class.) >> >> Normally, when we talk about removing APIs, there is a simple bit of >> messaging that goes something like this: >> 1. This is hopefully a simple code change (e.g., stop extending Applet, >> since it does you no good anyway). >> 2. If you're not ready to make the code change, stay on an old version >> for now >> 3. If you're not going to be ready soon, use an LTS release. >> >> There's a cluster of vague implicit assumptions buried in such messaging, >> such as: >> 1. The application is actively maintained, or at least there exists a >> person or group of people nominally in charge of maintaining it. >> 2. The user and developer of the application are one and the same person, >> or at least know each other or have some sort of business relationship or >> SOMETHING. >> 3. In short, it assumes that if the application doesn't run, the >> developer has some reason to care. If the developer doesn't care, it's >> presumably because the app has no users and hence nobody cares. >> >> In the case of the applet API, this is all largely false. >> There are people who once upon a time put a cute little applet on the >> web, and also made it runnable standalone. >> If anyone happens to find this useful to them, then all the better, but >> those people are not customers, just like someone is not your customer just >> because they happen to read your blog. >> In other words, if these cute little former applets stop working, the >> original author has no incentive to care and might not even notice for many >> years. >> >> But even though these are all unmaintained, it does not mean they are >> unused! >> They may indeed have users, possibly users who find them indispensable! >> But those users may not have access to the code, and may not be >> programmers even if they did have access. >> To those users, removing the applet API means that these apps no longer >> work on the latest JDK, and they have no one to complain to. >> >> For a while, they can stay on old JDK, but eventually this becomes harder >> and harder as old JDK versions may not support new operating systems and >> CPUs and stuff. >> (Not everyone knows how to set up a VM and an emulator and stuff.) >> Also, some people may be too nervous to run an old JVM that hasn't gotten >> security updates in a long time. >> >> Conversely, consider the cost of keeping these APIs. They would still be >> deprecated. >> Nobody is filing bug reports against them, since they are unusable anyway. >> They are not "literally free" but the maintenance burden for the OpenJDK >> team should be only marginally higher than the maintenance burden of dead >> code. >> >> Thoughts? >> >> Thanks, >> Mark. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From psadhukhan at openjdk.org Mon Nov 3 04:59:03 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 3 Nov 2025 04:59:03 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v4] In-Reply-To: References: Message-ID: > If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder` > it throws NPE which is not mentioned in the spec as the expected outcome. > Fixed the NPE and the spec Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27949/files - new: https://git.openjdk.org/jdk/pull/27949/files/0ecc57ba..2c018656 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27949&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27949&range=02-03 Stats: 39 lines in 2 files changed: 10 ins; 21 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27949.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27949/head:pull/27949 PR: https://git.openjdk.org/jdk/pull/27949 From psadhukhan at openjdk.org Mon Nov 3 04:59:06 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 3 Nov 2025 04:59:06 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v3] In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 20:38:29 GMT, Phil Race wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Test update > > src/java.desktop/share/classes/javax/swing/BorderFactory.java line 147: > >> 145: * the highlight color. The inner edge of the shadow area >> 146: * uses a brighter shade of the shadow color. >> 147: * If highlight and shadow color are null, then it will > > The text above says that if both are null it will fall back. You don't mean that. > You mean if either is null it will fall back. > > This results in the colors all being null. > > And I think you need to look further. > The NPE happens because BevelBorder does this > this(bevelType, highlight.brighter(), highlight, shadow, shadow.brighter()); > > But the constructor it is calling is also public and will happily allow nulls for any specific case. > So perhaps the above constructor should be doing something like > ((highlight != null) ? highlight.brighter : null) Yes, it seems handling the NPE in BevelBorder is more apt..I have updated the PR removing from BorderFactory and updated BevelBorder to handle null hinghlighter and shadow > src/java.desktop/share/classes/javax/swing/BorderFactory.java line 158: > >> 156: */ >> 157: public static Border createBevelBorder(int type, Color highlight, Color shadow) { >> 158: if (highlight != null && shadow != null) { > > What happens if type isn't a known type ? > Looks to me like no errors but no painting but I've not looked very closely. > Whatever we want should be specified everywhere. Yes, if its not a known type, then it will not draw as seen here...so I have updated the spec of all methods to highlight this aspect instead...But this will also require CSR update, if we remove this spec update or clarification, we can do away with CSR...is that clarification needed in the spec? https://github.com/openjdk/jdk/blob/4cfabd605c42494db4ca4078344d32abc951a9ae/src/java.desktop/share/classes/javax/swing/border/BevelBorder.java#L132-L138 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2485306131 PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2485308363 From psadhukhan at openjdk.org Mon Nov 3 05:16:10 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 3 Nov 2025 05:16:10 GMT Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v3] In-Reply-To: References: <0MDTPquVuMulH9tEnu_VEaKM7e6SPCpHh_19RhGWXMw=.56db997b-8a7e-48ea-bd07-e9721c5eea28@github.com> Message-ID: On Fri, 22 Aug 2025 22:16:48 GMT, Phil Race wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> javadoc update > > I don't think you are capturing what is going on here. > The cases here are that y=0 so you can't scroll up, because you are at the top. > You don't ordinarlly see this in the positive direction because the cell that is returned is null for out of range, and otherwise it at least points to the TOP of the last cell. > But I'm not sure how you can actually scroll, because the returned increment would take you off the bottom of the list, > And if the rectangle you pass in has a y that is = the height of the list, then scrolling in a positive direction also returns 0. > If it is GREATER than the height, then I get back a negative increment ! > > So this needs quite a bit more than the suggested words, because they aren't accurate or nearly sufficient. > I think a code fix might be needed too. > I can even get a negative scroll value from the upwards direction. > All you have to do is pass a synthesized rect to the API. > The implementation doesn't seem to be expecting that and it should probably do something in response, but it may be too late from a compatibility point of view. > I need you to figure this all out. Hi @prrace , this one also needs a recheck from your side as I have updated the code to handle negative scrollvalue so now in all cases, whatever I tested, its returning a positive value which is mentioned now in the spec.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26500#issuecomment-3478932107 From psadhukhan at openjdk.org Mon Nov 3 05:20:07 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 3 Nov 2025 05:20:07 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v3] In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 04:53:24 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/share/classes/javax/swing/BorderFactory.java line 147: >> >>> 145: * the highlight color. The inner edge of the shadow area >>> 146: * uses a brighter shade of the shadow color. >>> 147: * If highlight and shadow color are null, then it will >> >> The text above says that if both are null it will fall back. You don't mean that. >> You mean if either is null it will fall back. >> >> This results in the colors all being null. >> >> And I think you need to look further. >> The NPE happens because BevelBorder does this >> this(bevelType, highlight.brighter(), highlight, shadow, shadow.brighter()); >> >> But the constructor it is calling is also public and will happily allow nulls for any specific case. >> So perhaps the above constructor should be doing something like >> ((highlight != null) ? highlight.brighter : null) > > Yes, it seems handling the NPE in BevelBorder is more apt..I have updated the PR removing from BorderFactory and updated BevelBorder to handle null hinghlighter and shadow BevelBorder handles null color too as seen here so we can do as suggested https://github.com/openjdk/jdk/blob/4cfabd605c42494db4ca4078344d32abc951a9ae/src/java.desktop/share/classes/javax/swing/border/BevelBorder.java#L163-L166 https://github.com/openjdk/jdk/blob/4cfabd605c42494db4ca4078344d32abc951a9ae/src/java.desktop/share/classes/javax/swing/border/BevelBorder.java#L195-L198 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2485327587 From davidalayachew at gmail.com Mon Nov 3 05:21:36 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Mon, 3 Nov 2025 00:21:36 -0500 Subject: a last-minute plea to reconsider JEP 504: removing the applet API breaks non-applets In-Reply-To: References: Message-ID: You're coming at this from the API and functionality perspective. I am saying to look at it from the testing coverage, performance, bug reports, etc. There are a lot of standards to maintain, and thus, A LOT that goes into maintaining the JDK. Being well contained only eases some parts of the effort. As for WebStart, yet another side of maintainability is security. WebStart could be (and has been) used to exploit vulnerabilities, so the reasons to remove it increased even further. As for running Applets, that should be very easy to do. Like you said, provide implementations for the classes and methods in the applet packages, make a runtime image that includes them, then tell people to download that. You can also build a launcher that calls the necessary Applet API's. While it won't be as straight forward as WebStart, it's still very easy to do. On Sun, Nov 2, 2025, 11:20?PM Mark Yagnatinsky wrote: > Thanks for replying! I guess I'm not convinced that their "mere > existence" means that each feature needs to take them into account. > For one thing, they already don't work, and they are already deprecated. > They are also "well contained": the bulk of the API surface lives in just > one package (java.applet). > (Compare this to, say, the Security Manager, which really did have its > tendrils all over the place, or serialization, which still does.) > > I'm also not sure WebStart is quite analogous here. (Disclaimer: I know > roughly nothing about webstart; this may all be wrong.) > As far as I understand, all you need for web start to work is that some > program on your computer knows what to do with JNLP files. > Thus, it's perfectly practical for a third party to write such a program. > The only "tricky" part that I can think of is to ensure that the > javax.jnlp package exists even when running on newer versions of the JDK, > But since the JNLP launcher has full control of the classpath of the JVM, > it can indeed arrange for this. > > In the case of desktop apps that also happen to be applets, it's not clear > to me what to do; we no longer have a separate launcher. > Is the idea to create a jar file with the contents of the java.applet > package, and then tell people to always add it to their classpath? > > Either way, thanks for confirming the mailing list! > Mark. > > On Sun, Nov 2, 2025 at 8:55?PM David Alayachew > wrote: > >> No, you are on the right mailing list. >> >> Let me start by saying -- I know how you feel. The way you feel about >> Applets is exactly how I felt about Java WebStart >> . I'm still cranky about >> it's removal. >> >> But to jump right into the point -- Deprecation for Removal means that >> the OpenJDK will no longer support this API, and thus, are removing it from >> the SDK. >> >> But that doesn't mean that the functionality is dead, just means that it >> won't be supported by the OpenJDK. My WebStart has found new life under >> OpenWebStart . I guarantee you that a similar >> thing will be made for Applets, as Applets went way further than Java >> WebStart ever did. >> >> And as for the reason, please remember that the existence of a feature >> means that it adds weight to the load. Java Applets could receive no >> changes whatsoever for the next 10 years, and yet *their mere existence* in >> the SDK contributes a large amount to the maintenance effort. And the >> reason why it adds so much to the maintenance effort is because Java must >> ensure that each feature or library they introduce is cohesive with the >> SDK. By keeping Applets in, that's one more thing that needs to be checked >> against. And Applets are large enough that this checking is non-trivial. >> >> I would encourage you (and those you come across) to look to Open Source >> Software solutions to the removal of Applets. You might be surprised how >> easy it is to achieve. >> >> On Fri, Oct 31, 2025 at 2:35?PM Mark Yagnatinsky >> wrote: >> >>> In the olden days, it was pretty common to make apps that supported two >>> launch modes: >>> 1. entry point in main() created its own window using JFrame or whatever. >>> 2. But also extend Applet so as to run in the browser. >>> >>> These days, the second mode no longer works because no browser supports >>> applets. >>> But the first mode still works fine. It would STOP working if the >>> applet API were removed. >>> (In particular, class loading would fail if the JVM can't find the >>> parent class.) >>> >>> Normally, when we talk about removing APIs, there is a simple bit of >>> messaging that goes something like this: >>> 1. This is hopefully a simple code change (e.g., stop extending Applet, >>> since it does you no good anyway). >>> 2. If you're not ready to make the code change, stay on an old version >>> for now >>> 3. If you're not going to be ready soon, use an LTS release. >>> >>> There's a cluster of vague implicit assumptions buried in such >>> messaging, such as: >>> 1. The application is actively maintained, or at least there exists a >>> person or group of people nominally in charge of maintaining it. >>> 2. The user and developer of the application are one and the same >>> person, or at least know each other or have some sort of business >>> relationship or SOMETHING. >>> 3. In short, it assumes that if the application doesn't run, the >>> developer has some reason to care. If the developer doesn't care, it's >>> presumably because the app has no users and hence nobody cares. >>> >>> In the case of the applet API, this is all largely false. >>> There are people who once upon a time put a cute little applet on the >>> web, and also made it runnable standalone. >>> If anyone happens to find this useful to them, then all the better, but >>> those people are not customers, just like someone is not your customer just >>> because they happen to read your blog. >>> In other words, if these cute little former applets stop working, the >>> original author has no incentive to care and might not even notice for many >>> years. >>> >>> But even though these are all unmaintained, it does not mean they are >>> unused! >>> They may indeed have users, possibly users who find them indispensable! >>> But those users may not have access to the code, and may not be >>> programmers even if they did have access. >>> To those users, removing the applet API means that these apps no longer >>> work on the latest JDK, and they have no one to complain to. >>> >>> For a while, they can stay on old JDK, but eventually this becomes >>> harder and harder as old JDK versions may not support new operating systems >>> and CPUs and stuff. >>> (Not everyone knows how to set up a VM and an emulator and stuff.) >>> Also, some people may be too nervous to run an old JVM that hasn't >>> gotten security updates in a long time. >>> >>> Conversely, consider the cost of keeping these APIs. They would still >>> be deprecated. >>> Nobody is filing bug reports against them, since they are unusable >>> anyway. >>> They are not "literally free" but the maintenance burden for the OpenJDK >>> team should be only marginally higher than the maintenance burden of dead >>> code. >>> >>> Thoughts? >>> >>> Thanks, >>> Mark. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From azvegint at openjdk.org Mon Nov 3 05:39:05 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 3 Nov 2025 05:39:05 GMT Subject: RFR: 8370637: [Windows] Crash if use Graphics after PrintJob.end [v2] In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 21:17:50 GMT, Phil Race wrote: >> Synchronize WPrinterJob calls which use the printDC to avoid crash in case of mis-use. >> The printerDC is released when the job ends. >> It is zero-ed out in the handle in which it is stored >> The calls which expect it to be valid now all check for zero and return if it is zero. >> The calls are made synchronized as is the call to endDoc which zeroes it, so that they cannot have it zeroed out whilst using it. >> >> The tests are the same as in the fix for JDK-8370141 which is also under review. >> Which ever is 2nd to be pushed will have to merge in the changes from the first > > Phil Race has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - 8370637 > - 8370637 > - Merge > - 8370637 Marked as reviewed by azvegint (Reviewer). src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java line 956: > 954: } > 955: > 956: protected synchronized void beginPath() { Perhaps this is a topic for a different PR, but the `protected` keyword is redundant here, as well as in many other places in the class, because the `WPrinterJob` is a final class. src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 1589: > 1587: if ((HDC)dc != NULL) { > 1588: DeletePrintDC((HDC)dc); > 1589: } Suggestion: if ((HDC)dc != NULL) { DeletePrintDC((HDC)dc); } The closing brace is misaligned here and in all other cases. src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 1871: > 1869: TRY; > 1870: > 1871: if ((HDC)printDC == NULL) { There is no need to place this check inside the try-catch block. src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 2249: > 2247: if ((HDC)printDC == NULL) { > 2248: return; > 2249: } Suggestion: if ((HDC)printDC == NULL) { return; } There are several cases of similar alignment issues. ------------- PR Review: https://git.openjdk.org/jdk/pull/27984#pullrequestreview-3409406830 PR Review Comment: https://git.openjdk.org/jdk/pull/27984#discussion_r2485346330 PR Review Comment: https://git.openjdk.org/jdk/pull/27984#discussion_r2485315283 PR Review Comment: https://git.openjdk.org/jdk/pull/27984#discussion_r2485332854 PR Review Comment: https://git.openjdk.org/jdk/pull/27984#discussion_r2485329414 From jdv at openjdk.org Mon Nov 3 08:28:14 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 3 Nov 2025 08:28:14 GMT Subject: RFR: 8357034: GifImageDecoder can produce wrong transparent pixels [v8] In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 21:26:45 GMT, Jeremy Wood wrote: >> If there are two consecutive frames that use DISPOSAL_SAVE, but the transparent pixel index changed: we might accidentally send the wrong data to the ImageConsumer. >> >> We already had logic that submits info "the hard way" (see comment in code); this PR just makes sure we trigger that block. >> >> There are a cluster of four related PRs that share the GifComparison class in this PR. >> >> 1. [8357034](https://github.com/openjdk/jdk/pull/25264) (this one) >> 2. ~~[8356137](https://github.com/openjdk/jdk/pull/25044)~~ (integrated) >> 3. [8356320](https://github.com/openjdk/jdk/pull/25076) >> 4. [8351913](https://github.com/openjdk/jdk/pull/24271) >> >> This bug can be observed reading these gif animations: >> >> https://giphy.com/gifs/fomoduck-duck-fomo-ZUlzR40oGACqNmy0q8 >> https://media4.giphy.com/media/Zbf4JQzcDhzeraQvk9/giphy.gif >> https://giphy.com/gifs/computer-working-cat-LHZyixOnHwDDy >> https://giphy.com/gifs/90s-fgfgif-r4BmI9xUaDuKJQdd3l >> >> ### Describing This Bug >> >> The steps/explanation that lead to this failure are a little complicated. I'll try to summarize the original bug here. >> >> All three frames in the unit test's GIF use disposal code doNotDispose, meaning the frames are layered one on top of the previous. >> >> The first frame produces 3 circles from left to right using these colors: >> 0xff0000 (red) 0xffff00 (yellow) 0x00ff00 (green) >> >> The background is 0x00ffff (cyan). It is the transparent pixel, so the first frame is: >> >> frame_0 >> >> Now we start processing the second frame. The pixels are the same, but the color model has changed so the zeroeth color (red) is the transparent index. >> >> When the GifImageDecoder layers the 2nd frame on top of the 1st frame, it notices that `model.equals(saved_model)` is `false`. This means it enter a block of code that refers to "the hard way" of passing new pixel information to the ImageConsumers. >> >> The 2nd frame, after being painted on the 1st frame, looks like: >> frame_1 >> ? >> The 3rd frame is exactly the same as the 2nd. But here's where the bug is: now `model.equals(saved_model)` is `true`, so GifImageDecoder tries to pass the pixel information the easy way. The result is: >> >> frame_2_awt > This is in response to: > https://github.com/openjdk/jdk/pull/25264/files#r2292318270 > - Merge branch 'master' into JDK-8357034 > - 8357034: re-wrapping line breaks > - 8356137, 8357034: add debug option to dump PNGs of frames > > This is in response to: > https://github.com/openjdk/jdk/pull/25044#pullrequestreview-3007487527 > - Merge branch 'master' into JDK-8357034 > > # Conflicts: > # test/jdk/sun/awt/image/gif/GifBuilder.java > # test/jdk/sun/awt/image/gif/GifComparison.java > - 8357034: avoid recalculating isSimpleSavedImageComparison for every line > > This is in response to: > https://github.com/openjdk/jdk/pull/25264#discussion_r2197097522 > - Merge branch 'master' into JDK-8357034 > - 8356320: Use new GifBuilder and remove ukraine-flag.gif > > This is an extension of work for this PR: > https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750 > - 8356137: adding copyright > - ... and 25 more: https://git.openjdk.org/jdk/compare/1781b186...ece8707a Marked as reviewed by jdv (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25264#pullrequestreview-3409879277 From psadhukhan at openjdk.org Mon Nov 3 08:30:06 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 3 Nov 2025 08:30:06 GMT Subject: RFR: 6185110: Undefined behaviour of SampleModel for width, height < 0 In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 22:30:53 GMT, Phil Race wrote: > The only significant change here is to ensure that all SampleModel types throw a specified exception if a client > calls any of the following methods with a negative width or height. > getPixels(..) > setPixels(..) > getSamples(..) > setSamples(..) > > The rest is fixing the javadoc to properly describe what happens and some minor cleanup. > I use {@inheritDoc} to avoid repeating the super-class doc. And no one now has to tediously compare them. > I could just delete the javadoc but that would cause no javadoc to be generated for an overridden method. > There were a couple of surprises with {@inheritDoc} and the one I had to deal with is that declared RuntimeExceptions > are not inherited. You need to explicitly re-add them. This because if it isn't an exception in the method signature (as in foo() throws BarException), and instead you only have "@throws BarException" it will not be inherited. > > I added a test which verifies the behaviour for illegal arguments. > > CSR is here https://bugs.openjdk.org/browse/JDK-8369623 I have relooked at this and have some comments.. src/java.desktop/share/classes/java/awt/image/BandedSampleModel.java line 603: > 601: * @param data The DataBuffer containing the image data > 602: * @see #getDataElements(int, int, Object, DataBuffer) > 603: * @throws NullPointerException if {@code data} is null. I guess we will get NPE if (@code obj] is also null...Shouldn't we specify that too? src/java.desktop/share/classes/java/awt/image/ComponentSampleModel.java line 901: > 899: * @param data the DataBuffer containing the image data > 900: * @see #getDataElements(int, int, Object, DataBuffer) > 901: * @throws NullPointerException if {@code data} is null. same here src/java.desktop/share/classes/java/awt/image/MultiPixelPackedSampleModel.java line 597: > 595: * @param data the {@code DataBuffer} containing the image data > 596: * @see #getDataElements(int, int, Object, DataBuffer) > 597: * @throws NullPointerException if {@code data} is null. here too src/java.desktop/share/classes/java/awt/image/MultiPixelPackedSampleModel.java line 650: > 648: * @param data the {@code DataBuffer} containing the image data > 649: * @see #getPixel(int, int, int[], DataBuffer) > 650: * @throws NullPointerException if {@code data} is null. here NPE can be thrown if iArray is null...maybe we should mention that in spec too.. src/java.desktop/share/classes/java/awt/image/SinglePixelPackedSampleModel.java line 571: > 569: * @param data The DataBuffer containing the image data. > 570: * @see #getDataElements(int, int, Object, DataBuffer) > 571: * @throws NullPointerException if {@code data} is null. same...NPE for null obj? ------------- Changes requested by psadhukhan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27754#pullrequestreview-3409716566 PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2485532857 PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2485535771 PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2485538234 PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2485552416 PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2485648028 From psadhukhan at openjdk.org Mon Nov 3 08:35:06 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 3 Nov 2025 08:35:06 GMT Subject: RFR: 4690476: NegativeArraySizeException from AffineTransformOp with shear In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 22:05:05 GMT, Phil Race wrote: > This fix does a couple of things > > 1) AffineTransformOp.createCompatibleDestImage() and AffineTransformOp.createCompatibleDestRaster() now specify that they will throw RasterFormatException if the transformed size is too large. They were already getting an exception. > Note that inside the JDK only the imaging API implementation itself uses these APIs and I suspect they are rarely used by applications. > > 2) AffineTransformOp.filter(src, null) will not throw an exception if it cannot create a destination image or raster of the required size and instead will use the source image size. This means applications which simply filter() will not need to carefully examine the transform. Sophisticated applications which want to do this can use the above "create*" methods to explicitly create the destination to find this out. > > So some inconsistency but I think it is a user-friendly trade-off. > > A CSR will be needed but I want to get past initial review first. > Update : CSR is now created https://bugs.openjdk.org/browse/JDK-8370162 test/jdk/java/awt/image/AffineTransformOp/AffineTxOpSizeTest.java line 2: > 1: /* > 2: * Copyright (c) 2017, Oracle and/or its affiliates. All rights reserved. shouldnt it be 2025? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27707#discussion_r2485665187 From psadhukhan at openjdk.org Mon Nov 3 08:39:07 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 3 Nov 2025 08:39:07 GMT Subject: RFR: 4690476: NegativeArraySizeException from AffineTransformOp with shear In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 22:05:05 GMT, Phil Race wrote: > This fix does a couple of things > > 1) AffineTransformOp.createCompatibleDestImage() and AffineTransformOp.createCompatibleDestRaster() now specify that they will throw RasterFormatException if the transformed size is too large. They were already getting an exception. > Note that inside the JDK only the imaging API implementation itself uses these APIs and I suspect they are rarely used by applications. > > 2) AffineTransformOp.filter(src, null) will not throw an exception if it cannot create a destination image or raster of the required size and instead will use the source image size. This means applications which simply filter() will not need to carefully examine the transform. Sophisticated applications which want to do this can use the above "create*" methods to explicitly create the destination to find this out. > > So some inconsistency but I think it is a user-friendly trade-off. > > A CSR will be needed but I want to get past initial review first. > Update : CSR is now created https://bugs.openjdk.org/browse/JDK-8370162 LGTM test/jdk/java/awt/image/AffineTransformOp/AffineTxOpSizeTest.java line 66: > 64: } catch (RasterFormatException e) { > 65: } > 66: } alignment ------------- Marked as reviewed by psadhukhan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27707#pullrequestreview-3409912528 PR Review Comment: https://git.openjdk.org/jdk/pull/27707#discussion_r2485673488 From psadhukhan at openjdk.org Mon Nov 3 08:44:02 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 3 Nov 2025 08:44:02 GMT Subject: RFR: 8370719: [Linux] Use /etc/os-release values for font configuration file names In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 19:07:04 GMT, Phil Race wrote: > The JBS issue has a long discussion and explanation but here's a short version. > Instead of having baked in names of distros in the code that figures out names for font configuration files for Linux > use the standard ID and VERSION_ID fields in /etc/os-release which is now standard. > even systemd doesn't work if it does not exist https://0pointer.de/blog/projects/os-release > And if it doesn't we just use "Linux" as the name. Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28073#pullrequestreview-3409936212 From psadhukhan at openjdk.org Mon Nov 3 08:50:04 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 3 Nov 2025 08:50:04 GMT Subject: RFR: 8370637: [Windows] Crash if use Graphics after PrintJob.end [v2] In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 21:17:50 GMT, Phil Race wrote: >> Synchronize WPrinterJob calls which use the printDC to avoid crash in case of mis-use. >> The printerDC is released when the job ends. >> It is zero-ed out in the handle in which it is stored >> The calls which expect it to be valid now all check for zero and return if it is zero. >> The calls are made synchronized as is the call to endDoc which zeroes it, so that they cannot have it zeroed out whilst using it. >> >> The tests are the same as in the fix for JDK-8370141 which is also under review. >> Which ever is 2nd to be pushed will have to merge in the changes from the first > > Phil Race has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - 8370637 > - 8370637 > - Merge > - 8370637 Marked as reviewed by psadhukhan (Reviewer). test/jdk/java/awt/PrintJob/PrintJobAfterEndTest.java line 26: > 24: > 25: /* > 26: @test no * here at all...to be consistent with above test and other, we can add * test/jdk/java/awt/print/PrinterJob/PrintAfterEndTest.java line 24: > 22: */ > 23: > 24: /** * single asterisk for consistency.. ------------- PR Review: https://git.openjdk.org/jdk/pull/27984#pullrequestreview-3409959096 PR Review Comment: https://git.openjdk.org/jdk/pull/27984#discussion_r2485703913 PR Review Comment: https://git.openjdk.org/jdk/pull/27984#discussion_r2485701930 From smandalika at openjdk.org Mon Nov 3 09:50:52 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Mon, 3 Nov 2025 09:50:52 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update [v2] In-Reply-To: References: Message-ID: <6XykBCcrEOsnVlocyyitMS58bEG-GCWIte8RyrJaMIY=.e93900f2-8c14-4061-b34a-2777fbe52cf5@github.com> > Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java > Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt. Srinivas Mandalika has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge master - 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update - 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update ------------- Changes: https://git.openjdk.org/jdk/pull/27139/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27139&range=01 Stats: 35 lines in 2 files changed: 0 ins; 9 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/27139.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27139/head:pull/27139 PR: https://git.openjdk.org/jdk/pull/27139 From psadhukhan at openjdk.org Mon Nov 3 10:05:12 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 3 Nov 2025 10:05:12 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v5] In-Reply-To: References: Message-ID: > If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder` > it throws NPE which is not mentioned in the spec as the expected outcome. > Fixed the NPE and the spec Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27949/files - new: https://git.openjdk.org/jdk/pull/27949/files/2c018656..d8de38b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27949&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27949&range=03-04 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27949.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27949/head:pull/27949 PR: https://git.openjdk.org/jdk/pull/27949 From duke at openjdk.org Mon Nov 3 10:57:11 2025 From: duke at openjdk.org (duke) Date: Mon, 3 Nov 2025 10:57:11 GMT Subject: RFR: 8368882: NPE during text drawing on machine with JP locale [v7] In-Reply-To: References: Message-ID: <2FKK7SaSffphJT4gfy4ymouokdGXWOBoyuimS6-ejJY=.b4a0c7a8-e03e-432e-8cb3-a53671c3a311@github.com> On Wed, 29 Oct 2025 19:09:13 GMT, Sergey Nazarkin wrote: >> There is a reproducible bug in symbol rendering on Windows machines with [particular](https://github.com/openjdk/jdk/blob/9d71af108ea2cc3682607527246d60a19fd820ba/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L244) default locales. This changeset fixes the deferred font initialisation request, which now skips the last font in the list. >> >> The test (attached to the jira) was performed on a Windows 11 machine with the Japanese locale set as the default. Without the fix, it fails with an NPE. With the fix it displays a window showing glyphs drawn by all the fonts accessible from the Java application. > > Sergey Nazarkin has updated the pull request incrementally with one additional commit since the last revision: > > Remove test @snazarkin Your change (at version af3eb2f85a1e0ad32c3756b96f7942ae4c7c36a3) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27551#issuecomment-3479932787 From snazarki at openjdk.org Mon Nov 3 12:59:22 2025 From: snazarki at openjdk.org (Sergey Nazarkin) Date: Mon, 3 Nov 2025 12:59:22 GMT Subject: Integrated: 8368882: NPE during text drawing on machine with JP locale In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 16:15:45 GMT, Sergey Nazarkin wrote: > There is a reproducible bug in symbol rendering on Windows machines with [particular](https://github.com/openjdk/jdk/blob/9d71af108ea2cc3682607527246d60a19fd820ba/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L244) default locales. This changeset fixes the deferred font initialisation request, which now skips the last font in the list. > > The test (attached to the jira) was performed on a Windows 11 machine with the Japanese locale set as the default. Without the fix, it fails with an NPE. With the fix it displays a window showing glyphs drawn by all the fonts accessible from the Java application. This pull request has now been integrated. Changeset: 4520983e Author: Sergey Nazarkin Committer: Dmitry Cherepanov URL: https://git.openjdk.org/jdk/commit/4520983e8e5fcfb22e04508d50676df6831fa636 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8368882: NPE during text drawing on machine with JP locale Reviewed-by: serb, prr, psadhukhan ------------- PR: https://git.openjdk.org/jdk/pull/27551 From aivanov at openjdk.org Mon Nov 3 15:16:49 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 3 Nov 2025 15:16:49 GMT Subject: RFR: 8349157: Unnecessary Hashtable usage in XKeysym.javaKeycode2KeysymHash In-Reply-To: References: Message-ID: <8INk7EJ6ggAMkJcaIJ290UaCxxoAGkLbo6cJhhiVNU0=.d36ca5d5-6fbe-4d4d-af8a-0140b3bbdd2c@github.com> On Wed, 29 Jan 2025 09:35:09 GMT, Andrey Turbanov wrote: > There is a field `sun.awt.X11.XKeysym#javaKeycode2KeysymHash` which uses legacy Hashtable class. > As this map is read-only and all its content is initialized in `` we can safely use immutable Map instead. Looks reasonable to me. I'd approve it. ------------- PR Review: https://git.openjdk.org/jdk/pull/23347#pullrequestreview-3411499877 From markyag at gmail.com Mon Nov 3 15:22:46 2025 From: markyag at gmail.com (Mark Yagnatinsky) Date: Mon, 3 Nov 2025 10:22:46 -0500 Subject: a last-minute plea to reconsider JEP 504: removing the applet API breaks non-applets In-Reply-To: References: Message-ID: We seem to be talking past each other, at least slightly. My goal is NOT to actually run applets. Anyone who wanted to actually run applets should have complained to browser vendors many years ago, as opposed to complaining to Java devs now. My point is that there are many apps that were published with TWO entry points class Main extends javax.swing.JApplet { // entry point 1: be an applet public static void main(String... argos){} // entry point 2: main method } By removing the applet API, we break use case #2, because the class loader will fail to load Main because its parent class does not exist. Note that this use case does not care about "testing coverage, performance, bug reports, etc". The applet API does not have to actually WORK, let alone work well. It suffices for the classes to exist, so that class loading succeeds. As for "make a runtime image that includes them, then tell people to download that"... WHO should do this, exactly? Certainly not the author of the applet! The whole worry is that the applet is unmaintained! The idea must then be that 1. some third party creates such a thing, and then 2. this becomes popular enough that someone with moderate skills in Google-fu can find this thing once they notice they can't run their favorite app anymore. If nothing else, the wording in the JEP needs a bit of clarification to say that this is indeed the hoped-for plan for these old apps. Jep 504 is here: JEP 504: Remove the Applet API In the "risks and assumptions" section, it has this: "Given that it is largely unusable, there are no substantial risks to user applications in removing the Applet API." The point I'm trying to make here is that there is indeed a substantial risk, DESPITE the fact that it is indeed unusable! And the "motivation" section makes a similar claim. There should at the very least be a few words in the JEP that discuss the breakage of non-applets. I tried to bring this up on the jdk-dev list back when I heard about deprecation for removal, here: The jdk-dev April 2021 Archive by thread Back then, some folks seemed somewhat sympathetic. (Hmm... maybe I should try that list again??) For instance, Alan Bateman said "It seems reasonable to use the intervening period to explore migration options and see if it's worth leaving some kind of carcass in place to keep the abandoned code running in stand-alone code for a bit longer." But as far as I can tell, nothing came of it. At the very least it seems the JEP text should mention the problem? On Mon, Nov 3, 2025 at 12:21?AM David Alayachew wrote: > You're coming at this from the API and functionality perspective. I am > saying to look at it from the testing coverage, performance, bug reports, > etc. There are a lot of standards to maintain, and thus, A LOT that goes > into maintaining the JDK. Being well contained only eases some parts of the > effort. > > As for WebStart, yet another side of maintainability is security. WebStart > could be (and has been) used to exploit vulnerabilities, so the reasons to > remove it increased even further. > > As for running Applets, that should be very easy to do. Like you said, > provide implementations for the classes and methods in the applet packages, > make a runtime image that includes them, then tell people to download that. > You can also build a launcher that calls the necessary Applet API's. While > it won't be as straight forward as WebStart, it's still very easy to do. > > On Sun, Nov 2, 2025, 11:20?PM Mark Yagnatinsky wrote: > >> Thanks for replying! I guess I'm not convinced that their "mere >> existence" means that each feature needs to take them into account. >> For one thing, they already don't work, and they are already deprecated. >> They are also "well contained": the bulk of the API surface lives in just >> one package (java.applet). >> (Compare this to, say, the Security Manager, which really did have its >> tendrils all over the place, or serialization, which still does.) >> >> I'm also not sure WebStart is quite analogous here. (Disclaimer: I know >> roughly nothing about webstart; this may all be wrong.) >> As far as I understand, all you need for web start to work is that some >> program on your computer knows what to do with JNLP files. >> Thus, it's perfectly practical for a third party to write such a program. >> The only "tricky" part that I can think of is to ensure that the >> javax.jnlp package exists even when running on newer versions of the JDK, >> But since the JNLP launcher has full control of the classpath of the JVM, >> it can indeed arrange for this. >> >> In the case of desktop apps that also happen to be applets, it's not >> clear to me what to do; we no longer have a separate launcher. >> Is the idea to create a jar file with the contents of the java.applet >> package, and then tell people to always add it to their classpath? >> >> Either way, thanks for confirming the mailing list! >> Mark. >> >> On Sun, Nov 2, 2025 at 8:55?PM David Alayachew >> wrote: >> >>> No, you are on the right mailing list. >>> >>> Let me start by saying -- I know how you feel. The way you feel about >>> Applets is exactly how I felt about Java WebStart >>> . I'm still cranky about >>> it's removal. >>> >>> But to jump right into the point -- Deprecation for Removal means that >>> the OpenJDK will no longer support this API, and thus, are removing it from >>> the SDK. >>> >>> But that doesn't mean that the functionality is dead, just means that it >>> won't be supported by the OpenJDK. My WebStart has found new life under >>> OpenWebStart . I guarantee you that a >>> similar thing will be made for Applets, as Applets went way further than >>> Java WebStart ever did. >>> >>> And as for the reason, please remember that the existence of a feature >>> means that it adds weight to the load. Java Applets could receive no >>> changes whatsoever for the next 10 years, and yet *their mere existence* in >>> the SDK contributes a large amount to the maintenance effort. And the >>> reason why it adds so much to the maintenance effort is because Java must >>> ensure that each feature or library they introduce is cohesive with the >>> SDK. By keeping Applets in, that's one more thing that needs to be checked >>> against. And Applets are large enough that this checking is non-trivial. >>> >>> I would encourage you (and those you come across) to look to Open Source >>> Software solutions to the removal of Applets. You might be surprised how >>> easy it is to achieve. >>> >>> On Fri, Oct 31, 2025 at 2:35?PM Mark Yagnatinsky >>> wrote: >>> >>>> In the olden days, it was pretty common to make apps that supported two >>>> launch modes: >>>> 1. entry point in main() created its own window using JFrame or >>>> whatever. >>>> 2. But also extend Applet so as to run in the browser. >>>> >>>> These days, the second mode no longer works because no browser supports >>>> applets. >>>> But the first mode still works fine. It would STOP working if the >>>> applet API were removed. >>>> (In particular, class loading would fail if the JVM can't find the >>>> parent class.) >>>> >>>> Normally, when we talk about removing APIs, there is a simple bit of >>>> messaging that goes something like this: >>>> 1. This is hopefully a simple code change (e.g., stop extending Applet, >>>> since it does you no good anyway). >>>> 2. If you're not ready to make the code change, stay on an old version >>>> for now >>>> 3. If you're not going to be ready soon, use an LTS release. >>>> >>>> There's a cluster of vague implicit assumptions buried in such >>>> messaging, such as: >>>> 1. The application is actively maintained, or at least there exists a >>>> person or group of people nominally in charge of maintaining it. >>>> 2. The user and developer of the application are one and the same >>>> person, or at least know each other or have some sort of business >>>> relationship or SOMETHING. >>>> 3. In short, it assumes that if the application doesn't run, the >>>> developer has some reason to care. If the developer doesn't care, it's >>>> presumably because the app has no users and hence nobody cares. >>>> >>>> In the case of the applet API, this is all largely false. >>>> There are people who once upon a time put a cute little applet on the >>>> web, and also made it runnable standalone. >>>> If anyone happens to find this useful to them, then all the better, but >>>> those people are not customers, just like someone is not your customer just >>>> because they happen to read your blog. >>>> In other words, if these cute little former applets stop working, the >>>> original author has no incentive to care and might not even notice for many >>>> years. >>>> >>>> But even though these are all unmaintained, it does not mean they are >>>> unused! >>>> They may indeed have users, possibly users who find them indispensable! >>>> But those users may not have access to the code, and may not be >>>> programmers even if they did have access. >>>> To those users, removing the applet API means that these apps no longer >>>> work on the latest JDK, and they have no one to complain to. >>>> >>>> For a while, they can stay on old JDK, but eventually this becomes >>>> harder and harder as old JDK versions may not support new operating systems >>>> and CPUs and stuff. >>>> (Not everyone knows how to set up a VM and an emulator and stuff.) >>>> Also, some people may be too nervous to run an old JVM that hasn't >>>> gotten security updates in a long time. >>>> >>>> Conversely, consider the cost of keeping these APIs. They would still >>>> be deprecated. >>>> Nobody is filing bug reports against them, since they are unusable >>>> anyway. >>>> They are not "literally free" but the maintenance burden for the >>>> OpenJDK team should be only marginally higher than the maintenance burden >>>> of dead code. >>>> >>>> Thoughts? >>>> >>>> Thanks, >>>> Mark. >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbaesken at openjdk.org Mon Nov 3 15:28:10 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 3 Nov 2025 15:28:10 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v2] In-Reply-To: References: <5OAU93NhLcyzzkr2M029oa4nQnyzqqDQqBwvJjNhKsA=.9bca2a2c-4f38-47a5-9a04-8cc415a99008@github.com> <8O4Yy-dC8NorVuQ6MNOSmx2neronvvnG1BscwtjjOYI=.47d69f86-71ed-4b41-a328-eb222c332b6e@github.com> Message-ID: On Thu, 30 Oct 2025 15:41:06 GMT, Matthias Baesken wrote: > For those libs where we set LTO = true, we can add a global on/off configure arg to enable this. This way, we do not cause issues for distributors because still the configure flag must be set For Hotspot / libjvm we have currently `--enable-jvm-feature-link-time-opt` ; maybe we should introduce something similar named for the JDK libs where we choose lto? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3481107407 From smandalika at openjdk.org Mon Nov 3 16:05:42 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Mon, 3 Nov 2025 16:05:42 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update [v3] In-Reply-To: References: Message-ID: > Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java > Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt. Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: 8068378: Review feedback for instructions, missing break in switch case in Test.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27139/files - new: https://git.openjdk.org/jdk/pull/27139/files/6045f729..15ecb2f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27139&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27139&range=01-02 Stats: 21 lines in 2 files changed: 5 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/27139.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27139/head:pull/27139 PR: https://git.openjdk.org/jdk/pull/27139 From smandalika at openjdk.org Mon Nov 3 16:17:14 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Mon, 3 Nov 2025 16:17:14 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update [v4] In-Reply-To: References: Message-ID: > Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java > Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt. Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: Fixed whitepsace error. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27139/files - new: https://git.openjdk.org/jdk/pull/27139/files/15ecb2f0..aa874e0c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27139&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27139&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27139.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27139/head:pull/27139 PR: https://git.openjdk.org/jdk/pull/27139 From smandalika at openjdk.org Mon Nov 3 16:17:16 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Mon, 3 Nov 2025 16:17:16 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update [v3] In-Reply-To: References: Message-ID: <52mzOqswcrKLvU_wHyTr_Ytyj2Y-dSJqOgBNZsThe4g=.bebeca7a-d935-4caa-8d67-da4ca3ed3798@github.com> On Mon, 3 Nov 2025 16:05:42 GMT, Srinivas Mandalika wrote: >> Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java >> Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > 8068378: Review feedback for instructions, missing break in switch case in Test.java image ------------- PR Comment: https://git.openjdk.org/jdk/pull/27139#issuecomment-3481319246 From smandalika at openjdk.org Mon Nov 3 16:17:19 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Mon, 3 Nov 2025 16:17:19 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update [v4] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 17:52:16 GMT, Phil Race wrote: >> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed whitepsace error. > > test/jdk/java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java line 65: > >> 63: "Verification step:\n" + >> 64: "Button is presseed - only if Modality Selection was 'Non-modal' or 'Modeless'.\n" + >> 65: "In all other cases, Window (3) should block input to Windows (1) and (2).\n\n" + > > I'm not sure this is correct. Document modal is not discussed here and its behavior will depend on the parent selection. If it is Dialog or Frame it will block. If it hidden or NULL, it won't block. > I see that on Mac and it makes sense if we consider that only in the Dialog/Frame cases are we making these the parent of the modal dialog. I've not tried other platforms but you should check but this is core AWT behavior so I hope it is the same. Fixed. Verified the behavior of all modes on Windows 11 x64, Ubuntu 25.10 x64 and Mac OSX 15 aarch64. Modified instructions to detail out scenarios for all modality types. Included behavior for document modal with parent as dialog/ frame and others as well. Fixed a missing break in switch case of Test.java causing a test bug. Instructions screen shot attached for reference. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27139#discussion_r2487039940 From prr at openjdk.org Mon Nov 3 17:25:58 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 3 Nov 2025 17:25:58 GMT Subject: RFR: 8370637: [Windows] Crash if use Graphics after PrintJob.end [v3] In-Reply-To: References: Message-ID: <_mphYSlTVI7kIHuamuZrx0nDVPi5mJVw0nNuustY3vs=.ec499d51-cd18-49c4-853b-988a6a1e624a@github.com> > Synchronize WPrinterJob calls which use the printDC to avoid crash in case of mis-use. > The printerDC is released when the job ends. > It is zero-ed out in the handle in which it is stored > The calls which expect it to be valid now all check for zero and return if it is zero. > The calls are made synchronized as is the call to endDoc which zeroes it, so that they cannot have it zeroed out whilst using it. > > The tests are the same as in the fix for JDK-8370141 which is also under review. > Which ever is 2nd to be pushed will have to merge in the changes from the first Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8370637 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27984/files - new: https://git.openjdk.org/jdk/pull/27984/files/4a4db71b..c6ac30b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27984&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27984&range=01-02 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27984.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27984/head:pull/27984 PR: https://git.openjdk.org/jdk/pull/27984 From davidalayachew at gmail.com Mon Nov 3 17:49:33 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Mon, 3 Nov 2025 12:49:33 -0500 Subject: a last-minute plea to reconsider JEP 504: removing the applet API breaks non-applets In-Reply-To: References: Message-ID: The Applet API and Applet classes merely existing in the JDK absolutely still contributes to testing coverage, performance, bug reports, etc. I understand now that you want to just have your code still compile. I am trying to tell you that even that goal still comes at a significant enough cost that removing them makes very good sense for the aforementioned reasons. As for the runtime image, it is not the OpenJDK's responsibility to find a worthy successor. Harsh as it is, this is the OpenJDK cutting off what they perceive as dead weight because of the aforementioned costs. Whoever picks it up and brings it back alive, great. And in this case, it should be quite easy to do. But the concept of a hoped for plan is not relevant here because the OpenJDK is not here to dictate what they want the community to do in regards to foster-parenting these orphaned applets. As for the JEP's wording, try and think at the scale of billions of Java programs when reading that quote. When looking at the scale of billions, sadly, "no substantial risks" is an accurate statement. As for Alan Bateman's quote, notice how he said "a little longer". This is very much him offering to lengthen the runway a little longer. But the intent still remains -- cutting off applets completely, including any remaining vestiges of the API. The lengthened runway is just to give people time to migrate, delaying the inevitable. On Mon, Nov 3, 2025, 10:23?AM Mark Yagnatinsky wrote: > We seem to be talking past each other, at least slightly. My goal is NOT > to actually run applets. > Anyone who wanted to actually run applets should have complained to > browser vendors many years ago, as opposed to complaining to Java devs now. > My point is that there are many apps that were published with TWO entry > points > > class Main extends javax.swing.JApplet { // entry point 1: be an applet > public static void main(String... argos){} // entry point 2: main > method > } > > By removing the applet API, we break use case #2, because the class loader > will fail to load Main because its parent class does not exist. > Note that this use case does not care about "testing coverage, > performance, bug reports, etc". > The applet API does not have to actually WORK, let alone work well. > It suffices for the classes to exist, so that class loading succeeds. > > As for "make a runtime image that includes them, then tell people to > download that"... WHO should do this, exactly? > Certainly not the author of the applet! The whole worry is that the > applet is unmaintained! > The idea must then be that > 1. some third party creates such a thing, and then > 2. this becomes popular enough that someone with moderate skills in > Google-fu can find this thing once they notice they can't run their > favorite app anymore. > > If nothing else, the wording in the JEP needs a bit of clarification to > say that this is indeed the hoped-for plan for these old apps. > Jep 504 is here: JEP 504: Remove the Applet API > > In the "risks and assumptions" section, it has this: > "Given that it is largely unusable, there are no substantial risks to user > applications in removing the Applet API." > The point I'm trying to make here is that there is indeed a substantial > risk, DESPITE the fact that it is indeed unusable! > And the "motivation" section makes a similar claim. > There should at the very least be a few words in the JEP that discuss the > breakage of non-applets. > > I tried to bring this up on the jdk-dev list back when I heard about > deprecation for removal, here: > The jdk-dev April 2021 Archive by thread > > Back then, some folks seemed somewhat sympathetic. (Hmm... maybe I should > try that list again??) > For instance, Alan Bateman said > > "It seems reasonable to use the intervening > period to explore migration options and see if it's worth leaving some > kind of carcass in place to keep the abandoned code running in > stand-alone code for a bit longer." > > But as far as I can tell, nothing came of it. > At the very least it seems the JEP text should mention the problem? > > On Mon, Nov 3, 2025 at 12:21?AM David Alayachew > wrote: > >> You're coming at this from the API and functionality perspective. I am >> saying to look at it from the testing coverage, performance, bug reports, >> etc. There are a lot of standards to maintain, and thus, A LOT that goes >> into maintaining the JDK. Being well contained only eases some parts of the >> effort. >> >> As for WebStart, yet another side of maintainability is security. >> WebStart could be (and has been) used to exploit vulnerabilities, so the >> reasons to remove it increased even further. >> >> As for running Applets, that should be very easy to do. Like you said, >> provide implementations for the classes and methods in the applet packages, >> make a runtime image that includes them, then tell people to download that. >> You can also build a launcher that calls the necessary Applet API's. While >> it won't be as straight forward as WebStart, it's still very easy to do. >> >> On Sun, Nov 2, 2025, 11:20?PM Mark Yagnatinsky wrote: >> >>> Thanks for replying! I guess I'm not convinced that their "mere >>> existence" means that each feature needs to take them into account. >>> For one thing, they already don't work, and they are already deprecated. >>> They are also "well contained": the bulk of the API surface lives in >>> just one package (java.applet). >>> (Compare this to, say, the Security Manager, which really did have its >>> tendrils all over the place, or serialization, which still does.) >>> >>> I'm also not sure WebStart is quite analogous here. (Disclaimer: I know >>> roughly nothing about webstart; this may all be wrong.) >>> As far as I understand, all you need for web start to work is that some >>> program on your computer knows what to do with JNLP files. >>> Thus, it's perfectly practical for a third party to write such a program. >>> The only "tricky" part that I can think of is to ensure that the >>> javax.jnlp package exists even when running on newer versions of the JDK, >>> But since the JNLP launcher has full control of the classpath of the >>> JVM, it can indeed arrange for this. >>> >>> In the case of desktop apps that also happen to be applets, it's not >>> clear to me what to do; we no longer have a separate launcher. >>> Is the idea to create a jar file with the contents of the java.applet >>> package, and then tell people to always add it to their classpath? >>> >>> Either way, thanks for confirming the mailing list! >>> Mark. >>> >>> On Sun, Nov 2, 2025 at 8:55?PM David Alayachew >>> wrote: >>> >>>> No, you are on the right mailing list. >>>> >>>> Let me start by saying -- I know how you feel. The way you feel about >>>> Applets is exactly how I felt about Java WebStart >>>> . I'm still cranky about >>>> it's removal. >>>> >>>> But to jump right into the point -- Deprecation for Removal means that >>>> the OpenJDK will no longer support this API, and thus, are removing it from >>>> the SDK. >>>> >>>> But that doesn't mean that the functionality is dead, just means that >>>> it won't be supported by the OpenJDK. My WebStart has found new life under >>>> OpenWebStart . I guarantee you that a >>>> similar thing will be made for Applets, as Applets went way further than >>>> Java WebStart ever did. >>>> >>>> And as for the reason, please remember that the existence of a feature >>>> means that it adds weight to the load. Java Applets could receive no >>>> changes whatsoever for the next 10 years, and yet *their mere >>>> existence* in the SDK contributes a large amount to the maintenance >>>> effort. And the reason why it adds so much to the maintenance effort is >>>> because Java must ensure that each feature or library they introduce is >>>> cohesive with the SDK. By keeping Applets in, that's one more thing that >>>> needs to be checked against. And Applets are large enough that this >>>> checking is non-trivial. >>>> >>>> I would encourage you (and those you come across) to look to Open >>>> Source Software solutions to the removal of Applets. You might be surprised >>>> how easy it is to achieve. >>>> >>>> On Fri, Oct 31, 2025 at 2:35?PM Mark Yagnatinsky >>>> wrote: >>>> >>>>> In the olden days, it was pretty common to make apps that supported >>>>> two launch modes: >>>>> 1. entry point in main() created its own window using JFrame or >>>>> whatever. >>>>> 2. But also extend Applet so as to run in the browser. >>>>> >>>>> These days, the second mode no longer works because no browser >>>>> supports applets. >>>>> But the first mode still works fine. It would STOP working if the >>>>> applet API were removed. >>>>> (In particular, class loading would fail if the JVM can't find the >>>>> parent class.) >>>>> >>>>> Normally, when we talk about removing APIs, there is a simple bit of >>>>> messaging that goes something like this: >>>>> 1. This is hopefully a simple code change (e.g., stop extending >>>>> Applet, since it does you no good anyway). >>>>> 2. If you're not ready to make the code change, stay on an old version >>>>> for now >>>>> 3. If you're not going to be ready soon, use an LTS release. >>>>> >>>>> There's a cluster of vague implicit assumptions buried in such >>>>> messaging, such as: >>>>> 1. The application is actively maintained, or at least there exists a >>>>> person or group of people nominally in charge of maintaining it. >>>>> 2. The user and developer of the application are one and the same >>>>> person, or at least know each other or have some sort of business >>>>> relationship or SOMETHING. >>>>> 3. In short, it assumes that if the application doesn't run, the >>>>> developer has some reason to care. If the developer doesn't care, it's >>>>> presumably because the app has no users and hence nobody cares. >>>>> >>>>> In the case of the applet API, this is all largely false. >>>>> There are people who once upon a time put a cute little applet on the >>>>> web, and also made it runnable standalone. >>>>> If anyone happens to find this useful to them, then all the better, >>>>> but those people are not customers, just like someone is not your customer >>>>> just because they happen to read your blog. >>>>> In other words, if these cute little former applets stop working, the >>>>> original author has no incentive to care and might not even notice for many >>>>> years. >>>>> >>>>> But even though these are all unmaintained, it does not mean they are >>>>> unused! >>>>> They may indeed have users, possibly users who find them indispensable! >>>>> But those users may not have access to the code, and may not be >>>>> programmers even if they did have access. >>>>> To those users, removing the applet API means that these apps no >>>>> longer work on the latest JDK, and they have no one to complain to. >>>>> >>>>> For a while, they can stay on old JDK, but eventually this becomes >>>>> harder and harder as old JDK versions may not support new operating systems >>>>> and CPUs and stuff. >>>>> (Not everyone knows how to set up a VM and an emulator and stuff.) >>>>> Also, some people may be too nervous to run an old JVM that hasn't >>>>> gotten security updates in a long time. >>>>> >>>>> Conversely, consider the cost of keeping these APIs. They would still >>>>> be deprecated. >>>>> Nobody is filing bug reports against them, since they are unusable >>>>> anyway. >>>>> They are not "literally free" but the maintenance burden for the >>>>> OpenJDK team should be only marginally higher than the maintenance burden >>>>> of dead code. >>>>> >>>>> Thoughts? >>>>> >>>>> Thanks, >>>>> Mark. >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From serb at openjdk.org Mon Nov 3 19:03:54 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 3 Nov 2025 19:03:54 GMT Subject: RFR: 8364583: ColorConvertOp fails for CMYK =?UTF-8?B?4oaS?= RGB conversion In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 05:25:44 GMT, Phil Race wrote: > color is initially returned as 4 element array but we over-write with 3 element and so next time through the loop it is used by but is too short. > More details in JBS. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27785#pullrequestreview-3412482120 From serb at openjdk.org Mon Nov 3 19:03:55 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 3 Nov 2025 19:03:55 GMT Subject: RFR: 8364583: ColorConvertOp fails for CMYK =?UTF-8?B?4oaS?= RGB conversion In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 21:47:31 GMT, Phil Race wrote: >>> It can also be over-written at line 835. >> >> Interesting, is it possible that that line has the same bug? >> `color = dstColorSpace.fromCIEXYZ(dstColor);` >> Does dstColor always have the same number of components as CIEXYZ? >> >> Is the logic of using CIEXYZ for mix of non-/ICC source and non-/ICC destination actually correct? > > fromCIEXYZ is defined on ColorSpace, not ICC_ColorSpace. > > It requires 3 (or more) components, and then dstColorSpace will return an array of colors in its own colorspace. > The dstColor parameter is always created with at least 3 components based on the dstNumComp > And if there's no bug in dstColorSpace it should return an array of the right length for itself. > So if there's a bug it isn't obvious to me. Seems the destination handles it properly; I tested it with the following example: import java.awt.Transparency; import java.awt.color.ColorSpace; import java.awt.image.BufferedImage; import java.awt.image.ColorConvertOp; import java.awt.image.ComponentColorModel; import java.awt.image.DataBuffer; import java.awt.image.WritableRaster; import static java.awt.color.ColorSpace.TYPE_2CLR; import static java.awt.color.ColorSpace.TYPE_FCLR; import static java.awt.color.ColorSpace.TYPE_GRAY; public final class TestCCP { private static final int WIDTH = 10; private static final int HEIGHT = 10; private static class CustomColorSpace extends ColorSpace { private final int numComponents; private CustomColorSpace(int type, int numComponents) { super(type, numComponents); this.numComponents = numComponents; } @Override public float[] toRGB(float[] colorvalue) { return new float[3]; } @Override public float[] fromRGB(float[] rgbvalue) { return new float[numComponents]; } @Override public float[] toCIEXYZ(float[] colorvalue) { return new float[3]; } @Override public float[] fromCIEXYZ(float[] colorvalue) { return new float[numComponents]; } } private static final ColorSpace[] CS = { ColorSpace.getInstance(ColorSpace.CS_CIEXYZ), ColorSpace.getInstance(ColorSpace.CS_GRAY), ColorSpace.getInstance(ColorSpace.CS_LINEAR_RGB), ColorSpace.getInstance(ColorSpace.CS_PYCC), ColorSpace.getInstance(ColorSpace.CS_sRGB), new CustomColorSpace(TYPE_GRAY, 1), new CustomColorSpace(TYPE_2CLR, 2), new CustomColorSpace(TYPE_FCLR, 15) }; public static void main(String[] args) { for (ColorSpace srcCS : CS) { for (ColorSpace fromCS : CS) { for (ColorSpace toCS : CS) { for (ColorSpace dstCS : CS) { BufferedImage src = createTestImage(srcCS); BufferedImage dst = createTestImage(dstCS); new ColorConvertOp(fromCS, toCS, null).filter(src, dst); } } } } } private static BufferedImage createTestImage(ColorSpace cs) { ComponentColorModel cm = new ComponentColorModel(cs, false, false, Transparency.OPAQUE, DataBuffer.TYPE_BYTE); WritableRaster raster = cm.createCompatibleWritableRaster(WIDTH, HEIGHT); return new BufferedImage(cm, raster, cm.isAlphaPremultiplied(), null); } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27785#discussion_r2487547644 From serb at openjdk.org Mon Nov 3 19:10:59 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 3 Nov 2025 19:10:59 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v9] In-Reply-To: References: <1nxKOtN4B2h026FhyQp8t-1IOZBFPMfnif7I5a0Vnuc=.9ffffa12-226f-49ac-8b85-fac3750c649f@github.com> <3hw1X_jGyDqVuyleOkeirF2hj4ZnfuBPoG9J-e4Rw50=.914a54f6-f2f8-491d-b2af-e84dfdc5967b@github.com> Message-ID: On Thu, 30 Oct 2025 19:49:49 GMT, Damon Nguyen wrote: >If the mouse movement used in Jemmy really does turn out to be preferred, we can make a future update to the mouse movement implementation since it does not seem to need any API doc changes. I don?t think it will be possible to change the implementation once these methods start being used by the tests, as the tests will depend on their behavior in one way or another. This means that once we release these methods, their implementation will essentially be set in stone. It would be better to check how this is implemented in a different API and see how difficult it would be to adjust the current implementation to follow the same behavior. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26969#issuecomment-3482081867 From duke at openjdk.org Mon Nov 3 19:14:15 2025 From: duke at openjdk.org (duke) Date: Mon, 3 Nov 2025 19:14:15 GMT Subject: RFR: 8357034: GifImageDecoder can produce wrong transparent pixels [v8] In-Reply-To: References: Message-ID: <6zVYGEw87efvxGaHMao1a2xe45w_uZQxC39LcE5u3VM=.3d43aa43-b0dd-409e-831d-08bca91f1f59@github.com> On Fri, 31 Oct 2025 21:26:45 GMT, Jeremy Wood wrote: >> If there are two consecutive frames that use DISPOSAL_SAVE, but the transparent pixel index changed: we might accidentally send the wrong data to the ImageConsumer. >> >> We already had logic that submits info "the hard way" (see comment in code); this PR just makes sure we trigger that block. >> >> There are a cluster of four related PRs that share the GifComparison class in this PR. >> >> 1. [8357034](https://github.com/openjdk/jdk/pull/25264) (this one) >> 2. ~~[8356137](https://github.com/openjdk/jdk/pull/25044)~~ (integrated) >> 3. [8356320](https://github.com/openjdk/jdk/pull/25076) >> 4. [8351913](https://github.com/openjdk/jdk/pull/24271) >> >> This bug can be observed reading these gif animations: >> >> https://giphy.com/gifs/fomoduck-duck-fomo-ZUlzR40oGACqNmy0q8 >> https://media4.giphy.com/media/Zbf4JQzcDhzeraQvk9/giphy.gif >> https://giphy.com/gifs/computer-working-cat-LHZyixOnHwDDy >> https://giphy.com/gifs/90s-fgfgif-r4BmI9xUaDuKJQdd3l >> >> ### Describing This Bug >> >> The steps/explanation that lead to this failure are a little complicated. I'll try to summarize the original bug here. >> >> All three frames in the unit test's GIF use disposal code doNotDispose, meaning the frames are layered one on top of the previous. >> >> The first frame produces 3 circles from left to right using these colors: >> 0xff0000 (red) 0xffff00 (yellow) 0x00ff00 (green) >> >> The background is 0x00ffff (cyan). It is the transparent pixel, so the first frame is: >> >> frame_0 >> >> Now we start processing the second frame. The pixels are the same, but the color model has changed so the zeroeth color (red) is the transparent index. >> >> When the GifImageDecoder layers the 2nd frame on top of the 1st frame, it notices that `model.equals(saved_model)` is `false`. This means it enter a block of code that refers to "the hard way" of passing new pixel information to the ImageConsumers. >> >> The 2nd frame, after being painted on the 1st frame, looks like: >> frame_1 >> ? >> The 3rd frame is exactly the same as the 2nd. But here's where the bug is: now `model.equals(saved_model)` is `true`, so GifImageDecoder tries to pass the pixel information the easy way. The result is: >> >> frame_2_awt > This is in response to: > https://github.com/openjdk/jdk/pull/25264/files#r2292318270 > - Merge branch 'master' into JDK-8357034 > - 8357034: re-wrapping line breaks > - 8356137, 8357034: add debug option to dump PNGs of frames > > This is in response to: > https://github.com/openjdk/jdk/pull/25044#pullrequestreview-3007487527 > - Merge branch 'master' into JDK-8357034 > > # Conflicts: > # test/jdk/sun/awt/image/gif/GifBuilder.java > # test/jdk/sun/awt/image/gif/GifComparison.java > - 8357034: avoid recalculating isSimpleSavedImageComparison for every line > > This is in response to: > https://github.com/openjdk/jdk/pull/25264#discussion_r2197097522 > - Merge branch 'master' into JDK-8357034 > - 8356320: Use new GifBuilder and remove ukraine-flag.gif > > This is an extension of work for this PR: > https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750 > - 8356137: adding copyright > - ... and 25 more: https://git.openjdk.org/jdk/compare/1781b186...ece8707a @mickleness Your change (at version ece8707a26e00ed04dc304831ae809137507f721) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25264#issuecomment-3482089617 From philip.race at oracle.com Mon Nov 3 19:22:46 2025 From: philip.race at oracle.com (Philip Race) Date: Mon, 3 Nov 2025 11:22:46 -0800 Subject: a last-minute plea to reconsider JEP 504: removing the applet API breaks non-applets In-Reply-To: References: Message-ID: <546ea570-b306-410b-bef4-c773f358572f@oracle.com> I hear you, but it was already removed over 3 months ago : https://bugs.openjdk.org/browse/JDK-8359053. Removing applet can't be without pain, and it has taken about 10 years of signalling to get here. The cost of keeping these APIs is non-zero and keeping them for ever whilst deprecating for removal is odd. As for mixed main/applet programs, I know about that usage model. I've done the same myself. Although the only reason I've done so, was so that something that was primarily an applet could be tested / debugged more easily. In other words if something was intended to be a standalone application, I would never introduce a dependency on the applet package. I'm not personally aware of any case of an applet that's still important after 25 years and yet no one has the source code. If you have source, migration should not be hard. If you don't, then staying on JDK 25 is an option which will get you well past 2030. That's some 4 more years than was originally anticipated when there were thoughts of removing it in the JDK 17 time frame. I'm sceptical that any such case of lost source would also need JDK 26 or later. -phil. On 11/2/25 8:20 PM, Mark Yagnatinsky wrote: > Thanks for replying!? I guess I'm not convinced that their "mere > existence" means that each feature needs to take them into account. > For one thing, they already don't work, and they are already deprecated. > They are also "well contained": the?bulk of the API surface lives in > just one package (java.applet). > (Compare?this to, say, the Security Manager, which really did have its > tendrils all over the place, or serialization, which still does.) > > I'm also not sure WebStart is quite analogous here. (Disclaimer: I > know roughly nothing about webstart; this may all be wrong.) > As far as I understand, all you need for web start to work is that > some program on your computer knows what to do with JNLP files. > Thus, it's perfectly practical for a third party to write such a program. > The only "tricky" part that I can think of is to ensure that the > javax.jnlp package exists even when running on newer versions of the JDK, > But since the JNLP launcher has full control of the classpath of the > JVM, it can indeed arrange for this. > > In the case of desktop apps that also happen to be applets, it's not > clear to me what to do; we no longer have a separate launcher. > Is the idea to create a jar file with the contents of the java.applet > package, and then tell people to always add it to their classpath? > > Either way, thanks for confirming the mailing list! > Mark. > > On Sun, Nov 2, 2025 at 8:55?PM David Alayachew > wrote: > > No, you are on the right mailing list. > > Let me start by saying -- I know how you feel. The way you feel > about Applets is exactly how I felt about Java WebStart > . I'm still cranky > about it's removal. > > But to jump right into the point -- Deprecation for Removal means > that the OpenJDK will no longer support this API, and thus, are > removing it from the SDK. > > But that doesn't mean that the functionality is dead, just means > that it won't be supported by the OpenJDK. My WebStart has found > new life under OpenWebStart . I > guarantee you that a similar thing will be made for Applets, as > Applets went way further than Java WebStart ever did. > > And as for the reason, please remember that the existence of a > feature means that it adds weight to the load. Java Applets could > receive no changes whatsoever for the next 10 years, and yet > */_their mere existence_/*?in the SDK contributes a large amount > to the maintenance effort. And the reason why it adds so much to > the maintenance effort is because Java must ensure that each > feature or library they introduce is cohesive with the SDK. By > keeping Applets in, that's one more thing that needs to be checked > against. And Applets are large enough that this checking is > non-trivial. > > I would encourage you (and those you come across) to look to Open > Source Software solutions to the removal of Applets. You might be > surprised how easy it is to achieve. > > On Fri, Oct 31, 2025 at 2:35?PM Mark Yagnatinsky > wrote: > > In the olden days, it was pretty common to make apps that > supported two launch modes: > 1. entry point in main() created its own window using JFrame > or whatever. > 2. But also extend Applet so as to run in the browser. > > These days, the second mode no longer?works because no browser > supports applets. > But the first mode still works fine.? It would STOP working if > the applet API were removed. > (In particular, class loading would fail if the JVM can't find > the parent class.) > > Normally, when we talk about removing APIs, there is a simple > bit of messaging that goes something like this: > 1. This is hopefully a simple code change (e.g., stop > extending Applet, since it does you no good anyway). > 2. If you're not ready to make the code change, stay on an old > version for now > 3. If you're not going to be ready soon, use an LTS release. > > There's a cluster of vague implicit assumptions buried in such > messaging, such as: > 1. The application is actively maintained, or at least there > exists a person or group of people nominally in charge of > maintaining it. > 2. The user and developer of the application are one and the > same person, or at least know each other or have some sort of > business relationship or SOMETHING. > 3. In short, it assumes that if the application doesn't run, > the developer has some reason to care. If the developer > doesn't care, it's presumably because the app has no users and > hence nobody cares. > > In the case of the applet API, this is all largely false. > There are people who once upon a time put a cute little applet > on the web, and also made it runnable standalone. > If anyone happens to find this useful to them, then all the > better, but those people are not customers, just like someone > is not your customer just because they happen to read your blog. > In other words, if these cute little former applets stop > working, the original author has no incentive to care and > might not even notice for many years. > > But even though these are all unmaintained, it does not mean > they are unused! > They may indeed have users, possibly users who find them > indispensable! > But those users may not have access to the code, and may not > be programmers even if they did have access. > To those users, removing the applet API means that these apps > no longer work on the latest JDK, and they have no one to > complain to. > > For a while, they can stay on old JDK, but eventually this > becomes harder and harder as old JDK versions may not support > new operating systems and CPUs and stuff. > (Not everyone knows how to set up a VM and an emulator and stuff.) > Also, some people may be too nervous to run an old JVM that > hasn't gotten security updates in a long time. > > Conversely, consider the cost of keeping these APIs.? They > would still be deprecated. > Nobody is filing bug reports against them, since they are > unusable anyway. > They are not "literally free" but the maintenance burden for > the OpenJDK team should be only marginally higher than the > maintenance burden of dead code. > > Thoughts? > > Thanks, > Mark. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aivanov at openjdk.org Mon Nov 3 20:47:59 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 3 Nov 2025 20:47:59 GMT Subject: RFR: 8369327: On macOS List may loses selection when added to Frame In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 01:20:41 GMT, Sergey Bylokhov wrote: > The bug happens when List.select(int) is used in multiple selection mode. It only appears when the List is added to a Frame, because in that case, the selection is handled by the platform peer, and the internal logic in the List class is skipped. > > To fix this, the code now uses [addSelectionInterval](https://github.com/openjdk/jdk/blob/910bb68e5191f830ff6f3dff5753e4e5f6214a7b/src/java.desktop/share/classes/javax/swing/ListSelectionModel.java#L93) instead of setSelectedIndex. This method works correctly for multiple selection mode when using JList as the delegate on macOS. > > I added DeselectionUnitTest and SelectionUnitTest tests for some selection and deselection cases. At first, it was one big test, but I split it because it got too large. > > **Notes on invalid index handling** > According to the java.awt.List [spec](https://github.com/openjdk/jdk/blob/0e5655e6680762a99b5aecb58369b880ea913565/src/java.desktop/share/classes/java/awt/List.java#L573), using invalid indexes is undefined behavior. For now, I have decided not to validate these cases fully in this patch, but I did add a check in the `LWListPeer.select()` to handle them more safely. > > The previously used setSelectedIndex method [ignored](https://github.com/openjdk/jdk/blob/0e5655e6680762a99b5aecb58369b880ea913565/src/java.desktop/share/classes/javax/swing/JList.java#L2229) indexes greater than the list size, unlike addSelectionInterval. So I added an explicit check to skip all indexes larger than the list size. > > Later, I discovered that passing a negative index not only causes an exception (which is acceptable, since it's undefined behavior), but also leaves the peer in an inconsistent state. This happens because setSkipStateChangedEvent(false) at the end of LWListPeer.select() is not called if an exception is thrown. > > To prevent this, I added a check to skip all negative values as well. As a result, the peer now cleanly ignores all out-of-range indexes. > > **Description of how invalid indexes are handled on other platforms:** > - The shared code in java.awt.List stores elements and selection separately, so it accepts invalid indexes. This can cause exceptions if the selection and data become out of sync. > - On Windows, all invalid indexes are ignored, except for the special value -1, which is used to select or deselect all elements. This happens because the indexes are passed to the win api without validation. > - XAWT uses the same logic as the shared code, so it can throw the same exceptions if the data... The list loses its ability to handle multiple selection after its added to a frame, do I understand the problem correctly? The test in the bug report first selects items and then adds the list to the frame. According to the tests, it's not a pre-requisite. I edited the subject of the issue and removed ?may? because the issue always happens. If the answer to my question above is ?yes?, the word ?multiple? should be added to the subject. There's a lot of code duplication between the tests, this is understandable since the tests are closely related. I suggest creating a folder for these three tests and maybe creating a super-class for `*UnitTest.java` that contains the `Test` interface and the common utility methods `assertEquals`, etc. On the other hand, splitting the test code like will make reading the tests somewhat harder? However, I still suggest adding a folder, let's say `ListSelection`, and putting these three tests into the folder. One should always run all the three tests, therefore grouping them in a folder is reasonable. src/java.desktop/macosx/classes/sun/lwawt/LWListPeer.java line 143: > 141: getDelegate().setSkipStateChangedEvent(true); > 142: getDelegate().getView().addSelectionInterval(index, index); > 143: getDelegate().setSkipStateChangedEvent(false); Does it make sense to call `setSkipStateChangedEvent(false)` in a `finally` block? It will ensure the component is left in a consistent state. test/jdk/java/awt/List/DeselectionUnitTest.java line 27: > 25: import java.awt.List; > 26: > 27: /** Suggestion: /* Let's not use javadoc syntax for jtreg tags. test/jdk/java/awt/List/DeselectionUnitTest.java line 36: > 34: > 35: public static void main(String[] args) { > 36: // non-displayable list Suggestion: // Non-displayable list I'd start with a capital letter for consistency because all other comments in the test start with a capital letter. Here, *displayable* is in the sense of `Component.isDisplayable()`, right? test/jdk/java/awt/List/DeselectionUnitTest.java line 37: > 35: public static void main(String[] args) { > 36: // non-displayable list > 37: testSingleMode(null); For consistency, Suggestion: testNonDisplayable(DeselectionUnitTest::testSingleMode);; where private static void testDisplayable(Test test) { test.execute(null); } Then the comments become redundant as the method names explicitly mention which state is tested. test/jdk/java/awt/List/DeselectionUnitTest.java line 42: > 40: testEmptyListDeselection(null); > 41: > 42: // displayable list Suggestion: // Displayable list test/jdk/java/awt/List/DeselectionUnitTest.java line 72: > 70: list.add("Item1"); > 71: list.add("Item2"); > 72: list.add("Item3"); I'd pull this piece of code into `createList` to avoid having the same code in all the test methods. test/jdk/java/awt/List/DeselectionUnitTest.java line 161: > 159: System.err.println("Expected: " + expected); > 160: System.err.println("Actual: " + actual); > 161: throw new RuntimeException("Values are not equal"); I'd still include the value into the exception message. test/jdk/java/awt/List/SelectInvalid.java line 28: > 26: import jdk.test.lib.Platform; > 27: > 28: /** Suggestion: /* ------------- PR Review: https://git.openjdk.org/jdk/pull/27682#pullrequestreview-3412685687 PR Review Comment: https://git.openjdk.org/jdk/pull/27682#discussion_r2487686109 PR Review Comment: https://git.openjdk.org/jdk/pull/27682#discussion_r2487692539 PR Review Comment: https://git.openjdk.org/jdk/pull/27682#discussion_r2487747353 PR Review Comment: https://git.openjdk.org/jdk/pull/27682#discussion_r2487756315 PR Review Comment: https://git.openjdk.org/jdk/pull/27682#discussion_r2487749710 PR Review Comment: https://git.openjdk.org/jdk/pull/27682#discussion_r2487726792 PR Review Comment: https://git.openjdk.org/jdk/pull/27682#discussion_r2487733674 PR Review Comment: https://git.openjdk.org/jdk/pull/27682#discussion_r2487758525 From markyag at gmail.com Mon Nov 3 21:00:12 2025 From: markyag at gmail.com (Mark Yagnatinsky) Date: Mon, 3 Nov 2025 16:00:12 -0500 Subject: a last-minute plea to reconsider JEP 504: removing the applet API breaks non-applets In-Reply-To: <546ea570-b306-410b-bef4-c773f358572f@oracle.com> References: <546ea570-b306-410b-bef4-c773f358572f@oracle.com> Message-ID: So there's no plan to even update the JEP text to mention this stuff then? (I admit staying on JDK 25 (or indeed JDK 8, which is when applets still "worked") is likely a viable option until somewhat past 2030.) On Mon, Nov 3, 2025 at 2:23?PM Philip Race wrote: > I hear you, but it was already removed over 3 months ago : > https://bugs.openjdk.org/browse/JDK-8359053. > > Removing applet can't be without pain, and it has taken about 10 years of > signalling to get here. > The cost of keeping these APIs is non-zero and keeping them for ever > whilst deprecating for removal is odd. > > As for mixed main/applet programs, I know about that usage model. I've > done the same myself. > Although the only reason I've done so, was so that something that was > primarily an applet could > be tested / debugged more easily. In other words if something was intended > to be a standalone > application, I would never introduce a dependency on the applet package. > > I'm not personally aware of any case of an applet that's still important > after 25 years and > yet no one has the source code. If you have source, migration should not > be hard. > If you don't, then staying on JDK 25 is an option which will get you well > past 2030. > That's some 4 more years than was originally anticipated when there were > thoughts of removing it in the JDK 17 time frame. > I'm sceptical that any such case of lost source would also need JDK 26 or > later. > > -phil. > > On 11/2/25 8:20 PM, Mark Yagnatinsky wrote: > > Thanks for replying! I guess I'm not convinced that their "mere > existence" means that each feature needs to take them into account. > For one thing, they already don't work, and they are already deprecated. > They are also "well contained": the bulk of the API surface lives in just > one package (java.applet). > (Compare this to, say, the Security Manager, which really did have its > tendrils all over the place, or serialization, which still does.) > > I'm also not sure WebStart is quite analogous here. (Disclaimer: I know > roughly nothing about webstart; this may all be wrong.) > As far as I understand, all you need for web start to work is that some > program on your computer knows what to do with JNLP files. > Thus, it's perfectly practical for a third party to write such a program. > The only "tricky" part that I can think of is to ensure that the > javax.jnlp package exists even when running on newer versions of the JDK, > But since the JNLP launcher has full control of the classpath of the JVM, > it can indeed arrange for this. > > In the case of desktop apps that also happen to be applets, it's not clear > to me what to do; we no longer have a separate launcher. > Is the idea to create a jar file with the contents of the java.applet > package, and then tell people to always add it to their classpath? > > Either way, thanks for confirming the mailing list! > Mark. > > On Sun, Nov 2, 2025 at 8:55?PM David Alayachew > wrote: > >> No, you are on the right mailing list. >> >> Let me start by saying -- I know how you feel. The way you feel about >> Applets is exactly how I felt about Java WebStart >> . I'm still cranky about >> it's removal. >> >> But to jump right into the point -- Deprecation for Removal means that >> the OpenJDK will no longer support this API, and thus, are removing it from >> the SDK. >> >> But that doesn't mean that the functionality is dead, just means that it >> won't be supported by the OpenJDK. My WebStart has found new life under >> OpenWebStart . I guarantee you that a similar >> thing will be made for Applets, as Applets went way further than Java >> WebStart ever did. >> >> And as for the reason, please remember that the existence of a feature >> means that it adds weight to the load. Java Applets could receive no >> changes whatsoever for the next 10 years, and yet *their mere existence* in >> the SDK contributes a large amount to the maintenance effort. And the >> reason why it adds so much to the maintenance effort is because Java must >> ensure that each feature or library they introduce is cohesive with the >> SDK. By keeping Applets in, that's one more thing that needs to be checked >> against. And Applets are large enough that this checking is non-trivial. >> >> I would encourage you (and those you come across) to look to Open Source >> Software solutions to the removal of Applets. You might be surprised how >> easy it is to achieve. >> >> On Fri, Oct 31, 2025 at 2:35?PM Mark Yagnatinsky >> wrote: >> >>> In the olden days, it was pretty common to make apps that supported two >>> launch modes: >>> 1. entry point in main() created its own window using JFrame or whatever. >>> 2. But also extend Applet so as to run in the browser. >>> >>> These days, the second mode no longer works because no browser supports >>> applets. >>> But the first mode still works fine. It would STOP working if the >>> applet API were removed. >>> (In particular, class loading would fail if the JVM can't find the >>> parent class.) >>> >>> Normally, when we talk about removing APIs, there is a simple bit of >>> messaging that goes something like this: >>> 1. This is hopefully a simple code change (e.g., stop extending Applet, >>> since it does you no good anyway). >>> 2. If you're not ready to make the code change, stay on an old version >>> for now >>> 3. If you're not going to be ready soon, use an LTS release. >>> >>> There's a cluster of vague implicit assumptions buried in such >>> messaging, such as: >>> 1. The application is actively maintained, or at least there exists a >>> person or group of people nominally in charge of maintaining it. >>> 2. The user and developer of the application are one and the same >>> person, or at least know each other or have some sort of business >>> relationship or SOMETHING. >>> 3. In short, it assumes that if the application doesn't run, the >>> developer has some reason to care. If the developer doesn't care, it's >>> presumably because the app has no users and hence nobody cares. >>> >>> In the case of the applet API, this is all largely false. >>> There are people who once upon a time put a cute little applet on the >>> web, and also made it runnable standalone. >>> If anyone happens to find this useful to them, then all the better, but >>> those people are not customers, just like someone is not your customer just >>> because they happen to read your blog. >>> In other words, if these cute little former applets stop working, the >>> original author has no incentive to care and might not even notice for many >>> years. >>> >>> But even though these are all unmaintained, it does not mean they are >>> unused! >>> They may indeed have users, possibly users who find them indispensable! >>> But those users may not have access to the code, and may not be >>> programmers even if they did have access. >>> To those users, removing the applet API means that these apps no longer >>> work on the latest JDK, and they have no one to complain to. >>> >>> For a while, they can stay on old JDK, but eventually this becomes >>> harder and harder as old JDK versions may not support new operating systems >>> and CPUs and stuff. >>> (Not everyone knows how to set up a VM and an emulator and stuff.) >>> Also, some people may be too nervous to run an old JVM that hasn't >>> gotten security updates in a long time. >>> >>> Conversely, consider the cost of keeping these APIs. They would still >>> be deprecated. >>> Nobody is filing bug reports against them, since they are unusable >>> anyway. >>> They are not "literally free" but the maintenance burden for the OpenJDK >>> team should be only marginally higher than the maintenance burden of dead >>> code. >>> >>> Thoughts? >>> >>> Thanks, >>> Mark. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serb at openjdk.org Mon Nov 3 21:22:42 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 3 Nov 2025 21:22:42 GMT Subject: RFR: 8370719: [Linux] Use /etc/os-release values for font configuration file names In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 19:07:04 GMT, Phil Race wrote: > The JBS issue has a long discussion and explanation but here's a short version. > Instead of having baked in names of distros in the code that figures out names for font configuration files for Linux > use the standard ID and VERSION_ID fields in /etc/os-release which is now standard. > even systemd doesn't work if it does not exist https://0pointer.de/blog/projects/os-release > And if it doesn't we just use "Linux" as the name. src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java line 320: > 318: } > 319: try { > 320: File f = new File("/etc/os-release"); Don't we need to check "/usr/lib/os-release" as well? https://www.freedesktop.org/software/systemd/man/latest/os-release.html >The file /etc/os-release takes precedence over /usr/lib/os-release. Applications should check for the former, and exclusively use its data if it exists, and only fall back to /usr/lib/os-release if that is missing. Applications should not combine the data from both files. /usr/lib/os-release is the recommended place to store OS release information as part of vendor trees. /etc/os-release should be a relative symlink to /usr/lib/os-release, to provide compatibility with applications only looking at /etc/. A relative symlink instead of an absolute symlink is necessary to avoid breaking the link in a chroot or initrd environment. src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java line 321: > 319: try { > 320: File f = new File("/etc/os-release"); > 321: if (f.canRead()) { Should we check whether this is a file and not a directory? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28073#discussion_r2487878342 PR Review Comment: https://git.openjdk.org/jdk/pull/28073#discussion_r2487871539 From serb at openjdk.org Mon Nov 3 21:41:44 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 3 Nov 2025 21:41:44 GMT Subject: RFR: 8357252: sun/awt/font/TestArabicHebrew.java fails in OEL 9 and 10 x64 In-Reply-To: <2DGbd1T9g477NOXI2G6bIcP7dYyM1-ur745qYQA69_o=.e5c976f6-b72d-4688-b8cc-3e9f68db192b@github.com> References: <2DGbd1T9g477NOXI2G6bIcP7dYyM1-ur745qYQA69_o=.e5c976f6-b72d-4688-b8cc-3e9f68db192b@github.com> Message-ID: On Thu, 30 Oct 2025 18:52:53 GMT, Phil Race wrote: > A long time ago (JDK 7) when the linux font properties were largely replaced by using fontconfig logic was included to try to limit the number of slots used for composite fonts by requiring that fonts add sufficient code points. > In practice today this limitation seems to be reductions like having 40 slots instead of 50. > Except for keeping it for debugging, this fix removes that limitation which had a bad consequence on some recent Linuxes where the primary Hebrew font (Noto Sans Hebrew) came after another font (DejaVu Sans) that provided some Hebrew accents and punctuation but not the alphabet and was also far enough down the list (14th) to be where we require 50 new code points to be worthy of inclusion and it only added 33. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28072#pullrequestreview-3413026437 From honkar at openjdk.org Mon Nov 3 21:56:44 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 3 Nov 2025 21:56:44 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v3] In-Reply-To: References: Message-ID: <8uTT1OhvToiXCQKK9gV6ug-_NnXufFjOOkBhrtRhg80=.6d333ab1-c47b-480f-8273-befe3af559fe@github.com> > `findComponent(final Container container, final Predicate predicate)` is a useful utility method and thus added to` javax/swing/regtesthelpers/Util.java` instead of having redundant code in tests. It can be used to find a component by label name. > > PS: Existing `Util.findSubComponent()` finds component by class name but `findComponent()` can be used to search for a particular component by label name/title when there are multiple subcomponents of same type by applying a predicate logic. Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: Review changes: EDT check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27944/files - new: https://git.openjdk.org/jdk/pull/27944/files/6bc90058..cec6a0ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27944&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27944&range=01-02 Stats: 24 lines in 3 files changed: 18 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27944.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27944/head:pull/27944 PR: https://git.openjdk.org/jdk/pull/27944 From honkar at openjdk.org Mon Nov 3 21:56:46 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 3 Nov 2025 21:56:46 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v2] In-Reply-To: References: Message-ID: On Thu, 23 Oct 2025 21:02:07 GMT, Harshitha Onkar wrote: >> `findComponent(final Container container, final Predicate predicate)` is a useful utility method and thus added to` javax/swing/regtesthelpers/Util.java` instead of having redundant code in tests. It can be used to find a component by label name. >> >> PS: Existing `Util.findSubComponent()` finds component by class name but `findComponent()` can be used to search for a particular component by label name/title when there are multiple subcomponents of same type by applying a predicate logic. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > review update @aivanov-jdk Updated. Please re-review. ------------- PR Review: https://git.openjdk.org/jdk/pull/27944#pullrequestreview-3413050456 From honkar at openjdk.org Mon Nov 3 21:56:49 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 3 Nov 2025 21:56:49 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v3] In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 11:27:03 GMT, Alexey Ivanov wrote: >> There are some tests where EDT calls are interleaved between calls to robot (non-EDT) (e.g bug4759934.java - findCancelButton()) and few other tests (e.g FileSizeCheck.java - findDetailsButton() and findTable() that are within upper level method which is called on EDT). Is it better to leave it as-is for flexibility rather than add a wrapper? >> >> If a wrapper is added we might need to check if it is already on EDT thread or not as below: >> >> >> if (isEventDispatchThread()) { >> return _findComponent(container, predicate); >> } else { >> return Util.invokeOnEDT(() -> _findComponent(container, predicate)); >> } > >> If a wrapper is added we might need to check if it is already on EDT thread or not as below: > > This is what I said: *?the implementation will run directly or on EDT.?* So if it's already on EDT, call directly; it it's not, use `invokeOnEDT`. > > The utility method can then be used in all the contexts without thinking. (The implementation, if you choose this way, should rather be `findComponentImpl` rather than prefixed with an underscore.) > > Likely, one still needs to call `findComponent` on EDT because any other operations on the component need to be on EDT. In this case, `findComponent` could throw an exception if it's called not on EDT. > > These things will ensure the method can work correctly. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2487957140 From honkar at openjdk.org Mon Nov 3 21:56:47 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 3 Nov 2025 21:56:47 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v3] In-Reply-To: References: Message-ID: On Thu, 23 Oct 2025 13:58:20 GMT, Alexey Ivanov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> Review changes: EDT check > > test/jdk/javax/swing/regtesthelpers/Util.java line 1: > >> 1: /* > >> Existing `Util.findSubComponent()` finds component by class name > > To eliminate code duplication, the existing `findSubComponent` should use the new `findComponent` which is more flexible. Just pass `parent.getClass().getName().contains(className)` as the predicate to the new method. Tested by in turn calling findComponent() from findSubComponent() it does not work as expected since the recursive logic to find the component differs for both methods. Replacing findSubComponent() as below with the latest changes does not work. To verify run javax/swing/JColorChooser/Test7194184.java by replacing the findSubComponent() as below. public static Component findSubComponent(Component parent, String className) { String parentClassName = parent.getClass().getName(); if (parentClassName.contains(className)) { return parent; } return findComponent((Container) parent, c -> parent.getClass().getName().contains(className)); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2487943726 From prr at openjdk.org Mon Nov 3 22:02:48 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 3 Nov 2025 22:02:48 GMT Subject: RFR: 8370719: [Linux] Use /etc/os-release values for font configuration file names In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 21:16:42 GMT, Sergey Bylokhov wrote: >> The JBS issue has a long discussion and explanation but here's a short version. >> Instead of having baked in names of distros in the code that figures out names for font configuration files for Linux >> use the standard ID and VERSION_ID fields in /etc/os-release which is now standard. >> even systemd doesn't work if it does not exist https://0pointer.de/blog/projects/os-release >> And if it doesn't we just use "Linux" as the name. > > src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java line 320: > >> 318: } >> 319: try { >> 320: File f = new File("/etc/os-release"); > > Don't we need to check "/usr/lib/os-release" as well? > https://www.freedesktop.org/software/systemd/man/latest/os-release.html >>The file /etc/os-release takes precedence over /usr/lib/os-release. Applications should check for the former, and exclusively use its data if it exists, and only fall back to /usr/lib/os-release if that is missing. Applications should not combine the data from both files. /usr/lib/os-release is the recommended place to store OS release information as part of vendor trees. /etc/os-release should be a relative symlink to /usr/lib/os-release, to provide compatibility with applications only looking at /etc/. A relative symlink instead of an absolute symlink is necessary to avoid breaking the link in a chroot or initrd environment. I'd considered that. Taking the wording above, which encourages apps to check /etc first, and that every system I've checked has an /etc/os-release, and that it isn't a big deal even if we fail to find it unless you are creating a custom fontconfig file, I saw no need. > src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java line 321: > >> 319: try { >> 320: File f = new File("/etc/os-release"); >> 321: if (f.canRead()) { > > Should we check whether this is a file and not a directory? That would be a weird problem which likely would mean the system can't even boot. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28073#discussion_r2487966755 PR Review Comment: https://git.openjdk.org/jdk/pull/28073#discussion_r2487967931 From serb at openjdk.org Mon Nov 3 22:23:48 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 3 Nov 2025 22:23:48 GMT Subject: RFR: 8370719: [Linux] Use /etc/os-release values for font configuration file names In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 21:58:56 GMT, Phil Race wrote: >> src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java line 320: >> >>> 318: } >>> 319: try { >>> 320: File f = new File("/etc/os-release"); >> >> Don't we need to check "/usr/lib/os-release" as well? >> https://www.freedesktop.org/software/systemd/man/latest/os-release.html >>>The file /etc/os-release takes precedence over /usr/lib/os-release. Applications should check for the former, and exclusively use its data if it exists, and only fall back to /usr/lib/os-release if that is missing. Applications should not combine the data from both files. /usr/lib/os-release is the recommended place to store OS release information as part of vendor trees. /etc/os-release should be a relative symlink to /usr/lib/os-release, to provide compatibility with applications only looking at /etc/. A relative symlink instead of an absolute symlink is necessary to avoid breaking the link in a chroot or initrd environment. > > I'd considered that. Taking the wording above, which encourages apps to check /etc first, and that every system I've checked has an /etc/os-release, and that it isn't a big deal even if we fail to find it unless you are creating a custom fontconfig file, I saw no need. But still, according to that document, the correct location for storing the file is /usr/lib/os-release, while /etc/xx is only a compatibility workaround. Since we?ve already moved from an unspecified or non-standard behavior to the standard one, why not follow the specification completely? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28073#discussion_r2488027729 From kizune at openjdk.org Mon Nov 3 22:34:46 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 3 Nov 2025 22:34:46 GMT Subject: RFR: 8370719: [Linux] Use /etc/os-release values for font configuration file names In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 22:21:19 GMT, Sergey Bylokhov wrote: > But still, according to that document, the correct location for storing the file is /usr/lib/os-release, while /etc/xx is only a compatibility workaround. Since we?ve already moved from an unspecified or non-standard behavior to the standard one, why not follow the specification completely? No, according to the [/etc/os-release man page](https://www.freedesktop.org/software/systemd/man/latest/os-release.html): _"The file /etc/os-release takes precedence over /usr/lib/os-release. Applications should check for the former, and exclusively use its data if it exists, and only fall back to /usr/lib/os-release if that is missing."_ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28073#discussion_r2488048799 From serb at openjdk.org Mon Nov 3 22:38:19 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 3 Nov 2025 22:38:19 GMT Subject: RFR: 8370719: [Linux] Use /etc/os-release values for font configuration file names In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 22:32:12 GMT, Alexander Zuev wrote: > No, according to the [/etc/os-release man page](https://www.freedesktop.org/software/systemd/man/latest/os-release.html): This is what I already posted above, same text on your link: > /usr/lib/os-release is the recommended place to store OS release information as part of vendor trees. /etc/os-release should be a relative symlink to /usr/lib/os-release, to provide compatibility with applications only looking at /etc/. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28073#discussion_r2488054855 From kizune at openjdk.org Mon Nov 3 22:42:01 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 3 Nov 2025 22:42:01 GMT Subject: RFR: 8370719: [Linux] Use /etc/os-release values for font configuration file names In-Reply-To: References: Message-ID: <5Bos0KnD6Ila_yoVNsOHyCROhYlt8l5IKfsWeWvbhJo=.c3c57420-ddbc-4594-ae9b-36045cc32462@github.com> On Mon, 3 Nov 2025 22:35:36 GMT, Sergey Bylokhov wrote: >>> But still, according to that document, the correct location for storing the file is /usr/lib/os-release, while /etc/xx is only a compatibility workaround. Since we?ve already moved from an unspecified or non-standard behavior to the standard one, why not follow the specification completely? >> >> No, according to the [/etc/os-release man page](https://www.freedesktop.org/software/systemd/man/latest/os-release.html): >> >> _"The file /etc/os-release takes precedence over /usr/lib/os-release. Applications should check for the former, and exclusively use its data if it exists, and only fall back to /usr/lib/os-release if that is missing."_ > >> No, according to the [/etc/os-release man page](https://www.freedesktop.org/software/systemd/man/latest/os-release.html): > > This is what I already posted above, same text on your link: > >> /usr/lib/os-release is the recommended place to store OS release information as part of vendor trees. /etc/os-release should be a relative symlink to /usr/lib/os-release, to provide compatibility with applications only looking at /etc/. That is a recommendation for Linux vendors on how to organize systemd related data - but we are not Linux vendors. We are on the side of application so we should check /etc as the documentation dictates. Because vendors can disobey the vendor side recommendation and put it... somewhere, like in /proc/systemd to be generated instead of static file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28073#discussion_r2488063772 From serb at openjdk.org Mon Nov 3 23:00:36 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 3 Nov 2025 23:00:36 GMT Subject: RFR: 8370719: [Linux] Use /etc/os-release values for font configuration file names In-Reply-To: <5Bos0KnD6Ila_yoVNsOHyCROhYlt8l5IKfsWeWvbhJo=.c3c57420-ddbc-4594-ae9b-36045cc32462@github.com> References: <5Bos0KnD6Ila_yoVNsOHyCROhYlt8l5IKfsWeWvbhJo=.c3c57420-ddbc-4594-ae9b-36045cc32462@github.com> Message-ID: On Mon, 3 Nov 2025 22:39:16 GMT, Alexander Zuev wrote: > Because vendors can disobey the vendor side recommendation and put it... somewhere, like in /proc/systemd to be generated instead of static file That is not. According to the specification, only two files are defined: >The /etc/os-release and /usr/lib/os-release files contain operating system identification data. One of them is the primary file, while the other "optional" and exists only for compatibility. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28073#discussion_r2488096114 From serb at openjdk.org Mon Nov 3 23:10:10 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 3 Nov 2025 23:10:10 GMT Subject: RFR: 8369327: On macOS List may loses selection when added to Frame [v2] In-Reply-To: References: Message-ID: <9t2i7R9UpT7sLYSW6UEArOX9NA6R0QqQ-ufmiOk8bqY=.4c9d5576-826c-4210-83a8-6a42cd177514@github.com> > The bug happens when List.select(int) is used in multiple selection mode. It only appears when the List is added to a Frame, because in that case, the selection is handled by the platform peer, and the internal logic in the List class is skipped. > > To fix this, the code now uses [addSelectionInterval](https://github.com/openjdk/jdk/blob/910bb68e5191f830ff6f3dff5753e4e5f6214a7b/src/java.desktop/share/classes/javax/swing/ListSelectionModel.java#L93) instead of setSelectedIndex. This method works correctly for multiple selection mode when using JList as the delegate on macOS. > > I added DeselectionUnitTest and SelectionUnitTest tests for some selection and deselection cases. At first, it was one big test, but I split it because it got too large. > > **Notes on invalid index handling** > According to the java.awt.List [spec](https://github.com/openjdk/jdk/blob/0e5655e6680762a99b5aecb58369b880ea913565/src/java.desktop/share/classes/java/awt/List.java#L573), using invalid indexes is undefined behavior. For now, I have decided not to validate these cases fully in this patch, but I did add a check in the `LWListPeer.select()` to handle them more safely. > > The previously used setSelectedIndex method [ignored](https://github.com/openjdk/jdk/blob/0e5655e6680762a99b5aecb58369b880ea913565/src/java.desktop/share/classes/javax/swing/JList.java#L2229) indexes greater than the list size, unlike addSelectionInterval. So I added an explicit check to skip all indexes larger than the list size. > > Later, I discovered that passing a negative index not only causes an exception (which is acceptable, since it's undefined behavior), but also leaves the peer in an inconsistent state. This happens because setSkipStateChangedEvent(false) at the end of LWListPeer.select() is not called if an exception is thrown. > > To prevent this, I added a check to skip all negative values as well. As a result, the peer now cleanly ignores all out-of-range indexes. > > **Description of how invalid indexes are handled on other platforms:** > - The shared code in java.awt.List stores elements and selection separately, so it accepts invalid indexes. This can cause exceptions if the selection and data become out of sync. > - On Windows, all invalid indexes are ignored, except for the special value -1, which is used to select or deselect all elements. This happens because the indexes are passed to the win api without validation. > - XAWT uses the same logic as the shared code, so it can throw the same exceptions if the data... Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8369327 - Update ProblemList.txt - Update SelectInvalid.java - Validate "index >= 0 && index < model.getSize()" - Create SelectInvalid.java - 8369327: On macOS List may loses selection when added to Frame ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27682/files - new: https://git.openjdk.org/jdk/pull/27682/files/3e3543ef..e639b90e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27682&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27682&range=00-01 Stats: 101136 lines in 1595 files changed: 57105 ins; 34314 del; 9717 mod Patch: https://git.openjdk.org/jdk/pull/27682.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27682/head:pull/27682 PR: https://git.openjdk.org/jdk/pull/27682 From kizune at openjdk.org Mon Nov 3 23:27:03 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 3 Nov 2025 23:27:03 GMT Subject: RFR: 8370719: [Linux] Use /etc/os-release values for font configuration file names In-Reply-To: References: <5Bos0KnD6Ila_yoVNsOHyCROhYlt8l5IKfsWeWvbhJo=.c3c57420-ddbc-4594-ae9b-36045cc32462@github.com> Message-ID: On Mon, 3 Nov 2025 22:57:43 GMT, Sergey Bylokhov wrote: >> That is a recommendation for Linux vendors on how to organize systemd related data - but we are not Linux vendors. We are on the side of application so we should check /etc as the documentation dictates. Because vendors can disobey the vendor side recommendation and put it... somewhere, like in /proc/systemd to be generated instead of static file. > >> Because vendors can disobey the vendor side recommendation and put it... somewhere, like in /proc/systemd to be generated instead of static file > > That is not. According to the specification, only two files are defined: >>The /etc/os-release and /usr/lib/os-release files contain operating system identification data. > > One of them is the primary file, while the other "optional" and exists only for compatibility. And for the application - and we are an application - the same documentation says to look at the primary file location - in /etc. And only fall back to the second location if that file does not exist. If the file in /etc exists and differs from the /usr/lib/ file the later should not be used. Which implies that system vendor **can** replace the /etc/os-release file with another one or with link to the place other than /usr/lib/os-release. The /usr/lib/os-release is a fallback location. But we already have a fallback mechanics - we will have generic values set (osName is "Linux" and osVersion id null). Lust look at the usage examples at the bottom of the man page - all examples are using /usr/lib/os-release if /etc/os-release does not exist. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28073#discussion_r2488141977 From serb at openjdk.org Tue Nov 4 00:25:02 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 4 Nov 2025 00:25:02 GMT Subject: RFR: 8370719: [Linux] Use /etc/os-release values for font configuration file names In-Reply-To: References: <5Bos0KnD6Ila_yoVNsOHyCROhYlt8l5IKfsWeWvbhJo=.c3c57420-ddbc-4594-ae9b-36045cc32462@github.com> Message-ID: On Mon, 3 Nov 2025 23:24:27 GMT, Alexander Zuev wrote: > all examples are using /usr/lib/os-release if /etc/os-release does not exist. This is what I pointed out, we should follow the spec and check the "/usr/lib/" if the file in /etc/ does not exist, since the spec allows it to be missing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28073#discussion_r2488243419 From serb at openjdk.org Tue Nov 4 00:38:10 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 4 Nov 2025 00:38:10 GMT Subject: RFR: 6185110: Undefined behaviour of SampleModel for width, height < 0 In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 21:15:31 GMT, Phil Race wrote: > I've just tried what you said you did and I don't see any link generated unless you mean the list of "Methods declared class "superclassname" Yes, that one. I?m pretty sure that in another bug, when we added a method that overrides the parent method without a specification, you convinced everyone that it was fine and no CSR was needed since the spec is identical to the parent class, and the block "Methods declared class "superclassname" is fine. To achieve that, we simply skipped the spec for the subclass, example: https://bugs.openjdk.org/browse/JDK-8258373 https://github.com/openjdk/jdk/commit/7afb01dc I assumed that the subclass only need the spec if there are some difference. >The problem with that, as I wrote somewhere, perhaps not here, is that it looks to the reader of the source as if there is no javadoc for this method. Right, but is it a big issue? The method will have the `@Override` annotation to highlight that it overrides the parent method, and it might be better than duplicating all those exceptions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27754#issuecomment-3483207441 From serb at openjdk.org Tue Nov 4 00:49:05 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 4 Nov 2025 00:49:05 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v5] In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 10:05:12 GMT, Prasanta Sadhukhan wrote: >> If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder` >> it throws NPE which is not mentioned in the spec as the expected outcome. >> Fixed the NPE and the spec > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > javadoc src/java.desktop/share/classes/javax/swing/border/BevelBorder.java line 107: > 105: public BevelBorder(int bevelType, Color highlight, Color shadow) { > 106: this(bevelType, (highlight != null) ? highlight.brighter() : null, > 107: highlight, shadow, (shadow != null) ? shadow.brighter() : null); The case where the code skips all these parameters and uses the component colors is not documented in this constructor and in the factory methods? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2488277395 From honkar at openjdk.org Tue Nov 4 01:04:01 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 4 Nov 2025 01:04:01 GMT Subject: RFR: 8364583: ColorConvertOp fails for CMYK =?UTF-8?B?4oaS?= RGB conversion In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 05:25:44 GMT, Phil Race wrote: > color is initially returned as 4 element array but we over-write with 3 element and so next time through the loop it is used by but is too short. > More details in JBS. In the process of reviewing the PR ------------- PR Comment: https://git.openjdk.org/jdk/pull/27785#issuecomment-3483259803 From serb at openjdk.org Tue Nov 4 01:10:05 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 4 Nov 2025 01:10:05 GMT Subject: RFR: 8370438: Offer link time optimization support on library level In-Reply-To: <809Ep8sEq1en07SmuThJa34v0-oYAdPr6Jhwg4DZTGM=.08fe720e-dc5e-4903-9c3c-e3f5770859e3@github.com> References: <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com> <809Ep8sEq1en07SmuThJa34v0-oYAdPr6Jhwg4DZTGM=.08fe720e-dc5e-4903-9c3c-e3f5770859e3@github.com> Message-ID: On Thu, 30 Oct 2025 15:48:41 GMT, Matthias Baesken wrote: > When introducing new compiler flags, you need to do one of: Just an idea to think about: would it be possible to share the same variable between the JDK and HotSpot to store these parameters? Even in this discussion, it would highlight that these parameters are not new. Or is it not worth the effort? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3483270323 From serb at openjdk.org Tue Nov 4 01:15:07 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 4 Nov 2025 01:15:07 GMT Subject: RFR: 8369129: Raster createPackedRaster methods specification clean up [v4] In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 21:07:41 GMT, Phil Race wrote: >I'll proceed accordingly unless you spot an issue. Also I'll need to run all our tests which I've not done yet. all tests are green? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27627#discussion_r2488320256 From serb at openjdk.org Tue Nov 4 01:30:04 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 4 Nov 2025 01:30:04 GMT Subject: RFR: 4617681: constructor of BufferedImage throws unexpected IllegalArgumentException In-Reply-To: References: <3_us2zAmdVS-gGC-7urjNFd3nOxDsl5n-3aAxli9kn0=.f6460486-5438-41f4-bafe-6d96254f30a8@github.com> <2ixIN5XwoxTtCHsXs5w6o2cxjjsCRoaFuVmBfbq0bkg=.81ad927c-0cc4-4810-af04-85114d960ba5@github.com> Message-ID: On Wed, 29 Oct 2025 13:27:49 GMT, Jayathirth D V wrote: >I see that none of the code path under this API uses BandedSampleModel. This discussion is about the possibility of changing that in the future. The current change prevents us from implementing those for large images(even by simply reusing BandedSampleModel instead of new class), since it includes strict limits and the TCK will enforce them. So, if we decide to change it later, we?ll also need to update the specification, which means the change can?t be backported. >But that seems nearly impossible. There's too many things in the spec. and implementation that would need revisision. What things? I don?t think we have any limits, except that we still need to implement it. Right now, we don?t define that behavior clearly. So, later, the user will get the correct large image when they ask for it, instead of getting an error. But the current patch is one of the thing which will prevent that, no? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2488342302 From psadhukhan at openjdk.org Tue Nov 4 03:13:01 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 4 Nov 2025 03:13:01 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v6] In-Reply-To: References: Message-ID: > If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder` > it throws NPE which is not mentioned in the spec as the expected outcome. > Fixed the NPE and the spec Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: - javadoc update - javadoc update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27949/files - new: https://git.openjdk.org/jdk/pull/27949/files/d8de38b3..27ed5b21 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27949&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27949&range=04-05 Stats: 16 lines in 2 files changed: 16 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27949.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27949/head:pull/27949 PR: https://git.openjdk.org/jdk/pull/27949 From psadhukhan at openjdk.org Tue Nov 4 03:13:04 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 4 Nov 2025 03:13:04 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v5] In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 00:45:20 GMT, Sergey Bylokhov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> javadoc > > src/java.desktop/share/classes/javax/swing/border/BevelBorder.java line 107: > >> 105: public BevelBorder(int bevelType, Color highlight, Color shadow) { >> 106: this(bevelType, (highlight != null) ? highlight.brighter() : null, >> 107: highlight, shadow, (shadow != null) ? shadow.brighter() : null); > > The case where the code skips all these parameters and uses the component colors is not documented in this constructor and in the factory methods? Updated javadoc ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2488494373 From psadhukhan at openjdk.org Tue Nov 4 03:17:07 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 4 Nov 2025 03:17:07 GMT Subject: RFR: 8370637: [Windows] Crash if use Graphics after PrintJob.end [v3] In-Reply-To: <_mphYSlTVI7kIHuamuZrx0nDVPi5mJVw0nNuustY3vs=.ec499d51-cd18-49c4-853b-988a6a1e624a@github.com> References: <_mphYSlTVI7kIHuamuZrx0nDVPi5mJVw0nNuustY3vs=.ec499d51-cd18-49c4-853b-988a6a1e624a@github.com> Message-ID: On Mon, 3 Nov 2025 17:25:58 GMT, Phil Race wrote: >> Synchronize WPrinterJob calls which use the printDC to avoid crash in case of mis-use. >> The printerDC is released when the job ends. >> It is zero-ed out in the handle in which it is stored >> The calls which expect it to be valid now all check for zero and return if it is zero. >> The calls are made synchronized as is the call to endDoc which zeroes it, so that they cannot have it zeroed out whilst using it. >> >> The tests are the same as in the fix for JDK-8370141 which is also under review. >> Which ever is 2nd to be pushed will have to merge in the changes from the first > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8370637 Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27984#pullrequestreview-3413823324 From psadhukhan at openjdk.org Tue Nov 4 03:22:00 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 4 Nov 2025 03:22:00 GMT Subject: RFR: 8357252: sun/awt/font/TestArabicHebrew.java fails in OEL 9 and 10 x64 In-Reply-To: <2DGbd1T9g477NOXI2G6bIcP7dYyM1-ur745qYQA69_o=.e5c976f6-b72d-4688-b8cc-3e9f68db192b@github.com> References: <2DGbd1T9g477NOXI2G6bIcP7dYyM1-ur745qYQA69_o=.e5c976f6-b72d-4688-b8cc-3e9f68db192b@github.com> Message-ID: <7Tw4XOpifKJVG48jyZFIXTNg-xgxZsPr3xx8IjpmKOE=.77f8cf0d-42ec-4cb0-9d06-4ef710940c09@github.com> On Thu, 30 Oct 2025 18:52:53 GMT, Phil Race wrote: > A long time ago (JDK 7) when the linux font properties were largely replaced by using fontconfig logic was included to try to limit the number of slots used for composite fonts by requiring that fonts add sufficient code points. > In practice today this limitation seems to be reductions like having 40 slots instead of 50. > Except for keeping it for debugging, this fix removes that limitation which had a bad consequence on some recent Linuxes where the primary Hebrew font (Noto Sans Hebrew) came after another font (DejaVu Sans) that provided some Hebrew accents and punctuation but not the alphabet and was also far enough down the list (14th) to be where we require 50 new code points to be worthy of inclusion and it only added 33. Could update the copyright year..Will reapprove if changed.. ------------- Marked as reviewed by psadhukhan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28072#pullrequestreview-3413828686 From tr at openjdk.org Tue Nov 4 04:31:05 2025 From: tr at openjdk.org (Tejesh R) Date: Tue, 4 Nov 2025 04:31:05 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: On Fri, 31 Oct 2025 16:27:23 GMT, Damon Nguyen wrote: > Double-checked this myself and it passes. Does `FrameLocation` need to be added to the PL then? No, that is also not failing. I will find out the fix that resolved this issue and then integrate the PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27678#issuecomment-3483703915 From tr at openjdk.org Tue Nov 4 07:08:51 2025 From: tr at openjdk.org (Tejesh R) Date: Tue, 4 Nov 2025 07:08:51 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v3] In-Reply-To: <8uTT1OhvToiXCQKK9gV6ug-_NnXufFjOOkBhrtRhg80=.6d333ab1-c47b-480f-8273-befe3af559fe@github.com> References: <8uTT1OhvToiXCQKK9gV6ug-_NnXufFjOOkBhrtRhg80=.6d333ab1-c47b-480f-8273-befe3af559fe@github.com> Message-ID: <6ymiIfr6yBXzVnHxqk8sDsV1KyAJWHjQhZcpNkh02vs=.1cb647a3-c610-436d-8045-8292902021aa@github.com> On Mon, 3 Nov 2025 21:56:44 GMT, Harshitha Onkar wrote: >> `findComponent(final Container container, final Predicate predicate)` is a useful utility method and thus added to` javax/swing/regtesthelpers/Util.java` instead of having redundant code in tests. It can be used to find a component by label name. >> >> PS: Existing `Util.findSubComponent()` finds component by class name but `findComponent()` can be used to search for a particular component by label name/title when there are multiple subcomponents of same type by applying a predicate logic. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > Review changes: EDT check Any reason for updating the test files with this PR ? I feel this PR should be restricted to Util file updates alone, updating the test files can be taken up separately. ------------- PR Review: https://git.openjdk.org/jdk/pull/27944#pullrequestreview-3414321097 From psadhukhan at openjdk.org Tue Nov 4 07:11:21 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 4 Nov 2025 07:11:21 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v7] In-Reply-To: References: Message-ID: > If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder` > it throws NPE which is not mentioned in the spec as the expected outcome. > Fixed the NPE and the spec Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: javadoc update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27949/files - new: https://git.openjdk.org/jdk/pull/27949/files/27ed5b21..f68195a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27949&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27949&range=05-06 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27949.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27949/head:pull/27949 PR: https://git.openjdk.org/jdk/pull/27949 From tr at openjdk.org Tue Nov 4 07:11:42 2025 From: tr at openjdk.org (Tejesh R) Date: Tue, 4 Nov 2025 07:11:42 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v6] In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 03:13:01 GMT, Prasanta Sadhukhan wrote: >> If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder` >> it throws NPE which is not mentioned in the spec as the expected outcome. >> Fixed the NPE and the spec > > Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: > > - javadoc update > - javadoc update src/java.desktop/share/classes/javax/swing/BorderFactory.java line 151: > 149: * If shadow color is {@code null}, the shadow color > 150: * is derived from the specified component's background color. > 151: * If bevelType is not of known type that is neither Suggestion: * If bevel type is not of known type that is neither src/java.desktop/share/classes/javax/swing/border/BevelBorder.java line 80: > 78: * colors will be derived from the background color of the > 79: * component passed into the paintBorder method. > 80: * If bevelType is not of known type that is neither Suggestion: * If bevel type is not of known type that is neither src/java.desktop/share/classes/javax/swing/border/BevelBorder.java line 101: > 99: * If shadow color is {@code null}, the shadow color > 100: * is derived from the specified component's background color. > 101: * If bevelType is not of known type that is neither Suggestion: * If bevel type is not of known type that is neither src/java.desktop/share/classes/javax/swing/border/BevelBorder.java line 121: > 119: * If any of the shadow color is {@code null}, the shadow color > 120: * is derived from the specified component's background color. > 121: * If bevelType is not of known type that is neither Suggestion: * If bevel type is not of known type that is neither ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2488905474 PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2488903938 PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2488906543 PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2488907065 From tr at openjdk.org Tue Nov 4 07:11:48 2025 From: tr at openjdk.org (Tejesh R) Date: Tue, 4 Nov 2025 07:11:48 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v6] In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 06:47:15 GMT, Tejesh R wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: >> >> - javadoc update >> - javadoc update > > src/java.desktop/share/classes/javax/swing/border/BevelBorder.java line 80: > >> 78: * colors will be derived from the background color of the >> 79: * component passed into the paintBorder method. >> 80: * If bevelType is not of known type that is neither > > Suggestion: > > * If bevel type is not of known type that is neither Also please update copyright here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2488908738 From psadhukhan at openjdk.org Tue Nov 4 07:11:53 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 4 Nov 2025 07:11:53 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v6] In-Reply-To: References: Message-ID: <7lx-7j_aFmZ2Qh3CcC7J2AEXwV5FTvtzg22-fizst80=.bf4ff844-ace0-4157-8c83-f75843ad8ef8@github.com> On Tue, 4 Nov 2025 06:49:00 GMT, Tejesh R wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: >> >> - javadoc update >> - javadoc update > > src/java.desktop/share/classes/javax/swing/border/BevelBorder.java line 121: > >> 119: * If any of the shadow color is {@code null}, the shadow color >> 120: * is derived from the specified component's background color. >> 121: * If bevelType is not of known type that is neither > > Suggestion: > > * If bevel type is not of known type that is neither Updated with code tag ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2488932678 From tr at openjdk.org Tue Nov 4 07:38:33 2025 From: tr at openjdk.org (Tejesh R) Date: Tue, 4 Nov 2025 07:38:33 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v7] In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 07:11:21 GMT, Prasanta Sadhukhan wrote: >> If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder` >> it throws NPE which is not mentioned in the spec as the expected outcome. >> Fixed the NPE and the spec > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > javadoc update LGTM ------------- Marked as reviewed by tr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27949#pullrequestreview-3414378090 From psadhukhan at openjdk.org Tue Nov 4 09:21:03 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 4 Nov 2025 09:21:03 GMT Subject: RFR: 4954405: Data buffers created with an offset are unusable [v2] In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 21:01:35 GMT, Phil Race wrote: >> ByteInterleavedRaster is not including the DataBuffer offset in returns from getDataElements >> The super-class sets it in the constructor which runs very much like this subclass except it omits this. >> The parent class of ByteInterleavedRaster is ByteComponentRaster and it uses the DataBuffer offset >> to adjust dataOffsets values used in all calculations. >> >> Instead ByteInterleavedRaster does something a bit different than other classes where it includes it in some instance vars >> that also have additional offsets that apply for getPixels and getSamples but aren't used in getDataElements. >> >> It looks to me as if this is what ByteInterleavedRaster should also do instead. >> All existing tests pass, and this resolves the specific complaint in the bug report. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 4954405 Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27782#pullrequestreview-3415009600 From mbaesken at openjdk.org Tue Nov 4 09:23:04 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 4 Nov 2025 09:23:04 GMT Subject: RFR: 8370438: Offer link time optimization support on library level In-Reply-To: References: <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com> <809Ep8sEq1en07SmuThJa34v0-oYAdPr6Jhwg4DZTGM=.08fe720e-dc5e-4903-9c3c-e3f5770859e3@github.com> Message-ID: On Tue, 4 Nov 2025 01:07:28 GMT, Sergey Bylokhov wrote: > > When introducing new compiler flags, you need to do one of: > > Just an idea to think about: would it be possible to share the same variable between the JDK and HotSpot to store these parameters? Even in this discussion, it would highlight that these parameters are not new. Or is it not worth the effort? For the HS build, we set them directly in the makefile and not in the configure m4 files, see https://github.com/openjdk/jdk/blob/e4aed95cac343f1339b9bc87721561bdc4c2f5ad/make/hotspot/lib/JvmFeatures.gmk#L179 Might indeed make sense to refactor this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3484828679 From jwaters at openjdk.org Tue Nov 4 09:31:48 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 4 Nov 2025 09:31:48 GMT Subject: RFR: 8370438: Offer link time optimization support on library level In-Reply-To: References: <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com> <809Ep8sEq1en07SmuThJa34v0-oYAdPr6Jhwg4DZTGM=.08fe720e-dc5e-4903-9c3c-e3f5770859e3@github.com> Message-ID: On Tue, 4 Nov 2025 09:20:29 GMT, Matthias Baesken wrote: > > > When introducing new compiler flags, you need to do one of: > > > > > > Just an idea to think about: would it be possible to share the same variable between the JDK and HotSpot to store these parameters? Even in this discussion, it would highlight that these parameters are not new. Or is it not worth the effort? > > For the HS build, we set them directly in the makefile and not in the configure m4 files, see > > https://github.com/openjdk/jdk/blob/e4aed95cac343f1339b9bc87721561bdc4c2f5ad/make/hotspot/lib/JvmFeatures.gmk#L179 > > > Might indeed make sense to refactor this. It would be a little awkward to refactor only the JVM LTO flags into configure flags while leaving the rest of the JVM feature flags set by the Makefile, just my 2 cents. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3484869603 From jdv at openjdk.org Tue Nov 4 09:45:33 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 4 Nov 2025 09:45:33 GMT Subject: RFR: 8368729: Add appropriate checks in java.awt.image.Kernel constructor Message-ID: `java.awt.image.Kernel` constructor doesn't validate all input values and we need to add appropriate checks. A new test is also added to make sure we appropriate exception when invalid values are passed. This will also need a CSR. ------------- Commit messages: - 8368729: Add appropriate checks in java.awt.image.Kernel constructor Changes: https://git.openjdk.org/jdk/pull/28127/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28127&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368729 Stats: 83 lines in 2 files changed: 77 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/28127.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28127/head:pull/28127 PR: https://git.openjdk.org/jdk/pull/28127 From mbaesken at openjdk.org Tue Nov 4 10:06:26 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 4 Nov 2025 10:06:26 GMT Subject: RFR: 8370438: Offer link time optimization support on library level In-Reply-To: References: <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com> <809Ep8sEq1en07SmuThJa34v0-oYAdPr6Jhwg4DZTGM=.08fe720e-dc5e-4903-9c3c-e3f5770859e3@github.com> Message-ID: On Tue, 4 Nov 2025 09:29:25 GMT, Julian Waters wrote: >It would be a little awkward to refactor only the JVM LTO flags into configure flags while leaving the rest of the JVM feature flags set by the Makefile, just my 2 cents. The part in the Makefile would probably stay, but could reuse common flags from configure, e.g. something like this JVM_LDFLAGS_FEATURES += $(CXX_O_FLAG_HIGHEST_JVM) -flto=auto \ -fuse-linker-plugin -fno-strict-aliasing => JVM_LDFLAGS_FEATURES += $(CXX_O_FLAG_HIGHEST_JVM) $(LDFLAGS_LTO) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3485030596 From jdv at openjdk.org Tue Nov 4 11:44:47 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 4 Nov 2025 11:44:47 GMT Subject: RFR: 4954405: Data buffers created with an offset are unusable [v2] In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 21:01:35 GMT, Phil Race wrote: >> ByteInterleavedRaster is not including the DataBuffer offset in returns from getDataElements >> The super-class sets it in the constructor which runs very much like this subclass except it omits this. >> The parent class of ByteInterleavedRaster is ByteComponentRaster and it uses the DataBuffer offset >> to adjust dataOffsets values used in all calculations. >> >> Instead ByteInterleavedRaster does something a bit different than other classes where it includes it in some instance vars >> that also have additional offsets that apply for getPixels and getSamples but aren't used in getDataElements. >> >> It looks to me as if this is what ByteInterleavedRaster should also do instead. >> All existing tests pass, and this resolves the specific complaint in the bug report. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 4954405 Marked as reviewed by jdv (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27782#pullrequestreview-3416006894 From psadhukhan at openjdk.org Tue Nov 4 12:26:08 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 4 Nov 2025 12:26:08 GMT Subject: RFR: 8364583: ColorConvertOp fails for CMYK =?UTF-8?B?4oaS?= RGB conversion In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 05:25:44 GMT, Phil Race wrote: > color is initially returned as 4 element array but we over-write with 3 element and so next time through the loop it is used by but is too short. > More details in JBS. Marked as reviewed by psadhukhan (Reviewer). test/jdk/java/awt/image/ColorConvertOp/ColorConvertOpCMYK.java line 49: > 47: ColorSpace cs = ColorSpace.getInstance(ColorSpace.CS_sRGB); > 48: ColorConvertOp convertOp = new ColorConvertOp(cs, null); > 49: BufferedImage rgb = convertOp.filter(source, null); rgb variable can be removed... ------------- PR Review: https://git.openjdk.org/jdk/pull/27785#pullrequestreview-3416180330 PR Review Comment: https://git.openjdk.org/jdk/pull/27785#discussion_r2490306903 From aivanov at openjdk.org Tue Nov 4 13:26:53 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Nov 2025 13:26:53 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v3] In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 21:48:30 GMT, Harshitha Onkar wrote: >> test/jdk/javax/swing/regtesthelpers/Util.java line 1: >> >>> 1: /* >> >>> Existing `Util.findSubComponent()` finds component by class name >> >> To eliminate code duplication, the existing `findSubComponent` should use the new `findComponent` which is more flexible. Just pass `parent.getClass().getName().contains(className)` as the predicate to the new method. > > Tested by in turn calling findComponent() from findSubComponent() it does not work as expected since the recursive logic to find the component differs for both methods. > > Replacing findSubComponent() as below with the latest changes does not work. To verify run javax/swing/JColorChooser/Test7194184.java by replacing the findSubComponent() as below. > > > public static Component findSubComponent(Component parent, String className) { > String parentClassName = parent.getClass().getName(); > > if (parentClassName.contains(className)) { > return parent; > } > return findComponent((Container) parent, > c -> parent.getClass().getName().contains(className)); > } It fails because the code I proposed is plainly wrong. public static Component findSubComponent(Component parent, String className) { return findComponentImpl((Container) parent, c -> c.getClass().getName().contains(className)); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2490504845 From aivanov at openjdk.org Tue Nov 4 13:26:54 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Nov 2025 13:26:54 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v3] In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 13:22:33 GMT, Alexey Ivanov wrote: >> Tested by in turn calling findComponent() from findSubComponent() it does not work as expected since the recursive logic to find the component differs for both methods. >> >> Replacing findSubComponent() as below with the latest changes does not work. To verify run javax/swing/JColorChooser/Test7194184.java by replacing the findSubComponent() as below. >> >> >> public static Component findSubComponent(Component parent, String className) { >> String parentClassName = parent.getClass().getName(); >> >> if (parentClassName.contains(className)) { >> return parent; >> } >> return findComponent((Container) parent, >> c -> parent.getClass().getName().contains(className)); >> } > > It fails because the code I proposed is plainly wrong. > > > public static Component findSubComponent(Component parent, String className) { > return findComponentImpl((Container) parent, > c -> c.getClass().getName().contains(className)); > } I would even format it like this, wrapping all the chained calls: public static Component findSubComponent(Component parent, String className) { return findComponentImpl((Container) parent, c -> c.getClass() .getName() .contains(className)); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2490509126 From erikj at openjdk.org Tue Nov 4 13:39:40 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 4 Nov 2025 13:39:40 GMT Subject: RFR: 8370438: Offer link time optimization support on library level In-Reply-To: References: <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com> <809Ep8sEq1en07SmuThJa34v0-oYAdPr6Jhwg4DZTGM=.08fe720e-dc5e-4903-9c3c-e3f5770859e3@github.com> Message-ID: On Tue, 4 Nov 2025 10:02:39 GMT, Matthias Baesken wrote: > > It would be a little awkward to refactor only the JVM LTO flags into configure flags while leaving the rest of the JVM feature flags set by the Makefile, just my 2 cents. > > The part in the Makefile would probably stay, but could reuse common flags from configure, e.g. something like this > > ``` > JVM_LDFLAGS_FEATURES += $(CXX_O_FLAG_HIGHEST_JVM) -flto=auto \ > -fuse-linker-plugin -fno-strict-aliasing > => > JVM_LDFLAGS_FEATURES += $(CXX_O_FLAG_HIGHEST_JVM) $(LDFLAGS_LTO) > ``` Yes, please only define the values once and use the variables in the JVM makefile. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3486047759 From aivanov at openjdk.org Tue Nov 4 13:44:54 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Nov 2025 13:44:54 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v3] In-Reply-To: <8uTT1OhvToiXCQKK9gV6ug-_NnXufFjOOkBhrtRhg80=.6d333ab1-c47b-480f-8273-befe3af559fe@github.com> References: <8uTT1OhvToiXCQKK9gV6ug-_NnXufFjOOkBhrtRhg80=.6d333ab1-c47b-480f-8273-befe3af559fe@github.com> Message-ID: On Mon, 3 Nov 2025 21:56:44 GMT, Harshitha Onkar wrote: >> `findComponent(final Container container, final Predicate predicate)` is a useful utility method and thus added to` javax/swing/regtesthelpers/Util.java` instead of having redundant code in tests. It can be used to find a component by label name. >> >> PS: Existing `Util.findSubComponent()` finds component by class name but `findComponent()` can be used to search for a particular component by label name/title when there are multiple subcomponents of same type by applying a predicate logic. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > Review changes: EDT check Changes requested by aivanov (Reviewer). test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 234: > 232: Component result = Util.findComponent(container, > 233: c -> c instanceof JToggleButton button > 234: && "Details".equals(button.getToolTipText())); Suggestion: Component result = Util.findComponent(container, c -> c instanceof JToggleButton button && "Details".equals(button.getToolTipText())); Let's not touch the indentation of the second parameter. [The comment below](https://github.com/openjdk/jdk/pull/27944/files#r2461135990) is marked as resolved but it's not resolved. This is what I meant. That is, only `Util.` is added, only one line of the `findDetailsButton` method changes compared to master. test/jdk/javax/swing/JFileChooser/bug4759934.java line 74: > 72: robot.mousePress(MouseEvent.BUTTON1_DOWN_MASK); > 73: robot.mouseRelease(MouseEvent.BUTTON1_DOWN_MASK); > 74: robot.delay(500); All the clicks above are to click a button? Should we replace these clicks with programmatic clicks? However, I'd like to ensure the updated test still reproduces the original bug. Updating this test could better pull out into its own issue. (Yes, I remember that this refactoring comes from an internal comment I made when `javax/swing/JFileChooser/bug4759934.java` was open-sourced.) test/jdk/javax/swing/regtesthelpers/Util.java line 169: > 167: > 168: private static Component findComponentImpl(final Container container, > 169: final Predicate predicate) { Suggestion: private static Component findComponentImpl(final Container container, final Predicate predicate) { Align the second wrapped parameter. ------------- PR Review: https://git.openjdk.org/jdk/pull/27944#pullrequestreview-3416463764 PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2490559501 PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2490547507 PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2490517210 From aivanov at openjdk.org Tue Nov 4 13:49:20 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Nov 2025 13:49:20 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v3] In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 13:24:01 GMT, Alexey Ivanov wrote: >> It fails because the code I proposed is plainly wrong. >> >> >> public static Component findSubComponent(Component parent, String className) { >> return findComponentImpl((Container) parent, >> c -> c.getClass().getName().contains(className)); >> } > > I would even format it like this, wrapping all the chained calls: > > > public static Component findSubComponent(Component parent, String className) { > return findComponentImpl((Container) parent, > c -> c.getClass() > .getName() > .contains(className)); > } I also suggest calling `findComponent` instead of `findComponentImpl` ? then you can remove the line *?Always run this method on the EDT thread?* from the javadoc comment. Also, change ?a sub component? to ?a subcomponent?. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2490583144 From aivanov at openjdk.org Tue Nov 4 13:57:44 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Nov 2025 13:57:44 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v3] In-Reply-To: <6ymiIfr6yBXzVnHxqk8sDsV1KyAJWHjQhZcpNkh02vs=.1cb647a3-c610-436d-8045-8292902021aa@github.com> References: <8uTT1OhvToiXCQKK9gV6ug-_NnXufFjOOkBhrtRhg80=.6d333ab1-c47b-480f-8273-befe3af559fe@github.com> <6ymiIfr6yBXzVnHxqk8sDsV1KyAJWHjQhZcpNkh02vs=.1cb647a3-c610-436d-8045-8292902021aa@github.com> Message-ID: On Tue, 4 Nov 2025 06:57:46 GMT, Tejesh R wrote: > Any reason for updating the test files with this PR ? I feel this PR should be restricted to Util file updates alone, updating the test files can be taken up separately. This is a valid concern. I tend to agree. The test from which the `findComponent` method is moved to the `Util` class, `javax/swing/JFileChooser/FileSizeCheck.java`, isn't backported to any releases. Yet I expect this change to `Util` would be backported to all the supported releases. This is why I suggest submitting a new bug to update `FileSizeCheck.java`. (That new bug would be backported to 21u where the test `FileSizeCheck.java` exists.) Similarly, as [I just mentioned](https://github.com/openjdk/jdk/pull/27944#discussion_r2490547507), it makes sense to update `javax/swing/JFileChooser/bug4759934.java` in its own issue to keep the history clearer. Especially, if we replace all button clicks with programmatic `doClick` instead of using robot. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27944#issuecomment-3486126889 From aivanov at openjdk.org Tue Nov 4 14:04:09 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Nov 2025 14:04:09 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v3] In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 13:46:22 GMT, Alexey Ivanov wrote: >> I would even format it like this, wrapping all the chained calls: >> >> >> public static Component findSubComponent(Component parent, String className) { >> return findComponentImpl((Container) parent, >> c -> c.getClass() >> .getName() >> .contains(className)); >> } > > I also suggest calling `findComponent` instead of `findComponentImpl` ? then you can remove the line *?Always run this method on the EDT thread?* from the javadoc comment. > > Also, change ?a sub component? to ?a subcomponent?. > It fails because the code I proposed is plainly wrong. > > ```java > public static Component findSubComponent(Component parent, String className) { > return findComponentImpl((Container) parent, > c -> c.getClass().getName().contains(className)); > } > ``` This time I tested the above code by running the following tests `test/jdk/javax/swing/JFileChooser/FileChooserToolTipTest.java test/jdk/javax/swing/JFileChooser/FCPopupMenuOrientationTest.java` which use `Util.findSubComponent` and the tests passed for me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2490642394 From aivanov at openjdk.org Tue Nov 4 14:36:41 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Nov 2025 14:36:41 GMT Subject: RFR: 8349157: Unnecessary Hashtable usage in XKeysym.javaKeycode2KeysymHash In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 09:35:09 GMT, Andrey Turbanov wrote: > There is a field `sun.awt.X11.XKeysym#javaKeycode2KeysymHash` which uses legacy Hashtable class. > As this map is read-only and all its content is initialized in `` we can safely use immutable Map instead. I submitted a test job. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23347#issuecomment-3486307190 From mbaesken at openjdk.org Tue Nov 4 16:24:01 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 4 Nov 2025 16:24:01 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v4] In-Reply-To: References: Message-ID: <5zPoK0usRsiSMWNj6SoATGuJzQn50TFs4sqxwt9KqaM=.b4fb7d54-7ce9-4c1d-95a8-e5c1b49c88ed@github.com> > We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. > But for other JDK native libs, we do not have support for this feature. > LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Enable lto for BUILD_LIBSPLASHSCREEN, we could add a separate configure flag if desired ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27976/files - new: https://git.openjdk.org/jdk/pull/27976/files/de4dbf2b..6adc512d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27976/head:pull/27976 PR: https://git.openjdk.org/jdk/pull/27976 From mbaesken at openjdk.org Tue Nov 4 16:49:06 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 4 Nov 2025 16:49:06 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v5] In-Reply-To: References: Message-ID: > We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. > But for other JDK native libs, we do not have support for this feature. > LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Use lto configure flags in hs build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27976/files - new: https://git.openjdk.org/jdk/pull/27976/files/6adc512d..72ba9ed1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=03-04 Stats: 11 lines in 1 file changed: 0 ins; 5 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27976/head:pull/27976 PR: https://git.openjdk.org/jdk/pull/27976 From kizune at openjdk.org Tue Nov 4 16:51:25 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 4 Nov 2025 16:51:25 GMT Subject: RFR: 8357252: sun/awt/font/TestArabicHebrew.java fails in OEL 9 and 10 x64 In-Reply-To: <2DGbd1T9g477NOXI2G6bIcP7dYyM1-ur745qYQA69_o=.e5c976f6-b72d-4688-b8cc-3e9f68db192b@github.com> References: <2DGbd1T9g477NOXI2G6bIcP7dYyM1-ur745qYQA69_o=.e5c976f6-b72d-4688-b8cc-3e9f68db192b@github.com> Message-ID: On Thu, 30 Oct 2025 18:52:53 GMT, Phil Race wrote: > A long time ago (JDK 7) when the linux font properties were largely replaced by using fontconfig logic was included to try to limit the number of slots used for composite fonts by requiring that fonts add sufficient code points. > In practice today this limitation seems to be reductions like having 40 slots instead of 50. > Except for keeping it for debugging, this fix removes that limitation which had a bad consequence on some recent Linuxes where the primary Hebrew font (Noto Sans Hebrew) came after another font (DejaVu Sans) that provided some Hebrew accents and punctuation but not the alphabet and was also far enough down the list (14th) to be where we require 50 new code points to be worthy of inclusion and it only added 33. Marked as reviewed by kizune (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28072#pullrequestreview-3417568045 From aivanov at openjdk.org Tue Nov 4 17:33:41 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Nov 2025 17:33:41 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v7] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 14:17:52 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did >> >> build.log on release configuration: >> >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regEnable()': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:334:14: warning: unused variable 'freeData' [-Wunused-variable] >> 334 | bool freeData = false; >> | ^~~~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:326:11: warning: unused variable 'retval' [-Wunused-variable] >> 326 | DWORD retval = -1; >> | ^~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regDeleteValue(HKEY, LPCWSTR)': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:379:14: warning: unused variable 'freeData' [-Wunused-variable] >> 379 | bool freeData = false; >> | ^~~~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:367:11: warning: unused variable 'retval' [-Wunused-variable] >> 367 | DWORD retval = -1; >> | ^~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c: In function 'shutdownAccessBridge': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win3... > > Julian Waters has updated the pull request incrementally with five additional commits since the last revision: > > - Fixup code in JavaAccessBridge.cpp > - Mark unused code in AccessBridgeJavaVMInstance.cpp > - Mark lastError in jaccessinspector.cpp > - Remove other retval from jabswitch.cpp > - Remove retval from jabswitch.cpp What state are we in? Are there any updates to review? ------------- PR Review: https://git.openjdk.org/jdk/pull/21656#pullrequestreview-3417792263 From aivanov at openjdk.org Tue Nov 4 17:33:43 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Nov 2025 17:33:43 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 14:06:01 GMT, Julian Waters wrote: > Hi, I'm back to trying to work on the JDK now. Should this issue depend on 8348872 and 8348876? Hopefully those can be fixed soon Perhaps. With these issues resolved ? [JDK-8348872](https://bugs.openjdk.org/browse/JDK-8348872 "jabswitch.cpp: regEnable and regDeleteValue leak reallocated data buffer") and [JDK-8348876](https://bugs.openjdk.org/browse/JDK-8348876 "jabswitch.cpp: regEnable and regDeleteValue leak newStr") ? it could easier to clean up the code further. I don't mind if you take over these issues. I haven't got time to look at the issues since I submitted them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r2491444771 From aivanov at openjdk.org Tue Nov 4 17:35:52 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Nov 2025 17:35:52 GMT Subject: RFR: 8349157: Unnecessary Hashtable usage in XKeysym.javaKeycode2KeysymHash In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 09:35:09 GMT, Andrey Turbanov wrote: > There is a field `sun.awt.X11.XKeysym#javaKeycode2KeysymHash` which uses legacy Hashtable class. > As this map is read-only and all its content is initialized in `` we can safely use immutable Map instead. The tests are green. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23347#pullrequestreview-3417831162 From azvegint at openjdk.org Tue Nov 4 18:16:15 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 4 Nov 2025 18:16:15 GMT Subject: RFR: 8369327: On macOS List may loses selection when added to Frame [v2] In-Reply-To: <9t2i7R9UpT7sLYSW6UEArOX9NA6R0QqQ-ufmiOk8bqY=.4c9d5576-826c-4210-83a8-6a42cd177514@github.com> References: <9t2i7R9UpT7sLYSW6UEArOX9NA6R0QqQ-ufmiOk8bqY=.4c9d5576-826c-4210-83a8-6a42cd177514@github.com> Message-ID: On Mon, 3 Nov 2025 23:10:10 GMT, Sergey Bylokhov wrote: >> The bug happens when List.select(int) is used in multiple selection mode. It only appears when the List is added to a Frame, because in that case, the selection is handled by the platform peer, and the internal logic in the List class is skipped. >> >> To fix this, the code now uses [addSelectionInterval](https://github.com/openjdk/jdk/blob/910bb68e5191f830ff6f3dff5753e4e5f6214a7b/src/java.desktop/share/classes/javax/swing/ListSelectionModel.java#L93) instead of setSelectedIndex. This method works correctly for multiple selection mode when using JList as the delegate on macOS. >> >> I added DeselectionUnitTest and SelectionUnitTest tests for some selection and deselection cases. At first, it was one big test, but I split it because it got too large. >> >> **Notes on invalid index handling** >> According to the java.awt.List [spec](https://github.com/openjdk/jdk/blob/0e5655e6680762a99b5aecb58369b880ea913565/src/java.desktop/share/classes/java/awt/List.java#L573), using invalid indexes is undefined behavior. For now, I have decided not to validate these cases fully in this patch, but I did add a check in the `LWListPeer.select()` to handle them more safely. >> >> The previously used setSelectedIndex method [ignored](https://github.com/openjdk/jdk/blob/0e5655e6680762a99b5aecb58369b880ea913565/src/java.desktop/share/classes/javax/swing/JList.java#L2229) indexes greater than the list size, unlike addSelectionInterval. So I added an explicit check to skip all indexes larger than the list size. >> >> Later, I discovered that passing a negative index not only causes an exception (which is acceptable, since it's undefined behavior), but also leaves the peer in an inconsistent state. This happens because setSkipStateChangedEvent(false) at the end of LWListPeer.select() is not called if an exception is thrown. >> >> To prevent this, I added a check to skip all negative values as well. As a result, the peer now cleanly ignores all out-of-range indexes. >> >> **Description of how invalid indexes are handled on other platforms:** >> - The shared code in java.awt.List stores elements and selection separately, so it accepts invalid indexes. This can cause exceptions if the selection and data become out of sync. >> - On Windows, all invalid indexes are ignored, except for the special value -1, which is used to select or deselect all elements. This happens because the indexes are passed to the win api without validation. >> - XAWT uses the same logic as the shared code, so it can... > > Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8369327 > - Update ProblemList.txt > - Update SelectInvalid.java > - Validate "index >= 0 && index < model.getSize()" > - Create SelectInvalid.java > - 8369327: On macOS List may loses selection when added to Frame There is a failing JCK test after this behavioral change, it is against of this part of the specification: https://github.com/openjdk/jdk/blob/4c6af03f81e068a98b8f4628b96682a54f3946da/src/java.desktop/share/classes/java/awt/List.java#L732-L736 Now it always selects the very first item. The gist of the failed part of the test is as follows: [ListMultipleMode.java](https://github.com/user-attachments/files/23343220/ListMultipleMode.java) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27682#issuecomment-3487434403 From serb at openjdk.org Tue Nov 4 18:31:02 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 4 Nov 2025 18:31:02 GMT Subject: RFR: 8369327: On macOS List may loses selection when added to Frame [v2] In-Reply-To: References: <9t2i7R9UpT7sLYSW6UEArOX9NA6R0QqQ-ufmiOk8bqY=.4c9d5576-826c-4210-83a8-6a42cd177514@github.com> Message-ID: On Tue, 4 Nov 2025 18:13:53 GMT, Alexander Zvegintsev wrote: >There is a failing JCK test after this behavioral change, it is against of this part of the specification: It seems the test passed by accident before, because multiple selection didn?t work, so the switch to single selection never actually happened. Looking into the fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27682#issuecomment-3487485137 From kizune at openjdk.org Tue Nov 4 19:40:12 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 4 Nov 2025 19:40:12 GMT Subject: RFR: 8368729: Add appropriate checks in java.awt.image.Kernel constructor In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 09:35:32 GMT, Jayathirth D V wrote: > `java.awt.image.Kernel` constructor doesn't validate all input values and we need to add appropriate checks. > A new test is also added to make sure we appropriate exception when invalid values are passed. > > This will also need a CSR. The change seems reasonable but as you mentioned we will need CSR for changing public constructor documentation and it needs to be linked here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28127#issuecomment-3487733632 From azvegint at openjdk.org Tue Nov 4 19:59:14 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 4 Nov 2025 19:59:14 GMT Subject: RFR: 8368729: Add appropriate checks in java.awt.image.Kernel constructor In-Reply-To: References: Message-ID: <02HTdHYDK23DPPpvf1zcE1it03Fmx3LfcC70RmtmKsU=.8bf2cf9b-63c7-4314-8da8-1939174291b1@github.com> On Tue, 4 Nov 2025 09:35:32 GMT, Jayathirth D V wrote: > `java.awt.image.Kernel` constructor doesn't validate all input values and we need to add appropriate checks. > A new test is also added to make sure we appropriate exception when invalid values are passed. > > This will also need a CSR. ------------- Marked as reviewed by azvegint (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28127#pullrequestreview-3418429913 From honkar at openjdk.org Tue Nov 4 21:22:29 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 4 Nov 2025 21:22:29 GMT Subject: RFR: 8364583: ColorConvertOp fails for CMYK =?UTF-8?B?4oaS?= RGB conversion In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 19:00:45 GMT, Sergey Bylokhov wrote: >> fromCIEXYZ is defined on ColorSpace, not ICC_ColorSpace. >> >> It requires 3 (or more) components, and then dstColorSpace will return an array of colors in its own colorspace. >> The dstColor parameter is always created with at least 3 components based on the dstNumComp >> And if there's no bug in dstColorSpace it should return an array of the right length for itself. >> So if there's a bug it isn't obvious to me. > > Seems the destination handles it properly; I tested it with the following example: > > import java.awt.Transparency; > import java.awt.color.ColorSpace; > import java.awt.image.BufferedImage; > import java.awt.image.ColorConvertOp; > import java.awt.image.ComponentColorModel; > import java.awt.image.DataBuffer; > import java.awt.image.WritableRaster; > > import static java.awt.color.ColorSpace.TYPE_2CLR; > import static java.awt.color.ColorSpace.TYPE_FCLR; > import static java.awt.color.ColorSpace.TYPE_GRAY; > > public final class TestCCP { > > private static final int WIDTH = 10; > private static final int HEIGHT = 10; > > private static class CustomColorSpace extends ColorSpace { > private final int numComponents; > > private CustomColorSpace(int type, int numComponents) { > super(type, numComponents); > this.numComponents = numComponents; > } > > @Override > public float[] toRGB(float[] colorvalue) { > return new float[3]; > } > > @Override > public float[] fromRGB(float[] rgbvalue) { > return new float[numComponents]; > } > > @Override > public float[] toCIEXYZ(float[] colorvalue) { > return new float[3]; > } > > @Override > public float[] fromCIEXYZ(float[] colorvalue) { > return new float[numComponents]; > } > } > > private static final ColorSpace[] CS = { > ColorSpace.getInstance(ColorSpace.CS_CIEXYZ), > ColorSpace.getInstance(ColorSpace.CS_GRAY), > ColorSpace.getInstance(ColorSpace.CS_LINEAR_RGB), > ColorSpace.getInstance(ColorSpace.CS_PYCC), > ColorSpace.getInstance(ColorSpace.CS_sRGB), > new CustomColorSpace(TYPE_GRAY, 1), > new CustomColorSpace(TYPE_2CLR, 2), > new CustomColorSpace(TYPE_FCLR, 15) > }; > > public static void main(String[] args) { > for (ColorSpace srcCS : CS) { > for (ColorSpace fromCS : CS) { > for (ColorSpace toCS : CS) { > for (ColorSpace dstCS : CS) { > BufferedImage src = createTestImage(srcCS); > BufferedImage dst = createTestImage(dstCS); > > new ColorConvertOp(fromCS, toCS, null).filter(src, dst); > } > } > } > } > } > > private static BufferedImage createTestImage(ColorSpace cs) { > ComponentColorModel cm = new ComponentColorModel(cs, false, false,... @mrserb @prrace Are we testing the else block - the one for **"possible non-ICC src, possible CSList, possible non-ICC dst"** with the test provided by Sergey? Ln#872 in the else block has a similar line `color = srcCM.getNormalizedComponents(spixel, color, 0);` and the above test runs fine if normComponents is set to either color or null. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27785#discussion_r2492077834 From honkar at openjdk.org Tue Nov 4 21:25:59 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 4 Nov 2025 21:25:59 GMT Subject: RFR: 8364583: ColorConvertOp fails for CMYK =?UTF-8?B?4oaS?= RGB conversion In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 05:25:44 GMT, Phil Race wrote: > color is initially returned as 4 element array but we over-write with 3 element and so next time through the loop it is used by but is too short. > More details in JBS. The fix LGTM for the case demonstrated by the regression test although I'm not clear on the case described by @mrserb in this thread - https://github.com/openjdk/jdk/pull/27785/files#r2487547644 ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27785#pullrequestreview-3418679845 From prr at openjdk.org Tue Nov 4 21:43:35 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 4 Nov 2025 21:43:35 GMT Subject: Integrated: 8364583: ColorConvertOp fails for CMYK =?UTF-8?B?4oaS?= RGB conversion In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 05:25:44 GMT, Phil Race wrote: > color is initially returned as 4 element array but we over-write with 3 element and so next time through the loop it is used by but is too short. > More details in JBS. This pull request has now been integrated. Changeset: 8585b46c Author: Phil Race URL: https://git.openjdk.org/jdk/commit/8585b46c1221f6894f4f1cda34714e7b49a8cccb Stats: 52 lines in 3 files changed: 51 ins; 0 del; 1 mod 8364583: ColorConvertOp fails for CMYK ? RGB conversion Reviewed-by: serb, psadhukhan, honkar ------------- PR: https://git.openjdk.org/jdk/pull/27785 From prr at openjdk.org Tue Nov 4 21:50:48 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 4 Nov 2025 21:50:48 GMT Subject: RFR: 8369618: Remove outdated reference to JDK 1.1 in the spec of BufferedImage.TYPE_INT_ARGB In-Reply-To: References: Message-ID: On Sun, 12 Oct 2025 01:40:20 GMT, Sergey Bylokhov wrote: > The reference to "JDK 1.1 and earlier releases" was removed from the BufferedImage.TYPE_INT_ARGB spec. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27758#pullrequestreview-3418742068 From prr at openjdk.org Tue Nov 4 21:51:02 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 4 Nov 2025 21:51:02 GMT Subject: Integrated: 8357252: sun/awt/font/TestArabicHebrew.java fails in OEL 9 and 10 x64 In-Reply-To: <2DGbd1T9g477NOXI2G6bIcP7dYyM1-ur745qYQA69_o=.e5c976f6-b72d-4688-b8cc-3e9f68db192b@github.com> References: <2DGbd1T9g477NOXI2G6bIcP7dYyM1-ur745qYQA69_o=.e5c976f6-b72d-4688-b8cc-3e9f68db192b@github.com> Message-ID: On Thu, 30 Oct 2025 18:52:53 GMT, Phil Race wrote: > A long time ago (JDK 7) when the linux font properties were largely replaced by using fontconfig logic was included to try to limit the number of slots used for composite fonts by requiring that fonts add sufficient code points. > In practice today this limitation seems to be reductions like having 40 slots instead of 50. > Except for keeping it for debugging, this fix removes that limitation which had a bad consequence on some recent Linuxes where the primary Hebrew font (Noto Sans Hebrew) came after another font (DejaVu Sans) that provided some Hebrew accents and punctuation but not the alphabet and was also far enough down the list (14th) to be where we require 50 new code points to be worthy of inclusion and it only added 33. This pull request has now been integrated. Changeset: 245eeb41 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/245eeb41bc749cba4e44bf3998cf07e7a1b784ed Stats: 10 lines in 2 files changed: 0 ins; 8 del; 2 mod 8357252: sun/awt/font/TestArabicHebrew.java fails in OEL 9 and 10 x64 Reviewed-by: serb, psadhukhan, kizune ------------- PR: https://git.openjdk.org/jdk/pull/28072 From prr at openjdk.org Tue Nov 4 21:51:02 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 4 Nov 2025 21:51:02 GMT Subject: RFR: 8370719: [Linux] Use /etc/os-release values for font configuration file names In-Reply-To: References: <5Bos0KnD6Ila_yoVNsOHyCROhYlt8l5IKfsWeWvbhJo=.c3c57420-ddbc-4594-ae9b-36045cc32462@github.com> Message-ID: <4JSlgqjKEClxhzlVyqq5ZeLGNIZ-LZ6KkTVW6gNFZ9A=.0578c413-34c6-4a49-a843-894737cb323c@github.com> On Tue, 4 Nov 2025 00:22:38 GMT, Sergey Bylokhov wrote: >> And for the application - and we are an application - the same documentation says to look at the primary file location - in /etc. And only fall back to the second location if that file does not exist. If the file in /etc exists and differs from the /usr/lib/ file the later should not be used. Which implies that system vendor **can** replace the /etc/os-release file with another one or with link to the place other than /usr/lib/os-release. The /usr/lib/os-release is a fallback location. But we already have a fallback mechanics - we will have generic values set (osName is "Linux" and osVersion id null). Lust look at the usage examples at the bottom of the man page - all examples are using /usr/lib/os-release if /etc/os-release does not exist. > >> all examples are using /usr/lib/os-release if /etc/os-release does not exist. > > This is what I pointed out, we should follow the spec and check the "/usr/lib/" if the file in /etc/ does not exist, since the spec allows it to be missing. Applications are encouraged to check the /etc file. Also all here, someone has a list of which distros / versions contain this file https://github.com/chef/os_release It is maintained so people can look to see what to expect without having to install, but it seems to me like it is something that we really can depend on. Also note that all distros we explicitly recognize have this file, and that it is *what we are already doing* for other distros, where we fall back to this file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28073#discussion_r2492130980 From prr at openjdk.org Tue Nov 4 21:51:04 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 4 Nov 2025 21:51:04 GMT Subject: Integrated: 8370719: [Linux] Use /etc/os-release values for font configuration file names In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 19:07:04 GMT, Phil Race wrote: > The JBS issue has a long discussion and explanation but here's a short version. > Instead of having baked in names of distros in the code that figures out names for font configuration files for Linux > use the standard ID and VERSION_ID fields in /etc/os-release which is now standard. > even systemd doesn't work if it does not exist https://0pointer.de/blog/projects/os-release > And if it doesn't we just use "Linux" as the name. This pull request has now been integrated. Changeset: 984c87cf Author: Phil Race URL: https://git.openjdk.org/jdk/commit/984c87cf767a46a2c1000a4030dfd91a62b03b4d Stats: 62 lines in 2 files changed: 0 ins; 56 del; 6 mod 8370719: [Linux] Use /etc/os-release values for font configuration file names Reviewed-by: kizune, psadhukhan ------------- PR: https://git.openjdk.org/jdk/pull/28073 From prr at openjdk.org Tue Nov 4 21:53:08 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 4 Nov 2025 21:53:08 GMT Subject: Integrated: 4954405: Data buffers created with an offset are unusable In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 03:29:00 GMT, Phil Race wrote: > ByteInterleavedRaster is not including the DataBuffer offset in returns from getDataElements > The super-class sets it in the constructor which runs very much like this subclass except it omits this. > The parent class of ByteInterleavedRaster is ByteComponentRaster and it uses the DataBuffer offset > to adjust dataOffsets values used in all calculations. > > Instead ByteInterleavedRaster does something a bit different than other classes where it includes it in some instance vars > that also have additional offsets that apply for getPixels and getSamples but aren't used in getDataElements. > > It looks to me as if this is what ByteInterleavedRaster should also do instead. > All existing tests pass, and this resolves the specific complaint in the bug report. This pull request has now been integrated. Changeset: 146f8a83 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/146f8a83f9195ff246e2c3803c79171509df7d24 Stats: 75 lines in 2 files changed: 73 ins; 0 del; 2 mod 4954405: Data buffers created with an offset are unusable Reviewed-by: avu, psadhukhan, jdv ------------- PR: https://git.openjdk.org/jdk/pull/27782 From prr at openjdk.org Tue Nov 4 22:15:23 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 4 Nov 2025 22:15:23 GMT Subject: RFR: 8370637: [Windows] Crash if use Graphics after PrintJob.end [v4] In-Reply-To: References: Message-ID: > Synchronize WPrinterJob calls which use the printDC to avoid crash in case of mis-use. > The printerDC is released when the job ends. > It is zero-ed out in the handle in which it is stored > The calls which expect it to be valid now all check for zero and return if it is zero. > The calls are made synchronized as is the call to endDoc which zeroes it, so that they cannot have it zeroed out whilst using it. > > The tests are the same as in the fix for JDK-8370141 which is also under review. > Which ever is 2nd to be pushed will have to merge in the changes from the first Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8370637 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27984/files - new: https://git.openjdk.org/jdk/pull/27984/files/c6ac30b3..f41e12e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27984&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27984&range=02-03 Stats: 59 lines in 1 file changed: 0 ins; 0 del; 59 mod Patch: https://git.openjdk.org/jdk/pull/27984.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27984/head:pull/27984 PR: https://git.openjdk.org/jdk/pull/27984 From prr at openjdk.org Tue Nov 4 22:15:27 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 4 Nov 2025 22:15:27 GMT Subject: RFR: 8370637: [Windows] Crash if use Graphics after PrintJob.end [v2] In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 05:31:34 GMT, Alexander Zvegintsev wrote: >> Phil Race has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: >> >> - 8370637 >> - 8370637 >> - Merge >> - 8370637 > > src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java line 956: > >> 954: } >> 955: >> 956: protected synchronized void beginPath() { > > Perhaps this is a topic for a different PR, but the `protected` keyword is redundant here, as well as in many other places in the class, because the `WPrinterJob` is a final class. yes, another PR I think > src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 1589: > >> 1587: if ((HDC)dc != NULL) { >> 1588: DeletePrintDC((HDC)dc); >> 1589: } > > Suggestion: > > if ((HDC)dc != NULL) { > DeletePrintDC((HDC)dc); > } > > > The closing brace is misaligned here and in all other cases. I missed this comment. fixing. > src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 1871: > >> 1869: TRY; >> 1870: >> 1871: if ((HDC)printDC == NULL) { > > There is no need to place this check inside the try-catch block. I had to decide whether to put them outside or inside and it seemed safest to do it inside as a pattern. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27984#discussion_r2492175191 PR Review Comment: https://git.openjdk.org/jdk/pull/27984#discussion_r2492176209 PR Review Comment: https://git.openjdk.org/jdk/pull/27984#discussion_r2492179626 From prr at openjdk.org Tue Nov 4 22:15:28 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 4 Nov 2025 22:15:28 GMT Subject: RFR: 8370637: [Windows] Crash if use Graphics after PrintJob.end [v2] In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 22:08:23 GMT, Phil Race wrote: >> src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 1589: >> >>> 1587: if ((HDC)dc != NULL) { >>> 1588: DeletePrintDC((HDC)dc); >>> 1589: } >> >> Suggestion: >> >> if ((HDC)dc != NULL) { >> DeletePrintDC((HDC)dc); >> } >> >> >> The closing brace is misaligned here and in all other cases. > > I missed this comment. fixing. I missed this comment. fixing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27984#discussion_r2492178139 From prr at openjdk.org Wed Nov 5 00:22:18 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 5 Nov 2025 00:22:18 GMT Subject: RFR: 8370637: [Windows] Crash if use Graphics after PrintJob.end [v5] In-Reply-To: References: Message-ID: > Synchronize WPrinterJob calls which use the printDC to avoid crash in case of mis-use. > The printerDC is released when the job ends. > It is zero-ed out in the handle in which it is stored > The calls which expect it to be valid now all check for zero and return if it is zero. > The calls are made synchronized as is the call to endDoc which zeroes it, so that they cannot have it zeroed out whilst using it. > > The tests are the same as in the fix for JDK-8370141 which is also under review. > Which ever is 2nd to be pushed will have to merge in the changes from the first Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8370637 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27984/files - new: https://git.openjdk.org/jdk/pull/27984/files/f41e12e1..dbd0a850 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27984&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27984&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27984.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27984/head:pull/27984 PR: https://git.openjdk.org/jdk/pull/27984 From serb at openjdk.org Wed Nov 5 00:26:37 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 5 Nov 2025 00:26:37 GMT Subject: RFR: 8370719: [Linux] Use /etc/os-release values for font configuration file names In-Reply-To: <4JSlgqjKEClxhzlVyqq5ZeLGNIZ-LZ6KkTVW6gNFZ9A=.0578c413-34c6-4a49-a843-894737cb323c@github.com> References: <5Bos0KnD6Ila_yoVNsOHyCROhYlt8l5IKfsWeWvbhJo=.c3c57420-ddbc-4594-ae9b-36045cc32462@github.com> <4JSlgqjKEClxhzlVyqq5ZeLGNIZ-LZ6KkTV W6gNFZ9A=.0578c413-34c6-4a49-a843-894737cb323c@github.com> Message-ID: On Tue, 4 Nov 2025 21:45:26 GMT, Phil Race wrote: >Applications are encouraged to check the /etc file. I just highlighted that the current approach used in the patch does not follow the spec. While we can rely on the fact that some (or even most) distributions include this file in the /etc folder, the point still stands that this is a non-standard implementation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28073#discussion_r2492398072 From prr at openjdk.org Wed Nov 5 02:12:41 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 5 Nov 2025 02:12:41 GMT Subject: RFR: 8371304: mismatch in file name and class name for ByteInterleavedRasterOffsetsTest.java Message-ID: Fix class name in test. ------------- Commit messages: - 8371304 Changes: https://git.openjdk.org/jdk/pull/28142/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28142&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371304 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28142/head:pull/28142 PR: https://git.openjdk.org/jdk/pull/28142 From psadhukhan at openjdk.org Wed Nov 5 03:13:03 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 5 Nov 2025 03:13:03 GMT Subject: RFR: 8371304: mismatch in file name and class name for ByteInterleavedRasterOffsetsTest.java In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 02:04:24 GMT, Phil Race wrote: > Fix class name in test. Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28142#pullrequestreview-3419513645 From psadhukhan at openjdk.org Wed Nov 5 03:16:03 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 5 Nov 2025 03:16:03 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v3] In-Reply-To: References: Message-ID: On Sun, 2 Nov 2025 17:30:06 GMT, Phil Race wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Test update > > @TejeshR13 please review (in addition to @honkar-jdk ) @prrace Hi Phil, Can you please take a look at the CSR https://bugs.openjdk.org/browse/JDK-8370469? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27949#issuecomment-3489044317 From prr at openjdk.org Wed Nov 5 03:28:22 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 5 Nov 2025 03:28:22 GMT Subject: Integrated: 8371304: mismatch in file name and class name for ByteInterleavedRasterOffsetsTest.java In-Reply-To: References: Message-ID: <-Wt_lP37NpcB_fqA5JVsjC2tZTOZofZskbbGmfDLHBg=.19381fcc-deb7-4ef5-9ef7-d867867de11f@github.com> On Wed, 5 Nov 2025 02:04:24 GMT, Phil Race wrote: > Fix class name in test. This pull request has now been integrated. Changeset: d89c6a77 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/d89c6a77f2bf3e0f820f8f631d82d5bec1b02399 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8371304: mismatch in file name and class name for ByteInterleavedRasterOffsetsTest.java Reviewed-by: psadhukhan ------------- PR: https://git.openjdk.org/jdk/pull/28142 From jdv at openjdk.org Wed Nov 5 06:37:02 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 5 Nov 2025 06:37:02 GMT Subject: RFR: 8368729: Add appropriate checks in java.awt.image.Kernel constructor In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 19:38:02 GMT, Alexander Zuev wrote: > The change seems reasonable but as you mentioned we will need CSR for changing public constructor documentation and it needs to be linked here. Thanks for the review. There were some issues with Jira yesterday, so didn't raise a CSR. CSR is added now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28127#issuecomment-3489596351 From duke at openjdk.org Wed Nov 5 10:11:15 2025 From: duke at openjdk.org (Dmitry Kulikov) Date: Wed, 5 Nov 2025 10:11:15 GMT Subject: RFR: 8360120: Bundled macOS applications not receiving OpenURL events when launched as subprocess [v2] In-Reply-To: References: <7lKxbQNDcM9CZ2cM1XfnoMeeRLltiFkju6U3wPk71OA=.78b110f4-cb40-461c-aa3f-5f3bbacb2ae0@github.com> Message-ID: On Fri, 29 Aug 2025 04:42:24 GMT, Phil Race wrote: >> Yes, all 3 points are correct. Probably the native URL handler is installed during the startup of the bundled application in order to catch the first OpenURL event that might have launched the application in the first place (I'll conduct more tests to see how an early handler registration affects the startup behavior). Java code technically is not required to install any URL handlers even in case of a bundled application, however declaring the capability to handle OpenURL events in the application bundle requires some actions from the application developer. I guess it was thought of as a "common sense" not to declare OpenURL handling capability in the bundle without actually handling the URLs in the Java code. >> >> Searching the Internet so far did not show up any references to `[bundle _hasEAWTOverride:@"URLHandler"]` (or the respective keys in the property list file) except the JDK code itself. Under such circumstances I've decided to leave these checks intact. >> >> I'm investigating the possibility of composing a regression test for this change. It does not look straight impossible so far. I'll post an update on this matter shortly. > > @ProjectD8 any update on the regression test ? > Adding one (or not) is the only thing between this being a PR and a pushed fix. @prrace @azuev-java Thank you for the review and approval. I suggest we integrate these changes, and add the test when it is ready with a separate issue. Could you please sponsor this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25967#issuecomment-3490306743 From duke at openjdk.org Wed Nov 5 10:11:17 2025 From: duke at openjdk.org (duke) Date: Wed, 5 Nov 2025 10:11:17 GMT Subject: RFR: 8360120: Bundled macOS applications not receiving OpenURL events when launched as subprocess [v2] In-Reply-To: <7lKxbQNDcM9CZ2cM1XfnoMeeRLltiFkju6U3wPk71OA=.78b110f4-cb40-461c-aa3f-5f3bbacb2ae0@github.com> References: <7lKxbQNDcM9CZ2cM1XfnoMeeRLltiFkju6U3wPk71OA=.78b110f4-cb40-461c-aa3f-5f3bbacb2ae0@github.com> Message-ID: On Wed, 25 Jun 2025 07:03:33 GMT, Dmitry Kulikov wrote: >> Added an on-demand installation of the native OpenURL event handler to the `Application.setOpenURIHandler()`. >> >> This does not break the specification for the affected API, since the requirement of the application being bundled and containing `CFBundleURLTypes` in the `Info.plist` is still valid: macOS will neither launch nor send OpenURL events to an application that does not declare such capabilities it the bundle. >> >> Running tests on macOS showed no regressions after this patch. Other platforms are not affected. > > Dmitry Kulikov has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright years @ProjectD8 Your change (at version 9b579b6024d5e8055ffd3ba6ed3e7c6ddd73b667) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25967#issuecomment-3490315994 From mbaesken at openjdk.org Wed Nov 5 16:09:53 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 5 Nov 2025 16:09:53 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v5] In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 16:49:06 GMT, Matthias Baesken wrote: >> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. >> But for other JDK native libs, we do not have support for this feature. >> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Use lto configure flags in hs build Here are the lib sizes of libsplashscreen without / with lto for our toolchains at SAP (gcc 13.2.0, VS2022, Xcode 15.4) jdk opt / opt+LTO 1.5M / 1.5M aix_ppc64/images/jdk/lib/libsplashscreen.so 304K / 220K linux_aarch64/images/jdk/lib/libsplashscreen.so 292K / 180K linux_alpine_x86_64/images/jdk/lib/libsplashscreen.so 376K / 228K linux_ppc64le/images/jdk/lib/libsplashscreen.so 288K / 176K linux_x86_64/images/jdk/lib/libsplashscreen.so 388K / 240K darwinaarch64/images/jdk/lib/libsplashscreen.dylib 304K / 196K darwinintel64/images/jdk/lib/libsplashscreen.dylib 204K / 204K windows x86_64/images/jdk/bin/splashscreen.dll pdb / debuginfo size : jdk opt / opt+LTO 1.4M / 984K linux_aarch64/images/jdk/lib/libsplashscreen.debuginfo 1.4M / 924K linux_alpine_x86_64/images/jdk/lib/libsplashscreen.debuginfo 1.4M / 976K linux_ppc64le/images/jdk/lib/libsplashscreen.debuginfo 1.4M / 924K linux_x86_64/images/jdk/lib/libsplashscreen.debuginfo 352K / 344K windows x86_64/images/jdk/bin/splashscreen.dll.pdb ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3492076027 From mbaesken at openjdk.org Wed Nov 5 16:12:00 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 5 Nov 2025 16:12:00 GMT Subject: RFR: 8370438: Offer link time optimization support on library level In-Reply-To: References: <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com> <809Ep8sEq1en07SmuThJa34v0-oYAdPr6Jhwg4DZTGM=.08fe720e-dc5e-4903-9c3c-e3f5770859e3@github.com> Message-ID: On Tue, 4 Nov 2025 13:37:11 GMT, Erik Joelsson wrote: > Yes, please only define the values once and use the variables in the JVM makefile. I adjusted the build flag settings in JvmFeatures.gmk to use the flags set by configure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3492084845 From azvegint at openjdk.org Wed Nov 5 16:52:33 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 5 Nov 2025 16:52:33 GMT Subject: RFR: 8370637: [Windows] Crash if use Graphics after PrintJob.end [v5] In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 00:22:18 GMT, Phil Race wrote: >> Synchronize WPrinterJob calls which use the printDC to avoid crash in case of mis-use. >> The printerDC is released when the job ends. >> It is zero-ed out in the handle in which it is stored >> The calls which expect it to be valid now all check for zero and return if it is zero. >> The calls are made synchronized as is the call to endDoc which zeroes it, so that they cannot have it zeroed out whilst using it. >> >> The tests are the same as in the fix for JDK-8370141 which is also under review. >> Which ever is 2nd to be pushed will have to merge in the changes from the first > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8370637 Marked as reviewed by azvegint (Reviewer). src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 2013: > 2011: if ((HDC)printDC == NULL) { > 2012: return; > 2013: } Suggestion: if ((HDC)printDC == NULL) { return; } ------------- PR Review: https://git.openjdk.org/jdk/pull/27984#pullrequestreview-3423233198 PR Review Comment: https://git.openjdk.org/jdk/pull/27984#discussion_r2495325732 From dnguyen at openjdk.org Wed Nov 5 17:14:21 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 5 Nov 2025 17:14:21 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v9] In-Reply-To: References: <1nxKOtN4B2h026FhyQp8t-1IOZBFPMfnif7I5a0Vnuc=.9ffffa12-226f-49ac-8b85-fac3750c649f@github.com> <3hw1X_jGyDqVuyleOkeirF2hj4ZnfuBPoG9J-e4Rw50=.914a54f6-f2f8-491d-b2af-e84dfdc5967b@github.com> Message-ID: On Mon, 3 Nov 2025 19:08:30 GMT, Sergey Bylokhov wrote: > I don?t think it will be possible to change the implementation once these methods start being used by the tests, as the tests will depend on their behavior in one way or another. This means that once we release these methods, their implementation will essentially be set in stone. It would be better to check how this is implemented in a different API and see how difficult it would be to adjust the current implementation to follow the same behavior. I don't see why it wouldn't be possible to make changes to the implementation of the mouse movement. I have already looked at the API you described for mouse movement, and the implementation there is not too different. I don't think I'd need any new parameters or variables (except for 2 constant int vars), and would instead just change the calculation for the loop. For any relevant tests, it seems as long as the mouse can move from point A to B in a non-skipping fashion, then the implementation should be fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26969#issuecomment-3492402655 From erikj at openjdk.org Wed Nov 5 17:48:28 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 5 Nov 2025 17:48:28 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v5] In-Reply-To: References: Message-ID: <31uD61UWj2KbHHXtP8wsSHHbAAraD1MRQPpVrxKse8Q=.1037cea5-a914-46fd-b481-1cc72bbef719@github.com> On Tue, 4 Nov 2025 16:49:06 GMT, Matthias Baesken wrote: >> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. >> But for other JDK native libs, we do not have support for this feature. >> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Use lto configure flags in hs build make/autoconf/flags-cflags.m4 line 285: > 283: C_O_FLAG_NONE="-O0" > 284: > 285: # link time optimization can be additionally enabled on lib level I don't think this comment makes much sense in this context. make/common/native/Flags.gmk line 69: > 67: $1_OPT_CFLAGS += $(C_O_FLAG_LTO) > 68: $1_OPT_CXXFLAGS += $(CXX_O_FLAG_LTO) > 69: endif I don't think adding the LTO flags to the OPT flags is the right move, but if we are going with that, then this addition of LTO flags should only be done if `$$($1_OPTIMIZATION)` is set, as otherwise, those flags are already added through `$$($2_OPT_CFLAGS)`. That means, this block should be moved into the else block above, before the endif on line 64. However, the OPT flags are treated separately through SetupCompilerFlags and SetupCompileFileFlags because it should be possible to override the optimization level on a per file basis. The LTO flags on the other hand, are not possible to override on a per file basis, so we should not be tinkering with those in the SetupCompileFileFlags macro at all. So mixing in the LTO flags with the OPT flags is the wrong move. make/common/native/Flags.gmk line 242: > 240: ifeq ($$($1_LINK_TIME_OPTIMIZATION), true) > 241: $1_EXTRA_LDFLAGS += $(LDFLAGS_LTO) > 242: endif For flag ordering, I think this being a link unit global setting should be appended before the OS and TOOLCHAIN specific flags above. make/hotspot/lib/JvmFeatures.gmk line 186: > 184: else ifeq ($(call isCompiler, microsoft), true) > 185: JVM_CFLAGS_FEATURES += $(CXX_O_FLAG_LTO) > 186: JVM_LDFLAGS_FEATURES += $(LDFLAGS_LTO) Now that we have variables for LTO flags, we shouldn't need compiler type checks for adding them. We can keep the conditionals for the other flags, but adding LTO flags looks compiler agnostic. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2495462638 PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2495525800 PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2495534912 PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2495546178 From prr at openjdk.org Wed Nov 5 17:49:22 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 5 Nov 2025 17:49:22 GMT Subject: RFR: 8371066: Remove unused class TextSourceLabel and associated class hierarchy In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 17:17:06 GMT, Daniel Gredler wrote: > The class `TextSourceLabel` is unused, as is the associated factory method `TextLabelFactory.createSimple(...)`. > > The abstractions provided by the abstract classes `TextLabel` and `ExtendedTextLabel` only make sense when there are two types of text labels (`TextSourceLabel` and `ExtendedTextSourceLabel`). With the deletion of `TextSourceLabel`, both `TextLabel` and `ExtendedTextLabel` can also be removed. > > The JavaDoc for the abstract methods in `TextLabel` and `ExtendedTextLabel`, which are implemented in `ExtendedTextSourceLabel`, was moved to `ExtendedTextSourceLabel` prior to the deletion of these two classes. > > The few small convenience methods in `TextLabel` and `ExtendedTextLabel` were also moved to `ExtendedTextSourceLabel` prior to the deletion of these two classes. > > I would have liked to give the combined `TextLabel` + `ExtendedTextLabel` + `ExtendedTextSourceLabel` class the name `TextLabel`, but I've used `ExtendedTextSourceLabel` instead because it makes the diff much smaller and maximizes code history traceability. > > See initial mailing list discussion: https://mail.openjdk.org/pipermail/client-libs-dev/2025-September/032302.html Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28090#pullrequestreview-3423551648 From honkar at openjdk.org Wed Nov 5 17:54:30 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 5 Nov 2025 17:54:30 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v4] In-Reply-To: References: Message-ID: > `findComponent(final Container container, final Predicate predicate)` is a useful utility method and thus added to` javax/swing/regtesthelpers/Util.java` instead of having redundant code in tests. It can be used to find a component by label name. > > PS: Existing `Util.findSubComponent()` finds component by class name but `findComponent()` can be used to search for a particular component by label name/title when there are multiple subcomponents of same type by applying a predicate logic. Harshitha Onkar has updated the pull request incrementally with two additional commits since the last revision: - indentation - Util changes and revert test changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27944/files - new: https://git.openjdk.org/jdk/pull/27944/files/cec6a0ca..0eef08de Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27944&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27944&range=02-03 Stats: 78 lines in 3 files changed: 33 ins; 27 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/27944.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27944/head:pull/27944 PR: https://git.openjdk.org/jdk/pull/27944 From honkar at openjdk.org Wed Nov 5 17:58:05 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 5 Nov 2025 17:58:05 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v5] In-Reply-To: References: Message-ID: > `findComponent(final Container container, final Predicate predicate)` is a useful utility method and thus added to` javax/swing/regtesthelpers/Util.java` instead of having redundant code in tests. It can be used to find a component by label name. > > PS: Existing `Util.findSubComponent()` finds component by class name but `findComponent()` can be used to search for a particular component by label name/title when there are multiple subcomponents of same type by applying a predicate logic. Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: indentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27944/files - new: https://git.openjdk.org/jdk/pull/27944/files/0eef08de..16a3770c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27944&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27944&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27944.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27944/head:pull/27944 PR: https://git.openjdk.org/jdk/pull/27944 From honkar at openjdk.org Wed Nov 5 18:02:26 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 5 Nov 2025 18:02:26 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v3] In-Reply-To: References: <8uTT1OhvToiXCQKK9gV6ug-_NnXufFjOOkBhrtRhg80=.6d333ab1-c47b-480f-8273-befe3af559fe@github.com> <6ymiIfr6yBXzVnHxqk8sDsV1KyAJWHjQhZcpNkh02vs=.1cb647a3-c610-436d-8045-8292902021aa@github.com> Message-ID: <1l1kAeBi1gtBkca3tQYEChmegyC6Fse9PJJfw63PDaY=.6018a20c-59ef-45fb-9f35-99b60c0612c5@github.com> On Tue, 4 Nov 2025 13:55:19 GMT, Alexey Ivanov wrote: >> Any reason for updating the test files with this PR ? I feel this PR should be restricted to Util file updates alone, updating the test files can be taken up separately. > >> Any reason for updating the test files with this PR ? I feel this PR should be restricted to Util file updates alone, updating the test files can be taken up separately. > > This is a valid concern. I tend to agree. The test from which the `findComponent` method is moved to the `Util` class, `javax/swing/JFileChooser/FileSizeCheck.java`, isn't backported to any releases. Yet I expect this change to `Util` would be backported to all the supported releases. > > This is why I suggest submitting a new bug to update `FileSizeCheck.java`. (That new bug would be backported to 21u where the test `FileSizeCheck.java` exists.) > > Similarly, as [I just mentioned](https://github.com/openjdk/jdk/pull/27944#discussion_r2490547507), it makes sense to update `javax/swing/JFileChooser/bug4759934.java` in its own issue to keep the history clearer. Especially, if we replace all button clicks with programmatic `doClick` instead of using robot. @aivanov-jdk As suggested I'll be creating separate PRs for test changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27944#issuecomment-3492618889 From honkar at openjdk.org Wed Nov 5 18:02:29 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 5 Nov 2025 18:02:29 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v5] In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 14:01:16 GMT, Alexey Ivanov wrote: >> I also suggest calling `findComponent` instead of `findComponentImpl` ? then you can remove the line *?Always run this method on the EDT thread?* from the javadoc comment. >> >> Also, change ?a sub component? to ?a subcomponent?. > >> It fails because the code I proposed is plainly wrong. >> >> ```java >> public static Component findSubComponent(Component parent, String className) { >> return findComponentImpl((Container) parent, >> c -> c.getClass().getName().contains(className)); >> } >> ``` > > This time I tested the above code by running the following tests `test/jdk/javax/swing/JFileChooser/FileChooserToolTipTest.java test/jdk/javax/swing/JFileChooser/FCPopupMenuOrientationTest.java` which use `Util.findSubComponent` and the tests passed for me. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2495585933 From aivanov at openjdk.org Wed Nov 5 18:07:11 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 5 Nov 2025 18:07:11 GMT Subject: RFR: 8370637: [Windows] Crash if use Graphics after PrintJob.end [v5] In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 00:22:18 GMT, Phil Race wrote: >> Synchronize WPrinterJob calls which use the printDC to avoid crash in case of mis-use. >> The printerDC is released when the job ends. >> It is zero-ed out in the handle in which it is stored >> The calls which expect it to be valid now all check for zero and return if it is zero. >> The calls are made synchronized as is the call to endDoc which zeroes it, so that they cannot have it zeroed out whilst using it. >> >> The tests are the same as in the fix for JDK-8370141 which is also under review. >> Which ever is 2nd to be pushed will have to merge in the changes from the first > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8370637 Marked as reviewed by aivanov (Reviewer). src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java line 1102: > 1100: > 1101: protected synchronized void fillRect(float x, float y, float width, float height, > 1102: Color color) { Suggestion: protected synchronized void fillRect(float x, float y, float width, float height, Color color) { Restore alignment for the `color` argument. There are other similar cases which IDE could quickly update. src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java line 1450: > 1448: * StartPage routine. > 1449: */ > 1450: protected synchronized native void deviceStartPage(PageFormat format, Printable painter, This line is now longer than 80 columns (it's 93 to be precise). ------------- PR Review: https://git.openjdk.org/jdk/pull/27984#pullrequestreview-3423603468 PR Review Comment: https://git.openjdk.org/jdk/pull/27984#discussion_r2495583486 PR Review Comment: https://git.openjdk.org/jdk/pull/27984#discussion_r2495595975 From prr at openjdk.org Wed Nov 5 18:18:27 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 5 Nov 2025 18:18:27 GMT Subject: RFR: 8370637: [Windows] Crash if use Graphics after PrintJob.end [v6] In-Reply-To: References: Message-ID: > Synchronize WPrinterJob calls which use the printDC to avoid crash in case of mis-use. > The printerDC is released when the job ends. > It is zero-ed out in the handle in which it is stored > The calls which expect it to be valid now all check for zero and return if it is zero. > The calls are made synchronized as is the call to endDoc which zeroes it, so that they cannot have it zeroed out whilst using it. > > The tests are the same as in the fix for JDK-8370141 which is also under review. > Which ever is 2nd to be pushed will have to merge in the changes from the first Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8370637 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27984/files - new: https://git.openjdk.org/jdk/pull/27984/files/dbd0a850..34a4cf49 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27984&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27984&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27984.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27984/head:pull/27984 PR: https://git.openjdk.org/jdk/pull/27984 From azvegint at openjdk.org Wed Nov 5 18:18:28 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 5 Nov 2025 18:18:28 GMT Subject: RFR: 8370637: [Windows] Crash if use Graphics after PrintJob.end [v6] In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 18:14:52 GMT, Phil Race wrote: >> Synchronize WPrinterJob calls which use the printDC to avoid crash in case of mis-use. >> The printerDC is released when the job ends. >> It is zero-ed out in the handle in which it is stored >> The calls which expect it to be valid now all check for zero and return if it is zero. >> The calls are made synchronized as is the call to endDoc which zeroes it, so that they cannot have it zeroed out whilst using it. >> >> The tests are the same as in the fix for JDK-8370141 which is also under review. >> Which ever is 2nd to be pushed will have to merge in the changes from the first > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8370637 Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27984#pullrequestreview-3423662120 From prr at openjdk.org Wed Nov 5 18:33:20 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 5 Nov 2025 18:33:20 GMT Subject: RFR: 8368729: Add appropriate checks in java.awt.image.Kernel constructor In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 09:35:32 GMT, Jayathirth D V wrote: > `java.awt.image.Kernel` constructor doesn't validate all input values and we need to add appropriate checks. > A new test is also added to make sure we appropriate exception when invalid values are passed. > > This will also need a CSR. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28127#pullrequestreview-3423724452 From aivanov at openjdk.org Wed Nov 5 18:42:15 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 5 Nov 2025 18:42:15 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v5] In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 17:58:05 GMT, Harshitha Onkar wrote: >> `findComponent(final Container container, final Predicate predicate)` is a useful utility method and thus added to` javax/swing/regtesthelpers/Util.java` instead of having redundant code in tests. It can be used to find a component by label name. >> >> PS: Existing `Util.findSubComponent()` finds component by class name but `findComponent()` can be used to search for a particular component by label name/title when there are multiple subcomponents of same type by applying a predicate logic. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > indentation Changes requested by aivanov (Reviewer). test/jdk/javax/swing/regtesthelpers/Util.java line 147: > 145: */ > 146: public static Component findSubComponent(Component parent, String className) { > 147: return findComponentImpl((Container) parent, To guarantee, it's run on EDT, you have to call `findComponent`. test/jdk/javax/swing/regtesthelpers/Util.java line 324: > 322: Box buttonBox = Box.createHorizontalBox(); > 323: JButton passButton = new JButton("Pass"); > 324: JButton failButton = new JButton("Fail"); I'd leave these lines untouched. Usages of `createModalDialogWithPassFailButtons` could be replaced with `PassFailJFrame` for consistency. It's out of scope. ------------- PR Review: https://git.openjdk.org/jdk/pull/27944#pullrequestreview-3423742869 PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2495689923 PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2495697707 From prr at openjdk.org Wed Nov 5 18:55:30 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 5 Nov 2025 18:55:30 GMT Subject: Integrated: 8370637: [Windows] Crash if use Graphics after PrintJob.end In-Reply-To: References: Message-ID: <-m-vw-iUdZbNKGQCGECmIdFzUTeoEJdvv15G706ouK4=.19b72044-0063-4efa-9414-045346d83254@github.com> On Fri, 24 Oct 2025 22:03:13 GMT, Phil Race wrote: > Synchronize WPrinterJob calls which use the printDC to avoid crash in case of mis-use. > The printerDC is released when the job ends. > It is zero-ed out in the handle in which it is stored > The calls which expect it to be valid now all check for zero and return if it is zero. > The calls are made synchronized as is the call to endDoc which zeroes it, so that they cannot have it zeroed out whilst using it. > > The tests are the same as in the fix for JDK-8370141 which is also under review. > Which ever is 2nd to be pushed will have to merge in the changes from the first This pull request has now been integrated. Changeset: 7d93cb73 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/7d93cb73c45d393705504f0637b12512124923a1 Stats: 206 lines in 4 files changed: 126 ins; 0 del; 80 mod 8370637: [Windows] Crash if use Graphics after PrintJob.end Reviewed-by: azvegint, psadhukhan, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/27984 From duke at openjdk.org Wed Nov 5 18:57:38 2025 From: duke at openjdk.org (Dmitry Kulikov) Date: Wed, 5 Nov 2025 18:57:38 GMT Subject: Integrated: 8360120: Bundled macOS applications not receiving OpenURL events when launched as subprocess In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 05:14:11 GMT, Dmitry Kulikov wrote: > Added an on-demand installation of the native OpenURL event handler to the `Application.setOpenURIHandler()`. > > This does not break the specification for the affected API, since the requirement of the application being bundled and containing `CFBundleURLTypes` in the `Info.plist` is still valid: macOS will neither launch nor send OpenURL events to an application that does not declare such capabilities it the bundle. > > Running tests on macOS showed no regressions after this patch. Other platforms are not affected. This pull request has now been integrated. Changeset: 2872f815 Author: Dmitry Kulikov Committer: Phil Race URL: https://git.openjdk.org/jdk/commit/2872f815fdbe4a84bbec1cd910e81e2e21fffbdf Stats: 41 lines in 3 files changed: 32 ins; 3 del; 6 mod 8360120: Bundled macOS applications not receiving OpenURL events when launched as subprocess Reviewed-by: kizune, prr ------------- PR: https://git.openjdk.org/jdk/pull/25967 From prr at openjdk.org Wed Nov 5 18:58:38 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 5 Nov 2025 18:58:38 GMT Subject: Integrated: 8368576: PrintJob.getGraphics() does not specify behavior after PrintJob.end() In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 16:43:13 GMT, Phil Race wrote: > Update the spec. of java.awt.PrintJob.getGraphics() to document long standing behaviour after PrintJob.end() has been called. > > A CSR has been created https://bugs.openjdk.org/browse/JDK-8368577 This pull request has now been integrated. Changeset: 5a37374d Author: Phil Race URL: https://git.openjdk.org/jdk/commit/5a37374dcaae0d3939570b33418f772a901df21a Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8368576: PrintJob.getGraphics() does not specify behavior after PrintJob.end() Reviewed-by: psadhukhan, tr, serb ------------- PR: https://git.openjdk.org/jdk/pull/27474 From jwood at openjdk.org Wed Nov 5 19:00:47 2025 From: jwood at openjdk.org (Jeremy Wood) Date: Wed, 5 Nov 2025 19:00:47 GMT Subject: Integrated: 8357034: GifImageDecoder can produce wrong transparent pixels In-Reply-To: References: Message-ID: <8tDVgtuUFaL08gmGs-e99Tw2zaqOci1F7NoajVmwq5c=.0288e84b-7fc7-4074-9c3b-e1b576be2416@github.com> On Fri, 16 May 2025 10:26:47 GMT, Jeremy Wood wrote: > If there are two consecutive frames that use DISPOSAL_SAVE, but the transparent pixel index changed: we might accidentally send the wrong data to the ImageConsumer. > > We already had logic that submits info "the hard way" (see comment in code); this PR just makes sure we trigger that block. > > There are a cluster of four related PRs that share the GifComparison class in this PR. > > 1. [8357034](https://github.com/openjdk/jdk/pull/25264) (this one) > 2. ~~[8356137](https://github.com/openjdk/jdk/pull/25044)~~ (integrated) > 3. [8356320](https://github.com/openjdk/jdk/pull/25076) > 4. [8351913](https://github.com/openjdk/jdk/pull/24271) > > This bug can be observed reading these gif animations: > > https://giphy.com/gifs/fomoduck-duck-fomo-ZUlzR40oGACqNmy0q8 > https://media4.giphy.com/media/Zbf4JQzcDhzeraQvk9/giphy.gif > https://giphy.com/gifs/computer-working-cat-LHZyixOnHwDDy > https://giphy.com/gifs/90s-fgfgif-r4BmI9xUaDuKJQdd3l > > ### Describing This Bug > > The steps/explanation that lead to this failure are a little complicated. I'll try to summarize the original bug here. > > All three frames in the unit test's GIF use disposal code doNotDispose, meaning the frames are layered one on top of the previous. > > The first frame produces 3 circles from left to right using these colors: > 0xff0000 (red) 0xffff00 (yellow) 0x00ff00 (green) > > The background is 0x00ffff (cyan). It is the transparent pixel, so the first frame is: > > frame_0 > > Now we start processing the second frame. The pixels are the same, but the color model has changed so the zeroeth color (red) is the transparent index. > > When the GifImageDecoder layers the 2nd frame on top of the 1st frame, it notices that `model.equals(saved_model)` is `false`. This means it enter a block of code that refers to "the hard way" of passing new pixel information to the ImageConsumers. > > The 2nd frame, after being painted on the 1st frame, looks like: > frame_1 > ? > The 3rd frame is exactly the same as the 2nd. But here's where the bug is: now `model.equals(saved_model)` is `true`, so GifImageDecoder tries to pass the pixel information the easy way. The result is: > > frame_2_awt > > Because it'... This pull request has now been integrated. Changeset: acc8a76d Author: Jeremy Wood Committer: Phil Race URL: https://git.openjdk.org/jdk/commit/acc8a76db2314211dd29a5b84c5bbe73d9055c76 Stats: 147 lines in 5 files changed: 112 ins; 4 del; 31 mod 8357034: GifImageDecoder can produce wrong transparent pixels Reviewed-by: jdv, prr ------------- PR: https://git.openjdk.org/jdk/pull/25264 From honkar at openjdk.org Wed Nov 5 19:03:23 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 5 Nov 2025 19:03:23 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v6] In-Reply-To: References: Message-ID: <4Yy1FYVHwxACErG90M6hVNgB4TAYa9xcgZgWb_EbDfo=.35677f94-c910-455e-be3f-e81299076e8e@github.com> > `findComponent(final Container container, final Predicate predicate)` is a useful utility method and thus added to` javax/swing/regtesthelpers/Util.java` instead of having redundant code in tests. It can be used to find a component by label name. > > PS: Existing `Util.findSubComponent()` finds component by class name but `findComponent()` can be used to search for a particular component by label name/title when there are multiple subcomponents of same type by applying a predicate logic. Harshitha Onkar has updated the pull request incrementally with two additional commits since the last revision: - revert unchanged lines - review update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27944/files - new: https://git.openjdk.org/jdk/pull/27944/files/16a3770c..13736446 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27944&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27944&range=04-05 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27944.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27944/head:pull/27944 PR: https://git.openjdk.org/jdk/pull/27944 From honkar at openjdk.org Wed Nov 5 19:03:25 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 5 Nov 2025 19:03:25 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v5] In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 18:36:35 GMT, Alexey Ivanov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> indentation > > test/jdk/javax/swing/regtesthelpers/Util.java line 147: > >> 145: */ >> 146: public static Component findSubComponent(Component parent, String className) { >> 147: return findComponentImpl((Container) parent, > > To guarantee, it's run on EDT, you have to call `findComponent`. Oh, missed it earlier. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2495747144 From aivanov at openjdk.org Wed Nov 5 21:47:03 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 5 Nov 2025 21:47:03 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v6] In-Reply-To: <4Yy1FYVHwxACErG90M6hVNgB4TAYa9xcgZgWb_EbDfo=.35677f94-c910-455e-be3f-e81299076e8e@github.com> References: <4Yy1FYVHwxACErG90M6hVNgB4TAYa9xcgZgWb_EbDfo=.35677f94-c910-455e-be3f-e81299076e8e@github.com> Message-ID: On Wed, 5 Nov 2025 19:03:23 GMT, Harshitha Onkar wrote: >> `findComponent(final Container container, final Predicate predicate)` is a useful utility method and thus added to` javax/swing/regtesthelpers/Util.java` instead of having redundant code in tests. It can be used to find a component by label name. >> >> PS: Existing `Util.findSubComponent()` finds component by class name but `findComponent()` can be used to search for a particular component by label name/title when there are multiple subcomponents of same type by applying a predicate logic. > > Harshitha Onkar has updated the pull request incrementally with two additional commits since the last revision: > > - revert unchanged lines > - review update Looks good to me, except for minor formatting nit. test/jdk/javax/swing/regtesthelpers/Util.java line 150: > 148: c -> c.getClass() > 149: .getName() > 150: .contains(className)); Suggestion: return findComponent((Container) parent, c -> c.getClass() .getName() .contains(className)); Correct alignment. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27944#pullrequestreview-3424579183 PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2496280401 From honkar at openjdk.org Wed Nov 5 22:11:03 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 5 Nov 2025 22:11:03 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v3] In-Reply-To: References: <8uTT1OhvToiXCQKK9gV6ug-_NnXufFjOOkBhrtRhg80=.6d333ab1-c47b-480f-8273-befe3af559fe@github.com> Message-ID: <4ZMPZwaW_pv8Fuj7HoziY_srmErdR6wffknz-lQK1mc=.e2be4c5f-3009-4ba1-8738-4fb842420fe4@github.com> On Tue, 4 Nov 2025 13:36:39 GMT, Alexey Ivanov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> Review changes: EDT check > > test/jdk/javax/swing/JFileChooser/bug4759934.java line 74: > >> 72: robot.mousePress(MouseEvent.BUTTON1_DOWN_MASK); >> 73: robot.mouseRelease(MouseEvent.BUTTON1_DOWN_MASK); >> 74: robot.delay(500); > > All the clicks above are to click a button? Should we replace these clicks with programmatic clicks? > > However, I'd like to ensure the updated test still reproduces the original bug. Updating this test could better pull out into its own issue. (Yes, I remember that this refactoring comes from an internal comment I made when `javax/swing/JFileChooser/bug4759934.java` was open-sourced.) I'll be updating the tests in another PR. To answer your question. > All the clicks above are to click a button? Should we replace these clicks with programmatic clicks? I'm for keeping the other clicks as-is (via Robot) since we have reference to these buttons unlike the cancel button of JFileChooser and this way we keep much of the original test case intact without overly modifying it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2496343433 From kizune at openjdk.org Wed Nov 5 22:28:01 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 5 Nov 2025 22:28:01 GMT Subject: RFR: 8368729: Add appropriate checks in java.awt.image.Kernel constructor In-Reply-To: References: Message-ID: <0sUjMEnM8uERhfgjZAopImWPQpi5HqDfyUuS92HxT0c=.8dd09ff1-a3a6-43ef-b553-e00457010f24@github.com> On Tue, 4 Nov 2025 09:35:32 GMT, Jayathirth D V wrote: > `java.awt.image.Kernel` constructor doesn't validate all input values and we need to add appropriate checks. > A new test is also added to make sure we appropriate exception when invalid values are passed. > > This will also need a CSR. Marked as reviewed by kizune (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28127#pullrequestreview-3424748369 From serb at openjdk.org Wed Nov 5 23:53:06 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 5 Nov 2025 23:53:06 GMT Subject: RFR: 8368729: Add appropriate checks in java.awt.image.Kernel constructor In-Reply-To: References: Message-ID: <7DpQRTNILJjPS0vCTMv1_EYUUYn_L797H-15bvDnQuk=.7d607f81-0477-4aab-a0d3-86624ba7508d@github.com> On Tue, 4 Nov 2025 09:35:32 GMT, Jayathirth D V wrote: > `java.awt.image.Kernel` constructor doesn't validate all input values and we need to add appropriate checks. > A new test is also added to make sure we appropriate exception when invalid values are passed. > > This will also need a CSR. src/java.desktop/share/classes/java/awt/image/Kernel.java line 62: > 60: * @param height height of the kernel > 61: * @param data kernel data in row major order > 62: * @throws IllegalArgumentException if {@code data} is null Is there any particular reason why IllegalArgumentException was chosen instead of NullPointerException? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28127#discussion_r2496550441 From serb at openjdk.org Thu Nov 6 00:16:05 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 6 Nov 2025 00:16:05 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v9] In-Reply-To: References: <1nxKOtN4B2h026FhyQp8t-1IOZBFPMfnif7I5a0Vnuc=.9ffffa12-226f-49ac-8b85-fac3750c649f@github.com> <3hw1X_jGyDqVuyleOkeirF2hj4ZnfuBPoG9J-e4Rw50=.914a54f6-f2f8-491d-b2af-e84dfdc5967b@github.com> Message-ID: On Wed, 5 Nov 2025 17:11:34 GMT, Damon Nguyen wrote: >I don't see why it wouldn't be possible to make changes to the implementation of the mouse movement. I have already looked at the API you described for mouse movement, and the implementation there is not too different. That sounds good. Are there any blockers to implementing it in the current patch? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26969#issuecomment-3494182342 From honkar at openjdk.org Thu Nov 6 01:01:41 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 6 Nov 2025 01:01:41 GMT Subject: RFR: JDK-8371364 : Refactor javax/swing/JFileChooser/FileSizeCheck.java to use Util.findComponent() Message-ID: <1-YFX00LL6t9o8Z3uYzzTszxcSXWMX9LxR3uw9Sbwtw=.14d4a5c0-0d2a-4105-9b77-a98bfd40366d@github.com> FileSizeCheck.java test changes related to addition of new method to Util - https://github.com/openjdk/jdk/pull/27944. ------------- Commit messages: - test update Changes: https://git.openjdk.org/jdk/pull/28168/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28168&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371364 Stats: 22 lines in 1 file changed: 2 ins; 17 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28168.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28168/head:pull/28168 PR: https://git.openjdk.org/jdk/pull/28168 From honkar at openjdk.org Thu Nov 6 01:06:00 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 6 Nov 2025 01:06:00 GMT Subject: RFR: JDK-8371364 : Refactor javax/swing/JFileChooser/FileSizeCheck.java to use Util.findComponent() In-Reply-To: <1-YFX00LL6t9o8Z3uYzzTszxcSXWMX9LxR3uw9Sbwtw=.14d4a5c0-0d2a-4105-9b77-a98bfd40366d@github.com> References: <1-YFX00LL6t9o8Z3uYzzTszxcSXWMX9LxR3uw9Sbwtw=.14d4a5c0-0d2a-4105-9b77-a98bfd40366d@github.com> Message-ID: On Thu, 6 Nov 2025 00:54:45 GMT, Harshitha Onkar wrote: > FileSizeCheck.java test changes related to addition of new method to Util - https://github.com/openjdk/jdk/pull/27944. @aivanov-jdk @TejeshR13 Please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/28168#issuecomment-3494336532 From honkar at openjdk.org Thu Nov 6 01:07:12 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 6 Nov 2025 01:07:12 GMT Subject: RFR: JDK-8371365 : Update /javax/swing/JFileChooser/bug4759934.java to use Util.findComponent() Message-ID: /javax/swing/JFileChooser/bug4759934.java test changes related to addition of new method to Util - https://github.com/openjdk/jdk/pull/27944. ------------- Commit messages: - test update Changes: https://git.openjdk.org/jdk/pull/28169/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28169&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371365 Stats: 13 lines in 1 file changed: 11 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28169.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28169/head:pull/28169 PR: https://git.openjdk.org/jdk/pull/28169 From honkar at openjdk.org Thu Nov 6 01:07:12 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 6 Nov 2025 01:07:12 GMT Subject: RFR: JDK-8371365 : Update /javax/swing/JFileChooser/bug4759934.java to use Util.findComponent() In-Reply-To: References: Message-ID: On Thu, 6 Nov 2025 01:00:43 GMT, Harshitha Onkar wrote: > /javax/swing/JFileChooser/bug4759934.java test changes related to addition of new method to Util - https://github.com/openjdk/jdk/pull/27944. @aivanov-jdk @TejeshR13 Please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/28169#issuecomment-3494336221 From honkar at openjdk.org Thu Nov 6 01:10:48 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 6 Nov 2025 01:10:48 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v7] In-Reply-To: References: Message-ID: > `findComponent(final Container container, final Predicate predicate)` is a useful utility method and thus added to` javax/swing/regtesthelpers/Util.java` instead of having redundant code in tests. It can be used to find a component by label name. > > PS: Existing `Util.findSubComponent()` finds component by class name but `findComponent()` can be used to search for a particular component by label name/title when there are multiple subcomponents of same type by applying a predicate logic. Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: spacing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27944/files - new: https://git.openjdk.org/jdk/pull/27944/files/13736446..9bf19261 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27944&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27944&range=05-06 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27944.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27944/head:pull/27944 PR: https://git.openjdk.org/jdk/pull/27944 From honkar at openjdk.org Thu Nov 6 01:22:04 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 6 Nov 2025 01:22:04 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v7] In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 07:11:21 GMT, Prasanta Sadhukhan wrote: >> If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder` >> it throws NPE which is not mentioned in the spec as the expected outcome. >> Fixed the NPE and the spec > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > javadoc update LGTM. You can also add a case in the test for BevelBorder.LOWERED for completeness. ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27949#pullrequestreview-3425227889 From jwood at openjdk.org Thu Nov 6 04:23:50 2025 From: jwood at openjdk.org (Jeremy Wood) Date: Thu, 6 Nov 2025 04:23:50 GMT Subject: RFR: 8351913: ToolkitImage renders some gifs wrong [v9] In-Reply-To: <74IJiA4t9MAOiGPCGuls0-KbIfGg9D2bNUXPapOx0Zs=.4cdf9b89-4007-4727-a07e-ac4eae84134e@github.com> References: <74IJiA4t9MAOiGPCGuls0-KbIfGg9D2bNUXPapOx0Zs=.4cdf9b89-4007-4727-a07e-ac4eae84134e@github.com> Message-ID: > I do not have much background in LZW compression or in C, but I'm reasonably confident this resolves the problem I'm observing. It looks like the GifImageDecoder was not always correctly handling compression codes after the table reached its limit of ~4096. If anyone has suggestions for improvements I'm happy to make adjustments. > > Luckily while debugging this: I was able to compare the flawed implementation (GifImageDecoder) with ImageIO's implementation (GIFImageReader) to help identify how the suffix/prefix tables are supposed to work. > > ImageIO's implementation may have suffered a similar bug (maybe https://bugs.openjdk.org/browse/JDK-7131823 ?), and that appears to have been backported. > > There are a cluster of four related PRs that share the GifComparison class in this PR. > > 1. ~~[8357034](https://github.com/openjdk/jdk/pull/25264)~~ (integrated) > 2. ~~[8356137](https://github.com/openjdk/jdk/pull/25044)~~ (integrated) > 3. [8356320](https://github.com/openjdk/jdk/pull/25076) > 4. [8351913](https://github.com/openjdk/jdk/pull/24271) (this one) > > This bug can be observed reading these gif animations: > https://pixabay.com/gifs/pattern-mandela-geometric-loading-20162/ > https://pixabay.com/gifs/colourful-paint-spiral-pattern-20276/ > https://pixabay.com/gifs/dance-party-dancer-dancing-girl-19993/ > https://pixabay.com/gifs/spiral-orbit-colourful-pattern-20278/ > https://pixabay.com/gifs/flower-smiley-happy-yellow-bright-11997/ > https://pixabay.com/gifs/ghost-spooky-halloween-horror-20223/ > https://pixabay.com/gifs/fish-tadpole-sperm-decorative-20078/ > https://pixabay.com/gifs/cat-kitten-black-cats-sleep-nap-20104/ > https://giphy.com/gifs/party-gzhreEYEFrEYw > https://giphy.com/gifs/hello-happy-birthday-all-xRVUlSCqTTZRLMdUiC > https://giphy.com/gifs/GpANv0ZGOo973DNPyg > https://giphy.com/gifs/pinatafarmsapp-birthday-happy-pinata-farms-rrmf3fICPZWg1MMXOW > https://pixabay.com/gifs/stars-twinkle-sky-universe-cosmos-13910/ > https://pixabay.com/gifs/laundry-washing-clean-clothes-18875/ > https://giphy.com/gifs/cat-white-mikitti-VItynXR1BzF5z0aTM7 > https://giphy.com/gifs/love-good-morning-cute-sTuKV3kHCkuc1hzd5C > https://giphy.com/gifs/tv2norge-dance-celebration-birthday-duNowzaVje6Di3hnOu > https://tenor.com/view/hasher-sticker-gif-24531859 > https://giphy.com/gifs/animanias-emoji-mickey-mouse-minnie-BeiTtDrExJZsoHzglJ > https://giphy.com/gifs/morning-good-gm-dvwk9tqWYN8Wn2s4yn > https://giphy.com/gifs/memoriachilena-familia-memoria-chilena-patrimonio-cultural-comn-7rRmOg13aXImUOEhO7 > https://giphy.co... Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits: - 8351913: resolving compiler error introduced with latest merge In other related tickets: we added a directory in which we can write the gif frames to visually inspect each frame. - Merge branch 'master' into JDK-8351913 - Merge branch 'master' into JDK-8351913 - 8351913: re-wrapping line breaks - Merge branch 'master' into JDK-8351913 # Conflicts: # test/jdk/sun/awt/image/gif/GifComparison.java - Merge branch 'master' into JDK-8351913 - 8356137: Adding copyright to GifComparison - 8356320: trivial whitespace and comment changes - Merge branch 'master' into JDK-8351913 - Merge branch 'master' of https://github.com/mickleness/jdk - ... and 26 more: https://git.openjdk.org/jdk/compare/acc8a76d...c3f78a51 ------------- Changes: https://git.openjdk.org/jdk/pull/24271/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24271&range=08 Stats: 61 lines in 4 files changed: 55 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/24271.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24271/head:pull/24271 PR: https://git.openjdk.org/jdk/pull/24271 From smandalika at openjdk.org Thu Nov 6 05:02:04 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Thu, 6 Nov 2025 05:02:04 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update [v4] In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 16:17:14 GMT, Srinivas Mandalika wrote: >> Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java >> Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Fixed whitepsace error. Can someone take a quick look and provide feedback on this simple instruction update MR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27139#issuecomment-3495071410 From tr at openjdk.org Thu Nov 6 07:07:03 2025 From: tr at openjdk.org (Tejesh R) Date: Thu, 6 Nov 2025 07:07:03 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v7] In-Reply-To: References: Message-ID: <534X0yuIBdiPiqnt2pnbpa-6Tae29Hj17zH6CAsg9lM=.a1accbac-ae8c-4d73-be66-6780243b75c9@github.com> On Thu, 6 Nov 2025 01:10:48 GMT, Harshitha Onkar wrote: >> `findComponent(final Container container, final Predicate predicate)` is a useful utility method and thus added to` javax/swing/regtesthelpers/Util.java` instead of having redundant code in tests. It can be used to find a component by label name. >> >> PS: Existing `Util.findSubComponent()` finds component by class name but `findComponent()` can be used to search for a particular component by label name/title when there are multiple subcomponents of same type by applying a predicate logic. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > spacing LGTM. ------------- Marked as reviewed by tr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27944#pullrequestreview-3426531038 From psadhukhan at openjdk.org Thu Nov 6 07:45:30 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 6 Nov 2025 07:45:30 GMT Subject: RFR: 8371163: Make GlyphView/TestGlyphBGHeight.java headless Message-ID: Test is made headless ------------- Commit messages: - 8371163: Make GlyphView/TestGlyphBGHeight.java headless Changes: https://git.openjdk.org/jdk/pull/28173/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28173&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371163 Stats: 66 lines in 1 file changed: 15 ins; 22 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/28173.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28173/head:pull/28173 PR: https://git.openjdk.org/jdk/pull/28173 From jdv at openjdk.org Thu Nov 6 08:48:08 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 6 Nov 2025 08:48:08 GMT Subject: RFR: 8368729: Add appropriate checks in java.awt.image.Kernel constructor In-Reply-To: <7DpQRTNILJjPS0vCTMv1_EYUUYn_L797H-15bvDnQuk=.7d607f81-0477-4aab-a0d3-86624ba7508d@github.com> References: <7DpQRTNILJjPS0vCTMv1_EYUUYn_L797H-15bvDnQuk=.7d607f81-0477-4aab-a0d3-86624ba7508d@github.com> Message-ID: <_94TDObFPwQ6uoerq8PSnI7OR0ge67DfdHGbfACo5Gw=.9814805f-2a6c-432a-9535-88711f12d042@github.com> On Wed, 5 Nov 2025 23:50:45 GMT, Sergey Bylokhov wrote: >> `java.awt.image.Kernel` constructor doesn't validate all input values and we need to add appropriate checks. >> A new test is also added to make sure we appropriate exception when invalid values are passed. >> >> This will also need a CSR. > > src/java.desktop/share/classes/java/awt/image/Kernel.java line 62: > >> 60: * @param height height of the kernel >> 61: * @param data kernel data in row major order >> 62: * @throws IllegalArgumentException if {@code data} is null > > Is there any particular reason why IllegalArgumentException was chosen instead of NullPointerException? Spec of NPE states multiple reasons of when an NPE is thrown while using null object and IAE clearly mentions that we are trying to validate input arguments and throw it when we see any issue. Current spec already throws IAE in one of the validation scenario, so throwing the same IAE for other input argument validation is uniform. We can say that in other parts of JDK we throw NPE for null argument verification, but using IAE in this scenario looks better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28127#discussion_r2498039966 From mbaesken at openjdk.org Thu Nov 6 09:00:13 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 6 Nov 2025 09:00:13 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v5] In-Reply-To: <31uD61UWj2KbHHXtP8wsSHHbAAraD1MRQPpVrxKse8Q=.1037cea5-a914-46fd-b481-1cc72bbef719@github.com> References: <31uD61UWj2KbHHXtP8wsSHHbAAraD1MRQPpVrxKse8Q=.1037cea5-a914-46fd-b481-1cc72bbef719@github.com> Message-ID: <2xxNnTYM_sGTOtbEafbA6GDVO1Qy2WOs2midOMhBMIs=.4e1c8ee1-c75f-4d41-8e19-75987fca5b92@github.com> On Wed, 5 Nov 2025 17:45:56 GMT, Erik Joelsson wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Use lto configure flags in hs build > > make/hotspot/lib/JvmFeatures.gmk line 186: > >> 184: else ifeq ($(call isCompiler, microsoft), true) >> 185: JVM_CFLAGS_FEATURES += $(CXX_O_FLAG_LTO) >> 186: JVM_LDFLAGS_FEATURES += $(LDFLAGS_LTO) > > Now that we have variables for LTO flags, we shouldn't need compiler type checks for adding them. We can keep the conditionals for the other flags, but adding LTO flags looks compiler agnostic. We still add CXX_O_FLAG_HIGHEST_JVM to the JVM_LDFLAGS_FEATURES for gcc/clang , but not for msvc. Not sure why. So there is still a bit of difference between compilers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2498082307 From jwaters at openjdk.org Thu Nov 6 09:12:03 2025 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 6 Nov 2025 09:12:03 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v5] In-Reply-To: <2xxNnTYM_sGTOtbEafbA6GDVO1Qy2WOs2midOMhBMIs=.4e1c8ee1-c75f-4d41-8e19-75987fca5b92@github.com> References: <31uD61UWj2KbHHXtP8wsSHHbAAraD1MRQPpVrxKse8Q=.1037cea5-a914-46fd-b481-1cc72bbef719@github.com> <2xxNnTYM_sGTOtbEafbA6GDVO1Qy2WOs2midOMhBMIs=.4e1c8ee1-c75f-4d41-8e19-75987fca5b92@github.com> Message-ID: On Thu, 6 Nov 2025 08:57:27 GMT, Matthias Baesken wrote: >> make/hotspot/lib/JvmFeatures.gmk line 186: >> >>> 184: else ifeq ($(call isCompiler, microsoft), true) >>> 185: JVM_CFLAGS_FEATURES += $(CXX_O_FLAG_LTO) >>> 186: JVM_LDFLAGS_FEATURES += $(LDFLAGS_LTO) >> >> Now that we have variables for LTO flags, we shouldn't need compiler type checks for adding them. We can keep the conditionals for the other flags, but adding LTO flags looks compiler agnostic. > > We still add CXX_O_FLAG_HIGHEST_JVM to the JVM_LDFLAGS_FEATURES for gcc/clang , but not for msvc. Not sure why. So there is still a bit of difference between compilers. That's due to how the toolchains work, with VC you're passing the options directly to the linker, while for gcc/clang you're passing the optimization flag to the driver, which understands the optimization option, unlike link.exe (Technically you're passing it to the compiler for gcc/clang I believe, both of them use the compiler's middle end to optimize your code during the link step when LTO is enabled from what I recall) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2498129638 From duke at openjdk.org Thu Nov 6 10:48:18 2025 From: duke at openjdk.org (Christian Heilmann) Date: Thu, 6 Nov 2025 10:48:18 GMT Subject: RFR: 8297191: [macos] printing a page range with starting page > 1 results in missing pages [v2] In-Reply-To: References: Message-ID: On Fri, 18 Jul 2025 13:19:10 GMT, Christian Heilmann wrote: >> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS. >> >> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m. > > Christian Heilmann has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS > - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS > - Merge branch 'master' of https://github.com/openjdk/jdk into pr/11266 > - Merge branch 'master' into pr/11266 > - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS I repeated the test on macOS 26.0.1. All the values displayed in the native macOS print dialogue were shown as expected. I only highlighted one case where I provided a PageRanges(1,5) and macOS intelligently switched to all pages in the native print dialogue, which is correct, but this could be unexpected. **Test with native (DialogTypeSelection.NATIVE) print dialog** |Pageable.getNumberOfPages|PrintRequestAttributeSet|displayed in macOS native print dialog |---|---|---| | 5 | - |(*)All Pages - ( )Ranage from 1 to 1| | 5 | PageRanges(1,5) |**(*)All Pages - ( )Range from 1 to 1**| | 5 | PageRanges(1,1) |( )All Pages - (*)Range from 1 to 1| | 5 | PageRanges(1,3) |( )All Pages - (*)Range from 1 to 3| | 5 | PageRanges(3,5) |( )All Pages - (*)Range from 3 to 5| | 5 | PageRanges(5,5) |( )All Pages - (*)Range from 5 to 5| | 5 | PageRanges(5,10) |( )All Pages - (*)Range from 5 to 10| | UNKNOWN_NUMBER_OF_PAGES | - |(*)All Pages - ( )Range from 1 to 1| | UNKNOWN_NUMBER_OF_PAGES | PageRanges(1,5) |**( )All Pages - (*)Range from 1 to 5**| | UNKNOWN_NUMBER_OF_PAGES | PageRanges(1,1) |( )All Pages - (*)Range from 1 to 1| | UNKNOWN_NUMBER_OF_PAGES | PageRanges(1,3) |( )All Pages - (*)Range from 1 to 3| | UNKNOWN_NUMBER_OF_PAGES | PageRanges(3,5) |( )All Pages - (*)Range from 3 to 5| | UNKNOWN_NUMBER_OF_PAGES | PageRanges(5,5) |( )All Pages - (*)Range from 5 to 5| | UNKNOWN_NUMBER_OF_PAGES | PageRanges(5,10) |( )All Pages - (*)Range from 5 to 10| ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3496509402 From mbaesken at openjdk.org Thu Nov 6 12:30:47 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 6 Nov 2025 12:30:47 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v6] In-Reply-To: References: Message-ID: > We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. > But for other JDK native libs, we do not have support for this feature. > LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Remove lto related comment in flags-cflags.m4 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27976/files - new: https://git.openjdk.org/jdk/pull/27976/files/72ba9ed1..75f83437 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27976/head:pull/27976 PR: https://git.openjdk.org/jdk/pull/27976 From mbaesken at openjdk.org Thu Nov 6 12:35:05 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 6 Nov 2025 12:35:05 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v5] In-Reply-To: <31uD61UWj2KbHHXtP8wsSHHbAAraD1MRQPpVrxKse8Q=.1037cea5-a914-46fd-b481-1cc72bbef719@github.com> References: <31uD61UWj2KbHHXtP8wsSHHbAAraD1MRQPpVrxKse8Q=.1037cea5-a914-46fd-b481-1cc72bbef719@github.com> Message-ID: On Wed, 5 Nov 2025 17:38:58 GMT, Erik Joelsson wrote: > I don't think adding the LTO flags to the OPT flags is the right move So where should I move it? After all it is link time *optimization* so it is an optimization related tool feature. But should I remove it completely from SetupCompileFileFlags because having it in SetupCompilerFlags is sufficient for out task ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2498787207 From mbaesken at openjdk.org Thu Nov 6 12:49:22 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 6 Nov 2025 12:49:22 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v7] In-Reply-To: References: Message-ID: <5oAFgVlLJT7GeJB0w5ufEgOlGoO8mLYo2qjxkHGm_Hc=.7c5bdf18-b9a5-4a54-afd8-8059a45a22b9@github.com> > We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. > But for other JDK native libs, we do not have support for this feature. > LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Move LTO link flag settings a little up ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27976/files - new: https://git.openjdk.org/jdk/pull/27976/files/75f83437..e68bc711 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=05-06 Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27976/head:pull/27976 PR: https://git.openjdk.org/jdk/pull/27976 From aivanov at openjdk.org Thu Nov 6 13:10:08 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 6 Nov 2025 13:10:08 GMT Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent() [v7] In-Reply-To: References: Message-ID: On Thu, 6 Nov 2025 01:10:48 GMT, Harshitha Onkar wrote: >> `findComponent(final Container container, final Predicate predicate)` is a useful utility method and thus added to` javax/swing/regtesthelpers/Util.java` instead of having redundant code in tests. It can be used to find a component by label name. >> >> PS: Existing `Util.findSubComponent()` finds component by class name but `findComponent()` can be used to search for a particular component by label name/title when there are multiple subcomponents of same type by applying a predicate logic. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > spacing Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27944#pullrequestreview-3428110026 From aivanov at openjdk.org Thu Nov 6 13:15:09 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 6 Nov 2025 13:15:09 GMT Subject: RFR: JDK-8371365 : Update /javax/swing/JFileChooser/bug4759934.java to use Util.findComponent() In-Reply-To: References: Message-ID: On Thu, 6 Nov 2025 01:00:43 GMT, Harshitha Onkar wrote: > /javax/swing/JFileChooser/bug4759934.java test changes related to addition of new method to Util - https://github.com/openjdk/jdk/pull/27944. test/jdk/javax/swing/JFileChooser/bug4759934.java line 74: > 72: robot.mouseMove(dlgBtnLoc.x , dlgBtnLoc.y); > 73: robot.mousePress(MouseEvent.BUTTON1_DOWN_MASK); > 74: robot.mouseRelease(MouseEvent.BUTTON1_DOWN_MASK); https://github.com/openjdk/jdk/pull/27944#discussion_r2490547507 > All the clicks above are to click a button? Should we replace these clicks with programmatic clicks? This is more reliable and quicker than robot. The only possible issue is to to ensure the updated test still reproduces the original bug. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28169#discussion_r2498919704 From aivanov at openjdk.org Thu Nov 6 13:29:05 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 6 Nov 2025 13:29:05 GMT Subject: RFR: JDK-8371365 : Update /javax/swing/JFileChooser/bug4759934.java to use Util.findComponent() In-Reply-To: References: Message-ID: On Thu, 6 Nov 2025 13:12:13 GMT, Alexey Ivanov wrote: >> /javax/swing/JFileChooser/bug4759934.java test changes related to addition of new method to Util - https://github.com/openjdk/jdk/pull/27944. > > test/jdk/javax/swing/JFileChooser/bug4759934.java line 74: > >> 72: robot.mouseMove(dlgBtnLoc.x , dlgBtnLoc.y); >> 73: robot.mousePress(MouseEvent.BUTTON1_DOWN_MASK); >> 74: robot.mouseRelease(MouseEvent.BUTTON1_DOWN_MASK); > > https://github.com/openjdk/jdk/pull/27944#discussion_r2490547507 > >> All the clicks above are to click a button? Should we replace these clicks with programmatic clicks? > > This is more reliable and quicker than robot. > > The only possible issue is to to ensure the updated test still reproduces the original bug. I just noticed your comment: https://github.com/openjdk/jdk/pull/27944#discussion_r2496343433 > I'm for keeping the other clicks as-is (via Robot) since we have reference to these buttons unlike the cancel button of JFileChooser and this way keep much of the original test case intact without overly modifying it. ??Since we have reference to these buttons,? it's even easier to call `frameBtn.doClick()` and `dlgBtnLoc.doClick()`. Once you get the reference to the Cancel button in the file chooser you can also use robot to click the button. Using consistently the same method to click the buttons makes the test easier to comprehend. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28169#discussion_r2498964348 From aivanov at openjdk.org Thu Nov 6 13:35:07 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 6 Nov 2025 13:35:07 GMT Subject: RFR: JDK-8371364 : Refactor javax/swing/JFileChooser/FileSizeCheck.java to use Util.findComponent() In-Reply-To: <1-YFX00LL6t9o8Z3uYzzTszxcSXWMX9LxR3uw9Sbwtw=.14d4a5c0-0d2a-4105-9b77-a98bfd40366d@github.com> References: <1-YFX00LL6t9o8Z3uYzzTszxcSXWMX9LxR3uw9Sbwtw=.14d4a5c0-0d2a-4105-9b77-a98bfd40366d@github.com> Message-ID: On Thu, 6 Nov 2025 00:54:45 GMT, Harshitha Onkar wrote: > FileSizeCheck.java test changes related to addition of new method to Util - https://github.com/openjdk/jdk/pull/27944. Changes requested by aivanov (Reviewer). test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 240: > 238: private static JTable findTable(final Container container) { > 239: Component result = Util.findComponent(container, > 240: c -> c instanceof JTable); Suggestion: Component result = Util.findComponent(container, c -> c instanceof JTable); Align the second parameter. ------------- PR Review: https://git.openjdk.org/jdk/pull/28168#pullrequestreview-3428208525 PR Review Comment: https://git.openjdk.org/jdk/pull/28168#discussion_r2498980214 From mbaesken at openjdk.org Thu Nov 6 13:52:23 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 6 Nov 2025 13:52:23 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v8] In-Reply-To: References: Message-ID: > We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. > But for other JDK native libs, we do not have support for this feature. > LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Simplify lto flag assignment for hs in JvmFeatures.gmk ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27976/files - new: https://git.openjdk.org/jdk/pull/27976/files/e68bc711..a5e266e0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=06-07 Stats: 10 lines in 1 file changed: 2 ins; 6 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27976/head:pull/27976 PR: https://git.openjdk.org/jdk/pull/27976 From erikj at openjdk.org Thu Nov 6 13:52:24 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 6 Nov 2025 13:52:24 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v5] In-Reply-To: References: <31uD61UWj2KbHHXtP8wsSHHbAAraD1MRQPpVrxKse8Q=.1037cea5-a914-46fd-b481-1cc72bbef719@github.com> <2xxNnTYM_sGTOtbEafbA6GDVO1Qy2WOs2midOMhBMIs=.4e1c8ee1-c75f-4d41-8e19-75987fca5b92@github.com> Message-ID: On Thu, 6 Nov 2025 09:09:52 GMT, Julian Waters wrote: >> We still add CXX_O_FLAG_HIGHEST_JVM to the JVM_LDFLAGS_FEATURES for gcc/clang , but not for msvc. Not sure why. So there is still a bit of difference between compilers. > > That's due to how the toolchains work, with VC you're passing the options directly to the linker, while for gcc/clang you're passing the optimization flag to the driver, which understands the optimization option, unlike link.exe (Technically you're passing it to the compiler for gcc/clang I believe, both of them use the compiler's middle end to optimize your code during the link step when LTO is enabled from what I recall) > We still add CXX_O_FLAG_HIGHEST_JVM to the JVM_LDFLAGS_FEATURES for gcc/clang , but not for msvc. Not sure why. So there is still a bit of difference between compilers. That is what I meant. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2499024967 From erikj at openjdk.org Thu Nov 6 14:01:54 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 6 Nov 2025 14:01:54 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v5] In-Reply-To: References: <31uD61UWj2KbHHXtP8wsSHHbAAraD1MRQPpVrxKse8Q=.1037cea5-a914-46fd-b481-1cc72bbef719@github.com> Message-ID: On Thu, 6 Nov 2025 12:32:14 GMT, Matthias Baesken wrote: >> make/common/native/Flags.gmk line 69: >> >>> 67: $1_OPT_CFLAGS += $(C_O_FLAG_LTO) >>> 68: $1_OPT_CXXFLAGS += $(CXX_O_FLAG_LTO) >>> 69: endif >> >> I don't think adding the LTO flags to the OPT flags is the right move, but if we are going with that, then this addition of LTO flags should only be done if `$$($1_OPTIMIZATION)` is set, as otherwise, those flags are already added through `$$($2_OPT_CFLAGS)`. That means, this block should be moved into the else block above, before the endif on line 64. >> >> However, the OPT flags are treated separately through SetupCompilerFlags and SetupCompileFileFlags because it should be possible to override the optimization level on a per file basis. The LTO flags on the other hand, are not possible to override on a per file basis, so we should not be tinkering with those in the SetupCompileFileFlags macro at all. So mixing in the LTO flags with the OPT flags is the wrong move. > >> I don't think adding the LTO flags to the OPT flags is the right move > > So where should I move it? After all it is link time *optimization* so it is an optimization related tool feature. > But should I remove it completely from SetupCompileFileFlags because having it in SetupCompilerFlags is sufficient for out task ? Again, the optimization flags aren't handled as a separate set of variables because they are of the category "optimization". It's because optimization flags are handled on a higher level with an abstraction of "low", "medium", "high" etc, and that abstraction allows for specific file overrides. That's what the `*_OPT_C*FLAGS` are there to handle. Since the LTO flags are not related to this abstraction, they should not be mixed into these variables, that is just confusing and adding unnecessary complexity. The LTO flags should just be stacked on to the `$1_EXTRA_*` flags like any other. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2499047995 From erikj at openjdk.org Thu Nov 6 14:01:59 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 6 Nov 2025 14:01:59 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v8] In-Reply-To: References: Message-ID: On Thu, 6 Nov 2025 13:52:23 GMT, Matthias Baesken wrote: >> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. >> But for other JDK native libs, we do not have support for this feature. >> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Simplify lto flag assignment for hs in JvmFeatures.gmk make/hotspot/lib/JvmFeatures.gmk line 182: > 180: JVM_LDFLAGS_FEATURES += $(LDFLAGS_LTO) > 181: else > 182: JVM_LDFLAGS_FEATURES += $(CXX_O_FLAG_HIGHEST_JVM) $(LDFLAGS_LTO) That's better, but looking at this again, if we are now abstracting LTO support into `SetupNativeCompilation`, then CompileJvm.gmk/JvmFeatures.gmk should use that instead of adding the flags manually. What I mean is, in this conditional on the jvm feature `link-time-opt`, a variable should be set that causes `LINK_TIME_OPTIMIZATION` to be set to true for libjvm. No LTO flags should be explicitly added here, just the optimization flag for gcc/clang. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2499068717 From mbaesken at openjdk.org Thu Nov 6 15:30:30 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 6 Nov 2025 15:30:30 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v9] In-Reply-To: References: Message-ID: > We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. > But for other JDK native libs, we do not have support for this feature. > LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Use LINK_TIME_OPTIMIZATION for libjvm build too ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27976/files - new: https://git.openjdk.org/jdk/pull/27976/files/a5e266e0..bea8d07a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=07-08 Stats: 7 lines in 2 files changed: 2 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27976/head:pull/27976 PR: https://git.openjdk.org/jdk/pull/27976 From azvegint at openjdk.org Thu Nov 6 15:44:28 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 6 Nov 2025 15:44:28 GMT Subject: RFR: 8371225: Missing release of GDK lock in Java_sun_awt_X11_GtkFileDialogPeer_run() Message-ID: The `Java_sun_awt_X11_GtkFileDialogPeer_run` JNI function does not call `gdk_threads_leave` for the corresponding `gdk_threads_enter` in 3 cases of early return. This simple change resolves the issue. Testing looks good. ------------- Commit messages: - year - 8371225: Missing release of GDK lock in Java_sun_awt_X11_GtkFileDialogPeer_run() Changes: https://git.openjdk.org/jdk/pull/28177/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28177&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371225 Stats: 7 lines in 1 file changed: 4 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28177.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28177/head:pull/28177 PR: https://git.openjdk.org/jdk/pull/28177 From aivanov at openjdk.org Thu Nov 6 17:45:38 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 6 Nov 2025 17:45:38 GMT Subject: RFR: 8371225: Missing release of GDK lock in Java_sun_awt_X11_GtkFileDialogPeer_run() In-Reply-To: References: Message-ID: On Thu, 6 Nov 2025 15:36:07 GMT, Alexander Zvegintsev wrote: > The `Java_sun_awt_X11_GtkFileDialogPeer_run` JNI function does not call `gdk_threads_leave` for the corresponding `gdk_threads_enter` in 3 cases of early return. > This simple change resolves the issue. > > Testing looks good. Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28177#pullrequestreview-3429616696 From aivanov at openjdk.org Thu Nov 6 17:57:14 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 6 Nov 2025 17:57:14 GMT Subject: RFR: 8371163: Make GlyphView/TestGlyphBGHeight.java headless In-Reply-To: References: Message-ID: <6_mF_b8u61-cEu0VvsxXedyIAfT9fTZR9IElnjMXghA=.84359b54-4547-432f-a520-d34a68796117@github.com> On Thu, 6 Nov 2025 07:37:49 GMT, Prasanta Sadhukhan wrote: > Test is made headless Changes requested by aivanov (Reviewer). test/jdk/javax/swing/text/GlyphView/TestGlyphBGHeight.java line 52: > 50: static int getEmptyPixel() { > 51: return 0xFFFFFFFF; > 52: } Do you need a method? Can't it be a constant? private static final Color EMPTY_PIXEL = new Color(0xFFFFFFFF); test/jdk/javax/swing/text/GlyphView/TestGlyphBGHeight.java line 63: > 61: g.fillRect(0, 0, WIDTH, HEIGHT); > 62: } > 63: }); You can draw into the image on the thread where you created it. test/jdk/javax/swing/text/GlyphView/TestGlyphBGHeight.java line 70: > 68: > 69: final BufferedImage img = createImage(); > 70: SwingUtilities.invokeAndWait(() -> { You can create the text component directly on the main thread. The component will never be accessed from EDT if you perform all the operations on the main thread. test/jdk/javax/swing/text/GlyphView/TestGlyphBGHeight.java line 71: > 69: final BufferedImage img = createImage(); > 70: SwingUtilities.invokeAndWait(() -> { > 71: final JTextPane comp = new JTextPane(); I'd rather name it `textPane`, it's more descriptive than `comp`. test/jdk/javax/swing/text/GlyphView/TestGlyphBGHeight.java line 83: > 81: > 82: comp.setSize(WIDTH, HEIGHT); > 83: comp.setDocument(doc); `setDocument` is a no-op and is not needed, you modified the document that's already installed into the component. test/jdk/javax/swing/text/GlyphView/TestGlyphBGHeight.java line 93: > 91: BufferedImage bimg = img.getSubimage(0, FONTSIZE + 20, WIDTH, 1); > 92: ImageIO.write(bimg, "png", new File("AppTest1.png")); > 93: for (int x = 10; x < WIDTH/ 2; x++) { Suggestion: for (int x = 10; x < WIDTH / 2; x++) { test/jdk/javax/swing/text/GlyphView/TestGlyphBGHeight.java line 98: > 96: if (col.equals(Color.YELLOW)) { > 97: throw new RuntimeException(" Background is painted taller than needed for styled text"); > 98: } Suggestion: int col = bimg.getRGB(x, 0); System.out.println(Integer.toHexString(col)); if (col != Color.YELLOW.getRGB()) { throw new RuntimeException("Background is painted taller than needed for styled text"); } ------------- PR Review: https://git.openjdk.org/jdk/pull/28173#pullrequestreview-3429631823 PR Review Comment: https://git.openjdk.org/jdk/pull/28173#discussion_r2500117414 PR Review Comment: https://git.openjdk.org/jdk/pull/28173#discussion_r2500119803 PR Review Comment: https://git.openjdk.org/jdk/pull/28173#discussion_r2500145516 PR Review Comment: https://git.openjdk.org/jdk/pull/28173#discussion_r2500124142 PR Review Comment: https://git.openjdk.org/jdk/pull/28173#discussion_r2500158068 PR Review Comment: https://git.openjdk.org/jdk/pull/28173#discussion_r2500130800 PR Review Comment: https://git.openjdk.org/jdk/pull/28173#discussion_r2500139189 From serb at openjdk.org Thu Nov 6 18:36:04 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 6 Nov 2025 18:36:04 GMT Subject: RFR: 8368729: Add appropriate checks in java.awt.image.Kernel constructor In-Reply-To: <_94TDObFPwQ6uoerq8PSnI7OR0ge67DfdHGbfACo5Gw=.9814805f-2a6c-432a-9535-88711f12d042@github.com> References: <7DpQRTNILJjPS0vCTMv1_EYUUYn_L797H-15bvDnQuk=.7d607f81-0477-4aab-a0d3-86624ba7508d@github.com> <_94TDObFPwQ6uoerq8PSnI7OR0ge67DfdHGbfACo5Gw=.9814805f-2a6c-432a-9535-88711f12d042@github.com> Message-ID: <5PSIpKWEsYE-hJyqSik3iUJ7mG9QnfI14XNez3Xfhc4=.77b50ab4-1d69-402e-bb6f-b389f7f7d63e@github.com> On Thu, 6 Nov 2025 08:45:28 GMT, Jayathirth D V wrote: >Current spec already throws IAE in one of the validation scenario, so throwing the same IAE for other input argument validation is uniform. We usually throw an NPE when the value is null, since you can?t validate any properties on a null reference, and it?s more specific than an IAE. Moreover, NPE was thrown before, so this won?t change the behavior. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28127#discussion_r2500318684 From serb at openjdk.org Thu Nov 6 19:33:04 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 6 Nov 2025 19:33:04 GMT Subject: RFR: 8371225: Missing release of GDK lock in Java_sun_awt_X11_GtkFileDialogPeer_run() In-Reply-To: References: Message-ID: On Thu, 6 Nov 2025 15:36:07 GMT, Alexander Zvegintsev wrote: > The `Java_sun_awt_X11_GtkFileDialogPeer_run` JNI function does not call `gdk_threads_leave` for the corresponding `gdk_threads_enter` in 3 cases of early return. > This simple change resolves the issue. > > Testing looks good. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28177#pullrequestreview-3430154169 From azvegint at openjdk.org Thu Nov 6 20:27:11 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 6 Nov 2025 20:27:11 GMT Subject: Integrated: 8371225: Missing release of GDK lock in Java_sun_awt_X11_GtkFileDialogPeer_run() In-Reply-To: References: Message-ID: On Thu, 6 Nov 2025 15:36:07 GMT, Alexander Zvegintsev wrote: > The `Java_sun_awt_X11_GtkFileDialogPeer_run` JNI function does not call `gdk_threads_leave` for the corresponding `gdk_threads_enter` in 3 cases of early return. > This simple change resolves the issue. > > Testing looks good. This pull request has now been integrated. Changeset: 8a0c47d4 Author: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/8a0c47d4ba4db523d94689b3ac347e9cd35183ce Stats: 7 lines in 1 file changed: 4 ins; 2 del; 1 mod 8371225: Missing release of GDK lock in Java_sun_awt_X11_GtkFileDialogPeer_run() Reviewed-by: aivanov, serb ------------- PR: https://git.openjdk.org/jdk/pull/28177 From dnguyen at openjdk.org Thu Nov 6 23:26:02 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 6 Nov 2025 23:26:02 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v9] In-Reply-To: References: <1nxKOtN4B2h026FhyQp8t-1IOZBFPMfnif7I5a0Vnuc=.9ffffa12-226f-49ac-8b85-fac3750c649f@github.com> <3hw1X_jGyDqVuyleOkeirF2hj4ZnfuBPoG9J-e4Rw50=.914a54f6-f2f8-491d-b2af-e84dfdc5967b@github.com> Message-ID: On Thu, 6 Nov 2025 00:13:35 GMT, Sergey Bylokhov wrote: > > I don't see why it wouldn't be possible to make changes to the implementation of the mouse movement. I have already looked at the API you described for mouse movement, and the implementation there is not too different. > > That sounds good. Are there any blockers to implementing it in the current patch? Mostly due to time and that the other implementation requires time to re-test and get reviews/approvals on. I picked up these changes to the Robot API after it has already been proposed for a while, and this PR has also been up for a while. Testing on this and the csr is complete. I believe there may be a discussion about whether a change from this mouse movement implementation to the RobotDriver version is needed. I'm sure people would like to chime in on this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26969#issuecomment-3499808720 From psadhukhan at openjdk.org Fri Nov 7 03:35:41 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 7 Nov 2025 03:35:41 GMT Subject: RFR: 8371163: Make GlyphView/TestGlyphBGHeight.java headless [v2] In-Reply-To: References: Message-ID: > Test is made headless Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Review fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28173/files - new: https://git.openjdk.org/jdk/pull/28173/files/31553875..2fd23125 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28173&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28173&range=00-01 Stats: 35 lines in 1 file changed: 0 ins; 12 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/28173.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28173/head:pull/28173 PR: https://git.openjdk.org/jdk/pull/28173 From psadhukhan at openjdk.org Fri Nov 7 03:35:42 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 7 Nov 2025 03:35:42 GMT Subject: RFR: 8371163: Make GlyphView/TestGlyphBGHeight.java headless In-Reply-To: References: Message-ID: On Thu, 6 Nov 2025 07:37:49 GMT, Prasanta Sadhukhan wrote: > Test is made headless Updated PR ------------- PR Comment: https://git.openjdk.org/jdk/pull/28173#issuecomment-3500512843 From psadhukhan at openjdk.org Fri Nov 7 08:57:12 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 7 Nov 2025 08:57:12 GMT Subject: RFR: 8251928: [macos] the printer DPI always be 72, cause some content lost when print out [v9] In-Reply-To: References: Message-ID: On Sat, 1 Nov 2025 14:31:41 GMT, GennadiyKrivoshein wrote: >> The fix for the https://bugs.openjdk.org/browse/JDK-8251928. >> >> **Description**. >> This PR contains changes to be able to print with DPI higher than 72 on macOS, set default CPrinterJob DPI is 300 like in the PSPrinterJob. >> >> As described in the macOS drawing guide, the following steps are required to draw with high DPI (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html#//apple_ref/doc/uid/TP40003290-CH204-BCICIJAJ): >> 1. Convert the user-space point, size, or rectangle value to device space coordinates; >> 2. Normalize the value in device space so that it is aligned to the appropriate pixel boundary; >> 3. Convert the normalized value back to user space; >> 4. Draw your content using the adjusted value. >> >> The 1-st step is now implemented in the CPrinterJob, a Graphics provided to the print method adjusted to a printer's DPI. >> The 2-nd step is a drawing process in the java code (without changes). >> The 3-rd step is now implemented in the PrinterView.m, the drawing scaled back to the 72 DPI. >> The 4-th step is a drawing process in the native code (without changes). >> >> **Tests**. >> I run all tests from javax.print package and there is no any regression. >> New test covers macOS and Linux only because we know its default DPI - 300. > > GennadiyKrivoshein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - Merge branch 'openjdk:master' into macOS_printing_DPI > - Revert PeekGraphics > - Merge branch 'openjdk:master' into macOS_printing_DPI > - move scaling to GraphicsConfig, update PeekGraphics > - revert CGraphicsDevice.m constants. Update orientation constant usage > - remove setDevClip usage. Update names. Handle page format orientation. > - Merge branch 'openjdk:master' into macOS_printing_DPI > - Merge branch 'openjdk:master' into macOS_printing_DPI > - [macos] the printer DPI always be 72 Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25489#pullrequestreview-3432345216 From jdv at openjdk.org Fri Nov 7 09:45:05 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Fri, 7 Nov 2025 09:45:05 GMT Subject: RFR: 8368729: Add appropriate checks in java.awt.image.Kernel constructor In-Reply-To: <5PSIpKWEsYE-hJyqSik3iUJ7mG9QnfI14XNez3Xfhc4=.77b50ab4-1d69-402e-bb6f-b389f7f7d63e@github.com> References: <7DpQRTNILJjPS0vCTMv1_EYUUYn_L797H-15bvDnQuk=.7d607f81-0477-4aab-a0d3-86624ba7508d@github.com> <_94TDObFPwQ6uoerq8PSnI7OR0ge67DfdHGbfACo5Gw=.9814805f-2a6c-432a-9535-88711f12d042@github.com> <5PSIpKWEsYE-hJyqSik3iUJ7mG9QnfI14XNez3Xfhc4=.77b50ab4-1d69-402e-bb6f-b389f7f7d63e@github.com> Message-ID: On Thu, 6 Nov 2025 18:33:26 GMT, Sergey Bylokhov wrote: >> Spec of NPE states multiple reasons of when an NPE is thrown while using null object and IAE clearly mentions that we are trying to validate input arguments and throw it when we see any issue. >> >> Current spec already throws IAE in one of the validation scenario, so throwing the same IAE for other input argument validation is uniform. >> >> We can say that in some parts of JDK we throw NPE for null argument verification, but using IAE in this scenario looks better. > >>Current spec already throws IAE in one of the validation scenario, so throwing the same IAE for other input argument validation is uniform. > > We usually throw an NPE when the value is null, since you can?t validate any properties on a null reference, and it?s more specific than an IAE. Moreover, NPE was thrown before, so this won?t change the behavior. NPE which was thrown before was undefined behaviour. There is no objection in CSR request also. I would like to continue keeping usage of IAE. If majority of reviewers have objections, we can take it up in follow-up issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28127#discussion_r2502405775 From jdv at openjdk.org Fri Nov 7 09:49:15 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Fri, 7 Nov 2025 09:49:15 GMT Subject: Integrated: 8368729: Add appropriate checks in java.awt.image.Kernel constructor In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 09:35:32 GMT, Jayathirth D V wrote: > `java.awt.image.Kernel` constructor doesn't validate all input values and we need to add appropriate checks. > A new test is also added to make sure we appropriate exception when invalid values are passed. > > This will also need a CSR. This pull request has now been integrated. Changeset: 4233178a Author: Jayathirth D V URL: https://git.openjdk.org/jdk/commit/4233178af20f07ade32322fad931c68e1c4251cf Stats: 83 lines in 2 files changed: 77 ins; 0 del; 6 mod 8368729: Add appropriate checks in java.awt.image.Kernel constructor Reviewed-by: azvegint, prr, kizune ------------- PR: https://git.openjdk.org/jdk/pull/28127 From mbaesken at openjdk.org Fri Nov 7 15:06:51 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 7 Nov 2025 15:06:51 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: Message-ID: > We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. > But for other JDK native libs, we do not have support for this feature. > LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Add lto to EXTRA_FLAGS, not to OPT ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27976/files - new: https://git.openjdk.org/jdk/pull/27976/files/bea8d07a..bc591fdf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=08-09 Stats: 15 lines in 1 file changed: 5 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27976/head:pull/27976 PR: https://git.openjdk.org/jdk/pull/27976 From mbaesken at openjdk.org Fri Nov 7 15:06:52 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 7 Nov 2025 15:06:52 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v5] In-Reply-To: References: <31uD61UWj2KbHHXtP8wsSHHbAAraD1MRQPpVrxKse8Q=.1037cea5-a914-46fd-b481-1cc72bbef719@github.com> Message-ID: On Thu, 6 Nov 2025 13:53:07 GMT, Erik Joelsson wrote: >>> I don't think adding the LTO flags to the OPT flags is the right move >> >> So where should I move it? After all it is link time *optimization* so it is an optimization related tool feature. >> But should I remove it completely from SetupCompileFileFlags because having it in SetupCompilerFlags is sufficient for out task ? > > Again, the optimization flags aren't handled as a separate set of variables because they are of the category "optimization". It's because optimization flags are handled on a higher level with an abstraction of "low", "medium", "high" etc, and that abstraction allows for specific file overrides. That's what the `*_OPT_C*FLAGS` are there to handle. Since the LTO flags are not related to this abstraction, they should not be mixed into these variables, that is just confusing and adding unnecessary complexity. > > The LTO flags should just be stacked on to the `$1_EXTRA_*` flags like any other. I adjusted my changes to Flags.gmk . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2504024684 From duke at openjdk.org Fri Nov 7 17:45:23 2025 From: duke at openjdk.org (lawrence.andrews) Date: Fri, 7 Nov 2025 17:45:23 GMT Subject: RFR: 8371485: ProblemList awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java for linux Message-ID: Problem listing test awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java is intermittently on linux atleast from JDK 22, JDK 24 & JDK 25 . ------------- Commit messages: - 8371485: ProblemList awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java for linux Changes: https://git.openjdk.org/jdk/pull/28203/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28203&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371485 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28203.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28203/head:pull/28203 PR: https://git.openjdk.org/jdk/pull/28203 From azvegint at openjdk.org Fri Nov 7 17:45:23 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 7 Nov 2025 17:45:23 GMT Subject: RFR: 8371485: ProblemList awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java for linux In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 17:37:07 GMT, lawrence.andrews wrote: > Problem listing test awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java is intermittently on linux atleast from JDK 22, JDK 24 & JDK 25 . Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28203#pullrequestreview-3435418926 From honkar at openjdk.org Fri Nov 7 17:51:34 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 7 Nov 2025 17:51:34 GMT Subject: Integrated: JDK-8353755 : Add a helper method to Util - findComponent() In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 22:02:42 GMT, Harshitha Onkar wrote: > `findComponent(final Container container, final Predicate predicate)` is a useful utility method and thus added to` javax/swing/regtesthelpers/Util.java` instead of having redundant code in tests. It can be used to find a component by label name. > > PS: Existing `Util.findSubComponent()` finds component by class name but `findComponent()` can be used to search for a particular component by label name/title when there are multiple subcomponents of same type by applying a predicate logic. This pull request has now been integrated. Changeset: 35491038 Author: Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/354910381a9319723d43a6182269b5449c02a527 Stats: 54 lines in 1 file changed: 38 ins; 2 del; 14 mod 8353755: Add a helper method to Util - findComponent() Reviewed-by: aivanov, tr ------------- PR: https://git.openjdk.org/jdk/pull/27944 From honkar at openjdk.org Fri Nov 7 18:21:26 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 7 Nov 2025 18:21:26 GMT Subject: RFR: JDK-8371364 : Refactor javax/swing/JFileChooser/FileSizeCheck.java to use Util.findComponent() [v2] In-Reply-To: <1-YFX00LL6t9o8Z3uYzzTszxcSXWMX9LxR3uw9Sbwtw=.14d4a5c0-0d2a-4105-9b77-a98bfd40366d@github.com> References: <1-YFX00LL6t9o8Z3uYzzTszxcSXWMX9LxR3uw9Sbwtw=.14d4a5c0-0d2a-4105-9b77-a98bfd40366d@github.com> Message-ID: <7KZ_fuoccnuZ2j8DRL2amW6BwZ_RxbcTijE5JLAQjsY=.c115c456-deb6-4fc5-ae34-b8e87f8039bd@github.com> > FileSizeCheck.java test changes related to addition of new method to Util - https://github.com/openjdk/jdk/pull/27944. Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into Util_FileSizeCheck - indentation - test update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28168/files - new: https://git.openjdk.org/jdk/pull/28168/files/a7273e14..68a9b845 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28168&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28168&range=00-01 Stats: 104030 lines in 1543 files changed: 59145 ins; 35437 del; 9448 mod Patch: https://git.openjdk.org/jdk/pull/28168.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28168/head:pull/28168 PR: https://git.openjdk.org/jdk/pull/28168 From honkar at openjdk.org Fri Nov 7 18:21:27 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 7 Nov 2025 18:21:27 GMT Subject: RFR: JDK-8371364 : Refactor javax/swing/JFileChooser/FileSizeCheck.java to use Util.findComponent() [v2] In-Reply-To: References: <1-YFX00LL6t9o8Z3uYzzTszxcSXWMX9LxR3uw9Sbwtw=.14d4a5c0-0d2a-4105-9b77-a98bfd40366d@github.com> Message-ID: <7-qOnmv1DLufzqcEd0_HUMiKuKpnub1TESvbnQ64JHI=.537af80e-18a4-475d-bb61-287b8bbc98aa@github.com> On Thu, 6 Nov 2025 13:31:58 GMT, Alexey Ivanov wrote: >> Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' into Util_FileSizeCheck >> - indentation >> - test update > > test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 240: > >> 238: private static JTable findTable(final Container container) { >> 239: Component result = Util.findComponent(container, >> 240: c -> c instanceof JTable); > > Suggestion: > > Component result = Util.findComponent(container, > c -> c instanceof JTable); > > Align the second parameter. Updated. Please re-review. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28168#discussion_r2504893869 From aivanov at openjdk.org Fri Nov 7 18:33:03 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 7 Nov 2025 18:33:03 GMT Subject: RFR: JDK-8371364 : Refactor javax/swing/JFileChooser/FileSizeCheck.java to use Util.findComponent() [v2] In-Reply-To: <7KZ_fuoccnuZ2j8DRL2amW6BwZ_RxbcTijE5JLAQjsY=.c115c456-deb6-4fc5-ae34-b8e87f8039bd@github.com> References: <1-YFX00LL6t9o8Z3uYzzTszxcSXWMX9LxR3uw9Sbwtw=.14d4a5c0-0d2a-4105-9b77-a98bfd40366d@github.com> <7KZ_fuoccnuZ2j8DRL2amW6BwZ_RxbcTijE5JLAQjsY=.c115c456-deb6-4fc5-ae34-b8e87f8039bd@github.com> Message-ID: On Fri, 7 Nov 2025 18:21:26 GMT, Harshitha Onkar wrote: >> FileSizeCheck.java test changes related to addition of new method to Util - https://github.com/openjdk/jdk/pull/27944. > > Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into Util_FileSizeCheck > - indentation > - test update Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28168#pullrequestreview-3435654921 From aivanov at openjdk.org Fri Nov 7 18:41:02 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 7 Nov 2025 18:41:02 GMT Subject: RFR: 8371163: Make GlyphView/TestGlyphBGHeight.java headless [v2] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 03:35:41 GMT, Prasanta Sadhukhan wrote: >> Test is made headless > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Review fix Marked as reviewed by aivanov (Reviewer). test/jdk/javax/swing/text/GlyphView/TestGlyphBGHeight.java line 59: > 57: > 58: public static void main(String[] args) throws Exception { > 59: I would also remove the blank line at the start of the `main` method. test/jdk/javax/swing/text/GlyphView/TestGlyphBGHeight.java line 85: > 83: System.out.println(Integer.toHexString(col)); > 84: if (col == Color.YELLOW.getRGB()) { > 85: throw new RuntimeException(" Background is painted taller than needed for styled text"); Suggestion: throw new RuntimeException("Background is painted taller than needed for styled text"); There should be no space at the start of the message. ------------- PR Review: https://git.openjdk.org/jdk/pull/28173#pullrequestreview-3435685180 PR Review Comment: https://git.openjdk.org/jdk/pull/28173#discussion_r2504959362 PR Review Comment: https://git.openjdk.org/jdk/pull/28173#discussion_r2504955991 From honkar at openjdk.org Fri Nov 7 18:44:11 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 7 Nov 2025 18:44:11 GMT Subject: Integrated: JDK-8371364 : Refactor javax/swing/JFileChooser/FileSizeCheck.java to use Util.findComponent() In-Reply-To: <1-YFX00LL6t9o8Z3uYzzTszxcSXWMX9LxR3uw9Sbwtw=.14d4a5c0-0d2a-4105-9b77-a98bfd40366d@github.com> References: <1-YFX00LL6t9o8Z3uYzzTszxcSXWMX9LxR3uw9Sbwtw=.14d4a5c0-0d2a-4105-9b77-a98bfd40366d@github.com> Message-ID: On Thu, 6 Nov 2025 00:54:45 GMT, Harshitha Onkar wrote: > FileSizeCheck.java test changes related to addition of new method to Util - https://github.com/openjdk/jdk/pull/27944. This pull request has now been integrated. Changeset: 9bc23608 Author: Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/9bc23608fb5719c3e977b5839efed5bc3f64a268 Stats: 23 lines in 1 file changed: 2 ins; 17 del; 4 mod 8371364: Refactor javax/swing/JFileChooser/FileSizeCheck.java to use Util.findComponent() Reviewed-by: aivanov ------------- PR: https://git.openjdk.org/jdk/pull/28168 From duke at openjdk.org Fri Nov 7 18:56:01 2025 From: duke at openjdk.org (duke) Date: Fri, 7 Nov 2025 18:56:01 GMT Subject: RFR: 8371485: ProblemList awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java for linux In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 17:37:07 GMT, lawrence.andrews wrote: > Problem listing test awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java is intermittently on linux atleast from JDK 22, JDK 24 & JDK 25 . @lawrence-andrew Your change (at version 53626b35eb36cb1a1397cedd3a8fcf956dc0e272) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28203#issuecomment-3504281418 From honkar at openjdk.org Fri Nov 7 19:13:05 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 7 Nov 2025 19:13:05 GMT Subject: RFR: JDK-8371365 : Update javax/swing/JFileChooser/bug4759934.java to use Util.findComponent() In-Reply-To: References: Message-ID: On Thu, 6 Nov 2025 13:26:35 GMT, Alexey Ivanov wrote: >> test/jdk/javax/swing/JFileChooser/bug4759934.java line 74: >> >>> 72: robot.mouseMove(dlgBtnLoc.x , dlgBtnLoc.y); >>> 73: robot.mousePress(MouseEvent.BUTTON1_DOWN_MASK); >>> 74: robot.mouseRelease(MouseEvent.BUTTON1_DOWN_MASK); >> >> https://github.com/openjdk/jdk/pull/27944#discussion_r2490547507 >> >>> All the clicks above are to click a button? Should we replace these clicks with programmatic clicks? >> >> This is more reliable and quicker than robot. >> >> The only possible issue is to to ensure the updated test still reproduces the original bug. > > I just noticed your comment: https://github.com/openjdk/jdk/pull/27944#discussion_r2496343433 > >> I'm for keeping the other clicks as-is (via Robot) since we have reference to these buttons unlike the cancel button of JFileChooser and this way keep much of the original test case intact without overly modifying it. > > ??Since we have reference to these buttons,? it's even easier to call `frameBtn.doClick()` and `dlgBtnLoc.doClick()`. > > Once you get the reference to the Cancel button in the file chooser you can also use robot to click the button. > > Using consistently the same method to click the buttons makes the test easier to comprehend. I referred to the original JBS issue for which this test was created - [JDK-4759934](https://bugs.openjdk.org/browse/JDK-4759934). Looks like we can use doClick() instead of using Robot for the clicks. But the problem is that when we use doClick() for frameBtn and dialogBtn, JFC's click on Cancel button doesn't happen and the test fails due to timeout. This happens on macOS26, I have to test on other platforms. SwingUtilities.invokeAndWait(() -> frameBtn.doClick()); robot.waitForIdle(); robot.delay(500); SwingUtilities.invokeAndWait(() -> dialogBtn.doClick()); robot.waitForIdle(); robot.delay(500); SwingUtilities.invokeAndWait(() -> { JButton cancelBtn = findCancelButton(jfc); cancelBtn.doClick(); }); robot.delay(500); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28169#discussion_r2505072844 From aivanov at openjdk.org Fri Nov 7 19:44:04 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 7 Nov 2025 19:44:04 GMT Subject: RFR: JDK-8371365 : Update javax/swing/JFileChooser/bug4759934.java to use Util.findComponent() In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 19:10:47 GMT, Harshitha Onkar wrote: >> I just noticed your comment: https://github.com/openjdk/jdk/pull/27944#discussion_r2496343433 >> >>> I'm for keeping the other clicks as-is (via Robot) since we have reference to these buttons unlike the cancel button of JFileChooser and this way keep much of the original test case intact without overly modifying it. >> >> ??Since we have reference to these buttons,? it's even easier to call `frameBtn.doClick()` and `dlgBtnLoc.doClick()`. >> >> Once you get the reference to the Cancel button in the file chooser you can also use robot to click the button. >> >> Using consistently the same method to click the buttons makes the test easier to comprehend. > > I referred to the original JBS issue for which this test was created - [JDK-4759934](https://bugs.openjdk.org/browse/JDK-4759934). Looks like we can use doClick() instead of using Robot for the clicks. > > But the problem is that when we use doClick() for frameBtn and dialogBtn, JFC's click on Cancel button doesn't happen and the test fails due to timeout. This happens on macOS26, I have to test on other platforms. > > > > SwingUtilities.invokeAndWait(() -> frameBtn.doClick()); > robot.waitForIdle(); > robot.delay(500); > > SwingUtilities.invokeAndWait(() -> dialogBtn.doClick()); > robot.waitForIdle(); > robot.delay(500); > > SwingUtilities.invokeAndWait(() -> { > JButton cancelBtn = findCancelButton(jfc); > cancelBtn.doClick(); > }); > robot.delay(500); I see? It may be not worth the effort then. However, this behaviour ? clicking the Cancel button doesn't happen ? could be a bug. Why does the test time out? Even if clicking the Cancel button didn't work, the test should finish with a failure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28169#discussion_r2505202670 From honkar at openjdk.org Fri Nov 7 19:56:07 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 7 Nov 2025 19:56:07 GMT Subject: RFR: JDK-8371365 : Update javax/swing/JFileChooser/bug4759934.java to use Util.findComponent() In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 19:41:32 GMT, Alexey Ivanov wrote: >> I referred to the original JBS issue for which this test was created - [JDK-4759934](https://bugs.openjdk.org/browse/JDK-4759934). Looks like we can use doClick() instead of using Robot for the clicks. >> >> But the problem is that when we use doClick() for frameBtn and dialogBtn, JFC's click on Cancel button doesn't happen and the test fails due to timeout. This happens on macOS26, I have to test on other platforms. >> >> >> >> SwingUtilities.invokeAndWait(() -> frameBtn.doClick()); >> robot.waitForIdle(); >> robot.delay(500); >> >> SwingUtilities.invokeAndWait(() -> dialogBtn.doClick()); >> robot.waitForIdle(); >> robot.delay(500); >> >> SwingUtilities.invokeAndWait(() -> { >> JButton cancelBtn = findCancelButton(jfc); >> cancelBtn.doClick(); >> }); >> robot.delay(500); > > I see? It may be not worth the effort then. > > However, this behaviour ? clicking the Cancel button doesn't happen ? could be a bug. > > Why does the test time out? Even if clicking the Cancel button didn't work, the test should finish with a failure. I believe the test hangs at that point - cancelBtn.doClick() and does not proceed to the test condition check. I'll need to check in depth as to why this is happening. > I see? It may be not worth the effort then. I can create a separate JBS issue to look into it and as for the test changes use the doClick() for just the JFC's Cancel button. Does this sound good to you? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28169#discussion_r2505248035 From honkar at openjdk.org Fri Nov 7 20:01:54 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 7 Nov 2025 20:01:54 GMT Subject: RFR: JDK-8371365 : Update javax/swing/JFileChooser/bug4759934.java to use Util.findComponent() [v2] In-Reply-To: References: Message-ID: > /javax/swing/JFileChooser/bug4759934.java test changes related to addition of new method to Util - https://github.com/openjdk/jdk/pull/27944. Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - unused import - Merge branch 'master' into Util_bug4759934 - test update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28169/files - new: https://git.openjdk.org/jdk/pull/28169/files/35285891..f2d59e99 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28169&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28169&range=00-01 Stats: 104030 lines in 1543 files changed: 59145 ins; 35438 del; 9447 mod Patch: https://git.openjdk.org/jdk/pull/28169.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28169/head:pull/28169 PR: https://git.openjdk.org/jdk/pull/28169 From aivanov at openjdk.org Fri Nov 7 20:16:03 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 7 Nov 2025 20:16:03 GMT Subject: RFR: JDK-8371365 : Update javax/swing/JFileChooser/bug4759934.java to use Util.findComponent() [v2] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 19:53:20 GMT, Harshitha Onkar wrote: > Does this sound good to you? This is likely the best approach. It's a new problem that we discovered. It doesn't prevent integrating the change to search for the Cancel button in the file chooser, yet it would be good to investigate what goes wrong when all the buttons are clicked programmatically instead of using the robot to generate mouse clicks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28169#discussion_r2505321863 From aivanov at openjdk.org Fri Nov 7 20:33:04 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 7 Nov 2025 20:33:04 GMT Subject: RFR: JDK-8371365 : Update javax/swing/JFileChooser/bug4759934.java to use Util.findComponent() [v2] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 20:01:54 GMT, Harshitha Onkar wrote: >> /javax/swing/JFileChooser/bug4759934.java test changes related to addition of new method to Util - https://github.com/openjdk/jdk/pull/27944. > > Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - unused import > - Merge branch 'master' into Util_bug4759934 > - test update Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28169#pullrequestreview-3436233434 From duke at openjdk.org Fri Nov 7 20:39:22 2025 From: duke at openjdk.org (lawrence.andrews) Date: Fri, 7 Nov 2025 20:39:22 GMT Subject: Integrated: 8371485: ProblemList awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java for linux In-Reply-To: References: Message-ID: <1ELmE3JcXuCM9TrzZ0ueN45W3yy_JgNdzu6gBuchaJM=.d9b3ea0e-e204-4b8a-8c93-da70e04c6b66@github.com> On Fri, 7 Nov 2025 17:37:07 GMT, lawrence.andrews wrote: > Problem listing test awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java is intermittently on linux atleast from JDK 22, JDK 24 & JDK 25 . This pull request has now been integrated. Changeset: 066810c8 Author: Lawrence Andrews Committer: Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/066810c877b206a66cc87537487b17f0481646c3 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8371485: ProblemList awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java for linux Reviewed-by: azvegint ------------- PR: https://git.openjdk.org/jdk/pull/28203 From serb at openjdk.org Fri Nov 7 22:40:02 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 7 Nov 2025 22:40:02 GMT Subject: RFR: 8371163: Make GlyphView/TestGlyphBGHeight.java headless [v2] In-Reply-To: <6_mF_b8u61-cEu0VvsxXedyIAfT9fTZR9IElnjMXghA=.84359b54-4547-432f-a520-d34a68796117@github.com> References: <6_mF_b8u61-cEu0VvsxXedyIAfT9fTZR9IElnjMXghA=.84359b54-4547-432f-a520-d34a68796117@github.com> Message-ID: On Thu, 6 Nov 2025 17:51:44 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Review fix > > test/jdk/javax/swing/text/GlyphView/TestGlyphBGHeight.java line 70: > >> 68: >> 69: final BufferedImage img = createImage(); >> 70: SwingUtilities.invokeAndWait(() -> { > > You can create the text component directly on the main thread. The component will never be accessed from EDT if you perform all the operations on the main thread. It depends, the code may post some events on EDT which will cause the component be accessed on different threads, for example via [JComponent.revalidate ](https://github.com/openjdk/jdk/blob/066810c877b206a66cc87537487b17f0481646c3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4943) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28173#discussion_r2505762629 From serb at openjdk.org Sat Nov 8 00:36:04 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 8 Nov 2025 00:36:04 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v9] In-Reply-To: References: <1nxKOtN4B2h026FhyQp8t-1IOZBFPMfnif7I5a0Vnuc=.9ffffa12-226f-49ac-8b85-fac3750c649f@github.com> <3hw1X_jGyDqVuyleOkeirF2hj4ZnfuBPoG9J-e4Rw50=.914a54f6-f2f8-491d-b2af-e84dfdc5967b@github.com> Message-ID: On Thu, 6 Nov 2025 23:23:15 GMT, Damon Nguyen wrote: >I believe there may be a discussion about whether a change from this mouse movement implementation to the RobotDriver version is needed. I'm sure people would like to chime in on this. We do not need to rush the patch, we can discuss it here. Since there is an alternative implementation we can discuss the pros and cons. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26969#issuecomment-3505479118 From serb at openjdk.org Sat Nov 8 00:37:07 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 8 Nov 2025 00:37:07 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 15:06:51 GMT, Matthias Baesken wrote: >> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. >> But for other JDK native libs, we do not have support for this feature. >> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Add lto to EXTRA_FLAGS, not to OPT make/modules/java.desktop/lib/ClientLibraries.gmk line 229: > 227: EXCLUDES := $(LIBSPLASHSCREEN_EXCLUDES), \ > 228: OPTIMIZATION := SIZE, \ > 229: LINK_TIME_OPTIMIZATION := true, \ You do not need to change it in this patch, it can be done separately per lib. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2505913339 From serb at openjdk.org Sat Nov 8 01:11:16 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 8 Nov 2025 01:11:16 GMT Subject: RFR: 8368729: Add appropriate checks in java.awt.image.Kernel constructor In-Reply-To: References: <7DpQRTNILJjPS0vCTMv1_EYUUYn_L797H-15bvDnQuk=.7d607f81-0477-4aab-a0d3-86624ba7508d@github.com> <_94TDObFPwQ6uoerq8PSnI7OR0ge67DfdHGbfACo5Gw=.9814805f-2a6c-432a-9535-88711f12d042@github.com> <5PSIpKWEsYE-hJyqSik3iUJ7mG9QnfI14XNez3Xfhc4=.77b50ab4-1d69-402e-bb6f-b389f7f7d63e@github.com> Message-ID: On Fri, 7 Nov 2025 09:41:57 GMT, Jayathirth D V wrote: >NPE which was thrown before was undefined behaviour. >There is no objection in CSR request also. I would like to continue keeping usage of IAE. Most of the new code in the JDK throws NullPointerException for null arguments. We already had a similar discussion recently, and most of the same arguments apply here as well: https://mail.openjdk.org/pipermail/client-libs-dev/2025-May/028879.html https://github.com/openjdk/jdk/pull/24991/commits/040e8ddddc4d46b60d047f7f5fbe19a6c2c5683b It also appears that this is the first usage of "@throws IllegalArgumentException" for null parameters in that package, but there are some usages of NPE for null. >If majority of reviewers have objections, we can take it up in follow-up issue. I have filed: https://bugs.openjdk.org/browse/JDK-8371501 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28127#discussion_r2505940997 From kizune at openjdk.org Sat Nov 8 23:22:41 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Sat, 8 Nov 2025 23:22:41 GMT Subject: RFR: 8371508: [macos] In Aqua LaF menu items layout is incorrect in RTL orientation Message-ID: The problem is that we do not correct the icon and text re-alignment that happens when we call SwingUtilities.layoutCompoundLabel Here's the comparison of the alignment before and after the fix Before: before_fix After: after_fix ------------- Commit messages: - 8371508: [macos] In Aqua LaF menu items layout is incorrect in RTL orientation Changes: https://git.openjdk.org/jdk/pull/28210/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28210&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371508 Stats: 35 lines in 2 files changed: 30 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28210.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28210/head:pull/28210 PR: https://git.openjdk.org/jdk/pull/28210 From kizune at openjdk.org Sat Nov 8 23:26:19 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Sat, 8 Nov 2025 23:26:19 GMT Subject: RFR: 8371508: [macos] In Aqua LaF menu items layout is incorrect in RTL orientation [v2] In-Reply-To: References: Message-ID: <7lU-DpazJjVmfcY_pN7Y1-nV8_5zajs40JoWzXwe2cE=.f87c6c0f-049c-4f70-8d0e-a285880d4e25@github.com> > The problem is that we do not correct the icon and text re-alignment that happens when we call SwingUtilities.layoutCompoundLabel > > Here's the comparison of the alignment before and after the fix > Before: > before_fix > After: > after_fix Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Use correct bug id in the test. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28210/files - new: https://git.openjdk.org/jdk/pull/28210/files/9ae94ead..0427d6a1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28210&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28210&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28210.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28210/head:pull/28210 PR: https://git.openjdk.org/jdk/pull/28210 From duke at openjdk.org Sat Nov 8 23:59:02 2025 From: duke at openjdk.org (lawrence.andrews) Date: Sat, 8 Nov 2025 23:59:02 GMT Subject: RFR: 8371508: [macos] In Aqua LaF menu items layout is incorrect in RTL orientation [v2] In-Reply-To: <7lU-DpazJjVmfcY_pN7Y1-nV8_5zajs40JoWzXwe2cE=.f87c6c0f-049c-4f70-8d0e-a285880d4e25@github.com> References: <7lU-DpazJjVmfcY_pN7Y1-nV8_5zajs40JoWzXwe2cE=.f87c6c0f-049c-4f70-8d0e-a285880d4e25@github.com> Message-ID: On Sat, 8 Nov 2025 23:26:19 GMT, Alexander Zuev wrote: >> The problem is that we do not correct the icon and text re-alignment that happens when we call SwingUtilities.layoutCompoundLabel >> >> Here's the comparison of the alignment before and after the fix >> Before: >> before_fix >> After: >> after_fix > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Use correct bug id in the test. Question on sub menu arrow . I see both the LTR & RTL are same. Should not be different > ------------- PR Comment: https://git.openjdk.org/jdk/pull/28210#issuecomment-3507180851 From psadhukhan at openjdk.org Sun Nov 9 07:27:10 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Sun, 9 Nov 2025 07:27:10 GMT Subject: Integrated: 8299304: Test "java/awt/print/PrinterJob/PageDialogTest.java" fails on macOS 13 x64 because the Page Dialog blocks the Toolkit In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 05:44:53 GMT, Prasanta Sadhukhan wrote: > mac printer dialog blocks underlying window even on native platform so this is not applicable to the test so restricting to run on osx This pull request has now been integrated. Changeset: 4a14c81a Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/4a14c81a06ab2be1d56cd01288135fbd369eb9c7 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod 8299304: Test "java/awt/print/PrinterJob/PageDialogTest.java" fails on macOS 13 x64 because the Page Dialog blocks the Toolkit Reviewed-by: tr ------------- PR: https://git.openjdk.org/jdk/pull/27243 From psadhukhan at openjdk.org Sun Nov 9 07:28:17 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Sun, 9 Nov 2025 07:28:17 GMT Subject: Integrated: 8371163: Make GlyphView/TestGlyphBGHeight.java headless In-Reply-To: References: Message-ID: On Thu, 6 Nov 2025 07:37:49 GMT, Prasanta Sadhukhan wrote: > Test is made headless This pull request has now been integrated. Changeset: ebd1c038 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/ebd1c03829c354007a4ca9971be313d19eac2373 Stats: 62 lines in 1 file changed: 9 ins; 28 del; 25 mod 8371163: Make GlyphView/TestGlyphBGHeight.java headless 8371377: javax/swing/text/GlyphView/TestGlyphBGHeight.java fails in Ubuntu 24.04 X11 Reviewed-by: aivanov ------------- PR: https://git.openjdk.org/jdk/pull/28173 From psadhukhan at openjdk.org Mon Nov 10 02:07:29 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 10 Nov 2025 02:07:29 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v7] In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 07:11:21 GMT, Prasanta Sadhukhan wrote: >> If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder` >> it throws NPE which is not mentioned in the spec as the expected outcome. >> Fixed the NPE and the spec > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > javadoc update I guess spec clarification isn't strictly necessary for this PR..The code change would take care of the NPE and since RDP1 is approaching with not much time left for CSR approval, I would like to make this PR code-fix only and remove the spec update to do for another time.. Any objections? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27949#issuecomment-3509130916 From mbaesken at openjdk.org Mon Nov 10 08:09:07 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 10 Nov 2025 08:09:07 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: Message-ID: On Sat, 8 Nov 2025 00:34:02 GMT, Sergey Bylokhov wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Add lto to EXTRA_FLAGS, not to OPT > > make/modules/java.desktop/lib/ClientLibraries.gmk line 229: > >> 227: EXCLUDES := $(LIBSPLASHSCREEN_EXCLUDES), \ >> 228: OPTIMIZATION := SIZE, \ >> 229: LINK_TIME_OPTIMIZATION := true, \ > > You do not need to change it in this patch, it can be done separately per lib. I think there was the concern raised previously, that without setting it for at least one lib, nobody would use/try it and the feature would 'rot' . (there was also the idea to add a configure option to enable/disable the whole 'lto on jdk native libs' ; I can add this but currently not sure if this is desired) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2509194261 From aivanov at openjdk.org Mon Nov 10 14:29:04 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 10 Nov 2025 14:29:04 GMT Subject: RFR: 8371163: Make GlyphView/TestGlyphBGHeight.java headless [v2] In-Reply-To: References: <6_mF_b8u61-cEu0VvsxXedyIAfT9fTZR9IElnjMXghA=.84359b54-4547-432f-a520-d34a68796117@github.com> Message-ID: On Fri, 7 Nov 2025 22:37:17 GMT, Sergey Bylokhov wrote: > It depends, the code may post some events on EDT which will cause the component be accessed on different threads, for example via [JComponent.revalidate ](https://github.com/openjdk/jdk/blob/066810c877b206a66cc87537487b17f0481646c3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4943) Yes, it's possible? I still think it is safe in this particular case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28173#discussion_r2510774876 From duke at openjdk.org Mon Nov 10 15:19:17 2025 From: duke at openjdk.org (duke) Date: Mon, 10 Nov 2025 15:19:17 GMT Subject: RFR: 8251928: [macos] the printer DPI always be 72, cause some content lost when print out [v9] In-Reply-To: References: Message-ID: <6LsoYEsfMK3zz4_G06s4-k_lpJdftA5suC2i8s-96G0=.beae989d-8b9b-43a1-ae77-e2ce2bf9e0bb@github.com> On Sat, 1 Nov 2025 14:31:41 GMT, GennadiyKrivoshein wrote: >> The fix for the https://bugs.openjdk.org/browse/JDK-8251928. >> >> **Description**. >> This PR contains changes to be able to print with DPI higher than 72 on macOS, set default CPrinterJob DPI is 300 like in the PSPrinterJob. >> >> As described in the macOS drawing guide, the following steps are required to draw with high DPI (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html#//apple_ref/doc/uid/TP40003290-CH204-BCICIJAJ): >> 1. Convert the user-space point, size, or rectangle value to device space coordinates; >> 2. Normalize the value in device space so that it is aligned to the appropriate pixel boundary; >> 3. Convert the normalized value back to user space; >> 4. Draw your content using the adjusted value. >> >> The 1-st step is now implemented in the CPrinterJob, a Graphics provided to the print method adjusted to a printer's DPI. >> The 2-nd step is a drawing process in the java code (without changes). >> The 3-rd step is now implemented in the PrinterView.m, the drawing scaled back to the 72 DPI. >> The 4-th step is a drawing process in the native code (without changes). >> >> **Tests**. >> I run all tests from javax.print package and there is no any regression. >> New test covers macOS and Linux only because we know its default DPI - 300. > > GennadiyKrivoshein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - Merge branch 'openjdk:master' into macOS_printing_DPI > - Revert PeekGraphics > - Merge branch 'openjdk:master' into macOS_printing_DPI > - move scaling to GraphicsConfig, update PeekGraphics > - revert CGraphicsDevice.m constants. Update orientation constant usage > - remove setDevClip usage. Update names. Handle page format orientation. > - Merge branch 'openjdk:master' into macOS_printing_DPI > - Merge branch 'openjdk:master' into macOS_printing_DPI > - [macos] the printer DPI always be 72 @GennadiyKrivoshein Your change (at version 5767f1ceb8a62be9f4b76b0c571c97decdbd3a76) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25489#issuecomment-3512309616 From dnguyen at openjdk.org Mon Nov 10 18:45:08 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 10 Nov 2025 18:45:08 GMT Subject: RFR: JDK-8371365 : Update javax/swing/JFileChooser/bug4759934.java to use Util.findComponent() [v2] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 20:01:54 GMT, Harshitha Onkar wrote: >> /javax/swing/JFileChooser/bug4759934.java test changes related to addition of new method to Util - https://github.com/openjdk/jdk/pull/27944. > > Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - unused import > - Merge branch 'master' into Util_bug4759934 > - test update LGTM. Seems like this will be more consistent and reads better. Tested and passes. ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/28169#pullrequestreview-3444645819 From serb at openjdk.org Mon Nov 10 20:52:52 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 10 Nov 2025 20:52:52 GMT Subject: RFR: 8299304: Test "java/awt/print/PrinterJob/PageDialogTest.java" fails on macOS 13 x64 because the Page Dialog blocks the Toolkit In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 07:37:08 GMT, Prasanta Sadhukhan wrote: >I have asked @lawrence-andrew to check with ATR testing team as to why it was not marked as failure for macos? What was the answer? Did you check if this is not a product bug? The appearance of the java page dialog looks different from the native dialog used by some native apps. Maybe we set the parent of the dialog in the wrong way? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27243#issuecomment-3513842602 From acobbs at openjdk.org Mon Nov 10 22:24:52 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 10 Nov 2025 22:24:52 GMT Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression [v5] In-Reply-To: References: Message-ID: <26Gs2omFeLXWjo85AUbAb34PpolWLLsjB2aMS92fNKY=.04fb0491-212d-4212-9dde-08250f361053@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 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 ------------- Changes: https://git.openjdk.org/jdk/pull/25167/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=04 Stats: 1667 lines in 35 files changed: 1492 ins; 49 del; 126 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 kizune at openjdk.org Tue Nov 11 02:00:06 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 11 Nov 2025 02:00:06 GMT Subject: RFR: 8371508: [macos] In Aqua LaF menu items layout is incorrect in RTL orientation [v2] In-Reply-To: References: <7lU-DpazJjVmfcY_pN7Y1-nV8_5zajs40JoWzXwe2cE=.f87c6c0f-049c-4f70-8d0e-a285880d4e25@github.com> Message-ID: On Sat, 8 Nov 2025 23:56:35 GMT, lawrence.andrews wrote: > Question on sub menu arrow . I see both the LTR & RTL are same. Should not be different > I think it should be, but it is initialized statically in AquaImageFactory. It might be a good idea to change it for RTL menu items but i think it is out of scope for this particular fix - here we only deal with the incorrect layout of the menu item components. I can create a follow-up bug to fix for the wrong arrow icon used for RTL menus to fix in the future. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28210#issuecomment-3514653367 From duke at openjdk.org Tue Nov 11 03:52:15 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Tue, 11 Nov 2025 03:52:15 GMT Subject: Integrated: 8251928: [macos] the printer DPI always be 72, cause some content lost when print out In-Reply-To: References: Message-ID: On Wed, 28 May 2025 10:29:17 GMT, GennadiyKrivoshein wrote: > The fix for the https://bugs.openjdk.org/browse/JDK-8251928. > > **Description**. > This PR contains changes to be able to print with DPI higher than 72 on macOS, set default CPrinterJob DPI is 300 like in the PSPrinterJob. > > As described in the macOS drawing guide, the following steps are required to draw with high DPI (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html#//apple_ref/doc/uid/TP40003290-CH204-BCICIJAJ): > 1. Convert the user-space point, size, or rectangle value to device space coordinates; > 2. Normalize the value in device space so that it is aligned to the appropriate pixel boundary; > 3. Convert the normalized value back to user space; > 4. Draw your content using the adjusted value. > > The 1-st step is now implemented in the CPrinterJob, a Graphics provided to the print method adjusted to a printer's DPI. > The 2-nd step is a drawing process in the java code (without changes). > The 3-rd step is now implemented in the PrinterView.m, the drawing scaled back to the 72 DPI. > The 4-th step is a drawing process in the native code (without changes). > > **Tests**. > I run all tests from javax.print package and there is no any regression. > New test covers macOS and Linux only because we know its default DPI - 300. This pull request has now been integrated. Changeset: 76a1109d Author: GennadiyKrivoshein <164895822+GennadiyKrivoshein at users.noreply.github.com> Committer: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/76a1109d6fc7baac9ebc7accff800ef8927931bb Stats: 379 lines in 5 files changed: 367 ins; 1 del; 11 mod 8251928: [macos] the printer DPI always be 72, cause some content lost when print out Reviewed-by: psadhukhan, prr ------------- PR: https://git.openjdk.org/jdk/pull/25489 From tr at openjdk.org Tue Nov 11 04:55:06 2025 From: tr at openjdk.org (Tejesh R) Date: Tue, 11 Nov 2025 04:55:06 GMT Subject: RFR: 8371508: [macos] In Aqua LaF menu items layout is incorrect in RTL orientation [v2] In-Reply-To: <7lU-DpazJjVmfcY_pN7Y1-nV8_5zajs40JoWzXwe2cE=.f87c6c0f-049c-4f70-8d0e-a285880d4e25@github.com> References: <7lU-DpazJjVmfcY_pN7Y1-nV8_5zajs40JoWzXwe2cE=.f87c6c0f-049c-4f70-8d0e-a285880d4e25@github.com> Message-ID: On Sat, 8 Nov 2025 23:26:19 GMT, Alexander Zuev wrote: >> The problem is that we do not correct the icon and text re-alignment that happens when we call SwingUtilities.layoutCompoundLabel >> >> Here's the comparison of the alignment before and after the fix >> Before: >> before_fix >> After: >> after_fix > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Use correct bug id in the test. test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 60: > 58: * @test id=aqua > 59: * @bug 8371508 > 60: * @requires (os.family == "mac") I guess now the test can be run in window and mac OS ? Any idea on Nimbus L&F in windows os ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28210#discussion_r2512828684 From psadhukhan at openjdk.org Tue Nov 11 06:46:45 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 11 Nov 2025 06:46:45 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v8] In-Reply-To: References: Message-ID: > If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder` > it throws NPE which is not mentioned in the spec as the expected outcome. > Fixed the NPE and the spec Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: - Code fix only - Code fix only ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27949/files - new: https://git.openjdk.org/jdk/pull/27949/files/f68195a6..fdd91b7b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27949&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27949&range=06-07 Stats: 33 lines in 2 files changed: 0 ins; 30 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27949.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27949/head:pull/27949 PR: https://git.openjdk.org/jdk/pull/27949 From psadhukhan at openjdk.org Tue Nov 11 06:50:25 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 11 Nov 2025 06:50:25 GMT Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v7] In-Reply-To: References: Message-ID: > It seems JList.getScrollableUnitIncrement can sometime return 0 instead of positive number which is not specified in the javadoc which can lead to confusion. Clarified javadoc as to when it can return 0. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: spec wording ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26500/files - new: https://git.openjdk.org/jdk/pull/26500/files/9224a1a8..3dcf2347 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26500&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26500&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26500.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26500/head:pull/26500 PR: https://git.openjdk.org/jdk/pull/26500 From tr at openjdk.org Tue Nov 11 11:22:27 2025 From: tr at openjdk.org (Tejesh R) Date: Tue, 11 Nov 2025 11:22:27 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v8] In-Reply-To: References: Message-ID: <8qfwnFfYIBiIScLmyJYdp7nwRHl62gYY54hW1dhKilw=.20d5c918-8641-4bf8-bce6-46bebd0c1a83@github.com> On Tue, 11 Nov 2025 06:46:45 GMT, Prasanta Sadhukhan wrote: >> If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder` >> it throws NPE which is not mentioned in the spec as the expected outcome. >> Fixed the NPE and the spec > > Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: > > - Code fix only > - Code fix only Marked as reviewed by tr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27949#pullrequestreview-3447558915 From tr at openjdk.org Tue Nov 11 11:23:25 2025 From: tr at openjdk.org (Tejesh R) Date: Tue, 11 Nov 2025 11:23:25 GMT Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v7] In-Reply-To: References: Message-ID: <_tY3fk8zC2In-oPxI6221EvgK1B6f09fF1j_bxgf7OU=.83ffedd9-fb69-42aa-879e-22540a3aa777@github.com> On Tue, 11 Nov 2025 06:50:25 GMT, Prasanta Sadhukhan wrote: >> It seems JList.getScrollableUnitIncrement can sometime return 0 instead of positive number which is not specified in the javadoc which can lead to confusion. Clarified javadoc as to when it can return 0. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > spec wording src/java.desktop/share/classes/javax/swing/JList.java line 2510: > 2508: * @param direction less or equal to zero to scroll up/back, > 2509: * greater than zero for down/forward > 2510: * @return the non-negative "unit" increment value for scrolling in the specified direction I guess the length is exceeding 80 column. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26500#discussion_r2513848654 From psadhukhan at openjdk.org Tue Nov 11 11:55:59 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 11 Nov 2025 11:55:59 GMT Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v8] In-Reply-To: References: Message-ID: <5dc6nhWoY6uh21_XogROhl0OxcfSOP-0qaST7HOkQjE=.7ddc3f97-6658-4d31-b2fa-8eb5c4e6e406@github.com> > It seems JList.getScrollableUnitIncrement can sometime return 0 instead of positive number which is not specified in the javadoc which can lead to confusion. Clarified javadoc as to when it can return 0. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: spec wording ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26500/files - new: https://git.openjdk.org/jdk/pull/26500/files/3dcf2347..92fd3e3c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26500&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26500&range=06-07 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26500.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26500/head:pull/26500 PR: https://git.openjdk.org/jdk/pull/26500 From psadhukhan at openjdk.org Tue Nov 11 11:56:02 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 11 Nov 2025 11:56:02 GMT Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v7] In-Reply-To: <_tY3fk8zC2In-oPxI6221EvgK1B6f09fF1j_bxgf7OU=.83ffedd9-fb69-42aa-879e-22540a3aa777@github.com> References: <_tY3fk8zC2In-oPxI6221EvgK1B6f09fF1j_bxgf7OU=.83ffedd9-fb69-42aa-879e-22540a3aa777@github.com> Message-ID: <6gs-sa8CRYQTXHfEiigop-doAgr_oW-OYXjpSJ4p-Yo=.5a39ac57-a824-44e9-8b45-ef6b642c83e8@github.com> On Tue, 11 Nov 2025 11:20:58 GMT, Tejesh R wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> spec wording > > src/java.desktop/share/classes/javax/swing/JList.java line 2510: > >> 2508: * @param direction less or equal to zero to scroll up/back, >> 2509: * greater than zero for down/forward >> 2510: * @return the non-negative "unit" increment value for scrolling in the specified direction > > I guess the length is exceeding 80 column. updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26500#discussion_r2513951217 From jdv at openjdk.org Tue Nov 11 13:16:19 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 11 Nov 2025 13:16:19 GMT Subject: RFR: 8363950: Incorrect jtreg header in TestLayoutVsICU.java Message-ID: TestLayoutVsICU was added when harfbuzz is integrated as default opentype layout engine under https://bugs.openjdk.org/browse/JDK-8143177 to replace ICU in JDK 9. ICU code is removed under https://bugs.openjdk.org/browse/JDK-8183978 in JDK 10. This test was used to manually check harfbuzz generated glyphs with already stored ICU one from the XML file. This manual test has many dependencies to make it work and it is not documented properly. Harfbuzz has gone through many iterations of stabilization already. Since this test is almost a no-op we are planning to delete it. More details about history is in JBS. ------------- Commit messages: - 8363950: Incorrect jtreg header in TestLayoutVsICU.java Changes: https://git.openjdk.org/jdk/pull/28234/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28234&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8363950 Stats: 2716 lines in 2 files changed: 0 ins; 2716 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28234.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28234/head:pull/28234 PR: https://git.openjdk.org/jdk/pull/28234 From tr at openjdk.org Tue Nov 11 13:44:05 2025 From: tr at openjdk.org (Tejesh R) Date: Tue, 11 Nov 2025 13:44:05 GMT Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v8] In-Reply-To: <5dc6nhWoY6uh21_XogROhl0OxcfSOP-0qaST7HOkQjE=.7ddc3f97-6658-4d31-b2fa-8eb5c4e6e406@github.com> References: <5dc6nhWoY6uh21_XogROhl0OxcfSOP-0qaST7HOkQjE=.7ddc3f97-6658-4d31-b2fa-8eb5c4e6e406@github.com> Message-ID: On Tue, 11 Nov 2025 11:55:59 GMT, Prasanta Sadhukhan wrote: >> It seems JList.getScrollableUnitIncrement can sometime return 0 instead of positive number which is not specified in the javadoc which can lead to confusion. Clarified javadoc as to when it can return 0. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > spec wording Marked as reviewed by tr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26500#pullrequestreview-3448130401 From azvegint at openjdk.org Tue Nov 11 16:17:17 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 11 Nov 2025 16:17:17 GMT Subject: RFR: 8363950: Incorrect jtreg header in TestLayoutVsICU.java In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 13:06:44 GMT, Jayathirth D V wrote: > TestLayoutVsICU was added when harfbuzz is integrated as default opentype layout engine under https://bugs.openjdk.org/browse/JDK-8143177 to replace ICU in JDK 9. ICU code is removed under https://bugs.openjdk.org/browse/JDK-8183978 in JDK 10. This test was used to manually check harfbuzz generated glyphs with already stored ICU one from the XML file. > > This manual test has many dependencies to make it work and it is not documented properly. Harfbuzz has gone through many iterations of stabilization already. Since this test is almost a no-op we are planning to delete it. More details about history is in JBS. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28234#pullrequestreview-3448842068 From azvegint at openjdk.org Tue Nov 11 16:31:06 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 11 Nov 2025 16:31:06 GMT Subject: RFR: JDK-8371365 : Update javax/swing/JFileChooser/bug4759934.java to use Util.findComponent() [v2] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 20:01:54 GMT, Harshitha Onkar wrote: >> /javax/swing/JFileChooser/bug4759934.java test changes related to addition of new method to Util - https://github.com/openjdk/jdk/pull/27944. > > Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - unused import > - Merge branch 'master' into Util_bug4759934 > - test update Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28169#pullrequestreview-3448913466 From dgredler at openjdk.org Tue Nov 11 18:56:08 2025 From: dgredler at openjdk.org (Daniel Gredler) Date: Tue, 11 Nov 2025 18:56:08 GMT Subject: RFR: 8368702: [macosx] Printing text with composite fonts loses font transform In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 11:46:47 GMT, Daniel Gredler wrote: > When printing text on macOS, if the text uses a composite font (a logical font composed of more than one physical font) with a custom affine transform, the transform can be lost, and the text printed without the transform applied. > > This is one of a few issues affecting the problem listed manual test `java/awt/print/PrinterJob/PrintTextTest.java` on macOS, and can be observed on page 10, on the last line ("TextLayout 2"). Without the fix, the text on this line is not stretched across the x-axis, resulting in large gaps of white space between runs of different script types. This one still needs two reviews, if any reviewers have some free time. Note that you don't actually need to print to paper to check the `java/awt/print/PrinterJob/PrintTextTest.java` test results, you can use "print to PDF" to check the print output. You do, however, need a mac. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27544#issuecomment-3518327523 From kizune at openjdk.org Tue Nov 11 20:02:06 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 11 Nov 2025 20:02:06 GMT Subject: RFR: 8371508: [macos] In Aqua LaF menu items layout is incorrect in RTL orientation [v2] In-Reply-To: References: <7lU-DpazJjVmfcY_pN7Y1-nV8_5zajs40JoWzXwe2cE=.f87c6c0f-049c-4f70-8d0e-a285880d4e25@github.com> Message-ID: On Tue, 11 Nov 2025 04:49:16 GMT, Tejesh R wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Use correct bug id in the test. > > test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 60: > >> 58: * @test id=aqua >> 59: * @bug 8371508 >> 60: * @requires (os.family == "mac") > > I guess now the test can be run in window and mac OS ? Any idea on Nimbus L&F in windows os ? This is Aqua LnF specific fix and Aqua LnF is only available on macOS so this exact test case can only be ran on mac. Initially test was used to validate the layout for Windows and Motif LnF. I haven't tried Nimbus yet. If there are problems with Nimbus on Windows they might be addressed separately. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28210#discussion_r2515562912 From jdv at openjdk.org Wed Nov 12 04:47:09 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 12 Nov 2025 04:47:09 GMT Subject: Integrated: 8363950: Incorrect jtreg header in TestLayoutVsICU.java In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 13:06:44 GMT, Jayathirth D V wrote: > TestLayoutVsICU was added when harfbuzz is integrated as default opentype layout engine under https://bugs.openjdk.org/browse/JDK-8143177 to replace ICU in JDK 9. ICU code is removed under https://bugs.openjdk.org/browse/JDK-8183978 in JDK 10. This test was used to manually check harfbuzz generated glyphs with already stored ICU one from the XML file. > > This manual test has many dependencies to make it work and it is not documented properly. Harfbuzz has gone through many iterations of stabilization already. Since this test is almost a no-op we are planning to delete it. More details about history is in JBS. This pull request has now been integrated. Changeset: 15dcbf0b Author: Jayathirth D V URL: https://git.openjdk.org/jdk/commit/15dcbf0bc80b3c1ab09e44b9447c639780cce65e Stats: 2716 lines in 2 files changed: 0 ins; 2716 del; 0 mod 8363950: Incorrect jtreg header in TestLayoutVsICU.java Reviewed-by: azvegint ------------- PR: https://git.openjdk.org/jdk/pull/28234 From tr at openjdk.org Wed Nov 12 04:53:02 2025 From: tr at openjdk.org (Tejesh R) Date: Wed, 12 Nov 2025 04:53:02 GMT Subject: RFR: 8371508: [macos] In Aqua LaF menu items layout is incorrect in RTL orientation [v2] In-Reply-To: <7lU-DpazJjVmfcY_pN7Y1-nV8_5zajs40JoWzXwe2cE=.f87c6c0f-049c-4f70-8d0e-a285880d4e25@github.com> References: <7lU-DpazJjVmfcY_pN7Y1-nV8_5zajs40JoWzXwe2cE=.f87c6c0f-049c-4f70-8d0e-a285880d4e25@github.com> Message-ID: On Sat, 8 Nov 2025 23:26:19 GMT, Alexander Zuev wrote: >> The problem is that we do not correct the icon and text re-alignment that happens when we call SwingUtilities.layoutCompoundLabel >> >> Here's the comparison of the alignment before and after the fix >> Before: >> before_fix >> After: >> after_fix > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Use correct bug id in the test. src/java.desktop/macosx/classes/com/apple/laf/AquaMenuPainter.java line 538: > 536: checkIconR.x = w - (checkIconR.x + checkIconR.width); > 537: if (menuItem.getHorizontalTextPosition() != SwingConstants.CENTER) { > 538: int d = textR.x - iconR.x; `d` refers to difference ? Could be `diff` for readability ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28210#discussion_r2516754264 From serb at openjdk.org Wed Nov 12 07:15:11 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 12 Nov 2025 07:15:11 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: Message-ID: <2UyKPJka869d7X4QtgbdbiGyYPkYnJH1DmRCpinPJMA=.6080b598-0e51-4ec6-bc72-7b0d68ef42d4@github.com> On Mon, 10 Nov 2025 08:06:21 GMT, Matthias Baesken wrote: >I think there was the concern raised previously, that without setting it for at least one lib, nobody would use/try it and the feature would 'rot' . I see, I'll run the tests for this lib then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2517166399 From psadhukhan at openjdk.org Wed Nov 12 08:28:07 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 12 Nov 2025 08:28:07 GMT Subject: RFR: 8368702: [macosx] Printing text with composite fonts loses font transform In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 11:46:47 GMT, Daniel Gredler wrote: > When printing text on macOS, if the text uses a composite font (a logical font composed of more than one physical font) with a custom affine transform, the transform can be lost, and the text printed without the transform applied. > > This is one of a few issues affecting the problem listed manual test `java/awt/print/PrinterJob/PrintTextTest.java` on macOS, and can be observed on page 10, on the last line ("TextLayout 2"). Without the fix, the text on this line is not stretched across the x-axis, resulting in large gaps of white space between runs of different script types. LGTM.. ------------- Marked as reviewed by psadhukhan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27544#pullrequestreview-3452194542 From psadhukhan at openjdk.org Wed Nov 12 08:53:46 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 12 Nov 2025 08:53:46 GMT Subject: RFR: 8042054: JTree.updateUI uses out-of-date item size information Message-ID: `JTree.updateUI` calculate item sizes from the cell renderer, but it doesn't call `updateUI `on the cell renderer until afterwards. This leads to incorrect size calculation, which is observed when we switch from one L&F to another where it is seen that all tree items are slightly too cramped, with too little space between rows and text are abbreviated. Fix is to ensure `JTree.updateUI` update the cell renderer before updating the UI. CI testing is ok.. Before fix image After fix image ------------- Commit messages: - 8042054: JTree.updateUI uses out-of-date item size information - 8042054: JTree.updateUI uses out-of-date item size information Changes: https://git.openjdk.org/jdk/pull/28258/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28258&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8042054 Stats: 105 lines in 2 files changed: 102 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28258.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28258/head:pull/28258 PR: https://git.openjdk.org/jdk/pull/28258 From mbaesken at openjdk.org Wed Nov 12 09:03:06 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 12 Nov 2025 09:03:06 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: <2UyKPJka869d7X4QtgbdbiGyYPkYnJH1DmRCpinPJMA=.6080b598-0e51-4ec6-bc72-7b0d68ef42d4@github.com> References: <2UyKPJka869d7X4QtgbdbiGyYPkYnJH1DmRCpinPJMA=.6080b598-0e51-4ec6-bc72-7b0d68ef42d4@github.com> Message-ID: On Wed, 12 Nov 2025 07:12:03 GMT, Sergey Bylokhov wrote: > I see, I'll run the tests for this lib then. Great, thanks ! Please tell if it works for you and what are the size reductions you get for the lib (mostly for gcc). Also please tell about your opinion on the configure option to enable/disable the whole 'lto on jdk native libs' . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2517462352 From psadhukhan at openjdk.org Wed Nov 12 10:05:06 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 12 Nov 2025 10:05:06 GMT Subject: RFR: 8371508: [macos] In Aqua LaF menu items layout is incorrect in RTL orientation [v2] In-Reply-To: <7lU-DpazJjVmfcY_pN7Y1-nV8_5zajs40JoWzXwe2cE=.f87c6c0f-049c-4f70-8d0e-a285880d4e25@github.com> References: <7lU-DpazJjVmfcY_pN7Y1-nV8_5zajs40JoWzXwe2cE=.f87c6c0f-049c-4f70-8d0e-a285880d4e25@github.com> Message-ID: <7m34qGlFammbS9KJZMP-5YE7tM7l2zyz7mntUC4cm60=.7a530988-b17f-4d44-be1e-72a1c442dd35@github.com> On Sat, 8 Nov 2025 23:26:19 GMT, Alexander Zuev wrote: >> The problem is that we do not correct the icon and text re-alignment that happens when we call SwingUtilities.layoutCompoundLabel >> >> Here's the comparison of the alignment before and after the fix >> Before: >> before_fix >> After: >> after_fix > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Use correct bug id in the test. It seems the check icon is almost overlapping with text.....maybe a little more gap is needed... image unlike what we have in native image Also, there is a closed test ManualBug6458123.java where the alignment seems to be wrong image whereas it should have been image Probably CENTER check you added should be extended.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28210#issuecomment-3521095162 From psadhukhan at openjdk.org Wed Nov 12 10:24:04 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 12 Nov 2025 10:24:04 GMT Subject: RFR: 8371508: [macos] In Aqua LaF menu items layout is incorrect in RTL orientation [v2] In-Reply-To: <7lU-DpazJjVmfcY_pN7Y1-nV8_5zajs40JoWzXwe2cE=.f87c6c0f-049c-4f70-8d0e-a285880d4e25@github.com> References: <7lU-DpazJjVmfcY_pN7Y1-nV8_5zajs40JoWzXwe2cE=.f87c6c0f-049c-4f70-8d0e-a285880d4e25@github.com> Message-ID: <_EYCSLQ1PnDbAfmh5xdHOmkwRKdlM-h8N49mEwc_Hwk=.1f0cf52c-123e-42ed-af02-108056809cff@github.com> On Sat, 8 Nov 2025 23:26:19 GMT, Alexander Zuev wrote: >> The problem is that we do not correct the icon and text re-alignment that happens when we call SwingUtilities.layoutCompoundLabel >> >> Here's the comparison of the alignment before and after the fix >> Before: >> before_fix >> After: >> after_fix > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Use correct bug id in the test. Also I couldn't find in native that it supports BOTH check mark and icon together..seems like it's either-or concept.. but in java AquaL&F we are supporting both icon and checkmark together for a menu item as can be seen above...Not sure if it will be a bug.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28210#issuecomment-3521181338 From psadhukhan at openjdk.org Wed Nov 12 11:49:24 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 12 Nov 2025 11:49:24 GMT Subject: RFR: 8371066: Remove unused class TextSourceLabel and associated class hierarchy In-Reply-To: References: Message-ID: <2pBvh3DquN77B20GhcfU6KOu63Nly0XFZsu5k0Pz5bo=.e18ae1d0-20cf-4a85-b902-158026496c7e@github.com> On Fri, 31 Oct 2025 17:17:06 GMT, Daniel Gredler wrote: > The class `TextSourceLabel` is unused, as is the associated factory method `TextLabelFactory.createSimple(...)`. > > The abstractions provided by the abstract classes `TextLabel` and `ExtendedTextLabel` only make sense when there are two types of text labels (`TextSourceLabel` and `ExtendedTextSourceLabel`). With the deletion of `TextSourceLabel`, both `TextLabel` and `ExtendedTextLabel` can also be removed. > > The JavaDoc for the abstract methods in `TextLabel` and `ExtendedTextLabel`, which are implemented in `ExtendedTextSourceLabel`, was moved to `ExtendedTextSourceLabel` prior to the deletion of these two classes. > > The few small convenience methods in `TextLabel` and `ExtendedTextLabel` were also moved to `ExtendedTextSourceLabel` prior to the deletion of these two classes. > > I would have liked to give the combined `TextLabel` + `ExtendedTextLabel` + `ExtendedTextSourceLabel` class the name `TextLabel`, but I've used `ExtendedTextSourceLabel` instead because it makes the diff much smaller and maximizes code history traceability. > > See initial mailing list discussion: https://mail.openjdk.org/pipermail/client-libs-dev/2025-September/032302.html Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28090#pullrequestreview-3453031576 From aivanov at openjdk.org Wed Nov 12 12:01:09 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 12 Nov 2025 12:01:09 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v8] In-Reply-To: References: Message-ID: <4ntGE91uWjSi9JEBMv_p7B0NEpvGwczBk1-uDaWQmRA=.085bb21c-2dc0-442e-9554-3a8355a52488@github.com> On Tue, 11 Nov 2025 06:46:45 GMT, Prasanta Sadhukhan wrote: >> If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder` >> it throws NPE which is not mentioned in the spec as the expected outcome. >> Fixed the NPE and the spec > > Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: > > - Code fix only > - Code fix only Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/border/BevelBorder.java line 99: > 97: public BevelBorder(int bevelType, Color highlight, Color shadow) { > 98: this(bevelType, (highlight != null) ? highlight.brighter() : null, > 99: highlight, shadow, (shadow != null) ? shadow.brighter() : null); Suggestion: this(bevelType, (highlight != null) ? highlight.brighter() : null, highlight, shadow, (shadow != null) ? shadow.brighter() : null); Fix the indentation. In fact, I suggest wrapping the parameters and having highlight and shadow on one line, I think this will improve readability. Suggestion: this(bevelType, (highlight != null) ? highlight.brighter() : null, highlight, shadow, (shadow != null) ? shadow.brighter() : null); This way both highlight and shadow colors are logically grouped. test/jdk/javax/swing/border/TestBevelBorderParam.java line 46: > 44: str.append("BorderFactory.createBevelBorder throws NPE for null highlight and shadow"); > 45: } > 46: try { Suggestion: } try { Add blank lines between code blocks testing different constructors ? the code is so much easier to read compared to a long wall lines without breaks. test/jdk/javax/swing/border/TestBevelBorderParam.java line 53: > 51: str.append("BorderFactory.createSoftBevelBorder throws NPE for null highlight and shadow"); > 52: } > 53: try { Suggestion: } try { test/jdk/javax/swing/border/TestBevelBorderParam.java line 60: > 58: str.append("BevelBorder constructor throws NPE for null highlight and shadow"); > 59: } > 60: if (failure) { You don't need the `failure` variable. If `str` is not empty, throw the exception. test/jdk/javax/swing/border/TestBevelBorderParam.java line 60: > 58: str.append("BevelBorder constructor throws NPE for null highlight and shadow"); > 59: } > 60: if (failure) { Suggestion: } if (failure) { ------------- PR Review: https://git.openjdk.org/jdk/pull/27949#pullrequestreview-3453055437 PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2518010156 PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2518020140 PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2518021409 PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2518014929 PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2518021985 From psadhukhan at openjdk.org Wed Nov 12 12:29:26 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 12 Nov 2025 12:29:26 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v9] In-Reply-To: References: Message-ID: <8EdsEXQjv3Fic4LUh8uDTaSPYZrNd2_qsSMHEfkU4io=.d6863e03-ee59-407f-9e2b-a2037a923da2@github.com> > If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder` > it throws NPE which is not mentioned in the spec as the expected outcome. > Fixed the NPE and the spec Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Review comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27949/files - new: https://git.openjdk.org/jdk/pull/27949/files/fdd91b7b..115189a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27949&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27949&range=07-08 Stats: 11 lines in 2 files changed: 4 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27949.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27949/head:pull/27949 PR: https://git.openjdk.org/jdk/pull/27949 From psadhukhan at openjdk.org Wed Nov 12 12:29:29 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 12 Nov 2025 12:29:29 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v8] In-Reply-To: <4ntGE91uWjSi9JEBMv_p7B0NEpvGwczBk1-uDaWQmRA=.085bb21c-2dc0-442e-9554-3a8355a52488@github.com> References: <4ntGE91uWjSi9JEBMv_p7B0NEpvGwczBk1-uDaWQmRA=.085bb21c-2dc0-442e-9554-3a8355a52488@github.com> Message-ID: On Wed, 12 Nov 2025 11:53:47 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: >> >> - Code fix only >> - Code fix only > > src/java.desktop/share/classes/javax/swing/border/BevelBorder.java line 99: > >> 97: public BevelBorder(int bevelType, Color highlight, Color shadow) { >> 98: this(bevelType, (highlight != null) ? highlight.brighter() : null, >> 99: highlight, shadow, (shadow != null) ? shadow.brighter() : null); > > Suggestion: > > this(bevelType, (highlight != null) ? highlight.brighter() : null, > highlight, shadow, (shadow != null) ? shadow.brighter() : null); > > Fix the indentation. > > In fact, I suggest wrapping the parameters and having highlight and shadow on one line, I think this will improve readability. > > > Suggestion: > > this(bevelType, > (highlight != null) ? highlight.brighter() : null, highlight, > shadow, (shadow != null) ? shadow.brighter() : null); > > This way both highlight and shadow colors are logically grouped. ok > test/jdk/javax/swing/border/TestBevelBorderParam.java line 60: > >> 58: str.append("BevelBorder constructor throws NPE for null highlight and shadow"); >> 59: } >> 60: if (failure) { > > You don't need the `failure` variable. If `str` is not empty, throw the exception. ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2518107416 PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2518107738 From aivanov at openjdk.org Wed Nov 12 14:12:28 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 12 Nov 2025 14:12:28 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v9] In-Reply-To: <8EdsEXQjv3Fic4LUh8uDTaSPYZrNd2_qsSMHEfkU4io=.d6863e03-ee59-407f-9e2b-a2037a923da2@github.com> References: <8EdsEXQjv3Fic4LUh8uDTaSPYZrNd2_qsSMHEfkU4io=.d6863e03-ee59-407f-9e2b-a2037a923da2@github.com> Message-ID: <3gJLs0kbqEcfoeFapGVY1AGrKwI3bLHAk1uT61Bl9Lw=.daec187d-ac2b-415d-9315-574fd5317955@github.com> On Wed, 12 Nov 2025 12:29:26 GMT, Prasanta Sadhukhan wrote: >> If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder` >> it throws NPE which is not mentioned in the spec as the expected outcome. >> Fixed the NPE and the spec > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Review comment Changes requested by aivanov (Reviewer). > I guess spec clarification isn't strictly necessary for this PR..\ > ?Any objections? I've been wondering why I can't see any javadoc changes. Sounds reasonable to me. test/jdk/javax/swing/border/TestBevelBorderParam.java line 59: > 57: str.append("BevelBorder constructor throws NPE for null highlight and shadow"); > 58: } > 59: if (str.length() != 0) { Suggestion: } if (str.length() != 0) { The `if` statement also starts a new logical block. ------------- PR Review: https://git.openjdk.org/jdk/pull/27949#pullrequestreview-3453635218 PR Comment: https://git.openjdk.org/jdk/pull/27949#issuecomment-3522134135 PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2518450267 From dgredler at openjdk.org Wed Nov 12 14:46:04 2025 From: dgredler at openjdk.org (Daniel Gredler) Date: Wed, 12 Nov 2025 14:46:04 GMT Subject: Integrated: 8371066: Remove unused class TextSourceLabel and associated class hierarchy In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 17:17:06 GMT, Daniel Gredler wrote: > The class `TextSourceLabel` is unused, as is the associated factory method `TextLabelFactory.createSimple(...)`. > > The abstractions provided by the abstract classes `TextLabel` and `ExtendedTextLabel` only make sense when there are two types of text labels (`TextSourceLabel` and `ExtendedTextSourceLabel`). With the deletion of `TextSourceLabel`, both `TextLabel` and `ExtendedTextLabel` can also be removed. > > The JavaDoc for the abstract methods in `TextLabel` and `ExtendedTextLabel`, which are implemented in `ExtendedTextSourceLabel`, was moved to `ExtendedTextSourceLabel` prior to the deletion of these two classes. > > The few small convenience methods in `TextLabel` and `ExtendedTextLabel` were also moved to `ExtendedTextSourceLabel` prior to the deletion of these two classes. > > I would have liked to give the combined `TextLabel` + `ExtendedTextLabel` + `ExtendedTextSourceLabel` class the name `TextLabel`, but I've used `ExtendedTextSourceLabel` instead because it makes the diff much smaller and maximizes code history traceability. > > See initial mailing list discussion: https://mail.openjdk.org/pipermail/client-libs-dev/2025-September/032302.html This pull request has now been integrated. Changeset: 4042e821 Author: Daniel Gredler URL: https://git.openjdk.org/jdk/commit/4042e821c6f582bf31201acb9f2d98d940383f1c Stats: 649 lines in 7 files changed: 137 ins; 480 del; 32 mod 8371066: Remove unused class TextSourceLabel and associated class hierarchy Reviewed-by: prr, psadhukhan ------------- PR: https://git.openjdk.org/jdk/pull/28090 From psadhukhan at openjdk.org Wed Nov 12 15:06:03 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 12 Nov 2025 15:06:03 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v10] In-Reply-To: References: Message-ID: > If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder` > it throws NPE which is not mentioned in the spec as the expected outcome. > Fixed the NPE and the spec Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27949/files - new: https://git.openjdk.org/jdk/pull/27949/files/115189a7..ea2f6d5f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27949&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27949&range=08-09 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27949.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27949/head:pull/27949 PR: https://git.openjdk.org/jdk/pull/27949 From aivanov at openjdk.org Wed Nov 12 15:33:18 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 12 Nov 2025 15:33:18 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v10] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 15:06:03 GMT, Prasanta Sadhukhan wrote: >> If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder` >> it throws NPE which is not mentioned in the spec as the expected outcome. >> Fixed the NPE and the spec > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > fix Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27949#pullrequestreview-3454065278 From honkar at openjdk.org Wed Nov 12 18:00:15 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 12 Nov 2025 18:00:15 GMT Subject: RFR: JDK-8371365 : Update javax/swing/JFileChooser/bug4759934.java to use Util.findComponent() [v2] In-Reply-To: References: Message-ID: <6_TbhjDR55BUuqDfKy_YoMWPsgnQBRz3VrmxkrZldfA=.64b8c5df-8189-4d9e-a268-a0ee97a42aeb@github.com> On Fri, 7 Nov 2025 20:13:45 GMT, Alexey Ivanov wrote: >> I believe the test hangs after - dialogBtn.doClick() and does not proceed to the test condition check. I'll need to check in depth as to why this is happening. >> >>> I see? It may be not worth the effort then. >> >> I can create a separate JBS issue to look into it and as for the test changes use the doClick() for just the JFC's Cancel button. Does this sound good to you? > >> Does this sound good to you? > > This is likely the best approach. > > It's a new problem that we discovered. It doesn't prevent integrating the change to search for the Cancel button in the file chooser, yet it would be good to investigate what goes wrong when all the buttons are clicked programmatically instead of using the robot to generate mouse clicks. Created a new JBS to track the doClick() issue - [JDK-8371728](https://bugs.openjdk.org/browse/JDK-8371728) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28169#discussion_r2519271550 From honkar at openjdk.org Wed Nov 12 18:00:17 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 12 Nov 2025 18:00:17 GMT Subject: Integrated: JDK-8371365 : Update javax/swing/JFileChooser/bug4759934.java to use Util.findComponent() In-Reply-To: References: Message-ID: On Thu, 6 Nov 2025 01:00:43 GMT, Harshitha Onkar wrote: > /javax/swing/JFileChooser/bug4759934.java test changes related to addition of new method to Util - https://github.com/openjdk/jdk/pull/27944. This pull request has now been integrated. Changeset: 78db38f1 Author: Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/78db38f14044d434eabb61ff8293d62eff3c497c Stats: 14 lines in 1 file changed: 11 ins; 1 del; 2 mod 8371365: Update javax/swing/JFileChooser/bug4759934.java to use Util.findComponent() Reviewed-by: aivanov, dnguyen, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/28169 From dnguyen at openjdk.org Wed Nov 12 19:13:06 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 12 Nov 2025 19:13:06 GMT Subject: RFR: 8371508: [macos] In Aqua LaF menu items layout is incorrect in RTL orientation [v2] In-Reply-To: <7m34qGlFammbS9KJZMP-5YE7tM7l2zyz7mntUC4cm60=.7a530988-b17f-4d44-be1e-72a1c442dd35@github.com> References: <7lU-DpazJjVmfcY_pN7Y1-nV8_5zajs40JoWzXwe2cE=.f87c6c0f-049c-4f70-8d0e-a285880d4e25@github.com> <7m34qGlFammbS9KJZMP-5YE7tM7l2zyz7mntUC4cm60=.7a530988-b17f-4d44-be1e-72a1c442dd35@github.com> Message-ID: On Wed, 12 Nov 2025 10:02:40 GMT, Prasanta Sadhukhan wrote: >It seems the check icon is almost overlapping with text.....maybe a little more gap is needed... I agree with this. It looks off. Adding a gap when LTR looks needed. >Also I couldn't find in native that it supports BOTH check mark and icon together.. Screenshot 2025-11-12 at 11 08 17?AM This is an example of what I found on macOS native TextEdit. I think having both can be possible. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28210#issuecomment-3523499640 From psadhukhan at openjdk.org Thu Nov 13 01:22:18 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 13 Nov 2025 01:22:18 GMT Subject: Integrated: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow In-Reply-To: References: Message-ID: On Thu, 23 Oct 2025 06:54:27 GMT, Prasanta Sadhukhan wrote: > If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder` > it throws NPE which is not mentioned in the spec as the expected outcome. > Fixed the NPE and the spec This pull request has now been integrated. Changeset: bc66d3e6 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/bc66d3e65d208edc69e8ae334d23b38f2b78a440 Stats: 68 lines in 2 files changed: 66 ins; 0 del; 2 mod 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow Reviewed-by: aivanov, tr, honkar ------------- PR: https://git.openjdk.org/jdk/pull/27949 From dnguyen at openjdk.org Thu Nov 13 04:05:08 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 13 Nov 2025 04:05:08 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v9] In-Reply-To: References: <1nxKOtN4B2h026FhyQp8t-1IOZBFPMfnif7I5a0Vnuc=.9ffffa12-226f-49ac-8b85-fac3750c649f@github.com> <3hw1X_jGyDqVuyleOkeirF2hj4ZnfuBPoG9J-e4Rw50=.914a54f6-f2f8-491d-b2af-e84dfdc5967b@github.com> Message-ID: On Sat, 8 Nov 2025 00:32:56 GMT, Sergey Bylokhov wrote: > We do not need to rush the patch, we can discuss it here. Since there is an alternative implementation we can discuss the pros and cons. I don't think this is rushed. Also, I did a brief demo of the mouse movement in `ToolTipDemoTest.java` with others in a client-team meeting and the consensus was that the difference wasn't significant. This meeting was where we discussed whether this needed to be updated now or in a future PR, and everyone agreed that if the `glide` implementation can be updated to `RobotDriver's` `moveMouse` way later, separately. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26969#issuecomment-3525195618 From psadhukhan at openjdk.org Thu Nov 13 04:14:01 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 13 Nov 2025 04:14:01 GMT Subject: RFR: 8368702: [macosx] Printing text with composite fonts loses font transform In-Reply-To: References: Message-ID: <4s6eeHtVrFbR3vAqqIzdw_AkKZGAGp_8XZJpPYKq5yk=.4f301037-8cf0-4b2a-a665-2c760d27cb33@github.com> On Mon, 29 Sep 2025 11:46:47 GMT, Daniel Gredler wrote: > When printing text on macOS, if the text uses a composite font (a logical font composed of more than one physical font) with a custom affine transform, the transform can be lost, and the text printed without the transform applied. > > This is one of a few issues affecting the problem listed manual test `java/awt/print/PrinterJob/PrintTextTest.java` on macOS, and can be observed on page 10, on the last line ("TextLayout 2"). Without the fix, the text on this line is not stretched across the x-axis, resulting in large gaps of white space between runs of different script types. BTW, are you also working on issue in Page 8 of the above test? I guess that's the only issue remaining after this as I see.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27544#issuecomment-3525225572 From dnguyen at openjdk.org Thu Nov 13 04:17:04 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 13 Nov 2025 04:17:04 GMT Subject: RFR: 8042054: JTree.updateUI uses out-of-date item size information In-Reply-To: References: Message-ID: <2MqeCxzhvLFTChzvx2MNkk3_6ei7nRsl0gvH51Liymw=.a8434405-a4b8-49cd-869a-ad97c811117c@github.com> On Wed, 12 Nov 2025 07:56:33 GMT, Prasanta Sadhukhan wrote: > `JTree.updateUI` calculate item sizes from the cell renderer, but it doesn't call `updateUI `on the cell renderer until afterwards. This leads to incorrect size calculation, which is observed when we switch from one L&F to another where it is seen that all tree items are slightly too cramped, with too little space between rows and text are abbreviated. > Fix is to ensure `JTree.updateUI` update the cell renderer before updating the UI. > CI testing is ok.. > > Before fix > image > > After fix > image The change itself looks straight-forward and clean. Testing looks OK. Left some minor suggestions. test/jdk/javax/swing/JTree/JTreeUpdateTest.java line 27: > 25: * @test > 26: * @bug 8042054 > 27: * @summary JTree.updateUI sould use updated item size information Suggestion: * @summary JTree.updateUI should use updated item size information test/jdk/javax/swing/JTree/JTreeUpdateTest.java line 49: > 47: and JTree items are cramped with little space between rows > 48: then press Fail. > 49: If the left JTree is identical with right JTree, press Pass. Suggestion: A frame with two identical JTrees is shown. If the left JTree's text is abbreviated and JTree items are cramped with little space between rows then press Fail. If the left JTree is identical to the right JTree, press Pass. Looks a little strange with where the line breaks are. Some are long and some are short. And phrasing. test/jdk/javax/swing/JTree/JTreeUpdateTest.java line 62: > 60: } > 61: > 62: static JFrame createUI() { Suggestion: private static JFrame createUI() { Explicitly set to public or private. test/jdk/javax/swing/JTree/JTreeUpdateTest.java line 89: > 87: SwingUtilities.updateComponentTreeUI(tree2); > 88: } > 89: }); Suggestion: SwingUtilities.invokeLater(() -> { setLaf("javax.swing.plaf.nimbus.NimbusLookAndFeel"); SwingUtilities.updateComponentTreeUI(frame); SwingUtilities.updateComponentTreeUI(tree2); }); Can replace with lambda expression. ------------- PR Review: https://git.openjdk.org/jdk/pull/28258#pullrequestreview-3457190833 PR Review Comment: https://git.openjdk.org/jdk/pull/28258#discussion_r2521286133 PR Review Comment: https://git.openjdk.org/jdk/pull/28258#discussion_r2521291600 PR Review Comment: https://git.openjdk.org/jdk/pull/28258#discussion_r2521308239 PR Review Comment: https://git.openjdk.org/jdk/pull/28258#discussion_r2521297975 From smandalika at openjdk.org Thu Nov 13 04:55:12 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Thu, 13 Nov 2025 04:55:12 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update [v4] In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 16:17:14 GMT, Srinivas Mandalika wrote: >> Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java >> Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Fixed whitepsace error. Can someone take a quick look and provide feedback on this simple instruction update MR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27139#issuecomment-3525361550 From psadhukhan at openjdk.org Thu Nov 13 05:22:40 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 13 Nov 2025 05:22:40 GMT Subject: RFR: 8042054: JTree.updateUI uses out-of-date item size information [v2] In-Reply-To: References: Message-ID: > `JTree.updateUI` calculate item sizes from the cell renderer, but it doesn't call `updateUI `on the cell renderer until afterwards. This leads to incorrect size calculation, which is observed when we switch from one L&F to another where it is seen that all tree items are slightly too cramped, with too little space between rows and text are abbreviated. > Fix is to ensure `JTree.updateUI` update the cell renderer before updating the UI. > CI testing is ok.. > > Before fix > image > > After fix > image Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Test formatting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28258/files - new: https://git.openjdk.org/jdk/pull/28258/files/522159b1..a11aa575 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28258&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28258&range=00-01 Stats: 13 lines in 1 file changed: 0 ins; 4 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/28258.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28258/head:pull/28258 PR: https://git.openjdk.org/jdk/pull/28258 From psadhukhan at openjdk.org Thu Nov 13 05:22:41 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 13 Nov 2025 05:22:41 GMT Subject: RFR: 8042054: JTree.updateUI uses out-of-date item size information In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 07:56:33 GMT, Prasanta Sadhukhan wrote: > `JTree.updateUI` calculate item sizes from the cell renderer, but it doesn't call `updateUI `on the cell renderer until afterwards. This leads to incorrect size calculation, which is observed when we switch from one L&F to another where it is seen that all tree items are slightly too cramped, with too little space between rows and text are abbreviated. > Fix is to ensure `JTree.updateUI` update the cell renderer before updating the UI. > CI testing is ok.. > > Before fix > image > > After fix > image Test updated.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28258#issuecomment-3525447513 From dgredler at openjdk.org Thu Nov 13 06:48:03 2025 From: dgredler at openjdk.org (Daniel Gredler) Date: Thu, 13 Nov 2025 06:48:03 GMT Subject: RFR: 8368702: [macosx] Printing text with composite fonts loses font transform In-Reply-To: <4s6eeHtVrFbR3vAqqIzdw_AkKZGAGp_8XZJpPYKq5yk=.4f301037-8cf0-4b2a-a665-2c760d27cb33@github.com> References: <4s6eeHtVrFbR3vAqqIzdw_AkKZGAGp_8XZJpPYKq5yk=.4f301037-8cf0-4b2a-a665-2c760d27cb33@github.com> Message-ID: <61yIQhbCb6rHwPwDFWKxUhdQsithtqZcV4oeRZlLpOM=.f27b9821-3bbe-49a9-8d77-1182b190e808@github.com> On Thu, 13 Nov 2025 04:11:36 GMT, Prasanta Sadhukhan wrote: >> When printing text on macOS, if the text uses a composite font (a logical font composed of more than one physical font) with a custom affine transform, the transform can be lost, and the text printed without the transform applied. >> >> This is one of a few issues affecting the problem listed manual test `java/awt/print/PrinterJob/PrintTextTest.java` on macOS, and can be observed on page 10, on the last line ("TextLayout 2"). Without the fix, the text on this line is not stretched across the x-axis, resulting in large gaps of white space between runs of different script types. > > BTW, are you also working on issue in Page 8 of the above test? I guess that's the only issue remaining after this as I see.. @prsadhuk Yep, I've been whittling down the issues in this test for the past year or so, and plan to wrap up with page 8 as soon as my other open PRs are finalized. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27544#issuecomment-3525805172 From serb at openjdk.org Thu Nov 13 06:49:15 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 13 Nov 2025 06:49:15 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v9] In-Reply-To: <3gJLs0kbqEcfoeFapGVY1AGrKwI3bLHAk1uT61Bl9Lw=.daec187d-ac2b-415d-9315-574fd5317955@github.com> References: <8EdsEXQjv3Fic4LUh8uDTaSPYZrNd2_qsSMHEfkU4io=.d6863e03-ee59-407f-9e2b-a2037a923da2@github.com> <3gJLs0kbqEcfoeFapGVY1AGrKwI3bLHAk1uT61Bl9Lw=.daec187d-ac2b-415d-9315-574fd5317955@github.com> Message-ID: <0bA_mGkm8kPxh61JNBUxHLnUpY3duH2RwaRBDriphhw=.37f587ef-437e-4558-b038-87b711c08520@github.com> On Wed, 12 Nov 2025 14:09:25 GMT, Alexey Ivanov wrote: > I've been wondering why I can't see any javadoc changes. > > Sounds reasonable to me. @aivanov-jdk How could the csr be skipped? This is clearly a behavior change, even without a spec update. >The code change would take care of the NPE and since RDP1 is approaching with not much time left for CSR approval That is not a valid argument to skip a csr. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27949#issuecomment-3525809019 From psadhukhan at openjdk.org Thu Nov 13 08:00:44 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 13 Nov 2025 08:00:44 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v10] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 15:06:03 GMT, Prasanta Sadhukhan wrote: >> If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder` >> it throws NPE which is not mentioned in the spec as the expected outcome. >> Fixed the NPE and the spec > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > fix I dont think I agree....We fixed NPE which is not documented in the spec so fixing an exception is a normal bugfix and spec update is not required in my opinion...If it had been documented, then spec clarification would have been needed.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27949#issuecomment-3526194301 From aivanov at openjdk.org Thu Nov 13 13:18:08 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 13 Nov 2025 13:18:08 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v9] In-Reply-To: <0bA_mGkm8kPxh61JNBUxHLnUpY3duH2RwaRBDriphhw=.37f587ef-437e-4558-b038-87b711c08520@github.com> References: <8EdsEXQjv3Fic4LUh8uDTaSPYZrNd2_qsSMHEfkU4io=.d6863e03-ee59-407f-9e2b-a2037a923da2@github.com> <3gJLs0kbqEcfoeFapGVY1AGrKwI3bLHAk1uT61Bl9Lw=.daec187d-ac2b-415d-9315-574fd5317955@github.com> <0bA_mGkm8kPxh61JNBUxHLnUpY3duH2RwaRBDriphhw=.37f587ef-437e-4558-b038-87b711c08520@github.com> Message-ID: On Thu, 13 Nov 2025 06:46:37 GMT, Sergey Bylokhov wrote: > > I've been wondering why I can't see any javadoc changes. > > Sounds reasonable to me. > > @aivanov-jdk How could the csr be skipped? This is clearly a behavior change, even without a spec update. > > > The code change would take care of the NPE and since RDP1 is approaching with not much time left for CSR approval > > That is not a valid argument to skip a csr. @mrserb I agree with Prasanta's evaluation. The spec doesn't specify how `null` arguments are handled, nor does it specify `NullPointerException` is to be thrown. The `BevelBorder` constructor that takes four color parameters https://github.com/openjdk/jdk/blob/412b43658a878bf004502a68948cb0c68375468e/src/java.desktop/share/classes/javax/swing/border/BevelBorder.java#L112-L120 accepts `null` and does not throw exceptions. Yet the `BevelBorder` constructor that takes two color parameters threw `NullPointerException` if either of the color arguments was `null`. What's fixed is the behaviour of this constructor now aligns with that of the constructor with more arguments, specifically *no `NullPointerException` is thrown if `null` color is passed*. Now, both constructors behave *consistently*. In my opinion, such a change doesn't require a CSR. Moreover, this new behaviour is consistent with what specified for [`BevelBorder.getHighlightInnerColor`](https://docs.oracle.com/en/java/javase/25/docs/api/java.desktop/javax/swing/border/BevelBorder.html#getHighlightInnerColor()) and other getters of colors. https://github.com/openjdk/jdk/blob/412b43658a878bf004502a68948cb0c68375468e/src/java.desktop/share/classes/javax/swing/border/BevelBorder.java#L231-L233 It could be good to expand the specification of the constructors with regards to `null` arguments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27949#issuecomment-3527766363 From serb at openjdk.org Thu Nov 13 17:23:52 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 13 Nov 2025 17:23:52 GMT Subject: RFR: 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow [v9] In-Reply-To: References: <8EdsEXQjv3Fic4LUh8uDTaSPYZrNd2_qsSMHEfkU4io=.d6863e03-ee59-407f-9e2b-a2037a923da2@github.com> <3gJLs0kbqEcfoeFapGVY1AGrKwI3bLHAk1uT61Bl9Lw=.daec187d-ac2b-415d-9315-574fd5317955@github.com> <0bA_mGkm8kPxh61JNBUxHLnUpY3duH2RwaRBDriphhw=.37f587ef-437e-4558-b038-87b711c08520@github.com> Message-ID: <9rvdohl2J5_efYXpxEMV6AD_KOYwguIwKowwugAe3ZI=.8ce763e9-4017-464d-a199-105b69f5b66e@github.com> On Thu, 13 Nov 2025 13:14:04 GMT, Alexey Ivanov wrote: > What's fixed is the behaviour of this constructor now aligns with that of the constructor with more arguments, specifically no NullPointerException is thrown if null color is passed. Now, both constructors behave consistently. But they cannot behave consistently. The constructor you mentioned has parameters such as highlightInner and highlightOuter, which may be null, and the corresponding getters specify this behavior. However, the constructor updated in this patch takes a different parameter. The color from which, according to the specification, colors like highlightInner and highlightOuter should be derived. If the provided color is null, it is impossible to derive these values, and an exception was originally thrown. Now, instead of throwing an exception when the specification cannot be followed, the implementation silently falls back to unspecified logic, which contradicts the spec. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27949#issuecomment-3528891157 From honkar at openjdk.org Thu Nov 13 17:52:23 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 13 Nov 2025 17:52:23 GMT Subject: Withdrawn: JDK-8017182 : [macosx] MouseClickCount.java produces click count greater than 1 when left-button click is followed by quick right button click In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 23:59:05 GMT, Harshitha Onkar wrote: > On macOS mouse sensitivity setting play a role in click count increment. By increasing the double-click speed under > (Settings > Mouse Sensitivity > Double click speed), the click count no longer shows as 1,2. > > image This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27379 From serb at openjdk.org Thu Nov 13 19:35:05 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 13 Nov 2025 19:35:05 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v9] In-Reply-To: References: <1nxKOtN4B2h026FhyQp8t-1IOZBFPMfnif7I5a0Vnuc=.9ffffa12-226f-49ac-8b85-fac3750c649f@github.com> <3hw1X_jGyDqVuyleOkeirF2hj4ZnfuBPoG9J-e4Rw50=.914a54f6-f2f8-491d-b2af-e84dfdc5967b@github.com> Message-ID: On Thu, 13 Nov 2025 04:02:29 GMT, Damon Nguyen wrote: > I don't think this is rushed. Also, I did a brief demo of the mouse movement in `ToolTipDemoTest.java` with others in a client-team meeting and the consensus was that the difference wasn't significant. This meeting was where we discussed whether this needed to be updated now or in a future PR, and everyone agreed that if the `glide` implementation can be updated to `RobotDriver's` `moveMouse` way later, separately. Please file the follow up issue then, it will be good to change that sooner than later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26969#issuecomment-3529395650 From kizune at openjdk.org Thu Nov 13 20:11:02 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 13 Nov 2025 20:11:02 GMT Subject: RFR: 8371508: [macos] In Aqua LaF menu items layout is incorrect in RTL orientation [v2] In-Reply-To: References: <7lU-DpazJjVmfcY_pN7Y1-nV8_5zajs40JoWzXwe2cE=.f87c6c0f-049c-4f70-8d0e-a285880d4e25@github.com> Message-ID: <6n_AdJB2OYVeMFSvfYngb-CPjN2RU2GN5Wyy5q_nfcQ=.82d8171e-7c9c-4c2e-9182-12d1649270e1@github.com> On Wed, 12 Nov 2025 04:49:37 GMT, Tejesh R wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Use correct bug id in the test. > > src/java.desktop/macosx/classes/com/apple/laf/AquaMenuPainter.java line 538: > >> 536: checkIconR.x = w - (checkIconR.x + checkIconR.width); >> 537: if (menuItem.getHorizontalTextPosition() != SwingConstants.CENTER) { >> 538: int d = textR.x - iconR.x; > > `d` refers to difference ? Could be `diff` for readability ? D is for distance but i can rename it into delta - that will cover both meanings. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28210#discussion_r2524793108 From kizune at openjdk.org Thu Nov 13 21:36:48 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 13 Nov 2025 21:36:48 GMT Subject: RFR: 8371508: [macos] In Aqua LaF menu items layout is incorrect in RTL orientation [v3] In-Reply-To: References: Message-ID: > The problem is that we do not correct the icon and text re-alignment that happens when we call SwingUtilities.layoutCompoundLabel > > Here's the comparison of the alignment before and after the fix > Before: > before_fix > After: > after_fix Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Rename d to delta for better readability. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28210/files - new: https://git.openjdk.org/jdk/pull/28210/files/0427d6a1..7b8b934b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28210&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28210&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28210.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28210/head:pull/28210 PR: https://git.openjdk.org/jdk/pull/28210 From serb at openjdk.org Thu Nov 13 23:00:34 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 13 Nov 2025 23:00:34 GMT Subject: RFR: 8371501: Change IAE to NPE in java.awt.image.Kernel when data is null Message-ID: <0bU-D8sNFOFCEtIwSv6d0b75uIO9mkK24qtA_guTS1U=.8f40f71b-249d-4f84-ad73-af2b66e1f52a@github.com> This is an update to the patch integrated in https://github.com/openjdk/jdk/pull/28127. It changes the exception from IllegalArgumentException back to NullPointerException, which was thrown previously. Rationale: - Since an NPE was already thrown before, this does not introduce a behavior change - Throwing NPE on null is the common pattern used across the codebase, including in the affected package Additional notes: The patch uses the idiomatic way to check parameters for null via Objects.requireNonNull(). I am not sure whether this code path is performance critical. The use of >> 1 instead of / 2 suggests that performance might matter. If this code is performance sensitive, we can remove the Objects.requireNonNull() call, because even without it the resulting NPE would still clearly show which variable was null when its field was accessed. It is also possible to remove the use of multiplyExact(). We can simply multiply width/height as long values and compare the result with the data length. In case of overflow, the existing ?Data array too small? exception would still be thrown. ------------- Commit messages: - 8371501: Change IAE to NPE in java.awt.image.Kernel when data is null Changes: https://git.openjdk.org/jdk/pull/28249/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28249&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371501 Stats: 41 lines in 2 files changed: 18 ins; 6 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/28249.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28249/head:pull/28249 PR: https://git.openjdk.org/jdk/pull/28249 From honkar at openjdk.org Thu Nov 13 23:29:13 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 13 Nov 2025 23:29:13 GMT Subject: RFR: JDK-8365426 : [macos26] Graphics2D tests fail on new macOS 26 Message-ID: This test started to fail on macOS26 due to color inconsistency at certain points. Color tolerance has been added as a fix. The color tolerance for the dominant component (eg Color.RED - dominant component is red) is set less (delta of PRIMARY_TOLERANCE = 2) and for non-dominant (For Color.RED - Green and Blue are non-dominant) is set more (delta of TOLERANCE=30). This ensures we are checking for shades (brighter/lighter) of the expected color. Since the issue is only seen on macOS, I have set both PRIMARY_TOLERANCE & TOLERANCE to 2 on other platforms to keep the test almost close to the original one. Tested locally on macOS 26.0.1 and 26.1 and fix works as expected. CI testing on other platforms looks good and no regressions are observed (Link added to JBS). ------------- Commit messages: - test condition shortened - CopyAreaOOB fix for macOS26 Changes: https://git.openjdk.org/jdk/pull/28312/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28312&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365426 Stats: 44 lines in 1 file changed: 19 ins; 2 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/28312.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28312/head:pull/28312 PR: https://git.openjdk.org/jdk/pull/28312 From honkar at openjdk.org Thu Nov 13 23:29:14 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 13 Nov 2025 23:29:14 GMT Subject: RFR: JDK-8365426 : [macos26] Graphics2D tests fail on new macOS 26 In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 23:20:18 GMT, Harshitha Onkar wrote: > This test started to fail on macOS26 due to color inconsistency at certain points. > Color tolerance has been added as a fix. > > The color tolerance for the dominant component (eg Color.RED - dominant component is red) is set less (delta of PRIMARY_TOLERANCE = 2) and for non-dominant (For Color.RED - Green and Blue are non-dominant) is set more (delta of TOLERANCE=30). This ensures we are checking for shades (brighter/lighter) of the expected color. > > Since the issue is only seen on macOS, I have set both PRIMARY_TOLERANCE & TOLERANCE to 2 on other platforms to keep the test almost close to the original one. > > Tested locally on macOS 26.0.1 and 26.1 and fix works as expected. > > CI testing on other platforms looks good and no regressions are observed (Link added to JBS). test/jdk/java/awt/Graphics2D/CopyAreaOOB.java line 73: > 71: try { > 72: if (!Platform.isOSX()) { > 73: TOLERANCE = PRIMARY_TOLERANCE; I could set tolerance and primary_tolerance both to zero on other platforms although I have currently set it to a small delta of 2. I can change it to zero if any reviewers suggest that exact color compare would be better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28312#discussion_r2525241621 From kizune at openjdk.org Fri Nov 14 00:29:00 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Fri, 14 Nov 2025 00:29:00 GMT Subject: RFR: JDK-8365426 : [macos26] Graphics2D tests fail on new macOS 26 In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 23:20:18 GMT, Harshitha Onkar wrote: > This test started to fail on macOS26 due to color inconsistency at certain points. > Color tolerance has been added as a fix. > > The color tolerance for the dominant component (eg Color.RED - dominant component is red) is set less (delta /PRIMARY_TOLERANCE = 2) and for non-dominant (For Color.RED - Green and Blue are non-dominant) is set more (delta / TOLERANCE=30). This ensures we are checking for shades (brighter/lighter) of the expected color. > > Since the issue is only seen on macOS, I have set both PRIMARY_TOLERANCE & TOLERANCE to 2 on other platforms to keep the test almost close to the original one. > > Tested locally on macOS 26.0.1 and 26.1 and fix works as expected. > > CI testing on other platforms looks good and no regressions are observed (Link added to JBS). Looks good. ------------- Marked as reviewed by kizune (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28312#pullrequestreview-3462251667 From dnguyen at openjdk.org Fri Nov 14 01:11:13 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 14 Nov 2025 01:11:13 GMT Subject: RFR: JDK-8365426 : [macos26] Graphics2D tests fail on new macOS 26 In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 23:20:18 GMT, Harshitha Onkar wrote: > This test started to fail on macOS26 due to color inconsistency at certain points. > Color tolerance has been added as a fix. > > The color tolerance for the dominant component (eg Color.RED - dominant component is red) is set less (delta /PRIMARY_TOLERANCE = 2) and for non-dominant (For Color.RED - Green and Blue are non-dominant) is set more (delta / TOLERANCE=30). This ensures we are checking for shades (brighter/lighter) of the expected color. > > Since the issue is only seen on macOS, I have set both PRIMARY_TOLERANCE & TOLERANCE to 2 on other platforms to keep the test almost close to the original one. > > Tested locally on macOS 26.0.1 and 26.1 and fix works as expected. > > CI testing on other platforms looks good and no regressions are observed (Link added to JBS). Tolerances seemed to do the trick. Tested on my various devices (including the macOS 26 machine I originally found this issue on) and this passes now. I wonder what in macOS 26 causes the slight color variances when other OS's (including previous macOS versions) don't have this issue. ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/28312#pullrequestreview-3462334105 From serb at openjdk.org Fri Nov 14 05:54:13 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 14 Nov 2025 05:54:13 GMT Subject: RFR: 8371657: [macosx] Programmatically selecting/deselecting List item triggers an ItemEvent Message-ID: When I was working on [JDK-8369327](https://bugs.openjdk.org/browse/JDK-8369327) I got a suggestion to update the code that disables unnecessary events: https://github.com/openjdk/jdk/pull/27682#discussion_r2487686109 After checking that code more closely, I found that it does not work in all cases. The checks were first added in [JDK-7125456](https://bugs.openjdk.org/browse/JDK-7125456). It looks like only the case for the select method was fixed. Other cases still cause unnecessary events, and even more events happen when trying to add multi selection mode: https://github.com/openjdk/jdk/pull/27682#issuecomment-3487434403 So I made a new bug for this issue and fixed it separately. The [spec](https://github.com/openjdk/jdk/blob/8531fa146be1da5e96c0f23091882a27c67d7893/src/java.desktop/share/classes/java/awt/List.java#L899): * Adds the specified item listener to receive item events from * this list. Item events are sent in response to user input, but not * in response to calls to {@code select} or {@code deselect}. The new test checks most of the methods in the `java.awt.List` class. It passes on linux/windows, confirming that the same behavior is implemented in other toolkits (unfortunately on linux it is not stable enough so I had to problemlist it due to [JDK-8201307](https://bugs.openjdk.org/browse/JDK-8201307)). The test only checks for programmatic changes to the list. I am sure that if I change it to test mix of programmatic/user changes it will fail. I will work on that in a follow up bug. @aivanov-jdk @azvegint please take a look ------------- Commit messages: - Disable the new test on Linux due to 8201307 - Merge branch 'openjdk:master' into JDK-8371657 - 8371657: [macosx] Programmatically selecting/deselecting List item triggers an ItemEvent Changes: https://git.openjdk.org/jdk/pull/28245/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28245&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371657 Stats: 215 lines in 3 files changed: 202 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/28245.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28245/head:pull/28245 PR: https://git.openjdk.org/jdk/pull/28245 From serb at openjdk.org Fri Nov 14 06:18:17 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 14 Nov 2025 06:18:17 GMT Subject: RFR: 8371759: Add missing @Override annotations in com.sun.imageio package Message-ID: <9IK6e1aTK_6ckzZNDuL7EGPLEd3DZd4RFGCgkEBF-jo=.70bb31bb-a3a6-480e-a39c-edaf5ad47c2e@github.com> This patch adds missing `@Override` annotations to methods in the `com.sun.imageio` 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: - 8371759: Add missing @Override annotations in com.sun.imageio package Changes: https://git.openjdk.org/jdk/pull/28282/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28282&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371759 Stats: 491 lines in 93 files changed: 401 ins; 0 del; 90 mod Patch: https://git.openjdk.org/jdk/pull/28282.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28282/head:pull/28282 PR: https://git.openjdk.org/jdk/pull/28282 From serb at openjdk.org Fri Nov 14 06:23:08 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 14 Nov 2025 06:23:08 GMT Subject: RFR: JDK-8365426 : [macos26] Graphics2D tests fail on new macOS 26 In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 23:24:07 GMT, Harshitha Onkar wrote: >> This test started to fail on macOS26 due to color inconsistency at certain points. >> Color tolerance has been added as a fix. >> >> The color tolerance for the dominant component (eg Color.RED - dominant component is red) is set less (delta /PRIMARY_TOLERANCE = 2) and for non-dominant (For Color.RED - Green and Blue are non-dominant) is set more (delta / TOLERANCE=30). This ensures we are checking for shades (brighter/lighter) of the expected color. >> >> Since the issue is only seen on macOS, I have set both PRIMARY_TOLERANCE & TOLERANCE to 2 on other platforms to keep the test almost close to the original one. >> >> Tested locally on macOS 26.0.1 and 26.1 and fix works as expected. >> >> CI testing on other platforms looks good and no regressions are observed (Link added to JBS). > > test/jdk/java/awt/Graphics2D/CopyAreaOOB.java line 73: > >> 71: try { >> 72: if (!Platform.isOSX()) { >> 73: TOLERANCE = PRIMARY_TOLERANCE; > > I could set tolerance and primary_tolerance both to zero on other platforms although I have currently set it to a small delta of 2. I can change it to zero if any reviewers suggest that exact color compare would be better. What is the reason for the color mismatch? Is it possible to check whether it is caused by the rendering pipeline (for example, different colors between metal and ogl), by the native code used by robot (we could compare it with a native screencapture tool), by the code that converts the native image to Java (using Robot.createMultiResolutionScreenCapture might help), or by some blending at the edges of the rendered area? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28312#discussion_r2525923170 From serb at openjdk.org Fri Nov 14 06:27:07 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 14 Nov 2025 06:27:07 GMT Subject: RFR: 8042054: JTree.updateUI uses out-of-date item size information [v2] In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 05:22:40 GMT, Prasanta Sadhukhan wrote: >> `JTree.updateUI` calculate item sizes from the cell renderer, but it doesn't call `updateUI `on the cell renderer until afterwards. This leads to incorrect size calculation, which is observed when we switch from one L&F to another where it is seen that all tree items are slightly too cramped, with too little space between rows and text are abbreviated. >> Fix is to ensure `JTree.updateUI` update the cell renderer before updating the UI. >> CI testing is ok.. >> >> Before fix >> image >> >> After fix >> image > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test formatting src/java.desktop/share/classes/javax/swing/JTree.java line 784: > 782: > 783: setUI((TreeUI)UIManager.getUI(this)); > 784: } finally { Is it possible that the cell renderer and cell editor depend on the current UI set on the component, which is the opposite situation of the current bug, how it will work before after the patch? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28258#discussion_r2525933343 From serb at openjdk.org Fri Nov 14 07:14:10 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 14 Nov 2025 07:14:10 GMT Subject: RFR: 8349157: Unnecessary Hashtable usage in XKeysym.javaKeycode2KeysymHash In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 09:35:09 GMT, Andrey Turbanov wrote: > There is a field `sun.awt.X11.XKeysym#javaKeycode2KeysymHash` which uses legacy Hashtable class. > As this map is read-only and all its content is initialized in `` we can safely use immutable Map instead. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23347#pullrequestreview-3463159334 From psadhukhan at openjdk.org Fri Nov 14 07:35:06 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 14 Nov 2025 07:35:06 GMT Subject: RFR: 8042054: JTree.updateUI uses out-of-date item size information [v2] In-Reply-To: References: Message-ID: On Fri, 14 Nov 2025 06:24:21 GMT, Sergey Bylokhov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Test formatting > > src/java.desktop/share/classes/javax/swing/JTree.java line 784: > >> 782: >> 783: setUI((TreeUI)UIManager.getUI(this)); >> 784: } finally { > > Is it possible that the cell renderer and cell editor depend on the current UI set on the component, which is the opposite situation of the current bug, how it will work before after the patch? I couldn't find any issue with it. I modified existing JTree/4330357/bug4330357.java to switch to Nimbus from Metal and I see no difference with Cell renderer and editor WIthout patch Image With patch Image ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28258#discussion_r2526151605 From kurt at openjdk.org Fri Nov 14 15:29:45 2025 From: kurt at openjdk.org (Kurt Miller) Date: Fri, 14 Nov 2025 15:29:45 GMT Subject: RFR: 8371914: PNG defines in CFLAGS can cause compilation errors with external libpng Message-ID: When building with external libpng the PNG defines added to CFLAGS may conflict with the installed libpng header pnglibconf.h resulting in compilation errors. For example on OpenBSD/aarch64: `/usr/local/include/pnglibconf.h:207:9: error: 'PNG_ARM_NEON_OPT' macro redefined [-Werror,-Wmacro-redefined]` This moves all `-DPNG_*` into the case where internal libpng is used. This has only been tested with the tier1 github actions so needs to be checked on Linux/ppc and AIX. ------------- Commit messages: - Only add libpng defines to CFLAGS when using internal libpng. Changes: https://git.openjdk.org/jdk/pull/28324/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28324&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371914 Stats: 37 lines in 1 file changed: 18 ins; 18 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28324.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28324/head:pull/28324 PR: https://git.openjdk.org/jdk/pull/28324 From serb at openjdk.org Fri Nov 14 21:33:00 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 14 Nov 2025 21:33:00 GMT Subject: RFR: 8042054: JTree.updateUI uses out-of-date item size information [v2] In-Reply-To: References: Message-ID: On Fri, 14 Nov 2025 07:31:32 GMT, Prasanta Sadhukhan wrote: >I couldn't find any issue with it. You can reproduce this issue with a custom renderer that depends on some data from the tree. If that data in turn depends on the current UI, then the renderer may continue using outdated UI information. Most components update their UI starting from the current component down the subtree: either by calling updateComponentTreeUI or by using the same pattern deleted in this patch. Examples JComboBox, JInternalFrame, JList, etc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28258#discussion_r2528993931 From honkar at openjdk.org Fri Nov 14 23:12:04 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 14 Nov 2025 23:12:04 GMT Subject: RFR: JDK-8365426 : [macos26] Graphics2D tests fail on new macOS 26 In-Reply-To: References: Message-ID: On Fri, 14 Nov 2025 06:20:08 GMT, Sergey Bylokhov wrote: >> test/jdk/java/awt/Graphics2D/CopyAreaOOB.java line 73: >> >>> 71: try { >>> 72: if (!Platform.isOSX()) { >>> 73: TOLERANCE = PRIMARY_TOLERANCE; >> >> I could set tolerance and primary_tolerance both to zero on other platforms although I have currently set it to a small delta of 2. I can change it to zero if any reviewers suggest that exact color compare would be better. > > What is the reason for the color mismatch? Is it possible to check whether it is caused by the rendering pipeline (for example, different colors between metal and ogl), by the native code used by robot (we could compare it with a native screencapture tool), by the code that converts the native image to Java (using Robot.createMultiResolutionScreenCapture might help), or by some blending at the edges of the rendered area? Couple of observations - The test fails irrespective of whether opengl or metal pipeline is used - The color inconsistency is not only at the edges but at random points (can be checked by enabling DEBUG in the test) - Apple introduced Metal 4 APIs on Apple macOS26 but this can be eliminated as the root cause since the issue occurs on macOS26 x64 as well and when using opengl. - Setting color profile to sRGB doesn't work either. - One probable cause could be that CRobot uses deprecated [CGWindowListCreateImage](https://developer.apple.com/documentation/coregraphics/cgwindowlistcreateimage(_:_:_:_:)?language=objc) for screencapture and the recommended new API is ScreenCaptureKit. Currently the test fails on CI (macOS26) creating noise and adding a color tolerance is the best workaround for now until the root cause or the new feature/setting which is causing the issue on macOS26 is found. I'll create a new JBS issue to track it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28312#discussion_r2529204369 From honkar at openjdk.org Fri Nov 14 23:57:17 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 14 Nov 2025 23:57:17 GMT Subject: Integrated: JDK-8365426 : [macos26] Graphics2D tests fail on new macOS 26 In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 23:20:18 GMT, Harshitha Onkar wrote: > This test started to fail on macOS26 due to color inconsistency at certain points. > Color tolerance has been added as a fix. > > The color tolerance for the dominant component (eg Color.RED - dominant component is red) is set less (delta /PRIMARY_TOLERANCE = 2) and for non-dominant (For Color.RED - Green and Blue are non-dominant) is set more (delta / TOLERANCE=30). This ensures we are checking for shades (brighter/lighter) of the expected color. > > Since the issue is only seen on macOS, I have set both PRIMARY_TOLERANCE & TOLERANCE to 2 on other platforms to keep the test almost close to the original one. > > Tested locally on macOS 26.0.1 and 26.1 and fix works as expected. > > CI testing on other platforms looks good and no regressions are observed (Link added to JBS). This pull request has now been integrated. Changeset: 7c169c98 Author: Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/7c169c9814a694126f524e8941b1035e6695900c Stats: 44 lines in 1 file changed: 19 ins; 2 del; 23 mod 8365426: [macos26] Graphics2D tests fail on new macOS 26 Reviewed-by: kizune, dnguyen ------------- PR: https://git.openjdk.org/jdk/pull/28312 From serb at openjdk.org Sat Nov 15 00:24:10 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 15 Nov 2025 00:24:10 GMT Subject: RFR: JDK-8365426 : [macos26] Graphics2D tests fail on new macOS 26 In-Reply-To: References: Message-ID: On Fri, 14 Nov 2025 23:09:51 GMT, Harshitha Onkar wrote: >Currently the test fails on CI (macOS26) creating noise and adding a color tolerance is the best workaround for now until the root cause or the new feature/setting which is causing the issue on macOS26 is found. I can create a new JBS issue to track it. So the reason is actually unknown, and it does not seem to be related to blending on the corners or to shadows. So why did we change the test instead of investigating why J2D renders the wrong color? It could be better to problem list it since initial version was able to reproduce the bug. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28312#discussion_r2529308681 From psadhukhan at openjdk.org Sun Nov 16 06:48:08 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Sun, 16 Nov 2025 06:48:08 GMT Subject: RFR: 8042054: JTree.updateUI uses out-of-date item size information [v2] In-Reply-To: References: Message-ID: On Fri, 14 Nov 2025 21:30:17 GMT, Sergey Bylokhov wrote: > You can reproduce this issue with a custom renderer Did you manage to reproduce? If yes, could you give me the reproducer then? Regarding other components, the submitter did talk about other JBS submitted by him like JList for example being ignored so maybe same thing needs to be done there too.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28258#discussion_r2531494313 From serb at openjdk.org Mon Nov 17 03:37:05 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 17 Nov 2025 03:37:05 GMT Subject: RFR: 8042054: JTree.updateUI uses out-of-date item size information [v2] In-Reply-To: References: Message-ID: On Sun, 16 Nov 2025 06:44:58 GMT, Prasanta Sadhukhan wrote: >>>I couldn't find any issue with it. >> >> You can reproduce this issue with a custom renderer that depends on some data from the tree. If that data in turn depends on the current UI, then the renderer may continue using outdated UI information. >> >> Most components update their UI starting from the current component down the subtree: either by calling updateComponentTreeUI or by using the same pattern deleted in this patch. Examples JComboBox, JInternalFrame, JList, etc. > >> You can reproduce this issue with a custom renderer > Did you manage to reproduce? If yes, could you give me the reproducer then? > > Regarding other components, the submitter did talk about other JBS submitted by him like JList for example being ignored so maybe same thing needs to be done there too.. I do not think we should change the parent->child order. We need to figure out some other possibilities. Possibly some components that use the same logic are not affected because they perform additional recalculations at the end of their UI updates. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28258#discussion_r2532566964 From psadhukhan at openjdk.org Mon Nov 17 04:58:10 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 17 Nov 2025 04:58:10 GMT Subject: RFR: 8042054: JTree.updateUI uses out-of-date item size information [v2] In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 03:34:23 GMT, Sergey Bylokhov wrote: >>> You can reproduce this issue with a custom renderer >> Did you manage to reproduce? If yes, could you give me the reproducer then? >> >> Regarding other components, the submitter did talk about other JBS submitted by him like JList for example being ignored so maybe same thing needs to be done there too.. > > I do not think we should change the parent->child order. We need to figure out some other possibilities. Possibly some components that use the same logic are not affected because they perform additional recalculations at the end of their UI updates. > either by calling updateComponentTreeUI or by using the same pattern deleted in this patch If calling updateComponentTreeUI is logical updation to be done after L&F change, then maybe we can consider it as a pertinent solution too and close this as not an issue.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28258#discussion_r2532699537 From aturbanov at openjdk.org Mon Nov 17 09:11:43 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 17 Nov 2025 09:11:43 GMT Subject: Integrated: 8349157: Unnecessary Hashtable usage in XKeysym.javaKeycode2KeysymHash In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 09:35:09 GMT, Andrey Turbanov wrote: > There is a field `sun.awt.X11.XKeysym#javaKeycode2KeysymHash` which uses legacy Hashtable class. > As this map is read-only and all its content is initialized in `` we can safely use immutable Map instead. This pull request has now been integrated. Changeset: 69e30244 Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/69e30244c0c359e7108acd36d903fa22970822b9 Stats: 20 lines in 1 file changed: 7 ins; 9 del; 4 mod 8349157: Unnecessary Hashtable usage in XKeysym.javaKeycode2KeysymHash Reviewed-by: aivanov, serb ------------- PR: https://git.openjdk.org/jdk/pull/23347 From dgredler at openjdk.org Mon Nov 17 16:12:47 2025 From: dgredler at openjdk.org (Daniel Gredler) Date: Mon, 17 Nov 2025 16:12:47 GMT Subject: RFR: 8167268: StandardGlyphVector.getGlyphMetrics creates metrics with erroneous bounds for characters with no outline (e.g., the space character ' ') [v2] In-Reply-To: References: <5ByvfoSYjN0rek4eEOaZIhSkoaDnNMAO7jiCiO0U7Yk=.6b551db8-0733-46c3-b97b-aed5754eb9a2@github.com> Message-ID: On Tue, 30 Sep 2025 20:12:22 GMT, Daniel Gredler wrote: >> `GlyphMetrics` objects returned by `StandardGlyphVector.getGlyphMetrics(int)` contain bounds that are calculated by taking the glyph?s visual bounds and normalizing them by subtracting the glyph?s position. >> >> However, some glyphs (e.g., the glyph for the space character) do not have visual bounds. Their outline is an empty shape. In such a case the bounds in the metrics should not be normalized by the glyph?s position. The code erroneously ignores this special case, thus producing bounds with inconsistent negative x-positions. > > Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision: > > Split long line This one needs a second review, if anyone has some availability. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27580#issuecomment-3542696499 From dgredler at openjdk.org Mon Nov 17 16:12:46 2025 From: dgredler at openjdk.org (Daniel Gredler) Date: Mon, 17 Nov 2025 16:12:46 GMT Subject: RFR: 8368702: [macosx] Printing text with composite fonts loses font transform In-Reply-To: References: Message-ID: <_aia8reFDSKKvEehbN8uL1-6bKpC2m6uJnatkYr6v18=.2038f90a-6ec7-4845-bed2-bd9b34b2a4f6@github.com> On Mon, 29 Sep 2025 11:46:47 GMT, Daniel Gredler wrote: > When printing text on macOS, if the text uses a composite font (a logical font composed of more than one physical font) with a custom affine transform, the transform can be lost, and the text printed without the transform applied. > > This is one of a few issues affecting the problem listed manual test `java/awt/print/PrinterJob/PrintTextTest.java` on macOS, and can be observed on page 10, on the last line ("TextLayout 2"). Without the fix, the text on this line is not stretched across the x-axis, resulting in large gaps of white space between runs of different script types. This one needs a second review, if anyone has some availability. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27544#issuecomment-3542694306 From erikj at openjdk.org Mon Nov 17 19:04:35 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 17 Nov 2025 19:04:35 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: <2UyKPJka869d7X4QtgbdbiGyYPkYnJH1DmRCpinPJMA=.6080b598-0e51-4ec6-bc72-7b0d68ef42d4@github.com> Message-ID: On Wed, 12 Nov 2025 08:59:52 GMT, Matthias Baesken wrote: >>>I think there was the concern raised previously, that without setting it for at least one lib, nobody would use/try it and the feature would 'rot' . >> >> I see, I'll run the tests for this lib then. > >> I see, I'll run the tests for this lib then. > > Great, thanks ! Please tell if it works for you and what are the size reductions you get for the lib (mostly for gcc). > Also please tell about your opinion on the configure option to enable/disable the whole 'lto on jdk native libs' . I don't think we need to disable this on a global level. For hotspot it was done because it only ever worked in specific jvm configurations. We can revisit that if we discover problems with specific toolchain versions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2535204191 From erikj at openjdk.org Mon Nov 17 20:15:15 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 17 Nov 2025 20:15:15 GMT Subject: RFR: 8371914: PNG defines in CFLAGS can cause compilation errors with external libpng In-Reply-To: References: Message-ID: On Fri, 14 Nov 2025 14:48:14 GMT, Kurt Miller wrote: > When building with external libpng the PNG defines added to CFLAGS may conflict with the installed libpng header pnglibconf.h resulting in compilation errors. For example on OpenBSD/aarch64: > > `/usr/local/include/pnglibconf.h:207:9: error: 'PNG_ARM_NEON_OPT' macro redefined [-Werror,-Wmacro-redefined]` > > This moves all `-DPNG_*` into the case where internal libpng is used. This has only been tested with the tier1 github actions so needs to be checked on Linux/ppc and AIX. I think this looks ok, but someone from client should weigh in too. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28324#pullrequestreview-3474397386 From dnguyen at openjdk.org Mon Nov 17 21:24:27 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 17 Nov 2025 21:24:27 GMT Subject: Integrated: 8150564: Migrate useful ExtendedRobot methods into awt.Robot In-Reply-To: References: Message-ID: <3tfVaCcWnw-n67d_XVdd5nSs4bObrTEXCWkZDJWkstc=.0a7891f5-8afc-43d7-b8ba-4066d20308b6@github.com> On Wed, 27 Aug 2025 18:36:30 GMT, Damon Nguyen wrote: > Some useful methods (click, glide, waitForIdle, type) in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using these ExtendedRobot methods will be handled separately. This pull request has now been integrated. Changeset: e0670387 Author: Damon Nguyen URL: https://git.openjdk.org/jdk/commit/e067038796e2798132e07aa47b695f3c21b87e79 Stats: 227 lines in 1 file changed: 227 ins; 0 del; 0 mod 8150564: Migrate useful ExtendedRobot methods into awt.Robot Reviewed-by: kizune, prr, liach ------------- PR: https://git.openjdk.org/jdk/pull/26969 From serb at openjdk.org Tue Nov 18 00:58:01 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 18 Nov 2025 00:58:01 GMT Subject: RFR: 8042054: JTree.updateUI uses out-of-date item size information [v2] In-Reply-To: References: Message-ID: <4nSpiTCuM72-GVjWm8-ukgr_wnEanjktrQcoqCvZ77A=.a19ae102-5b0f-4164-88e8-ba6c4c7295e3@github.com> On Mon, 17 Nov 2025 04:55:52 GMT, Prasanta Sadhukhan wrote: >If calling updateComponentTreeUI is logical updation to be done after L&F change, then maybe we can consider it as a pertinent solution too and close this as not an issue.. We should check the other components. Are any of them affected? If not we can check why, and apply the same logic to jtree. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28258#discussion_r2535968329 From jdv at openjdk.org Tue Nov 18 06:20:16 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 18 Nov 2025 06:20:16 GMT Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out on macOS 12 [v7] In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 07:04:57 GMT, Prasanta Sadhukhan wrote: >> Test used to timeout even though it seems the test passed..Increased the timeout to a safe value as sometimes it shows elapsed time to timeout > 300secs in macOS in CI and also ensured the wait-time for child process to execute the test is not been waiting endlessly. >> Also ensured the original display mode is resetted after the test to prevent affecting following tests. >> >> Tried 100 iterations of the fix on all platforms which is ok > > Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - PL updation > - Merge master > - Added mac ARM JBS > - PL updation > - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8273617 > - Remove displayMode reset > - EDT fix, timeout reduced > - 8273617: UninitializedDisplayModeChangeTest.java times out on macOS 12 This test continues to hang and leave 2 windows open even after jtreg says test passed when run on external display. Open windows are not responding and we need to explicitly force close them. On default retinal display it runs fine and doesn't leave any open windows. I have M1 Macbook running macOS 26.1. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27365#issuecomment-3545429953 From psadhukhan at openjdk.org Tue Nov 18 08:22:17 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 18 Nov 2025 08:22:17 GMT Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out on macOS 12 [v7] In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 07:04:57 GMT, Prasanta Sadhukhan wrote: >> Test used to timeout even though it seems the test passed..Increased the timeout to a safe value as sometimes it shows elapsed time to timeout > 300secs in macOS in CI and also ensured the wait-time for child process to execute the test is not been waiting endlessly. >> Also ensured the original display mode is resetted after the test to prevent affecting following tests. >> >> Tried 100 iterations of the fix on all platforms which is ok > > Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - PL updation > - Merge master > - Added mac ARM JBS > - PL updation > - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8273617 > - Remove displayMode reset > - EDT fix, timeout reduced > - 8273617: UninitializedDisplayModeChangeTest.java times out on macOS 12 ok..atleast now it is passing consistently in retina unlike earlier when it was initially raised, which is a move in positive direction..probably an apple bug.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27365#issuecomment-3546117056 From psadhukhan at openjdk.org Tue Nov 18 08:22:19 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 18 Nov 2025 08:22:19 GMT Subject: Withdrawn: 8273617: UninitializedDisplayModeChangeTest.java times out on macOS 12 In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 13:24:06 GMT, Prasanta Sadhukhan wrote: > Test used to timeout even though it seems the test passed..Increased the timeout to a safe value as sometimes it shows elapsed time to timeout > 300secs in macOS in CI and also ensured the wait-time for child process to execute the test is not been waiting endlessly. > Also ensured the original display mode is resetted after the test to prevent affecting following tests. > > Tried 100 iterations of the fix on all platforms which is ok This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27365 From psadhukhan at openjdk.org Tue Nov 18 09:02:38 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 18 Nov 2025 09:02:38 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update [v4] In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 16:17:14 GMT, Srinivas Mandalika wrote: >> Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java >> Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Fixed whitepsace error. are the same instructions valid for all platforms? test/jdk/ProblemList.txt line 783: > 781: java/awt/Modal/WsDisabledStyle/CloseBlocker/CloseBlocker.java 7187741 linux-all,macosx-all > 782: java/awt/xembed/server/TestXEmbedServerJava.java 8001150,8004031 generic-all > 783: java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java 8162380 generic-all what about this PL entry? should be removed!!! test/jdk/java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java line 64: > 62: "3.Press the button on Window (1) & Window (2) \n" + > 63: "Verification step:\n" + > 64: "\tIf Modality is 'Non-modal'or 'Modeless', Button is presseed \n" + presseed -> pressed test/jdk/java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java line 65: > 63: "Verification step:\n" + > 64: "\tIf Modality is 'Non-modal'or 'Modeless', Button is presseed \n" + > 65: "\tIf Modality is 'Document'& parent is not Frame/Dialog, Button is presseed \n" + presseed -> pressed test/jdk/java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java line 68: > 66: "\tIn all other cases, button is not pressed & Window (3) should \n" + > 67: "\tblock input to Windows (1) & (2).\n\n" + > 68: "4. Next, press the 'Open' button in Window (3to open print dialog.\n\n" + closing brace test/jdk/java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java line 78: > 76: "should be seen, as before.\n" + > 77: "To close all test windows, press 'Finish'.\n\n" + > 78: "7. Repeat the steps for different combinations od Dialog Parent, Dialog Modality Type, Print Dialg Type.\n" + od -> of ------------- PR Review: https://git.openjdk.org/jdk/pull/27139#pullrequestreview-3476272691 PR Review Comment: https://git.openjdk.org/jdk/pull/27139#discussion_r2536951544 PR Review Comment: https://git.openjdk.org/jdk/pull/27139#discussion_r2536937973 PR Review Comment: https://git.openjdk.org/jdk/pull/27139#discussion_r2536940128 PR Review Comment: https://git.openjdk.org/jdk/pull/27139#discussion_r2536941457 PR Review Comment: https://git.openjdk.org/jdk/pull/27139#discussion_r2536945004 From smandalika at openjdk.org Tue Nov 18 09:02:39 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Tue, 18 Nov 2025 09:02:39 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update [v4] In-Reply-To: References: Message-ID: <4dptE_SoFqbHPAo5Jbuv6m4ipo77-NOpRbSb6sTKkGA=.97cec7c4-0dcb-4fc6-a4be-dfbc3aa7c341@github.com> On Mon, 3 Nov 2025 16:17:14 GMT, Srinivas Mandalika wrote: >> Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java >> Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Fixed whitepsace error. Hi, can someone take a quick look and provide feedback on this simple instruction update MR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27139#issuecomment-3546182450 From psadhukhan at openjdk.org Tue Nov 18 09:02:41 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 18 Nov 2025 09:02:41 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update [v4] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 08:55:14 GMT, Prasanta Sadhukhan wrote: >> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed whitepsace error. > > test/jdk/java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java line 65: > >> 63: "Verification step:\n" + >> 64: "\tIf Modality is 'Non-modal'or 'Modeless', Button is presseed \n" + >> 65: "\tIf Modality is 'Document'& parent is not Frame/Dialog, Button is presseed \n" + > > presseed -> pressed space after 'Document' ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27139#discussion_r2536943279 From rkannathpari at openjdk.org Tue Nov 18 11:34:48 2025 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 18 Nov 2025 11:34:48 GMT Subject: RFR: 8372048: Performance improvement on Linux remote desktop Message-ID: Hi Reviewers, Observed these two demon threads are created on class initializing time due to static variable and static block call. Observed [ScreencastHelper.isAvailable()](https://github.com/openjdk/jdk/blob/28d94d6ab4994b844af98c5c227b40b5fb8a72e5/src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java#L1527) from XToolkit.java call is enough to start these demon threads on latest Linux (Gnome version 47 and above). In my observation some simple workflows not passing through the code where these **Watchers** are required, at the same time threads are running because of the above reason. So moving those into lazy loading will improve loading time and performance. Please review and let me know your suggestions. Renjith. ------------- Commit messages: - 8372048: Performance improvement on Linux remote desktop Changes: https://git.openjdk.org/jdk/pull/28369/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28369&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372048 Stats: 32 lines in 2 files changed: 25 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28369.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28369/head:pull/28369 PR: https://git.openjdk.org/jdk/pull/28369 From azvegint at openjdk.org Tue Nov 18 14:18:05 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 18 Nov 2025 14:18:05 GMT Subject: RFR: 8372048: Performance improvement on Linux remote desktop In-Reply-To: References: Message-ID: <2syebYk098G_EhY20dqOJgUeU0Q1wPA44lKvgJEnt10=.42cb457d-6673-4163-969d-74a2070079ef@github.com> On Tue, 18 Nov 2025 11:27:30 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > > Observed these two demon threads are created on class initializing time due to static variable and static block call. Observed [ScreencastHelper.isAvailable()](https://github.com/openjdk/jdk/blob/28d94d6ab4994b844af98c5c227b40b5fb8a72e5/src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java#L1527) from XToolkit.java call is enough to start these demon threads on latest Linux (Gnome version 47 and above). In my observation some simple workflows not passing through the code where these **Watchers** are required, at the same time threads are running because of the above reason. So moving those into lazy loading will improve loading time and performance. > > Please review and let me know your suggestions. > > Renjith. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28369#pullrequestreview-3478054932 From fkirmaier at openjdk.org Tue Nov 18 14:31:47 2025 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Tue, 18 Nov 2025 14:31:47 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v2] In-Reply-To: <9laKluorZwfx_Zo5zghvmrAWLqHloigB6eHhrWCcwW0=.7e8113ab-8c09-415b-861f-865d1da4959e@github.com> References: <9laKluorZwfx_Zo5zghvmrAWLqHloigB6eHhrWCcwW0=.7e8113ab-8c09-415b-861f-865d1da4959e@github.com> Message-ID: On Thu, 30 Oct 2025 20:03:22 GMT, Phil Race wrote: >> Christian Heilmann has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS >> - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS >> - Merge branch 'master' of https://github.com/openjdk/jdk into pr/11266 >> - Merge branch 'master' into pr/11266 >> - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS > > Note as I wrote in an old comment in this PR, this JBS issue title needed to be improved. > I've updated it and now you'll need to make the PR title match. @prrace Anything else left we should do get this PR merged? Would be appreciated, if we can complete this PR. :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3546448561 From aivanov at openjdk.org Tue Nov 18 14:31:47 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 18 Nov 2025 14:31:47 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v2] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 01:41:44 GMT, Phil Race wrote: > I think this all bears a bit more studying as to which code to update for the fix - one of these has to go (although knowsPageRange probably needs to exist and return YES, else the peek won't happen if I correctly read the Apple docs) We have to return `YES` to `knowsPageRange`. Printing doesn't work otherwise. I am still for simplifying the code if we're accepting what's currently suggested: 1. Get rid of `totalPages`. ([comment](https://github.com/openjdk/jdk/pull/11266#discussion_r2298979119)) 2. Always use NSIntegerMax and remove the fTotalPages field. ([comment](https://github.com/openjdk/jdk/pull/11266#discussion_r2298982204)) ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3547871808 From duke at openjdk.org Tue Nov 18 15:01:14 2025 From: duke at openjdk.org (Christian Heilmann) Date: Tue, 18 Nov 2025 15:01:14 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v3] In-Reply-To: References: Message-ID: > This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS. > > The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m. Christian Heilmann has updated the pull request incrementally with three additional commits since the last revision: - Update PrinterView.m - Update PrinterView.h - Update CPrinterJob.m ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11266/files - new: https://git.openjdk.org/jdk/pull/11266/files/857a3781..8d00e6c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11266&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11266&range=01-02 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11266.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/11266/head:pull/11266 PR: https://git.openjdk.org/jdk/pull/11266 From duke at openjdk.org Tue Nov 18 15:01:29 2025 From: duke at openjdk.org (Christian Heilmann) Date: Tue, 18 Nov 2025 15:01:29 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v2] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 19:51:27 GMT, Alexey Ivanov wrote: >> Christian Heilmann has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS >> - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS >> - Merge branch 'master' of https://github.com/openjdk/jdk into pr/11266 >> - Merge branch 'master' into pr/11266 >> - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS > > src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m line 1: > >> 1: /* > > Bump the copyright year to 2025. done. > src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.h line 1: > >> 1: /* > > Update the copyright year. done. > src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m line 1: > >> 1: /* > > Update the copyright year. done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11266#discussion_r2538522138 PR Review Comment: https://git.openjdk.org/jdk/pull/11266#discussion_r2538528608 PR Review Comment: https://git.openjdk.org/jdk/pull/11266#discussion_r2538528166 From duke at openjdk.org Tue Nov 18 15:01:26 2025 From: duke at openjdk.org (eduardsdv) Date: Tue, 18 Nov 2025 15:01:26 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v2] In-Reply-To: References: Message-ID: On Fri, 18 Jul 2025 13:19:10 GMT, Christian Heilmann wrote: >> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS. >> >> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m. > > Christian Heilmann has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS > - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS > - Merge branch 'master' of https://github.com/openjdk/jdk into pr/11266 > - Merge branch 'master' into pr/11266 > - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS > I am still for simplifying the code if we're accepting what's currently suggested: > 1. Get rid of ``totalPages``. > 2. Always use NSIntegerMax and remove the fTotalPages field. The operating system may choose a different printing strategy (for example printing in reverse order) or UI feature depending on whether or not it knows the total number of available pages. If we know the number, why hide this information? Furthermore, even if macOS's current behaviour does not differ essentially (see this [comment](https://github.com/openjdk/jdk/pull/11266#issuecomment-3496509402)), it may do so in the future. Do we really want to touch this code again in the future? ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3547984684 From dgredler at openjdk.org Tue Nov 18 16:32:45 2025 From: dgredler at openjdk.org (Daniel Gredler) Date: Tue, 18 Nov 2025 16:32:45 GMT Subject: RFR: 8372048: Performance improvement on Linux remote desktop In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 11:27:30 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > > Observed these two demon threads are created on class initializing time due to static variable and static block call. Observed [ScreencastHelper.isAvailable()](https://github.com/openjdk/jdk/blob/28d94d6ab4994b844af98c5c227b40b5fb8a72e5/src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java#L1527) from XToolkit.java call is enough to start these demon threads on latest Linux (Gnome version 47 and above). In my observation some simple workflows not passing through the code where these **Watchers** are required, at the same time threads are running because of the above reason. So moving those into lazy loading will improve loading time and performance. > > Please review and let me know your suggestions. > > Renjith. I'm not familiar with this part of the code, but this might be a good candidate for `StableValue` / `LazyConstant`, once it's ready? https://mail.openjdk.org/pipermail/client-libs-dev/2025-September/032518.html ------------- PR Comment: https://git.openjdk.org/jdk/pull/28369#issuecomment-3548497817 From aivanov at openjdk.org Tue Nov 18 16:38:46 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 18 Nov 2025 16:38:46 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v2] In-Reply-To: References: Message-ID: <5lmqQHUbBU1yxP1TBDriW3til76-9EORSR2mNB4DqDE=.c121bd0b-e276-4e44-b830-7b6291026255@github.com> On Tue, 18 Nov 2025 14:53:00 GMT, eduardsdv wrote: > > I am still for simplifying the code if we're accepting what's currently suggested: > > > > 1. Get rid of `totalPages`. > > 2. Always use NSIntegerMax and remove the fTotalPages field. > > The operating system may choose a different printing strategy (for example printing in reverse order) or UI feature depending on whether or not it knows the total number of available pages. If we know the number, why hide this information? You're right? Will Java code still handle this situation correctly if the OS decides to print in reverse order? > Furthermore, even if macOS's current behaviour does not differ essentially (see this [comment](https://github.com/openjdk/jdk/pull/11266#issuecomment-3496509402)), it may do so in the future. Do we really want to touch this code again in the future? Fair enough. I agree it should be future-proof. On the other hand, as Phil highlighted, should we then communicate our intent of printing the range of pages to macOS and pass *the start page* correctly as we do now (in the unfixed code) contrasting with always passing 1 in the suggested fix? And, instead, to modify the code that applies the range for the second time to ensure ?we are **NOT** setting a range within a range?? ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3548524383 From kizune at openjdk.org Tue Nov 18 22:31:13 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 18 Nov 2025 22:31:13 GMT Subject: RFR: 8372120: Add missing sound keyword to MIDI tests Message-ID: Add missing keyword to the tests where it is required but missing. ------------- Commit messages: - 8372120: Add missing sound keyword to MIDI tests Changes: https://git.openjdk.org/jdk/pull/28382/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28382&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372120 Stats: 5 lines in 5 files changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28382.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28382/head:pull/28382 PR: https://git.openjdk.org/jdk/pull/28382 From kcr at openjdk.org Tue Nov 18 22:42:57 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 18 Nov 2025 22:42:57 GMT Subject: RFR: 8372120: Add missing sound keyword to MIDI tests In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 22:22:36 GMT, Alexander Zuev wrote: > Add missing keyword to the tests where it is required but missing. LGTM ------------- Marked as reviewed by kcr (Author). PR Review: https://git.openjdk.org/jdk/pull/28382#pullrequestreview-3479951193 From duke at openjdk.org Tue Nov 18 22:42:58 2025 From: duke at openjdk.org (lawrence.andrews) Date: Tue, 18 Nov 2025 22:42:58 GMT Subject: RFR: 8372120: Add missing sound keyword to MIDI tests In-Reply-To: References: Message-ID: <_Hdk-elO_Z9nH17CS34bqrEIIV9gM_8d6Bio0mlgATk=.ab1801bd-bdb4-419b-8168-e338aad2ba03@github.com> On Tue, 18 Nov 2025 22:22:36 GMT, Alexander Zuev wrote: > Add missing keyword to the tests where it is required but missing. LGTM ------------- PR Comment: https://git.openjdk.org/jdk/pull/28382#issuecomment-3549722343 From serb at openjdk.org Tue Nov 18 23:30:30 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 18 Nov 2025 23:30:30 GMT Subject: RFR: 8372120: Add missing sound keyword to MIDI tests In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 22:22:36 GMT, Alexander Zuev wrote: > Add missing keyword to the tests where it is required but missing. test/jdk/javax/sound/midi/spi/MidiDeviceProvider/ExpectedNPEOnNull.java line 36: > 34: * @bug 8143909 > 35: * @key sound > 36: * @author Sergey Bylokhov What exception causes this(and others) tests to fail if the hardware device is not configured? please add it to the PR of jbs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28382#discussion_r2539938219 From serb at openjdk.org Tue Nov 18 23:35:26 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 18 Nov 2025 23:35:26 GMT Subject: RFR: 8372048: Performance improvement on Linux remote desktop In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 11:27:30 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > > Observed these two demon threads are created on class initializing time due to static variable and static block call. Observed [ScreencastHelper.isAvailable()](https://github.com/openjdk/jdk/blob/28d94d6ab4994b844af98c5c227b40b5fb8a72e5/src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java#L1527) from XToolkit.java call is enough to start these demon threads on latest Linux (Gnome version 47 and above). In my observation some simple workflows not passing through the code where these **Watchers** are required, at the same time threads are running because of the above reason. So moving those into lazy loading will improve loading time and performance. > > Please review and let me know your suggestions. > > Renjith. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28369#pullrequestreview-3480075746 From dholmes at openjdk.org Tue Nov 18 23:45:11 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 18 Nov 2025 23:45:11 GMT Subject: RFR: 8372120: Add missing sound keyword to MIDI tests In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 22:22:36 GMT, Alexander Zuev wrote: > Add missing keyword to the tests where it is required but missing. Seems fine to me. Just to be clear these "key" values simply allow you to tell jtreg to include/exclude a test based on the key value, so it just gives finer-grained control. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28382#pullrequestreview-3480099319 From kizune at openjdk.org Tue Nov 18 23:54:46 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 18 Nov 2025 23:54:46 GMT Subject: RFR: 8372120: Add missing sound keyword to MIDI tests In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 23:43:03 GMT, David Holmes wrote: > Seems fine to me. Just to be clear these "key" values simply allow you to tell jtreg to include/exclude a test based on the key value, so it just gives finer-grained control. Yes, the key will not alter the logic of the test itself - just add a means to be included or excluded depending on the test harness parameters. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28382#issuecomment-3549928525 From kizune at openjdk.org Tue Nov 18 23:54:46 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 18 Nov 2025 23:54:46 GMT Subject: RFR: 8372120: Add missing sound keyword to MIDI tests In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 23:26:43 GMT, Sergey Bylokhov wrote: >> Add missing keyword to the tests where it is required but missing. > > test/jdk/javax/sound/midi/spi/MidiDeviceProvider/ExpectedNPEOnNull.java line 36: > >> 34: * @bug 8143909 >> 35: * @key sound >> 36: * @author Sergey Bylokhov > > What exception causes this(and others) tests to fail if the hardware device is not configured? please add it to the PR of jbs. It can cause these tests to hang in native methods if device is not configured or not accessible in latest macOS. We need finer control as to which tests needs not to be executed on such machines. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28382#discussion_r2539975863 From kizune at openjdk.org Tue Nov 18 23:54:47 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 18 Nov 2025 23:54:47 GMT Subject: Integrated: 8372120: Add missing sound keyword to MIDI tests In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 22:22:36 GMT, Alexander Zuev wrote: > Add missing keyword to the tests where it is required but missing. This pull request has now been integrated. Changeset: 902aa4dc Author: Alexander Zuev URL: https://git.openjdk.org/jdk/commit/902aa4dcd297fef34cb302e468b030c48665ec84 Stats: 5 lines in 5 files changed: 5 ins; 0 del; 0 mod 8372120: Add missing sound keyword to MIDI tests Reviewed-by: kcr, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/28382 From serb at openjdk.org Wed Nov 19 00:03:54 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 19 Nov 2025 00:03:54 GMT Subject: RFR: 8372120: Add missing sound keyword to MIDI tests In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 23:48:44 GMT, Alexander Zuev wrote: >> test/jdk/javax/sound/midi/spi/MidiDeviceProvider/ExpectedNPEOnNull.java line 36: >> >>> 34: * @bug 8143909 >>> 35: * @key sound >>> 36: * @author Sergey Bylokhov >> >> What exception causes this(and others) tests to fail if the hardware device is not configured? please add it to the PR of jbs. > > It can cause these tests to hang in native methods if device is not configured or not accessible in latest macOS. We need finer control as to which tests needs not to be executed on such machines. Then it seems like a product bug that this test hangs. Why don?t you list add it to the problem list? What are the stack traces? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28382#discussion_r2539992559 From smandalika at openjdk.org Wed Nov 19 06:03:07 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Wed, 19 Nov 2025 06:03:07 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update [v4] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 08:58:43 GMT, Prasanta Sadhukhan wrote: > are the same instructions valid for all platforms? I have checked the behavior on a Windows 11 x64, Mac OS 15 arch64, Ubuntu 24.04. In all the machines the new instructions are applicable and there was no need for an OS-specific instruction change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27139#issuecomment-3550930282 From smandalika at openjdk.org Wed Nov 19 06:15:37 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Wed, 19 Nov 2025 06:15:37 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update [v4] In-Reply-To: References: Message-ID: <1JeSv0KBFciGWsc_fh1aqPVIKc2oWCvoA1rTaYGbRqA=.b7a66c0f-9f18-48da-9377-58f26096149a@github.com> On Tue, 18 Nov 2025 08:57:44 GMT, Prasanta Sadhukhan wrote: >> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed whitepsace error. > > test/jdk/ProblemList.txt line 783: > >> 781: java/awt/Modal/WsDisabledStyle/CloseBlocker/CloseBlocker.java 7187741 linux-all,macosx-all >> 782: java/awt/xembed/server/TestXEmbedServerJava.java 8001150,8004031 generic-all >> 783: java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java 8162380 generic-all > > what about this PL entry? should be removed!!! java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java 8068378 generic-all This is the test whose instructions have been modified and it is removed. java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java 8162380 generic-all This test is unrelated to this PR and it came in as part of an earlier merge conflict resolution. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27139#discussion_r2540676366 From smandalika at openjdk.org Wed Nov 19 06:18:10 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Wed, 19 Nov 2025 06:18:10 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update [v4] In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 16:17:14 GMT, Srinivas Mandalika wrote: >> Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java >> Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Fixed whitepsace error. - Checked the behavior on a Windows 11 x64, Mac OS 15 arch64, Ubuntu 24.04. In all the machines the new instructions are applicable as is, and there was no need for an OS-specific instruction change. - Fixed all suggested typos. - No change to PL as it does not have the above test - it included a separate test as part of a merge conflict resolution. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27139#issuecomment-3550976789 From smandalika at openjdk.org Wed Nov 19 06:22:20 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Wed, 19 Nov 2025 06:22:20 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update [v5] In-Reply-To: References: Message-ID: > Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java > Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt. Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: Fixed Typos ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27139/files - new: https://git.openjdk.org/jdk/pull/27139/files/aa874e0c..3512ea2e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27139&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27139&range=03-04 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/27139.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27139/head:pull/27139 PR: https://git.openjdk.org/jdk/pull/27139 From psadhukhan at openjdk.org Wed Nov 19 06:53:25 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 19 Nov 2025 06:53:25 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update [v4] In-Reply-To: <1JeSv0KBFciGWsc_fh1aqPVIKc2oWCvoA1rTaYGbRqA=.b7a66c0f-9f18-48da-9377-58f26096149a@github.com> References: <1JeSv0KBFciGWsc_fh1aqPVIKc2oWCvoA1rTaYGbRqA=.b7a66c0f-9f18-48da-9377-58f26096149a@github.com> Message-ID: On Wed, 19 Nov 2025 06:13:13 GMT, Srinivas Mandalika wrote: >> test/jdk/ProblemList.txt line 783: >> >>> 781: java/awt/Modal/WsDisabledStyle/CloseBlocker/CloseBlocker.java 7187741 linux-all,macosx-all >>> 782: java/awt/xembed/server/TestXEmbedServerJava.java 8001150,8004031 generic-all >>> 783: java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java 8162380 generic-all >> >> what about this PL entry? should be removed!!! > > java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java 8068378 generic-all > This is the test whose instructions have been modified and it is removed. > > java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java 8162380 generic-all > This test is unrelated to this PR and it came in as part of an earlier merge conflict resolution. It's not part of latest PL so it might have been incomplete merge conflict...please merge again.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27139#discussion_r2540756114 From duke at openjdk.org Wed Nov 19 09:58:52 2025 From: duke at openjdk.org (duke) Date: Wed, 19 Nov 2025 09:58:52 GMT Subject: RFR: 8372048: Performance improvement on Linux remote desktop In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 11:27:30 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > > Observed these two demon threads are created on class initializing time due to static variable and static block call. Observed [ScreencastHelper.isAvailable()](https://github.com/openjdk/jdk/blob/28d94d6ab4994b844af98c5c227b40b5fb8a72e5/src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java#L1527) from XToolkit.java call is enough to start these demon threads on latest Linux (Gnome version 47 and above). In my observation some simple workflows not passing through the code where these **Watchers** are required, at the same time threads are running because of the above reason. So moving those into lazy loading will improve loading time and performance. > > Please review and let me know your suggestions. > > Renjith. @Renjithkannath Your change (at version c290886b922b39de630541700b2c01e828ab8eb2) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28369#issuecomment-3551826527 From rkannathpari at openjdk.org Wed Nov 19 12:16:05 2025 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Wed, 19 Nov 2025 12:16:05 GMT Subject: Integrated: 8372048: Performance improvement on Linux remote desktop In-Reply-To: References: Message-ID: <1-TWseIb2hyfIkF6fSN5XkWsXD5PMucxjo9IJ7oE818=.537168e5-90fe-4f0a-b7df-e1c68d2f88bb@github.com> On Tue, 18 Nov 2025 11:27:30 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > > Observed these two demon threads are created on class initializing time due to static variable and static block call. Observed [ScreencastHelper.isAvailable()](https://github.com/openjdk/jdk/blob/28d94d6ab4994b844af98c5c227b40b5fb8a72e5/src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java#L1527) from XToolkit.java call is enough to start these demon threads on latest Linux (Gnome version 47 and above). In my observation some simple workflows not passing through the code where these **Watchers** are required, at the same time threads are running because of the above reason. So moving those into lazy loading will improve loading time and performance. > > Please review and let me know your suggestions. > > Renjith. This pull request has now been integrated. Changeset: 0b3df489 Author: Renjith Kannath Pariyangad Committer: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/0b3df489e9d3b6d876a67793e082b930c17ade3e Stats: 32 lines in 2 files changed: 25 ins; 6 del; 1 mod 8372048: Performance improvement on Linux remote desktop Reviewed-by: azvegint, serb ------------- PR: https://git.openjdk.org/jdk/pull/28369 From duke at openjdk.org Wed Nov 19 16:28:08 2025 From: duke at openjdk.org (eduardsdv) Date: Wed, 19 Nov 2025 16:28:08 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v2] In-Reply-To: <5lmqQHUbBU1yxP1TBDriW3til76-9EORSR2mNB4DqDE=.c121bd0b-e276-4e44-b830-7b6291026255@github.com> References: <5lmqQHUbBU1yxP1TBDriW3til76-9EORSR2mNB4DqDE=.c121bd0b-e276-4e44-b830-7b6291026255@github.com> Message-ID: On Tue, 18 Nov 2025 16:36:40 GMT, Alexey Ivanov wrote: > Will Java code still handle this situation correctly if the OS decides to print in reverse order? If the number of pages is not known, I can imagine two strategies how the macOS can handle this: 1: The macOS starts with the first page, iterates over all pages, stores them all in a cache and only then sends them to the printer in reverse order. In this case, the pages are acquired from the Java program in the usual order. 2: The macOS iterates through all the pages, starting with the first and working towards the last. It then knows how many pages there are and can access them in reverse order. In my opinion, it should work either way because the Java printing API supports random access order. >On the other hand, as Phil highlighted, should we then communicate our intent of printing the range of pages to macOS and pass the start page correctly as we do now (in the unfixed code) contrasting with always passing 1 in the suggested fix? The intention to print only a range of pages is communicated to macOS via the ``CPrinterJob.javaPrinterJobToNSPrintInfo()``. The ``PrinterView.knowsPageRanges()`` is used to return the full range of available pages (or the range of pages that program can print) and therefore it must always return the range [1..``Pageable.getNumberOfPages()``]. > And, instead, to modify the code that applies the range for the second time to ensure ?we are NOT setting a range within a range?? The PR fixes precisely this problem, whereby the page range passed via ``PageRange`` was forwarded twice to macOS. One time in ``PrinterView.knowsPageRanges()`` and the second time in ``CPrinterJob.javaPrinterJobToNSPrintInfo()``, which led to the setting of "a range withing range". Now, only the ``CPrinterJob.javaPrinterJobToNSPrintInfo()`` is responsible for passing of ``PageRange`` to macOS. The ``PrinterView.knowsPageRanges()`` just returns the number of available pages. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3553611629 From aivanov at openjdk.org Wed Nov 19 17:23:43 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 19 Nov 2025 17:23:43 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v2] In-Reply-To: References: <5lmqQHUbBU1yxP1TBDriW3til76-9EORSR2mNB4DqDE=.c121bd0b-e276-4e44-b830-7b6291026255@github.com> Message-ID: On Wed, 19 Nov 2025 16:25:46 GMT, eduardsdv wrote: > > On the other hand, as Phil highlighted, should we then communicate our intent of printing the range of pages to macOS and pass the start page correctly as we do now (in the unfixed code) contrasting with always passing 1 in the suggested fix? > > The intention to print only a range of pages is communicated to macOS via the `CPrinterJob.javaPrinterJobToNSPrintInfo()`. The `PrinterView.knowsPageRanges()` is used to return the full range of available pages (or the range of pages that program can print) and therefore it must always return the range [1..`Pageable.getNumberOfPages()`]. This is what this PR suggests. I'm questioning *this approach* now that we know the range of pages was applied twice. > > And, instead, to modify the code that applies the range for the second time to ensure ?we are NOT setting a range within a range?? > > The PR fixes precisely this problem, whereby the page range passed via `PageRange` was forwarded twice to macOS. One time in `PrinterView.knowsPageRanges()` and the second time in `CPrinterJob.javaPrinterJobToNSPrintInfo()`, which led to the setting of "a range withing range". > > Now, only the `CPrinterJob.javaPrinterJobToNSPrintInfo()` is responsible for passing of `PageRange` to macOS. The `PrinterView.knowsPageRanges()` just returns the number of available pages. Can we do it the opposite way? This is what I'm asking about. Report the correct page range to macOS (as it's used to be done) but stop applying this range again on the Java side. Perhaps, we still need to verify that the page that macOS requests to print is within the range and just print it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3553846587 From serb at openjdk.org Wed Nov 19 22:14:27 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 19 Nov 2025 22:14:27 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 15:06:51 GMT, Matthias Baesken wrote: >> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. >> But for other JDK native libs, we do not have support for this feature. >> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Add lto to EXTRA_FLAGS, not to OPT @azvegint please verify this patch by the mach5. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3554830496 From azvegint at openjdk.org Thu Nov 20 01:11:11 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 20 Nov 2025 01:11:11 GMT Subject: RFR: 8371657: [macosx] Programmatically selecting/deselecting List item triggers an ItemEvent In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 22:21:44 GMT, Sergey Bylokhov wrote: > When I was working on [JDK-8369327](https://bugs.openjdk.org/browse/JDK-8369327) I got a suggestion to update the code that disables unnecessary events: > https://github.com/openjdk/jdk/pull/27682#discussion_r2487686109 > > After checking that code more closely, I found that it does not work in all cases. The checks were first added in [JDK-7125456](https://bugs.openjdk.org/browse/JDK-7125456). It looks like only the case for the select method was fixed. Other cases still cause unnecessary events, and even more events happen when trying to add multi selection mode: https://github.com/openjdk/jdk/pull/27682#issuecomment-3487434403 > > So I made a new bug for this issue and fixed it separately. > > The [spec](https://github.com/openjdk/jdk/blob/8531fa146be1da5e96c0f23091882a27c67d7893/src/java.desktop/share/classes/java/awt/List.java#L899): > > * Adds the specified item listener to receive item events from > * this list. Item events are sent in response to user input, but not > * in response to calls to {@code select} or {@code deselect}. > > > The new test checks most of the methods in the `java.awt.List` class. It passes on linux/windows, confirming that the same behavior is implemented in other toolkits (unfortunately on linux it is not stable enough so I had to problemlist it due to [JDK-8201307](https://bugs.openjdk.org/browse/JDK-8201307)). The test only checks for programmatic changes to the list. I am sure that if I change it to test mix of programmatic/user changes it will fail. I will work on that in a follow up bug. > > @aivanov-jdk @azvegint please take a look Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28245#pullrequestreview-3485277508 From psadhukhan at openjdk.org Thu Nov 20 08:20:02 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 20 Nov 2025 08:20:02 GMT Subject: RFR: 8372103: Metal JButton doesn't show focus if no text or icon Message-ID: If a JButton in Metal Look&Feel has no text or icon, it will not show an indicator when selected. Fix is made to show a focus rectangle even for empty button Before fix image After fix image ------------- Commit messages: - jcheck - 8372103: Metal JButton doesn't show focus if no text or icon Changes: https://git.openjdk.org/jdk/pull/28408/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28408&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372103 Stats: 82 lines in 2 files changed: 81 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28408.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28408/head:pull/28408 PR: https://git.openjdk.org/jdk/pull/28408 From psadhukhan at openjdk.org Thu Nov 20 08:39:16 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 20 Nov 2025 08:39:16 GMT Subject: RFR: 8298432: Investigate the benefits of usage of GetPrimitiveArrayCritical in the cmm code In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 09:29:48 GMT, Sergey Bylokhov wrote: > The LCMS JNI code currently uses GetByteArrayElements, GetShortArrayElements, GetIntArrayElements. These can be replaced by GetPrimitiveArrayCritical, which avoids unnecessary copying of array data and provides measurable performance improvements. > > This optimization was postponed earlier due to several reasons: > > - At that time, G1 did not support pinning, so critical sections could interfere with GC (see [JEP 423](https://openjdk.org/jeps/423)). Also note that this API is already used safely in many parts of java2d/awt. > - There was a plan to migrate to panama, but cold-startup issues ([JDK-8313344](https://bugs.openjdk.org/browse/JDK-8313344)) remain unresolved. > - GetPrimitiveArrayCritical forbids many JNI operations inside the critical region, including allocations and java callbacks, which could be unsafe for LCMS error handlers. However, LCMS color conversions do not trigger such callbacks (see [LittleCMS #516](https://github.com/mm2/Little-CMS/issues/516)). > > Performance data of various [combinations](https://bugs.openjdk.org/secure/attachment/114273/OnePixelConvert-1.java) for ColorSpace.toXX/fromXX in single-threaded and multi-threaded (64 threads) modes: > https://jmh.morethan.io/?gists=b1440355577dc48f2b19b976b67f1120,d31c6a585330c9167b462e377445ad2f > Example: > image Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27841#pullrequestreview-3486325398 From psadhukhan at openjdk.org Thu Nov 20 09:33:44 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 20 Nov 2025 09:33:44 GMT Subject: RFR: 8372103: Metal JButton doesn't show focus if no text or icon [v2] In-Reply-To: References: Message-ID: > If a JButton in Metal Look&Feel has no text or icon, it will not show an indicator when selected. > Fix is made to show a focus rectangle even for empty button > > Before fix > image > > After fix > image Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Initialisation fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28408/files - new: https://git.openjdk.org/jdk/pull/28408/files/b85fdf4a..45cf15ec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28408&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28408&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28408.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28408/head:pull/28408 PR: https://git.openjdk.org/jdk/pull/28408 From smandalika at openjdk.org Thu Nov 20 09:54:48 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Thu, 20 Nov 2025 09:54:48 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update [v6] In-Reply-To: References: Message-ID: > Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java > Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt. Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: Merge master ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27139/files - new: https://git.openjdk.org/jdk/pull/27139/files/3512ea2e..544a7813 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27139&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27139&range=04-05 Stats: 5 lines in 1 file changed: 1 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27139.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27139/head:pull/27139 PR: https://git.openjdk.org/jdk/pull/27139 From smandalika at openjdk.org Thu Nov 20 09:59:54 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Thu, 20 Nov 2025 09:59:54 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update [v7] In-Reply-To: References: Message-ID: > Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java > Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt. Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: Added line after subsection name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27139/files - new: https://git.openjdk.org/jdk/pull/27139/files/544a7813..befd454a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27139&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27139&range=05-06 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27139.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27139/head:pull/27139 PR: https://git.openjdk.org/jdk/pull/27139 From smandalika at openjdk.org Thu Nov 20 09:59:55 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Thu, 20 Nov 2025 09:59:55 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update [v4] In-Reply-To: References: <1JeSv0KBFciGWsc_fh1aqPVIKc2oWCvoA1rTaYGbRqA=.b7a66c0f-9f18-48da-9377-58f26096149a@github.com> Message-ID: On Wed, 19 Nov 2025 06:51:02 GMT, Prasanta Sadhukhan wrote: >> java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java 8068378 generic-all >> This is the test whose instructions have been modified and it is removed. >> >> java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java 8162380 generic-all >> This test is unrelated to this PR and it came in as part of an earlier merge conflict resolution. > > It's not part of latest PL so it might have been incomplete merge conflict...please merge again.. This is now fixed. AltGraphModifierTest.java entry is no longer present in the PL. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27139#discussion_r2545203245 From psadhukhan at openjdk.org Thu Nov 20 11:41:20 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 20 Nov 2025 11:41:20 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update [v7] In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 09:59:54 GMT, Srinivas Mandalika wrote: >> Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java >> Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Added line after subsection name test/jdk/ProblemList.txt line 182: > 180: java/awt/Mixing/AWT_Mixing/JSpinnerInGlassPaneOverlapping.java 8158801 windows-all > 181: java/awt/Mixing/AWT_Mixing/JSpinnerOverlapping.java 8158801 windows-all > 182: java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java 8158801,8357360 windows-all,linux-all this is already present in the PL..why is it being added here? same for l751 guess master is not getting merged properly... This will cause merge-conflict when you will try to integrate.. I expect only l783 to be removed in the PL and no other changes... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27139#discussion_r2545657479 From dfuchs at openjdk.org Thu Nov 20 12:26:21 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 20 Nov 2025 12:26:21 GMT Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a lock [v2] In-Reply-To: References: Message-ID: > An experimental change to SelectorManager::shutdown unveil a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool. > > The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool. > > This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test. > > To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock. Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'SelectorManagerVT-8372159' into ConnectionCloseLock-8372198 - 8372198: Avoid closing PlainHttpConnection while holding a lock ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28421/files - new: https://git.openjdk.org/jdk/pull/28421/files/177e7ee3..97ce3737 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28421&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28421&range=00-01 Stats: 19751 lines in 348 files changed: 10987 ins; 5712 del; 3052 mod Patch: https://git.openjdk.org/jdk/pull/28421.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28421/head:pull/28421 PR: https://git.openjdk.org/jdk/pull/28421 From dfuchs at openjdk.org Thu Nov 20 12:26:22 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 20 Nov 2025 12:26:22 GMT Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a lock In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 10:38:08 GMT, Daniel Fuchs wrote: > An experimental change to SelectorManager::shutdown unveil a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool. > > The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool. > > This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test. > > To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock. Something went wrong when I tried to merge the main PR branch in the dependent PR branch. I'm going to withdraw this PR and start again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28421#issuecomment-3557752299 From dfuchs at openjdk.org Thu Nov 20 12:26:23 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 20 Nov 2025 12:26:23 GMT Subject: Withdrawn: 8372198: Avoid closing PlainHttpConnection while holding a lock In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 10:38:08 GMT, Daniel Fuchs wrote: > An experimental change to SelectorManager::shutdown unveil a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool. > > The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool. > > This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test. > > To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/28421 From azvegint at openjdk.org Thu Nov 20 15:44:24 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 20 Nov 2025 15:44:24 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: Message-ID: On Wed, 19 Nov 2025 22:11:35 GMT, Sergey Bylokhov wrote: > @azvegint please verify this patch by the mach5. clientlibs is all green. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3558726324 From vdyakov at openjdk.org Thu Nov 20 16:58:53 2025 From: vdyakov at openjdk.org (Victor Dyakov) Date: Thu, 20 Nov 2025 16:58:53 GMT Subject: RFR: 8371501: Change IAE to NPE in java.awt.image.Kernel when data is null In-Reply-To: <0bU-D8sNFOFCEtIwSv6d0b75uIO9mkK24qtA_guTS1U=.8f40f71b-249d-4f84-ad73-af2b66e1f52a@github.com> References: <0bU-D8sNFOFCEtIwSv6d0b75uIO9mkK24qtA_guTS1U=.8f40f71b-249d-4f84-ad73-af2b66e1f52a@github.com> Message-ID: <5j_SDXEgO9yoQlZhoZC-5wsTPH5okfPLRyAmxIHFveY=.dfc920a1-7709-4656-8c84-a1788da99643@github.com> On Wed, 12 Nov 2025 02:54:08 GMT, Sergey Bylokhov wrote: > This is an update to the patch integrated in https://github.com/openjdk/jdk/pull/28127. It changes the exception from IllegalArgumentException back to NullPointerException, which was thrown previously. > > Rationale: > - Since an NPE was already thrown before, this does not introduce a behavior change > - Throwing NPE on null is the common pattern used across the codebase, including in the affected package > > Additional notes: > The patch uses the idiomatic way to check parameters for null via Objects.requireNonNull(). I am not sure whether this code path is performance critical. The use of >> 1 instead of / 2 suggests that performance might matter. If this code is performance sensitive, we can remove the Objects.requireNonNull() call, because even without it the resulting NPE would still clearly show which variable was null when its field was accessed. > > It is also possible to remove the use of multiplyExact(). We can simply multiply width/height as long values and compare the result with the data length. In case of overflow, the existing ?Data array too small? exception would still be thrown. CSR is not yet created that is why we haven?t looked at it yet ------------- PR Comment: https://git.openjdk.org/jdk/pull/28249#issuecomment-3559081324 From duke at openjdk.org Thu Nov 20 17:28:30 2025 From: duke at openjdk.org (eduardsdv) Date: Thu, 20 Nov 2025 17:28:30 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v2] In-Reply-To: References: <5lmqQHUbBU1yxP1TBDriW3til76-9EORSR2mNB4DqDE=.c121bd0b-e276-4e44-b830-7b6291026255@github.com> Message-ID: On Wed, 19 Nov 2025 17:20:18 GMT, Alexey Ivanov wrote: > > Now, only the `CPrinterJob.javaPrinterJobToNSPrintInfo()` is responsible for passing of `PageRange` to macOS. The `PrinterView.knowsPageRanges()` just returns the number of available pages. > > Can we do it the opposite way? This is what I'm asking about. > > Report the correct page range to macOS (as it's used to be done) but stop applying this range again on the Java side. Hm, I'm afraid I don't really understand what you're trying to achieve. The error occurred because the wrong number of pages was passed to macOS. This now fixed and done in the ``knowsPageRanges()`` method, which is the API defined by the macOS. For the case that a Swing print dialog, a custom dialog or no dialog at all is used, Java defines an API for printing particular pages: the ``PageRanges`` class. This information is passed to macOS via ``NSPrintInfo``, which is filled in ``CPrinterJob.javaPrinterJobToNSPrintInfo()`` including the intended page range. I don't see how it could be done in the opposite way. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3559220600 From erikj at openjdk.org Thu Nov 20 17:45:28 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 20 Nov 2025 17:45:28 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 15:06:51 GMT, Matthias Baesken wrote: >> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. >> But for other JDK native libs, we do not have support for this feature. >> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Add lto to EXTRA_FLAGS, not to OPT Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27976#pullrequestreview-3489112220 From aivanov at openjdk.org Thu Nov 20 19:10:10 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 20 Nov 2025 19:10:10 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v3] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 15:01:14 GMT, Christian Heilmann wrote: >> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS. >> >> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m. > > Christian Heilmann has updated the pull request incrementally with three additional commits since the last revision: > > - Update PrinterView.m > - Update PrinterView.h > - Update CPrinterJob.m Phil said and you agreed that the page range was applied twice. Do I understand it correctly? Previously, we passed the correct range of pages to macOS via `knowsPageRanges()`, for example 2?4. The proposed fix changes the code so that the range is pages isn't passed to macOS, or rather page 1 to number of pages. Then when printing Java applies the requested page range. Is it possible to pass the known page range to macOS and was done before the current PR? For example, to print pages 2?4, pass the start page 2 and the number of pages 3. (The number of pages to print is known even if a `Printable` interface doesn't return the number of pages.) Then modify the printing code in Java so that it doesn't apply the page range again, but just prints the requested pages instead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3559611904 From prr at openjdk.org Thu Nov 20 21:12:26 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 20 Nov 2025 21:12:26 GMT Subject: RFR: 8371501: Change IAE to NPE in java.awt.image.Kernel when data is null In-Reply-To: <0bU-D8sNFOFCEtIwSv6d0b75uIO9mkK24qtA_guTS1U=.8f40f71b-249d-4f84-ad73-af2b66e1f52a@github.com> References: <0bU-D8sNFOFCEtIwSv6d0b75uIO9mkK24qtA_guTS1U=.8f40f71b-249d-4f84-ad73-af2b66e1f52a@github.com> Message-ID: On Wed, 12 Nov 2025 02:54:08 GMT, Sergey Bylokhov wrote: > This is an update to the patch integrated in https://github.com/openjdk/jdk/pull/28127. It changes the exception from IllegalArgumentException back to NullPointerException, which was thrown previously. > > Rationale: > - Since an NPE was already thrown before, this does not introduce a behavior change > - Throwing NPE on null is the common pattern used across the codebase, including in the affected package > > Additional notes: > The patch uses the idiomatic way to check parameters for null via Objects.requireNonNull(). I am not sure whether this code path is performance critical. The use of >> 1 instead of / 2 suggests that performance might matter. If this code is performance sensitive, we can remove the Objects.requireNonNull() call, because even without it the resulting NPE would still clearly show which variable was null when its field was accessed. > > It is also possible to remove the use of multiplyExact(). We can simply multiply width/height as long values and compare the result with the data length. In case of overflow, the existing ?Data array too small? exception would still be thrown. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28249#pullrequestreview-3489945412 From prr at openjdk.org Thu Nov 20 22:03:28 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 20 Nov 2025 22:03:28 GMT Subject: RFR: 8369129: Raster createPackedRaster methods specification clean up [v4] In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 01:12:07 GMT, Sergey Bylokhov wrote: >> I've played around a bit. >> Commenting specifically about the one createInterleavedRaster factory method which accepts, width, height and the strides, I don't think such cases of zero pixel stride have ever been useful. >> I've written a small test (which I'll paste below) and as far as I've found so far, a zero pixel or scan line stride always results in an exception >> from somewhere. And the exceptions are the same for each case. I've tried JDK 8, JDK 24 and a build of the current proposed fix. >> >> So I think we could explicitly disallow 0 for these strides on this method although rather than a mix >> of RasterFormatException and IllegalArgumentException, they'd all become IllegalArgumentException >> >> For the other public factory method createInterleavedRaster that accepts a DataBuffer, even if the app makes it large enough, >> there's still an exception in most cases. The sole "working" case I've found is if bandoffsets are also all zero. >> >> Raster.createInterleavedRaster(new DataBufferByte(100), 1, 1, 0, 0, new int[] { 0 }); >> >> To continue to allow that we'd need to still allow zero strides on that method and use words about the bandoffsets. >> >> The words about the bandOffsets should in fact go on both methods. They apply more broadly than a zero stride. >> >> I'll proceed accordingly unless you spot an issue. Also I'll need to run all our tests which I've not done yet. >> >> I don't intend to look at the allowability of zero in other APIs as part of this change. >> >> BTW negative strides was asked for here : https://bugs.openjdk.org/browse/JDK-4296691 >> >> I don't think we'll ever do that. >> >> test program : >> import static java.awt.image.DataBuffer.TYPE_BYTE ; >> import java.awt.image.Raster; >> >> public class ZeroStride { >> public static void main(String[] args) { >> // w h ss ps bandoffsets >> test(1, 1, 0, 0, new int[] { 0, 0, 0}); >> test(1, 1, 0, 0, new int[] { 0, 1, 2}); >> test(1, 1, 0, 1, new int[] { 0, 0, 0}); >> test(1, 1, 3, 0, new int[] { 0, 0, 0}); >> test(1, 1, 3, 0, new int[] { 0, 1, 2}); >> } >> >> static void test(int w, int h, int scanlineStride, int pixelStride, int[] offsets) { >> try { >> System.err.println("w="+w+" h=" + h + " scanlineStride=" + scanlineStride + >> " pixelStride = " + pixelStride + >> ((offsets[1] == 0) ? " bands={0,0,0}" : " bands={0,1,2}")); >> ... > >>I'll proceed accordingly unless you spot an issue. Also I'll need to run all our tests which I've not done yet. > > all tests are green? Yes all tests are green. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27627#discussion_r2547806650 From prr at openjdk.org Thu Nov 20 22:08:42 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 20 Nov 2025 22:08:42 GMT Subject: RFR: 8369129: Raster createPackedRaster methods specification clean up [v4] In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 08:13:19 GMT, Jayathirth D V wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8369129 > > test/jdk/java/awt/image/Raster/CreateRasterExceptionTest.java line 56: > >> 54: /** >> 55: * If running on a JDK of the targetVersion or later, throw >> 56: * a RuntimeException becuase the exception argument > > "because" fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27627#discussion_r2547823703 From prr at openjdk.org Thu Nov 20 22:54:26 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 20 Nov 2025 22:54:26 GMT Subject: RFR: 6185110: Undefined behaviour of SampleModel for width, height < 0 [v2] In-Reply-To: References: Message-ID: <7IV5G4Nw8tfLQOUeLVs0EYWJ7CEnWGxIfJfkSWahbA8=.2d73e218-e749-4a1d-89be-59f7a8c16008@github.com> > The only significant change here is to ensure that all SampleModel types throw a specified exception if a client > calls any of the following methods with a negative width or height. > getPixels(..) > setPixels(..) > getSamples(..) > setSamples(..) > > The rest is fixing the javadoc to properly describe what happens and some minor cleanup. > I use {@inheritDoc} to avoid repeating the super-class doc. And no one now has to tediously compare them. > I could just delete the javadoc but that would cause no javadoc to be generated for an overridden method. > There were a couple of surprises with {@inheritDoc} and the one I had to deal with is that declared RuntimeExceptions > are not inherited. You need to explicitly re-add them. This because if it isn't an exception in the method signature (as in foo() throws BarException), and instead you only have "@throws BarException" it will not be inherited. > > I added a test which verifies the behaviour for illegal arguments. > > CSR is here https://bugs.openjdk.org/browse/JDK-8369623 Phil Race has updated the pull request incrementally with one additional commit since the last revision: 6185110 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27754/files - new: https://git.openjdk.org/jdk/pull/27754/files/3d7f9272..99d5d146 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27754&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27754&range=00-01 Stats: 12 lines in 5 files changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27754/head:pull/27754 PR: https://git.openjdk.org/jdk/pull/27754 From serb at openjdk.org Fri Nov 21 02:35:34 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 21 Nov 2025 02:35:34 GMT Subject: RFR: 8369129: Raster createPackedRaster methods specification clean up [v6] In-Reply-To: References: Message-ID: On Mon, 27 Oct 2025 17:23:42 GMT, Phil Race wrote: >> Updates the specification of Raster.createPackedRaster(..) methods and also the implementation of these to explicitly check the specified conditions rather than relying on them being passed up from some other API. >> >> Also one each of the createInterleavedRaster(..) and createBandedRaster(..) methods have an update >> >> createInterleavedRaster(...) to address that even if WxH does not exceed Integer.MAX_VALUE, the storage needed still might. >> >> createBandedRaster(..) to address >> - a not explicitly specified or tested case that WxH must not overflow >> - a not explicitly tested NPE case if bandMasks is null. This was relying on a de-reference and the actual check for it being null would have thrown the wrong exception type (AIOBE) - meaning not the one NPE actually specified and thrown. >> There's an unfortunate oddity with this that of bankIndices is null it specifies and throws AIOBE, but I didn't think it worth changing either of these to make them consistent. >> >> The existing CreateRasterExceptionTest.java is updated to verify all these assertions. >> In almost all cases the behaviour is unchanged, it is just now properly specified and verified up front. >> >> There are only 2 sub-tests which would fail on JDK 25 >> The test can also be run (and pass) there without this fix because it explicitly handles those 2 cases which are reasonable behavioral changes >> - One for the createInterleavedRaster() update where the unchecked case could end up causing a NegativeArraySizeException. This seems like a merited change. >> - One for an unlikely case where if an app specified 0 app to createPackedRaster, divide by zero would happen. >> >> The CSR is now ready for review https://bugs.openjdk.org/browse/JDK-8369131 > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8369129 Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27627#pullrequestreview-3490913817 From jwaters at openjdk.org Fri Nov 21 06:18:31 2025 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 21 Nov 2025 06:18:31 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: Message-ID: <9rA2TTpNljE7FkFoJm1xAWnBX67WMakn4Jnch-duNfc=.24ffb34c-628b-49df-a331-4016ab13ab65@github.com> On Fri, 7 Nov 2025 15:06:51 GMT, Matthias Baesken wrote: >> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. >> But for other JDK native libs, we do not have support for this feature. >> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Add lto to EXTRA_FLAGS, not to OPT Not really fond of the way this was done, but oh well, I can live with the changes regardless. make/autoconf/flags-cflags.m4 line 327: > 325: C_O_FLAG_NONE="-Od" > 326: C_O_FLAG_SIZE="-O1" > 327: C_O_FLAG_LTO="-GL" There is sometimes warning spam during linking if -Gy is not set alongside -GL last I remember. This probably won't break LTO builds, but it could possibly be annoying. Whether you want to add the flag is up to you, however. ------------- PR Review: https://git.openjdk.org/jdk/pull/27976#pullrequestreview-3491340499 PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2548662231 From tr at openjdk.org Fri Nov 21 09:33:14 2025 From: tr at openjdk.org (Tejesh R) Date: Fri, 21 Nov 2025 09:33:14 GMT Subject: RFR: 8371759: Add missing @Override annotations in com.sun.imageio package In-Reply-To: <9IK6e1aTK_6ckzZNDuL7EGPLEd3DZd4RFGCgkEBF-jo=.70bb31bb-a3a6-480e-a39c-edaf5ad47c2e@github.com> References: <9IK6e1aTK_6ckzZNDuL7EGPLEd3DZd4RFGCgkEBF-jo=.70bb31bb-a3a6-480e-a39c-edaf5ad47c2e@github.com> Message-ID: On Thu, 13 Nov 2025 06:40:43 GMT, Sergey Bylokhov wrote: > This patch adds missing `@Override` annotations to methods in the `com.sun.imageio` package that override methods from a superclass or interface. > Only source annotations are added; there are no behavioral changes. > > The previous patch for `com.sun.beans` can be found here: https://github.com/openjdk/jdk/pull/27887. Marked as reviewed by tr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28282#pullrequestreview-3491880742 From tr at openjdk.org Fri Nov 21 09:38:19 2025 From: tr at openjdk.org (Tejesh R) Date: Fri, 21 Nov 2025 09:38:19 GMT Subject: RFR: 8371657: [macosx] Programmatically selecting/deselecting List item triggers an ItemEvent In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 22:21:44 GMT, Sergey Bylokhov wrote: > When I was working on [JDK-8369327](https://bugs.openjdk.org/browse/JDK-8369327) I got a suggestion to update the code that disables unnecessary events: > https://github.com/openjdk/jdk/pull/27682#discussion_r2487686109 > > After checking that code more closely, I found that it does not work in all cases. The checks were first added in [JDK-7125456](https://bugs.openjdk.org/browse/JDK-7125456). It looks like only the case for the select method was fixed. Other cases still cause unnecessary events, and even more events happen when trying to add multi selection mode: https://github.com/openjdk/jdk/pull/27682#issuecomment-3487434403 > > So I made a new bug for this issue and fixed it separately. > > The [spec](https://github.com/openjdk/jdk/blob/8531fa146be1da5e96c0f23091882a27c67d7893/src/java.desktop/share/classes/java/awt/List.java#L899): > > * Adds the specified item listener to receive item events from > * this list. Item events are sent in response to user input, but not > * in response to calls to {@code select} or {@code deselect}. > > > The new test checks most of the methods in the `java.awt.List` class. It passes on linux/windows, confirming that the same behavior is implemented in other toolkits (unfortunately on linux it is not stable enough so I had to problemlist it due to [JDK-8201307](https://bugs.openjdk.org/browse/JDK-8201307)). The test only checks for programmatic changes to the list. I am sure that if I change it to test mix of programmatic/user changes it will fail. I will work on that in a follow up bug. > > @aivanov-jdk @azvegint please take a look test/jdk/java/awt/List/NoEvents/ProgrammaticChange.java line 30: > 28: import java.util.function.Supplier; > 29: > 30: /** Suggestion: /* ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28245#discussion_r2549109883 From duke at openjdk.org Fri Nov 21 10:05:50 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Fri, 21 Nov 2025 10:05:50 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v3] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 15:01:14 GMT, Christian Heilmann wrote: >> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS. >> >> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m. > > Christian Heilmann has updated the pull request incrementally with three additional commits since the last revision: > > - Update PrinterView.m > - Update PrinterView.h > - Update CPrinterJob.m Let me add links to the Apple documentation. https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Printing/osxp_pagination/osxp_pagination.html#//apple_ref/doc/uid/20001051-119382-BBCEGCBI - Custom Pagination. https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Printing/osxp_printapps/osxp_printapps.html#//apple_ref/doc/uid/20000861-SW1 - Customizing Content for the Printed Page (NSView). Java uses the NSView to print documents, NSView is a reflection of a printing document (OpenBook or another class that extends Pageable interface). The "(BOOL) knowsPageRange:(NSRangePointer) range;" method returns TRUE if we know the document size (the Pageable.getNumberOfPages() method returns the number of pages) or FALSE if we don't know the size of the document (the Pageable.getNumberOfPages() returns UNKNOWN_NUMBER_OF_PAGES). NSView's page numbers are one-based ? that is, pages run from 1 to N, so if the Pageable.getNumberOfPages() returned, for example, 10, then we should set NSRange->location = 1 and NSRange->length = 10. As described in the Apple documentation, "The printing system sends a rectForPage: message to your app before each page is printed, base on the range of pages the user selects in the Print panel". The range of pages the user selected in the Print panel is not the same range as the knowsPageRange. This is an instance of the PageRanges.class from the PrintRequestAttributeSet (a user's selection from the print dialog). I assume that "knowsPageRange" is the size of the whole document, and that printingDictionary's NSPrintFirstPage and NSPrintLastPage is the printing range of the document the user selected. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3562280885 From mbaesken at openjdk.org Fri Nov 21 12:35:59 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 21 Nov 2025 12:35:59 GMT Subject: RFR: 8370438: Offer link time optimization support on library level In-Reply-To: References: <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com> <809Ep8sEq1en07SmuThJa34v0-oYAdPr6Jhwg4DZTGM=.08fe720e-dc5e-4903-9c3c-e3f5770859e3@github.com> Message-ID: On Tue, 4 Nov 2025 13:37:11 GMT, Erik Joelsson wrote: >>>It would be a little awkward to refactor only the JVM LTO flags into configure flags while leaving the rest of the JVM feature flags set by the Makefile, just my 2 cents. >> >> The part in the Makefile would probably stay, but could reuse common flags from configure, e.g. something like this >> >> >> JVM_LDFLAGS_FEATURES += $(CXX_O_FLAG_HIGHEST_JVM) -flto=auto \ >> -fuse-linker-plugin -fno-strict-aliasing >> => >> JVM_LDFLAGS_FEATURES += $(CXX_O_FLAG_HIGHEST_JVM) $(LDFLAGS_LTO) > >> > It would be a little awkward to refactor only the JVM LTO flags into configure flags while leaving the rest of the JVM feature flags set by the Makefile, just my 2 cents. >> >> The part in the Makefile would probably stay, but could reuse common flags from configure, e.g. something like this >> >> ``` >> JVM_LDFLAGS_FEATURES += $(CXX_O_FLAG_HIGHEST_JVM) -flto=auto \ >> -fuse-linker-plugin -fno-strict-aliasing >> => >> JVM_LDFLAGS_FEATURES += $(CXX_O_FLAG_HIGHEST_JVM) $(LDFLAGS_LTO) >> ``` > > Yes, please only define the values once and use the variables in the JVM makefile. @erikj79 thanks for the review ! @mrserb are you fine with the change as it is now ? @tstuefe maybe you can test it to see if there are issues with your specific toolchain versions at IBM and/or RedHat ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3562836140 From mbaesken at openjdk.org Fri Nov 21 12:35:59 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 21 Nov 2025 12:35:59 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: <9rA2TTpNljE7FkFoJm1xAWnBX67WMakn4Jnch-duNfc=.24ffb34c-628b-49df-a331-4016ab13ab65@github.com> References: <9rA2TTpNljE7FkFoJm1xAWnBX67WMakn4Jnch-duNfc=.24ffb34c-628b-49df-a331-4016ab13ab65@github.com> Message-ID: <2Y4KNmCMKy1c6vU0HoaQqrX48YKEzmkdKM_zkERZ77g=.2ff9709b-3f4f-490e-8150-65c54c4dd225@github.com> On Fri, 21 Nov 2025 06:15:09 GMT, Julian Waters wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Add lto to EXTRA_FLAGS, not to OPT > > make/autoconf/flags-cflags.m4 line 327: > >> 325: C_O_FLAG_NONE="-Od" >> 326: C_O_FLAG_SIZE="-O1" >> 327: C_O_FLAG_LTO="-GL" > > There is sometimes warning spam during linking if -Gy is not set alongside -GL last I remember. This probably won't break LTO builds, but it could possibly be annoying. Whether you want to add the flag is up to you, however. We build with VS2022 and I cannot see issues/spam . What would it look like? Is it something we only see with older VS versions ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2549614850 From prr at openjdk.org Fri Nov 21 18:23:31 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 21 Nov 2025 18:23:31 GMT Subject: Integrated: 8369129: Raster createPackedRaster methods specification clean up In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 18:51:28 GMT, Phil Race wrote: > Updates the specification of Raster.createPackedRaster(..) methods and also the implementation of these to explicitly check the specified conditions rather than relying on them being passed up from some other API. > > Also one each of the createInterleavedRaster(..) and createBandedRaster(..) methods have an update > > createInterleavedRaster(...) to address that even if WxH does not exceed Integer.MAX_VALUE, the storage needed still might. > > createBandedRaster(..) to address > - a not explicitly specified or tested case that WxH must not overflow > - a not explicitly tested NPE case if bandMasks is null. This was relying on a de-reference and the actual check for it being null would have thrown the wrong exception type (AIOBE) - meaning not the one NPE actually specified and thrown. > There's an unfortunate oddity with this that of bankIndices is null it specifies and throws AIOBE, but I didn't think it worth changing either of these to make them consistent. > > The existing CreateRasterExceptionTest.java is updated to verify all these assertions. > In almost all cases the behaviour is unchanged, it is just now properly specified and verified up front. > > There are only 2 sub-tests which would fail on JDK 25 > The test can also be run (and pass) there without this fix because it explicitly handles those 2 cases which are reasonable behavioral changes > - One for the createInterleavedRaster() update where the unchecked case could end up causing a NegativeArraySizeException. This seems like a merited change. > - One for an unlikely case where if an app specified 0 app to createPackedRaster, divide by zero would happen. > > The CSR is now ready for review https://bugs.openjdk.org/browse/JDK-8369131 This pull request has now been integrated. Changeset: 3a45e615 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/3a45e615973727446c9081b5affbbe7ffe7c3bea Stats: 688 lines in 2 files changed: 631 ins; 18 del; 39 mod 8369129: Raster createPackedRaster methods specification clean up Reviewed-by: jdv, serb ------------- PR: https://git.openjdk.org/jdk/pull/27627 From serb at openjdk.org Sun Nov 23 22:57:35 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 23 Nov 2025 22:57:35 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: Message-ID: <_Whdp13JzAcz3uydTQ5z2M2hbkFEnDasS4H4MrEReQU=.b49bdeed-a10a-4166-a435-5daa49db5af5@github.com> On Fri, 7 Nov 2025 15:06:51 GMT, Matthias Baesken wrote: >> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. >> But for other JDK native libs, we do not have support for this feature. >> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Add lto to EXTRA_FLAGS, not to OPT Marked as reviewed by serb (Reviewer). here is my finding, no issues were found by the tests: Platform / Compiler | Before | After | Win (number) | Win (%) -- | -- | -- | -- | -- Windows, VS 2022 | 204 800 | 206 848 | ?2 048 | ?1.00% macOS, Xcode 14.3.1 | 335 664 | 219 568 | 116 096 | 34.57% macOS, Xcode 26 | 391 168 | 237 360 | 153 808 | 39.32% gcc 13.3.0 | 307 936 | 219 344 | 88 592 | 28.77% gcc 11.4.0 | 303 944 | 174 168 | 129 776 | 42.70% gcc 11.5.0 | 295 280 | 177 360 | 117 920 | 39.93% ------------- PR Review: https://git.openjdk.org/jdk/pull/27976#pullrequestreview-3498070608 PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3568427441 From serb at openjdk.org Sun Nov 23 23:55:12 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 23 Nov 2025 23:55:12 GMT Subject: RFR: 8371657: [macosx] Programmatically selecting/deselecting List item triggers an ItemEvent In-Reply-To: References: Message-ID: On Fri, 21 Nov 2025 09:33:45 GMT, Tejesh R wrote: >> When I was working on [JDK-8369327](https://bugs.openjdk.org/browse/JDK-8369327) I got a suggestion to update the code that disables unnecessary events: >> https://github.com/openjdk/jdk/pull/27682#discussion_r2487686109 >> >> After checking that code more closely, I found that it does not work in all cases. The checks were first added in [JDK-7125456](https://bugs.openjdk.org/browse/JDK-7125456). It looks like only the case for the select method was fixed. Other cases still cause unnecessary events, and even more events happen when trying to add multi selection mode: https://github.com/openjdk/jdk/pull/27682#issuecomment-3487434403 >> >> So I made a new bug for this issue and fixed it separately. >> >> The [spec](https://github.com/openjdk/jdk/blob/8531fa146be1da5e96c0f23091882a27c67d7893/src/java.desktop/share/classes/java/awt/List.java#L899): >> >> * Adds the specified item listener to receive item events from >> * this list. Item events are sent in response to user input, but not >> * in response to calls to {@code select} or {@code deselect}. >> >> >> The new test checks most of the methods in the `java.awt.List` class. It passes on linux/windows, confirming that the same behavior is implemented in other toolkits (unfortunately on linux it is not stable enough so I had to problemlist it due to [JDK-8201307](https://bugs.openjdk.org/browse/JDK-8201307)). The test only checks for programmatic changes to the list. I am sure that if I change it to test mix of programmatic/user changes it will fail. I will work on that in a follow up bug. >> >> @aivanov-jdk @azvegint please take a look > > test/jdk/java/awt/List/NoEvents/ProgrammaticChange.java line 30: > >> 28: import java.util.function.Supplier; >> 29: >> 30: /** > > Suggestion: > > /* I intentionally used that style so the tags would be highlighted and validated by the IDE. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28245#discussion_r2554420074 From serb at openjdk.org Mon Nov 24 00:16:19 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 24 Nov 2025 00:16:19 GMT Subject: RFR: 8371501: Change IAE to NPE in java.awt.image.Kernel when data is null In-Reply-To: <0bU-D8sNFOFCEtIwSv6d0b75uIO9mkK24qtA_guTS1U=.8f40f71b-249d-4f84-ad73-af2b66e1f52a@github.com> References: <0bU-D8sNFOFCEtIwSv6d0b75uIO9mkK24qtA_guTS1U=.8f40f71b-249d-4f84-ad73-af2b66e1f52a@github.com> Message-ID: On Wed, 12 Nov 2025 02:54:08 GMT, Sergey Bylokhov wrote: > This is an update to the patch integrated in https://github.com/openjdk/jdk/pull/28127. It changes the exception from IllegalArgumentException back to NullPointerException, which was thrown previously. > > Rationale: > - Since an NPE was already thrown before, this does not introduce a behavior change > - Throwing NPE on null is the common pattern used across the codebase, including in the affected package > > Additional notes: > The patch uses the idiomatic way to check parameters for null via Objects.requireNonNull(). I am not sure whether this code path is performance critical. The use of >> 1 instead of / 2 suggests that performance might matter. If this code is performance sensitive, we can remove the Objects.requireNonNull() call, because even without it the resulting NPE would still clearly show which variable was null when its field was accessed. > > It is also possible to remove the use of multiplyExact(). We can simply multiply width/height as long values and compare the result with the data length. In case of overflow, the existing ?Data array too small? exception would still be thrown. csr is created: https://bugs.openjdk.org/browse/JDK-8372379 ------------- PR Comment: https://git.openjdk.org/jdk/pull/28249#issuecomment-3568502773 From mbaesken at openjdk.org Mon Nov 24 08:30:07 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 24 Nov 2025 08:30:07 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: <_Whdp13JzAcz3uydTQ5z2M2hbkFEnDasS4H4MrEReQU=.b49bdeed-a10a-4166-a435-5daa49db5af5@github.com> References: <_Whdp13JzAcz3uydTQ5z2M2hbkFEnDasS4H4MrEReQU=.b49bdeed-a10a-4166-a435-5daa49db5af5@github.com> Message-ID: On Sun, 23 Nov 2025 22:53:45 GMT, Sergey Bylokhov wrote: > here is my finding, no issues were found by the tests: > > Platform / Compiler Before After Win (number) Win (%) > Windows, VS 2022 204 800 206 848 ?2 048 ?1.00% > macOS, Xcode 14.3.1 335 664 219 568 116 096 34.57% > macOS, Xcode 26 391 168 237 360 153 808 39.32% > gcc 13.3.0 307 936 219 344 88 592 28.77% > gcc 11.4.0 303 944 174 168 129 776 42.70% > gcc 11.5.0 295 280 177 360 117 920 39.93% Thanks for testing, the results look pretty good ! In case some older toolchain has issues with the lto , we could disable it for this toolchain for `BUILD_LIBSPLASHSCREEN` in a follow up; but so far no such toolchain has been observed. So can I go ahead with the integrate ? Or should we wait for some other OpenJDK vendor to test the PR ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3569489846 From psadhukhan at openjdk.org Mon Nov 24 09:01:23 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 24 Nov 2025 09:01:23 GMT Subject: RFR: 8307246 : Printing: banded raster path doesn't account for device offset values [v10] In-Reply-To: References: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com> <-uBivDed7DkoAeGhXvrcA6ab9g0lIbh4hJfsnjBhPRo=.e8a74f45-5b54-4bf0-9d85-f3fa6de31050@github.com> Message-ID: On Fri, 9 Feb 2024 09:47:25 GMT, vtstydev wrote: >>> > Revert the changes to the test which limit the pages printed out. >>> > The test MUST print all orientations and MUST always print both opaque and alpha >>> > 95% of the point of this test is to ensure consistency across all cases and if it doesn't test them it is mostly pointless. >>> >>> @prrace May I revert everything in the test that @prsadhuk requested here: [#17030 (comment)](https://github.com/openjdk/jdk/pull/17030#issuecomment-1920510837) or you prefer that I change only how acting test by default? >> >> I mean by default, when run by a testing framework, the test should print all those pages. >> This is a manual test. It will be run rarely so when it does get run it ought to be thorough. >> Manual doesn't mean someone typing "java AlphaPrintingOffsets", it means when jtreg is told to run the "@key manual" tests. >> Any test options would only come in to play only if a developer wants to run the test directly by hand and chooses them. >> FWIW I doubt they'll be useful but no harm leaving them but I'm also fine with complete reversion. >> >> PS those options also complicate the instructions to the user ! > > @prrace I would like to backport this path to jdk8. May I ask you to add labels into JBS ? Hi @vtstydev It seems this bugfix has caused a regression [JDK-8372335](https://bugs.openjdk.org/browse/JDK-8372335) whereby the corner of the printout is cut-off as seen below...Will you be able to take a look? image ------------- PR Comment: https://git.openjdk.org/jdk/pull/17030#issuecomment-3569610098 From duke at openjdk.org Mon Nov 24 09:42:21 2025 From: duke at openjdk.org (eduardsdv) Date: Mon, 24 Nov 2025 09:42:21 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v3] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 15:01:14 GMT, Christian Heilmann wrote: >> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS. >> >> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m. > > Christian Heilmann has updated the pull request incrementally with three additional commits since the last revision: > > - Update PrinterView.m > - Update PrinterView.h > - Update CPrinterJob.m > Let me add links to the Apple documentation. > ... > I assume that "knowsPageRange" is the size of the whole document, and that printingDictionary's NSPrintFirstPage and NSPrintLastPage is the printing range of the document the user selected. Thanks for the links, @GennadiyKrivoshein. Yes, I also understand macOS to work this way. It seems that the ``knowsPageRange()`` is required, while ``NSPrintFirstPage`` and ``NSPrintLastPage`` are optional. These are also used to pre-fill the print dialog. I would also like to respond to your comment, @aivanov-jdk. > Phil said and you agreed that the page range was applied twice. Do I understand it correctly? Yes > Previously, we passed the correct range of pages to macOS via knowsPageRanges(), for example 2?4. No, I wouldn't say this is correct; it's what caused the bug. However, macOS also handles this data by printing only the pages in the range 2st?4st. > The proposed fix changes the code so that the range is pages isn't passed to macOS, or rather page 1 to number of pages. Yes, the ``knowsPageRanges()`` is used to inform the macOS about the number of available pages by returning a range 1-N. > Then when printing Java applies the requested page range. > Is it possible to pass the known page range to macOS and was done before the current PR? For example, to print pages 2?4, pass the start page 2 and the number of pages 3. (The number of pages to print is known even if a Printable interface doesn't return the number of pages.) > Then modify the printing code in Java so that it doesn't apply the page range again, but just prints the requested pages instead. After spending some time thinking about it, I would say, it would be possible to use only the ``knowsPageRanges()`` function to print a sub-range of available pages. I also tested it. It works indeed, when **no print dialog** is used. When a program uses the native macOS print dialog, or even a custom one, it needs to pass the **total number** of pages and optionally the **suggestion/pre-fill** via the ``PageRanges`` parameter. So there are two pieces of information that we need to pass to macOS. Combining them into one range returned by the ``knowsPageRanges()`` function would be difficult, if not impossible. I'm asking why we should do that when macOS offers two APIs for it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3569782352 From erikj at openjdk.org Mon Nov 24 13:47:32 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 24 Nov 2025 13:47:32 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: <_Whdp13JzAcz3uydTQ5z2M2hbkFEnDasS4H4MrEReQU=.b49bdeed-a10a-4166-a435-5daa49db5af5@github.com> Message-ID: On Mon, 24 Nov 2025 08:26:27 GMT, Matthias Baesken wrote: > So can I go ahead with the integrate ? > Or should we wait for some other OpenJDK vendor to test the PR ? I think you are good to go. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3570857541 From azvegint at openjdk.org Mon Nov 24 14:35:51 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 24 Nov 2025 14:35:51 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 15:06:51 GMT, Matthias Baesken wrote: >> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. >> But for other JDK native libs, we do not have support for this feature. >> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Add lto to EXTRA_FLAGS, not to OPT Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27976#pullrequestreview-3500730204 From prr at openjdk.org Mon Nov 24 20:40:13 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 24 Nov 2025 20:40:13 GMT Subject: RFR: 6185110: Undefined behaviour of SampleModel for width, height < 0 [v3] In-Reply-To: References: Message-ID: > The only significant change here is to ensure that all SampleModel types throw a specified exception if a client > calls any of the following methods with a negative width or height. > getPixels(..) > setPixels(..) > getSamples(..) > setSamples(..) > > The rest is fixing the javadoc to properly describe what happens and some minor cleanup. > I use {@inheritDoc} to avoid repeating the super-class doc. And no one now has to tediously compare them. > I could just delete the javadoc but that would cause no javadoc to be generated for an overridden method. > There were a couple of surprises with {@inheritDoc} and the one I had to deal with is that declared RuntimeExceptions > are not inherited. You need to explicitly re-add them. This because if it isn't an exception in the method signature (as in foo() throws BarException), and instead you only have "@throws BarException" it will not be inherited. > > I added a test which verifies the behaviour for illegal arguments. > > CSR is here https://bugs.openjdk.org/browse/JDK-8369623 Phil Race has updated the pull request incrementally with one additional commit since the last revision: 6185110 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27754/files - new: https://git.openjdk.org/jdk/pull/27754/files/99d5d146..f483fcba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27754&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27754&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27754/head:pull/27754 PR: https://git.openjdk.org/jdk/pull/27754 From prr at openjdk.org Mon Nov 24 20:40:17 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 24 Nov 2025 20:40:17 GMT Subject: RFR: 6185110: Undefined behaviour of SampleModel for width, height < 0 [v3] In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 07:23:06 GMT, Prasanta Sadhukhan wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 6185110 > > src/java.desktop/share/classes/java/awt/image/BandedSampleModel.java line 603: > >> 601: * @param data The DataBuffer containing the image data >> 602: * @see #getDataElements(int, int, Object, DataBuffer) >> 603: * @throws NullPointerException if {@code data} is null. > > I guess we will get NPE if (@code obj] is also null...Shouldn't we specify that too? I updated this as you can see. > src/java.desktop/share/classes/java/awt/image/ComponentSampleModel.java line 901: > >> 899: * @param data the DataBuffer containing the image data >> 900: * @see #getDataElements(int, int, Object, DataBuffer) >> 901: * @throws NullPointerException if {@code data} is null. > > same here I updated this as you can see. > src/java.desktop/share/classes/java/awt/image/MultiPixelPackedSampleModel.java line 597: > >> 595: * @param data the {@code DataBuffer} containing the image data >> 596: * @see #getDataElements(int, int, Object, DataBuffer) >> 597: * @throws NullPointerException if {@code data} is null. > > here too I updated this as you can see. > src/java.desktop/share/classes/java/awt/image/MultiPixelPackedSampleModel.java line 650: > >> 648: * @param data the {@code DataBuffer} containing the image data >> 649: * @see #getPixel(int, int, int[], DataBuffer) >> 650: * @throws NullPointerException if {@code data} is null. > > here NPE can be thrown if iArray is null...maybe we should mention that in spec too.. Looks like this is the one case that missed saying that. > src/java.desktop/share/classes/java/awt/image/SinglePixelPackedSampleModel.java line 571: > >> 569: * @param data The DataBuffer containing the image data. >> 570: * @see #getDataElements(int, int, Object, DataBuffer) >> 571: * @throws NullPointerException if {@code data} is null. > > same...NPE for null obj? I updated this as you can see. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2551178466 PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2551178742 PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2551181012 PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2557652512 PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2551179238 From prr at openjdk.org Mon Nov 24 20:58:15 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 24 Nov 2025 20:58:15 GMT Subject: RFR: 6185110: Undefined behaviour of SampleModel for width, height < 0 [v4] In-Reply-To: References: Message-ID: > The only significant change here is to ensure that all SampleModel types throw a specified exception if a client > calls any of the following methods with a negative width or height. > getPixels(..) > setPixels(..) > getSamples(..) > setSamples(..) > > The rest is fixing the javadoc to properly describe what happens and some minor cleanup. > I use {@inheritDoc} to avoid repeating the super-class doc. And no one now has to tediously compare them. > I could just delete the javadoc but that would cause no javadoc to be generated for an overridden method. > There were a couple of surprises with {@inheritDoc} and the one I had to deal with is that declared RuntimeExceptions > are not inherited. You need to explicitly re-add them. This because if it isn't an exception in the method signature (as in foo() throws BarException), and instead you only have "@throws BarException" it will not be inherited. > > I added a test which verifies the behaviour for illegal arguments. > > CSR is here https://bugs.openjdk.org/browse/JDK-8369623 Phil Race has updated the pull request incrementally with one additional commit since the last revision: 6185110 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27754/files - new: https://git.openjdk.org/jdk/pull/27754/files/f483fcba..721b95b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27754&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27754&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27754/head:pull/27754 PR: https://git.openjdk.org/jdk/pull/27754 From prr at openjdk.org Mon Nov 24 22:10:55 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 24 Nov 2025 22:10:55 GMT Subject: RFR: 4617681: constructor of BufferedImage throws unexpected IllegalArgumentException In-Reply-To: References: <3_us2zAmdVS-gGC-7urjNFd3nOxDsl5n-3aAxli9kn0=.f6460486-5438-41f4-bafe-6d96254f30a8@github.com> <2ixIN5XwoxTtCHsXs5w6o2cxjjsCRoaFuVmBfbq0bkg=.81ad927c-0cc4-4810-af04-85114d960ba5@github.com> Message-ID: On Tue, 4 Nov 2025 01:27:18 GMT, Sergey Bylokhov wrote: >> I see that none of the code path under this API uses BandedSampleModel. >> >> We can continue to create DataBuffer to hold >Integer.MAX_VALUE and use it to create a Raster with BandedSampleModel and then create a BufferedImage out of it. >> >> >> import java.awt.Transparency; >> import java.awt.color.ColorSpace; >> import java.awt.image.BandedSampleModel; >> import java.awt.image.BufferedImage; >> import java.awt.image.ColorModel; >> import java.awt.image.ComponentColorModel; >> import java.awt.image.DataBuffer; >> import java.awt.image.DataBufferByte; >> import java.awt.image.Raster; >> import java.awt.image.WritableRaster; >> >> public class BandedBufferedImage { >> public static void main (String[] args) { >> int width = 1; >> int height = Integer.MAX_VALUE - 5; >> int numBands = 3; // For RGB >> int dataType = DataBuffer.TYPE_BYTE; // 8-bit per band >> >> // Create arrays for bank indices and band offsets >> int[] bankIndices = new int[numBands]; >> int[] bandOffsets = new int[numBands]; >> for (int i = 0; i < numBands; i++) { >> bankIndices[i] = i; // Each band in its own bank >> bandOffsets[i] = 0; // Offset within each bank >> } >> >> BandedSampleModel sampleModel = new BandedSampleModel( >> dataType, width, height, width, bankIndices, bandOffsets >> ); >> DataBuffer dataBuffer = new DataBufferByte(width * height, numBands); >> WritableRaster raster = Raster.createWritableRaster(sampleModel, dataBuffer, null); >> ColorSpace cs = ColorSpace.getInstance(ColorSpace.CS_sRGB); >> int[] bits = {8, 8, 8}; // 8 bits per color component (R, G, B) >> ColorModel colorModel = new ComponentColorModel(cs, bits, false, false, Transparency.OPAQUE, dataType); >> BufferedImage bufferedImage = new BufferedImage(colorModel, raster, false, null); >> } >> } >> >> >> So there are no restrictions on these values. Even if someone extends ComponentSampleModel and divides data into separate bands they can continue to do so. > >>I see that none of the code path under this API uses BandedSampleModel. > > This discussion is about the possibility of changing that in the future. The current change prevents us from implementing those for large images(even by simply reusing BandedSampleModel instead of new class), since it includes strict limits and the TCK will enforce them. So, if we decide to change it later, we?ll also need to update the specification, which means the change can?t be backported. > >>But that seems nearly impossible. There's too many things in the spec. and implementation that would need revisision. > > What things? I don?t think we have any limits, except that we still need to implement it. Right now, we don?t define that behavior clearly. So, later, the user will get the correct large image when they ask for it, instead of getting an error. But the current patch is one of the thing which will prevent that, no? The spec update in question only applies to the pre-defined types. I see no circumstance in which we'd ever modify the implementation of these. I actually tried this (meaning BandedSampleModel) months ago now, for the 3BYTE_BGR case which is the one of those with the biggest current constraint. ie. I changed the implementation of that case and found that printing, Image I/O and IIRC at least one other thing I can't remember now assumed the current implementation. They'd need to be re-worked first. I don't see this ever happening. If internal code makes assumption, external code likely does too. If we did add a new pre-defined type that can exceed these limits because it used a banded raster, then as part of adding that, updating the spec for this case would be part of that. And that could never be backported anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2557863299 From dnguyen at openjdk.org Mon Nov 24 22:42:20 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 24 Nov 2025 22:42:20 GMT Subject: RFR: 4617681: constructor of BufferedImage throws unexpected IllegalArgumentException In-Reply-To: References: Message-ID: On Sun, 5 Oct 2025 20:33:26 GMT, Phil Race wrote: > Specifying the behaviour of BufferedImage constructors for invalid dimensions is long overdue. > > The behaviour for image types and sizes <= 0 is unchanged by this PR. > Also in many cases the behaviour for sizes that are too large is also unchanged. > In some cases, the behaviour is changed from "accidental" NegativeArraySizeException to a consistent IllegalArgumentException. > > In no case is anything changed that would affect the possibility to construct a BufferedImage. > > A test is provided to ensure the behaviour. > > A CSR is provided too : https://bugs.openjdk.org/browse/JDK-8369155 The additional checks for throwing exceptions look logical and fine to me. As mentioned, there isn't any behavioral changes to the constructor, and I found no issues with this when testing. ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/27640#pullrequestreview-3502501936 From serb at openjdk.org Mon Nov 24 22:53:57 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 24 Nov 2025 22:53:57 GMT Subject: RFR: 4617681: constructor of BufferedImage throws unexpected IllegalArgumentException In-Reply-To: References: <3_us2zAmdVS-gGC-7urjNFd3nOxDsl5n-3aAxli9kn0=.f6460486-5438-41f4-bafe-6d96254f30a8@github.com> <2ixIN5XwoxTtCHsXs5w6o2cxjjsCRoaFuVmBfbq0bkg=.81ad927c-0cc4-4810-af04-85114d960ba5@github.com> Message-ID: On Mon, 24 Nov 2025 22:07:12 GMT, Phil Race wrote: > If we did add a new pre-defined type that can exceed these limits because it used a banded r I agree with this. It will be hard to reimplement, but maybe we can still hint that this behavior depends on the implementation rather than specifying it strictly in the documentation? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2557960020 From psadhukhan at openjdk.org Tue Nov 25 03:38:15 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 25 Nov 2025 03:38:15 GMT Subject: RFR: 6185110: Undefined behaviour of SampleModel for width, height < 0 [v4] In-Reply-To: References: Message-ID: On Fri, 21 Nov 2025 23:05:41 GMT, Phil Race wrote: >> src/java.desktop/share/classes/java/awt/image/BandedSampleModel.java line 603: >> >>> 601: * @param data The DataBuffer containing the image data >>> 602: * @see #getDataElements(int, int, Object, DataBuffer) >>> 603: * @throws NullPointerException if {@code data} is null. >> >> I guess we will get NPE if (@code obj] is also null...Shouldn't we specify that too? > > I updated this as you can see. Can we specify the NPEs in the same line like what it is done in l675 to be consistent and also to be concise? `@throws NullPointerException if {@code obj} or {code data} is null.` >> src/java.desktop/share/classes/java/awt/image/ComponentSampleModel.java line 901: >> >>> 899: * @param data the DataBuffer containing the image data >>> 900: * @see #getDataElements(int, int, Object, DataBuffer) >>> 901: * @throws NullPointerException if {@code data} is null. >> >> same here > > I updated this as you can see. same, can we put it in single line as done in l974? >> src/java.desktop/share/classes/java/awt/image/MultiPixelPackedSampleModel.java line 597: >> >>> 595: * @param data the {@code DataBuffer} containing the image data >>> 596: * @see #getDataElements(int, int, Object, DataBuffer) >>> 597: * @throws NullPointerException if {@code data} is null. >> >> here too > > I updated this as you can see. here too same line? >> src/java.desktop/share/classes/java/awt/image/SinglePixelPackedSampleModel.java line 571: >> >>> 569: * @param data The DataBuffer containing the image data. >>> 570: * @see #getDataElements(int, int, Object, DataBuffer) >>> 571: * @throws NullPointerException if {@code data} is null. >> >> same...NPE for null obj? > > I updated this as you can see. same can be done in single line?!! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2558420555 PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2558422207 PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2558424470 PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2558425032 From psadhukhan at openjdk.org Tue Nov 25 03:38:16 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 25 Nov 2025 03:38:16 GMT Subject: RFR: 6185110: Undefined behaviour of SampleModel for width, height < 0 [v4] In-Reply-To: References: Message-ID: On Tue, 25 Nov 2025 03:17:23 GMT, Prasanta Sadhukhan wrote: >> I updated this as you can see. > > Can we specify the NPEs in the same line like what it is done in l675 to be consistent and also to be concise? > `@throws NullPointerException if {@code obj} or {code data} is null.` Also, can we specify {@code null} to give emphasis? I see it is be being done like that in many places in swing like for ex. `javax/swing/plaf/basic/BasicLookAndFeel.java: * @throws NullPointerException if {@code table} is {@code null}` and in some updated class in this PR too in some places ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2558430538 From psadhukhan at openjdk.org Tue Nov 25 03:38:20 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 25 Nov 2025 03:38:20 GMT Subject: RFR: 6185110: Undefined behaviour of SampleModel for width, height < 0 [v4] In-Reply-To: References: Message-ID: On Mon, 24 Nov 2025 20:58:15 GMT, Phil Race wrote: >> The only significant change here is to ensure that all SampleModel types throw a specified exception if a client >> calls any of the following methods with a negative width or height. >> getPixels(..) >> setPixels(..) >> getSamples(..) >> setSamples(..) >> >> The rest is fixing the javadoc to properly describe what happens and some minor cleanup. >> I use {@inheritDoc} to avoid repeating the super-class doc. And no one now has to tediously compare them. >> I could just delete the javadoc but that would cause no javadoc to be generated for an overridden method. >> There were a couple of surprises with {@inheritDoc} and the one I had to deal with is that declared RuntimeExceptions >> are not inherited. You need to explicitly re-add them. This because if it isn't an exception in the method signature (as in foo() throws BarException), and instead you only have "@throws BarException" it will not be inherited. >> >> I added a test which verifies the behaviour for illegal arguments. >> >> CSR is here https://bugs.openjdk.org/browse/JDK-8369623 > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 6185110 src/java.desktop/share/classes/java/awt/image/MultiPixelPackedSampleModel.java line 451: > 449: * not large enough to hold the pixel data > 450: * @see #setDataElements(int, int, Object, DataBuffer) > 451: * @throws NullPointerException if {@code data} is null. what about {@code obj}, guess it will throw NPE too? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2558437724 From azvegint at openjdk.org Tue Nov 25 04:04:39 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 25 Nov 2025 04:04:39 GMT Subject: RFR: 8371501: Change IAE to NPE in java.awt.image.Kernel when data is null In-Reply-To: <0bU-D8sNFOFCEtIwSv6d0b75uIO9mkK24qtA_guTS1U=.8f40f71b-249d-4f84-ad73-af2b66e1f52a@github.com> References: <0bU-D8sNFOFCEtIwSv6d0b75uIO9mkK24qtA_guTS1U=.8f40f71b-249d-4f84-ad73-af2b66e1f52a@github.com> Message-ID: On Wed, 12 Nov 2025 02:54:08 GMT, Sergey Bylokhov wrote: > This is an update to the patch integrated in https://github.com/openjdk/jdk/pull/28127. It changes the exception from IllegalArgumentException back to NullPointerException, which was thrown previously. > > Rationale: > - Since an NPE was already thrown before, this does not introduce a behavior change > - Throwing NPE on null is the common pattern used across the codebase, including in the affected package > > Additional notes: > The patch uses the idiomatic way to check parameters for null via Objects.requireNonNull(). I am not sure whether this code path is performance critical. The use of >> 1 instead of / 2 suggests that performance might matter. If this code is performance sensitive, we can remove the Objects.requireNonNull() call, because even without it the resulting NPE would still clearly show which variable was null when its field was accessed. > > It is also possible to remove the use of multiplyExact(). We can simply multiply width/height as long values and compare the result with the data length. In case of overflow, the existing ?Data array too small? exception would still be thrown. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28249#pullrequestreview-3503177535 From azvegint at openjdk.org Tue Nov 25 04:26:38 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 25 Nov 2025 04:26:38 GMT Subject: RFR: 8372103: Metal JButton doesn't show focus if no text or icon [v2] In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 09:33:44 GMT, Prasanta Sadhukhan wrote: >> If a JButton in Metal Look&Feel has no text or icon, it will not show an indicator when selected. >> Fix is made to show a focus rectangle even for empty button >> >> Before fix >> image >> >> After fix >> image > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Initialisation fix Marked as reviewed by azvegint (Reviewer). test/jdk/javax/swing/plaf/metal/MetalFocusBug.java line 55: > 53: public static void main(String[] args) throws Exception { > 54: // Set Metal L&F > 55: UIManager.setLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel"); EDT? ------------- PR Review: https://git.openjdk.org/jdk/pull/28408#pullrequestreview-3503195205 PR Review Comment: https://git.openjdk.org/jdk/pull/28408#discussion_r2558489612 From jdv at openjdk.org Tue Nov 25 05:08:23 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 25 Nov 2025 05:08:23 GMT Subject: RFR: 8371759: Add missing @Override annotations in com.sun.imageio package In-Reply-To: <9IK6e1aTK_6ckzZNDuL7EGPLEd3DZd4RFGCgkEBF-jo=.70bb31bb-a3a6-480e-a39c-edaf5ad47c2e@github.com> References: <9IK6e1aTK_6ckzZNDuL7EGPLEd3DZd4RFGCgkEBF-jo=.70bb31bb-a3a6-480e-a39c-edaf5ad47c2e@github.com> Message-ID: On Thu, 13 Nov 2025 06:40:43 GMT, Sergey Bylokhov wrote: > This patch adds missing `@Override` annotations to methods in the `com.sun.imageio` package that override methods from a superclass or interface. > Only source annotations are added; there are no behavioral changes. > > The previous patch for `com.sun.beans` can be found here: https://github.com/openjdk/jdk/pull/27887. Marked as reviewed by jdv (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28282#pullrequestreview-3503281570 From psadhukhan at openjdk.org Tue Nov 25 05:27:37 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 25 Nov 2025 05:27:37 GMT Subject: RFR: 8372103: Metal JButton doesn't show focus if no text or icon [v2] In-Reply-To: References: Message-ID: <9zYUTDz67kqT7VcmhiIMwQoXHb67BEBHJZeJhVa6jp0=.56476b79-6be8-4417-b431-3bf19ced931c@github.com> On Tue, 25 Nov 2025 04:14:43 GMT, Alexander Zvegintsev wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Initialisation fix > > test/jdk/javax/swing/plaf/metal/MetalFocusBug.java line 55: > >> 53: public static void main(String[] args) throws Exception { >> 54: // Set Metal L&F >> 55: UIManager.setLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel"); > > EDT? I could but it seems it is not done in other tests too for ex. plaf/metal/MetalSliderUI/4186347/bug4186347.java plaf/basic/BasicToolBarUI/bug4305622.java etc so not needed strictly.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28408#discussion_r2558586240 From mbaesken at openjdk.org Tue Nov 25 08:29:30 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 25 Nov 2025 08:29:30 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 15:06:51 GMT, Matthias Baesken wrote: >> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. >> But for other JDK native libs, we do not have support for this feature. >> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Add lto to EXTRA_FLAGS, not to OPT Thanks the the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3574310327 From mbaesken at openjdk.org Tue Nov 25 08:29:32 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 25 Nov 2025 08:29:32 GMT Subject: Integrated: 8370438: Offer link time optimization support on library level In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 12:58:15 GMT, Matthias Baesken wrote: > We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. > But for other JDK native libs, we do not have support for this feature. > LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. This pull request has now been integrated. Changeset: 5ef2c9aa Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/5ef2c9aa09247f9853bf04db0df962fcff764499 Stats: 48 lines in 8 files changed: 34 ins; 11 del; 3 mod 8370438: Offer link time optimization support on library level Reviewed-by: erikj, serb, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/27976 From aivanov at openjdk.org Tue Nov 25 09:31:56 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 25 Nov 2025 09:31:56 GMT Subject: RFR: 8371501: Change IAE to NPE in java.awt.image.Kernel when data is null In-Reply-To: <0bU-D8sNFOFCEtIwSv6d0b75uIO9mkK24qtA_guTS1U=.8f40f71b-249d-4f84-ad73-af2b66e1f52a@github.com> References: <0bU-D8sNFOFCEtIwSv6d0b75uIO9mkK24qtA_guTS1U=.8f40f71b-249d-4f84-ad73-af2b66e1f52a@github.com> Message-ID: On Wed, 12 Nov 2025 02:54:08 GMT, Sergey Bylokhov wrote: > This is an update to the patch integrated in https://github.com/openjdk/jdk/pull/28127. It changes the exception from IllegalArgumentException back to NullPointerException, which was thrown previously. > > Rationale: > - Since an NPE was already thrown before, this does not introduce a behavior change > - Throwing NPE on null is the common pattern used across the codebase, including in the affected package > > Additional notes: > The patch uses the idiomatic way to check parameters for null via Objects.requireNonNull(). I am not sure whether this code path is performance critical. The use of >> 1 instead of / 2 suggests that performance might matter. If this code is performance sensitive, we can remove the Objects.requireNonNull() call, because even without it the resulting NPE would still clearly show which variable was null when its field was accessed. > > It is also possible to remove the use of multiplyExact(). We can simply multiply width/height as long values and compare the result with the data length. In case of overflow, the existing ?Data array too small? exception would still be thrown. Looks good except for a minor comment in the test. test/jdk/java/awt/image/ConvolveOp/KernelInitialisationTest.java line 49: > 47: System.err.println("Expected: " + expected); > 48: System.err.println("Actual: " + actual); > 49: throw new RuntimeException("Test failed"); Does it make sense to include the class names in the error message too? It helps analysing the failure, you know the reason without opening the log file. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28249#pullrequestreview-3504115865 PR Review Comment: https://git.openjdk.org/jdk/pull/28249#discussion_r2559237017 From tr at openjdk.org Tue Nov 25 11:42:57 2025 From: tr at openjdk.org (Tejesh R) Date: Tue, 25 Nov 2025 11:42:57 GMT Subject: RFR: 8372103: Metal JButton doesn't show focus if no text or icon [v2] In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 09:33:44 GMT, Prasanta Sadhukhan wrote: >> If a JButton in Metal Look&Feel has no text or icon, it will not show an indicator when selected. >> Fix is made to show a focus rectangle even for empty button >> >> Before fix >> image >> >> After fix >> image > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Initialisation fix LGTM ------------- Marked as reviewed by tr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28408#pullrequestreview-3504677945 From psadhukhan at openjdk.org Tue Nov 25 11:42:59 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 25 Nov 2025 11:42:59 GMT Subject: Integrated: 8372103: Metal JButton doesn't show focus if no text or icon In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 08:06:01 GMT, Prasanta Sadhukhan wrote: > If a JButton in Metal Look&Feel has no text or icon, it will not show an indicator when selected. > Fix is made to show a focus rectangle even for empty button > > Before fix > image > > After fix > image This pull request has now been integrated. Changeset: 49176e32 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/49176e322bbb9ed1ef2f534b949b937770b54162 Stats: 82 lines in 2 files changed: 81 ins; 0 del; 1 mod 8372103: Metal JButton doesn't show focus if no text or icon Reviewed-by: azvegint, tr ------------- PR: https://git.openjdk.org/jdk/pull/28408 From jwaters at openjdk.org Tue Nov 25 12:20:12 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 25 Nov 2025 12:20:12 GMT Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v3] In-Reply-To: References: Message-ID: > This is a general cleanup and improvement of LTO, as well as a quick fix to remove a workaround in the Makefiles that disabled LTO for g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble. The -Wno-attribute-warning change here can be removed once Kim's new poisoning solution is integrated. > > - -fno-omit-frame-pointer is added to gcc to stop the linker from emitting code without the frame pointer > - -flto is set to $(JOBS) instead of auto to better match what the user requested > - -Gy is passed to the Microsoft compiler. This does not fully fix LTO under Microsoft, but prevents warnings about -LTCG:INCREMENTAL at least Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - Revert recent changes to ClientLibraries.gmk - Revert recent changes to CompileJvm.gmk - Revert recent changes to Flags.gmk - Revert recent changes to NativeCompilation.gmk - Revert recent changes to spec.gmk.template - Revert recent changes to flags-ldflags.m4 - Revert recent changes to flags-cflags.m4 - Remove no longer needed warning disable in JvmFeatures.gmk - Merge branch 'master' into patch-16 - Merge branch 'openjdk:master' into patch-16 - ... and 11 more: https://git.openjdk.org/jdk/compare/34d6cc0d...9599d09e ------------- Changes: https://git.openjdk.org/jdk/pull/22464/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22464&range=02 Stats: 53 lines in 9 files changed: 11 ins; 38 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22464.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22464/head:pull/22464 PR: https://git.openjdk.org/jdk/pull/22464 From psadhukhan at openjdk.org Tue Nov 25 12:27:10 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 25 Nov 2025 12:27:10 GMT Subject: RFR: 8042054: JTree.updateUI uses out-of-date item size information [v2] In-Reply-To: <4nSpiTCuM72-GVjWm8-ukgr_wnEanjktrQcoqCvZ77A=.a19ae102-5b0f-4164-88e8-ba6c4c7295e3@github.com> References: <4nSpiTCuM72-GVjWm8-ukgr_wnEanjktrQcoqCvZ77A=.a19ae102-5b0f-4164-88e8-ba6c4c7295e3@github.com> Message-ID: On Tue, 18 Nov 2025 00:55:34 GMT, Sergey Bylokhov wrote: >>> either by calling updateComponentTreeUI or by using the same pattern deleted in this patch >> >> If calling updateComponentTreeUI is logical updation to be done after L&F change, then maybe we can consider it as a pertinent solution too and close this as not an issue.. > >>If calling updateComponentTreeUI is logical updation to be done after L&F change, then maybe we can consider it as a pertinent solution too and close this as not an issue.. > > We should check the other components. Are any of them affected? If not we can check why, and apply the same logic to jtree. Since this is similar to JTable where issue is not seen and the cellrenderer and editors are used, I guess we should follow the same approach as it is being done in JTable as below and set the renderers and editors before the UI.. https://github.com/openjdk/jdk/blob/49176e322bbb9ed1ef2f534b949b937770b54162/src/java.desktop/share/classes/javax/swing/JTable.java#L3697-L3727 Other which does not use this renderers and editors we can skip setting UI after for the timebeing.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28258#discussion_r2559808008 From jdv at openjdk.org Tue Nov 25 15:55:12 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 25 Nov 2025 15:55:12 GMT Subject: RFR: 8298432: Investigate the benefits of usage of GetPrimitiveArrayCritical in the cmm code In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 09:29:48 GMT, Sergey Bylokhov wrote: > The LCMS JNI code currently uses GetByteArrayElements, GetShortArrayElements, GetIntArrayElements. These can be replaced by GetPrimitiveArrayCritical, which avoids unnecessary copying of array data and provides measurable performance improvements. > > This optimization was postponed earlier due to several reasons: > > - At that time, G1 did not support pinning, so critical sections could interfere with GC (see [JEP 423](https://openjdk.org/jeps/423)). Also note that this API is already used safely in many parts of java2d/awt. > - There was a plan to migrate to panama, but cold-startup issues ([JDK-8313344](https://bugs.openjdk.org/browse/JDK-8313344)) remain unresolved. > - GetPrimitiveArrayCritical forbids many JNI operations inside the critical region, including allocations and java callbacks, which could be unsafe for LCMS error handlers. However, LCMS color conversions do not trigger such callbacks (see [LittleCMS #516](https://github.com/mm2/Little-CMS/issues/516)). > > Performance data of various [combinations](https://bugs.openjdk.org/secure/attachment/114273/OnePixelConvert-1.java) for ColorSpace.toXX/fromXX in single-threaded and multi-threaded (64 threads) modes: > https://jmh.morethan.io/?gists=b1440355577dc48f2b19b976b67f1120,d31c6a585330c9167b462e377445ad2f > Example: > image Change looks good to me. I have given client test run, if it is green will approve it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27841#issuecomment-3576335426 From dnguyen at openjdk.org Tue Nov 25 17:43:29 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 25 Nov 2025 17:43:29 GMT Subject: RFR: 8371657: [macosx] Programmatically selecting/deselecting List item triggers an ItemEvent In-Reply-To: References: Message-ID: <-6bkIgaJXb3S_Qn9sVBf-O6LDQBq266fuYetaiYvHdw=.dedefab5-9a4b-42ad-8acb-86d4950a4c41@github.com> On Tue, 11 Nov 2025 22:21:44 GMT, Sergey Bylokhov wrote: > When I was working on [JDK-8369327](https://bugs.openjdk.org/browse/JDK-8369327) I got a suggestion to update the code that disables unnecessary events: > https://github.com/openjdk/jdk/pull/27682#discussion_r2487686109 > > After checking that code more closely, I found that it does not work in all cases. The checks were first added in [JDK-7125456](https://bugs.openjdk.org/browse/JDK-7125456). It looks like only the case for the select method was fixed. Other cases still cause unnecessary events, and even more events happen when trying to add multi selection mode: https://github.com/openjdk/jdk/pull/27682#issuecomment-3487434403 > > So I made a new bug for this issue and fixed it separately. > > The [spec](https://github.com/openjdk/jdk/blob/8531fa146be1da5e96c0f23091882a27c67d7893/src/java.desktop/share/classes/java/awt/List.java#L899): > > * Adds the specified item listener to receive item events from > * this list. Item events are sent in response to user input, but not > * in response to calls to {@code select} or {@code deselect}. > > > The new test checks most of the methods in the `java.awt.List` class. It passes on linux/windows, confirming that the same behavior is implemented in other toolkits (unfortunately on linux it is not stable enough so I had to problemlist it due to [JDK-8201307](https://bugs.openjdk.org/browse/JDK-8201307)). The test only checks for programmatic changes to the list. I am sure that if I change it to test mix of programmatic/user changes it will fail. I will work on that in a follow up bug. > > @aivanov-jdk @azvegint please take a look Marked as reviewed by dnguyen (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28245#pullrequestreview-3506183255 From aivanov at openjdk.org Tue Nov 25 17:53:53 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 25 Nov 2025 17:53:53 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v3] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 15:01:14 GMT, Christian Heilmann wrote: >> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS. >> >> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m. > > Christian Heilmann has updated the pull request incrementally with three additional commits since the last revision: > > - Update PrinterView.m > - Update PrinterView.h > - Update CPrinterJob.m Referring to [Phil's comment](https://github.com/openjdk/jdk/pull/11266#issuecomment-3247397993), > So deleting/commenting out these lines > > ``` > [printingDictionary setObject:[NSNumber numberWithInteger:fromPage] forKey:NSPrintFirstPage]; > [printingDictionary setObject:[NSNumber numberWithInteger:toPage] forKey:NSPrintLastPage]; > ``` > and ensuring we always set > ``` > [printingDictionary setObject:[NSNumber numberWithBool:YES] forKey:NSPrintAllPages]; > ``` > Also fixes this bug. > > It seems odd that we have these two ways of doing a similar thing and that they interact like this. Indeed, it fixes this bug, but it breaks [JDK-8061258](https://bugs.openjdk.org/browse/JDK-8061258) and its test `java/awt/print/PrinterJob/DlgAttrsBug.java`? or maybe not because `DlgAttrsBug.java` fails without either version of the fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3576826652 From aivanov at openjdk.org Tue Nov 25 17:56:37 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 25 Nov 2025 17:56:37 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v3] In-Reply-To: References: Message-ID: <87aXkXpP4WeCbGXsfDiu6kP1lyzwNmg3w1sUl7SU4Mo=.57951920-19ba-4955-93c6-f4d45a98e3c3@github.com> On Tue, 25 Nov 2025 17:50:48 GMT, Alexey Ivanov wrote: > Indeed, it fixes this bug, but it breaks [JDK-8061258](https://bugs.openjdk.org/browse/JDK-8061258) and its test `java/awt/print/PrinterJob/DlgAttrsBug.java`? or maybe not because `DlgAttrsBug.java` fails without either version of the fix. Since `javaPrinterJobToNSPrintInfo` is called before showing the print dialog and from the printing loop, commenting out the code that sets `from` and `to` pages will likely break selection in the print dialog. Therefore, we're left with only one option that's proposed in this PR: do not set the real page range before starting the print loop. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3576836217 From prr at openjdk.org Tue Nov 25 19:41:10 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 25 Nov 2025 19:41:10 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v3] In-Reply-To: <87aXkXpP4WeCbGXsfDiu6kP1lyzwNmg3w1sUl7SU4Mo=.57951920-19ba-4955-93c6-f4d45a98e3c3@github.com> References: <87aXkXpP4WeCbGXsfDiu6kP1lyzwNmg3w1sUl7SU4Mo=.57951920-19ba-4955-93c6-f4d45a98e3c3@github.com> Message-ID: On Tue, 25 Nov 2025 17:53:58 GMT, Alexey Ivanov wrote: > Indeed, it fixes this bug, but it breaks [JDK-8061258](https://bugs.openjdk.org/browse/JDK-8061258) and its test java/awt/print/PrinterJob/DlgAttrsBug.java? or maybe not because DlgAttrsBug.java fails without either version of the fix. Isn't that because of https://bugs.openjdk.org/browse/JDK-8341058 ? ie a macOS bug fixed in macOS 26. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3577289079 From nicolas.baumann1 at gmail.com Mon Nov 17 07:55:02 2025 From: nicolas.baumann1 at gmail.com (Nicolas Baumann) Date: Mon, 17 Nov 2025 08:55:02 +0100 Subject: Java 25 swing bug - pending review ID 9079510 Message-ID: Hello, Here?s a link with all the details: https://stackoverflow.com/q/79820806/8315843 Thanks, Nicolas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prr at openjdk.org Tue Nov 25 20:35:34 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 25 Nov 2025 20:35:34 GMT Subject: RFR: 6185110: Undefined behaviour of SampleModel for width, height < 0 [v5] In-Reply-To: References: Message-ID: > The only significant change here is to ensure that all SampleModel types throw a specified exception if a client > calls any of the following methods with a negative width or height. > getPixels(..) > setPixels(..) > getSamples(..) > setSamples(..) > > The rest is fixing the javadoc to properly describe what happens and some minor cleanup. > I use {@inheritDoc} to avoid repeating the super-class doc. And no one now has to tediously compare them. > I could just delete the javadoc but that would cause no javadoc to be generated for an overridden method. > There were a couple of surprises with {@inheritDoc} and the one I had to deal with is that declared RuntimeExceptions > are not inherited. You need to explicitly re-add them. This because if it isn't an exception in the method signature (as in foo() throws BarException), and instead you only have "@throws BarException" it will not be inherited. > > I added a test which verifies the behaviour for illegal arguments. > > CSR is here https://bugs.openjdk.org/browse/JDK-8369623 Phil Race has updated the pull request incrementally with one additional commit since the last revision: 6185110 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27754/files - new: https://git.openjdk.org/jdk/pull/27754/files/721b95b2..06466064 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27754&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27754&range=03-04 Stats: 82 lines in 5 files changed: 0 ins; 0 del; 82 mod Patch: https://git.openjdk.org/jdk/pull/27754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27754/head:pull/27754 PR: https://git.openjdk.org/jdk/pull/27754 From prr at openjdk.org Tue Nov 25 20:35:39 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 25 Nov 2025 20:35:39 GMT Subject: RFR: 6185110: Undefined behaviour of SampleModel for width, height < 0 [v5] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 08:54:16 GMT, Andrey Turbanov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 6185110 > > src/java.desktop/share/classes/java/awt/image/BandedSampleModel.java line 450: > >> 448: >> 449: if (x < 0 || w < 0 || x >= width || w > width || x1 < 0 || x1 > width || >> 450: y < 0 || h < 0 || y >= height || h > height || y1 < 0 || y1 > height) > > Suggestion: > > y < 0 || h < 0 || y >= height || h > height || y1 < 0 || y1 > height) fixed > src/java.desktop/share/classes/java/awt/image/BandedSampleModel.java line 703: > >> 701: >> 702: if (x < 0 || w < 0 || x >= width || w > width || x1 < 0 || x1 > width || >> 703: y < 0 || h < 0 || y >= height || h > height || y1 < 0 || y1 > height) > > Suggestion: > > y < 0 || h < 0 || y >= height || h > height || y1 < 0 || y1 > height) updated > src/java.desktop/share/classes/java/awt/image/ComponentSampleModel.java line 747: > >> 745: >> 746: if (x < 0 || (w < 0) || x >= width || w > width || x1 < 0 || x1 > width || >> 747: y < 0 || (h < 0) || y >= height || y > height || y1 < 0 || y1 > height) > > Suggestion: > > y < 0 || (h < 0) || y >= height || y > height || y1 < 0 || y1 > height) updated > src/java.desktop/share/classes/java/awt/image/ComponentSampleModel.java line 1002: > >> 1000: >> 1001: if (x < 0 || w < 0 || x >= width || w > width || x1 < 0 || x1 > width || >> 1002: y < 0 || h < 0 || y >= height || h > height || y1 < 0 || y1 > height) > > Suggestion: > > y < 0 || h < 0 || y >= height || h > height || y1 < 0 || y1 > height) updated > src/java.desktop/share/classes/java/awt/image/SinglePixelPackedSampleModel.java line 460: > >> 458: >> 459: if (x < 0 || w < 0 || x >= width || w > width || x1 < 0 || x1 > width || >> 460: y < 0 || h < 0 || y >= height || h > height || y1 < 0 || y1 > height) > > Suggestion: > > y < 0 || h < 0 || y >= height || h > height || y1 < 0 || y1 > height) updated > src/java.desktop/share/classes/java/awt/image/SinglePixelPackedSampleModel.java line 640: > >> 638: >> 639: if (x < 0 || w < 0 || x >= width || w > width || x1 < 0 || x1 > width || >> 640: y < 0 || h < 0 || y >= height || h > height || y1 < 0 || y1 > height) > > Suggestion: > > y < 0 || h < 0 || y >= height || h > height || y1 < 0 || y1 > height) updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2561283658 PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2561301121 PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2561301852 PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2561302540 PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2561303287 PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2561303621 From prr at openjdk.org Tue Nov 25 20:35:40 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 25 Nov 2025 20:35:40 GMT Subject: RFR: 6185110: Undefined behaviour of SampleModel for width, height < 0 [v5] In-Reply-To: References: Message-ID: On Tue, 25 Nov 2025 03:25:53 GMT, Prasanta Sadhukhan wrote: >> Can we specify the NPEs in the same line like what it is done in l675 to be consistent and also to be concise? >> `@throws NullPointerException if {@code obj} or {code data} is null.` > > Also, can we specify {@code null} to give emphasis? I see it is be being done like that in many places in swing like for ex. > `javax/swing/plaf/basic/BasicLookAndFeel.java: * @throws NullPointerException if {@code table} is {@code null}` > and in some updated class in this PR too in some places I've changed "is null" to "is {@code null}" everywhere I could see in the javadoc in the files in this PR. I have not updated the CSR, and don't plan to, since this is not a spec issue . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2561300605 From prr at openjdk.org Tue Nov 25 20:35:42 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 25 Nov 2025 20:35:42 GMT Subject: RFR: 6185110: Undefined behaviour of SampleModel for width, height < 0 [v4] In-Reply-To: References: Message-ID: On Tue, 25 Nov 2025 03:31:30 GMT, Prasanta Sadhukhan wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 6185110 > > src/java.desktop/share/classes/java/awt/image/MultiPixelPackedSampleModel.java line 451: > >> 449: * not large enough to hold the pixel data >> 450: * @see #setDataElements(int, int, Object, DataBuffer) >> 451: * @throws NullPointerException if {@code data} is null. > > what about {@code obj}, guess it will throw NPE too? No, in fact it won't. See the code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2561317957 From aivanov at openjdk.org Tue Nov 25 21:29:02 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 25 Nov 2025 21:29:02 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v3] In-Reply-To: References: <87aXkXpP4WeCbGXsfDiu6kP1lyzwNmg3w1sUl7SU4Mo=.57951920-19ba-4955-93c6-f4d45a98e3c3@github.com> Message-ID: <6N4dBgysy_lPvqgMd5rdu7sylfudLxtMlTuipt6UHVM=.3f1869fa-2eb1-4031-92cf-db6b4dc2be62@github.com> On Tue, 25 Nov 2025 19:38:08 GMT, Phil Race wrote: > > Indeed, it fixes this bug, but it breaks [JDK-8061258](https://bugs.openjdk.org/browse/JDK-8061258) and its test java/awt/print/PrinterJob/DlgAttrsBug.java? or maybe not because DlgAttrsBug.java fails without either version of the fix. > > Isn't that because of https://bugs.openjdk.org/browse/JDK-8341058 ? ie a macOS bug fixed in macOS 26. Yes, I think it's the one. I have no access to a host with macOS 26. I suspect that both `DlgAttrsBug.java` and `PageRangesDlgTest.java` will fail if we comment out the calls to set `fromPage` and `toPage` in `printingDictionary` in the `javaPrinterJobToNSPrintInfo` function in `CPrinterJob.m`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3577652342 From aivanov at openjdk.org Tue Nov 25 21:42:17 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 25 Nov 2025 21:42:17 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v3] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 15:01:14 GMT, Christian Heilmann wrote: >> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS. >> >> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m. > > Christian Heilmann has updated the pull request incrementally with three additional commits since the last revision: > > - Update PrinterView.m > - Update PrinterView.h > - Update CPrinterJob.m As I mentioned previously, I wrote an automatic test which verifies printing page ranges: [`PageRangesAuto.java`](https://github.com/aivanov-jdk/jdk/blob/b6f8db73461f9de15de6b9b6aeb33f523585f808/test/jdk/java/awt/print/PrinterJob/PageRangesAuto.java). The `PageRangesAuto.java` test fails without the proposed fix and passes with it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3577688690 From prr at openjdk.org Tue Nov 25 21:42:19 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 25 Nov 2025 21:42:19 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v3] In-Reply-To: <6N4dBgysy_lPvqgMd5rdu7sylfudLxtMlTuipt6UHVM=.3f1869fa-2eb1-4031-92cf-db6b4dc2be62@github.com> References: <87aXkXpP4WeCbGXsfDiu6kP1lyzwNmg3w1sUl7SU4Mo=.57951920-19ba-4955-93c6-f4d45a98e3c3@github.com> <6N4dBgysy_lPvqgMd5rdu7sylfudLxtMlTuipt6UHVM=.3f1869fa-2eb1-4031-92cf-db6b4dc2be62@github.com> Message-ID: On Tue, 25 Nov 2025 21:26:14 GMT, Alexey Ivanov wrote: > > > Indeed, it fixes this bug, but it breaks [JDK-8061258](https://bugs.openjdk.org/browse/JDK-8061258) and its test java/awt/print/PrinterJob/DlgAttrsBug.java? or maybe not because DlgAttrsBug.java fails without either version of the fix. > > > > > > Isn't that because of https://bugs.openjdk.org/browse/JDK-8341058 ? ie a macOS bug fixed in macOS 26. > > Yes, I think it's the one. I have no access to a host with macOS 26. > > I suspect that both `DlgAttrsBug.java` and `PageRangesDlgTest.java` will fail if we comment out the calls to set `fromPage` and `toPage` in `printingDictionary` in the `javaPrinterJobToNSPrintInfo` function in `CPrinterJob.m`. Meaning, even if running on macOS 26 they'll fail ? I suppose that's possible, or even likely, but it would be good to verify that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3577692651 From aivanov at openjdk.org Tue Nov 25 21:48:42 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 25 Nov 2025 21:48:42 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v3] In-Reply-To: References: Message-ID: <4oKealE5XNibgmk6pnNfG2n4UaMWUcO2chnWCrtYMrY=.44e515fa-682f-4b72-8b43-ba694967b047@github.com> On Tue, 18 Nov 2025 15:01:14 GMT, Christian Heilmann wrote: >> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS. >> >> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m. > > Christian Heilmann has updated the pull request incrementally with three additional commits since the last revision: > > - Update PrinterView.m > - Update PrinterView.h > - Update CPrinterJob.m While this PR was on review, the`test/jdk/java/awt/print/PrinterJob/PageRanges.java` test was updated to the `PassFailJFrame` framework. The test can now be run with jtreg and, therefore, it can be used verify the fix. Thus, *add 8297191 to the `@bug` tag in `PrinterJob/PageRanges.java`*. [I had already asked for it](https://github.com/openjdk/jdk/pull/11266#pullrequestreview-3152815416). ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/11266#pullrequestreview-3506975619 From aivanov at openjdk.org Tue Nov 25 22:01:27 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 25 Nov 2025 22:01:27 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v3] In-Reply-To: References: <87aXkXpP4WeCbGXsfDiu6kP1lyzwNmg3w1sUl7SU4Mo=.57951920-19ba-4955-93c6-f4d45a98e3c3@github.com> <6N4dBgysy_lPvqgMd5rdu7sylfudLxtMlTuipt6UHVM=.3f1869fa-2eb1-4031-92cf-db6b4dc2be62@github.com> Message-ID: On Tue, 25 Nov 2025 21:39:58 GMT, Phil Race wrote: > Meaning, even if running on macOS 26 they'll fail ? I suppose that's possible, or even likely, but it would be good to verify that. @prrace Yes.\ I agree we should confirm it's the case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3577746727 From prr at openjdk.org Tue Nov 25 22:59:06 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 25 Nov 2025 22:59:06 GMT Subject: RFR: 6185110: Undefined behaviour of SampleModel for width, height < 0 [v6] In-Reply-To: References: Message-ID: > The only significant change here is to ensure that all SampleModel types throw a specified exception if a client > calls any of the following methods with a negative width or height. > getPixels(..) > setPixels(..) > getSamples(..) > setSamples(..) > > The rest is fixing the javadoc to properly describe what happens and some minor cleanup. > I use {@inheritDoc} to avoid repeating the super-class doc. And no one now has to tediously compare them. > I could just delete the javadoc but that would cause no javadoc to be generated for an overridden method. > There were a couple of surprises with {@inheritDoc} and the one I had to deal with is that declared RuntimeExceptions > are not inherited. You need to explicitly re-add them. This because if it isn't an exception in the method signature (as in foo() throws BarException), and instead you only have "@throws BarException" it will not be inherited. > > I added a test which verifies the behaviour for illegal arguments. > > CSR is here https://bugs.openjdk.org/browse/JDK-8369623 Phil Race has updated the pull request incrementally with one additional commit since the last revision: 6185110 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27754/files - new: https://git.openjdk.org/jdk/pull/27754/files/06466064..8fa2f2dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27754&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27754&range=04-05 Stats: 12 lines in 5 files changed: 0 ins; 6 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27754/head:pull/27754 PR: https://git.openjdk.org/jdk/pull/27754 From prr at openjdk.org Tue Nov 25 22:59:07 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 25 Nov 2025 22:59:07 GMT Subject: RFR: 6185110: Undefined behaviour of SampleModel for width, height < 0 [v6] In-Reply-To: References: Message-ID: On Tue, 25 Nov 2025 20:23:54 GMT, Phil Race wrote: >> Also, can we specify {@code null} to give emphasis? I see it is be being done like that in many places in swing like for ex. >> `javax/swing/plaf/basic/BasicLookAndFeel.java: * @throws NullPointerException if {@code table} is {@code null}` >> and in some updated class in this PR too in some places > > I've changed "is null" to "is {@code null}" everywhere I could see in the javadoc in the files in this PR. > I have not updated the CSR, and don't plan to, since this is not a spec issue . > Can we specify the NPEs in the same line like what it is done in l675 to be consistent and also to be concise? `@throws NullPointerException if {@code obj} or {code data} is null.` I think I've done this now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2561812192 From psadhukhan at openjdk.org Wed Nov 26 03:14:55 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 26 Nov 2025 03:14:55 GMT Subject: RFR: 6185110: Undefined behaviour of SampleModel for width, height < 0 [v6] In-Reply-To: References: Message-ID: On Tue, 25 Nov 2025 22:59:06 GMT, Phil Race wrote: >> The only significant change here is to ensure that all SampleModel types throw a specified exception if a client >> calls any of the following methods with a negative width or height. >> getPixels(..) >> setPixels(..) >> getSamples(..) >> setSamples(..) >> >> The rest is fixing the javadoc to properly describe what happens and some minor cleanup. >> I use {@inheritDoc} to avoid repeating the super-class doc. And no one now has to tediously compare them. >> I could just delete the javadoc but that would cause no javadoc to be generated for an overridden method. >> There were a couple of surprises with {@inheritDoc} and the one I had to deal with is that declared RuntimeExceptions >> are not inherited. You need to explicitly re-add them. This because if it isn't an exception in the method signature (as in foo() throws BarException), and instead you only have "@throws BarException" it will not be inherited. >> >> I added a test which verifies the behaviour for illegal arguments. >> >> CSR is here https://bugs.openjdk.org/browse/JDK-8369623 > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 6185110 LGTM ------------- Marked as reviewed by psadhukhan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27754#pullrequestreview-3508327836 From psadhukhan at openjdk.org Wed Nov 26 03:27:50 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 26 Nov 2025 03:27:50 GMT Subject: RFR: 6185110: Undefined behaviour of SampleModel for width, height < 0 [v6] In-Reply-To: References: Message-ID: On Tue, 25 Nov 2025 22:59:06 GMT, Phil Race wrote: >> The only significant change here is to ensure that all SampleModel types throw a specified exception if a client >> calls any of the following methods with a negative width or height. >> getPixels(..) >> setPixels(..) >> getSamples(..) >> setSamples(..) >> >> The rest is fixing the javadoc to properly describe what happens and some minor cleanup. >> I use {@inheritDoc} to avoid repeating the super-class doc. And no one now has to tediously compare them. >> I could just delete the javadoc but that would cause no javadoc to be generated for an overridden method. >> There were a couple of surprises with {@inheritDoc} and the one I had to deal with is that declared RuntimeExceptions >> are not inherited. You need to explicitly re-add them. This because if it isn't an exception in the method signature (as in foo() throws BarException), and instead you only have "@throws BarException" it will not be inherited. >> >> I added a test which verifies the behaviour for illegal arguments. >> >> CSR is here https://bugs.openjdk.org/browse/JDK-8369623 > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 6185110 src/java.desktop/share/classes/java/awt/image/SampleModel.java line 534: > 532: * @throws NullPointerException if {@code obj} or {@code data} is {@code null}. > 533: * @throws ArrayIndexOutOfBoundsException if the coordinates are > 534: * not in bounds, or if obj is too small to hold the input. In some places {@code obj} is used, in some places it is not, like here and l583, Maybe we can think of being consistent.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2562806976 From jdv at openjdk.org Wed Nov 26 04:04:53 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 26 Nov 2025 04:04:53 GMT Subject: RFR: 8298432: Investigate the benefits of usage of GetPrimitiveArrayCritical in the cmm code In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 09:29:48 GMT, Sergey Bylokhov wrote: > The LCMS JNI code currently uses GetByteArrayElements, GetShortArrayElements, GetIntArrayElements. These can be replaced by GetPrimitiveArrayCritical, which avoids unnecessary copying of array data and provides measurable performance improvements. > > This optimization was postponed earlier due to several reasons: > > - At that time, G1 did not support pinning, so critical sections could interfere with GC (see [JEP 423](https://openjdk.org/jeps/423)). Also note that this API is already used safely in many parts of java2d/awt. > - There was a plan to migrate to panama, but cold-startup issues ([JDK-8313344](https://bugs.openjdk.org/browse/JDK-8313344)) remain unresolved. > - GetPrimitiveArrayCritical forbids many JNI operations inside the critical region, including allocations and java callbacks, which could be unsafe for LCMS error handlers. However, LCMS color conversions do not trigger such callbacks (see [LittleCMS #516](https://github.com/mm2/Little-CMS/issues/516)). > > Performance data of various [combinations](https://bugs.openjdk.org/secure/attachment/114273/OnePixelConvert-1.java) for ColorSpace.toXX/fromXX in single-threaded and multi-threaded (64 threads) modes: > https://jmh.morethan.io/?gists=b1440355577dc48f2b19b976b67f1120,d31c6a585330c9167b462e377445ad2f > Example: > image Marked as reviewed by jdv (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27841#pullrequestreview-3508504250 From tr at openjdk.org Wed Nov 26 04:09:46 2025 From: tr at openjdk.org (Tejesh R) Date: Wed, 26 Nov 2025 04:09:46 GMT Subject: RFR: 8371657: [macosx] Programmatically selecting/deselecting List item triggers an ItemEvent In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 22:21:44 GMT, Sergey Bylokhov wrote: > When I was working on [JDK-8369327](https://bugs.openjdk.org/browse/JDK-8369327) I got a suggestion to update the code that disables unnecessary events: > https://github.com/openjdk/jdk/pull/27682#discussion_r2487686109 > > After checking that code more closely, I found that it does not work in all cases. The checks were first added in [JDK-7125456](https://bugs.openjdk.org/browse/JDK-7125456). It looks like only the case for the select method was fixed. Other cases still cause unnecessary events, and even more events happen when trying to add multi selection mode: https://github.com/openjdk/jdk/pull/27682#issuecomment-3487434403 > > So I made a new bug for this issue and fixed it separately. > > The [spec](https://github.com/openjdk/jdk/blob/8531fa146be1da5e96c0f23091882a27c67d7893/src/java.desktop/share/classes/java/awt/List.java#L899): > > * Adds the specified item listener to receive item events from > * this list. Item events are sent in response to user input, but not > * in response to calls to {@code select} or {@code deselect}. > > > The new test checks most of the methods in the `java.awt.List` class. It passes on linux/windows, confirming that the same behavior is implemented in other toolkits (unfortunately on linux it is not stable enough so I had to problemlist it due to [JDK-8201307](https://bugs.openjdk.org/browse/JDK-8201307)). The test only checks for programmatic changes to the list. I am sure that if I change it to test mix of programmatic/user changes it will fail. I will work on that in a follow up bug. > > @aivanov-jdk @azvegint please take a look Marked as reviewed by tr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28245#pullrequestreview-3508519333 From tr at openjdk.org Wed Nov 26 04:30:48 2025 From: tr at openjdk.org (Tejesh R) Date: Wed, 26 Nov 2025 04:30:48 GMT Subject: RFR: 8371508: [macos] In Aqua LaF menu items layout is incorrect in RTL orientation [v3] In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 21:36:48 GMT, Alexander Zuev wrote: >> The problem is that we do not correct the icon and text re-alignment that happens when we call SwingUtilities.layoutCompoundLabel >> >> Here's the comparison of the alignment before and after the fix >> Before: >> before_fix >> After: >> after_fix > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Rename d to delta for better readability. LGTM ------------- Marked as reviewed by tr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28210#pullrequestreview-3508589253 From azvegint at openjdk.org Wed Nov 26 05:23:52 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 26 Nov 2025 05:23:52 GMT Subject: RFR: 8298432: Investigate the benefits of usage of GetPrimitiveArrayCritical in the cmm code In-Reply-To: References: Message-ID: <3zTLutK2_Ylit15zN-CojSnNXC46M8Jt8Yb-4Fya5yM=.dd8326bc-606a-4d46-8686-27db227c3225@github.com> On Thu, 16 Oct 2025 09:29:48 GMT, Sergey Bylokhov wrote: > The LCMS JNI code currently uses GetByteArrayElements, GetShortArrayElements, GetIntArrayElements. These can be replaced by GetPrimitiveArrayCritical, which avoids unnecessary copying of array data and provides measurable performance improvements. > > This optimization was postponed earlier due to several reasons: > > - At that time, G1 did not support pinning, so critical sections could interfere with GC (see [JEP 423](https://openjdk.org/jeps/423)). Also note that this API is already used safely in many parts of java2d/awt. > - There was a plan to migrate to panama, but cold-startup issues ([JDK-8313344](https://bugs.openjdk.org/browse/JDK-8313344)) remain unresolved. > - GetPrimitiveArrayCritical forbids many JNI operations inside the critical region, including allocations and java callbacks, which could be unsafe for LCMS error handlers. However, LCMS color conversions do not trigger such callbacks (see [LittleCMS #516](https://github.com/mm2/Little-CMS/issues/516)). > > Performance data of various [combinations](https://bugs.openjdk.org/secure/attachment/114273/OnePixelConvert-1.java) for ColorSpace.toXX/fromXX in single-threaded and multi-threaded (64 threads) modes: > https://jmh.morethan.io/?gists=b1440355577dc48f2b19b976b67f1120,d31c6a585330c9167b462e377445ad2f > Example: > image Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27841#pullrequestreview-3508810934 From jwood at openjdk.org Wed Nov 26 07:01:30 2025 From: jwood at openjdk.org (Jeremy Wood) Date: Wed, 26 Nov 2025 07:01:30 GMT Subject: RFR: 8303904: [macos]Transparent Windows Paint Wrong (Opaque, Pixelated) w/o Volatile Buffering [v4] In-Reply-To: References: Message-ID: <3nNFuj1jPkidYxhw8D8SurgtyxztY8CR-nGRs-6niUs=.a03f5bab-c2bc-4473-8b82-e936cee9e7e3@github.com> > When "swing.volatileImageBufferEnabled" is false: we were mistakenly using an opaque image at 100% resolution. > > In hindsight the original ticket probably should be split up into two distinct issues: > 1. The window is opaque, so pixels that should be transparent are black. > 2. The window is the wrong resolution. On a 200% resolution monitor it renders as if it were 100% (so it looks pixelated). > > This PR started 2 years ago. I got stuck and abandoned it, and @anass-baya picked it back up again this year: https://github.com/openjdk/jdk/pull/23430/ > > In that PR @mrserb suggested we try to fix this problem in RepaintManager (see https://github.com/openjdk/jdk/pull/23430#discussion_r2089555453 ), so that's what this PR does. > > Also this refactors some existing code (the BackingStoreMultiResolutionImage) from JViewport to wrap a BufferedImage in a smaller (transformed) MultiResolutionImage. Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 32 additional commits since the last revision: - Merge branch 'master' into JDK-8303904 - Merge branch 'master' into JDK-8303904 - 8303904: comment cleanup - 8303904: designing around imagined edge cases I don't know if these will ever come up in the real world, but since this is critical infrastructure I want to be careful. (A Swing app may become unusable if this code fails.) Concern A: In the event our AffineTransform is a rotation or a flip: Now we'll use the c.createImage(virtualWidth, virtualHeight), which means we fall back to the code we've been using for over a decade. Concern B: In the event our AffineTransform scales to zero, we'll at least make the image 1x1. - 8303904: minor cleanup - 8303904: minor cleanup - 8303904: minor cleanup This makes this method ALWAYS return a BackingStoreMultiResolutionImage, even if the scaled size is the same as the virtual size. (Just because making this method return a BufferedImage OR a BackingStoreMultiResolutionImage seems like an unnecessary level of abstraction; and that could turn into a potential point of confusion for future devs.) - 8303904: use BackingStoreMultiResolutionImage It's functionally the same thing; this is just reusing code (and it avoids the hacky fake image involving getScaledInstance). - Revert "8303904: support rotated GraphicsConfiguration" This reverts commit 55b1a708cdc8608824d04974ad96b62fd50149d3. - Revert "8303904: fixing AffineTransform fields" This reverts commit 2d32aaf0e670a9967877e5a4bf4c0ec1079bb070. - ... and 22 more: https://git.openjdk.org/jdk/compare/a80eb2b8...a3eb2d62 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13196/files - new: https://git.openjdk.org/jdk/pull/13196/files/ee0d8b1e..a3eb2d62 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13196&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13196&range=02-03 Stats: 605872 lines in 6705 files changed: 415549 ins; 120902 del; 69421 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 jwood at openjdk.org Wed Nov 26 07:05:48 2025 From: jwood at openjdk.org (Jeremy Wood) Date: Wed, 26 Nov 2025 07:05:48 GMT Subject: RFR: 8303904: [macos]Transparent Windows Paint Wrong (Opaque, Pixelated) w/o Volatile Buffering [v2] In-Reply-To: References: <0tixl2g0Tq-yGHz6_0XsPjZwYoW_YWjuoMcaFOVR_68=.0ef9b8e4-930e-4136-8426-124d1e0a5053@github.com> Message-ID: On Thu, 23 Oct 2025 15:06:18 GMT, Anass Baya wrote: >> What is the fate of auto-closed PRs? >> >> That is: as long as I don't delete this branch in my repo will this be available for future reference if anyone dusts off this ticket in the future? > > Hey @mickleness, > the fix is causing a regression. > the test javax/swing/JTable/8236907/LastVisibleRow.java is failing with the fix > I'm investigation that > BR, @anass-baya can you elaborate on what failure you're seeing? I merged master into this branch and ran these tests on my Mac without any failures: jeremy at mac jdk % /Users/jeremy/IdeaProjects/jtreg/build/images/jtreg/bin/jtreg -jdk:/Users/jeremy/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk /Users/jeremy/IdeaProjects/jdk/test/jdk/javax/swing/RepaintManager/8303904 Directory "JTwork" not found: creating Test results: passed: 2 Report written to /Users/jeremy/IdeaProjects/jdk/JTreport/html/report.html Results written to /Users/jeremy/IdeaProjects/jdk/JTwork jeremy at mac jdk % /Users/jeremy/IdeaProjects/jtreg/build/images/jtreg/bin/jtreg -jdk:/Users/jeremy/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk /Users/jeremy/IdeaProjects/jdk/test/jdk/javax/swing/JTable/8236907/ Test results: passed: 1 Report written to /Users/jeremy/IdeaProjects/jdk/JTreport/html/report.html Results written to /Users/jeremy/IdeaProjects/jdk/JTwork [JTwork.zip](https://github.com/user-attachments/files/23763851/JTwork.zip) If I can reproduce the failure(s) I can try resolving them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13196#issuecomment-3579663410 From psadhukhan at openjdk.org Wed Nov 26 07:53:07 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 26 Nov 2025 07:53:07 GMT Subject: RFR: 6681958: Maximization state of JInternalFrames is corrupted by WindowsDesktopManager Message-ID: Issue is if one internal frame is open and maximized and another internal frame is created which is initialized with `setMaximum(true)` then after opening the second internal frame the new internal frame is opened as non-maximized The fix makes sure the 2nd internal frame remains maximised if it is set with maximized attrbute, that is If the current frame is maximized, transfer that attribute to the frame being activated. which is also mentioned in this comment https://github.com/openjdk/jdk/blob/46ee8d550e42f756dd04fa67ed549c93b632df77/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsDesktopManager.java#L70-L71 This code seems to be added for [JDK-5036083](https://bugs.openjdk.org/browse/JDK-5036083) which expects When a frame is maximized and then minimized, the next frame should NOT be maximized. It still honours that fix as the test mentioned in JDK-5036083 works as expected as mentioned above along with fixing the present issue.. ------------- Commit messages: - Optimize fix - 6681958: Maximization state of JInternalFrames is corrupted by WindowsDesktopManager Changes: https://git.openjdk.org/jdk/pull/28502/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28502&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6681958 Stats: 108 lines in 2 files changed: 104 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28502.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28502/head:pull/28502 PR: https://git.openjdk.org/jdk/pull/28502 From thomas at devoogdt.com Wed Nov 26 09:39:49 2025 From: thomas at devoogdt.com (Thomas Devoogdt) Date: Wed, 26 Nov 2025 10:39:49 +0100 Subject: [OpenJDK][Headless] Allow compilation without X11 In-Reply-To: References: Message-ID: Hi all, I'm trying to compile OpenJDK in headless mode without the required X11 libraries. This becomes more common in embedded systems, where e.g. no head is used at all, or where e.g. only wayland is available. For this, I proposed a patch in buildroot, see https://patchwork.ozlabs.org/project/buildroot/patch/20251115154030.1746780-1-thomas at devoogdt.com/ . Buildroots policy is to upstream any custom patch when applicable, for which I created https://github.com/openjdk/jdk/pull/28310. The first question, is there any interest to support compilation without X11 in headless mode? If yes, who can create a formal "issue" and pick this up as my "sponsor"? If this PR gets merged, is there any interest to backport this to the relevant LTS distributions? Buildroot ships JDK with the somewhat outdated versions 17 and 21? Kind regards, Thomas Devoogdt -------------- next part -------------- An HTML attachment was scrubbed... URL: From smandalika at openjdk.org Wed Nov 26 09:57:24 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Wed, 26 Nov 2025 09:57:24 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update [v8] In-Reply-To: References: Message-ID: > Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java > Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt. Srinivas Mandalika has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: - Merge branch 'openjdk:master' into 8068378 - Added line after subsection name - Merge master - Fixed Typos - Fixed whitepsace error. - 8068378: Review feedback for instructions, missing break in switch case in Test.java - Merge master - 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update - 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update ------------- Changes: https://git.openjdk.org/jdk/pull/27139/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27139&range=07 Stats: 36 lines in 3 files changed: 1 ins; 6 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/27139.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27139/head:pull/27139 PR: https://git.openjdk.org/jdk/pull/27139 From smandalika at openjdk.org Wed Nov 26 10:11:43 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Wed, 26 Nov 2025 10:11:43 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update [v9] In-Reply-To: References: Message-ID: <2DBu36zE3beU_knxnBljTntowN7bsFyUcWat7xFAttI=.ca3be83f-c872-481d-b666-a0689183ee10@github.com> > Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java > Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt. Srinivas Mandalika has updated the pull request incrementally with 10 additional commits since the last revision: - Trigger the bot. - Merge branch '8068378' of github.com:srmandal/jdk into 8068378 - Merge branch 'master' of github.com:openjdk/jdk into 8068378 - Added line after subsection name - Merge master - Fixed Typos - Fixed whitepsace error. - 8068378: Review feedback for instructions, missing break in switch case in Test.java - Removed Merge Conflict from PL file. - 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27139/files - new: https://git.openjdk.org/jdk/pull/27139/files/f19d1428..2cdf3000 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27139&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27139&range=07-08 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27139.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27139/head:pull/27139 PR: https://git.openjdk.org/jdk/pull/27139 From smandalika at openjdk.org Wed Nov 26 10:11:46 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Wed, 26 Nov 2025 10:11:46 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update [v7] In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 11:37:30 GMT, Prasanta Sadhukhan wrote: >> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: >> >> Added line after subsection name > > test/jdk/ProblemList.txt line 182: > >> 180: java/awt/Mixing/AWT_Mixing/JSpinnerInGlassPaneOverlapping.java 8158801 windows-all >> 181: java/awt/Mixing/AWT_Mixing/JSpinnerOverlapping.java 8158801 windows-all >> 182: java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java 8158801,8357360 windows-all,linux-all > > this is already present in the PL..why is it being added here? same for l751 > guess master is not getting merged properly... > This will cause merge-conflict when you will try to integrate.. > > I expect only l783 to be removed in the PL and no other changes... I have fixed this issue and now only l783 is removed in the PL. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27139#discussion_r2564364901 From psadhukhan at openjdk.org Wed Nov 26 10:16:54 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 26 Nov 2025 10:16:54 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update [v9] In-Reply-To: <2DBu36zE3beU_knxnBljTntowN7bsFyUcWat7xFAttI=.ca3be83f-c872-481d-b666-a0689183ee10@github.com> References: <2DBu36zE3beU_knxnBljTntowN7bsFyUcWat7xFAttI=.ca3be83f-c872-481d-b666-a0689183ee10@github.com> Message-ID: On Wed, 26 Nov 2025 10:11:43 GMT, Srinivas Mandalika wrote: >> Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java >> Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt. > > Srinivas Mandalika has updated the pull request incrementally with 10 additional commits since the last revision: > > - Trigger the bot. > - Merge branch '8068378' of github.com:srmandal/jdk into 8068378 > - Merge branch 'master' of github.com:openjdk/jdk into 8068378 > - Added line after subsection name > - Merge master > - Fixed Typos > - Fixed whitepsace error. > - 8068378: Review feedback for instructions, missing break in switch case in Test.java > - Removed Merge Conflict from PL file. > - 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27139#pullrequestreview-3510200084 From jdv at openjdk.org Wed Nov 26 10:38:01 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 26 Nov 2025 10:38:01 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: On Tue, 4 Nov 2025 04:27:59 GMT, Tejesh R wrote: >> Double-checked this myself and it passes. Does `FrameLocation` need to be added to the PL then? > >> Double-checked this myself and it passes. Does `FrameLocation` need to be added to the PL then? > > No, that is also not failing. I will find out the fix that resolved this issue and then integrate the PR. @TejeshR13 Need to update the title of this PR. Have you made sure SizeMinimizedTest.java passes after multiple test runs in CI? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27678#issuecomment-3580681444 From mbaesken at openjdk.org Wed Nov 26 13:04:12 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 26 Nov 2025 13:04:12 GMT Subject: RFR: 8369911: Test sun/java2d/marlin/ClipShapeTest.java#CubicDoDash, #Cubic and #Poly fail intermittent Message-ID: We see a number of failures in the test sun/java2d/marlin/ClipShapeTest.java#CubicDoDash . Output looks like this : ----------System.out:(0/0)---------- ----------System.err:(113/6520)---------- Oct 15, 2025 12:23:16 AM sun.java2d.marlin.MarlinUtils logInfo INFO: =============================================================================== Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo INFO: Marlin software rasterizer = ENABLED Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo INFO: Version = [marlin-0.9.4.6.1-Unsafe-OpenJDK] Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo INFO: sun.java2d.renderer = sun.java2d.marlin.DMarlinRenderingEngine Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo INFO: sun.java2d.renderer.useThreadLocal = true Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo INFO: sun.java2d.renderer.useRef = soft Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo INFO: sun.java2d.renderer.edges = 4096 Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo INFO: sun.java2d.renderer.pixelWidth = 4096 Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo ... INFO: QUAD_DEC_BND = 0.12800000607967377 Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo INFO: INITIAL_EDGES_CAPACITY = 98304 Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo INFO: INITIAL_CROSSING_COUNT = 1024 Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo INFO: =============================================================================== java.lang.RuntimeException: Marlin renderer not used at runtime ! at ClipShapeTest.main(ClipShapeTest.java:250) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1474) Looks like the logger usage was wrong, @RogerRiggs pointed this out. ------------- Commit messages: - JDK-8369911 Changes: https://git.openjdk.org/jdk/pull/28507/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28507&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369911 Stats: 5 lines in 1 file changed: 2 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28507.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28507/head:pull/28507 PR: https://git.openjdk.org/jdk/pull/28507 From mdoerr at openjdk.org Wed Nov 26 13:36:49 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 26 Nov 2025 13:36:49 GMT Subject: RFR: 8369911: Test sun/java2d/marlin/ClipShapeTest.java#CubicDoDash, #Cubic and #Poly fail intermittent In-Reply-To: References: Message-ID: On Wed, 26 Nov 2025 12:57:03 GMT, Matthias Baesken wrote: > We see a number of failures in the test sun/java2d/marlin/ClipShapeTest.java#CubicDoDash . > Output looks like this : > > > ----------System.out:(0/0)---------- > ----------System.err:(113/6520)---------- > Oct 15, 2025 12:23:16 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: =============================================================================== > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: Marlin software rasterizer = ENABLED > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: Version = [marlin-0.9.4.6.1-Unsafe-OpenJDK] > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer = sun.java2d.marlin.DMarlinRenderingEngine > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.useThreadLocal = true > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.useRef = soft > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.edges = 4096 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.pixelWidth = 4096 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > ... > INFO: QUAD_DEC_BND = 0.12800000607967377 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: INITIAL_EDGES_CAPACITY = 98304 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: INITIAL_CROSSING_COUNT = 1024 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: =============================================================================== > java.lang.RuntimeException: Marlin renderer not used at runtime ! > at ClipShapeTest.main(ClipShapeTest.java:250) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1474) > > > Looks like the logger usage was wrong, @RogerRiggs pointed this out. LGTM, but should be reviewed by the client-lib 2d folks. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28507#pullrequestreview-3510998254 From mbaesken at openjdk.org Wed Nov 26 14:20:11 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 26 Nov 2025 14:20:11 GMT Subject: RFR: 8369911: Test sun/java2d/marlin/ClipShapeTest.java#CubicDoDash, #Cubic and #Poly fail intermittent In-Reply-To: References: Message-ID: <2zSCLsUHs4CqyGS9j2qsRqHy3eBmYXdEUfJapJz-TKY=.46e99bf0-4c8e-4e6d-a486-e5046cfd4632@github.com> On Wed, 26 Nov 2025 12:57:03 GMT, Matthias Baesken wrote: > We see a number of failures in the test sun/java2d/marlin/ClipShapeTest.java#CubicDoDash . > Output looks like this : > > > ----------System.out:(0/0)---------- > ----------System.err:(113/6520)---------- > Oct 15, 2025 12:23:16 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: =============================================================================== > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: Marlin software rasterizer = ENABLED > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: Version = [marlin-0.9.4.6.1-Unsafe-OpenJDK] > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer = sun.java2d.marlin.DMarlinRenderingEngine > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.useThreadLocal = true > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.useRef = soft > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.edges = 4096 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.pixelWidth = 4096 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > ... > INFO: QUAD_DEC_BND = 0.12800000607967377 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: INITIAL_EDGES_CAPACITY = 98304 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: INITIAL_CROSSING_COUNT = 1024 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: =============================================================================== > java.lang.RuntimeException: Marlin renderer not used at runtime ! > at ClipShapeTest.main(ClipShapeTest.java:250) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1474) > > > Looks like the logger usage was wrong, @RogerRiggs pointed this out. @RogerRiggs maybe you want to review it too ? And can add you as co author if you like because you gave the advice about logger usage. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28507#issuecomment-3581529086 From rriggs at openjdk.org Wed Nov 26 14:58:56 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 26 Nov 2025 14:58:56 GMT Subject: RFR: 8369911: Test sun/java2d/marlin/ClipShapeTest.java#CubicDoDash, #Cubic and #Poly fail intermittent In-Reply-To: References: Message-ID: On Wed, 26 Nov 2025 12:57:03 GMT, Matthias Baesken wrote: > We see a number of failures in the test sun/java2d/marlin/ClipShapeTest.java#CubicDoDash . > Output looks like this : > > > ----------System.out:(0/0)---------- > ----------System.err:(113/6520)---------- > Oct 15, 2025 12:23:16 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: =============================================================================== > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: Marlin software rasterizer = ENABLED > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: Version = [marlin-0.9.4.6.1-Unsafe-OpenJDK] > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer = sun.java2d.marlin.DMarlinRenderingEngine > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.useThreadLocal = true > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.useRef = soft > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.edges = 4096 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.pixelWidth = 4096 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > ... > INFO: QUAD_DEC_BND = 0.12800000607967377 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: INITIAL_EDGES_CAPACITY = 98304 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: INITIAL_CROSSING_COUNT = 1024 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: =============================================================================== > java.lang.RuntimeException: Marlin renderer not used at runtime ! > at ClipShapeTest.main(ClipShapeTest.java:250) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1474) > > > Looks like the logger usage was wrong, @RogerRiggs pointed this out. That same (local variable for getLogger) appears in the other tests in the marlin directory. Please fix the others too. ./marlin/TextClipErrorTest.java ./marlin/CrashPaintTest.java ./marlin/Bug8341381.java ./marlin/CrashNaNTest.java (I don't need credit) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28507#issuecomment-3581700821 From rriggs at openjdk.org Wed Nov 26 15:06:13 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 26 Nov 2025 15:06:13 GMT Subject: RFR: 8369911: Test sun/java2d/marlin/ClipShapeTest.java#CubicDoDash, #Cubic and #Poly fail intermittent In-Reply-To: References: Message-ID: <_zGLlcu6WWoOg617kgczrteRFJyF0yZCRKpnbXR28l0=.b5561f38-445f-4bdf-a3b3-cf1fdef6474b@github.com> On Wed, 26 Nov 2025 12:57:03 GMT, Matthias Baesken wrote: > We see a number of failures in the test sun/java2d/marlin/ClipShapeTest.java#CubicDoDash . > Output looks like this : > > > ----------System.out:(0/0)---------- > ----------System.err:(113/6520)---------- > Oct 15, 2025 12:23:16 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: =============================================================================== > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: Marlin software rasterizer = ENABLED > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: Version = [marlin-0.9.4.6.1-Unsafe-OpenJDK] > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer = sun.java2d.marlin.DMarlinRenderingEngine > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.useThreadLocal = true > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.useRef = soft > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.edges = 4096 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.pixelWidth = 4096 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > ... > INFO: QUAD_DEC_BND = 0.12800000607967377 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: INITIAL_EDGES_CAPACITY = 98304 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: INITIAL_CROSSING_COUNT = 1024 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: =============================================================================== > java.lang.RuntimeException: Marlin renderer not used at runtime ! > at ClipShapeTest.main(ClipShapeTest.java:250) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1474) > > > Looks like the logger usage was wrong, @RogerRiggs pointed this out. Just saw the issue filed for the other tests in java2d (JDK-8372592). Either way is fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28507#issuecomment-3581732689 From duke at openjdk.org Wed Nov 26 16:19:52 2025 From: duke at openjdk.org (Christian Heilmann) Date: Wed, 26 Nov 2025 16:19:52 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v4] In-Reply-To: References: Message-ID: > This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS. > > The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m. Christian Heilmann has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: - Merge branch 'openjdk:master' into pr/8297191 - Update PrinterView.m - Update PrinterView.h - Update CPrinterJob.m - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS - Merge branch 'master' of https://github.com/openjdk/jdk into pr/11266 - Merge branch 'master' into pr/11266 - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11266/files - new: https://git.openjdk.org/jdk/pull/11266/files/8d00e6c5..fc38fec2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11266&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11266&range=02-03 Stats: 632731 lines in 7051 files changed: 430870 ins; 129939 del; 71922 mod Patch: https://git.openjdk.org/jdk/pull/11266.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/11266/head:pull/11266 PR: https://git.openjdk.org/jdk/pull/11266 From duke at openjdk.org Wed Nov 26 16:25:04 2025 From: duke at openjdk.org (Christian Heilmann) Date: Wed, 26 Nov 2025 16:25:04 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v5] In-Reply-To: References: Message-ID: > This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS. > > The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m. Christian Heilmann has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'pr/8297191' of https://github.com/christianheilmann/jdk into pr/11266 - added 8297191 to @bug ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11266/files - new: https://git.openjdk.org/jdk/pull/11266/files/fc38fec2..845d55e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11266&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11266&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11266.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/11266/head:pull/11266 PR: https://git.openjdk.org/jdk/pull/11266 From aivanov at openjdk.org Wed Nov 26 16:25:10 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 26 Nov 2025 16:25:10 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v4] In-Reply-To: References: Message-ID: On Wed, 26 Nov 2025 16:19:52 GMT, Christian Heilmann wrote: >> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS. >> >> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m. > > Christian Heilmann has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: > > - Merge branch 'openjdk:master' into pr/8297191 > - Update PrinterView.m > - Update PrinterView.h > - Update CPrinterJob.m > - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS > - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS > - Merge branch 'master' of https://github.com/openjdk/jdk into pr/11266 > - Merge branch 'master' into pr/11266 > - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS > > Meaning, even if running on macOS 26 they'll fail ? I suppose that's possible, or even likely, but it would be good to verify that. > > Yes.\ > I agree we should confirm it's the case. @prrace I tested on a macOS 26, both `DlgAttrsBug.java` and `PageRangesDlgTest.java` fail if I uncomment the lines; the tests pass if I use a recent mainline build or a build from this PR. So, testing results rule out this second option for fixing this bug. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3582116510 From duke at openjdk.org Wed Nov 26 16:25:11 2025 From: duke at openjdk.org (Christian Heilmann) Date: Wed, 26 Nov 2025 16:25:11 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v4] In-Reply-To: References: Message-ID: On Wed, 26 Nov 2025 16:19:52 GMT, Christian Heilmann wrote: >> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS. >> >> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m. > > Christian Heilmann has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: > > - Merge branch 'openjdk:master' into pr/8297191 > - Update PrinterView.m > - Update PrinterView.h > - Update CPrinterJob.m > - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS > - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS > - Merge branch 'master' of https://github.com/openjdk/jdk into pr/11266 > - Merge branch 'master' into pr/11266 > - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS > While this PR was on review, the `test/jdk/java/awt/print/PrinterJob/PageRanges.java` test was updated to the `PassFailJFrame` framework. The test can now be run with jtreg and, therefore, it can be used to verify the fix. > > Thus, _add 8297191 to the `@bug` tag in `PrinterJob/PageRanges.java`_. > > (You will need to merge master into your branch.) > > [I had already asked for it](https://github.com/openjdk/jdk/pull/11266#pullrequestreview-3152815416). I merged the master into this branch and added 8297191 to @bug in PageRanges.java. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3582117036 From aivanov at openjdk.org Wed Nov 26 16:52:56 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 26 Nov 2025 16:52:56 GMT Subject: RFR: 4617681: constructor of BufferedImage throws unexpected IllegalArgumentException In-Reply-To: References: Message-ID: On Sun, 5 Oct 2025 20:33:26 GMT, Phil Race wrote: > Specifying the behaviour of BufferedImage constructors for invalid dimensions is long overdue. > > The behaviour for image types and sizes <= 0 is unchanged by this PR. > Also in many cases the behaviour for sizes that are too large is also unchanged. > In some cases, the behaviour is changed from "accidental" NegativeArraySizeException to a consistent IllegalArgumentException. > > In no case is anything changed that would affect the possibility to construct a BufferedImage. > > A test is provided to ensure the behaviour. > > A CSR is provided too : https://bugs.openjdk.org/browse/JDK-8369155 Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 292: > 290: * image types. The {@code ColorSpace} for the image is the > 291: * default sRGB space. > 292: * {@code BufferedImage} is a type that supports only one tile. Suggestion: * default sRGB space. *

* {@code BufferedImage} is a type that supports only one tile. To start a new paragraph? I think it would improve readability. src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 297: > 295: * Java primitive arrays so the number of samples that can be > 296: * stored are limited by the maximum size of a Java array. > 297: * This is at most {@code Integer.MAX_VALUE}. Shouldn't the sentence "This is at most?", be linked to the previous sentence with a comma. *This* refers to *the maximum size of a Java array*, it could be not as clear when these closely related sentences are split into two separate sentences. src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 299: > 297: * This is at most {@code Integer.MAX_VALUE}. > 298: * The number of samples per-pixel for an {@code imageType} affect > 299: * the maximum. For example if an image format uses bytes to store Suggestion: * the maximum. For example, if an image format uses bytes to store A comma after ?for example?. src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 303: > 301: * it will only be able to hold one fourth as many pixels as an image > 302: * that uses an int to store all four samples. > 303: * For example {@code TYPE_4BYTE_ABGR} may use 4 bytes to store a pixel Suggestion: * For example, {@code TYPE_4BYTE_ABGR} may use 4 bytes to store a pixel src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 307: > 305: * So the maximum number of pixels in a {@code BufferedImage} is > 306: * format dependent. > 307: * @param width width of the created image Suggestion: * format dependent. * * @param width width of the created image I'd add a blank line here to visually separate the description from the parameter list. src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 343: > 341: if (lsz > Integer.MAX_VALUE) { > 342: throw new IllegalArgumentException( > 343: "width " + width + " height " + height + " overflow int"); Suggestion: "width " + width + "* height " + height + " overflow int"); Is the asterisk to denote multiplication missing? src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 362: > 360: if ((spp != 1) && (lsz * spp > Integer.MAX_VALUE)) { > 361: throw new IllegalArgumentException( > 362: "width " + width + " height " + height + " * " + Suggestion: "width " + width + "* height " + height + " * " + Is the asterisk missing? src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 672: > 670: * {@code raster} is incompatible with {@code cm} > 671: * @throws IllegalArgumentException if > 672: * {@code raster} {@code minX} or {@code minY} is not zero Suggestion: * {@code raster}, {@code minX} or {@code minY} is not zero Is the comma missing? src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 677: > 675: * @see WritableRaster > 676: */ > 677: Remove this blank too? So that the javadoc ends just above a constructor declaration as in other cases? ------------- PR Review: https://git.openjdk.org/jdk/pull/27640#pullrequestreview-3511751915 PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2565650069 PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2565663429 PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2565667499 PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2565673736 PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2565684666 PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2565710115 PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2565716561 PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2565722017 PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2565727927 From aivanov at openjdk.org Wed Nov 26 16:55:46 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 26 Nov 2025 16:55:46 GMT Subject: RFR: 4617681: constructor of BufferedImage throws unexpected IllegalArgumentException In-Reply-To: References: Message-ID: On Sun, 5 Oct 2025 20:33:26 GMT, Phil Race wrote: > Specifying the behaviour of BufferedImage constructors for invalid dimensions is long overdue. > > The behaviour for image types and sizes <= 0 is unchanged by this PR. > Also in many cases the behaviour for sizes that are too large is also unchanged. > In some cases, the behaviour is changed from "accidental" NegativeArraySizeException to a consistent IllegalArgumentException. > > In no case is anything changed that would affect the possibility to construct a BufferedImage. > > A test is provided to ensure the behaviour. > > A CSR is provided too : https://bugs.openjdk.org/browse/JDK-8369155 > Found leading lowercase letter in issue title for 4617681: *constructor of BufferedImage throws unexpected IllegalArgumentException* I'm for updating the subject of the JBS issue that the word ?constructor? starts with a capital letter. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27640#issuecomment-3582253292 From aivanov at openjdk.org Wed Nov 26 17:12:49 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 26 Nov 2025 17:12:49 GMT Subject: RFR: 8371657: [macosx] Programmatically selecting/deselecting List item triggers an ItemEvent In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 22:21:44 GMT, Sergey Bylokhov wrote: > When I was working on [JDK-8369327](https://bugs.openjdk.org/browse/JDK-8369327) I got a suggestion to update the code that disables unnecessary events: > https://github.com/openjdk/jdk/pull/27682#discussion_r2487686109 > > After checking that code more closely, I found that it does not work in all cases. The checks were first added in [JDK-7125456](https://bugs.openjdk.org/browse/JDK-7125456). It looks like only the case for the select method was fixed. Other cases still cause unnecessary events, and even more events happen when trying to add multi selection mode: https://github.com/openjdk/jdk/pull/27682#issuecomment-3487434403 > > So I made a new bug for this issue and fixed it separately. > > The [spec](https://github.com/openjdk/jdk/blob/8531fa146be1da5e96c0f23091882a27c67d7893/src/java.desktop/share/classes/java/awt/List.java#L899): > > * Adds the specified item listener to receive item events from > * this list. Item events are sent in response to user input, but not > * in response to calls to {@code select} or {@code deselect}. > > > The new test checks most of the methods in the `java.awt.List` class. It passes on linux/windows, confirming that the same behavior is implemented in other toolkits (unfortunately on linux it is not stable enough so I had to problemlist it due to [JDK-8201307](https://bugs.openjdk.org/browse/JDK-8201307)). The test only checks for programmatic changes to the list. I am sure that if I change it to test mix of programmatic/user changes it will fail. I will work on that in a follow up bug. > > @aivanov-jdk @azvegint please take a look Looks good to me. Fix the typo in the `deselectALl` method name in the test. test/jdk/java/awt/List/NoEvents/ProgrammaticChange.java line 103: > 101: verify(); > 102: > 103: // "makeVisible" may change the current selection I wonder how `makeVisible` can change the current selection. I'd say it's a bug, if calling `makeVisible` changes the current selection. test/jdk/java/awt/List/NoEvents/ProgrammaticChange.java line 153: > 151: } > 152: > 153: private static void deselectALl(List list) { Suggestion: private static void deselectAll(List list) { Typo. ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28245#pullrequestreview-3511935907 PR Review Comment: https://git.openjdk.org/jdk/pull/28245#discussion_r2565801951 PR Review Comment: https://git.openjdk.org/jdk/pull/28245#discussion_r2565807059 From aivanov at openjdk.org Wed Nov 26 17:12:51 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 26 Nov 2025 17:12:51 GMT Subject: RFR: 8371657: [macosx] Programmatically selecting/deselecting List item triggers an ItemEvent In-Reply-To: References: Message-ID: On Sun, 23 Nov 2025 23:51:46 GMT, Sergey Bylokhov wrote: >> test/jdk/java/awt/List/NoEvents/ProgrammaticChange.java line 30: >> >>> 28: import java.util.function.Supplier; >>> 29: >>> 30: /** >> >> Suggestion: >> >> /* > > I intentionally used that style so the tags would be highlighted and validated by the IDE. I?d rather not use javadoc-style comments for jtreg tags because the jtreg tags aren?t javadoc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28245#discussion_r2565827578 From aivanov at openjdk.org Wed Nov 26 17:22:04 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 26 Nov 2025 17:22:04 GMT Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1 results in missing pages [v5] In-Reply-To: References: Message-ID: On Wed, 26 Nov 2025 16:25:04 GMT, Christian Heilmann wrote: >> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS. >> >> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m. > > Christian Heilmann has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'pr/8297191' of https://github.com/christianheilmann/jdk into pr/11266 > - added 8297191 to @bug I've run all the client automatic tests, and there are no failures. I'd like to run all manual and automatic printer tests locally (on a host that has a printer configured). I'll appreciate if you could run them too, especially the tests in `test/jdk/java/awt/print` and `test/jdk/javax/awt/print`. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/11266#pullrequestreview-3512002256 From prr at openjdk.org Wed Nov 26 18:05:54 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 26 Nov 2025 18:05:54 GMT Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v8] In-Reply-To: <5dc6nhWoY6uh21_XogROhl0OxcfSOP-0qaST7HOkQjE=.7ddc3f97-6658-4d31-b2fa-8eb5c4e6e406@github.com> References: <5dc6nhWoY6uh21_XogROhl0OxcfSOP-0qaST7HOkQjE=.7ddc3f97-6658-4d31-b2fa-8eb5c4e6e406@github.com> Message-ID: On Tue, 11 Nov 2025 11:55:59 GMT, Prasanta Sadhukhan wrote: >> It seems JList.getScrollableUnitIncrement can sometime return 0 instead of positive number which is not specified in the javadoc which can lead to confusion. Clarified javadoc as to when it can return 0. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > spec wording src/java.desktop/share/classes/javax/swing/JList.java line 2510: > 2508: * @param direction less or equal to zero to scroll up/back, > 2509: * greater than zero for down/forward > 2510: * @return the non-negative "unit" increment value Since zero isn't "the distance to scroll to the next row", we need to explain when and why it can be zero. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26500#discussion_r2566005916 From lbourges at openjdk.org Wed Nov 26 18:26:50 2025 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Wed, 26 Nov 2025 18:26:50 GMT Subject: RFR: 8369911: Test sun/java2d/marlin/ClipShapeTest.java#CubicDoDash, #Cubic and #Poly fail intermittent In-Reply-To: References: Message-ID: On Wed, 26 Nov 2025 12:57:03 GMT, Matthias Baesken wrote: > We see a number of failures in the test sun/java2d/marlin/ClipShapeTest.java#CubicDoDash . > Output looks like this : > > > ----------System.out:(0/0)---------- > ----------System.err:(113/6520)---------- > Oct 15, 2025 12:23:16 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: =============================================================================== > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: Marlin software rasterizer = ENABLED > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: Version = [marlin-0.9.4.6.1-Unsafe-OpenJDK] > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer = sun.java2d.marlin.DMarlinRenderingEngine > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.useThreadLocal = true > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.useRef = soft > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.edges = 4096 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.pixelWidth = 4096 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > ... > INFO: QUAD_DEC_BND = 0.12800000607967377 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: INITIAL_EDGES_CAPACITY = 98304 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: INITIAL_CROSSING_COUNT = 1024 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: =============================================================================== > java.lang.RuntimeException: Marlin renderer not used at runtime ! > at ClipShapeTest.main(ClipShapeTest.java:250) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1474) > > > Looks like the logger usage was wrong, @RogerRiggs pointed this out. LGTM, even if it means some gc or classloader behaviour changed ------------- PR Comment: https://git.openjdk.org/jdk/pull/28507#issuecomment-3582680558 From dnguyen at openjdk.org Wed Nov 26 18:26:53 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 26 Nov 2025 18:26:53 GMT Subject: RFR: 4617681: constructor of BufferedImage throws unexpected IllegalArgumentException In-Reply-To: References: Message-ID: On Sun, 5 Oct 2025 20:33:26 GMT, Phil Race wrote: > Specifying the behaviour of BufferedImage constructors for invalid dimensions is long overdue. > > The behaviour for image types and sizes <= 0 is unchanged by this PR. > Also in many cases the behaviour for sizes that are too large is also unchanged. > In some cases, the behaviour is changed from "accidental" NegativeArraySizeException to a consistent IllegalArgumentException. > > In no case is anything changed that would affect the possibility to construct a BufferedImage. > > A test is provided to ensure the behaviour. > > A CSR is provided too : https://bugs.openjdk.org/browse/JDK-8369155 src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 345: > 343: "width " + width + " height " + height + " overflow int"); > 344: } > 345: /* most BufferedImage formats use one data buffer element per pixel. Suggestion: /* Most BufferedImage formats use one data buffer element per pixel. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2566071669 From rriggs at openjdk.org Wed Nov 26 19:13:46 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 26 Nov 2025 19:13:46 GMT Subject: RFR: 8369911: Test sun/java2d/marlin/ClipShapeTest.java#CubicDoDash, #Cubic and #Poly fail intermittent In-Reply-To: References: Message-ID: On Wed, 26 Nov 2025 12:57:03 GMT, Matthias Baesken wrote: > We see a number of failures in the test sun/java2d/marlin/ClipShapeTest.java#CubicDoDash . > Output looks like this : > > > ----------System.out:(0/0)---------- > ----------System.err:(113/6520)---------- > Oct 15, 2025 12:23:16 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: =============================================================================== > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: Marlin software rasterizer = ENABLED > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: Version = [marlin-0.9.4.6.1-Unsafe-OpenJDK] > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer = sun.java2d.marlin.DMarlinRenderingEngine > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.useThreadLocal = true > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.useRef = soft > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.edges = 4096 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.pixelWidth = 4096 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > ... > INFO: QUAD_DEC_BND = 0.12800000607967377 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: INITIAL_EDGES_CAPACITY = 98304 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: INITIAL_CROSSING_COUNT = 1024 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: =============================================================================== > java.lang.RuntimeException: Marlin renderer not used at runtime ! > at ClipShapeTest.main(ClipShapeTest.java:250) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1474) > > > Looks like the logger usage was wrong, @RogerRiggs pointed this out. Looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28507#pullrequestreview-3512408339 From serb at openjdk.org Wed Nov 26 19:42:18 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 26 Nov 2025 19:42:18 GMT Subject: RFR: 8298432: Investigate the benefits of usage of GetPrimitiveArrayCritical in the cmm code [v2] In-Reply-To: References: Message-ID: <4p2hklFnTIMx0psepAxeYWcPWDdDJoZavT5rKf3Cg1k=.e26a5664-947f-42d0-a875-b8735082ecd8@github.com> > The LCMS JNI code currently uses GetByteArrayElements, GetShortArrayElements, GetIntArrayElements. These can be replaced by GetPrimitiveArrayCritical, which avoids unnecessary copying of array data and provides measurable performance improvements. > > This optimization was postponed earlier due to several reasons: > > - At that time, G1 did not support pinning, so critical sections could interfere with GC (see [JEP 423](https://openjdk.org/jeps/423)). Also note that this API is already used safely in many parts of java2d/awt. > - There was a plan to migrate to panama, but cold-startup issues ([JDK-8313344](https://bugs.openjdk.org/browse/JDK-8313344)) remain unresolved. > - GetPrimitiveArrayCritical forbids many JNI operations inside the critical region, including allocations and java callbacks, which could be unsafe for LCMS error handlers. However, LCMS color conversions do not trigger such callbacks (see [LittleCMS #516](https://github.com/mm2/Little-CMS/issues/516)). > > Performance data of various [combinations](https://bugs.openjdk.org/secure/attachment/114273/OnePixelConvert-1.java) for ColorSpace.toXX/fromXX in single-threaded and multi-threaded (64 threads) modes: > https://jmh.morethan.io/?gists=b1440355577dc48f2b19b976b67f1120,d31c6a585330c9167b462e377445ad2f > Example: > image Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8298432-v3 - Merge branch 'openjdk:master' into JDK-8298432-v3 - 8298432: Investigate the benefits of usage of GetPrimitiveArrayCritical in the cmm code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27841/files - new: https://git.openjdk.org/jdk/pull/27841/files/e372a430..4871f883 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27841&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27841&range=00-01 Stats: 333176 lines in 3097 files changed: 215179 ins; 72640 del; 45357 mod Patch: https://git.openjdk.org/jdk/pull/27841.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27841/head:pull/27841 PR: https://git.openjdk.org/jdk/pull/27841 From serb at openjdk.org Wed Nov 26 19:57:47 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 26 Nov 2025 19:57:47 GMT Subject: RFR: 8369911: Test sun/java2d/marlin/ClipShapeTest.java#CubicDoDash, #Cubic and #Poly fail intermittent In-Reply-To: References: Message-ID: On Wed, 26 Nov 2025 12:57:03 GMT, Matthias Baesken wrote: > We see a number of failures in the test sun/java2d/marlin/ClipShapeTest.java#CubicDoDash . > Output looks like this : > > > ----------System.out:(0/0)---------- > ----------System.err:(113/6520)---------- > Oct 15, 2025 12:23:16 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: =============================================================================== > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: Marlin software rasterizer = ENABLED > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: Version = [marlin-0.9.4.6.1-Unsafe-OpenJDK] > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer = sun.java2d.marlin.DMarlinRenderingEngine > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.useThreadLocal = true > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.useRef = soft > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.edges = 4096 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.pixelWidth = 4096 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > ... > INFO: QUAD_DEC_BND = 0.12800000607967377 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: INITIAL_EDGES_CAPACITY = 98304 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: INITIAL_CROSSING_COUNT = 1024 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: =============================================================================== > java.lang.RuntimeException: Marlin renderer not used at runtime ! > at ClipShapeTest.main(ClipShapeTest.java:250) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1474) > > > Looks like the logger usage was wrong, @RogerRiggs pointed this out. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28507#pullrequestreview-3512561978 From serb at openjdk.org Wed Nov 26 22:15:57 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 26 Nov 2025 22:15:57 GMT Subject: Integrated: 8298432: Investigate the benefits of usage of GetPrimitiveArrayCritical in the cmm code In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 09:29:48 GMT, Sergey Bylokhov wrote: > The LCMS JNI code currently uses GetByteArrayElements, GetShortArrayElements, GetIntArrayElements. These can be replaced by GetPrimitiveArrayCritical, which avoids unnecessary copying of array data and provides measurable performance improvements. > > This optimization was postponed earlier due to several reasons: > > - At that time, G1 did not support pinning, so critical sections could interfere with GC (see [JEP 423](https://openjdk.org/jeps/423)). Also note that this API is already used safely in many parts of java2d/awt. > - There was a plan to migrate to panama, but cold-startup issues ([JDK-8313344](https://bugs.openjdk.org/browse/JDK-8313344)) remain unresolved. > - GetPrimitiveArrayCritical forbids many JNI operations inside the critical region, including allocations and java callbacks, which could be unsafe for LCMS error handlers. However, LCMS color conversions do not trigger such callbacks (see [LittleCMS #516](https://github.com/mm2/Little-CMS/issues/516)). > > Performance data of various [combinations](https://bugs.openjdk.org/secure/attachment/114273/OnePixelConvert-1.java) for ColorSpace.toXX/fromXX in single-threaded and multi-threaded (64 threads) modes: > https://jmh.morethan.io/?gists=b1440355577dc48f2b19b976b67f1120,d31c6a585330c9167b462e377445ad2f > Example: > image This pull request has now been integrated. Changeset: 42db9ab6 Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/42db9ab629a6209aa471de8b3034c053b77629dd Stats: 79 lines in 4 files changed: 4 ins; 60 del; 15 mod 8298432: Investigate the benefits of usage of GetPrimitiveArrayCritical in the cmm code Reviewed-by: psadhukhan, jdv, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/27841 From jdv at openjdk.org Thu Nov 27 01:19:29 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 27 Nov 2025 01:19:29 GMT Subject: RFR: 8372534: Update Libpng to 1.6.51 Message-ID: <3LLhVAk4ZEb7Jd1DtXsdSh86IO0v9ESh8Rxy2XbPK0g=.7b1ba348-7cfd-4499-8f1f-77a1056079ea@github.com> Upgrade libpng used for Splashscreen from 1.6.47 to 1.6.51 version. ------------- Commit messages: - Update - update .md file - 8372534: Update Libpng to 1.6.51 Changes: https://git.openjdk.org/jdk/pull/28518/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28518&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372534 Stats: 638 lines in 21 files changed: 297 ins; 207 del; 134 mod Patch: https://git.openjdk.org/jdk/pull/28518.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28518/head:pull/28518 PR: https://git.openjdk.org/jdk/pull/28518 From serb at openjdk.org Thu Nov 27 01:47:53 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 27 Nov 2025 01:47:53 GMT Subject: RFR: 8371657: [macosx] Programmatically selecting/deselecting List item triggers an ItemEvent In-Reply-To: References: Message-ID: On Wed, 26 Nov 2025 17:04:30 GMT, Alexey Ivanov wrote: >> When I was working on [JDK-8369327](https://bugs.openjdk.org/browse/JDK-8369327) I got a suggestion to update the code that disables unnecessary events: >> https://github.com/openjdk/jdk/pull/27682#discussion_r2487686109 >> >> After checking that code more closely, I found that it does not work in all cases. The checks were first added in [JDK-7125456](https://bugs.openjdk.org/browse/JDK-7125456). It looks like only the case for the select method was fixed. Other cases still cause unnecessary events, and even more events happen when trying to add multi selection mode: https://github.com/openjdk/jdk/pull/27682#issuecomment-3487434403 >> >> So I made a new bug for this issue and fixed it separately. >> >> The [spec](https://github.com/openjdk/jdk/blob/8531fa146be1da5e96c0f23091882a27c67d7893/src/java.desktop/share/classes/java/awt/List.java#L899): >> >> * Adds the specified item listener to receive item events from >> * this list. Item events are sent in response to user input, but not >> * in response to calls to {@code select} or {@code deselect}. >> >> >> The new test checks most of the methods in the `java.awt.List` class. It passes on linux/windows, confirming that the same behavior is implemented in other toolkits (unfortunately on linux it is not stable enough so I had to problemlist it due to [JDK-8201307](https://bugs.openjdk.org/browse/JDK-8201307)). The test only checks for programmatic changes to the list. I am sure that if I change it to test mix of programmatic/user changes it will fail. I will work on that in a follow up bug. >> >> @aivanov-jdk @azvegint please take a look > > test/jdk/java/awt/List/NoEvents/ProgrammaticChange.java line 103: > >> 101: verify(); >> 102: >> 103: // "makeVisible" may change the current selection > > I wonder how `makeVisible` can change the current selection. I'd say it's a bug, if calling `makeVisible` changes the current selection. As of now, it should not change. However, this is lwawt, which uses the active swing l&f, and I do not see a reason why someone could not change that based on a design choice. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28245#discussion_r2566930453 From serb at openjdk.org Thu Nov 27 01:51:52 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 27 Nov 2025 01:51:52 GMT Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2] In-Reply-To: References: Message-ID: On Mon, 24 Nov 2025 07:59:24 GMT, Julian Waters wrote: >gcc documentation states that you typically need to pass the same options to the link step from the compile step, since the linker when LTO is active is actually the compiler in disguise. So it seems a pre-existing bug which affects the old jdk updates as well? probably we can extract that change and fix it separately and then backport? or do you plan to backport this one? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3583903828 From serb at openjdk.org Thu Nov 27 01:57:50 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 27 Nov 2025 01:57:50 GMT Subject: RFR: 8042054: JTree.updateUI uses out-of-date item size information [v2] In-Reply-To: References: <4nSpiTCuM72-GVjWm8-ukgr_wnEanjktrQcoqCvZ77A=.a19ae102-5b0f-4164-88e8-ba6c4c7295e3@github.com> Message-ID: On Tue, 25 Nov 2025 12:25:08 GMT, Prasanta Sadhukhan wrote: >>>If calling updateComponentTreeUI is logical updation to be done after L&F change, then maybe we can consider it as a pertinent solution too and close this as not an issue.. >> >> We should check the other components. Are any of them affected? If not we can check why, and apply the same logic to jtree. > > Since this is similar to JTable where issue is not seen and the cellrenderer and editors are used, I guess we should follow the same approach as it is being done in JTable as below and set the renderers and editors before the UI.. > > https://github.com/openjdk/jdk/blob/49176e322bbb9ed1ef2f534b949b937770b54162/src/java.desktop/share/classes/javax/swing/JTable.java#L3697-L3727 > > Other which does not use this renderers and editors we can skip setting UI after for the timebeing.. I see, please double check how the setUI() of "jtree vs jtable" are implemented, are they the same? also do we need to call something similar to configureEnclosingScrollPaneUI() in jtree? is the order is the only difference between the two? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28258#discussion_r2566943226 From jdv at openjdk.org Thu Nov 27 02:17:47 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 27 Nov 2025 02:17:47 GMT Subject: RFR: 8372534: Update Libpng to 1.6.51 In-Reply-To: <3LLhVAk4ZEb7Jd1DtXsdSh86IO0v9ESh8Rxy2XbPK0g=.7b1ba348-7cfd-4499-8f1f-77a1056079ea@github.com> References: <3LLhVAk4ZEb7Jd1DtXsdSh86IO0v9ESh8Rxy2XbPK0g=.7b1ba348-7cfd-4499-8f1f-77a1056079ea@github.com> Message-ID: On Thu, 27 Nov 2025 01:12:48 GMT, Jayathirth D V wrote: > Upgrade libpng used for Splashscreen from 1.6.47 to 1.6.51 version. make/modules/java.desktop/lib/ClientLibraries.gmk line 240: > 238: DISABLED_WARNINGS_gcc_jcmaster.c := implicit-fallthrough, \ > 239: DISABLED_WARNINGS_gcc_jdphuff.c := shift-negative-value, \ > 240: DISABLED_WARNINGS_gcc_png.c := maybe-uninitialized, \ These warnings were disabled in previous libpng update because of https://github.com/openjdk/jdk/pull/24021/files#r1993813117 We have appropriate update in upstream and we are not facing the build issue, so the code change is reverted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28518#discussion_r2566971834 From psadhukhan at openjdk.org Thu Nov 27 02:41:27 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 27 Nov 2025 02:41:27 GMT Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v9] In-Reply-To: References: Message-ID: > It seems JList.getScrollableUnitIncrement can sometime return 0 instead of positive number which is not specified in the javadoc which can lead to confusion. Clarified javadoc as to when it can return 0. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: javadoc clarification for 0 value ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26500/files - new: https://git.openjdk.org/jdk/pull/26500/files/92fd3e3c..691ab9c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26500&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26500&range=07-08 Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26500.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26500/head:pull/26500 PR: https://git.openjdk.org/jdk/pull/26500 From psadhukhan at openjdk.org Thu Nov 27 02:41:28 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 27 Nov 2025 02:41:28 GMT Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v8] In-Reply-To: References: <5dc6nhWoY6uh21_XogROhl0OxcfSOP-0qaST7HOkQjE=.7ddc3f97-6658-4d31-b2fa-8eb5c4e6e406@github.com> Message-ID: <9p8hB35Or4BbhJZOdIuMLXcEpP56RHDWHvJBp7ZLMeQ=.0198a21a-7353-404d-a7b3-9fd34fcee9d7@github.com> On Wed, 26 Nov 2025 18:03:09 GMT, Phil Race wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> spec wording > > src/java.desktop/share/classes/javax/swing/JList.java line 2510: > >> 2508: * @param direction less or equal to zero to scroll up/back, >> 2509: * greater than zero for down/forward >> 2510: * @return the non-negative "unit" increment value > > Since zero isn't "the distance to scroll to the next row", we need to explain when and why it can be zero. I have put in the conditions for returning zero value increment ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26500#discussion_r2566999733 From psadhukhan at openjdk.org Thu Nov 27 03:01:48 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 27 Nov 2025 03:01:48 GMT Subject: RFR: 8042054: JTree.updateUI uses out-of-date item size information [v2] In-Reply-To: References: <4nSpiTCuM72-GVjWm8-ukgr_wnEanjktrQcoqCvZ77A=.a19ae102-5b0f-4164-88e8-ba6c4c7295e3@github.com> Message-ID: On Thu, 27 Nov 2025 01:55:34 GMT, Sergey Bylokhov wrote: >> Since this is similar to JTable where issue is not seen and the cellrenderer and editors are used, I guess we should follow the same approach as it is being done in JTable as below and set the renderers and editors before the UI.. >> >> https://github.com/openjdk/jdk/blob/49176e322bbb9ed1ef2f534b949b937770b54162/src/java.desktop/share/classes/javax/swing/JTable.java#L3697-L3727 >> >> Other which does not use this renderers and editors we can skip setting UI after for the timebeing.. > > I see, please double check how the setUI() of "jtree vs jtable" are implemented, are they the same? also do we need to call something similar to configureEnclosingScrollPaneUI() in jtree? is the order is the only difference between the two? It's almost the same, JTable setUI calls an extra repaint [which is part of JTable.setUI spec too) which I am not sure is necessary for JTree for which we have [treeDidChange](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/JTree.html#treeDidChange())()] Regarding `configureEnclosingScrollPaneUI`, it's not needed as it is used to cater to the scrollPane with JTable feature https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/JTable.html#createScrollPaneForTable(javax.swing.JTable) which is not present for JTree ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28258#discussion_r2567026460 From jwaters at openjdk.org Thu Nov 27 04:26:51 2025 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 27 Nov 2025 04:26:51 GMT Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2] In-Reply-To: References: Message-ID: On Thu, 27 Nov 2025 01:49:07 GMT, Sergey Bylokhov wrote: > > gcc documentation states that you typically need to pass the same options to the link step from the compile step, since the linker when LTO is active is actually the compiler in disguise. > > So it seems a pre-existing bug which affects the old jdk updates as well? probably we can extract that change and fix it separately and then backport? or do you plan to backport this one? Hmm, I didn't create this with the idea of backporting it in mind. Should I do that? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3584144134 From psadhukhan at openjdk.org Thu Nov 27 10:03:48 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 27 Nov 2025 10:03:48 GMT Subject: RFR: 6292135: DefaultTableModel.setColumnIdentifiers() Clears JTable Row Heights Message-ID: Calling `DefaultTableModel.setColumnIdentifiers()` resizes the row height of the table to default row height (16) even if the row height is changed to something other than the default using J`Table.setRowHeight(row, height). ` The spec of `DefaultTableModel.setColumnIdentifiers()` https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/table/DefaultTableModel.html#setColumnIdentifiers(java.lang.Object[]) says that it `replaces the column identifiers in the model`, that is, the header field of the column is changed to the passed identifier and nowhere it is mentioned that row height would be changed. The issue happens because calling `DefaultTableModel.setColumnIdentifiers()` results in the firing of a `TableModelEvent` with HEADER_ROW event and JTable resets the `rowModel` for it irrespective of what the event is. Fix is to not reset the `rowModel` to keep the set rowHeight intact for HEADER_ROW event No other issue observed with CI with this fix.. ------------- Commit messages: - jcheck - JDK-6292135:DefaultTableModel.setColumnIdentifiers() Clears JTable Row Heights Changes: https://git.openjdk.org/jdk/pull/28529/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28529&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6292135 Stats: 101 lines in 2 files changed: 99 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28529.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28529/head:pull/28529 PR: https://git.openjdk.org/jdk/pull/28529 From psadhukhan at openjdk.org Thu Nov 27 12:44:28 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 27 Nov 2025 12:44:28 GMT Subject: RFR: 5107379: Component orientation in JOptionPane is not proper in Motif L&F. Message-ID: Issue is icon in JOptionPane is not aligned as per the Component Orientation in Motif LookAndFeel. It seems only the buttons are aligned as per component orientation whereas the icon is not. It is because the icon is drawn at "West" constraint whereas it should be drawn at beginning of line as done in BasicOptionPaneUI to ensure component orientation is honoured. ------------- Commit messages: - jcheck - 5107379: Component orientation in JOptionPane is not proper in Motif L&F. Changes: https://git.openjdk.org/jdk/pull/28532/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28532&range=00 Issue: https://bugs.openjdk.org/browse/JDK-5107379 Stats: 124 lines in 2 files changed: 122 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28532.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28532/head:pull/28532 PR: https://git.openjdk.org/jdk/pull/28532 From mbaesken at openjdk.org Thu Nov 27 12:46:11 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 27 Nov 2025 12:46:11 GMT Subject: RFR: 8369911: Test sun/java2d/marlin/ClipShapeTest.java#CubicDoDash, #Cubic and #Poly fail intermittent In-Reply-To: References: Message-ID: <9FmPecqfLBYDgXa9g45T6eiWygCMt80OhhZ6u-X9Me4=.69696159-25a8-4788-9f67-7eb5b7644f8d@github.com> On Wed, 26 Nov 2025 12:57:03 GMT, Matthias Baesken wrote: > We see a number of failures in the test sun/java2d/marlin/ClipShapeTest.java#CubicDoDash . > Output looks like this : > > > ----------System.out:(0/0)---------- > ----------System.err:(113/6520)---------- > Oct 15, 2025 12:23:16 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: =============================================================================== > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: Marlin software rasterizer = ENABLED > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: Version = [marlin-0.9.4.6.1-Unsafe-OpenJDK] > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer = sun.java2d.marlin.DMarlinRenderingEngine > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.useThreadLocal = true > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.useRef = soft > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.edges = 4096 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.pixelWidth = 4096 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > ... > INFO: QUAD_DEC_BND = 0.12800000607967377 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: INITIAL_EDGES_CAPACITY = 98304 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: INITIAL_CROSSING_COUNT = 1024 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: =============================================================================== > java.lang.RuntimeException: Marlin renderer not used at runtime ! > at ClipShapeTest.main(ClipShapeTest.java:250) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1474) > > > Looks like the logger usage was wrong, @RogerRiggs pointed this out. Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28507#issuecomment-3585658025 From mbaesken at openjdk.org Thu Nov 27 12:46:12 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 27 Nov 2025 12:46:12 GMT Subject: Integrated: 8369911: Test sun/java2d/marlin/ClipShapeTest.java#CubicDoDash, #Cubic and #Poly fail intermittent In-Reply-To: References: Message-ID: On Wed, 26 Nov 2025 12:57:03 GMT, Matthias Baesken wrote: > We see a number of failures in the test sun/java2d/marlin/ClipShapeTest.java#CubicDoDash . > Output looks like this : > > > ----------System.out:(0/0)---------- > ----------System.err:(113/6520)---------- > Oct 15, 2025 12:23:16 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: =============================================================================== > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: Marlin software rasterizer = ENABLED > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: Version = [marlin-0.9.4.6.1-Unsafe-OpenJDK] > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer = sun.java2d.marlin.DMarlinRenderingEngine > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.useThreadLocal = true > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.useRef = soft > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.edges = 4096 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: sun.java2d.renderer.pixelWidth = 4096 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > ... > INFO: QUAD_DEC_BND = 0.12800000607967377 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: INITIAL_EDGES_CAPACITY = 98304 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: INITIAL_CROSSING_COUNT = 1024 > Oct 15, 2025 12:23:17 AM sun.java2d.marlin.MarlinUtils logInfo > INFO: =============================================================================== > java.lang.RuntimeException: Marlin renderer not used at runtime ! > at ClipShapeTest.main(ClipShapeTest.java:250) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1474) > > > Looks like the logger usage was wrong, @RogerRiggs pointed this out. This pull request has now been integrated. Changeset: 150def42 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/150def42dd7f22d949b4d788bfe5986f236b9b37 Stats: 5 lines in 1 file changed: 2 ins; 3 del; 0 mod 8369911: Test sun/java2d/marlin/ClipShapeTest.java#CubicDoDash, #Cubic and #Poly fail intermittent Reviewed-by: mdoerr, rriggs, serb ------------- PR: https://git.openjdk.org/jdk/pull/28507 From aivanov at openjdk.org Thu Nov 27 19:14:53 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 27 Nov 2025 19:14:53 GMT Subject: RFR: 8371657: [macosx] Programmatically selecting/deselecting List item triggers an ItemEvent In-Reply-To: References: Message-ID: On Thu, 27 Nov 2025 01:45:06 GMT, Sergey Bylokhov wrote: > As of now, it should not change. However, this is lwawt, which uses the active swing l&f, and I do not see a reason why someone could not change that based on a design choice. I can't come up with any reason where `makeVisible` changes the current selection. The purpose of the method is to ensure the item at the specified index is visible which involves scrolling the list if the item isn't currently visible. I should never ever change the selected items. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28245#discussion_r2569806110 From serb at openjdk.org Thu Nov 27 21:44:45 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 27 Nov 2025 21:44:45 GMT Subject: RFR: 8371657: [macosx] Programmatically selecting/deselecting List item triggers an ItemEvent In-Reply-To: References: Message-ID: On Thu, 27 Nov 2025 19:12:19 GMT, Alexey Ivanov wrote: >> As of now, it should not change. However, this is lwawt, which uses the active swing l&f, and I do not see a reason why someone could not change that based on a design choice. > >> As of now, it should not change. However, this is lwawt, which uses the active swing l&f, and I do not see a reason why someone could not change that based on a design choice. > > I can't come up with any reason where `makeVisible` changes the current selection. The purpose of the method is to ensure the item at the specified index is visible which involves scrolling the list if the item isn't currently visible. > > I should never ever change the selected items. No, it?s not necessarily scrolling. It can remove items from the visible area and add items that should be visible. To do this, it only needs to update the current L&F. List.makeVisible() spec allows this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28245#discussion_r2570003913 From serb at openjdk.org Thu Nov 27 21:49:07 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 27 Nov 2025 21:49:07 GMT Subject: RFR: 8371657: [macosx] Programmatically selecting/deselecting List item triggers an ItemEvent [v2] In-Reply-To: References: Message-ID: > When I was working on [JDK-8369327](https://bugs.openjdk.org/browse/JDK-8369327) I got a suggestion to update the code that disables unnecessary events: > https://github.com/openjdk/jdk/pull/27682#discussion_r2487686109 > > After checking that code more closely, I found that it does not work in all cases. The checks were first added in [JDK-7125456](https://bugs.openjdk.org/browse/JDK-7125456). It looks like only the case for the select method was fixed. Other cases still cause unnecessary events, and even more events happen when trying to add multi selection mode: https://github.com/openjdk/jdk/pull/27682#issuecomment-3487434403 > > So I made a new bug for this issue and fixed it separately. > > The [spec](https://github.com/openjdk/jdk/blob/8531fa146be1da5e96c0f23091882a27c67d7893/src/java.desktop/share/classes/java/awt/List.java#L899): > > * Adds the specified item listener to receive item events from > * this list. Item events are sent in response to user input, but not > * in response to calls to {@code select} or {@code deselect}. > > > The new test checks most of the methods in the `java.awt.List` class. It passes on linux/windows, confirming that the same behavior is implemented in other toolkits (unfortunately on linux it is not stable enough so I had to problemlist it due to [JDK-8201307](https://bugs.openjdk.org/browse/JDK-8201307)). The test only checks for programmatic changes to the list. I am sure that if I change it to test mix of programmatic/user changes it will fail. I will work on that in a follow up bug. > > @aivanov-jdk @azvegint please take a look Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8371657 - Disable the new test on Linux due to 8201307 - Merge branch 'openjdk:master' into JDK-8371657 - 8371657: [macosx] Programmatically selecting/deselecting List item triggers an ItemEvent ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28245/files - new: https://git.openjdk.org/jdk/pull/28245/files/e4ca5019..5f7e55c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28245&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28245&range=00-01 Stats: 75549 lines in 1172 files changed: 50313 ins; 17042 del; 8194 mod Patch: https://git.openjdk.org/jdk/pull/28245.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28245/head:pull/28245 PR: https://git.openjdk.org/jdk/pull/28245 From serb at openjdk.org Thu Nov 27 21:54:45 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 27 Nov 2025 21:54:45 GMT Subject: RFR: 8372534: Update Libpng to 1.6.51 In-Reply-To: <3LLhVAk4ZEb7Jd1DtXsdSh86IO0v9ESh8Rxy2XbPK0g=.7b1ba348-7cfd-4499-8f1f-77a1056079ea@github.com> References: <3LLhVAk4ZEb7Jd1DtXsdSh86IO0v9ESh8Rxy2XbPK0g=.7b1ba348-7cfd-4499-8f1f-77a1056079ea@github.com> Message-ID: On Thu, 27 Nov 2025 01:12:48 GMT, Jayathirth D V wrote: > Upgrade libpng used for Splashscreen from 1.6.47 to 1.6.51 version. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28518#pullrequestreview-3516983381 From serb at openjdk.org Thu Nov 27 22:17:23 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 27 Nov 2025 22:17:23 GMT Subject: RFR: 8371657: [macosx] Programmatically selecting/deselecting List item triggers an ItemEvent [v3] In-Reply-To: References: Message-ID: > When I was working on [JDK-8369327](https://bugs.openjdk.org/browse/JDK-8369327) I got a suggestion to update the code that disables unnecessary events: > https://github.com/openjdk/jdk/pull/27682#discussion_r2487686109 > > After checking that code more closely, I found that it does not work in all cases. The checks were first added in [JDK-7125456](https://bugs.openjdk.org/browse/JDK-7125456). It looks like only the case for the select method was fixed. Other cases still cause unnecessary events, and even more events happen when trying to add multi selection mode: https://github.com/openjdk/jdk/pull/27682#issuecomment-3487434403 > > So I made a new bug for this issue and fixed it separately. > > The [spec](https://github.com/openjdk/jdk/blob/8531fa146be1da5e96c0f23091882a27c67d7893/src/java.desktop/share/classes/java/awt/List.java#L899): > > * Adds the specified item listener to receive item events from > * this list. Item events are sent in response to user input, but not > * in response to calls to {@code select} or {@code deselect}. > > > The new test checks most of the methods in the `java.awt.List` class. It passes on linux/windows, confirming that the same behavior is implemented in other toolkits (unfortunately on linux it is not stable enough so I had to problemlist it due to [JDK-8201307](https://bugs.openjdk.org/browse/JDK-8201307)). The test only checks for programmatic changes to the list. I am sure that if I change it to test mix of programmatic/user changes it will fail. I will work on that in a follow up bug. > > @aivanov-jdk @azvegint please take a look Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: Update ProgrammaticChange.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28245/files - new: https://git.openjdk.org/jdk/pull/28245/files/5f7e55c0..4c2b8769 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28245&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28245&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28245.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28245/head:pull/28245 PR: https://git.openjdk.org/jdk/pull/28245 From serb at openjdk.org Thu Nov 27 22:18:10 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 27 Nov 2025 22:18:10 GMT Subject: RFR: 8371759: Add missing @Override annotations in com.sun.imageio package [v2] In-Reply-To: <9IK6e1aTK_6ckzZNDuL7EGPLEd3DZd4RFGCgkEBF-jo=.70bb31bb-a3a6-480e-a39c-edaf5ad47c2e@github.com> References: <9IK6e1aTK_6ckzZNDuL7EGPLEd3DZd4RFGCgkEBF-jo=.70bb31bb-a3a6-480e-a39c-edaf5ad47c2e@github.com> Message-ID: > This patch adds missing `@Override` annotations to methods in the `com.sun.imageio` package that override methods from a superclass or interface. > Only source annotations are added; there are no behavioral changes. > > The previous patch for `com.sun.beans` can be found here: https://github.com/openjdk/jdk/pull/27887. Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8371759 - 8371759: Add missing @Override annotations in com.sun.imageio package ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28282/files - new: https://git.openjdk.org/jdk/pull/28282/files/c5caa00a..e9a3887f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28282&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28282&range=00-01 Stats: 78174 lines in 1216 files changed: 52499 ins; 17162 del; 8513 mod Patch: https://git.openjdk.org/jdk/pull/28282.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28282/head:pull/28282 PR: https://git.openjdk.org/jdk/pull/28282 From azvegint at openjdk.org Fri Nov 28 05:45:53 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 28 Nov 2025 05:45:53 GMT Subject: RFR: 8371759: Add missing @Override annotations in com.sun.imageio package [v2] In-Reply-To: References: <9IK6e1aTK_6ckzZNDuL7EGPLEd3DZd4RFGCgkEBF-jo=.70bb31bb-a3a6-480e-a39c-edaf5ad47c2e@github.com> Message-ID: <7iRqArroIhsno2Ht7zASqjyYVY52_TQvzbT3kfY-k44=.d10859d9-6e3b-4fb1-8756-784420cb9f20@github.com> On Thu, 27 Nov 2025 22:18:10 GMT, Sergey Bylokhov wrote: >> This patch adds missing `@Override` annotations to methods in the `com.sun.imageio` package that override methods from a superclass or interface. >> Only source annotations are added; there are no behavioral changes. >> >> The previous patch for `com.sun.beans` can be found here: https://github.com/openjdk/jdk/pull/27887. > > Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8371759 > - 8371759: Add missing @Override annotations in com.sun.imageio package Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28282#pullrequestreview-3517544257 From azvegint at openjdk.org Fri Nov 28 06:08:53 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 28 Nov 2025 06:08:53 GMT Subject: RFR: 8372534: Update Libpng to 1.6.51 In-Reply-To: <3LLhVAk4ZEb7Jd1DtXsdSh86IO0v9ESh8Rxy2XbPK0g=.7b1ba348-7cfd-4499-8f1f-77a1056079ea@github.com> References: <3LLhVAk4ZEb7Jd1DtXsdSh86IO0v9ESh8Rxy2XbPK0g=.7b1ba348-7cfd-4499-8f1f-77a1056079ea@github.com> Message-ID: On Thu, 27 Nov 2025 01:12:48 GMT, Jayathirth D V wrote: > Upgrade libpng used for Splashscreen from 1.6.47 to 1.6.51 version. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28518#pullrequestreview-3517579285 From psadhukhan at openjdk.org Fri Nov 28 06:38:30 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 28 Nov 2025 06:38:30 GMT Subject: RFR: 4337898: Serializing DefaultTableCellRenderer changes colors Message-ID: <7RPOHaLbFxCEgnFqBg5HFXrU1t6gx3CsiiqwbRKN3VQ=.3213266e-8746-4bdf-a4a4-0d3ea7969087@github.com> 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.. ------------- Commit messages: - jcheck - 4337898: Serializing DefaultTableCellRenderer changes colors - 4337898: Serializing DefaultTableCellRenderer changes colors Changes: https://git.openjdk.org/jdk/pull/28549/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28549&range=00 Issue: https://bugs.openjdk.org/browse/JDK-4337898 Stats: 102 lines in 2 files changed: 101 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28549.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28549/head:pull/28549 PR: https://git.openjdk.org/jdk/pull/28549 From serb at openjdk.org Fri Nov 28 06:42:10 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 28 Nov 2025 06:42:10 GMT Subject: Integrated: 8371759: Add missing @Override annotations in com.sun.imageio package In-Reply-To: <9IK6e1aTK_6ckzZNDuL7EGPLEd3DZd4RFGCgkEBF-jo=.70bb31bb-a3a6-480e-a39c-edaf5ad47c2e@github.com> References: <9IK6e1aTK_6ckzZNDuL7EGPLEd3DZd4RFGCgkEBF-jo=.70bb31bb-a3a6-480e-a39c-edaf5ad47c2e@github.com> Message-ID: On Thu, 13 Nov 2025 06:40:43 GMT, Sergey Bylokhov wrote: > This patch adds missing `@Override` annotations to methods in the `com.sun.imageio` package that override methods from a superclass or interface. > Only source annotations are added; there are no behavioral changes. > > The previous patch for `com.sun.beans` can be found here: https://github.com/openjdk/jdk/pull/27887. This pull request has now been integrated. Changeset: 0c6d1b9c Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/0c6d1b9c8bfd7f4e39a6621c7a8f7bdcd044a05f Stats: 491 lines in 93 files changed: 401 ins; 0 del; 90 mod 8371759: Add missing @Override annotations in com.sun.imageio package Reviewed-by: tr, jdv, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/28282 From azvegint at openjdk.org Fri Nov 28 07:49:48 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 28 Nov 2025 07:49:48 GMT Subject: RFR: 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.. Did you verify that colors are successfully restored after deserialization? (standard and manually set) test/jdk/javax/swing/DefaultTableCellRenderer/DefRendererSerialize.java line 46: > 44: static final String INSTRUCTIONS = """ > 45: A JTable is shown > 46: If the table text is black on white and not black on gray, We can set the table's background color to a bright color, such as red, to distinguish it from the gray. On some displays, it can be difficult to see the difference between `java.awt.Color[r=238,g=238,b=238]` and `java.awt.Color[r=255,g=255,b=255]` with the naked eye. test/jdk/javax/swing/DefaultTableCellRenderer/DefRendererSerialize.java line 62: > 60: static JFrame createTestUI() { > 61: String[][] rowData = { {"1-1","1-2","1-3"}, > 62: {"2-1","2-2","2-3"}, I guess the test could be automated. e.g. if we leave the central cell blank: Suggestion: {"2-1","","2-3"}, We can safely retrieve the pixel color from the center of the cell and check it against the white color Rectangle tableRect = table.getCellRect(1, 1, true); Point tableOnScreen = table.getLocationOnScreen(); Point p = new Point( tableOnScreen.x + tableRect.x + tableRect.width / 2, tableOnScreen.y + tableRect.y + tableRect.height / 2 ); Color pixelColor = robot.getPixelColor(p.x, p.y); // ... color check ------------- PR Review: https://git.openjdk.org/jdk/pull/28549#pullrequestreview-3517761910 PR Review Comment: https://git.openjdk.org/jdk/pull/28549#discussion_r2570711017 PR Review Comment: https://git.openjdk.org/jdk/pull/28549#discussion_r2570685639 From psadhukhan at openjdk.org Fri Nov 28 09:00:20 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 28 Nov 2025 09:00:20 GMT Subject: RFR: 6223700: XP L&F: Non-TopLevel JMenu's painting error Message-ID: <7szJgbTU8E_MWUDB2koWP4tDiP8nqiaYZ41cDrbRo3o=.9f3341d5-a9bb-48b8-8052-a706adfe7165@github.com> It is seen that non-TopLevel JMenu's get repainted when the mouse exits the item. If the popup menu is still visible to the right, repainting the JMenu causes the selection background to be repainted over the top of the popup, even though the popup is supposed to appear above the JMenu. The problem is caused by the mouse handling code in the protected inner class `WindowsMenuUI.WindowsMouseInputHandler.` The `mouseEntered` and `mouseExited` handlers set the RollOver property and the JMenu gets repainted. However, setting the RollOver property is only necessary for top-level JMenus. Non-TopLevel JMenu menu items such as these get painted by the super class BasicMenuItemUI which uses isSelected() rather than isRollOver() to determine whether the selection background color should be used. Fix is to use the repainting only for TopLevel Menu in `mouseExited`, the same way it is being done for `mouseEntered` ------------- Commit messages: - jcheck - 6223700: XP L&F: Non-TopLevel JMenu's painting error Changes: https://git.openjdk.org/jdk/pull/28551/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28551&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6223700 Stats: 83 lines in 2 files changed: 82 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28551.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28551/head:pull/28551 PR: https://git.openjdk.org/jdk/pull/28551 From aivanov at openjdk.org Fri Nov 28 18:13:47 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 28 Nov 2025 18:13:47 GMT Subject: RFR: 8371657: [macosx] Programmatically selecting/deselecting List item triggers an ItemEvent [v3] In-Reply-To: References: Message-ID: On Thu, 27 Nov 2025 22:17:23 GMT, Sergey Bylokhov wrote: >> When I was working on [JDK-8369327](https://bugs.openjdk.org/browse/JDK-8369327) I got a suggestion to update the code that disables unnecessary events: >> https://github.com/openjdk/jdk/pull/27682#discussion_r2487686109 >> >> After checking that code more closely, I found that it does not work in all cases. The checks were first added in [JDK-7125456](https://bugs.openjdk.org/browse/JDK-7125456). It looks like only the case for the select method was fixed. Other cases still cause unnecessary events, and even more events happen when trying to add multi selection mode: https://github.com/openjdk/jdk/pull/27682#issuecomment-3487434403 >> >> So I made a new bug for this issue and fixed it separately. >> >> The [spec](https://github.com/openjdk/jdk/blob/8531fa146be1da5e96c0f23091882a27c67d7893/src/java.desktop/share/classes/java/awt/List.java#L899): >> >> * Adds the specified item listener to receive item events from >> * this list. Item events are sent in response to user input, but not >> * in response to calls to {@code select} or {@code deselect}. >> >> >> The new test checks most of the methods in the `java.awt.List` class. It passes on linux/windows, confirming that the same behavior is implemented in other toolkits (unfortunately on linux it is not stable enough so I had to problemlist it due to [JDK-8201307](https://bugs.openjdk.org/browse/JDK-8201307)). The test only checks for programmatic changes to the list. I am sure that if I change it to test mix of programmatic/user changes it will fail. I will work on that in a follow up bug. >> >> @aivanov-jdk @azvegint please take a look > > Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: > > Update ProgrammaticChange.java Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28245#pullrequestreview-3519661706 From aivanov at openjdk.org Fri Nov 28 20:05:46 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 28 Nov 2025 20:05:46 GMT Subject: RFR: 8371657: [macosx] Programmatically selecting/deselecting List item triggers an ItemEvent [v3] In-Reply-To: References: Message-ID: On Thu, 27 Nov 2025 21:42:10 GMT, Sergey Bylokhov wrote: > No, it?s not necessarily scrolling. It can remove items from the visible area and add items that should be visible. What do you mean? Scrolling means exactly this: move the visible area so that the item at the `index` becomes visible; this implies other items will become invisible. > To do this, it only needs to update the current L&F. List.makeVisible() spec allows this. I don't understand what you mean here, either. --- Still why do you think the selection may change during this operation? If all the items in the list are selected, they have to remain selected, whatever the list itself does to ensure the item at the `index` is visible on the screen. If none of the items are selected, it has to remain so. Calling `makeVisible` should never select or deselect items in the list. In this test, `getSelectedIndexes` would return an array that contains `[0, 1, ?, list.getItemCount() -1]`, in other words all the indexes of the items in the list. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28245#discussion_r2572407734 From dnguyen at openjdk.org Fri Nov 28 22:08:13 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 28 Nov 2025 22:08:13 GMT Subject: RFR: 8371647: 7 Integer overflows in mlib_malloc of mlib_sys.c:85 Message-ID: There is a possible overflow when using `mlib_alloc()`. For example, `mlib_alloc(sizeof(mlib_s32) * (m * n))` may overflow if m and n are greater than 46430, since this would be greater than the max value for a signed 32 bit integer. I have added `SAFE_TO_ADD` and `SAFE_TO_MULT` in an attempt to amend this issue. CI testing shows all green. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/28560/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28560&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371647 Stats: 42 lines in 5 files changed: 42 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28560.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28560/head:pull/28560 PR: https://git.openjdk.org/jdk/pull/28560 From prr at openjdk.org Sat Nov 29 01:51:47 2025 From: prr at openjdk.org (Phil Race) Date: Sat, 29 Nov 2025 01:51:47 GMT Subject: RFR: 8372534: Update Libpng to 1.6.51 In-Reply-To: <3LLhVAk4ZEb7Jd1DtXsdSh86IO0v9ESh8Rxy2XbPK0g=.7b1ba348-7cfd-4499-8f1f-77a1056079ea@github.com> References: <3LLhVAk4ZEb7Jd1DtXsdSh86IO0v9ESh8Rxy2XbPK0g=.7b1ba348-7cfd-4499-8f1f-77a1056079ea@github.com> Message-ID: On Thu, 27 Nov 2025 01:12:48 GMT, Jayathirth D V wrote: > Upgrade libpng used for Splashscreen from 1.6.47 to 1.6.51 version. I assume all splash screen tests PASS ? ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28518#pullrequestreview-3520303089 From serb at openjdk.org Sat Nov 29 23:26:46 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 29 Nov 2025 23:26:46 GMT Subject: RFR: 8371657: [macosx] Programmatically selecting/deselecting List item triggers an ItemEvent [v3] In-Reply-To: References: Message-ID: On Fri, 28 Nov 2025 20:03:34 GMT, Alexey Ivanov wrote: >Scrolling means exactly this: move the visible area so that the item at the index becomes visible; this implies other items will become invisible. No that is not, there is nothing related to the scrolling in the spec of makeVisible: `Makes the item at the specified index visible.` That spec can be implemented in a different ways. > In this test, getSelectedIndexes would return an array that contains [0, 1, ?, list.getItemCount() -1], in other words all the indexes of the items in the list. Just check the spec of the getSelectedIndexes method: it contains the list of selected indexes, not the actual selected items. This is why notifications are sent when the add/delete methods are executed, even if the added or deleted items are not selected. It is possible that makeVisible will delete all items before the visible region and then add them at the end, which will trigger notifications even though this is only an intermediate operation. >>To do this, it only needs to update the current L&F. List.makeVisible() spec allows this. >I don't understand what you mean here, either. You do not believe it is possible to implement a JList.ensureIndexIsVisible() in a ui delegate using add/delete in some L&F? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28245#discussion_r2573245958 From jdv at openjdk.org Sun Nov 30 15:53:47 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Sun, 30 Nov 2025 15:53:47 GMT Subject: RFR: 8372534: Update Libpng to 1.6.51 In-Reply-To: References: <3LLhVAk4ZEb7Jd1DtXsdSh86IO0v9ESh8Rxy2XbPK0g=.7b1ba348-7cfd-4499-8f1f-77a1056079ea@github.com> Message-ID: <1SGfRUTyMfMhYv9D1VS3sldPARt4uF-Lr2LGYXWzgIo=.c7c15f97-c53c-4636-bc25-b475a08575a2@github.com> On Sat, 29 Nov 2025 01:48:41 GMT, Phil Race wrote: > I assume all splash screen tests PASS ? Yes, Automated tests are verified in CI and i have verified manual tests locally. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28518#issuecomment-3592727853