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: >

@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: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. > >

@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

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:

> 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

------------- 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

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: