From jwaters at openjdk.org Mon Jan 1 17:56:19 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 1 Jan 2024 17:56:19 GMT Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v45] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: <4KJ3Dr7751aD60ympmRcvJEN22Tzt3va9I04AT8YNX8=.d474b0b8-4a2a-49bc-8ceb-8f3ea69b8b74@github.com> On Mon, 4 Dec 2023 09:39:09 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits: > > - Merge branch 'openjdk:master' into patch-10 > - Fix awt_Window.cpp > - Fix awt_PrintJob.cpp > - -Zc:stringStrings no longer needed with -permissive- flags-cflags.m4 > - Fix awt_Window.cpp > - awt_Window.cpp > - awt_PrintJob.cpp > - awt_Frame.cpp > - Whitespace awt_Component.cpp > - awt_Frame.cpp > - ... and 68 more: https://git.openjdk.org/jdk/compare/ed5b8c3a...fda1ab0f Do not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1873418448 From mickleness at gmail.com Mon Jan 1 20:28:46 2024 From: mickleness at gmail.com (Jeremy Wood) Date: Mon, 01 Jan 2024 20:28:46 +0000 Subject: the easiest ways to play an audio clip are the discouraged ones In-Reply-To: References: Message-ID: I agree playing audio was difficult to navigate when I first tried it. I?m a relative outsider to this group and have no sway over things like documentation, but for anyone interested in doing their own legwork on this topic: here?s some code I used to help manage audio: The audio player itself: https://github.com/mickleness/pumpernickel/blob/master/src/main/java/com/pump/audio/AudioPlayer.java A Swing component to help manage it: https://github.com/mickleness/pumpernickel/blob/master/src/main/java/com/pump/swing/AudioPlayerComponent.java A jar that executes it: https://github.com/mickleness/pumpernickel/tree/master/release/jars A video of the Swing code in action that demos a couple different UIs: https://screenpal.com/watch/cZVVYZVHymx - Jeremy ------ Original Message ------ >From mark.yagnatinsky at barclays.com To swinxythecat at gmail.com Cc client-libs-dev at openjdk.org Date 12/31/23, 2:43:09?PM Subject RE: the easiest ways to play an audio clip are the discouraged ones >Resending; last one got blocked due to message size so trimming >previous conversation > > > >From: Yagnatinsky, Mark : Markets Pre Trade >Sent: Tuesday, December 26, 2023 12:18 AM >To: 'SWinxy' >Cc:client-libs-dev at openjdk.org >Subject: RE: the easiest ways to play an audio clip are the discouraged >ones > > > >Thanks for responding. And thanks for the history page!! > >The sad thing is that the issue is not just a documentation issue. > >It really does takes around five dozen of lines of code to do >accomplish the following task: > >?play a sound file on my disk without leaking any resources? > >(Or at least, I haven?t found a way to do it in much less than five >dozen lines.) > > > >AudioAction is also ?intern-ish?: it seems designed to be called from >look & feel code. > > > >As for the tutorials: I realize they are barely maintained and I wish >they still were. > >But I see they still get occasional updates. Maybe this one could be >improved. > >I suspect the sound tutorial has had no big updates since 1998, though >the history page you linked claims 2006 for Java 6? (but where?s >getClip() then?) > > > >But lack of good docs is merely the second-biggest problem. > >The biggest is that the API provides no easy way to accomplish what >should be a trivial task. > >Ideally the following lines of code should Just Work: > >javax.sound.Player.playAsync(url); // fire and forget; leaks nothing > >javax.sound.Player.playAndWait(url); // returns once playback is done, >leaks nothing. > >I shouldn?t have to know about ULAW vs ALAW vs PCM. > >I shouldn?t even have to know about sampled vs midi. > >(For nontrivial things, obviously those are very different; but not for >something this simple.) > >I shouldn?t have to implement line listeners and create a countdown >latch. > >It really shouldn?t be this hard! > >The current difficulty level is high enough that people will ask >themselves: > >?do I really need add sound support? Maybe I can live without it?? > >It should be easy enough that you can do it on a whim! > >This message is for information purposes only. It is not a >recommendation, advice, offer or solicitation to buy or sell a product >or service, nor an official confirmation of any transaction. It is >directed at persons who are professionals and is intended for the >recipient(s) only. It is not directed at retail customers. This message >is subject to the terms at: >https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. > >For important disclosures, please see: >https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html >regarding marketing commentary from Barclays Sales and/or Trading >desks, who are active market participants; >https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html >regarding our standard terms for Barclays Corporate and Investment Bank >where we trade with you in principal-to-principal wholesale markets >transactions; and in respect to Barclays Research, including >disclosures relating to specific issuers, see: >http://publicresearch.barclays.com. >__________________________________________________________________________________ >If you are incorporated or operating in Australia, read these important >disclosures: >https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html. >__________________________________________________________________________________ >For more details about how we use personal information, see our privacy >notice: >https://www.cib.barclays/disclosures/personal-information-use.html. >__________________________________________________________________________________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serb at openjdk.org Tue Jan 2 00:36:49 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 2 Jan 2024 00:36:49 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v4] In-Reply-To: References: Message-ID: On Fri, 22 Dec 2023 04:03:14 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. >> >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Removed space test/jdk/java/awt/color/NonICCFilterTest.java line 106: > 104: ccop.filter(src, dest); > 105: > 106: try { This try block seems unnecessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1439107074 From psadhukhan at openjdk.org Tue Jan 2 03:19:42 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 2 Jan 2024 03:19:42 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v6] In-Reply-To: References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> Message-ID: On Wed, 20 Dec 2023 16:58:53 GMT, Alexey Ivanov wrote: > > > > But I do have another suggestion that actually might have been the best thing to do all those years ago. Keep the over-ride as the default behaviour, and document it better. But if the app calls setMaximumSize or setMinimumSize() then honour it like you are supposed to. I suspect very few apps actually call these since they are complete no-ops today. If we do that, then yes, you'll still see differences if you do call those APIs and forgot about it because it didn't make a difference. > > > > > > > > > Do you mean this way https://openjdk.github.io/cr/?repo=jdk&pr=15325&range=01#sdiff-0-src/java.desktop/share/classes/javax/swing/JScrollBar.java what I had done in the initial iteration? I guess that change will still show the above problem during frame resize, where scrollbars are not rigid > > > > > > This is how I understand Phil's comment. > > As I understand Phil's comment, he suggests using the implementation that you used in the first iteration of this fix: > > https://github.com/openjdk/jdk/blob/31bbdee8ea71f43eb4863af50b398170a7b81ed2/src/java.desktop/share/classes/javax/swing/JScrollBar.java#L762-L772 > > That is we preserve the current behaviour of `getMinimumSize()` and `getMaximumSize()` methods in `JScrollBar`, yet if `setMinimumSize()` or `setMaximumSize()` is called, the corresponding `get-` methods return the set value and thus they follow the contract specified in `JComponent`. > > @prrace, could you confirm, please? > I already mentioned to him in this comment https://github.com/openjdk/jdk/pull/15325#issuecomment-1818768822 that moving back to initial fix iteration will cause the same problem as you mentioned https://github.com/openjdk/jdk/pull/15325#issuecomment-1796167220 which is the same what we observed when we removed these 2 getXXX methods (which was mentioned in hmuller comment) so if we are OK with the change in behaviour as compared to current, then removing these 2 methods may be considered as compared to moving to 1st iteration of this fix... ------------- PR Comment: https://git.openjdk.org/jdk/pull/15325#issuecomment-1873589422 From rkannathpari at openjdk.org Tue Jan 2 03:48:12 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 2 Jan 2024 03:48:12 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v5] In-Reply-To: References: Message-ID: > Hi Reviewers, > There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. > > Renjith. Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Removed unnecessary try block ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16895/files - new: https://git.openjdk.org/jdk/pull/16895/files/1bf2cb3b..79627652 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=03-04 Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16895.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16895/head:pull/16895 PR: https://git.openjdk.org/jdk/pull/16895 From rkannathpari at openjdk.org Tue Jan 2 03:53:06 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 2 Jan 2024 03:53:06 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v6] In-Reply-To: References: Message-ID: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> > Hi Reviewers, > There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. > > Renjith. Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Removed unnecessary try block ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16895/files - new: https://git.openjdk.org/jdk/pull/16895/files/79627652..fdc1ce8a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16895.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16895/head:pull/16895 PR: https://git.openjdk.org/jdk/pull/16895 From rkannathpari at openjdk.org Tue Jan 2 03:53:07 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 2 Jan 2024 03:53:07 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v4] In-Reply-To: References: Message-ID: On Tue, 2 Jan 2024 00:33:47 GMT, Sergey Bylokhov wrote: >> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed space > > test/jdk/java/awt/color/NonICCFilterTest.java line 106: > >> 104: ccop.filter(src, dest); >> 105: >> 106: try { > > This try block seems unnecessary. @mrserb, Thank you for your review, I have removed try block. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1439139317 From serb at openjdk.org Tue Jan 2 05:34:51 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 2 Jan 2024 05:34:51 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v6] In-Reply-To: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> References: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> Message-ID: On Tue, 2 Jan 2024 03:53:06 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. >> >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Removed unnecessary try block test/jdk/java/awt/color/NonICCFilterTest.java line 47: > 45: > 46: protected TestColorSpace(boolean bSrc) { > 47: super(CS_sRGB, 3); CS_sRGB is not a constant of the ColorSpace type, the ICC_Profile.getInstance(xx).getColorSpaceType() and profile.getNumComponents() should be used. test/jdk/java/awt/color/NonICCFilterTest.java line 53: > 51: > 52: public float[] toRGB(float[] colorvalue) { > 53: return colorvalue; Just for completeness, it is probably better to use csRGB.toRGB and csRGB.fromRGB in these two methods test/jdk/java/awt/color/NonICCFilterTest.java line 109: > 107: throw new RuntimeException("Test failed: Source equal to Destination"); > 108: } > 109: } The "}" is missing in the latest version. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1439162717 PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1439163073 PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1439163248 From mark.yagnatinsky at barclays.com Tue Jan 2 06:27:12 2024 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Tue, 2 Jan 2024 06:27:12 +0000 Subject: the easiest ways to play an audio clip are the discouraged ones In-Reply-To: References: Message-ID: Thanks Julian (and sorry for messing up the message threading? I?ll try not to do that next time). It looks like you built a ?full-fledged? audio player, and it took hundreds of lines of code. Maybe that?s reasonable for a full-fledged audio player. But it?s unfortunate that even a basic ?fire and forget? feature to play an audio file should take lots of lines. This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. For important disclosures, please see: https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com. __________________________________________________________________________________ If you are incorporated or operating in Australia, read these important disclosures: https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html. __________________________________________________________________________________ For more details about how we use personal information, see our privacy notice: https://www.cib.barclays/disclosures/personal-information-use.html. __________________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From serb at openjdk.org Tue Jan 2 08:04:46 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 2 Jan 2024 08:04:46 GMT Subject: RFR: 8319598: SMFParser misinterprets interrupted running status [v2] In-Reply-To: References: Message-ID: On Sat, 11 Nov 2023 12:32:15 GMT, Jan Trukenm?ller wrote: >> The MIDI file parser misinterprets events without status byte when they appear directly after a Meta of SysEx event. >> >> For my bugfix I had to decide between two possible solutions: >> - Strict solution: Throw an InvalidMidiDataException >> - Tolerant solution: Use the status of the last channel event as running status >> >> I used the tolerant solution. >> I will send an email to the list client-libs-dev with my reasons. > > Jan Trukenm?ller has updated the pull request incrementally with one additional commit since the last revision: > > reduced line lengths keep open ------------- PR Comment: https://git.openjdk.org/jdk/pull/16546#issuecomment-1873710896 From duke at openjdk.org Tue Jan 2 12:45:04 2024 From: duke at openjdk.org (Karl T) Date: Tue, 2 Jan 2024 12:45:04 GMT Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java failed with 'Cannot invoke "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is null' In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 14:19:52 GMT, Alexey Ivanov wrote: > This is somewhat a continuation of #11104 where the issue was discussed and where I found [the root cause](https://github.com/openjdk/jdk/pull/11104#issuecomment-1382435784). > > **Root Cause** > > The icon extraction code compares the returned handle to zero: > https://github.com/openjdk/jdk/blob/8cb25d3de494c6d9357a1c199e1a9dbff9be9948/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1157-L1158 > > On 64-bit systems, a valid handle can be negative. For example: > > > getIcon : Desktop 16(16) > GetIconLocation(uFlags=0x22, flags=0x4, index=-110) SUCCESS - szBuf=C:\Windows\system32\imageres.dll > Extract - hres: 0, hIcon=0000000019B200F9, hIconSmall=FFFFFFFFF98C00EB, size=16(0x100020) > SUCCEEDED > !!! hIcon(0xfffffffff98c00eb) <= 0 : Desktop 16(16) > > > Here in `size=16(0x100020)`, 16 is the requested icon size, the value in parenthesis is value of `iconSize` passed to the [`Extract`](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-iextracticonw-extract) method that contains the size for small icon in high word and that for large icon in low word. `Desktop 16(16)` means the icon of size 16?16 is requested, and we're extracting 16?16 icon. > > The icon was extracted _successfully_ but its handle was interpreted as an error. > > The same problem exists in the fallback code: > https://github.com/openjdk/jdk/blob/8cb25d3de494c6d9357a1c199e1a9dbff9be9948/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1161 > > Then when the fallback code is executed, another problem occurs: > > > GetIconLocation(uFlags=0x40, flags=0x1a3, index=-675088752) SUCCESS - szBuf= > Extract - hres: 80004005, hIcon=0000000000000000, hIconSmall=000001A3D7C2F83A, size=16(100020) > NOT SUCCEEDED > hIcon = 0x1a3d7c2f83a : Desktop 16(16) > > > The error code 0x80004005 is `E_FAIL`. Yet the return value is not verified in the code: > https://github.com/openjdk/jdk/blob/8cb25d3de494c6d9357a1c199e1a9dbff9be9948/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp#L997-L1003 > > Since the icon handle is *seemingly* valid, it continues to extracting the icon bits: > > > native getIconBits - fn_GetIconInfo returned false > Error code: 0x57a - Invalid cursor handle. > makeIcon: iconBits = null > > > It's not a surprise. After all, the `Extract` method returned an error, which means neither icon handle is valid. > > In the end, the `MultiResolutionIcon` contains `null`: > > ????16 -> null > ????32 -> BufferedImage @ 59e735d > ????24 -> BufferedImage @ 60b2faf0 > > > This problem has existed fo... This PR does **not fix** the NPE. It is **still there in JDK 21.0.1**. See [this post](https://forums.oracle.com/ords/apexds/post/jdk-21-0-1-the-open-file-dialog-hangs-when-selecting-a-fold-0060), or https://github.com/apache/netbeans/issues/6828, or https://github.com/skylot/jadx/issues/2073 Steps to Reproduce: 1. Open the "Open file" dialog (Using JFileChooser) in Windows L&F. 2. Navigate to a folder containing .exe files with the default Windows exe icon (e.g. `C:\windows`). To finally fix the NPE change following line: https://github.com/openjdk/jdk/blob/2e4a3c47e262f91a7f881d9d990eb81a929d1627/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1451 to: ~~~java if (retVal != null && retVal.getWidth(null) != w) { ~~~ ------------- PR Comment: https://git.openjdk.org/jdk/pull/12010#issuecomment-1873980572 From mbaesken at openjdk.org Tue Jan 2 15:09:57 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 2 Jan 2024 15:09:57 GMT Subject: RFR: JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows Message-ID: <5x-CDbd8ujYRMOO46Emn8ybYsqfkipVoHBnFylB1DTE=.fdc27846-0928-4901-84cc-98937c76e7d1@github.com> The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni , and shows on Windows server 2019 the following JNI warning , so the test fails on this Windows version. stdout: [WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 23-internal/Native Method) at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 23-internal/Win32GraphicsEnvironment.java:95) at sun.awt.Win32GraphicsEnvironment.(java.desktop at 23-internal/Win32GraphicsEnvironment.java:63) at sun.awt.PlatformGraphicsInfo.createGE(java.desktop at 23-internal/PlatformGraphicsInfo.java:34) at java.awt.GraphicsEnvironment$LocalGE.createGE(java.desktop at 23-internal/GraphicsEnvironment.java:93) at java.awt.GraphicsEnvironment$LocalGE.(java.desktop at 23-internal/GraphicsEnvironment.java:84) at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(java.desktop at 23-internal/GraphicsEnvironment.java:106) at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44) We better add an exception check to get rid of the JNI warning (and also of the test failure) . ------------- Commit messages: - JDK-8276809 Changes: https://git.openjdk.org/jdk/pull/17224/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17224&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8276809 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17224.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17224/head:pull/17224 PR: https://git.openjdk.org/jdk/pull/17224 From aivanov at openjdk.org Tue Jan 2 16:14:50 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 2 Jan 2024 16:14:50 GMT Subject: RFR: 8320343 : Generate GIF images for AbstractButton/5049549/bug5049549.java [v6] In-Reply-To: References: Message-ID: <8uD-5Wj4lvE9Rz1SgddGVS8OZHnJX2-GXe9AfJaJXX4=.05b5dc8b-113a-485c-818a-8d908dd230b8@github.com> On Wed, 27 Dec 2023 03:47:16 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> >> Updated the test and it will generate required images on the fly so storing and loading image from repo could be avoided. Please review and let me know your suggestions. >> >> Regards, >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Added final modifier Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17029#pullrequestreview-1800664076 From rkannathpari at openjdk.org Tue Jan 2 16:18:47 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 2 Jan 2024 16:18:47 GMT Subject: Integrated: 8320343 : Generate GIF images for AbstractButton/5049549/bug5049549.java In-Reply-To: References: Message-ID: On Fri, 8 Dec 2023 03:23:22 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > > Updated the test and it will generate required images on the fly so storing and loading image from repo could be avoided. Please review and let me know your suggestions. > > Regards, > Renjith. This pull request has now been integrated. Changeset: 9481d06e Author: Renjith Kannath Pariyangad Committer: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/9481d06e62334872af539ccfb8c1ea25e30a6da3 Stats: 39 lines in 8 files changed: 22 ins; 4 del; 13 mod 8320343: Generate GIF images for AbstractButton/5049549/bug5049549.java Reviewed-by: aivanov ------------- PR: https://git.openjdk.org/jdk/pull/17029 From aivanov at openjdk.org Tue Jan 2 18:01:01 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 2 Jan 2024 18:01:01 GMT Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java failed with 'Cannot invoke "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is null' In-Reply-To: References: Message-ID: <5oI1DxjQwGFXbXcRPM3cxdcRShLl7V38BstVpQ9k8to=.47da765f-b4e1-4c4b-a643-e317e902318d@github.com> On Mon, 16 Jan 2023 14:19:52 GMT, Alexey Ivanov wrote: > This is somewhat a continuation of #11104 where the issue was discussed and where I found [the root cause](https://github.com/openjdk/jdk/pull/11104#issuecomment-1382435784). > > **Root Cause** > > The icon extraction code compares the returned handle to zero: > https://github.com/openjdk/jdk/blob/8cb25d3de494c6d9357a1c199e1a9dbff9be9948/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1157-L1158 > > On 64-bit systems, a valid handle can be negative. For example: > > > getIcon : Desktop 16(16) > GetIconLocation(uFlags=0x22, flags=0x4, index=-110) SUCCESS - szBuf=C:\Windows\system32\imageres.dll > Extract - hres: 0, hIcon=0000000019B200F9, hIconSmall=FFFFFFFFF98C00EB, size=16(0x100020) > SUCCEEDED > !!! hIcon(0xfffffffff98c00eb) <= 0 : Desktop 16(16) > > > Here in `size=16(0x100020)`, 16 is the requested icon size, the value in parenthesis is value of `iconSize` passed to the [`Extract`](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-iextracticonw-extract) method that contains the size for small icon in high word and that for large icon in low word. `Desktop 16(16)` means the icon of size 16?16 is requested, and we're extracting 16?16 icon. > > The icon was extracted _successfully_ but its handle was interpreted as an error. > > The same problem exists in the fallback code: > https://github.com/openjdk/jdk/blob/8cb25d3de494c6d9357a1c199e1a9dbff9be9948/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1161 > > Then when the fallback code is executed, another problem occurs: > > > GetIconLocation(uFlags=0x40, flags=0x1a3, index=-675088752) SUCCESS - szBuf= > Extract - hres: 80004005, hIcon=0000000000000000, hIconSmall=000001A3D7C2F83A, size=16(100020) > NOT SUCCEEDED > hIcon = 0x1a3d7c2f83a : Desktop 16(16) > > > The error code 0x80004005 is `E_FAIL`. Yet the return value is not verified in the code: > https://github.com/openjdk/jdk/blob/8cb25d3de494c6d9357a1c199e1a9dbff9be9948/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp#L997-L1003 > > Since the icon handle is *seemingly* valid, it continues to extracting the icon bits: > > > native getIconBits - fn_GetIconInfo returned false > Error code: 0x57a - Invalid cursor handle. > makeIcon: iconBits = null > > > It's not a surprise. After all, the `Extract` method returned an error, which means neither icon handle is valid. > > In the end, the `MultiResolutionIcon` contains `null`: > > ????16 -> null > ????32 -> BufferedImage @ 59e735d > ????24 -> BufferedImage @ 60b2faf0 > > > This problem has existed fo... Thank you, Karl, for bringing the problem in this PR. It already exist in JBS as [JDK-8320692](https://bugs.openjdk.org/browse/JDK-8320692): _Cannot invoke java.awt.Image.getWidth(java.awt.image.ImageObserver)_. I added my observations there. The problem is likely applicable to other file types which have per-instance icons, however, these are uncommon with the exception of exe files. The suggested fix won't work, there should be an icon but we have to handle the fallback gracefully. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12010#issuecomment-1874358079 From aivanov at openjdk.org Tue Jan 2 19:56:57 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 2 Jan 2024 19:56:57 GMT Subject: RFR: JDK-8320405: [Windows Server 2016] java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java shows issues in awt_Win32GraphicsDevice.cpp In-Reply-To: References: Message-ID: On Thu, 28 Dec 2023 09:48:52 GMT, Matthias Baesken wrote: > When running with fastdebug binaries we run intermittent into the issue below in > jtreg test java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java . > Seems we miss checking of successful HBITMAP creation before calling GetDIBits. > > HDC hBMDC = this->GetDC(); > HBITMAP hBM = ::CreateCompatibleBitmap(hBMDC, 1, 1); > VERIFY(::GetDIBits(hBMDC, hBM, 0, 1, NULL, gpBitmapInfo, DIB_RGB_COLORS)); > > in awt_Win32GraphicsDevice.cpp . Thats why the releast of hBMDC / hBM fails as well at the end of the function causing the seond and third warning. > > > Sat Nov 18 17:29:23 CET 2023 > > ********************* > AWT Assertion Failure > ********************* > ::GetDIBits(hBMDC, hBM, 0, 1, 0, gpBitmapInfo, 0) > File 'e:\openjdk\openjdk-21u-windows_x86_64-dbg\jdk\src\java.desktop\windows\native\libawt\windows\awt_Win32GraphicsDevice.cpp', at line 184 > GetLastError() is 57 : The parameter is incorrect. > > Do you want to break into the debugger? > ********************* > ********************* > AWT Assertion Failure > ********************* > ::DeleteObject(hBM) > File 'e:\openjdk\openjdk-21u-windows_x86_64-dbg\jdk\src\java.desktop\windows\native\libawt\windows\awt_Win32GraphicsDevice.cpp', at line 297 > GetLastError() is 57 : The parameter is incorrect. > > So it seems, we should have some additional checks/tracing. Is the purpose of this review to just add traces? The errors seems to come from *headless* environment. A better fix would be to add `@key headful` to the `MultiResolutionImageObserverTest.java` test, even though the test does not display UI. src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp line 142: > 140: } else { > 141: J2dTraceLn1(J2D_TRACE_WARNING, > 142: "CreateDC failed, so we cannot store the DC for later usage, mieInfo.szDevice is %S", Is `%S` a valid format string? It should in lower case: `%s`. It seems, ?store the DC for later usage? is misleading, it isn't stored? at least for a long period of time. src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp line 194: > 192: if (hBM == NULL) { > 193: J2dTraceLn(J2D_TRACE_WARNING, "AwtWin32GraphicsDevice::Initialize CreateCompatibleBitmap failed"); > 194: } Does it make sense to call `::GetLastError()` and trace its value? It seems that we cannot continue if `hBMDC` or `hBM` are null. Yet it seems unexpected. src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp line 309: > 307: } > 308: if (hBM != NULL) VERIFY(::DeleteObject(hBM)); > 309: if (hBMDC != NULL) VERIFY(::DeleteDC(hBMDC)); This should rather be expanded `if` statements with braces. ------------- PR Review: https://git.openjdk.org/jdk/pull/17197#pullrequestreview-1800910802 PR Review Comment: https://git.openjdk.org/jdk/pull/17197#discussion_r1439754392 PR Review Comment: https://git.openjdk.org/jdk/pull/17197#discussion_r1439757044 PR Review Comment: https://git.openjdk.org/jdk/pull/17197#discussion_r1439764934 From aivanov at openjdk.org Tue Jan 2 20:07:51 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 2 Jan 2024 20:07:51 GMT Subject: RFR: JDK-8320405: [Windows Server 2016] java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java shows issues in awt_Win32GraphicsDevice.cpp In-Reply-To: References: Message-ID: On Tue, 2 Jan 2024 19:37:53 GMT, Alexey Ivanov wrote: > It seems that we cannot continue if `hBMDC` or `hBM` are null. Yet it seems unexpected. Should we rather modify the code to back out and not to call APIs with NULL handles? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17197#discussion_r1439778065 From aivanov at openjdk.org Tue Jan 2 20:08:47 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 2 Jan 2024 20:08:47 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v7] In-Reply-To: References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> Message-ID: On Tue, 21 Nov 2023 03:33:21 GMT, Prasanta Sadhukhan wrote: >> javadoc contract for JComponent.setMinimumSize(Dimension) states: >> >> "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..." >> >> However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize() >> >> Fix is made to check if mnimumSize is set and if so, honour it.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Override set*Methods and update spec > > That is we preserve the current behaviour of `getMinimumSize()` and `getMaximumSize()` methods in `JScrollBar`, yet if `setMinimumSize()` or `setMaximumSize()` is called, the corresponding `get-` methods return the set value and thus they follow the contract specified in `JComponent`. > > @prrace, could you confirm, please? > > I already mentioned to him in this comment [#15325 (comment)](https://github.com/openjdk/jdk/pull/15325#issuecomment-1818768822) that moving back to initial fix iteration will cause the same problem as you mentioned [#15325 (comment)](https://github.com/openjdk/jdk/pull/15325#issuecomment-1796167220) which is the same what we observed when we removed these 2 getXXX methods (which was mentioned in hmuller comment) so if we are OK with the change in behaviour as compared to current, then removing these 2 methods may be considered as compared to moving to 1st iteration of this fix... Right. The change in behaviour will still be there. Personally, I think we should keep the current behaviour and document it. At the same time, I accept what Phil suggested: the behaviour remains the same unless `setMinimumSize()` or `setMaximumSize()` are called. The latter relies on [the assumptions](https://github.com/openjdk/jdk/pull/15325#issuecomment-1816933906): > I suspect very few apps actually call these since they are complete no-ops today. Phil notes: > If we do that, then yes, you'll still see differences if you do call those APIs and forgot about it because it didn't make a difference. Hence, there's a risk to break those few apps. This is why I prefer Phil's second suggestion: > If that isn't going to work, then, I think we should fall back to the pure documentation solution. > Well, almost pure docs, but not quite, because we need a no-op over-ride of `set*` on which to place the docs. This way, no app could be broken because the behaviour doesn't change, but the specification for `JScrollBar` changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15325#issuecomment-1874490256 From serb at openjdk.org Wed Jan 3 00:41:48 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 3 Jan 2024 00:41:48 GMT Subject: RFR: JDK-8320405: [Windows Server 2016] java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java shows issues in awt_Win32GraphicsDevice.cpp In-Reply-To: References: Message-ID: On Tue, 2 Jan 2024 20:04:39 GMT, Alexey Ivanov wrote: >> src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp line 194: >> >>> 192: if (hBM == NULL) { >>> 193: J2dTraceLn(J2D_TRACE_WARNING, "AwtWin32GraphicsDevice::Initialize CreateCompatibleBitmap failed"); >>> 194: } >> >> Does it make sense to call `::GetLastError()` and trace its value? >> >> It seems that we cannot continue if `hBMDC` or `hBM` are null. Yet it seems unexpected. > >> It seems that we cannot continue if `hBMDC` or `hBM` are null. Yet it seems unexpected. > > Should we rather modify the code to back out and not to call APIs with NULL handles? I think we should fallback to something. The bug itself looks similar to this: https://bugs.openjdk.org/browse/JDK-8185862 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17197#discussion_r1439981113 From rkannathpari at openjdk.org Wed Jan 3 03:45:06 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Wed, 3 Jan 2024 03:45:06 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v6] In-Reply-To: References: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> Message-ID: <8doF19-CcJAJ33FRt0PnKAUy2HOkZL1ddodJOgHT56A=.ae5ad0b8-77e2-498a-8803-e2b38439c08a@github.com> On Tue, 2 Jan 2024 05:29:35 GMT, Sergey Bylokhov wrote: >> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed unnecessary try block > > test/jdk/java/awt/color/NonICCFilterTest.java line 47: > >> 45: >> 46: protected TestColorSpace(boolean bSrc) { >> 47: super(CS_sRGB, 3); > > CS_sRGB is not a constant of the ColorSpace type, the ICC_Profile.getInstance(xx).getColorSpaceType() and profile.getNumComponents() should be used. Integrated this, please review > test/jdk/java/awt/color/NonICCFilterTest.java line 53: > >> 51: >> 52: public float[] toRGB(float[] colorvalue) { >> 53: return colorvalue; > > Just for completeness, it is probably better to use csRGB.toRGB and csRGB.fromRGB in these two methods Updated this ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1440043145 PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1440043507 From rkannathpari at openjdk.org Wed Jan 3 03:45:06 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Wed, 3 Jan 2024 03:45:06 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v7] In-Reply-To: References: Message-ID: > Hi Reviewers, > There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. > > Renjith. Renjith Kannath Pariyangad has updated the pull request incrementally with two additional commits since the last revision: - Copyright year updated - Review suggestions implemented ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16895/files - new: https://git.openjdk.org/jdk/pull/16895/files/fdc1ce8a..f73dbb98 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=05-06 Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/16895.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16895/head:pull/16895 PR: https://git.openjdk.org/jdk/pull/16895 From rkannathpari at openjdk.org Wed Jan 3 04:24:50 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Wed, 3 Jan 2024 04:24:50 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v6] In-Reply-To: References: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> Message-ID: On Tue, 2 Jan 2024 05:31:17 GMT, Sergey Bylokhov wrote: >> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed unnecessary try block > > test/jdk/java/awt/color/NonICCFilterTest.java line 109: > >> 107: throw new RuntimeException("Test failed: Source equal to Destination"); >> 108: } >> 109: } > > The "}" is missing in the latest version. oops, missed while integrating. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1440054991 From tr at openjdk.org Wed Jan 3 04:25:02 2024 From: tr at openjdk.org (Tejesh R) Date: Wed, 3 Jan 2024 04:25:02 GMT Subject: RFR: 8264102: JTable Keyboards Navigation differs with Test Instructions. Message-ID: Updated the actions for "ctrl shift DOWN" to "`selectLastRowExtendSelection`" and "ctrl shift UP", "`selectFirstRowExtendSelection`" in Basic and other Look and feel. Tested in CI and no regressions found. Test to be used - [javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java) ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/17236/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17236&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8264102 Stats: 16 lines in 8 files changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/17236.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17236/head:pull/17236 PR: https://git.openjdk.org/jdk/pull/17236 From psadhukhan at openjdk.org Wed Jan 3 05:33:04 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 3 Jan 2024 05:33:04 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v8] In-Reply-To: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> Message-ID: <4qlxE0k7KXnrw916s7DAGfYQbgLdrPmcSDfQdIRGTkw=.a21d1290-750f-4ae9-9f75-5f97ee2e8734@github.com> > javadoc contract for JComponent.setMinimumSize(Dimension) states: > > "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..." > > However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize() > > Fix is made to check if mnimumSize is set and if so, honour it.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Honour max/min size if set by user ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15325/files - new: https://git.openjdk.org/jdk/pull/15325/files/89aae1e2..0e4df2a1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15325&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15325&range=06-07 Stats: 11 lines in 1 file changed: 8 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15325/head:pull/15325 PR: https://git.openjdk.org/jdk/pull/15325 From psadhukhan at openjdk.org Wed Jan 3 05:33:04 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 3 Jan 2024 05:33:04 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v7] In-Reply-To: References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> Message-ID: On Tue, 21 Nov 2023 03:33:21 GMT, Prasanta Sadhukhan wrote: >> javadoc contract for JComponent.setMinimumSize(Dimension) states: >> >> "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..." >> >> However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize() >> >> Fix is made to check if mnimumSize is set and if so, honour it.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Override set*Methods and update spec OK..Updated PR to revive the 1st iteration of the fix to honour max/min size if set by user along with spec clarifications.. Hope this suffice... ------------- PR Comment: https://git.openjdk.org/jdk/pull/15325#issuecomment-1874869028 From mbaesken at openjdk.org Wed Jan 3 08:12:38 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 3 Jan 2024 08:12:38 GMT Subject: RFR: JDK-8320405: [Windows Server 2016] java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java shows issues in awt_Win32GraphicsDevice.cpp In-Reply-To: References: Message-ID: On Thu, 28 Dec 2023 09:48:52 GMT, Matthias Baesken wrote: > When running with fastdebug binaries we run intermittent into the issue below in > jtreg test java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java . > Seems we miss checking of successful HBITMAP creation before calling GetDIBits. > > HDC hBMDC = this->GetDC(); > HBITMAP hBM = ::CreateCompatibleBitmap(hBMDC, 1, 1); > VERIFY(::GetDIBits(hBMDC, hBM, 0, 1, NULL, gpBitmapInfo, DIB_RGB_COLORS)); > > in awt_Win32GraphicsDevice.cpp . Thats why the releast of hBMDC / hBM fails as well at the end of the function causing the seond and third warning. > > > Sat Nov 18 17:29:23 CET 2023 > > ********************* > AWT Assertion Failure > ********************* > ::GetDIBits(hBMDC, hBM, 0, 1, 0, gpBitmapInfo, 0) > File 'e:\openjdk\openjdk-21u-windows_x86_64-dbg\jdk\src\java.desktop\windows\native\libawt\windows\awt_Win32GraphicsDevice.cpp', at line 184 > GetLastError() is 57 : The parameter is incorrect. > > Do you want to break into the debugger? > ********************* > ********************* > AWT Assertion Failure > ********************* > ::DeleteObject(hBM) > File 'e:\openjdk\openjdk-21u-windows_x86_64-dbg\jdk\src\java.desktop\windows\native\libawt\windows\awt_Win32GraphicsDevice.cpp', at line 297 > GetLastError() is 57 : The parameter is incorrect. > > So it seems, we should have some additional checks/tracing. > Is the purpose of this review to just add traces? > > The errors seems to come from _headless_ environment. A better fix would be to add `@key headful` to the `MultiResolutionImageObserverTest.java` test, even though the test does not display UI. Hi Alexey, I am not against adding the key to the test, probably this makes sense. But still I think the coding itself should work better also in headless mode. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17197#issuecomment-1874983286 From mbaesken at openjdk.org Wed Jan 3 08:18:39 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 3 Jan 2024 08:18:39 GMT Subject: RFR: JDK-8320405: [Windows Server 2016] java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java shows issues in awt_Win32GraphicsDevice.cpp In-Reply-To: References: Message-ID: On Tue, 2 Jan 2024 19:33:44 GMT, Alexey Ivanov wrote: >> When running with fastdebug binaries we run intermittent into the issue below in >> jtreg test java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java . >> Seems we miss checking of successful HBITMAP creation before calling GetDIBits. >> >> HDC hBMDC = this->GetDC(); >> HBITMAP hBM = ::CreateCompatibleBitmap(hBMDC, 1, 1); >> VERIFY(::GetDIBits(hBMDC, hBM, 0, 1, NULL, gpBitmapInfo, DIB_RGB_COLORS)); >> >> in awt_Win32GraphicsDevice.cpp . Thats why the releast of hBMDC / hBM fails as well at the end of the function causing the seond and third warning. >> >> >> Sat Nov 18 17:29:23 CET 2023 >> >> ********************* >> AWT Assertion Failure >> ********************* >> ::GetDIBits(hBMDC, hBM, 0, 1, 0, gpBitmapInfo, 0) >> File 'e:\openjdk\openjdk-21u-windows_x86_64-dbg\jdk\src\java.desktop\windows\native\libawt\windows\awt_Win32GraphicsDevice.cpp', at line 184 >> GetLastError() is 57 : The parameter is incorrect. >> >> Do you want to break into the debugger? >> ********************* >> ********************* >> AWT Assertion Failure >> ********************* >> ::DeleteObject(hBM) >> File 'e:\openjdk\openjdk-21u-windows_x86_64-dbg\jdk\src\java.desktop\windows\native\libawt\windows\awt_Win32GraphicsDevice.cpp', at line 297 >> GetLastError() is 57 : The parameter is incorrect. >> >> So it seems, we should have some additional checks/tracing. > > src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp line 142: > >> 140: } else { >> 141: J2dTraceLn1(J2D_TRACE_WARNING, >> 142: "CreateDC failed, so we cannot store the DC for later usage, mieInfo.szDevice is %S", > > Is `%S` a valid format string? It should in lower case: `%s`. > > It seems, ?store the DC for later usage? is misleading, it isn't stored? at least for a long period of time. https://learn.microsoft.com/en-us/cpp/c-runtime-library/format-specification-syntax-printf-and-wprintf-functions?view=msvc-170 The %S is for wide chars, do you think we need the other one (%s) ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17197#discussion_r1440174314 From mbaesken at openjdk.org Wed Jan 3 11:47:54 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 3 Jan 2024 11:47:54 GMT Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified class name "java.util.Arrays" Message-ID: In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done. ------------- Commit messages: - JDK-8322782 Changes: https://git.openjdk.org/jdk/pull/17241/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17241&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322782 Stats: 19 lines in 8 files changed: 0 ins; 0 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/17241.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17241/head:pull/17241 PR: https://git.openjdk.org/jdk/pull/17241 From alanb at openjdk.org Wed Jan 3 13:32:38 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Jan 2024 13:32:38 GMT Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified class name "java.util.Arrays" In-Reply-To: References: Message-ID: <9oRf6_NeT3KKnkiZNAwUlcK6kBs13ahenPR1iWFfcb8=.ed953023-01bb-45d0-858e-daf5d4d52093@github.com> On Wed, 3 Jan 2024 11:41:20 GMT, Matthias Baesken wrote: > In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done. Looks fine, surprised to see so many. I assume you'll bump the copyright date on all the files before integrating. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17241#pullrequestreview-1802064657 From mbaesken at openjdk.org Wed Jan 3 13:51:03 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 3 Jan 2024 13:51:03 GMT Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified class name "java.util.Arrays" [v2] In-Reply-To: References: Message-ID: <7MyzckmpbHdkVKO-GM7_sEkpOtRCN7wf2dBe50P7ptE=.8764e79c-d68b-4737-a906-31dadf47c140@github.com> > In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust copyright date ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17241/files - new: https://git.openjdk.org/jdk/pull/17241/files/af1c0375..c06f35b5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17241&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17241&range=00-01 Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/17241.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17241/head:pull/17241 PR: https://git.openjdk.org/jdk/pull/17241 From mbaesken at openjdk.org Wed Jan 3 13:55:22 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 3 Jan 2024 13:55:22 GMT Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified class name "java.util.Arrays" [v3] In-Reply-To: References: Message-ID: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com> > In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust Invokers.java too ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17241/files - new: https://git.openjdk.org/jdk/pull/17241/files/c06f35b5..eac9ca69 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17241&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17241&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17241.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17241/head:pull/17241 PR: https://git.openjdk.org/jdk/pull/17241 From mbaesken at openjdk.org Wed Jan 3 14:04:48 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 3 Jan 2024 14:04:48 GMT Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified class name "java.util.Arrays" [v3] In-Reply-To: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com> References: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com> Message-ID: On Wed, 3 Jan 2024 13:55:22 GMT, Matthias Baesken wrote: >> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Invokers.java too Hi Alan, thanks for the review ! I adjust the copyright year info and also some more places in Invokers.java . ------------- PR Comment: https://git.openjdk.org/jdk/pull/17241#issuecomment-1875416193 From aivanov at openjdk.org Wed Jan 3 15:24:47 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 3 Jan 2024 15:24:47 GMT Subject: RFR: JDK-8320405: [Windows Server 2016] java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java shows issues in awt_Win32GraphicsDevice.cpp In-Reply-To: References: Message-ID: On Wed, 3 Jan 2024 00:38:19 GMT, Sergey Bylokhov wrote: > I think we should fallback to something. The bug itself looks similar to this: https://bugs.openjdk.org/browse/JDK-8185862 [JDK-8185862](https://bugs.openjdk.org/browse/JDK-8185862) seems to be the exact duplicate of this one. It references [JDK-8269529](https://bugs.openjdk.org/browse/JDK-8269529) which implemented [a workaround](https://github.com/openjdk/jdk/commit/d042029509a8cbdb723f78e2cfee4e2885775814#diff-fba4a205d0e60634be77d7a7f16a582277f7461d92a9c70cfb96d4a87068d0f1R36): https://github.com/openjdk/jdk/blob/d042029509a8cbdb723f78e2cfee4e2885775814/test/jdk/javax/swing/reliability/HangDuringStaticInitialization.java#L36 [The same workaround](https://github.com/openjdk/jdk/commit/5c083e8560ce9cc78615e3149a558206724cff53#diff-3b5e63f29c2a52feda881e4115e5d09d1b8aecd4698f1d72981de94caa3a46d0R50) was implemented for [JDK-8266129](https://bugs.openjdk.org/browse/JDK-8266129): https://github.com/openjdk/jdk/blob/5c083e8560ce9cc78615e3149a558206724cff53/test/jdk/tools/jpackage/windows/WinInstallerIconTest.java#L50 There's @prrace's comment [in the JBS](https://bugs.openjdk.org/browse/JDK-8266129?focusedId=14416854&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14416854): There's a bunch of AWT implementation missing to properly work headless. Random tests run into it. The tests should not have to deal with it. Instead it requires an unfunded effort to rework headless mode support in AWT and 2D. So, we can add `@requires !vm.debug` to the `MultiResolutionImageObserverTest.java` test or, better, handle the situation gracefully. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17197#discussion_r1440577143 From aivanov at openjdk.org Wed Jan 3 15:39:40 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 3 Jan 2024 15:39:40 GMT Subject: RFR: JDK-8320405: [Windows Server 2016] java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java shows issues in awt_Win32GraphicsDevice.cpp In-Reply-To: References: Message-ID: <2ZKWdemDZ7lxatijM7GPrGdGf8rE5kAROZrKHICui1Y=.1e0c86f2-a00b-4400-9873-aea76468adff@github.com> On Thu, 28 Dec 2023 09:48:52 GMT, Matthias Baesken wrote: > When running with fastdebug binaries we run intermittent into the issue below in > jtreg test java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java . > Seems we miss checking of successful HBITMAP creation before calling GetDIBits. > > HDC hBMDC = this->GetDC(); > HBITMAP hBM = ::CreateCompatibleBitmap(hBMDC, 1, 1); > VERIFY(::GetDIBits(hBMDC, hBM, 0, 1, NULL, gpBitmapInfo, DIB_RGB_COLORS)); > > in awt_Win32GraphicsDevice.cpp . Thats why the releast of hBMDC / hBM fails as well at the end of the function causing the seond and third warning. > > > Sat Nov 18 17:29:23 CET 2023 > > ********************* > AWT Assertion Failure > ********************* > ::GetDIBits(hBMDC, hBM, 0, 1, 0, gpBitmapInfo, 0) > File 'e:\openjdk\openjdk-21u-windows_x86_64-dbg\jdk\src\java.desktop\windows\native\libawt\windows\awt_Win32GraphicsDevice.cpp', at line 184 > GetLastError() is 57 : The parameter is incorrect. > > Do you want to break into the debugger? > ********************* > ********************* > AWT Assertion Failure > ********************* > ::DeleteObject(hBM) > File 'e:\openjdk\openjdk-21u-windows_x86_64-dbg\jdk\src\java.desktop\windows\native\libawt\windows\awt_Win32GraphicsDevice.cpp', at line 297 > GetLastError() is 57 : The parameter is incorrect. > > So it seems, we should have some additional checks/tracing. Hi Matthias, > But still I think the coding itself should work better also in headless mode. Then it should not only trace but fallback gracefully without calling APIs with the invalid parameters as discussed [in another thread](https://github.com/openjdk/jdk/pull/17197#discussion_r1439778065). The traces won't fix anything. According to the provided logs `hBMDC` is `NULL`, therefore `hBM` also becomes `NULL`, thus `::GetDIBits` also fails. There's already a workaround for [JDK-4684966](https://bugs.openjdk.org/browse/JDK-4684966): https://github.com/openjdk/jdk/blob/fb90af881badf143163c7d0b9961152c2a12cd84/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp#L195-L199 It should be extended to include the possible failure in the preceding call to `::GetDIBits`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17197#issuecomment-1875562325 From aivanov at openjdk.org Wed Jan 3 16:53:47 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 3 Jan 2024 16:53:47 GMT Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified class name "java.util.Arrays" [v3] In-Reply-To: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com> References: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com> Message-ID: On Wed, 3 Jan 2024 13:55:22 GMT, Matthias Baesken wrote: >> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Invokers.java too Looks good to me. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17241#pullrequestreview-1802684965 From aivanov at openjdk.org Wed Jan 3 16:59:46 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 3 Jan 2024 16:59:46 GMT Subject: RFR: JDK-8320405: [Windows Server 2016] java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java shows issues in awt_Win32GraphicsDevice.cpp In-Reply-To: References: Message-ID: On Wed, 3 Jan 2024 08:16:12 GMT, Matthias Baesken wrote: > https://learn.microsoft.com/en-us/cpp/c-runtime-library/format-specification-syntax-printf-and-wprintf-functions?view=msvc-170 The %S is for wide chars, do you think we need the other one (%s) ? You're right, it should be wide-char. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17197#discussion_r1440679674 From aivanov at openjdk.org Wed Jan 3 20:10:30 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 3 Jan 2024 20:10:30 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v7] In-Reply-To: References: Message-ID: <_gm-Utdk0aGY3B2jkYv58Tqj--Hm_nyDLmGDl5S7nWA=.f701d994-c052-496d-b5fa-9fc3d4f08bf6@github.com> On Wed, 3 Jan 2024 03:45:06 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. >> >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with two additional commits since the last revision: > > - Copyright year updated > - Review suggestions implemented Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java line 1: > 1: /* Please update the copyright year. test/jdk/java/awt/color/NonICCFilterTest.java line 38: > 36: * @test > 37: * @bug 8316497 > 38: * @summary Verifies Color filter on Non ICC profile Suggestion: * @summary Verifies Color filter on non-ICC profile test/jdk/java/awt/color/NonICCFilterTest.java line 51: > 49: csRGB = ColorSpace.getInstance(bSrc ? ColorSpace.CS_LINEAR_RGB : > 50: ColorSpace.CS_sRGB); > 51: } I propose to create a better wrapper: protected TestColorSpace(ColorSpace csRGB) { super(csRGB.getType(), csRGB.getNumComponents()); this.csRGB = csRGB; } You'll create the wrapper in a cleaner way: private static ColorSpace createColorSpace(boolean isSrc) { return new TestColorSpace(ColorSpace.getInstance(isSrc ? ColorSpace.CS_LINEAR_RGB : ColorSpace.CS_sRGB)); } test/jdk/java/awt/color/NonICCFilterTest.java line 53: > 51: } > 52: > 53: public float[] toRGB(float[] colorvalue) { Please add `@Override` annotations to the methods: `toRGB`, `fromRGB`, `toCIEXYZ`, `fromCIEXYZ`. test/jdk/java/awt/color/NonICCFilterTest.java line 55: > 53: public float[] toRGB(float[] colorvalue) { > 54: return colorvalue; > 55: } Suggestion: public float[] toRGB(float[] colorvalue) { return csRGB.toRGB(colorvalue); } This is what Sergey means. The comment applies to `fromRGB` method too. test/jdk/java/awt/color/NonICCFilterTest.java line 101: > 99: BufferedImage src, dest; > 100: src = createTestImage(true); > 101: dest = createTestImage(false); Declare variables at the same line where you initialise them: Suggestion: BufferedImage src = createTestImage(true); BufferedImage dest = createTestImage(false); Use `dst` as a more common abbreviation? ------------- PR Review: https://git.openjdk.org/jdk/pull/16895#pullrequestreview-1802942699 PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1440885046 PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1440842711 PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1440879982 PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1440886545 PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1440881611 PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1440883343 From aivanov at openjdk.org Wed Jan 3 20:10:32 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 3 Jan 2024 20:10:32 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v6] In-Reply-To: <8doF19-CcJAJ33FRt0PnKAUy2HOkZL1ddodJOgHT56A=.ae5ad0b8-77e2-498a-8803-e2b38439c08a@github.com> References: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> <8doF19-CcJAJ33FRt0PnKAUy2HOkZL1ddodJOgHT56A=.ae5ad0b8-77e2-498a-8803-e2b38439c08a@github.com> Message-ID: <6akE9WWZUu9ZHK5Drnv79JJTMvx9FAbfGYPCZTZ7ASE=.92a2a457-5a69-46fd-ba6c-e0a8085b4825@github.com> On Wed, 3 Jan 2024 03:42:35 GMT, Renjith Kannath Pariyangad wrote: >> test/jdk/java/awt/color/NonICCFilterTest.java line 53: >> >>> 51: >>> 52: public float[] toRGB(float[] colorvalue) { >>> 53: return colorvalue; >> >> Just for completeness, it is probably better to use csRGB.toRGB and csRGB.fromRGB in these two methods > > Updated this I agree with Sergey and I can't see any updates. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1440877582 From aivanov at openjdk.org Wed Jan 3 21:07:24 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 3 Jan 2024 21:07:24 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v6] In-Reply-To: <6akE9WWZUu9ZHK5Drnv79JJTMvx9FAbfGYPCZTZ7ASE=.92a2a457-5a69-46fd-ba6c-e0a8085b4825@github.com> References: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> <8doF19-CcJAJ33FRt0PnKAUy2HOkZL1ddodJOgHT56A=.ae5ad0b8-77e2-498a-8803-e2b38439c08a@github.com> <6akE9WWZUu9ZHK5Drnv79JJTMvx9FAbfGYPCZTZ7ASE=.92a2a457-5a69-46fd-ba6c-e0a8085b4825@github.com> Message-ID: <4553eVeRmo3q4n0NFkgLZpOfQOaRKWnuDNovobCAdFw=.a65e414c-8f12-40b3-8bcc-a87b71407fb7@github.com> On Wed, 3 Jan 2024 19:54:47 GMT, Alexey Ivanov wrote: >> Updated this > > I agree with Sergey and I can't see any updates. Hm? If modify the `toRGB` and `fromRGB` methods to use `csRGB` object, then the test does not fail without the fix. What's more interesting is that the images are equal before `filter` is applied. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1440948889 From rkannathpari at openjdk.org Thu Jan 4 04:45:22 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Thu, 4 Jan 2024 04:45:22 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v6] In-Reply-To: <4553eVeRmo3q4n0NFkgLZpOfQOaRKWnuDNovobCAdFw=.a65e414c-8f12-40b3-8bcc-a87b71407fb7@github.com> References: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> <8doF19-CcJAJ33FRt0PnKAUy2HOkZL1ddodJOgHT56A=.ae5ad0b8-77e2-498a-8803-e2b38439c08a@github.com> <6akE9WWZUu9ZHK5Drnv79JJTMvx9FAbfGYPCZTZ7ASE=.92a2a457-5a69-46fd-ba6c-e0a8085b4825@github.com> <4553eVeRmo3q4n0NFkgLZpOfQOaRKWnuDNovobCAdFw=.a65e414c-8f12-40b3-8bcc-a87b71407fb7@github.com> Message-ID: On Wed, 3 Jan 2024 21:04:50 GMT, Alexey Ivanov wrote: >> I agree with Sergey and I can't see any updates. > > Hm? If modify the `toRGB` and `fromRGB` methods to use `csRGB` object, then the test does not fail without the fix. > > What's more interesting is that the images are equal before `filter` is applied. @aivanov-jdk Thank you for clarifying, I thought he mean to modify `toCIEXYZ` and `fromCIEXYZ`. Yes if we modify `toRGB `and `fromRGB` then it will not pass through fixed area, So we may need to skip this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1441287458 From serb at openjdk.org Thu Jan 4 05:17:22 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 4 Jan 2024 05:17:22 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v6] In-Reply-To: References: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> <8doF19-CcJAJ33FRt0PnKAUy2HOkZL1ddodJOgHT56A=.ae5ad0b8-77e2-498a-8803-e2b38439c08a@github.com> <6akE9WWZUu9ZHK5Drnv79JJTMvx9FAbfGYPCZTZ7ASE=.92a2a457-5a69-46fd-ba6c-e0a8085b4825@github.com> <4553eVeRmo3q4n0NFkgLZpOfQOaRKWnuDNovobCAdFw=.a65e414c-8f12-40b3-8bcc-a87b71407fb7@github.com> Message-ID: On Thu, 4 Jan 2024 05:10:55 GMT, Sergey Bylokhov wrote: >> @aivanov-jdk Thank you for clarifying, I thought he mean to modify `toCIEXYZ` and `fromCIEXYZ`. Yes if we modify `toRGB `and `fromRGB` then it will not pass through fixed area, So we may need to skip this. > > The difference between srcColorSpace.fromCIEXYZ and dtsColorSpace.fromCIEXYZ can trigger an exception if both have different number of components, for example srcColorSpace = CS_GRAY and srcColorSpace.CS_sRGB =>ArrayIndexOutOfBoundsException will be triggered. > > > private static TestColorSpace createCS(boolean isSrc) { > ColorSpace cs = ColorSpace.getInstance( > isSrc ? ColorSpace.CS_GRAY : ColorSpace.CS_sRGB); > return new TestColorSpace(cs); > } > > public static void main(String[] args) { > BufferedImage src = createTestImage(true); > BufferedImage dest = createTestImage(false); > > ColorSpace mid = ColorSpace.getInstance(ColorSpace.CS_sRGB); > ColorConvertOp test = new ColorConvertOp(mid, null); > test.filter(src, dest); > } > > Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 1 > at java.desktop/java.awt.image.ColorConvertOp.nonICCBIFilter(ColorConvertOp.java:821) > at java.desktop/java.awt.image.ColorConvertOp.filter(ColorConvertOp.java:275) > at NonICCFilterTest.main(NonICCFilterTest.java:97) and instead of comparing that the images are just different, it is probably better to compare results of conversion via TestColorSpace wrapper vs ColorSpace w/o wrapper. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1441305407 From serb at openjdk.org Thu Jan 4 05:13:21 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 4 Jan 2024 05:13:21 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v6] In-Reply-To: References: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> <8doF19-CcJAJ33FRt0PnKAUy2HOkZL1ddodJOgHT56A=.ae5ad0b8-77e2-498a-8803-e2b38439c08a@github.com> <6akE9WWZUu9ZHK5Drnv79JJTMvx9FAbfGYPCZTZ7ASE=.92a2a457-5a69-46fd-ba6c-e0a8085b4825@github.com> <4553eVeRmo3q4n0NFkgLZpOfQOaRKWnuDNovobCAdFw=.a65e414c-8f12-40b3-8bcc-a87b71407fb7@github.com> Message-ID: On Thu, 4 Jan 2024 04:42:24 GMT, Renjith Kannath Pariyangad wrote: >> Hm? If modify the `toRGB` and `fromRGB` methods to use `csRGB` object, then the test does not fail without the fix. >> >> What's more interesting is that the images are equal before `filter` is applied. > > @aivanov-jdk Thank you for clarifying, I thought he mean to modify `toCIEXYZ` and `fromCIEXYZ`. Yes if we modify `toRGB `and `fromRGB` then it will not pass through fixed area, So we may need to skip this. The difference between srcColorSpace.fromCIEXYZ and dtsColorSpace.fromCIEXYZ can trigger an exception if both have different number of components, for example srcColorSpace = CS_GRAY and srcColorSpace.CS_sRGB =>ArrayIndexOutOfBoundsException will be triggered. private static TestColorSpace createCS(boolean isSrc) { ColorSpace cs = ColorSpace.getInstance( isSrc ? ColorSpace.CS_GRAY : ColorSpace.CS_sRGB); return new TestColorSpace(cs); } public static void main(String[] args) { BufferedImage src = createTestImage(true); BufferedImage dest = createTestImage(false); ColorSpace mid = ColorSpace.getInstance(ColorSpace.CS_sRGB); ColorConvertOp test = new ColorConvertOp(mid, null); test.filter(src, dest); } Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 1 at java.desktop/java.awt.image.ColorConvertOp.nonICCBIFilter(ColorConvertOp.java:821) at java.desktop/java.awt.image.ColorConvertOp.filter(ColorConvertOp.java:275) at NonICCFilterTest.main(NonICCFilterTest.java:97) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1441303144 From rkannathpari at openjdk.org Thu Jan 4 05:47:40 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Thu, 4 Jan 2024 05:47:40 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v8] In-Reply-To: References: Message-ID: <_EXrb-k5asE9yERLP8JiCquTnVNgaNeBH4nCobLmBEg=.93ee2b7d-b348-4c08-b82f-2e1b28384cc2@github.com> > Hi Reviewers, > There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. > > Renjith. Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Included the review suggesion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16895/files - new: https://git.openjdk.org/jdk/pull/16895/files/f73dbb98..9fc84de6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=06-07 Stats: 24 lines in 1 file changed: 10 ins; 2 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/16895.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16895/head:pull/16895 PR: https://git.openjdk.org/jdk/pull/16895 From serb at openjdk.org Thu Jan 4 05:56:22 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 4 Jan 2024 05:56:22 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v6] In-Reply-To: References: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> <8doF19-CcJAJ33FRt0PnKAUy2HOkZL1ddodJOgHT56A=.ae5ad0b8-77e2-498a-8803-e2b38439c08a@github.com> <6akE9WWZUu9ZHK5Drnv79JJTMvx9FAbfGYPCZTZ7ASE=.92a2a457-5a69-46fd-ba6c-e0a8085b4825@github.com> <4553eVeRmo3q4n0NFkgLZpOfQOaRKWnuDNovobCAdFw=.a65e414c-8f12-40b3-8bcc-a87b71407fb7@github.com> Message-ID: On Thu, 4 Jan 2024 05:15:05 GMT, Sergey Bylokhov wrote: >> The difference between srcColorSpace.fromCIEXYZ and dtsColorSpace.fromCIEXYZ can trigger an exception if both have different number of components, for example srcColorSpace = CS_GRAY and srcColorSpace.CS_sRGB =>ArrayIndexOutOfBoundsException will be triggered. >> >> >> private static TestColorSpace createCS(boolean isSrc) { >> ColorSpace cs = ColorSpace.getInstance( >> isSrc ? ColorSpace.CS_GRAY : ColorSpace.CS_sRGB); >> return new TestColorSpace(cs); >> } >> >> public static void main(String[] args) { >> BufferedImage src = createTestImage(true); >> BufferedImage dest = createTestImage(false); >> >> ColorSpace mid = ColorSpace.getInstance(ColorSpace.CS_sRGB); >> ColorConvertOp test = new ColorConvertOp(mid, null); >> test.filter(src, dest); >> } >> >> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 1 >> at java.desktop/java.awt.image.ColorConvertOp.nonICCBIFilter(ColorConvertOp.java:821) >> at java.desktop/java.awt.image.ColorConvertOp.filter(ColorConvertOp.java:275) >> at NonICCFilterTest.main(NonICCFilterTest.java:97) > > and instead of comparing that the images are just different, it is probably better to compare results of conversion via TestColorSpace wrapper vs ColorSpace w/o wrapper. Something like this: /* * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. * * This code is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * version 2 for more details (a copy is included in the LICENSE file that * accompanied this code). * * You should have received a copy of the GNU General Public License version * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. * * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA * or visit www.oracle.com if you need additional information or have any * questions. */ import java.awt.Color; import java.awt.GradientPaint; import java.awt.Graphics2D; 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; /* * @test * @bug 8316497 * @summary Verifies Color filter on Non ICC profile */ public final class NonICCFilterTest_123 { private static final class TestColorSpace extends ColorSpace { private final ColorSpace cs; TestColorSpace(ColorSpace cs) { super(cs.getType(), cs.getNumComponents()); this.cs = cs; } public float[] toRGB(float[] colorvalue) { return cs.toRGB(colorvalue); } public float[] fromRGB(float[] rgbvalue) { return cs.fromRGB(rgbvalue); } public float[] toCIEXYZ(float[] colorvalue) { return cs.toCIEXYZ(colorvalue); } public float[] fromCIEXYZ(float[] xyzvalue) { return cs.fromCIEXYZ(xyzvalue); } } private static BufferedImage createTestImage(boolean isSrc, boolean plain) { ColorSpace cs = createCS(isSrc, plain); ComponentColorModel cm = new ComponentColorModel(cs, false, false, Transparency.OPAQUE, DataBuffer.TYPE_BYTE); WritableRaster raster = cm.createCompatibleWritableRaster(100, 100); BufferedImage img = new BufferedImage(cm, raster, false, null); Graphics2D g = img.createGraphics(); GradientPaint gp = new GradientPaint(0, 0, Color.GREEN, raster.getWidth(), raster.getHeight(), Color.BLUE); g.setPaint(gp); g.fillRect(0, 0, raster.getWidth(), raster.getHeight()); g.dispose(); return img; } private static ColorSpace createCS(boolean isSrc, boolean plain) { ColorSpace cs = ColorSpace.getInstance( isSrc ? ColorSpace.CS_GRAY : ColorSpace.CS_sRGB); if (plain) { return cs; } return new TestColorSpace(cs); } private static boolean compareImages(BufferedImage destTest, BufferedImage destGold) { for (int x = 0; x < destTest.getWidth(); x++) { for (int y = 0; y < destTest.getHeight(); y++) { int rgb1 = destTest.getRGB(x, y); int rgb2 = destGold.getRGB(x, y); if (rgb1 != rgb2) { System.err.println("rgb1 = " + Integer.toHexString(rgb1)); System.err.println("rgb2 = " + Integer.toHexString(rgb2)); return true; } } } return false; } public static void main(String[] args) { BufferedImage srcTest = createTestImage(true, false); BufferedImage destTest = createTestImage(false, false); BufferedImage srcGold = createTestImage(true, true); BufferedImage destGold = createTestImage(false, true); ColorSpace mid = ColorSpace.getInstance(ColorSpace.CS_sRGB); ColorConvertOp test = new ColorConvertOp(mid, null); test.filter(srcTest, destTest); ColorConvertOp gold = new ColorConvertOp(mid, null); gold.filter(srcGold, destGold); if (compareImages(destTest, destGold)) { throw new RuntimeException("Test failed"); } } } Note that comparison at the end of the test fails, you can comment it out for now and create a separate bug -> looks like for the case above the results of out conversion is completely unexpected. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1441366764 From rkannathpari at openjdk.org Thu Jan 4 06:10:23 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Thu, 4 Jan 2024 06:10:23 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v6] In-Reply-To: References: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> <8doF19-CcJAJ33FRt0PnKAUy2HOkZL1ddodJOgHT56A=.ae5ad0b8-77e2-498a-8803-e2b38439c08a@github.com> <6akE9WWZUu9ZHK5Drnv79JJTMvx9FAbfGYPCZTZ7ASE=.92a2a457-5a69-46fd-ba6c-e0a8085b4825@github.com> <4553eVeRmo3q4n0NFkgLZpOfQOaRKWnuDNovobCAdFw=.a65e414c-8f12-40b3-8bcc-a87b71407fb7@github.com> Message-ID: On Thu, 4 Jan 2024 05:53:44 GMT, Sergey Bylokhov wrote: >> and instead of comparing that the images are just different, it is probably better to compare results of conversion via TestColorSpace wrapper vs ColorSpace w/o wrapper. > > Something like this: > > /* > * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > * under the terms of the GNU General Public License version 2 only, as > * published by the Free Software Foundation. > * > * This code is distributed in the hope that it will be useful, but WITHOUT > * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > * version 2 for more details (a copy is included in the LICENSE file that > * accompanied this code). > * > * You should have received a copy of the GNU General Public License version > * 2 along with this work; if not, write to the Free Software Foundation, > * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > * > * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > * or visit www.oracle.com if you need additional information or have any > * questions. > */ > > import java.awt.Color; > import java.awt.GradientPaint; > import java.awt.Graphics2D; > 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; > > /* > * @test > * @bug 8316497 > * @summary Verifies Color filter on Non ICC profile > */ > public final class NonICCFilterTest { > > private static final class TestColorSpace extends ColorSpace { > > private final ColorSpace cs; > > TestColorSpace(ColorSpace cs) { > super(cs.getType(), cs.getNumComponents()); > this.cs = cs; > } > > public float[] toRGB(float[] colorvalue) { > return cs.toRGB(colorvalue); > } > > public float[] fromRGB(float[] rgbvalue) { > return cs.fromRGB(rgbvalue); > } > > public float[] toCIEXYZ(float[] colorvalue) { > return cs.toCIEXYZ(colorvalue); > } > > public float[] fromCIEXYZ(float[] xyzvalue) { > return cs.fromCIEXYZ(xyzvalue); > } > } > > private static BufferedImage createTestImage(boolean isSrc, boolean plain) { > ColorSpace cs = createCS(isSrc, plain); > ComponentColorModel cm = new ComponentColorModel(cs, false, false, > Transparency.OPAQUE, DataBuffer.TYPE_BYTE); > WritableRaster raster = ... @mrserb, Thank you for bringing this up. Sorry I am not pretty clear about your suggestion on _Conversion via TestColorSpace wrapper vs ColorSpace w/o wrapper._ . In existing code `compareImages` (pixel value compare) function is local, are you suggesting to move this into wrapper? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1441374248 From serb at openjdk.org Thu Jan 4 06:17:22 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 4 Jan 2024 06:17:22 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v6] In-Reply-To: References: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> <8doF19-CcJAJ33FRt0PnKAUy2HOkZL1ddodJOgHT56A=.ae5ad0b8-77e2-498a-8803-e2b38439c08a@github.com> <6akE9WWZUu9ZHK5Drnv79JJTMvx9FAbfGYPCZTZ7ASE=.92a2a457-5a69-46fd-ba6c-e0a8085b4825@github.com> <4553eVeRmo3q4n0NFkgLZpOfQOaRKWnuDNovobCAdFw=.a65e414c-8f12-40b3-8bcc-a87b71407fb7@github.com> Message-ID: On Thu, 4 Jan 2024 06:08:00 GMT, Renjith Kannath Pariyangad wrote: >> Something like this: >> >> /* >> * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> * under the terms of the GNU General Public License version 2 only, as >> * published by the Free Software Foundation. >> * >> * This code is distributed in the hope that it will be useful, but WITHOUT >> * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or >> * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License >> * version 2 for more details (a copy is included in the LICENSE file that >> * accompanied this code). >> * >> * You should have received a copy of the GNU General Public License version >> * 2 along with this work; if not, write to the Free Software Foundation, >> * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >> * >> * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA >> * or visit www.oracle.com if you need additional information or have any >> * questions. >> */ >> >> import java.awt.Color; >> import java.awt.GradientPaint; >> import java.awt.Graphics2D; >> 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; >> >> /* >> * @test >> * @bug 8316497 >> * @summary Verifies Color filter on Non ICC profile >> */ >> public final class NonICCFilterTest { >> >> private static final class TestColorSpace extends ColorSpace { >> >> private final ColorSpace cs; >> >> TestColorSpace(ColorSpace cs) { >> super(cs.getType(), cs.getNumComponents()); >> this.cs = cs; >> } >> >> public float[] toRGB(float[] colorvalue) { >> return cs.toRGB(colorvalue); >> } >> >> public float[] fromRGB(float[] rgbvalue) { >> return cs.fromRGB(rgbvalue); >> } >> >> public float[] toCIEXYZ(float[] colorvalue) { >> return cs.toCIEXYZ(colorvalue); >> } >> >> public float[] fromCIEXYZ(float[] xyzvalue) { >> return cs.fromCIEXYZ(xyzvalue); >> } >> } >> >> private static BufferedImage createTestImage(boolean isSrc, boolean plain) { >> ColorSpace cs = createCS(isSrc, plain); >> ComponentColorM... > > @mrserb, Thank you for bringing this up. Sorry I am not pretty clear about your suggestion on _Conversion via TestColorSpace wrapper vs ColorSpace w/o wrapper._ . In existing code `compareImages` (pixel value compare) function is local, are you suggesting to move this into wrapper? Your `TestColorSpace` class is a wrapper on top of the actual color space. So you can compare the results of conversion using `TestColorSpace` vs using "actual color space" directly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1441377540 From psadhukhan at openjdk.org Thu Jan 4 07:46:15 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 4 Jan 2024 07:46:15 GMT Subject: RFR: 8322754: click JComboBox when dialog about to close causes IllegalComponentStateException Message-ID: Clicking to open a JComboBox popup during AWT event processing at the end of which the dialog will be closed causes an IllegalComponentStateException. Fix is made to check if combobox is showing before showing the popup to prevent the exception. ------------- Commit messages: - fix - 8322754: click JComboBox when dialog about to close causes IllegalComponentStateException - Merge remote-tracking branch 'upstream/master' - Merge remote-tracking branch 'upstream/master' - Merge remote-tracking branch 'upstream/master' - Merge remote-tracking branch 'upstream/master' - Merge - Merge branch 'master' of github.com:prsadhuk/jdk - Merge remote-tracking branch 'upstream/master' - Merge remote-tracking branch 'upstream/master' - ... and 2 more: https://git.openjdk.org/jdk/compare/fcf8368e...b50f63c8 Changes: https://git.openjdk.org/jdk/pull/17262/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17262&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322754 Stats: 94 lines in 2 files changed: 92 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17262.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17262/head:pull/17262 PR: https://git.openjdk.org/jdk/pull/17262 From mbaesken at openjdk.org Thu Jan 4 08:09:32 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 4 Jan 2024 08:09:32 GMT Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified class name "java.util.Arrays" [v3] In-Reply-To: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com> References: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com> Message-ID: On Wed, 3 Jan 2024 13:55:22 GMT, Matthias Baesken wrote: >> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Invokers.java too Hi Alexey, thanks for the review ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17241#issuecomment-1876673066 From mbaesken at openjdk.org Thu Jan 4 08:09:34 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 4 Jan 2024 08:09:34 GMT Subject: Integrated: JDK-8322782: Clean up usages of unnecessary fully qualified class name "java.util.Arrays" In-Reply-To: References: Message-ID: <3omokFt2Z2o6tspIqc14e1qKWtD9FygYKsoXsHjHnI0=.f649ef22-6972-4008-8df0-f5e0dec1038a@github.com> On Wed, 3 Jan 2024 11:41:20 GMT, Matthias Baesken wrote: > In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done. This pull request has now been integrated. Changeset: 1369c545 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/1369c545ac51d7b5ff623d486e28c939869fecb8 Stats: 29 lines in 9 files changed: 0 ins; 0 del; 29 mod 8322782: Clean up usages of unnecessary fully qualified class name "java.util.Arrays" Reviewed-by: alanb, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/17241 From rkannathpari at openjdk.org Thu Jan 4 08:58:20 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Thu, 4 Jan 2024 08:58:20 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v9] In-Reply-To: References: Message-ID: > Hi Reviewers, > There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. > > Renjith. Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Removed csRGB conversion call ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16895/files - new: https://git.openjdk.org/jdk/pull/16895/files/9fc84de6..dbfadbe4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16895.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16895/head:pull/16895 PR: https://git.openjdk.org/jdk/pull/16895 From abhiscxk at openjdk.org Thu Jan 4 11:44:21 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 4 Jan 2024 11:44:21 GMT Subject: RFR: 8322754: click JComboBox when dialog about to close causes IllegalComponentStateException In-Reply-To: References: Message-ID: On Thu, 4 Jan 2024 07:23:59 GMT, Prasanta Sadhukhan wrote: > Clicking to open a JComboBox popup during AWT event processing at the end of which the dialog will be closed causes an IllegalComponentStateException. > Fix is made to check if combobox is showing before showing the popup to prevent the exception. Verified the test. ------------- Marked as reviewed by abhiscxk (Committer). PR Review: https://git.openjdk.org/jdk/pull/17262#pullrequestreview-1803996229 From rkannathpari at openjdk.org Thu Jan 4 11:56:23 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Thu, 4 Jan 2024 11:56:23 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v6] In-Reply-To: References: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> <8doF19-CcJAJ33FRt0PnKAUy2HOkZL1ddodJOgHT56A=.ae5ad0b8-77e2-498a-8803-e2b38439c08a@github.com> <6akE9WWZUu9ZHK5Drnv79JJTMvx9FAbfGYPCZTZ7ASE=.92a2a457-5a69-46fd-ba6c-e0a8085b4825@github.com> <4553eVeRmo3q4n0NFkgLZpOfQOaRKWnuDNovobCAdFw=.a65e414c-8f12-40b3-8bcc-a87b71407fb7@github.com> Message-ID: On Thu, 4 Jan 2024 06:14:49 GMT, Sergey Bylokhov wrote: >> @mrserb, Thank you for bringing this up. Sorry I am not pretty clear about your suggestion on _Conversion via TestColorSpace wrapper vs ColorSpace w/o wrapper._ . In existing code `compareImages` (pixel value compare) function is local, are you suggesting to move this into wrapper? > > Your `TestColorSpace` class is a wrapper on top of the actual color space. So you can compare the results of conversion using `TestColorSpace` vs using "actual color space" directly. Thank you for sharing the detailed code, tried the above sample but its like Aleksei mentioned above _always passing irrespective of fix_. The fix area will pass only when non-ICC src and dst. Some of the color related function internally applying icc profile or other propertied and pass through other implementation. Not sure any other way to overcome this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1441659467 From aivanov at openjdk.org Thu Jan 4 12:35:36 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 4 Jan 2024 12:35:36 GMT Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java failed with 'Cannot invoke "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is null' In-Reply-To: <5oI1DxjQwGFXbXcRPM3cxdcRShLl7V38BstVpQ9k8to=.47da765f-b4e1-4c4b-a643-e317e902318d@github.com> References: <5oI1DxjQwGFXbXcRPM3cxdcRShLl7V38BstVpQ9k8to=.47da765f-b4e1-4c4b-a643-e317e902318d@github.com> Message-ID: On Tue, 2 Jan 2024 17:58:19 GMT, Alexey Ivanov wrote: > Thank you, Karl, for bringing the problem in this PR. It already exist in JBS as [JDK-8320692](https://bugs.openjdk.org/browse/JDK-8320692): _Cannot invoke java.awt.Image.getWidth(java.awt.image.ImageObserver)_. > > I added my observations there. The problem is likely applicable to other file types which have per-instance icons, however, these are uncommon with the exception of exe files. The suggested fix won't work, there should be an icon but we have to handle the fallback gracefully. @DevCharly Although the exception comes from the same code line, the root cause is different. In this PR, the problem was that a valid icon handle had been interpreted as invalid, thus a valid icon wasn't extracted. In case you reference, there's no icon to extract; I expect the shell to fallback to the default app icon automatically, but it doesn't happen, so we have to provide the fallback ourselves. It is a new case that hasn't been encountered before. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12010#issuecomment-1877024211 From rkannathpari at openjdk.org Thu Jan 4 13:05:42 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Thu, 4 Jan 2024 13:05:42 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v10] In-Reply-To: References: Message-ID: > Hi Reviewers, > There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. > > Renjith. Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Copyright year updated ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16895/files - new: https://git.openjdk.org/jdk/pull/16895/files/dbfadbe4..f6a435bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16895.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16895/head:pull/16895 PR: https://git.openjdk.org/jdk/pull/16895 From mbaesken at openjdk.org Thu Jan 4 14:42:14 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 4 Jan 2024 14:42:14 GMT Subject: RFR: JDK-8320405: [Windows Server 2016] java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java shows issues in awt_Win32GraphicsDevice.cpp [v2] In-Reply-To: References: Message-ID: > When running with fastdebug binaries we run intermittent into the issue below in > jtreg test java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java . > Seems we miss checking of successful HBITMAP creation before calling GetDIBits. > > HDC hBMDC = this->GetDC(); > HBITMAP hBM = ::CreateCompatibleBitmap(hBMDC, 1, 1); > VERIFY(::GetDIBits(hBMDC, hBM, 0, 1, NULL, gpBitmapInfo, DIB_RGB_COLORS)); > > in awt_Win32GraphicsDevice.cpp . Thats why the releast of hBMDC / hBM fails as well at the end of the function causing the seond and third warning. > > > Sat Nov 18 17:29:23 CET 2023 > > ********************* > AWT Assertion Failure > ********************* > ::GetDIBits(hBMDC, hBM, 0, 1, 0, gpBitmapInfo, 0) > File 'e:\openjdk\openjdk-21u-windows_x86_64-dbg\jdk\src\java.desktop\windows\native\libawt\windows\awt_Win32GraphicsDevice.cpp', at line 184 > GetLastError() is 57 : The parameter is incorrect. > > Do you want to break into the debugger? > ********************* > ********************* > AWT Assertion Failure > ********************* > ::DeleteObject(hBM) > File 'e:\openjdk\openjdk-21u-windows_x86_64-dbg\jdk\src\java.desktop\windows\native\libawt\windows\awt_Win32GraphicsDevice.cpp', at line 297 > GetLastError() is 57 : The parameter is incorrect. > > So it seems, we should have some additional checks/tracing. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: handle return value of other GetDIBits call, adjust if checks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17197/files - new: https://git.openjdk.org/jdk/pull/17197/files/cfc9088e..2e0d83f1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17197&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17197&range=00-01 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/17197.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17197/head:pull/17197 PR: https://git.openjdk.org/jdk/pull/17197 From mbaesken at openjdk.org Thu Jan 4 14:43:21 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 4 Jan 2024 14:43:21 GMT Subject: RFR: JDK-8320405: [Windows Server 2016] java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java shows issues in awt_Win32GraphicsDevice.cpp In-Reply-To: <2ZKWdemDZ7lxatijM7GPrGdGf8rE5kAROZrKHICui1Y=.1e0c86f2-a00b-4400-9873-aea76468adff@github.com> References: <2ZKWdemDZ7lxatijM7GPrGdGf8rE5kAROZrKHICui1Y=.1e0c86f2-a00b-4400-9873-aea76468adff@github.com> Message-ID: On Wed, 3 Jan 2024 15:36:16 GMT, Alexey Ivanov wrote: > It should be extended to include the possible failure in the preceding call to ::GetDIBits. I handle now also a failure of the first GetDIBits call; and also added braces at the if's mentioned. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17197#issuecomment-1877205475 From aivanov at openjdk.org Thu Jan 4 17:06:27 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 4 Jan 2024 17:06:27 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v6] In-Reply-To: References: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> <8doF19-CcJAJ33FRt0PnKAUy2HOkZL1ddodJOgHT56A=.ae5ad0b8-77e2-498a-8803-e2b38439c08a@github.com> <6akE9WWZUu9ZHK5Drnv79JJTMvx9FAbfGYPCZTZ7ASE=.92a2a457-5a69-46fd-ba6c-e0a8085b4825@github.com> <4553eVeRmo3q4n0NFkgLZpOfQOaRKWnuDNovobCAdFw=.a65e414c-8f12-40b3-8bcc-a87b71407fb7@github.com> Message-ID: On Thu, 4 Jan 2024 06:14:49 GMT, Sergey Bylokhov wrote: >> @mrserb, Thank you for bringing this up. Sorry I am not pretty clear about your suggestion on _Conversion via TestColorSpace wrapper vs ColorSpace w/o wrapper._ . In existing code `compareImages` (pixel value compare) function is local, are you suggesting to move this into wrapper? > > Your `TestColorSpace` class is a wrapper on top of the actual color space. So you can compare the results of conversion using `TestColorSpace` vs using "actual color space" directly. @mrserb With your code above, I get `ArrayIndexOutOfBoundsException`. Do you mean to say there are two additional bugs? 1. `ArrayIndexOutOfBoundsException` is thrown; 2. Even regular ICC_Profile result in unexpected behaviour. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1442039232 From aivanov at openjdk.org Thu Jan 4 17:06:25 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 4 Jan 2024 17:06:25 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v6] In-Reply-To: References: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> <8doF19-CcJAJ33FRt0PnKAUy2HOkZL1ddodJOgHT56A=.ae5ad0b8-77e2-498a-8803-e2b38439c08a@github.com> <6akE9WWZUu9ZHK5Drnv79JJTMvx9FAbfGYPCZTZ7ASE=.92a2a457-5a69-46fd-ba6c-e0a8085b4825@github.com> <4553eVeRmo3q4n0NFkgLZpOfQOaRKWnuDNovobCAdFw=.a65e414c-8f12-40b3-8bcc-a87b71407fb7@github.com> Message-ID: <-UkbhKJjMWz7BbxSim1qiITB3sZcslpFdEKA3RleCYY=.d1eea076-d9fd-4c8e-8121-abb2788de90d@github.com> On Thu, 4 Jan 2024 11:53:19 GMT, Renjith Kannath Pariyangad wrote: >> Your `TestColorSpace` class is a wrapper on top of the actual color space. So you can compare the results of conversion using `TestColorSpace` vs using "actual color space" directly. > > Thank you for sharing the detailed code, tried the above sample but its like Aleksei mentioned above _always passing irrespective of fix_. The fix area will pass only when non-ICC src and dst. Some of the color related function internally applying icc profile or other propertied and pass through other implementation. Not sure any other way to overcome this. I thought about it? I thought that the filter itself should exercise the code path that's modified but it doesn't seem like it does? I mean creating images with regular ICC profile and using the wrapper `TestColorSpace` in conversion: `new ColorConvertOp(new TestColorSpace(ColorSpace.getInstance(CS_LINEAR_RGB), null);` but it didn't work, the test passes without the fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1442035800 From aivanov at openjdk.org Thu Jan 4 17:12:25 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 4 Jan 2024 17:12:25 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v10] In-Reply-To: References: Message-ID: On Thu, 4 Jan 2024 13:05:42 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. >> >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Copyright year updated It looks good to me. The current test fails without the fix in `ColorConvertOp` and passes with the fix. Thus, the current bug is fixed and the regression test does its job. It's good that further bugs have been identified, these are to be submitted and then fixed. When the bugs are fixed, the test may be modified to test other conditions, provided it still verifies this changeset. test/jdk/java/awt/color/NonICCFilterTest.java line 108: > 106: public static void main(String[] args) { > 107: > 108: BufferedImage src = createTestImage(true); Suggestion: public static void main(String[] args) { BufferedImage src = createTestImage(true); Remove the blank line at the start of the `main` method. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16895#pullrequestreview-1804631569 PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1442041375 From serb at openjdk.org Thu Jan 4 17:57:23 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 4 Jan 2024 17:57:23 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v6] In-Reply-To: References: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> <8doF19-CcJAJ33FRt0PnKAUy2HOkZL1ddodJOgHT56A=.ae5ad0b8-77e2-498a-8803-e2b38439c08a@github.com> <6akE9WWZUu9ZHK5Drnv79JJTMvx9FAbfGYPCZTZ7ASE=.92a2a457-5a69-46fd-ba6c-e0a8085b4825@github.com> <4553eVeRmo3q4n0NFkgLZpOfQOaRKWnuDNovobCAdFw=.a65e414c-8f12-40b3-8bcc-a87b71407fb7@github.com> Message-ID: On Thu, 4 Jan 2024 17:04:01 GMT, Alexey Ivanov wrote: >> Your `TestColorSpace` class is a wrapper on top of the actual color space. So you can compare the results of conversion using `TestColorSpace` vs using "actual color space" directly. > > @mrserb With your code above, I get `ArrayIndexOutOfBoundsException`. > > Do you mean to say there are two additional bugs? > > 1. `ArrayIndexOutOfBoundsException` is thrown; > 2. Even regular ICC_Profile result in unexpected behaviour. The ArrayIndexOutOfBoundsException is the bug we are working on in this PR. The "unexpected behavior" we get when we use the TestColorSpace instead of direct usage of built-in profiles - it looks like the codepath we updated has some other bug that affects the rendering results. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1442087244 From serb at openjdk.org Thu Jan 4 18:07:23 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 4 Jan 2024 18:07:23 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v6] In-Reply-To: References: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> <8doF19-CcJAJ33FRt0PnKAUy2HOkZL1ddodJOgHT56A=.ae5ad0b8-77e2-498a-8803-e2b38439c08a@github.com> <6akE9WWZUu9ZHK5Drnv79JJTMvx9FAbfGYPCZTZ7ASE=.92a2a457-5a69-46fd-ba6c-e0a8085b4825@github.com> <4553eVeRmo3q4n0NFkgLZpOfQOaRKWnuDNovobCAdFw=.a65e414c-8f12-40b3-8bcc-a87b71407fb7@github.com> Message-ID: On Thu, 4 Jan 2024 17:54:10 GMT, Sergey Bylokhov wrote: >> @mrserb With your code above, I get `ArrayIndexOutOfBoundsException`. >> >> Do you mean to say there are two additional bugs? >> >> 1. `ArrayIndexOutOfBoundsException` is thrown; >> 2. Even regular ICC_Profile result in unexpected behaviour. > > The ArrayIndexOutOfBoundsException is the bug we are working on in this PR. The "unexpected behavior" we get when we use the TestColorSpace instead of direct usage of built-in profiles - it looks like the codepath we updated has some other bug that affects the rendering results. >I thought about it? I thought that the filter itself should exercise the code path that's modified but it doesn't seem like it does? I mean creating images with regular ICC profile and using the wrapper TestColorSpace in conversion: new ColorConvertOp(new TestColorSpace(ColorSpace.getInstance(CS_LINEAR_RGB), null); but it didn't work, the test passes without the fix. It is passed since it blindly checks the difference between src and dst, and since with proper implementation of TestColorSpacewe we always do "some" conversion -> the images are different -> the test passed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1442096879 From aivanov at openjdk.org Thu Jan 4 18:40:24 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 4 Jan 2024 18:40:24 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v6] In-Reply-To: References: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> <8doF19-CcJAJ33FRt0PnKAUy2HOkZL1ddodJOgHT56A=.ae5ad0b8-77e2-498a-8803-e2b38439c08a@github.com> <6akE9WWZUu9ZHK5Drnv79JJTMvx9FAbfGYPCZTZ7ASE=.92a2a457-5a69-46fd-ba6c-e0a8085b4825@github.com> <4553eVeRmo3q4n0NFkgLZpOfQOaRKWnuDNovobCAdFw=.a65e414c-8f12-40b3-8bcc-a87b71407fb7@github.com> Message-ID: On Thu, 4 Jan 2024 18:04:59 GMT, Sergey Bylokhov wrote: > > I thought about it? I thought that the filter itself should exercise the code path that's modified but it doesn't seem like it does? I mean creating images with regular ICC profile and using the wrapper TestColorSpace in conversion: new ColorConvertOp(new TestColorSpace(ColorSpace.getInstance(CS_LINEAR_RGB), null); but it didn't work, the test passes without the fix. > > It is passed since it blindly checks the difference between src and dst, and since with proper implementation of TestColorSpacewe we always do "some" conversion -> the images are different -> the test passed. Still, the current test catches the typo in the code `srcColorSpace` ? `dstColorSpace` that's now replaced. From this point view, the stated bug is fixed. At the same time, I agree there seem to be more bugs in the area. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1442124080 From serb at openjdk.org Thu Jan 4 19:00:27 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 4 Jan 2024 19:00:27 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v6] In-Reply-To: References: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> <8doF19-CcJAJ33FRt0PnKAUy2HOkZL1ddodJOgHT56A=.ae5ad0b8-77e2-498a-8803-e2b38439c08a@github.com> <6akE9WWZUu9ZHK5Drnv79JJTMvx9FAbfGYPCZTZ7ASE=.92a2a457-5a69-46fd-ba6c-e0a8085b4825@github.com> <4553eVeRmo3q4n0NFkgLZpOfQOaRKWnuDNovobCAdFw=.a65e414c-8f12-40b3-8bcc-a87b71407fb7@github.com> Message-ID: On Thu, 4 Jan 2024 18:37:54 GMT, Alexey Ivanov wrote: > Still, the current test catches the typo in the code srcColorSpace ? dstColorSpace that's now replaced. From this point view, the stated bug is fixed. But the implementation of TestColorSpacewe is wrong, and it may not work as expected after any other future updates. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1442142789 From serb at openjdk.org Fri Jan 5 03:34:26 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 5 Jan 2024 03:34:26 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v6] In-Reply-To: References: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> <8doF19-CcJAJ33FRt0PnKAUy2HOkZL1ddodJOgHT56A=.ae5ad0b8-77e2-498a-8803-e2b38439c08a@github.com> <6akE9WWZUu9ZHK5Drnv79JJTMvx9FAbfGYPCZTZ7ASE=.92a2a457-5a69-46fd-ba6c-e0a8085b4825@github.com> <4553eVeRmo3q4n0NFkgLZpOfQOaRKWnuDNovobCAdFw=.a65e414c-8f12-40b3-8bcc-a87b71407fb7@github.com> Message-ID: On Thu, 4 Jan 2024 18:58:02 GMT, Sergey Bylokhov wrote: >>> > I thought about it? I thought that the filter itself should exercise the code path that's modified but it doesn't seem like it does? I mean creating images with regular ICC profile and using the wrapper TestColorSpace in conversion: new ColorConvertOp(new TestColorSpace(ColorSpace.getInstance(CS_LINEAR_RGB), null); but it didn't work, the test passes without the fix. >>> >>> It is passed since it blindly checks the difference between src and dst, and since with proper implementation of TestColorSpacewe we always do "some" conversion -> the images are different -> the test passed. >> >> Still, the current test catches the typo in the code `srcColorSpace` ? `dstColorSpace` that's now replaced. From this point view, the stated bug is fixed. >> >> At the same time, I agree there seem to be more bugs in the area. > >> Still, the current test catches the typo in the code srcColorSpace ? dstColorSpace that's now replaced. From this point view, the stated bug is fixed. > > But the implementation of TestColorSpacewe is wrong, and it may not work as expected after any other future updates. There are at least two similar copy/paste typos. In the next line https://github.com/openjdk/jdk/blob/f73dbb985823d2d59bfcff8ba6951a0d9eb2cefc/src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java#L771 we use the srcNumComp which is the number of components for the incoming source color space, but the loop should be done over iccSrcNumComp which is a number of components of the "intermidiate" source color space. Similar issue is in the next line but for the destination https://github.com/openjdk/jdk/blob/f73dbb985823d2d59bfcff8ba6951a0d9eb2cefc/src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java#L785 It is possible that these compensate/affects each other and produce some non-completly broken result. The test from the comment above start to pass after these will be fixed. Since we found a few bugs in this code path, it will be useful to check the code path in the nonICCBIFilter where the CSList is not null(the intermidiate transform is wrapper as well, as of now our test uses the built-in ColorSpace.getInstance(CS_sRGB)) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1442465871 From psadhukhan at openjdk.org Fri Jan 5 05:21:26 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 5 Jan 2024 05:21:26 GMT Subject: RFR: 8264102: JTable Keyboards Navigation differs with Test Instructions. In-Reply-To: References: Message-ID: On Wed, 3 Jan 2024 04:20:44 GMT, Tejesh R wrote: > Updated the actions for "ctrl shift DOWN" to "`selectLastRowExtendSelection`" and "ctrl shift UP", "`selectFirstRowExtendSelection`" in Basic and other Look and feel. Tested in CI and no regressions found. > Test to be used - [javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java) It is definitely required for Windows L&F as excel also has same functionality for CTRL+SHIFT+UP/DOWN but I amnot sure if spec mandates it for all L&F...Did you see anywhere in spec that ctrl shift up/down should select all populated cells in the column. Please check in linux and macos if native spreadsheet has same functionality, if not restrict it to Windows only... Also, add bugid to the existing jtreg test...it may be recommended to modify the deprecated applet based test, since you are relying on that test to test this fix, to normal manual PassFailJFrame based test ------------- PR Comment: https://git.openjdk.org/jdk/pull/17236#issuecomment-1878139363 From tr at openjdk.org Fri Jan 5 06:06:30 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 5 Jan 2024 06:06:30 GMT Subject: RFR: 8264102: JTable Keyboards Navigation differs with Test Instructions. In-Reply-To: References: Message-ID: <9AnIu_dL5VeaMMqRqPjVOSUFSK7uJGMkuT8bF9KD-Lg=.70ba6b7b-8ed8-49eb-af86-320619fd1f2f@github.com> On Fri, 5 Jan 2024 05:18:37 GMT, Prasanta Sadhukhan wrote: > It is definitely required for Windows L&F as excel also has same functionality for CTRL+SHIFT+UP/DOWN but I amnot sure if spec mandates it for all L&F...Did you see anywhere in spec that ctrl shift up/down should select all populated cells in the column. Please check in linux and macos if native spreadsheet has same functionality, if not restrict it to Windows only... > > Also, add bugid to the existing jtreg test...it may be recommended to modify the deprecated applet based test, since you are relying on that test to test this fix, to normal manual PassFailJFrame based test I couldn't trace out to the spec and same functionality is seen in linux and macos too.. Sure update the test too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17236#issuecomment-1878170502 From tr at openjdk.org Fri Jan 5 07:31:46 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 5 Jan 2024 07:31:46 GMT Subject: RFR: 8264102: JTable Keyboards Navigation differs with Test Instructions. [v2] In-Reply-To: References: Message-ID: > Updated the actions for "ctrl shift DOWN" to "`selectLastRowExtendSelection`" and "ctrl shift UP", "`selectFirstRowExtendSelection`" in Basic and other Look and feel. Tested in CI and no regressions found. > Test to be used - [javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java) Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Review Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17236/files - new: https://git.openjdk.org/jdk/pull/17236/files/249e39c4..67fdf399 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17236&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17236&range=00-01 Stats: 417 lines in 3 files changed: 204 ins; 213 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17236.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17236/head:pull/17236 PR: https://git.openjdk.org/jdk/pull/17236 From mbaesken at openjdk.org Fri Jan 5 09:28:21 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 5 Jan 2024 09:28:21 GMT Subject: RFR: JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows In-Reply-To: <5x-CDbd8ujYRMOO46Emn8ybYsqfkipVoHBnFylB1DTE=.fdc27846-0928-4901-84cc-98937c76e7d1@github.com> References: <5x-CDbd8ujYRMOO46Emn8ybYsqfkipVoHBnFylB1DTE=.fdc27846-0928-4901-84cc-98937c76e7d1@github.com> Message-ID: On Tue, 2 Jan 2024 15:03:12 GMT, Matthias Baesken wrote: > The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni , and shows on Windows server 2019 the following JNI warning , so the test fails on this Windows version. > > stdout: [WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV > at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 23-internal/Native Method) > at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 23-internal/Win32GraphicsEnvironment.java:95) > at sun.awt.Win32GraphicsEnvironment.(java.desktop at 23-internal/Win32GraphicsEnvironment.java:63) > at sun.awt.PlatformGraphicsInfo.createGE(java.desktop at 23-internal/PlatformGraphicsInfo.java:34) > at java.awt.GraphicsEnvironment$LocalGE.createGE(java.desktop at 23-internal/GraphicsEnvironment.java:93) > at java.awt.GraphicsEnvironment$LocalGE.(java.desktop at 23-internal/GraphicsEnvironment.java:84) > at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(java.desktop at 23-internal/GraphicsEnvironment.java:106) > at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) > at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44) > > > We better add an exception check to get rid of the JNI warning (and also of the test failure) . Would be nice to get a review, the removed warning message leads to at least -1 failing test in our CI on Windows . ------------- PR Comment: https://git.openjdk.org/jdk/pull/17224#issuecomment-1878366512 From rkannathpari at openjdk.org Fri Jan 5 12:03:43 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Fri, 5 Jan 2024 12:03:43 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v11] In-Reply-To: References: Message-ID: <2pMaJWrb3fKl4nnOpDnLXX89tts9PadkPzJkqfgZxw4=.e168b349-3a53-4333-bfe2-a545d19ea3d5@github.com> > Hi Reviewers, > There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. > > Renjith. Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Removed unwanted converion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16895/files - new: https://git.openjdk.org/jdk/pull/16895/files/f6a435bc..56ce5c5e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=09-10 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16895.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16895/head:pull/16895 PR: https://git.openjdk.org/jdk/pull/16895 From perini.davide at dpsoftware.org Fri Jan 5 12:41:05 2024 From: perini.davide at dpsoftware.org (Davide Perini) Date: Fri, 5 Jan 2024 13:41:05 +0100 Subject: Windows 11: Notifications vanishes after few seconds. Message-ID: With previous version of Windows and JDK notification sticked in the Windows Notification Center forever until cancelled. Since the latest Windows/JDK, notifications vanishes automatically after few seconds. ### Code to reproduce the problem ``` import java.awt.*; public class Main { ??? public static void main(String[] args) throws Exception { ??????? SystemTray tray = SystemTray.getSystemTray(); ??????? Image image = Toolkit.getDefaultToolkit().createImage(""); ??????? TrayIcon trayIcon = new TrayIcon(image); ??????? trayIcon.setImageAutoSize(true); ??????? trayIcon.setToolTip("Demo"); ??????? tray.add(trayIcon); ??????? trayIcon.displayMessage("Hello, World", "notification demo", TrayIcon.MessageType.INFO); ??? } } ``` ### Expected Results Notifications sent from a TrayIcon should not vanish automatically after few seconds but should stay in the notification center until cancelled by the user. ### Actual Results Notifications sent from a TrayIcon vanishes automatically after few seconds ### What Java Version are you using? 21.0.1 ### What is your operating system and platform? Windows 11 Is there a way to workaround this JDK bug? I opened a bug report months ago but no one answered. Thanks Davide From rkannathpari at openjdk.org Fri Jan 5 13:21:29 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Fri, 5 Jan 2024 13:21:29 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v6] In-Reply-To: References: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> <8doF19-CcJAJ33FRt0PnKAUy2HOkZL1ddodJOgHT56A=.ae5ad0b8-77e2-498a-8803-e2b38439c08a@github.com> <6akE9WWZUu9ZHK5Drnv79JJTMvx9FAbfGYPCZTZ7ASE=.92a2a457-5a69-46fd-ba6c-e0a8085b4825@github.com> <4553eVeRmo3q4n0NFkgLZpOfQOaRKWnuDNovobCAdFw=.a65e414c-8f12-40b3-8bcc-a87b71407fb7@github.com> Message-ID: On Fri, 5 Jan 2024 03:32:10 GMT, Sergey Bylokhov wrote: >>> Still, the current test catches the typo in the code srcColorSpace ? dstColorSpace that's now replaced. From this point view, the stated bug is fixed. >> >> But the implementation of TestColorSpacewe is wrong, and it may not work as expected after any other future updates. > > There are at least two similar copy/paste typos. > In the next line https://github.com/openjdk/jdk/blob/f73dbb985823d2d59bfcff8ba6951a0d9eb2cefc/src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java#L771 we use the srcNumComp which is the number of components for the incoming source color space, but the loop should be done over iccSrcNumComp which is a number of components of the "intermidiate" source color space. Similar issue is in the next line but for the destination https://github.com/openjdk/jdk/blob/f73dbb985823d2d59bfcff8ba6951a0d9eb2cefc/src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java#L785 > > It is possible that these compensate/affects each other and produce some non-completly broken result. > The test from the comment above start to pass after these will be fixed. > > Since we found a few bugs in this code path, it will be useful to check the code path in the nonICCBIFilter where the CSList is not null(the intermidiate transform is wrapper as well, as of now our test uses the built-in ColorSpace.getInstance(CS_sRGB)) @mrserb for avoiding _ArrayIndexOutOfBoundsException_ I have modified `CS_GRAY `with `CS_LINEAR_RGB ` for making same number of channels. But the test passed irrespective of fix. Do you find any alternative way to fail the test with out fix ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1442869387 From kevin.rushforth at oracle.com Fri Jan 5 13:40:14 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 5 Jan 2024 05:40:14 -0800 Subject: The font module does not work well with fontconfig on Linux. In-Reply-To: References: Message-ID: <604a38f9-ebee-4256-a5e6-88abf6e68dc5@oracle.com> This is not the right mailing list to discuss problems in specific components. I'm redirecting this to client-libs-dev. -- Kevin On 1/4/2024 9:13 PM, ?kurn wrote: > Here are the problems I found, and here is a patch that may fix them. > > 1. The font manager uses the default logical?font as the fallback font. > On Linux systems, we can use fontconfig to get a matching list of fonts. > So, I added a new fallback method, FONTCONFIGURATION_FALLBACK, and > implemented it for Linux systems using fontconfig. > > 2. The FileFont object have no fallback?ability when rendering. > I make the FileFont class implement the FontSubstitution interface and > reuse the fallback method?on first. > This enhances text display on Linux systems that frequently use > FileFont objects, reduce the inability to display characters in > multiple languages when using physical fonts. > > I know my patch?still requires improvement, and I haven't adapted it > for Windows and Mac. But I hope this will lead to further discussion, > eventually?we can improve these problems. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aivanov at openjdk.org Fri Jan 5 15:52:24 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 5 Jan 2024 15:52:24 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v11] In-Reply-To: <2pMaJWrb3fKl4nnOpDnLXX89tts9PadkPzJkqfgZxw4=.e168b349-3a53-4333-bfe2-a545d19ea3d5@github.com> References: <2pMaJWrb3fKl4nnOpDnLXX89tts9PadkPzJkqfgZxw4=.e168b349-3a53-4333-bfe2-a545d19ea3d5@github.com> Message-ID: On Fri, 5 Jan 2024 12:03:43 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. >> >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Removed unwanted converion I've been thinking about it more, and I agree with Sergey. There are two types of `ColorSpace`s: ICC and non-ICC. The `TestColorSpace` is a wrapper on top of an `ICC_ColorSpace` (with Sergey's implementation that forwards all the method calls to its wrapped `ColorSpace` instance stored in the `cs` field. The expectation is that using the same ColorSpace result in the same output. We ? _Sergey_ ? do just that. 1. Take two images with an `ICC_ColorSpace` and transform them. 2. Take another pair of images with the wrapped `ICC_ColorSpace` and transform them. The result of the transformation must be the same, right? It's a better test. I've created [`renjith/sergey-8316497-colorConvertOp`](https://github.com/aivanov-jdk/jdk/tree/renjith/sergey-8316497-colorConvertOp) branch. It's based on Renjith's `[8316497-v1](https://github.com/Renjithkannath/jdk/tree/8316497-v1)` which corresponds to this PR. Sergey's code from [his comment](https://github.com/openjdk/jdk/pull/16895#discussion_r1441366764) above is available as [commit `ac6b10f`](https://github.com/aivanov-jdk/jdk/commit/ac6b10fa82e64934b46a642ad9a87d64d80affbf). I refactored it by introducing an enum for selecting the `ColorSpace`, it makes it easier to understand which `ColorSpace` is created. I modified `createTestImage` to accept a `ColorSpace`, this way it's not hidden inside but explicitly pass, which also improves the readability of the test. This is [commit `8e85480`](https://github.com/aivanov-jdk/jdk/commit/8e854807d63fe8dc5909c8562cb64cad53679749). Here's the link to my latest version of [the `NonICCFilterTest.java` test](https://github.com/aivanov-jdk/jdk/blob/8e854807d63fe8dc5909c8562cb64cad53679749/test/jdk/java/awt/color/NonICCFilterTest.java). Indeed, without Renjith's fix, the test fails with `ArrayIndexOutOfBoundsException`: Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 1 at java.desktop/java.awt.image.ColorConvertOp.nonICCBIFilter(ColorConvertOp.java:821) at java.desktop/java.awt.image.ColorConvertOp.filter(ColorConvertOp.java:275) at NonICCFilterTest.main(NonICCFilterTest.java:132) With the fix, the test still fails but differently: x = 0, y = 0 rgb1 = fff61041 rgb2 = ff00ff00 Exception in thread "main" java.lang.RuntimeException: Test failed at NonICCFilterTest.main(NonICCFilterTest.java:138) which means non-ICC color spaces aren't handled correctly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16895#issuecomment-1878880308 From aivanov at openjdk.org Fri Jan 5 16:20:26 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 5 Jan 2024 16:20:26 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v11] In-Reply-To: <2pMaJWrb3fKl4nnOpDnLXX89tts9PadkPzJkqfgZxw4=.e168b349-3a53-4333-bfe2-a545d19ea3d5@github.com> References: <2pMaJWrb3fKl4nnOpDnLXX89tts9PadkPzJkqfgZxw4=.e168b349-3a53-4333-bfe2-a545d19ea3d5@github.com> Message-ID: <8kpcrSX2C4eWwtiNVipJ_hl9xA4umQxfMfM0Wn2FTQU=.af616056-8fb5-4626-b115-76e1208feab1@github.com> On Fri, 5 Jan 2024 12:03:43 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. >> >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Removed unwanted converion Based on @mrserb observations, additional changes are required. ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16895#pullrequestreview-1806290196 From aivanov at openjdk.org Fri Jan 5 16:20:28 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 5 Jan 2024 16:20:28 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v6] In-Reply-To: References: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> <8doF19-CcJAJ33FRt0PnKAUy2HOkZL1ddodJOgHT56A=.ae5ad0b8-77e2-498a-8803-e2b38439c08a@github.com> <6akE9WWZUu9ZHK5Drnv79JJTMvx9FAbfGYPCZTZ7ASE=.92a2a457-5a69-46fd-ba6c-e0a8085b4825@github.com> <4553eVeRmo3q4n0NFkgLZpOfQOaRKWnuDNovobCAdFw=.a65e414c-8f12-40b3-8bcc-a87b71407fb7@github.com> Message-ID: On Fri, 5 Jan 2024 13:18:46 GMT, Renjith Kannath Pariyangad wrote: >> There are at least two similar copy/paste typos. >> In the next line https://github.com/openjdk/jdk/blob/f73dbb985823d2d59bfcff8ba6951a0d9eb2cefc/src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java#L771 we use the srcNumComp which is the number of components for the incoming source color space, but the loop should be done over iccSrcNumComp which is a number of components of the "intermidiate" source color space. Similar issue is in the next line but for the destination https://github.com/openjdk/jdk/blob/f73dbb985823d2d59bfcff8ba6951a0d9eb2cefc/src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java#L785 >> >> It is possible that these compensate/affects each other and produce some non-completly broken result. >> The test from the comment above start to pass after these will be fixed. >> >> Since we found a few bugs in this code path, it will be useful to check the code path in the nonICCBIFilter where the CSList is not null(the intermidiate transform is wrapper as well, as of now our test uses the built-in ColorSpace.getInstance(CS_sRGB)) > > @mrserb for avoiding _ArrayIndexOutOfBoundsException_ I have modified `CS_GRAY `with `CS_LINEAR_RGB ` for making same number of channels. But the test passed irrespective of fix. > Do you find any alternative way to fail the test with out fix ? > There are at least two similar copy/paste typos. In the next line > > https://github.com/openjdk/jdk/blob/f73dbb985823d2d59bfcff8ba6951a0d9eb2cefc/src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java#L771 > we use the srcNumComp which is the number of components for the incoming source color space, but the loop should be done over iccSrcNumComp which is a number of components of the "intermidiate" source color space. Similar issue is in the next line but for the destination > > https://github.com/openjdk/jdk/blob/f73dbb985823d2d59bfcff8ba6951a0d9eb2cefc/src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java#L785 > > It is possible that these compensate/affects each other and produce some non-completly broken result. The test from the comment above start to pass after these will be fixed. Indeed, these should be `iccSrcNumComp` and `iccDstNumComp` according to number of components in the allocated arrays. Modifying these lines make the test pass. > Since we found a few bugs in this code path, it will be useful to check the code path in the nonICCBIFilter where the CSList is not null(the intermidiate transform is wrapper as well, as of now our test uses the built-in ColorSpace.getInstance(CS_sRGB)) Agree, another (unit) test is required which exercises other code paths. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1443068123 From martin.petzold at tavla.de Fri Jan 5 17:33:25 2024 From: martin.petzold at tavla.de (Martin Petzold) Date: Fri, 5 Jan 2024 18:33:25 +0100 Subject: How to prevent OpenJDK 11 from changing the Window size due to some internal reason Message-ID: Dear all, most probably because of a bug in Weston implementation on Linux [1]: if I detach and attach an HDMI head OR change via HDMI-CEC to standby and back, my Java window is resized to 1x1 pixel automatically due to some internal method. This is a serious bug to us. We have tested with pure Weston application, and there was no such bug. Also we are using XWayland because of Java. Currently we cannot backport that patch to Weston 9 because of extensive changes in code. We tried to catch the event and resize back, but this was not stable. Any other idea for a work-around? Is there any way to prevent OpenJDK 11 from resizing any window in some internal method? I would like to have 100% control... [1] https://gitlab.freedesktop.org/wayland/weston/-/commit/bcacd9ec5a924317416eabb65a6cd6767d5bfb94 Thanks, Martin From serb at openjdk.org Fri Jan 5 19:15:21 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 5 Jan 2024 19:15:21 GMT Subject: RFR: 8322754: click JComboBox when dialog about to close causes IllegalComponentStateException In-Reply-To: References: Message-ID: <-M8WB1akKoHh5vG3iCOreWiLsNv9Mu7PwR1Y1RHThcY=.77d1490c-e4bb-49ed-b7fc-1ece9a9e89fc@github.com> On Thu, 4 Jan 2024 07:23:59 GMT, Prasanta Sadhukhan wrote: > Clicking to open a JComboBox popup during AWT event processing at the end of which the dialog will be closed causes an IllegalComponentStateException. > Fix is made to check if combobox is showing before showing the popup to prevent the exception. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17262#pullrequestreview-1806696232 From kcr at openjdk.org Fri Jan 5 23:48:20 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 5 Jan 2024 23:48:20 GMT Subject: RFR: 8221261: deadlock of CInputMethod.characterIndexForPoint and webkit.InputMethodClientImpl.getLocationOffset In-Reply-To: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com> References: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com> Message-ID: On Fri, 22 Dec 2023 11:27:00 GMT, Johannes Bechberger wrote: > A dead-lock is caused by the interaction of MacOS, the AWTEventQueue and JavaFX when the users pressed the Caps Lock key while the AWTEventQueue is processing another event (more on this in the issue). The bug depends on the specific timing of the event sending and can apparently be prevented by finishing all incoming OS events directly while the LWCToolkit.invokeAndWait method is executed. > > This fix is tested and fixes the issue. > > I attached a small > [reproducer](https://github.com/openjdk/jdk/files/13751865/Archive.zip), just run it with `mvn install package javafx:run`. I spent a fair bit of time over the last couple of days testing different solutions to this, as well as some initial discussions with Phil and Prasanta, and I believe that taking Anton's proposed solution and expanding it to cover all of the methods in CInputMethod is the best way to go. I created a Draft PR #17290 with that solution. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17184#issuecomment-1879386874 From jbechberger at openjdk.org Sat Jan 6 07:30:27 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Sat, 6 Jan 2024 07:30:27 GMT Subject: RFR: 8221261: deadlock of CInputMethod.characterIndexForPoint and webkit.InputMethodClientImpl.getLocationOffset In-Reply-To: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com> References: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com> Message-ID: On Fri, 22 Dec 2023 11:27:00 GMT, Johannes Bechberger wrote: > A dead-lock is caused by the interaction of MacOS, the AWTEventQueue and JavaFX when the users pressed the Caps Lock key while the AWTEventQueue is processing another event (more on this in the issue). The bug depends on the specific timing of the event sending and can apparently be prevented by finishing all incoming OS events directly while the LWCToolkit.invokeAndWait method is executed. > > This fix is tested and fixes the issue. > > I attached a small > [reproducer](https://github.com/openjdk/jdk/files/13751865/Archive.zip), just run it with `mvn install package javafx:run`. I'm closing this PR and looking into your PR. Thank you for your work. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17184#issuecomment-1879582075 From jbechberger at openjdk.org Sat Jan 6 07:30:28 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Sat, 6 Jan 2024 07:30:28 GMT Subject: Withdrawn: 8221261: deadlock of CInputMethod.characterIndexForPoint and webkit.InputMethodClientImpl.getLocationOffset In-Reply-To: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com> References: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com> Message-ID: On Fri, 22 Dec 2023 11:27:00 GMT, Johannes Bechberger wrote: > A dead-lock is caused by the interaction of MacOS, the AWTEventQueue and JavaFX when the users pressed the Caps Lock key while the AWTEventQueue is processing another event (more on this in the issue). The bug depends on the specific timing of the event sending and can apparently be prevented by finishing all incoming OS events directly while the LWCToolkit.invokeAndWait method is executed. > > This fix is tested and fixes the issue. > > I attached a small > [reproducer](https://github.com/openjdk/jdk/files/13751865/Archive.zip), just run it with `mvn install package javafx:run`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/17184 From serb at openjdk.org Sun Jan 7 00:49:25 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 7 Jan 2024 00:49:25 GMT Subject: RFR: 8320673 : PageFormat/CustomPaper.java has no Pass/Fail buttons; multiple instructions In-Reply-To: References: Message-ID: On Wed, 27 Dec 2023 04:20:42 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > > I have updated the test case. Now test has pass/fail option also test will execute two time for covering different cases which are part of the test. > > Please review and let me know your suggestions. > > Regards, > Renjith. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17194#pullrequestreview-1807638148 From duke at openjdk.org Sun Jan 7 23:32:52 2024 From: duke at openjdk.org (Martin Desruisseaux) Date: Sun, 7 Jan 2024 23:32:52 GMT Subject: RFR: 8323108: BufferedImage.setData(Raster) should not cast float and double values to integers Message-ID: The `BufferedImage` Javadoc does not mention any constraint about the data type. In practice, `BufferedImage` with floating point values can be rendered by Java2D as well as integers, provided that a compatible `ColorModel` was supplied at construction time. However calls to `setData(Raster)` unexpectedly cast floating point values to integers. For example sample value 0.8 become 0. This is demonstrated by the `SetData` test case in this pull request. An easy fix, which is proposed in this pull request, is to replace the whole `BufferedImage.setData(Raster)` method body by a simple call to `WritableRaster.setRect(Raster)`, which handles all `DataBuffer` types correctly. The method contracts documented in their respective Javadoc are compatible. Furthermore an examination of their source code shows that they are equivalent, except for the differences noted in the _Behavioural changes_ section below. # Source code comparison For demonstrating that delegating to `WritableRaster.setRect(Raster)` would be equivalent to the current code, one can copy the method body and apply the following changes: * Remove `dx` parameter, replaced by 0. * Remove `dy` parameter, replaced by 0. * Rename `srcRaster` parameter as `r` (like in `BufferedImage`). * Rename `startY` variable as `i` (like in `BufferedImage`). * Rename `srcOffX` variable as `startX` (like in `BufferedImage`). * Rename `srcOffY` variable as `startY` (like in `BufferedImage`). * Replace `this.minX` by 0 and simplify. * Replace `this.minY` by 0 and simplify. * Remove the `switch` statement, keeping only the `TYPE_INT` case. Then compare with `BufferedImage.setData(Raster)`. The modified block of code from `WritableRaster` is: int width = r.getWidth(); int height = r.getHeight(); int startX = r.getMinX(); int startY = r.getMinY(); We can see that above code is identical to `BufferedImage`. The next modified block of code from `WritableRaster`: int dstOffX = startX; int dstOffY = startY; // Clip to this raster if (dstOffX < 0) { width += dstOffX; startX -= dstOffX; // = 0 because dstOffX == startX dstOffX = 0; } if (dstOffY < 0) { height += dstOffY; startY -= dstOffY; // = 0 because dstOffY == startY dstOffY = 0; } if (dstOffX+width > this.width) { width = this.width - dstOffX; } if (dstOffY+height > this.height) { height = this.height - dstOffY; } if (width <= 0 || height <= 0) { return; } Above is equivalent to the following code from `BufferedImage`, except when there is integer underflow (see _Behavioural changes_ below): // Clip to the current Raster Rectangle rclip = new Rectangle(startX, startY, width, height); Rectangle bclip = new Rectangle(0, 0, raster.width, raster.height); Rectangle intersect = rclip.intersection(bclip); if (intersect.isEmpty()) { return; } width = intersect.width; height = intersect.height; startX = intersect.x; startY = intersect.y; Next modified block of code from `WritableRaster`: int[] iData = null; for (int i=0; i < height; i++) { // Grab one scanline at a time iData = r.getPixels(startX, startY+i, width, 1, iData); setPixels(dstOffX, dstOffY+i, width, 1, iData); } Above is equivalent to `BufferedImage` code (keeping in mind that `startX == dstOffX` and same for Y, because of the `BufferedImage` constraint on raster starting at 0,0): int[] tdata = null; // remind use get/setDataElements for speed if Rasters are // compatible for (int i = startY; i < startY+height; i++) { tdata = r.getPixels(startX,i,width,1,tdata); raster.setPixels(startX,i,width,1, tdata); } # Behavioural changes This pull request would change the `BufferedImage.setData(Raster)` behaviour in the following ways: * When using the standard `WritableRaster` implementations provided by OpenJDK, performance improvements may be observed because the JDK overrides `WritableRaster.setRect(Raster)` in various internal subclasses such as `ByteInterleavedRaster`. The overridden methods try to replace the loop by calls to `System.arraycopy(?)`. * If the user constructed a `BufferedImage` with his own `WritableRaster` implementation which overrides `setRect(Raster)`, his overridden method would now be invoked. It would be compatible with `BufferedImage` Javadoc however, which said _"This class relies on the data fetching and setting methods of `Raster`, and on the color characterization methods of `ColorModel`."_ * The current `BufferedImage` implementation is more robust to integer underflows, because it uses `Rectangle.intersection(Rectangle)` which is underflow-safe. This pull request would lost this safety, unless we modify `WritableRaster.setRect(Raster)` for using `Rectangle.intersection(?)` as well. # Open questions * Do we also modify the `WritableRaster.setRect(Raster)` implementation for preserving the integer underflow safety of current `BufferedImage` implementation? The change would be to replace current intersection calculation by call to `Rectangle.intersection(?)`. * The issue described in this pull request also applies to `BufferedImage.getData()` method and its derivative. Should we fix them as well? ------------- Commit messages: - Use Rectangle.intersection(Rectangle) in WritableRaster.setRect(int, int, Raster) for safety against integer underflow/overflow. - `BufferedImage.setData(Raster)` should not cast float and double values to integers. Changes: https://git.openjdk.org/jdk/pull/13797/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13797&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323108 Stats: 171 lines in 3 files changed: 120 ins; 47 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13797.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13797/head:pull/13797 PR: https://git.openjdk.org/jdk/pull/13797 From duke at openjdk.org Sun Jan 7 23:32:53 2024 From: duke at openjdk.org (Martin Desruisseaux) Date: Sun, 7 Jan 2024 23:32:53 GMT Subject: RFR: 8323108: BufferedImage.setData(Raster) should not cast float and double values to integers In-Reply-To: <8sczVIN8B_DZtm7JE15jczLuG5U1BcPVRCmxGKwe_4c=.f49bfeea-2764-4386-883f-1260d2c07d68@github.com> References: <8sczVIN8B_DZtm7JE15jczLuG5U1BcPVRCmxGKwe_4c=.f49bfeea-2764-4386-883f-1260d2c07d68@github.com> Message-ID: On Fri, 5 May 2023 01:10:18 GMT, Sergey Bylokhov wrote: >> The `BufferedImage` Javadoc does not mention any constraint about the data type. In practice, `BufferedImage` with floating point values can be rendered by Java2D as well as integers, provided that a compatible `ColorModel` was supplied at construction time. However calls to `setData(Raster)` unexpectedly cast floating point values to integers. For example sample value 0.8 become 0. This is demonstrated by the `SetData` test case in this pull request. >> >> An easy fix, which is proposed in this pull request, is to replace the whole `BufferedImage.setData(Raster)` method body by a simple call to `WritableRaster.setRect(Raster)`, which handles all `DataBuffer` types correctly. The method contracts documented in their respective Javadoc are compatible. Furthermore an examination of their source code shows that they are equivalent, except for the differences noted in the _Behavioural changes_ section below. >> >> # Source code comparison >> For demonstrating that delegating to `WritableRaster.setRect(Raster)` would be equivalent to the current code, one can copy the method body and apply the following changes: >> >> * Remove `dx` parameter, replaced by 0. >> * Remove `dy` parameter, replaced by 0. >> * Rename `srcRaster` parameter as `r` (like in `BufferedImage`). >> * Rename `startY` variable as `i` (like in `BufferedImage`). >> * Rename `srcOffX` variable as `startX` (like in `BufferedImage`). >> * Rename `srcOffY` variable as `startY` (like in `BufferedImage`). >> * Replace `this.minX` by 0 and simplify. >> * Replace `this.minY` by 0 and simplify. >> * Remove the `switch` statement, keeping only the `TYPE_INT` case. >> >> Then compare with `BufferedImage.setData(Raster)`. The modified block of code from `WritableRaster` is: >> >> >> int width = r.getWidth(); >> int height = r.getHeight(); >> int startX = r.getMinX(); >> int startY = r.getMinY(); >> >> We can see that above code is identical to `BufferedImage`. The next modified block of code from `WritableRaster`: >> >> >> int dstOffX = startX; >> int dstOffY = startY; >> >> // Clip to this raster >> if (dstOffX < 0) { >> width += dstOffX; >> startX -= dstOffX; // = 0 because dstOffX == startX >> dstOffX = 0; >> } >> if (dstOffY < 0) { >> height += dstOffY; >> startY -= dstOffY; // = 0 because dstOffY == startY >> dstOffY = 0; >> } >> if (dstOffX+width > this.width) { >> width = this.width - dstOffX; >> } >> if (dstOffY+height > this.height) { >> height = this.height - dstOffY; >> } >> if (width <= 0 ||... > > src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 1523: > >> 1521: Rectangle bclip = new Rectangle(0, 0, raster.width, raster.height); >> 1522: Rectangle intersect = rclip.intersection(bclip); >> 1523: if (intersect.isEmpty()) { > > Does the "raster.setRect" has equivalent optimizations? it seems that method implements handcrafter "intersection", any idea why it was implemented that way? I do not know why `WritableRaster.setRect(Raster)` computes intersection with its own code in the method body instead of delegating to `Rectangle.intersection(Rectangle)` in the same way as `BufferedImage.setData(Raster)` does. For now I see no technical reason. I'm tempted to add a commit to this pull request for replacing the intersection calculation of `WritableRaster.setRect(Raster)`, but abstained for now because I though that reviewers or sponsors may want to minimize the changes. However I believe that this replacement would be desirable at least for the extra robustness of `Rectangle` regarding underflow and overflow. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13797#discussion_r1185856477 From serb at openjdk.org Sun Jan 7 23:32:53 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 7 Jan 2024 23:32:53 GMT Subject: RFR: 8323108: BufferedImage.setData(Raster) should not cast float and double values to integers In-Reply-To: References: Message-ID: <0z2I6FfFetp_zQ89v6pehrFUqFh4gDYkDiJk-Fyb8X8=.ef867e3b-a4c9-4b9d-990c-dfceddfd32d4@github.com> On Tue, 7 Nov 2023 11:09:08 GMT, Martin Desruisseaux wrote: >would be replaced by the following (this code contains a call to getBounds() overrideable method): That call could be eliminated if you create the new rect using "minX, minY, width, height". But the new code adds allocation of two new objects which immediately become garbage, probably we can change the code w/o using Rectangle? > But anyway, the cost of Rectangle allocation is probably small comparatively to the cost of copying some thousands of pixel values. But can we solve both issues, add optimization w/o creating the new objects? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13797#issuecomment-1800203841 PR Comment: https://git.openjdk.org/jdk/pull/13797#issuecomment-1804319579 From duke at openjdk.org Sun Jan 7 23:32:53 2024 From: duke at openjdk.org (Martin Desruisseaux) Date: Sun, 7 Jan 2024 23:32:53 GMT Subject: RFR: 8323108: BufferedImage.setData(Raster) should not cast float and double values to integers In-Reply-To: <0z2I6FfFetp_zQ89v6pehrFUqFh4gDYkDiJk-Fyb8X8=.ef867e3b-a4c9-4b9d-990c-dfceddfd32d4@github.com> References: <0z2I6FfFetp_zQ89v6pehrFUqFh4gDYkDiJk-Fyb8X8=.ef867e3b-a4c9-4b9d-990c-dfceddfd32d4@github.com> Message-ID: <0J2O5bvt1T_xyIRv7qSzGQZSCx4dRlTVJMJchKUSO5Y=.45ab8f38-dc0d-43db-9666-e75ad5e5cfd0@github.com> On Thu, 9 Nov 2023 18:12:19 GMT, Sergey Bylokhov wrote: > But can we solve both issues, add optimization w/o creating the new objects? Not with the current `Rectangle` API as far as I can see. If the goal is maximal performances, the current code is likely better. The use of `Rectangle.intersection(Rectangle)` was proposed for safety rather than performance, because `Rectangle` is robust to integer underflow and overflow. However, I think that the current `WritableRaster.setRect(Raster)` code can underflow/overflow only if the checks performed at `Raster` construction time were bypassed, for example by modifying the protected fields after construction. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13797#issuecomment-1804395307 From duke at openjdk.org Sun Jan 7 23:32:52 2024 From: duke at openjdk.org (Martin Desruisseaux) Date: Sun, 7 Jan 2024 23:32:52 GMT Subject: RFR: 8323108: BufferedImage.setData(Raster) should not cast float and double values to integers In-Reply-To: References: Message-ID: On Thu, 4 May 2023 10:14:10 GMT, Martin Desruisseaux wrote: > The `BufferedImage` Javadoc does not mention any constraint about the data type. In practice, `BufferedImage` with floating point values can be rendered by Java2D as well as integers, provided that a compatible `ColorModel` was supplied at construction time. However calls to `setData(Raster)` unexpectedly cast floating point values to integers. For example sample value 0.8 become 0. This is demonstrated by the `SetData` test case in this pull request. > > An easy fix, which is proposed in this pull request, is to replace the whole `BufferedImage.setData(Raster)` method body by a simple call to `WritableRaster.setRect(Raster)`, which handles all `DataBuffer` types correctly. The method contracts documented in their respective Javadoc are compatible. Furthermore an examination of their source code shows that they are equivalent, except for the differences noted in the _Behavioural changes_ section below. > > # Source code comparison > For demonstrating that delegating to `WritableRaster.setRect(Raster)` would be equivalent to the current code, one can copy the method body and apply the following changes: > > * Remove `dx` parameter, replaced by 0. > * Remove `dy` parameter, replaced by 0. > * Rename `srcRaster` parameter as `r` (like in `BufferedImage`). > * Rename `startY` variable as `i` (like in `BufferedImage`). > * Rename `srcOffX` variable as `startX` (like in `BufferedImage`). > * Rename `srcOffY` variable as `startY` (like in `BufferedImage`). > * Replace `this.minX` by 0 and simplify. > * Replace `this.minY` by 0 and simplify. > * Remove the `switch` statement, keeping only the `TYPE_INT` case. > > Then compare with `BufferedImage.setData(Raster)`. The modified block of code from `WritableRaster` is: > > > int width = r.getWidth(); > int height = r.getHeight(); > int startX = r.getMinX(); > int startY = r.getMinY(); > > We can see that above code is identical to `BufferedImage`. The next modified block of code from `WritableRaster`: > > > int dstOffX = startX; > int dstOffY = startY; > > // Clip to this raster > if (dstOffX < 0) { > width += dstOffX; > startX -= dstOffX; // = 0 because dstOffX == startX > dstOffX = 0; > } > if (dstOffY < 0) { > height += dstOffY; > startY -= dstOffY; // = 0 because dstOffY == startY > dstOffY = 0; > } > if (dstOffX+width > this.width) { > width = this.width - dstOffX; > } > if (dstOffY+height > this.height) { > height = this.height - dstOffY; > } > if (width <= 0 || height <= 0) { > return; > } > > > Above is equivalent to the following code from `BufferedImage`, ex... A comment for keeping this merge request alive. Reminder: it is about resolving data lost in calls to `BufferedImage.setData(Raster)` caused by unnecessary casts of sample values. Ping for keeping this pull request alive. Can we have a reviewer for it, or open a discussion about whether to expand the issue scope as mentioned in the description? Issue reminder: `BufferedImage.setData(Raster)` lost data when using floating point values, without anything in the Javadoc suggesting that it is the expected behaviour. The proposed fix would resolve the data lost, *simplify* the code, possibly improve performances (but it is not the main goal) and be closer to what javadoc suggests. Open question: current pull request does the smallest amount of changes, but more simplifications are possible. Should we add them to this pull request? Thanks. Regarding the second issue (`getData()` and its derivatives), a closer look shows that I was wrong to said that it suffers the same problem than `setData(Raster)`. Only the latter needs to be fixed, so the current request should be sufficient. Regarding the second open question about replacing current handcrafter intersection code by a call to `Rectangle.intersection(Rectangle)`, the following code: if (dstOffX < this.minX) { int skipX = this.minX - dstOffX; width -= skipX; srcOffX += skipX; dstOffX = this.minX; } if (dstOffY < this.minY) { int skipY = this.minY - dstOffY; height -= skipY; srcOffY += skipY; dstOffY = this.minY; } if (dstOffX+width > this.minX+this.width) { width = this.minX + this.width - dstOffX; } if (dstOffY+height > this.minY+this.height) { height = this.minY + this.height - dstOffY; } if (width <= 0 || height <= 0) { return; } would be replaced by the following (this code contains a call to `getBounds()` overrideable method): Rectangle dstRect = new Rectangle(dstOffX, dstOffY, width, height); dstRect = dstRect.intersection(getBounds()); if (dstRect.isEmpty()) { return; } srcOffX += dstRect.x - dstOffX; srcOffY += dstRect.y - dstOffY; dstOffX = dstRect.x; dstOffY = dstRect.y; width = dstRect.width; height = dstRect.height; Would it be a worthly change? I do not see variant of `Rectangle.intersection(?)` with `int` arguments [in the Javadoc](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/Rectangle.html). Maybe HotSpot can avoid the allocation with escape analysis. But anyway, the cost of `Rectangle` allocation is probably small comparatively to the cost of copying some thousands of pixel values. Added a commit doing the replacement of handcrafter intersection in `WritableRaster.setRect(?)` by a call to `Rectangle.intersection(?)`. I couldn't run the jtreg tests however. I tried for a few hours, but I presume that I didn't configured correctly. Note that `setRect(?)` is overridden in `sun.awt.image.ByteInterleavedRaster` and `sun.awt.image.BytePackedRaster` for optimization purposes. Those methods use the same handcrafter intersection code than the one replaced by this commit. However I didn't updated the code in those subclasses. They should not be subject to underflow / overflow because users should not extend these classes and thus access to the protected fields. We could update those methods anyway for consistency, but I do not know what is the OpenJDK policy in that case. Regarding `BufferedImage.getData()`, I remember the issue. That method does not have the lost of precision issue documented in this pull request. But it would nevertheless benefit from the same change (delegate to `WritableRaster.setRect(?)`) for performance reasons, because of optimizations in above-cited `ByteInterleavedRaster` and `BytePackedRaster` subclasses. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13797#issuecomment-1607179108 PR Comment: https://git.openjdk.org/jdk/pull/13797#issuecomment-1685255511 PR Comment: https://git.openjdk.org/jdk/pull/13797#issuecomment-1798294061 PR Comment: https://git.openjdk.org/jdk/pull/13797#issuecomment-1800282141 PR Comment: https://git.openjdk.org/jdk/pull/13797#issuecomment-1808314079 From serb at openjdk.org Sun Jan 7 23:32:53 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 7 Jan 2024 23:32:53 GMT Subject: RFR: 8323108: BufferedImage.setData(Raster) should not cast float and double values to integers In-Reply-To: References: <8sczVIN8B_DZtm7JE15jczLuG5U1BcPVRCmxGKwe_4c=.f49bfeea-2764-4386-883f-1260d2c07d68@github.com> Message-ID: On Fri, 5 May 2023 08:58:37 GMT, Martin Desruisseaux wrote: >> src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 1523: >> >>> 1521: Rectangle bclip = new Rectangle(0, 0, raster.width, raster.height); >>> 1522: Rectangle intersect = rclip.intersection(bclip); >>> 1523: if (intersect.isEmpty()) { >> >> Does the "raster.setRect" has equivalent optimizations? it seems that method implements handcrafter "intersection", any idea why it was implemented that way? > > I do not know why `WritableRaster.setRect(Raster)` computes intersection with its own code in the method body instead of delegating to `Rectangle.intersection(Rectangle)` in the same way as `BufferedImage.setData(Raster)` does. For now I see no technical reason. I'm tempted to add a commit to this pull request for replacing the intersection calculation of `WritableRaster.setRect(Raster)`, but abstained for now because I though that reviewers or sponsors may want to minimize the changes. However I believe that this replacement would be desirable at least for the extra robustness of `Rectangle` regarding underflow and overflow. Can we prove the overflow issue there by some test? If yes then probably it would be useful to fix it as well, probably even as separate bug which can be later backported. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13797#discussion_r1187770347 From serb at openjdk.org Sun Jan 7 23:32:53 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 7 Jan 2024 23:32:53 GMT Subject: RFR: 8323108: BufferedImage.setData(Raster) should not cast float and double values to integers In-Reply-To: References: Message-ID: <8sczVIN8B_DZtm7JE15jczLuG5U1BcPVRCmxGKwe_4c=.f49bfeea-2764-4386-883f-1260d2c07d68@github.com> On Thu, 4 May 2023 10:14:10 GMT, Martin Desruisseaux wrote: > The `BufferedImage` Javadoc does not mention any constraint about the data type. In practice, `BufferedImage` with floating point values can be rendered by Java2D as well as integers, provided that a compatible `ColorModel` was supplied at construction time. However calls to `setData(Raster)` unexpectedly cast floating point values to integers. For example sample value 0.8 become 0. This is demonstrated by the `SetData` test case in this pull request. > > An easy fix, which is proposed in this pull request, is to replace the whole `BufferedImage.setData(Raster)` method body by a simple call to `WritableRaster.setRect(Raster)`, which handles all `DataBuffer` types correctly. The method contracts documented in their respective Javadoc are compatible. Furthermore an examination of their source code shows that they are equivalent, except for the differences noted in the _Behavioural changes_ section below. > > # Source code comparison > For demonstrating that delegating to `WritableRaster.setRect(Raster)` would be equivalent to the current code, one can copy the method body and apply the following changes: > > * Remove `dx` parameter, replaced by 0. > * Remove `dy` parameter, replaced by 0. > * Rename `srcRaster` parameter as `r` (like in `BufferedImage`). > * Rename `startY` variable as `i` (like in `BufferedImage`). > * Rename `srcOffX` variable as `startX` (like in `BufferedImage`). > * Rename `srcOffY` variable as `startY` (like in `BufferedImage`). > * Replace `this.minX` by 0 and simplify. > * Replace `this.minY` by 0 and simplify. > * Remove the `switch` statement, keeping only the `TYPE_INT` case. > > Then compare with `BufferedImage.setData(Raster)`. The modified block of code from `WritableRaster` is: > > > int width = r.getWidth(); > int height = r.getHeight(); > int startX = r.getMinX(); > int startY = r.getMinY(); > > We can see that above code is identical to `BufferedImage`. The next modified block of code from `WritableRaster`: > > > int dstOffX = startX; > int dstOffY = startY; > > // Clip to this raster > if (dstOffX < 0) { > width += dstOffX; > startX -= dstOffX; // = 0 because dstOffX == startX > dstOffX = 0; > } > if (dstOffY < 0) { > height += dstOffY; > startY -= dstOffY; // = 0 because dstOffY == startY > dstOffY = 0; > } > if (dstOffX+width > this.width) { > width = this.width - dstOffX; > } > if (dstOffY+height > this.height) { > height = this.height - dstOffY; > } > if (width <= 0 || height <= 0) { > return; > } > > > Above is equivalent to the following code from `BufferedImage`, ex... This change looks fine to me as is, but I think it would be useful to eliminate the next issue with the same patch(it depends on the change size): @prrace do you have a preference should we fix that in one or separate patches? >Do we also modify the WritableRaster.setRect(Raster) implementation for preserving the integer underflow safety of current BufferedImage implementation? The change would be to replace current intersection calculation by call to Rectangle.intersection(?). ok, let's use a solution based on the `Rectangle.intersection` keep open src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 1523: > 1521: Rectangle bclip = new Rectangle(0, 0, raster.width, raster.height); > 1522: Rectangle intersect = rclip.intersection(bclip); > 1523: if (intersect.isEmpty()) { Does the "raster.setRect" has equivalent optimizations? it seems that method implements handcrafter "intersection", any idea why it was implemented that way? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13797#issuecomment-1796884736 PR Comment: https://git.openjdk.org/jdk/pull/13797#issuecomment-1805005732 PR Comment: https://git.openjdk.org/jdk/pull/13797#issuecomment-1876243855 PR Review Comment: https://git.openjdk.org/jdk/pull/13797#discussion_r1185633352 From duke at openjdk.org Sun Jan 7 23:32:53 2024 From: duke at openjdk.org (Martin Desruisseaux) Date: Sun, 7 Jan 2024 23:32:53 GMT Subject: RFR: 8323108: BufferedImage.setData(Raster) should not cast float and double values to integers In-Reply-To: References: <8sczVIN8B_DZtm7JE15jczLuG5U1BcPVRCmxGKwe_4c=.f49bfeea-2764-4386-883f-1260d2c07d68@github.com> Message-ID: <6vAaSLOLKuHYGnPTpWX2BT_6-Iw_sVn3u3d3jDWISHU=.d6756d8f-ea24-4593-96d8-42cebc6bb79c@github.com> On Mon, 8 May 2023 18:44:00 GMT, Sergey Bylokhov wrote: >> I do not know why `WritableRaster.setRect(Raster)` computes intersection with its own code in the method body instead of delegating to `Rectangle.intersection(Rectangle)` in the same way as `BufferedImage.setData(Raster)` does. For now I see no technical reason. I'm tempted to add a commit to this pull request for replacing the intersection calculation of `WritableRaster.setRect(Raster)`, but abstained for now because I though that reviewers or sponsors may want to minimize the changes. However I believe that this replacement would be desirable at least for the extra robustness of `Rectangle` regarding underflow and overflow. > > Can we prove the overflow issue there by some test? If yes then probably it would be useful to fix it as well, probably even as separate bug which can be later backported. In theory the following code would demonstrate the overflow: var sm = new BandedSampleModel(DataBuffer.TYPE_BYTE, 100, 100, 1); var r1 = Raster.createWritableRaster(sm, new Point(Integer.MAX_VALUE - 150, 0)); var r2 = Raster.createWritableRaster(sm, new Point(Integer.MAX_VALUE - 50, 0)); // Overflow on X. r1.setRect(r2); It practice it does not happen so easily because the `Raster` constructor detects in advance the overflow and throws a `RasterFormatException` saying _"overflow condition for X coordinates of Raster"_. However because the `Raster.minX` field is protected and non-final, the constructor check can be bypassed as below: var r2 = new WritableRaster(sm, new Point()) { { // Constructor minX = Integer.MAX_VALUE - 50; sampleModelTranslateX = minX; } }; In which case the overflow happens and manifest itself with an `ArrayIndexOutOfBoundsException`. I do not know if this is considered a too convolved case for being worth a fix. However using the `BufferedImage` code, in addition of being robust to this case, would also be simpler. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13797#discussion_r1192681645 From psadhukhan at openjdk.org Mon Jan 8 02:49:32 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 8 Jan 2024 02:49:32 GMT Subject: Integrated: 8322754: click JComboBox when dialog about to close causes IllegalComponentStateException In-Reply-To: References: Message-ID: On Thu, 4 Jan 2024 07:23:59 GMT, Prasanta Sadhukhan wrote: > Clicking to open a JComboBox popup during AWT event processing at the end of which the dialog will be closed causes an IllegalComponentStateException. > Fix is made to check if combobox is showing before showing the popup to prevent the exception. This pull request has now been integrated. Changeset: e4427698 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/e44276989fc6358065412be7567d0141c84f1282 Stats: 94 lines in 2 files changed: 92 ins; 0 del; 2 mod 8322754: click JComboBox when dialog about to close causes IllegalComponentStateException Reviewed-by: abhiscxk, serb ------------- PR: https://git.openjdk.org/jdk/pull/17262 From psadhukhan at openjdk.org Mon Jan 8 04:08:24 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 8 Jan 2024 04:08:24 GMT Subject: RFR: 8264102: JTable Keyboards Navigation differs with Test Instructions. [v2] In-Reply-To: References: Message-ID: On Fri, 5 Jan 2024 07:31:46 GMT, Tejesh R wrote: >> Updated the actions for "ctrl shift DOWN" to "`selectLastRowExtendSelection`" and "ctrl shift UP", "`selectFirstRowExtendSelection`" in Basic and other Look and feel. Tested in CI and no regressions found. >> Test to be used - [javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java) > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review Fix test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 194: > 192: > 193: public static void main(String[] args) throws Exception { > 194: UIManager.setLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel"); The fix is for all L&F but the test is testing only Metal...It should be given chance to use default L&F in each platform.. If 4112270 is only about Metal, then a new test should be spawned to test this fix for all fixed L&F.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17236#discussion_r1444158927 From rkannathpari at openjdk.org Mon Jan 8 04:37:24 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Mon, 8 Jan 2024 04:37:24 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v11] In-Reply-To: References: <2pMaJWrb3fKl4nnOpDnLXX89tts9PadkPzJkqfgZxw4=.e168b349-3a53-4333-bfe2-a545d19ea3d5@github.com> Message-ID: <9aV4oO0qWtvoFkXmBmYgY0ARIkv90Z1J5xmjWcGvJz4=.71a10194-e5fc-49dd-ac9a-5b8826e6a71f@github.com> On Fri, 5 Jan 2024 15:49:56 GMT, Alexey Ivanov wrote: >> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed unwanted converion > > I've been thinking about it more, and I agree with Sergey. There are two types of `ColorSpace`s: ICC and non-ICC. The `TestColorSpace` is a wrapper on top of an `ICC_ColorSpace` (with Sergey's implementation that forwards all the method calls to its wrapped `ColorSpace` instance stored in the `cs` field. > > The expectation is that using the same ColorSpace result in the same output. We ? _Sergey_ ? do just that. > > 1. Take two images with an `ICC_ColorSpace` and transform them. > 2. Take another pair of images with the wrapped `ICC_ColorSpace` and transform them. > > The result of the transformation must be the same, right? It's a better test. > > I've created [`renjith/sergey-8316497-colorConvertOp`](https://github.com/aivanov-jdk/jdk/tree/renjith/sergey-8316497-colorConvertOp) branch. It's based on Renjith's `[8316497-v1](https://github.com/Renjithkannath/jdk/tree/8316497-v1)` which corresponds to this PR. > > Sergey's code from [his comment](https://github.com/openjdk/jdk/pull/16895#discussion_r1441366764) above is available as [commit `ac6b10f`](https://github.com/aivanov-jdk/jdk/commit/ac6b10fa82e64934b46a642ad9a87d64d80affbf). > > I refactored it by introducing an enum for selecting the `ColorSpace`, it makes it easier to understand which `ColorSpace` is created. I modified `createTestImage` to accept a `ColorSpace`, this way it's not hidden inside but explicitly pass, which also improves the readability of the test. This is [commit `8e85480`](https://github.com/aivanov-jdk/jdk/commit/8e854807d63fe8dc5909c8562cb64cad53679749). > > Here's the link to my latest version of [the `NonICCFilterTest.java` test](https://github.com/aivanov-jdk/jdk/blob/8e854807d63fe8dc5909c8562cb64cad53679749/test/jdk/java/awt/color/NonICCFilterTest.java). > > Indeed, without Renjith's fix, the test fails with `ArrayIndexOutOfBoundsException`: > > > Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 1 > at java.desktop/java.awt.image.ColorConvertOp.nonICCBIFilter(ColorConvertOp.java:821) > at java.desktop/java.awt.image.ColorConvertOp.filter(ColorConvertOp.java:275) > at NonICCFilterTest.main(NonICCFilterTest.java:132) > > > With the fix, the test still fails but differently: > > > x = 0, y = 0 > rgb1 = fff61041 > rgb2 = ff00ff00 > Exception in thread "main" java.lang.RuntimeException: Test failed > at NonICCFilterTest.main(NonICCFilterTest.java:138) > > > which means non-ICC color spaces aren't handled correctly. @aivanov-jdk , Thank you for the detailed investigation. Earlier I didn't do much investigation with or with out fix after getting _ArrayIndexOutOfBoundsException_. Now its narrow down as with fix there is no _array out of bound_ and with out there is. About the failure post fix : I think its because of typo, As per the logic comparing two image and if its not equal then test pass. I think if condition missed `not (!)` (original code return _true_ if match and _false_ if docent, in Sergey sample `compareImages ` returns _true_ if not match and _false_ if match but `if (compareImages(destTest, destGold))` same. @mrserb hope this observation is correct. Thank to @mrserb and @aivanov-jdk for your time and investigation, this helped to bring up few more issues. What do you suggest to cover these cases ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16895#issuecomment-1880373713 From tr at openjdk.org Mon Jan 8 05:02:25 2024 From: tr at openjdk.org (Tejesh R) Date: Mon, 8 Jan 2024 05:02:25 GMT Subject: RFR: 8264102: JTable Keyboards Navigation differs with Test Instructions. [v2] In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 04:06:09 GMT, Prasanta Sadhukhan wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Review Fix > > test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 194: > >> 192: >> 193: public static void main(String[] args) throws Exception { >> 194: UIManager.setLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel"); > > The fix is for all L&F but the test is testing only Metal...It should be given chance to use default L&F in each platform.. > If 4112270 is only about Metal, then a new test should be spawned to test this fix for all fixed L&F.. 4112270 is not only about Metal L&F. In Aqua L&F the functionality is different, it enables the cell to edit mode. Yet, in macos excel functionality is same as that of windows. Should we update Aqua too? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17236#discussion_r1444174136 From psadhukhan at openjdk.org Mon Jan 8 05:23:22 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 8 Jan 2024 05:23:22 GMT Subject: RFR: 8264102: JTable Keyboards Navigation differs with Test Instructions. [v2] In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 04:59:49 GMT, Tejesh R wrote: >> test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 194: >> >>> 192: >>> 193: public static void main(String[] args) throws Exception { >>> 194: UIManager.setLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel"); >> >> The fix is for all L&F but the test is testing only Metal...It should be given chance to use default L&F in each platform.. >> If 4112270 is only about Metal, then a new test should be spawned to test this fix for all fixed L&F.. > > 4112270 is not only about Metal L&F. In Aqua L&F the functionality is different, it enables the cell to edit mode. Yet, in macos excel functionality is same as that of windows. Should we update Aqua too? Which macos excel application you tested? Microsoft excel or NUmbers...I guess Numbers should be ideal native application to tell if native OS does need it and depending on that, we need to change it accordingly for Aqua L&F.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17236#discussion_r1444180340 From tr at openjdk.org Mon Jan 8 05:34:22 2024 From: tr at openjdk.org (Tejesh R) Date: Mon, 8 Jan 2024 05:34:22 GMT Subject: RFR: 8264102: JTable Keyboards Navigation differs with Test Instructions. [v2] In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 05:21:08 GMT, Prasanta Sadhukhan wrote: >> 4112270 is not only about Metal L&F. In Aqua L&F the functionality is different, it enables the cell to edit mode. Yet, in macos excel functionality is same as that of windows. Should we update Aqua too? > > Which macos excel application you tested? Microsoft excel or NUmbers...I guess Numbers should be ideal native application to tell if native OS does need it and depending on that, we need to change it accordingly for Aqua L&F.. In both Microsoft excel and Numbers, Ctrl shift UP/DOWN extends till first/end row. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17236#discussion_r1444183910 From abhiscxk at openjdk.org Mon Jan 8 08:18:43 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 8 Jan 2024 08:18:43 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF Message-ID: The collapsed icon for JTree is not painted using `Icon.paintIcon(Component c, Graphics g, int x, int y)` in GTK LAF. The collapsed icon is returned from BasicTreeUI class which doesn't contain any icon image whereas the expanded icon is returned from SynthTreeUI class and expanded icon is rendered correctly. The proposed fix is to return collapsed icon as an object of collapsed icon wrapper which implements synthIcon and is similar to the expanded icon implementation. Test mentioned in JBS is an applet based which is converted to main based now and extended for all installed LAFs on the system. No regression caused with the fix, link is attached in JBS . ------------- Commit messages: - JTree icon render fix Changes: https://git.openjdk.org/jdk/pull/17294/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17294&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8258979 Stats: 153 lines in 2 files changed: 115 ins; 1 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/17294.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17294/head:pull/17294 PR: https://git.openjdk.org/jdk/pull/17294 From serb at openjdk.org Mon Jan 8 08:18:43 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 8 Jan 2024 08:18:43 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 07:29:13 GMT, Abhishek Kumar wrote: > The collapsed icon for JTree is not painted using `Icon.paintIcon(Component c, Graphics g, int x, int y)` in GTK LAF. The collapsed icon is returned from BasicTreeUI class which doesn't contain any icon image whereas the expanded icon is returned from SynthTreeUI class and expanded icon is rendered correctly. > The proposed fix is to return collapsed icon as an object of collapsed icon wrapper which implements synthIcon and is similar to the expanded icon implementation. > > Test mentioned in JBS is an applet based which is converted to main based now and extended for all installed LAFs on the system. > > No regression caused with the fix, link is attached in JBS . > ?? Failed to retrieve information on issue 8258979. Looks like the bug is confidential/not public. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17294#issuecomment-1880542458 From abhiscxk at openjdk.org Mon Jan 8 08:18:44 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 8 Jan 2024 08:18:44 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 08:13:41 GMT, Sergey Bylokhov wrote: > > ?? Failed to retrieve information on issue 8258979. > > Looks like the bug is confidential/not public. Already updated the bug but it is still not reflected. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17294#issuecomment-1880545264 From psadhukhan at openjdk.org Mon Jan 8 08:46:23 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 8 Jan 2024 08:46:23 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 07:29:13 GMT, Abhishek Kumar wrote: > The collapsed icon for JTree is not painted using `Icon.paintIcon(Component c, Graphics g, int x, int y)` in GTK LAF. The collapsed icon is returned from BasicTreeUI class which doesn't contain any icon image whereas the expanded icon is returned from SynthTreeUI class and expanded icon is rendered correctly. > The proposed fix is to return collapsed icon as an object of collapsed icon wrapper which implements synthIcon and is similar to the expanded icon implementation. > > Test mentioned in JBS is an applet based which is converted to main based now and extended for all installed LAFs on the system. > > No regression caused with the fix, link is attached in JBS . JBS image suggests that no image is rendered either for collapsed or expanded icon for Ubuntu20.10-x64 but it seems you are seeing expanded icon but not collapsed icon, is that correct? WHich ubuntu you tested against? Did you check on ubuntu 20.10 in case ------------- PR Comment: https://git.openjdk.org/jdk/pull/17294#issuecomment-1880580485 From abhiscxk at openjdk.org Mon Jan 8 08:55:23 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 8 Jan 2024 08:55:23 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF In-Reply-To: References: Message-ID: <4WjQcgT9boEm9vnMHgqmV3tzknSYqPdUQRFRjZOX5_I=.2db98342-a148-44a8-8e06-8ffc0fe99d9e@github.com> On Mon, 8 Jan 2024 08:44:00 GMT, Prasanta Sadhukhan wrote: > JBS image suggests that no image is rendered either for collapsed or expanded icon for Ubuntu20.10-x64 but it seems you are seeing expanded icon but not collapsed icon, is that correct? Yes, only collapsed icon is not rendered. >Which ubuntu you tested against? 22.04 > Did you check on ubuntu 20.10 in case Didn't have 201.0 machine, so couldn't check. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17294#issuecomment-1880591624 From rschmelter at openjdk.org Mon Jan 8 09:05:23 2024 From: rschmelter at openjdk.org (Ralf Schmelter) Date: Mon, 8 Jan 2024 09:05:23 GMT Subject: RFR: JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows In-Reply-To: <5x-CDbd8ujYRMOO46Emn8ybYsqfkipVoHBnFylB1DTE=.fdc27846-0928-4901-84cc-98937c76e7d1@github.com> References: <5x-CDbd8ujYRMOO46Emn8ybYsqfkipVoHBnFylB1DTE=.fdc27846-0928-4901-84cc-98937c76e7d1@github.com> Message-ID: On Tue, 2 Jan 2024 15:03:12 GMT, Matthias Baesken wrote: > The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni , and shows on Windows server 2019 the following JNI warning , so the test fails on this Windows version. > > stdout: [WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV > at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 23-internal/Native Method) > at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 23-internal/Win32GraphicsEnvironment.java:95) > at sun.awt.Win32GraphicsEnvironment.(java.desktop at 23-internal/Win32GraphicsEnvironment.java:63) > at sun.awt.PlatformGraphicsInfo.createGE(java.desktop at 23-internal/PlatformGraphicsInfo.java:34) > at java.awt.GraphicsEnvironment$LocalGE.createGE(java.desktop at 23-internal/GraphicsEnvironment.java:93) > at java.awt.GraphicsEnvironment$LocalGE.(java.desktop at 23-internal/GraphicsEnvironment.java:84) > at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(java.desktop at 23-internal/GraphicsEnvironment.java:106) > at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) > at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44) > > > We better add an exception check to get rid of the JNI warning (and also of the test failure) . Looks good to me. Not sure if we really need the logging, since the called method only sets a boolean field. ------------- Marked as reviewed by rschmelter (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17224#pullrequestreview-1808402021 From psadhukhan at openjdk.org Mon Jan 8 09:14:23 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 8 Jan 2024 09:14:23 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 07:29:13 GMT, Abhishek Kumar wrote: > The collapsed icon for JTree is not painted using `Icon.paintIcon(Component c, Graphics g, int x, int y)` in GTK LAF. The collapsed icon is returned from BasicTreeUI class which doesn't contain any icon image whereas the expanded icon is returned from SynthTreeUI class and expanded icon is rendered correctly. > The proposed fix is to return collapsed icon as an object of collapsed icon wrapper which implements synthIcon and is similar to the expanded icon implementation. > > Test mentioned in JBS is an applet based which is converted to main based now and extended for all installed LAFs on the system. > > No regression caused with the fix, link is attached in JBS . How about latest 23.10? Probably you should install and check there as well if you dont have that.....There is a need to check in latest OracleLinux too as there is a difference in observations across ubuntu versions.. Also, if one icon is rendered and other is not, there is a potential to create automated test to render the icons into bufferedimage and compare, the collapsed one should be all white BI in failed case...and you can use that automated test to test in ubuntu20.10 machine which we seem to have few in mach5... ------------- PR Comment: https://git.openjdk.org/jdk/pull/17294#issuecomment-1880618805 From tr at openjdk.org Mon Jan 8 09:16:42 2024 From: tr at openjdk.org (Tejesh R) Date: Mon, 8 Jan 2024 09:16:42 GMT Subject: RFR: 8264102: JTable Keyboards Navigation differs with Test Instructions. [v3] In-Reply-To: References: Message-ID: <1mDjAlphaYvAtIbkJglBOfTYcWbU25WD65GxLSqLCpY=.c2b94010-2865-4e43-b956-43185f10735e@github.com> > Updated the actions for "ctrl shift DOWN" to "`selectLastRowExtendSelection`" and "ctrl shift UP", "`selectFirstRowExtendSelection`" in Basic and other Look and feel. Tested in CI and no regressions found. > Test to be used - [javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java) Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated for Aqua L&F ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17236/files - new: https://git.openjdk.org/jdk/pull/17236/files/67fdf399..b478b650 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17236&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17236&range=01-02 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17236.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17236/head:pull/17236 PR: https://git.openjdk.org/jdk/pull/17236 From abhiscxk at openjdk.org Mon Jan 8 09:21:25 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 8 Jan 2024 09:21:25 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 09:11:34 GMT, Prasanta Sadhukhan wrote: > How about latest 23.10? Probably you should install and check there as well if you dont have that.....There is a need to check in latest OracleLinux too as there is a difference in observations across ubuntu versions.. Also, if one icon is rendered and other is not, there is a potential to create automated test to render the icons into bufferedimage and compare, the collapsed one should be all white BI in failed case...and you can use that automated test to test in ubuntu20.10 machine which we seem to have few in mach5... Ok, will check and update. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17294#issuecomment-1880628554 From psadhukhan at openjdk.org Mon Jan 8 09:24:34 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 8 Jan 2024 09:24:34 GMT Subject: RFR: 8318112: CSS percentage values are capped at 100% Message-ID: Java CSS where values can be displayed in percent are capped at 100% so "width: 200%" and "width: 100%" are equal, which is incorrect. FIx is made to make sure parsing is not capped at 100% ------------- Commit messages: - 8318112: CSS percentage values are capped at 100% Changes: https://git.openjdk.org/jdk/pull/17299/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17299&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318112 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17299.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17299/head:pull/17299 PR: https://git.openjdk.org/jdk/pull/17299 From tr at openjdk.org Mon Jan 8 09:47:50 2024 From: tr at openjdk.org (Tejesh R) Date: Mon, 8 Jan 2024 09:47:50 GMT Subject: RFR: 8264102: JTable Keyboards Navigation differs with Test Instructions. [v4] In-Reply-To: References: Message-ID: > Updated the actions for "ctrl shift DOWN" to "`selectLastRowExtendSelection`" and "ctrl shift UP", "`selectFirstRowExtendSelection`" in Basic and other Look and feel. Tested in CI and no regressions found. > Test to be used - [javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java) Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Removing Metal specific L&F from test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17236/files - new: https://git.openjdk.org/jdk/pull/17236/files/b478b650..ccd5fd5b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17236&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17236&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17236.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17236/head:pull/17236 PR: https://git.openjdk.org/jdk/pull/17236 From mbaesken at openjdk.org Mon Jan 8 11:26:21 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 8 Jan 2024 11:26:21 GMT Subject: RFR: JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows In-Reply-To: <5x-CDbd8ujYRMOO46Emn8ybYsqfkipVoHBnFylB1DTE=.fdc27846-0928-4901-84cc-98937c76e7d1@github.com> References: <5x-CDbd8ujYRMOO46Emn8ybYsqfkipVoHBnFylB1DTE=.fdc27846-0928-4901-84cc-98937c76e7d1@github.com> Message-ID: On Tue, 2 Jan 2024 15:03:12 GMT, Matthias Baesken wrote: > The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni , and shows on Windows server 2019 the following JNI warning , so the test fails on this Windows version. > > stdout: [WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV > at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 23-internal/Native Method) > at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 23-internal/Win32GraphicsEnvironment.java:95) > at sun.awt.Win32GraphicsEnvironment.(java.desktop at 23-internal/Win32GraphicsEnvironment.java:63) > at sun.awt.PlatformGraphicsInfo.createGE(java.desktop at 23-internal/PlatformGraphicsInfo.java:34) > at java.awt.GraphicsEnvironment$LocalGE.createGE(java.desktop at 23-internal/GraphicsEnvironment.java:93) > at java.awt.GraphicsEnvironment$LocalGE.(java.desktop at 23-internal/GraphicsEnvironment.java:84) > at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(java.desktop at 23-internal/GraphicsEnvironment.java:106) > at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) > at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44) > > > We better add an exception check to get rid of the JNI warning (and also of the test failure) . Hi Ralf, thanks for the review ! Any other comments / reviews ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17224#issuecomment-1880818797 From stuefe at openjdk.org Mon Jan 8 11:31:22 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 8 Jan 2024 11:31:22 GMT Subject: RFR: JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows In-Reply-To: <5x-CDbd8ujYRMOO46Emn8ybYsqfkipVoHBnFylB1DTE=.fdc27846-0928-4901-84cc-98937c76e7d1@github.com> References: <5x-CDbd8ujYRMOO46Emn8ybYsqfkipVoHBnFylB1DTE=.fdc27846-0928-4901-84cc-98937c76e7d1@github.com> Message-ID: <5221cCyISeYlrenxY7QW84AiN0fknpjBEC6Q_4gfeJU=.dbf8c4a8-b039-4783-a16a-a4ee03396fde@github.com> On Tue, 2 Jan 2024 15:03:12 GMT, Matthias Baesken wrote: > The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni , and shows on Windows server 2019 the following JNI warning , so the test fails on this Windows version. > > stdout: [WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV > at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 23-internal/Native Method) > at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 23-internal/Win32GraphicsEnvironment.java:95) > at sun.awt.Win32GraphicsEnvironment.(java.desktop at 23-internal/Win32GraphicsEnvironment.java:63) > at sun.awt.PlatformGraphicsInfo.createGE(java.desktop at 23-internal/PlatformGraphicsInfo.java:34) > at java.awt.GraphicsEnvironment$LocalGE.createGE(java.desktop at 23-internal/GraphicsEnvironment.java:93) > at java.awt.GraphicsEnvironment$LocalGE.(java.desktop at 23-internal/GraphicsEnvironment.java:84) > at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(java.desktop at 23-internal/GraphicsEnvironment.java:106) > at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) > at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44) > > > We better add an exception check to get rid of the JNI warning (and also of the test failure) . +1. I agree with Ralf, logging is not that important. Possibly just add a (c-runtime) assert. Up to you. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17224#pullrequestreview-1808867637 From mbaesken at openjdk.org Mon Jan 8 11:48:33 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 8 Jan 2024 11:48:33 GMT Subject: RFR: JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows In-Reply-To: <5x-CDbd8ujYRMOO46Emn8ybYsqfkipVoHBnFylB1DTE=.fdc27846-0928-4901-84cc-98937c76e7d1@github.com> References: <5x-CDbd8ujYRMOO46Emn8ybYsqfkipVoHBnFylB1DTE=.fdc27846-0928-4901-84cc-98937c76e7d1@github.com> Message-ID: On Tue, 2 Jan 2024 15:03:12 GMT, Matthias Baesken wrote: > The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni , and shows on Windows server 2019 the following JNI warning , so the test fails on this Windows version. > > stdout: [WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV > at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 23-internal/Native Method) > at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 23-internal/Win32GraphicsEnvironment.java:95) > at sun.awt.Win32GraphicsEnvironment.(java.desktop at 23-internal/Win32GraphicsEnvironment.java:63) > at sun.awt.PlatformGraphicsInfo.createGE(java.desktop at 23-internal/PlatformGraphicsInfo.java:34) > at java.awt.GraphicsEnvironment$LocalGE.createGE(java.desktop at 23-internal/GraphicsEnvironment.java:93) > at java.awt.GraphicsEnvironment$LocalGE.(java.desktop at 23-internal/GraphicsEnvironment.java:84) > at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(java.desktop at 23-internal/GraphicsEnvironment.java:106) > at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) > at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44) > > > We better add an exception check to get rid of the JNI warning (and also of the test failure) . Hi Thomas, thanks for the review ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17224#issuecomment-1880845433 From mbaesken at openjdk.org Mon Jan 8 11:48:34 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 8 Jan 2024 11:48:34 GMT Subject: Integrated: JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows In-Reply-To: <5x-CDbd8ujYRMOO46Emn8ybYsqfkipVoHBnFylB1DTE=.fdc27846-0928-4901-84cc-98937c76e7d1@github.com> References: <5x-CDbd8ujYRMOO46Emn8ybYsqfkipVoHBnFylB1DTE=.fdc27846-0928-4901-84cc-98937c76e7d1@github.com> Message-ID: On Tue, 2 Jan 2024 15:03:12 GMT, Matthias Baesken wrote: > The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni , and shows on Windows server 2019 the following JNI warning , so the test fails on this Windows version. > > stdout: [WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV > at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 23-internal/Native Method) > at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 23-internal/Win32GraphicsEnvironment.java:95) > at sun.awt.Win32GraphicsEnvironment.(java.desktop at 23-internal/Win32GraphicsEnvironment.java:63) > at sun.awt.PlatformGraphicsInfo.createGE(java.desktop at 23-internal/PlatformGraphicsInfo.java:34) > at java.awt.GraphicsEnvironment$LocalGE.createGE(java.desktop at 23-internal/GraphicsEnvironment.java:93) > at java.awt.GraphicsEnvironment$LocalGE.(java.desktop at 23-internal/GraphicsEnvironment.java:84) > at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(java.desktop at 23-internal/GraphicsEnvironment.java:106) > at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) > at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44) > > > We better add an exception check to get rid of the JNI warning (and also of the test failure) . This pull request has now been integrated. Changeset: 71aac7a5 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/71aac7a5fbb9a32181ada1a04b6a9622fe939c59 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod 8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows Reviewed-by: rschmelter, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/17224 From jvanek at openjdk.org Mon Jan 8 13:08:30 2024 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Mon, 8 Jan 2024 13:08:30 GMT Subject: RFR: 8323170 - j2dbench is using outdated javac source/target to be able to build by itself Message-ID: This PR is fixig to-old values of javac source/target for jdk22. Note, that jdk21 suffers the same, only the target values have to be 8. I will be happy to backport this cange to jdk17 later. Note, that considering the rolling release of jdk and the reached threshold of bytecode compatibility, we will be forced to do this bump every STS, so best would be to drop this hardcoded limitation. As it obtains a bit more coding, I had filled the [JDK-8323169](https://bugs.openjdk.org/browse/JDK-8323169) - [ j2dbench need constant updating of javac source/target ](https://bugs.openjdk.org/browse/JDK-8323169) and will be happy to fit it for jdk asap once this direct fix bubbles to jdk21 ------------- Commit messages: - 8323170 - j2dbench is using outdated javac source/target to be able to build by itself Changes: https://git.openjdk.org/jdk/pull/17303/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17303&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323170 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/17303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17303/head:pull/17303 PR: https://git.openjdk.org/jdk/pull/17303 From aivanov at openjdk.org Mon Jan 8 13:50:29 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 8 Jan 2024 13:50:29 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 19:20:50 GMT, Sergey Bylokhov wrote: >> Hi Reviewers, >> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. >> >> Renjith. > > Can this patch be covered by the new test? > I think if condition missed `not (!)` (original code return _true_ if match and _false_ if docent, in Sergey sample `compareImages ` returns _true_ if not match and _false_ if match but `if (compareImages(destTest, destGold))` same. @mrserb hope this observation is correct. I believe Sergey's code in the test is correct. There are two images: `destTest` and `destGold`. The former is produced using the wrapper class, the latter is produced using the ICC color space. The wrapper `TestColorSpace` forwards all the calls to the `ICC_ColorSpace` that it wraps, therefore the transformed images must be *equal* because the applied transforms are absolutely the same. To avoid any confusion, I suggest renaming `compareImages` to `areImagesEqual` which leaves no ambiguity for its return value. I've updated the code in [commit `1788ef6`](https://github.com/aivanov-jdk/jdk/commit/1788ef69958cefef7c65fdf37607f0410b868aff). > Thank to @mrserb and @aivanov-jdk for your time and investigation, this helped to bring up few more issues. What do you suggest to cover these cases ? I'm not sure? We want the filter to take another path, there could be a list of filters applied, if I understand @mrserb correctly. Sergey could be able to provide a more detailed guidance. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16895#issuecomment-1881044740 From aivanov at openjdk.org Mon Jan 8 13:56:26 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 8 Jan 2024 13:56:26 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 13:48:10 GMT, Alexey Ivanov wrote: > To avoid any confusion, I suggest renaming `compareImages` to `areImagesEqual` which leaves no ambiguity for its return value. I've updated the code in [commit `1788ef6`](https://github.com/aivanov-jdk/jdk/commit/1788ef69958cefef7c65fdf37607f0410b868aff). @Renjithkannath, you can merge the changes I made into your branch using the following command: git pull https://github.com/aivanov-jdk/jdk.git renjith/sergey-8316497-colorConvertOp The command will merge the changes from the remote branch into your currently checked out branch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16895#issuecomment-1881055364 From kcr at openjdk.org Mon Jan 8 15:56:33 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 8 Jan 2024 15:56:33 GMT Subject: RFR: 8221261: deadlock of CInputMethod.characterIndexForPoint and webkit.InputMethodClientImpl.getLocationOffset In-Reply-To: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com> References: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com> Message-ID: On Fri, 22 Dec 2023 11:27:00 GMT, Johannes Bechberger wrote: > A dead-lock is caused by the interaction of MacOS, the AWTEventQueue and JavaFX when the users pressed the Caps Lock key while the AWTEventQueue is processing another event (more on this in the issue). The bug depends on the specific timing of the event sending and can apparently be prevented by finishing all incoming OS events directly while the LWCToolkit.invokeAndWait method is executed. > > This fix is tested and fixes the issue. > > I attached a small > [reproducer](https://github.com/openjdk/jdk/files/13751865/Archive.zip), just run it with `mvn install package javafx:run`. You're welcome. And thanks for getting the ball rolling. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17184#issuecomment-1881327529 From alexey.ivanov at oracle.com Mon Jan 8 16:59:40 2024 From: alexey.ivanov at oracle.com (Aleksei Ivanov) Date: Mon, 8 Jan 2024 16:59:40 +0000 Subject: Windows 11: Notifications vanishes after few seconds. In-Reply-To: References: Message-ID: Hi Davide, The bug that you reported has been moved to JDK project in JBS, you can view it as JDK-8315647 [1]. You should've received a link to it. > Is there a way to workaround this JDK bug? > I opened a bug report months ago but no one answered. What kind of answer did you expect to receive? You already asked this question on this mailing list in August [2]. I replied to your question [3]. Nothing has changed since August. It is not a bug in Java because a native Win32 app behaves the same way. I compiled and tested the sample [4], it behaves in Windows 11 as Java does: the displayed balloon notification does not go to notification centre. However, if I open notification centre while the balloon is displayed, it remains there. If I disable "Show notification banners" and leave "Show notifications in notification centre" enabled, the balloon goes directly to notification centre without displaying a banner. You can compile and test the sample too: git clone --filter=blob:none --sparse https://github.com/microsoft/Windows-classic-samples.git windows-samples cd windows-samples git sparse-checkout add Samples/Win7Samples/winui/shell/appshellintegration/NotificationIcon Navigate to the NotificationIcon folder and open NotificationIcon.sln in Visual Studio to compile and run it. If required, I can attach the compiled version of the application. I have closed JDK-8315647 as duplicate of JDK-8310352 [5]. -- Regards, Alexey [1] https://bugs.openjdk.org/browse/JDK-8315647 [2] https://mail.openjdk.org/pipermail/client-libs-dev/2023-August/014556.html [3] https://mail.openjdk.org/pipermail/client-libs-dev/2023-August/014557.html [4] https://learn.microsoft.com/en-us/windows/win32/shell/samples-notificationicon [5] https://bugs.openjdk.org/browse/JDK-8310352 On 2024-01-05 12:41, Davide Perini wrote: > With previous version of Windows and JDK notification sticked in the > Windows Notification Center forever until cancelled. > > Since the latest Windows/JDK, notifications vanishes automatically > after few seconds. > > ### Code to reproduce the problem > > ``` > import java.awt.*; > > public class Main { > ??? public static void main(String[] args) throws Exception { > ??????? SystemTray tray = SystemTray.getSystemTray(); > > ??????? Image image = Toolkit.getDefaultToolkit().createImage(""); > ??????? TrayIcon trayIcon = new TrayIcon(image); > ??????? trayIcon.setImageAutoSize(true); > ??????? trayIcon.setToolTip("Demo"); > ??????? tray.add(trayIcon); > > ??????? trayIcon.displayMessage("Hello, World", "notification demo", > TrayIcon.MessageType.INFO); > ??? } > } > ``` > > ### Expected Results > > Notifications sent from a TrayIcon should not vanish automatically > after few seconds but should stay in the notification center until > cancelled by the user. > > ### Actual Results > > Notifications sent from a TrayIcon vanishes automatically after few > seconds > > ### What Java Version are you using? > > 21.0.1 > > ### What is your operating system and platform? > > Windows 11 > > Is there a way to workaround this JDK bug? > I opened a bug report months ago but no one answered. > > Thanks > Davide From alexey.ivanov at oracle.com Mon Jan 8 17:24:27 2024 From: alexey.ivanov at oracle.com (Aleksei Ivanov) Date: Mon, 8 Jan 2024 17:24:27 +0000 Subject: How to prevent OpenJDK 11 from changing the Window size due to some internal reason In-Reply-To: References: Message-ID: <78213769-cda5-4123-96aa-ac995fff5fc2@oracle.com> Hi Martin, I'm afraid there's nothing I can add to the previous discussion in June 2023 [1]. I can only repeat Phil's statement [2], ?Wayland is not a supported platform for ANY version of JDK.? As Kevin suggested [3], you can try builds of the Wakefield project [4] or discuss it on Wakefield mailing list, you can even contribute a fix. At this time, ?Wayland is not a supported platform for ANY version of JDK.? -- Regards, Alexey [1] https://mail.openjdk.org/pipermail/client-libs-dev/2023-June/013155.html [2] https://mail.openjdk.org/pipermail/client-libs-dev/2023-June/013312.html [3] https://mail.openjdk.org/pipermail/client-libs-dev/2023-June/013137.html [4] https://openjdk.org/projects/wakefield/ On 2024-01-05 17:33, Martin Petzold wrote: > Dear all, > > most probably because of a bug in Weston implementation on Linux [1]: > if I detach and attach an HDMI head OR change via HDMI-CEC to standby > and back, my Java window is resized to 1x1 pixel automatically due to > some internal method. This is a serious bug to us. We have tested with > pure Weston application, and there was no such bug. Also we are using > XWayland because of Java. Currently we cannot backport that patch to > Weston 9 because of extensive changes in code. > > We tried to catch the event and resize back, but this was not stable. > Any other idea for a work-around? > > Is there any way to prevent OpenJDK 11 from resizing any window in > some internal method? I would like to have 100% control... > > [1] > https://gitlab.freedesktop.org/wayland/weston/-/commit/bcacd9ec5a924317416eabb65a6cd6767d5bfb94 > > > Thanks, > > Martin > From philip.race at oracle.com Mon Jan 8 17:48:05 2024 From: philip.race at oracle.com (Philip Race) Date: Mon, 8 Jan 2024 09:48:05 -0800 Subject: How to prevent OpenJDK 11 from changing the Window size due to some internal reason In-Reply-To: <78213769-cda5-4123-96aa-ac995fff5fc2@oracle.com> References: <78213769-cda5-4123-96aa-ac995fff5fc2@oracle.com> Message-ID: <1e3e2839-f2eb-453e-9619-52d8bdd68943@oracle.com> The release to try is not JDK 11u but current builds of JDK 22. https://jdk.java.net/22/ We are hopeful we will be able to support Wayland in X11 compatibility mode in that release using the work done in the Wakefield project and now integrated into JDK 22. But the first caveat is that means supporting it only on Ubuntu 22.04 and later. Nothing else (for now), and nothing earlier (ever). The 2nd caveat, is that in general (leaving aside Wayland) if there's a bug in the platform, it is not always possible to work around it in JDK. But if you can reproduce this on a desktop using Gnome 42 and later we can take a look to see if it occurs on Ubuntu and what might be done. -phil. On 1/8/24 9:24 AM, Aleksei Ivanov wrote: > Hi Martin, > > I'm afraid there's nothing I can add to the previous discussion in > June 2023 [1]. > > I can only repeat Phil's statement [2], ?Wayland is not a supported > platform for ANY version of JDK.? > > > As Kevin suggested [3], you can try builds of the Wakefield project > [4] or discuss it on Wakefield mailing list, you can even contribute a > fix. > > > At this time, ?Wayland is not a supported platform for ANY version of > JDK.? > From prr at openjdk.org Mon Jan 8 17:55:21 2024 From: prr at openjdk.org (Phil Race) Date: Mon, 8 Jan 2024 17:55:21 GMT Subject: RFR: 8323170 - j2dbench is using outdated javac source/target to be able to build by itself In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 13:03:22 GMT, Ji?? Van?k wrote: > This PR is fixig to-old values of javac source/target for jdk22. > Note, that jdk21 suffers the same, only the target values have to be 8. I will be happy to backport this cange to jdk17 later. > > Note, that considering the rolling release of jdk and the reached threshold of bytecode compatibility, we will be forced to do this bump every STS, so best would be to drop this hardcoded limitation. As it obtains a bit more coding, I had filled the [JDK-8323169](https://bugs.openjdk.org/browse/JDK-8323169) - [ j2dbench need constant updating of javac source/target ](https://bugs.openjdk.org/browse/JDK-8323169) and will be happy to fit it for jdk asap once this direct fix bubbles to jdk21 This has come up before. There might even be a "closed will not fix bug". This is deliberate. The intention of the j2dbench author was to be able to provide a stable base for the performance testing. As such until there is no JDK available on the planet that can use -source / target 1.7, there's no reason to change this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17303#issuecomment-1881561656 From rmahajan at openjdk.org Mon Jan 8 18:54:32 2024 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Mon, 8 Jan 2024 18:54:32 GMT Subject: RFR: 8322545: Declare newInsets as static in ThemeReader.cpp Message-ID: 8322545: Declare newInsets as static in ThemeReader.cpp ------------- Commit messages: - 8322545: Declare newInsets as static in ThemeReader.cpp Changes: https://git.openjdk.org/jdk/pull/17310/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17310&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322545 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17310/head:pull/17310 PR: https://git.openjdk.org/jdk/pull/17310 From perini.davide at dpsoftware.org Mon Jan 8 19:30:56 2024 From: perini.davide at dpsoftware.org (Davide Perini) Date: Mon, 8 Jan 2024 20:30:56 +0100 Subject: Windows 11: Notifications vanishes after few seconds. In-Reply-To: References: Message-ID: <9ecd6e22-3eb1-489b-b166-652a2fd1bf22@dpsoftware.org> Thanks for the Answer Aleksei, I have a lot of Windows apps that uses notifications without problems. even a simple python program like this works correctly. from win11toastimport toast toast('Hello','Click to run python script') is it possible that Microsoft changed the way how to create Notifications in Windows 11 and Java still uses the way it worked in Windows 7? Thanks Davide Il 08/01/2024 17:59, Aleksei Ivanov ha scritto: > Hi Davide, > > The bug that you reported has been moved to JDK project in JBS, you > can view it as JDK-8315647 [1]. You should've received a link to it. > >> Is there a way to workaround this JDK bug? >> I opened a bug report months ago but no one answered. > > What kind of answer did you expect to receive? > > You already asked this question on this mailing list in August [2]. I > replied to your question [3]. Nothing has changed since August. It is > not a bug in Java because a native Win32 app behaves the same way. > > I compiled and tested the sample [4], it behaves in Windows 11 as Java > does: the displayed balloon notification does not go to notification > centre. However, if I open notification centre while the balloon is > displayed, it remains there. If I disable "Show notification banners" > and leave "Show notifications in notification centre" enabled, the > balloon goes directly to notification centre without displaying a banner. > > You can compile and test the sample too: > > git clone --filter=blob:none --sparse > https://github.com/microsoft/Windows-classic-samples.git windows-samples > cd windows-samples > git sparse-checkout add > Samples/Win7Samples/winui/shell/appshellintegration/NotificationIcon > > Navigate to the NotificationIcon folder and open NotificationIcon.sln > in Visual Studio to compile and run it. > > If required, I can attach the compiled version of the application. > > > I have closed JDK-8315647 as duplicate of JDK-8310352 [5]. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serb at openjdk.org Mon Jan 8 19:35:22 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 8 Jan 2024 19:35:22 GMT Subject: RFR: 8322545: Declare newInsets as static in ThemeReader.cpp In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 18:45:05 GMT, Rajat Mahajan wrote: > 8322545: Declare newInsets as static in ThemeReader.cpp Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17310#pullrequestreview-1809890460 From aivanov at openjdk.org Mon Jan 8 19:40:23 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 8 Jan 2024 19:40:23 GMT Subject: RFR: 8322545: Declare newInsets as static in ThemeReader.cpp In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 18:45:05 GMT, Rajat Mahajan wrote: > 8322545: Declare newInsets as static in ThemeReader.cpp Marked as reviewed by aivanov (Reviewer). src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 1: > 1: /* Update the copyright year to 2024. ------------- PR Review: https://git.openjdk.org/jdk/pull/17310#pullrequestreview-1809896373 PR Review Comment: https://git.openjdk.org/jdk/pull/17310#discussion_r1445241482 From rmahajan at openjdk.org Mon Jan 8 19:48:36 2024 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Mon, 8 Jan 2024 19:48:36 GMT Subject: RFR: 8322545: Declare newInsets as static in ThemeReader.cpp [v2] In-Reply-To: References: Message-ID: > 8322545: Declare newInsets as static in ThemeReader.cpp Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: Update copyright year 2024 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17310/files - new: https://git.openjdk.org/jdk/pull/17310/files/a19c14f2..c11f9eb4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17310&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17310&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17310/head:pull/17310 PR: https://git.openjdk.org/jdk/pull/17310 From alexey.ivanov at oracle.com Mon Jan 8 19:55:52 2024 From: alexey.ivanov at oracle.com (Aleksei Ivanov) Date: Mon, 8 Jan 2024 19:55:52 +0000 Subject: Windows 11: Notifications vanishes after few seconds. In-Reply-To: <9ecd6e22-3eb1-489b-b166-652a2fd1bf22@dpsoftware.org> References: <9ecd6e22-3eb1-489b-b166-652a2fd1bf22@dpsoftware.org> Message-ID: <77e4ab4a-3813-4e83-b464-a4400dbe05f2@oracle.com> On 2024-01-08 19:30, Davide Perini wrote: > Thanks for the Answer Aleksei, > I have a lot of Windows apps that uses notifications without problems. > > even a simple python program like this works correctly. > from win11toastimport toast > > toast('Hello','Click to run python script') Python could use newer WinRT APIs [6], in particular ToastNotification class [7] which provide richer interface for the toast notifications. The package name ?toast? hints it uses the newer APIs. > is it possible that Microsoft changed the way how to create > Notifications in Windows 11 and Java still uses the way it worked in > Windows 7? Perhaps, Microsoft changed how they handle notifications in Windows 11. In Windows 10, the notifications created with a Java app remain in Action / Notification centre. Java uses Shell_NotifyIcon [8] function that has been available since Windows 95. -- Regards, Alexey [6] https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/ [7] https://learn.microsoft.com/en-us/uwp/api/windows.ui.notifications.toastnotification?view=winrt-22621 [8] https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shell_notifyiconw > > Thanks > Davide > > > > Il 08/01/2024 17:59, Aleksei Ivanov ha scritto: >> Hi Davide, >> >> The bug that you reported has been moved to JDK project in JBS, you >> can view it as JDK-8315647 [1]. You should've received a link to it. >> >>> Is there a way to workaround this JDK bug? >>> I opened a bug report months ago but no one answered. >> >> What kind of answer did you expect to receive? >> >> You already asked this question on this mailing list in August [2]. I >> replied to your question [3]. Nothing has changed since August. It is >> not a bug in Java because a native Win32 app behaves the same way. >> >> I compiled and tested the sample [4], it behaves in Windows 11 as >> Java does: the displayed balloon notification does not go to >> notification centre. However, if I open notification centre while the >> balloon is displayed, it remains there. If I disable "Show >> notification banners" and leave "Show notifications in notification >> centre" enabled, the balloon goes directly to notification centre >> without displaying a banner. >> >> You can compile and test the sample too: >> >> git clone --filter=blob:none --sparse >> https://github.com/microsoft/Windows-classic-samples.git windows-samples >> cd windows-samples >> git sparse-checkout add >> Samples/Win7Samples/winui/shell/appshellintegration/NotificationIcon >> >> Navigate to the NotificationIcon folder and open NotificationIcon.sln >> in Visual Studio to compile and run it. >> >> If required, I can attach the compiled version of the application. >> >> >> I have closed JDK-8315647 as duplicate of JDK-8310352 [5]. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aivanov at openjdk.org Mon Jan 8 20:01:31 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 8 Jan 2024 20:01:31 GMT Subject: RFR: 8322545: Declare newInsets as static in ThemeReader.cpp [v2] In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 19:48:36 GMT, Rajat Mahajan wrote: >> Since newInsets() function is a helper function used in ThemeReader.cpp only , this change declares it as static. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year 2024 Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17310#pullrequestreview-1809923005 From rmahajan at openjdk.org Mon Jan 8 20:01:32 2024 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Mon, 8 Jan 2024 20:01:32 GMT Subject: Integrated: 8322545: Declare newInsets as static in ThemeReader.cpp In-Reply-To: References: Message-ID: <9ldmSVI9k_FrJMltWirT13APVhodw1TYtdpjRTjw8XE=.77a7a83f-5777-4f36-843f-b1e2c801bedd@github.com> On Mon, 8 Jan 2024 18:45:05 GMT, Rajat Mahajan wrote: > Since newInsets() function is a helper function used in ThemeReader.cpp only , this change declares it as static. This pull request has now been integrated. Changeset: d78e8dab Author: Rajat Mahajan Committer: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/d78e8dab93868c1212c95e165f556ad89a0b6920 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8322545: Declare newInsets as static in ThemeReader.cpp Reviewed-by: serb, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/17310 From philip.race at oracle.com Mon Jan 8 20:05:01 2024 From: philip.race at oracle.com (Philip Race) Date: Mon, 8 Jan 2024 12:05:01 -0800 Subject: the easiest ways to play an audio clip are the discouraged ones In-Reply-To: References: Message-ID: Mark, It does seem like there's an ease of use gap here that will widen considerably when Applet is removed. The Applet? AudioClip code is actually built on top of javax.sound public APIs so we should at least find an alternative place to surface that functionality. I submitted https://bugs.openjdk.org/browse/JDK-8323215 -phil. On 1/1/24 10:27 PM, mark.yagnatinsky at barclays.com wrote: > > Thanks Julian (and sorry for messing up the message threading? I?ll > try not to do that next time). > > It looks like you built a ?full-fledged? audio player, and it took > hundreds of lines of code. > > Maybe that?s reasonable for a full-fledged audio player. > > But it?s unfortunate that even a basic ?fire and forget? feature to > play an audio file should take lots of lines. > > This message is for information purposes only. It is not a > recommendation, advice, offer or solicitation to buy or sell a product > or service, nor an official confirmation of any transaction. It is > directed at persons who are professionals and is intended for the > recipient(s) only. It is not directed at retail customers. This > message is subject to the terms at: > https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. > > For important disclosures, please see: > https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html > regarding marketing commentary from Barclays Sales and/or Trading > desks, who are active market participants; > https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html > regarding our standard terms for Barclays Corporate and Investment > Bank where we trade with you in principal-to-principal wholesale > markets transactions; and in respect to Barclays Research, including > disclosures relating to specific issuers, see: > http://publicresearch.barclays.com. > __________________________________________________________________________________ > > If you are incorporated or operating in Australia, read these > important disclosures: > https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html. > __________________________________________________________________________________ > For more details about how we use personal information, see our > privacy notice: > https://www.cib.barclays/disclosures/personal-information-use.html. > __________________________________________________________________________________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From perini.davide at dpsoftware.org Mon Jan 8 21:05:51 2024 From: perini.davide at dpsoftware.org (Davide Perini) Date: Mon, 8 Jan 2024 22:05:51 +0100 Subject: Windows 11: Notifications vanishes after few seconds. In-Reply-To: <77e4ab4a-3813-4e83-b464-a4400dbe05f2@oracle.com> References: <9ecd6e22-3eb1-489b-b166-652a2fd1bf22@dpsoftware.org> <77e4ab4a-3813-4e83-b464-a4400dbe05f2@oracle.com> Message-ID: <310e0659-fd0f-45c7-b462-7755a0144c34@dpsoftware.org> Thanks for the explanation?Aleksei but can you explain me what is the OpenJDK direction please? Suppose that you have a feature like this one, a simple notifications. Java worked well with Windows notifications until Win10, then Microsoft changed the APIs for notifications in Win11. Isn't OpenJDK supposed to adapt to the new Windows APIs? Does OpenJDK supports Windows 11 or not? It's a little "weird" to close an issue by saying that Java uses the same way to do the same thing since Windows 95 and that it's a Microsoft problem if they changed the way to send notifications to the OS. Java should support Microsoft Windows, it isn't Microsoft Windows that should support Java, isn't it? Other languages adapted their APIs for the new notifications system, like everyone should expect from a modern language, after 2 years from the release of Win 11, Oracle says that it worked since Windows 95, so it is ok to have a broken API in JDK because it worked before, they are the ones who broke it (Microsoft). Does Java offers a correct way to send Notifications in Win10? Answer: Yes Does Java offers a correct way to send Notifications in Win11? Answer: No Does other languages offers a correct way to send Notifications in Win11? Answer: Yes Does current JDK APIs works as expected in Win11? Answer: No because JDK uses an old API born with Win95 (30 years ago + or -) with a new OS born in 2021, this results in an unexcpected behaviour that doesn't work as supposed initially by the API. In the bug report you wrote: "I can't see what Java can do to change the behaviour." The answer is: "By implementing the correct API for the correct OS". Java is currently not able to correctly send a Notification in Windows 11. I see a bug there, if you don't see it, I'm pretty worried of the new JDK direction. Thanks Davide Il 08/01/2024 20:55, Aleksei Ivanov ha scritto: > On 2024-01-08 19:30, Davide Perini wrote: >> Thanks for the Answer Aleksei, >> I have a lot of Windows apps that uses notifications without problems. >> >> even a simple python program like this works correctly. >> from win11toastimport toast >> >> toast('Hello','Click to run python script') > > Python could use newer WinRT APIs [6], in particular ToastNotification > class [7] which provide richer interface for the toast notifications. > The package name ?toast? hints it uses the newer APIs. > >> is it possible that Microsoft changed the way how to create >> Notifications in Windows 11 and Java still uses the way it worked in >> Windows 7? > > Perhaps, Microsoft changed how they handle notifications in Windows > 11. In Windows 10, the notifications created with a Java app remain in > Action / Notification centre. > > Java uses Shell_NotifyIcon [8] function that has been available since > Windows 95. > > -- > Regards, > Alexey > > [6] https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/ > [7] > https://learn.microsoft.com/en-us/uwp/api/windows.ui.notifications.toastnotification?view=winrt-22621 > [8] > https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shell_notifyiconw > >> >> Thanks >> Davide >> >> >> >> Il 08/01/2024 17:59, Aleksei Ivanov ha scritto: >>> Hi Davide, >>> >>> The bug that you reported has been moved to JDK project in JBS, you >>> can view it as JDK-8315647 [1]. You should've received a link to it. >>> >>>> Is there a way to workaround this JDK bug? >>>> I opened a bug report months ago but no one answered. >>> >>> What kind of answer did you expect to receive? >>> >>> You already asked this question on this mailing list in August [2]. >>> I replied to your question [3]. Nothing has changed since August. It >>> is not a bug in Java because a native Win32 app behaves the same way. >>> >>> I compiled and tested the sample [4], it behaves in Windows 11 as >>> Java does: the displayed balloon notification does not go to >>> notification centre. However, if I open notification centre while >>> the balloon is displayed, it remains there. If I disable "Show >>> notification banners" and leave "Show notifications in notification >>> centre" enabled, the balloon goes directly to notification centre >>> without displaying a banner. >>> >>> You can compile and test the sample too: >>> >>> git clone --filter=blob:none --sparse >>> https://github.com/microsoft/Windows-classic-samples.git >>> windows-samples >>> cd windows-samples >>> git sparse-checkout add >>> Samples/Win7Samples/winui/shell/appshellintegration/NotificationIcon >>> >>> Navigate to the NotificationIcon folder and open >>> NotificationIcon.sln in Visual Studio to compile and run it. >>> >>> If required, I can attach the compiled version of the application. >>> >>> >>> I have closed JDK-8315647 as duplicate of JDK-8310352 [5]. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Jan 8 23:38:29 2024 From: philip.race at oracle.com (Philip Race) Date: Mon, 8 Jan 2024 15:38:29 -0800 Subject: Integrated: JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows In-Reply-To: References: <5x-CDbd8ujYRMOO46Emn8ybYsqfkipVoHBnFylB1DTE=.fdc27846-0928-4901-84cc-98937c76e7d1@github.com> Message-ID: <8a61d5c2-b178-4399-8bc3-859b9c14c6b2@oracle.com> I have two concerns with this integrated fix (1) Not a single developer who works on the client technology approved this. Client devs don't go unilaterally pushing fixes in hotspot without someone from hotspot approving. Even if JDK has no formal way to? verify that, it is really not acceptable to have this happen. And I have raised this before ! https://mail.openjdk.org/pipermail/client-libs-dev/2023-July/014074.html (2) This fix was proposed before and discussed here https://mail.openjdk.org/pipermail/client-libs-dev/2021-November/001116.html where it was requested that it be withdrawn until there is an actual understanding of the reason for the exception which has NEVER been seen in our testing here and once understood rather than suppressing it needs an actual fix and yet here it is again in the form previously rejected. This fix should be backed out. Please send out a PR to do so. -phil. On 1/8/24 3:48 AM, Matthias Baesken wrote: > On Tue, 2 Jan 2024 15:03:12 GMT, Matthias Baesken wrote: > >> The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni , and shows on Windows server 2019 the following JNI warning , so the test fails on this Windows version. >> >> stdout: [WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV >> at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 23-internal/Native Method) >> at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 23-internal/Win32GraphicsEnvironment.java:95) >> at sun.awt.Win32GraphicsEnvironment.(java.desktop at 23-internal/Win32GraphicsEnvironment.java:63) >> at sun.awt.PlatformGraphicsInfo.createGE(java.desktop at 23-internal/PlatformGraphicsInfo.java:34) >> at java.awt.GraphicsEnvironment$LocalGE.createGE(java.desktop at 23-internal/GraphicsEnvironment.java:93) >> at java.awt.GraphicsEnvironment$LocalGE.(java.desktop at 23-internal/GraphicsEnvironment.java:84) >> at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(java.desktop at 23-internal/GraphicsEnvironment.java:106) >> at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) >> at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44) >> >> >> We better add an exception check to get rid of the JNI warning (and also of the test failure) . > This pull request has now been integrated. > > Changeset: 71aac7a5 > Author: Matthias Baesken > URL: https://git.openjdk.org/jdk/commit/71aac7a5fbb9a32181ada1a04b6a9622fe939c59 > Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod > > 8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows > > Reviewed-by: rschmelter, stuefe > > ------------- > > PR: https://git.openjdk.org/jdk/pull/17224 From rkannathpari at openjdk.org Tue Jan 9 05:12:51 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 9 Jan 2024 05:12:51 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v12] In-Reply-To: References: Message-ID: <-ogs7WvU8NImiII0ImWGU4gKgsR0YMmx6vunbYfsYn4=.d5533311-aed9-4051-bf9c-a1a392c41b75@github.com> > Hi Reviewers, > There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. > > Renjith. Renjith Kannath Pariyangad has updated the pull request incrementally with three additional commits since the last revision: - Rename compareImages to areImagesEqual compareImages is ambiguous. Does it return true when images equal? The name areImagesEqual clearly conveys the intended return values, one doesn't need to look into its code to understand what's expected. Thus, the return values in the method are reversed, and the condition of the test is negated. - Improvements to Sergey's test Use enum instead of two booleans to select ColorSpace. Create the ColorSpace and pass it to createImage. Use constants to control the size of the image. Print the position of the failed pixel. - 8316497: Sergey's version of the non-ICC test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16895/files - new: https://git.openjdk.org/jdk/pull/16895/files/56ce5c5e..1788ef69 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=10-11 Stats: 60 lines in 1 file changed: 28 ins; 6 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/16895.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16895/head:pull/16895 PR: https://git.openjdk.org/jdk/pull/16895 From rkannathpari at openjdk.org Tue Jan 9 05:18:25 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 9 Jan 2024 05:18:25 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 13:53:21 GMT, Alexey Ivanov wrote: >>> I think if condition missed `not (!)` (original code return _true_ if match and _false_ if docent, in Sergey sample `compareImages ` returns _true_ if not match and _false_ if match but `if (compareImages(destTest, destGold))` same. @mrserb hope this observation is correct. >> >> I believe Sergey's code in the test is correct. There are two images: `destTest` and `destGold`. The former is produced using the wrapper class, the latter is produced using the ICC color space. The wrapper `TestColorSpace` forwards all the calls to the `ICC_ColorSpace` that it wraps, therefore the transformed images must be *equal* because the applied transforms are absolutely the same. >> >> To avoid any confusion, I suggest renaming `compareImages` to `areImagesEqual` which leaves no ambiguity for its return value. I've updated the code in [commit `1788ef6`](https://github.com/aivanov-jdk/jdk/commit/1788ef69958cefef7c65fdf37607f0410b868aff). >> >>> Thank to @mrserb and @aivanov-jdk for your time and investigation, this helped to bring up few more issues. What do you suggest to cover these cases ? >> >> I'm not sure? We want the filter to take another path, there could be a list of filters applied, if I understand @mrserb correctly. Sergey could be able to provide a more detailed guidance. > >> To avoid any confusion, I suggest renaming `compareImages` to `areImagesEqual` which leaves no ambiguity for its return value. I've updated the code in [commit `1788ef6`](https://github.com/aivanov-jdk/jdk/commit/1788ef69958cefef7c65fdf37607f0410b868aff). > > @Renjithkannath, you can merge the changes I made into your branch using the following command: > > > git pull https://github.com/aivanov-jdk/jdk.git renjith/sergey-8316497-colorConvertOp > > > The command will merge the changes from the remote branch into your currently checked out branch. @aivanov-jdk Thank you for sharing the updated code I have merged your changes from the branch and pushed in. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16895#issuecomment-1882425761 From psadhukhan at openjdk.org Tue Jan 9 07:03:23 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 9 Jan 2024 07:03:23 GMT Subject: RFR: 8264102: JTable Keyboards Navigation differs with Test Instructions. [v4] In-Reply-To: References: Message-ID: <5KY76Np-sM8dZxsGGPcEWl167PeVS5nalzm-hAins8I=.619bdfda-a5f7-43e8-89cc-3c4cc6a038de@github.com> On Mon, 8 Jan 2024 09:47:50 GMT, Tejesh R wrote: >> Updated the actions for "ctrl shift DOWN" to "`selectLastRowExtendSelection`" and "ctrl shift UP", "`selectFirstRowExtendSelection`" in Basic and other Look and feel. Tested in CI and no regressions found. >> Test to be used - [javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java) > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Removing Metal specific L&F from test Looks ok to me... Only thing is...If it could be done without much trouble, I would have listed the combinations of keyboard navigation in the test itself instead of directing to 4112270 ------------- Marked as reviewed by psadhukhan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17236#pullrequestreview-1810511365 From tr at openjdk.org Tue Jan 9 07:09:23 2024 From: tr at openjdk.org (Tejesh R) Date: Tue, 9 Jan 2024 07:09:23 GMT Subject: RFR: 8264102: JTable Keyboards Navigation differs with Test Instructions. [v4] In-Reply-To: <5KY76Np-sM8dZxsGGPcEWl167PeVS5nalzm-hAins8I=.619bdfda-a5f7-43e8-89cc-3c4cc6a038de@github.com> References: <5KY76Np-sM8dZxsGGPcEWl167PeVS5nalzm-hAins8I=.619bdfda-a5f7-43e8-89cc-3c4cc6a038de@github.com> Message-ID: On Tue, 9 Jan 2024 07:00:59 GMT, Prasanta Sadhukhan wrote: > Looks ok to me... Only thing is...If it could be done without much trouble, I would have listed the combinations of keyboard navigation in the test itself instead of directing to 4112270 Sure, can do that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17236#issuecomment-1882516667 From tr at openjdk.org Tue Jan 9 07:57:57 2024 From: tr at openjdk.org (Tejesh R) Date: Tue, 9 Jan 2024 07:57:57 GMT Subject: RFR: 8264102: JTable Keyboards Navigation differs with Test Instructions. [v5] In-Reply-To: References: Message-ID: > Updated the actions for "ctrl shift DOWN" to "`selectLastRowExtendSelection`" and "ctrl shift UP", "`selectFirstRowExtendSelection`" in Basic and other Look and feel. Tested in CI and no regressions found. > Test to be used - [javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java) Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated test instructions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17236/files - new: https://git.openjdk.org/jdk/pull/17236/files/ccd5fd5b..578d14b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17236&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17236&range=03-04 Stats: 38 lines in 1 file changed: 34 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17236.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17236/head:pull/17236 PR: https://git.openjdk.org/jdk/pull/17236 From serb at openjdk.org Tue Jan 9 08:58:33 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 9 Jan 2024 08:58:33 GMT Subject: RFR: 8323210: Update the usage of cmsFLAGS_COPY_ALPHA Message-ID: <0nHbRf6TugFDn_1am4ne2IqrO57EYvDblweDrdsoKyk=.50cfd90c-e1e6-4c0a-a41d-b2bd07933888@github.com> Implementation of cmsFLAGS_COPY_ALPHA in littlecms 2.16 is changed to throw an exception: - if the number of extra channels in src and dst are different. - If dst does not have an alpha but src has - If src does not have an alpha but dst has Exception does not occurred if the number of extra channels are the same(even if both are zero) ------------- Commit messages: - Update ColCvtAlphaDifferentSrcDst.java - 8323210: Update the usage of cmsFLAGS_COPY_ALPHA Changes: https://git.openjdk.org/jdk/pull/17320/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17320&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323210 Stats: 8 lines in 2 files changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17320.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17320/head:pull/17320 PR: https://git.openjdk.org/jdk/pull/17320 From jvanek at openjdk.org Tue Jan 9 09:34:21 2024 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Tue, 9 Jan 2024 09:34:21 GMT Subject: RFR: 8323170 - j2dbench is using outdated javac source/target to be able to build by itself In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 13:03:22 GMT, Ji?? Van?k wrote: > This PR is fixig to-old values of javac source/target for jdk22. > Note, that jdk21 suffers the same, only the target values have to be 8. I will be happy to backport this cange to jdk17 later. > > Note, that considering the rolling release of jdk and the reached threshold of bytecode compatibility, we will be forced to do this bump every STS, so best would be to drop this hardcoded limitation. As it obtains a bit more coding, I had filled the [JDK-8323169](https://bugs.openjdk.org/browse/JDK-8323169) - [ j2dbench need constant updating of javac source/target ](https://bugs.openjdk.org/browse/JDK-8323169) and will be happy to fit it for jdk asap once this direct fix bubbles to jdk21 Hello! Thanx for a reply! This could have been true when the source/target was rolling supper slowly, but now, with new jdk every half a year, this is literally forcing anybody who would like to j2dbenchmark newer jdks to substitute source/target or to compile by another jdk where non of that gave sense to me. I think j2dbench should go in spirit of in-tree jtregs and shold be ok for jdk it is cloned from. Anybody who wishes to run it on older jdk, can clone it from older jdk. One can argue that different j2dbenchmarks will produce different results, but j2dbench is completed project, and even bumping source/targe is not exactly well spent time. In addition user knows what jdk they are will be comparing, and select base j2dbench accordingly. I think it would be super rare to compare jdks 7-22 in one batch. If that would be a target, a bit of coding would be expected anyway. But you know better. Feel free to close (or tell me to close) this PR/bug . (Actually I think I was fixing it already once in past, from 1.4 to 1.7, but I had not found a commit nor pr so maybe that is what was closed "want fix") If I may dare to discuss furthermore, then I would like to persuade you that j2dbench should really be compilable with jdk it is part of. By keeping the source/target (or change it to release), or by dropping source/target completely, or to make it adjustable by better way then repalcing in build files (in which case the sane default, should be still compatible with jdk it iwas cloned from) . The proper sane defaults will nicely enforce clean code. To drop it completely may actually bring wider changes, and maybe indeed affect the accuracy (will try if that will be the case) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17303#issuecomment-1882704706 From rkannathpari at openjdk.org Tue Jan 9 11:11:38 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 9 Jan 2024 11:11:38 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v13] In-Reply-To: References: Message-ID: > Hi Reviewers, > There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. > > Renjith. Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Fixed other two typos ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16895/files - new: https://git.openjdk.org/jdk/pull/16895/files/1788ef69..6d47f16b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=11-12 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16895.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16895/head:pull/16895 PR: https://git.openjdk.org/jdk/pull/16895 From rkannathpari at openjdk.org Tue Jan 9 11:11:39 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 9 Jan 2024 11:11:39 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v6] In-Reply-To: References: <_3OD2Vf0d-YPDoO0dwtKmDWzsD4mu6shTSqwrJPUCnA=.e198abf8-6190-47a1-bcbe-39c0bc7ba432@github.com> <8doF19-CcJAJ33FRt0PnKAUy2HOkZL1ddodJOgHT56A=.ae5ad0b8-77e2-498a-8803-e2b38439c08a@github.com> <6akE9WWZUu9ZHK5Drnv79JJTMvx9FAbfGYPCZTZ7ASE=.92a2a457-5a69-46fd-ba6c-e0a8085b4825@github.com> <4553eVeRmo3q4n0NFkgLZpOfQOaRKWnuDNovobCAdFw=.a65e414c-8f12-40b3-8bcc-a87b71407fb7@github.com> Message-ID: On Fri, 5 Jan 2024 16:16:51 GMT, Alexey Ivanov wrote: >> @mrserb for avoiding _ArrayIndexOutOfBoundsException_ I have modified `CS_GRAY `with `CS_LINEAR_RGB ` for making same number of channels. But the test passed irrespective of fix. >> Do you find any alternative way to fail the test with out fix ? > >> There are at least two similar copy/paste typos. In the next line >> >> https://github.com/openjdk/jdk/blob/f73dbb985823d2d59bfcff8ba6951a0d9eb2cefc/src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java#L771 >> we use the srcNumComp which is the number of components for the incoming source color space, but the loop should be done over iccSrcNumComp which is a number of components of the "intermidiate" source color space. Similar issue is in the next line but for the destination >> >> https://github.com/openjdk/jdk/blob/f73dbb985823d2d59bfcff8ba6951a0d9eb2cefc/src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java#L785 >> >> It is possible that these compensate/affects each other and produce some non-completly broken result. The test from the comment above start to pass after these will be fixed. > > Indeed, these should be `iccSrcNumComp` and `iccDstNumComp` according to number of components in the allocated arrays. Modifying these lines make the test pass. > >> Since we found a few bugs in this code path, it will be useful to check the code path in the nonICCBIFilter where the CSList is not null(the intermidiate transform is wrapper as well, as of now our test uses the built-in ColorSpace.getInstance(CS_sRGB)) > > Agree, another (unit) test is required which exercises other code paths. These typos also fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1445952849 From aivanov at openjdk.org Tue Jan 9 14:09:26 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 9 Jan 2024 14:09:26 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v13] In-Reply-To: References: Message-ID: On Tue, 9 Jan 2024 11:11:38 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. >> >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Fixed other two typos Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16895#pullrequestreview-1811221529 From clanger at openjdk.org Tue Jan 9 14:14:33 2024 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 9 Jan 2024 14:14:33 GMT Subject: RFR: JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows In-Reply-To: <5x-CDbd8ujYRMOO46Emn8ybYsqfkipVoHBnFylB1DTE=.fdc27846-0928-4901-84cc-98937c76e7d1@github.com> References: <5x-CDbd8ujYRMOO46Emn8ybYsqfkipVoHBnFylB1DTE=.fdc27846-0928-4901-84cc-98937c76e7d1@github.com> Message-ID: On Tue, 2 Jan 2024 15:03:12 GMT, Matthias Baesken wrote: > The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni , and shows on Windows server 2019 the following JNI warning , so the test fails on this Windows version. > > stdout: [WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV > at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 23-internal/Native Method) > at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 23-internal/Win32GraphicsEnvironment.java:95) > at sun.awt.Win32GraphicsEnvironment.(java.desktop at 23-internal/Win32GraphicsEnvironment.java:63) > at sun.awt.PlatformGraphicsInfo.createGE(java.desktop at 23-internal/PlatformGraphicsInfo.java:34) > at java.awt.GraphicsEnvironment$LocalGE.createGE(java.desktop at 23-internal/GraphicsEnvironment.java:93) > at java.awt.GraphicsEnvironment$LocalGE.(java.desktop at 23-internal/GraphicsEnvironment.java:84) > at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(java.desktop at 23-internal/GraphicsEnvironment.java:106) > at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) > at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44) > > > We better add an exception check to get rid of the JNI warning (and also of the test failure) . Hi Phil, first of all, I guess it was an oversight of Matthias to not wait for some client libs representative to have a look. I agree that the integrated fix is potentially hiding a real issue which should rather be analysed a bit deeper. @MBaesken , can you please take care of the revert and then install a diagnosis patch in our test system that would print the exception and then bail out. That way we could maybe understand more about the actual root cause? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17224#issuecomment-1883120805 From mbaesken at openjdk.org Tue Jan 9 16:26:32 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 9 Jan 2024 16:26:32 GMT Subject: RFR: JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows In-Reply-To: <5x-CDbd8ujYRMOO46Emn8ybYsqfkipVoHBnFylB1DTE=.fdc27846-0928-4901-84cc-98937c76e7d1@github.com> References: <5x-CDbd8ujYRMOO46Emn8ybYsqfkipVoHBnFylB1DTE=.fdc27846-0928-4901-84cc-98937c76e7d1@github.com> Message-ID: On Tue, 2 Jan 2024 15:03:12 GMT, Matthias Baesken wrote: > The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni , and shows on Windows server 2019 the following JNI warning , so the test fails on this Windows version. > > stdout: [WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV > at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 23-internal/Native Method) > at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 23-internal/Win32GraphicsEnvironment.java:95) > at sun.awt.Win32GraphicsEnvironment.(java.desktop at 23-internal/Win32GraphicsEnvironment.java:63) > at sun.awt.PlatformGraphicsInfo.createGE(java.desktop at 23-internal/PlatformGraphicsInfo.java:34) > at java.awt.GraphicsEnvironment$LocalGE.createGE(java.desktop at 23-internal/GraphicsEnvironment.java:93) > at java.awt.GraphicsEnvironment$LocalGE.(java.desktop at 23-internal/GraphicsEnvironment.java:84) > at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(java.desktop at 23-internal/GraphicsEnvironment.java:106) > at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) > at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44) > > > We better add an exception check to get rid of the JNI warning (and also of the test failure) . Okay I can back it out, will create a JBS issue for that. However the current JNI warning gives us no real info, just creates noise in our test infrastructure; the ExceptionDescribe should be better : "Prints an exception and a backtrace of the stack to a system error-reporting channel, such as stderr. This is a convenience routine provided for debugging." https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html ------------- PR Comment: https://git.openjdk.org/jdk/pull/17224#issuecomment-1883367630 From stuefe at openjdk.org Tue Jan 9 17:22:36 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 9 Jan 2024 17:22:36 GMT Subject: RFR: JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows In-Reply-To: <5x-CDbd8ujYRMOO46Emn8ybYsqfkipVoHBnFylB1DTE=.fdc27846-0928-4901-84cc-98937c76e7d1@github.com> References: <5x-CDbd8ujYRMOO46Emn8ybYsqfkipVoHBnFylB1DTE=.fdc27846-0928-4901-84cc-98937c76e7d1@github.com> Message-ID: On Tue, 2 Jan 2024 15:03:12 GMT, Matthias Baesken wrote: > The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni , and shows on Windows server 2019 the following JNI warning , so the test fails on this Windows version. > > stdout: [WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV > at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 23-internal/Native Method) > at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 23-internal/Win32GraphicsEnvironment.java:95) > at sun.awt.Win32GraphicsEnvironment.(java.desktop at 23-internal/Win32GraphicsEnvironment.java:63) > at sun.awt.PlatformGraphicsInfo.createGE(java.desktop at 23-internal/PlatformGraphicsInfo.java:34) > at java.awt.GraphicsEnvironment$LocalGE.createGE(java.desktop at 23-internal/GraphicsEnvironment.java:93) > at java.awt.GraphicsEnvironment$LocalGE.(java.desktop at 23-internal/GraphicsEnvironment.java:84) > at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(java.desktop at 23-internal/GraphicsEnvironment.java:106) > at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) > at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44) > > > We better add an exception check to get rid of the JNI warning (and also of the test failure) . Hi Phil, sorry for this, this was not bad intent, just a plain mistake. It is somewhat difficult to remember the exact review rules per project. Help from Skara would certainly be useful here. Cheers, Thomas ------------- PR Comment: https://git.openjdk.org/jdk/pull/17224#issuecomment-1883471813 From prr at openjdk.org Tue Jan 9 20:41:22 2024 From: prr at openjdk.org (Phil Race) Date: Tue, 9 Jan 2024 20:41:22 GMT Subject: RFR: 8323210: Update the usage of cmsFLAGS_COPY_ALPHA In-Reply-To: <0nHbRf6TugFDn_1am4ne2IqrO57EYvDblweDrdsoKyk=.50cfd90c-e1e6-4c0a-a41d-b2bd07933888@github.com> References: <0nHbRf6TugFDn_1am4ne2IqrO57EYvDblweDrdsoKyk=.50cfd90c-e1e6-4c0a-a41d-b2bd07933888@github.com> Message-ID: On Tue, 9 Jan 2024 07:21:26 GMT, Sergey Bylokhov wrote: > Implementation of cmsFLAGS_COPY_ALPHA in littlecms 2.16 is changed to throw an exception: > - if the number of extra channels in src and dst are different. > - If dst does not have an alpha but src has > - If src does not have an alpha but dst has > > Exception does not occurred if the number of extra channels are the same(even if both are zero) Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17320#pullrequestreview-1811970243 From achung at openjdk.org Tue Jan 9 21:12:32 2024 From: achung at openjdk.org (Alisen Chung) Date: Tue, 9 Jan 2024 21:12:32 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) Message-ID: SunToolkit.java is trying to post an event on the TrayIcon appContext, but the TrayIcon was already removed by the test, causing an error. The fix is to make SunToolkit skip posting the event if appContext is null. The test is also updated to remove applet usage and use PassFailJFrame instead. ------------- Commit messages: - removed applet usage in test, fixed event posted on wrong app context bug Changes: https://git.openjdk.org/jdk/pull/17329/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17329&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316931 Stats: 274 lines in 3 files changed: 36 ins; 206 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/17329.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17329/head:pull/17329 PR: https://git.openjdk.org/jdk/pull/17329 From swinxythecat at gmail.com Tue Jan 9 21:50:24 2024 From: swinxythecat at gmail.com (SWinxy) Date: Tue, 9 Jan 2024 16:50:24 -0500 Subject: Windows 11: Notifications vanishes after few seconds. In-Reply-To: <310e0659-fd0f-45c7-b462-7755a0144c34@dpsoftware.org> References: <9ecd6e22-3eb1-489b-b166-652a2fd1bf22@dpsoftware.org> <77e4ab4a-3813-4e83-b464-a4400dbe05f2@oracle.com> <310e0659-fd0f-45c7-b462-7755a0144c34@dpsoftware.org> Message-ID: Back in mid-2021 I submitted a feature request to add new APIs for toast notifications on macOS and Windows *without* using SystemTray. It's something I'd like to implement. Apple introduced its notification APIs in macOS 10.8. Never worked with the WinRT before, though. SWinxy On Mon, Jan 8, 2024 at 4:06?PM Davide Perini wrote: > Thanks for the explanation Aleksei > but can you explain me what is the OpenJDK direction please? > > Suppose that you have a feature like this one, a simple notifications. > Java worked well with Windows notifications until Win10, > then Microsoft changed the APIs for notifications in Win11. > > Isn't OpenJDK supposed to adapt to the new Windows APIs? > > Does OpenJDK supports Windows 11 or not? > > It's a little "weird" to close an issue by saying that Java uses the same > way to do the same thing since Windows 95 > and that it's a Microsoft problem if they changed the way to send > notifications to the OS. > > Java should support Microsoft Windows, it isn't Microsoft Windows that > should support Java, > isn't it? > > Other languages adapted their APIs for the new notifications system, like > everyone should expect from a modern language, > after 2 years from the release of Win 11, > Oracle says that it worked since Windows 95, so it is ok to have a broken > API in JDK because it worked before, they are the ones who broke it > (Microsoft). > > Does Java offers a correct way to send Notifications in Win10? Answer: Yes > Does Java offers a correct way to send Notifications in Win11? Answer: No > Does other languages offers a correct way to send Notifications in Win11? > Answer: Yes > Does current JDK APIs works as expected in Win11? > Answer: No because JDK uses an old API born with Win95 (30 years ago + or > -) with a new OS born in 2021, this results in an unexcpected behaviour > that doesn't work as supposed initially by the API. > > In the bug report you wrote: > "I can't see what Java can do to change the behaviour." > > The answer is: > "By implementing the correct API for the correct OS". > > > Java is currently not able to correctly send a Notification in Windows 11. > > > I see a bug there, if you don't see it, > I'm pretty worried of the new JDK direction. > > Thanks > Davide > > > Il 08/01/2024 20:55, Aleksei Ivanov ha scritto: > > On 2024-01-08 19:30, Davide Perini wrote: > > Thanks for the Answer Aleksei, > I have a lot of Windows apps that uses notifications without problems. > > even a simple python program like this works correctly. > > from win11toast import toast > > toast('Hello', 'Click to run python script') > > > Python could use newer WinRT APIs [6], in particular ToastNotification > class [7] which provide richer interface for the toast notifications. The > package name ?toast? hints it uses the newer APIs. > > is it possible that Microsoft changed the way how to create Notifications > in Windows 11 and Java still uses the way it worked in Windows 7? > > > Perhaps, Microsoft changed how they handle notifications in Windows 11. In > Windows 10, the notifications created with a Java app remain in Action / > Notification centre. > > Java uses Shell_NotifyIcon [8] function that has been available since > Windows 95. > > -- > Regards, > Alexey > > [6] https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/ > [7] > https://learn.microsoft.com/en-us/uwp/api/windows.ui.notifications.toastnotification?view=winrt-22621 > [8] > https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shell_notifyiconw > > > Thanks > Davide > > > > Il 08/01/2024 17:59, Aleksei Ivanov ha scritto: > > Hi Davide, > > The bug that you reported has been moved to JDK project in JBS, you can > view it as JDK-8315647 [1]. You should've received a link to it. > > Is there a way to workaround this JDK bug? > I opened a bug report months ago but no one answered. > > > What kind of answer did you expect to receive? > > You already asked this question on this mailing list in August [2]. I > replied to your question [3]. Nothing has changed since August. It is not a > bug in Java because a native Win32 app behaves the same way. > > I compiled and tested the sample [4], it behaves in Windows 11 as Java > does: the displayed balloon notification does not go to notification > centre. However, if I open notification centre while the balloon is > displayed, it remains there. If I disable "Show notification banners" and > leave "Show notifications in notification centre" enabled, the balloon goes > directly to notification centre without displaying a banner. > > You can compile and test the sample too: > > git clone --filter=blob:none --sparse > https://github.com/microsoft/Windows-classic-samples.git > > windows-samples > cd windows-samples > git sparse-checkout add > Samples/Win7Samples/winui/shell/appshellintegration/NotificationIcon > > Navigate to the NotificationIcon folder and open NotificationIcon.sln in > Visual Studio to compile and run it. > > If required, I can attach the compiled version of the application. > > > I have closed JDK-8315647 as duplicate of JDK-8310352 [5]. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serb at openjdk.org Tue Jan 9 22:10:29 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 9 Jan 2024 22:10:29 GMT Subject: Integrated: 8323210: Update the usage of cmsFLAGS_COPY_ALPHA In-Reply-To: <0nHbRf6TugFDn_1am4ne2IqrO57EYvDblweDrdsoKyk=.50cfd90c-e1e6-4c0a-a41d-b2bd07933888@github.com> References: <0nHbRf6TugFDn_1am4ne2IqrO57EYvDblweDrdsoKyk=.50cfd90c-e1e6-4c0a-a41d-b2bd07933888@github.com> Message-ID: On Tue, 9 Jan 2024 07:21:26 GMT, Sergey Bylokhov wrote: > Implementation of cmsFLAGS_COPY_ALPHA in littlecms 2.16 is changed to throw an exception: > - if the number of extra channels in src and dst are different. > - If dst does not have an alpha but src has > - If src does not have an alpha but dst has > > Exception does not occurred if the number of extra channels are the same(even if both are zero) This pull request has now been integrated. Changeset: aba19334 Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/aba19334eaeb46d37169cddeef929b13e050a60e Stats: 8 lines in 2 files changed: 5 ins; 0 del; 3 mod 8323210: Update the usage of cmsFLAGS_COPY_ALPHA Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/17320 From abhiscxk at openjdk.org Wed Jan 10 04:54:34 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 10 Jan 2024 04:54:34 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF [v2] In-Reply-To: References: Message-ID: > The collapsed icon for JTree is not painted using `Icon.paintIcon(Component c, Graphics g, int x, int y)` in GTK LAF. The collapsed icon is returned from BasicTreeUI class which doesn't contain any icon image whereas the expanded icon is returned from SynthTreeUI class and expanded icon is rendered correctly. > The proposed fix is to return collapsed icon as an object of collapsed icon wrapper which implements synthIcon and is similar to the expanded icon implementation. > > Test mentioned in JBS is an applet based which is converted to main based now and extended for all installed LAFs on the system. > > No regression caused with the fix, link is attached in JBS . Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Test converted to automated and html file deleted ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17294/files - new: https://git.openjdk.org/jdk/pull/17294/files/fa9abd15..0702e42a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17294&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17294&range=00-01 Stats: 153 lines in 2 files changed: 22 ins; 90 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/17294.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17294/head:pull/17294 PR: https://git.openjdk.org/jdk/pull/17294 From abhiscxk at openjdk.org Wed Jan 10 05:00:33 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 10 Jan 2024 05:00:33 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF [v3] In-Reply-To: References: Message-ID: > The collapsed icon for JTree is not painted using `Icon.paintIcon(Component c, Graphics g, int x, int y)` in GTK LAF. The collapsed icon is returned from BasicTreeUI class which doesn't contain any icon image whereas the expanded icon is returned from SynthTreeUI class and expanded icon is rendered correctly. > The proposed fix is to return collapsed icon as an object of collapsed icon wrapper which implements synthIcon and is similar to the expanded icon implementation. > > Test mentioned in JBS is an applet based which is converted to main based now and extended for all installed LAFs on the system. > > No regression caused with the fix, link is attached in JBS . Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Remove whitespace error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17294/files - new: https://git.openjdk.org/jdk/pull/17294/files/0702e42a..ed5caa98 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17294&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17294&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17294.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17294/head:pull/17294 PR: https://git.openjdk.org/jdk/pull/17294 From abhiscxk at openjdk.org Wed Jan 10 05:00:35 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 10 Jan 2024 05:00:35 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 09:18:20 GMT, Abhishek Kumar wrote: >Also, if one icon is rendered and other is not, there is a potential to create automated test to render the icons into bufferedimage and compare, the collapsed one should be all white BI in failed case...and you can use that automated test to test in ubuntu20.10 machine which we seem to have few in mach5... Modified the manual test to automated and tested in mach5 machines. Test passed on all platforms. Test passed on specific ubuntu 20.10 machine multiple times. > How about latest 23.10? Probably you should install and check there as well if you dont have that.....There is a need to check in latest OracleLinux too as there is a difference in observations across ubuntu versions.. Installed 23.10 machine in my local and verified the automated test. Ran the test on oracle linux as well and it passed. CI link is attached in JBS for automated test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17294#issuecomment-1884189839 From abhiscxk at openjdk.org Wed Jan 10 05:13:28 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 10 Jan 2024 05:13:28 GMT Subject: RFR: 8264102: JTable Keyboards Navigation differs with Test Instructions. [v5] In-Reply-To: References: Message-ID: On Tue, 9 Jan 2024 07:57:57 GMT, Tejesh R wrote: >> Updated the actions for "ctrl shift DOWN" to "`selectLastRowExtendSelection`" and "ctrl shift UP", "`selectFirstRowExtendSelection`" in Basic and other Look and feel. Tested in CI and no regressions found. >> Test to be used - [javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java) > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated test instructions test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 221: > 219: JTable tableView = new JTable(dataModel); > 220: // Turn off auto-resizing so that we can set column sizes programmatically. > 221: // In this mode, all columns will get their preferred widths, as set blow. looks like a typo Suggestion: // In this mode, all columns will get their preferred widths, as set below. test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 230: > 228: try { > 229: initTest(); > 230: } catch (Exception e) { try-catch block may be removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17236#discussion_r1446889141 PR Review Comment: https://git.openjdk.org/jdk/pull/17236#discussion_r1446889773 From tr at openjdk.org Wed Jan 10 05:25:42 2024 From: tr at openjdk.org (Tejesh R) Date: Wed, 10 Jan 2024 05:25:42 GMT Subject: RFR: 8264102: JTable Keyboards Navigation differs with Test Instructions. [v6] In-Reply-To: References: Message-ID: > Updated the actions for "ctrl shift DOWN" to "`selectLastRowExtendSelection`" and "ctrl shift UP", "`selectFirstRowExtendSelection`" in Basic and other Look and feel. Tested in CI and no regressions found. > Test to be used - [javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java) Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17236/files - new: https://git.openjdk.org/jdk/pull/17236/files/578d14b0..a97fd6d7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17236&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17236&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17236.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17236/head:pull/17236 PR: https://git.openjdk.org/jdk/pull/17236 From tr at openjdk.org Wed Jan 10 05:25:45 2024 From: tr at openjdk.org (Tejesh R) Date: Wed, 10 Jan 2024 05:25:45 GMT Subject: RFR: 8264102: JTable Keyboards Navigation differs with Test Instructions. [v5] In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 05:10:33 GMT, Abhishek Kumar wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated test instructions > > test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 230: > >> 228: try { >> 229: initTest(); >> 230: } catch (Exception e) { > > try-catch block may be removed. It is required since I'm using PassFailJFrame inside `initTest()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17236#discussion_r1446894272 From psadhukhan at openjdk.org Wed Jan 10 05:59:25 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 10 Jan 2024 05:59:25 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF [v3] In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 05:00:33 GMT, Abhishek Kumar wrote: >> The collapsed icon for JTree is not painted using `Icon.paintIcon(Component c, Graphics g, int x, int y)` in GTK LAF. The collapsed icon is returned from BasicTreeUI class which doesn't contain any icon image whereas the expanded icon is returned from SynthTreeUI class and expanded icon is rendered correctly. >> The proposed fix is to return collapsed icon as an object of collapsed icon wrapper which implements synthIcon and is similar to the expanded icon implementation. >> >> Test mentioned in JBS is an applet based which is converted to main based now and extended for all installed LAFs on the system. >> >> No regression caused with the fix, link is attached in JBS . > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Remove whitespace error src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTreeUI.java line 837: > 835: } > 836: else { > 837: SynthGraphicsUtils.paintIcon(collapsedIcon, context, g, x, y, w, h); Guess it's a copy of `ExpandedIconWrapper `class, so `CollapsedIconWrapper `and `ExpandedIconWrapper` can be optimised to use common method passing in the "icon" argument.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17294#discussion_r1446917678 From abhiscxk at openjdk.org Wed Jan 10 06:00:25 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 10 Jan 2024 06:00:25 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) In-Reply-To: References: Message-ID: On Tue, 9 Jan 2024 21:06:50 GMT, Alisen Chung wrote: > SunToolkit.java is trying to post an event on the TrayIcon appContext, but the TrayIcon was already removed by the test, causing an error. The fix is to make SunToolkit skip posting the event if appContext is null. The test is also updated to remove applet usage and use PassFailJFrame instead. test/jdk/java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.java line 1: > 1: /* Please update copyright year. test/jdk/java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.java line 83: > 81: > 82: public void showFrameAndIcon() throws Exception { > 83: if (!traySupported) { Looks like redundant. Same condition is checked in startTest() method test/jdk/java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.java line 88: > 86: > 87: SwingUtilities.invokeAndWait(() -> { > 88: frame = new JFrame(); Please add a frame title. test/jdk/java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.java line 89: > 87: SwingUtilities.invokeAndWait(() -> { > 88: frame = new JFrame(); > 89: frame.setLayout (new BorderLayout()); Suggestion: frame.setLayout(new BorderLayout()); No need of space here and below as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17329#discussion_r1446918269 PR Review Comment: https://git.openjdk.org/jdk/pull/17329#discussion_r1446916922 PR Review Comment: https://git.openjdk.org/jdk/pull/17329#discussion_r1446917273 PR Review Comment: https://git.openjdk.org/jdk/pull/17329#discussion_r1446917478 From tr at openjdk.org Wed Jan 10 07:04:24 2024 From: tr at openjdk.org (Tejesh R) Date: Wed, 10 Jan 2024 07:04:24 GMT Subject: RFR: 8318112: CSS percentage values are capped at 100% In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 09:19:20 GMT, Prasanta Sadhukhan wrote: > Java CSS where values can be displayed in percent are capped at 100% so "width: 200%" and "width: 100%" are equal, which is incorrect. > FIx is made to make sure parsing is not capped at 100% Looks good to me. ------------- Marked as reviewed by tr (Committer). PR Review: https://git.openjdk.org/jdk/pull/17299#pullrequestreview-1812533207 From abhiscxk at openjdk.org Wed Jan 10 08:29:29 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 10 Jan 2024 08:29:29 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF [v3] In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 05:56:37 GMT, Prasanta Sadhukhan wrote: >> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove whitespace error > > src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTreeUI.java line 837: > >> 835: } >> 836: else { >> 837: SynthGraphicsUtils.paintIcon(collapsedIcon, context, g, x, y, w, h); > > Guess it's a copy of `ExpandedIconWrapper `class, so `CollapsedIconWrapper `and `ExpandedIconWrapper` can be optimised to use common method passing in the "icon" argument.. Should I merge the two classes into one class like instead of separate `ExpandedIconWrapper` and `CollapsedIconWrapper`, only one `IconWrapper` class? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17294#discussion_r1447033548 From psadhukhan at openjdk.org Wed Jan 10 08:58:25 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 10 Jan 2024 08:58:25 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF [v3] In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 08:25:52 GMT, Abhishek Kumar wrote: >> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTreeUI.java line 837: >> >>> 835: } >>> 836: else { >>> 837: SynthGraphicsUtils.paintIcon(collapsedIcon, context, g, x, y, w, h); >> >> Guess it's a copy of `ExpandedIconWrapper `class, so `CollapsedIconWrapper `and `ExpandedIconWrapper` can be optimised to use common method passing in the "icon" argument.. > > Should I merge the two classes into one class like instead of separate `ExpandedIconWrapper` and `CollapsedIconWrapper`, only one `IconWrapper` class? guess you could since they are all private.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17294#discussion_r1447064941 From mbaesken at openjdk.org Wed Jan 10 09:24:31 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 10 Jan 2024 09:24:31 GMT Subject: RFR: JDK-8323330: undo JDK-8276809 and bring back JNI warning Message-ID: <8WrmYE_8kPUOcMlaCHgCc6RS4UwuUJbu9AgHGuybAh0=.7f152b33-67a9-43a8-8283-28393973beb2@github.com> There have been concerns raised about [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) , so bring back the old behavior. ------------- Commit messages: - JDK-8323330 Changes: https://git.openjdk.org/jdk/pull/17341/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17341&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323330 Stats: 8 lines in 1 file changed: 0 ins; 6 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17341.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17341/head:pull/17341 PR: https://git.openjdk.org/jdk/pull/17341 From abhiscxk at openjdk.org Wed Jan 10 10:52:46 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 10 Jan 2024 10:52:46 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF [v3] In-Reply-To: References: Message-ID: <-scYamZDP8VxJnXVRotul1HLbwsyQlrSJw6ryPgHV50=.b525617b-4c42-430e-a10d-037b146cae4a@github.com> On Wed, 10 Jan 2024 08:55:19 GMT, Prasanta Sadhukhan wrote: >> Should I merge the two classes into one class like instead of separate `ExpandedIconWrapper` and `CollapsedIconWrapper`, only one `IconWrapper` class? > > guess you could since they are all private.. Merged `ExpandedIconWrapper` and `CollapsedIconWrapper` class to `IconWrapper ` class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17294#discussion_r1447202641 From abhiscxk at openjdk.org Wed Jan 10 10:52:44 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 10 Jan 2024 10:52:44 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF [v4] In-Reply-To: References: Message-ID: > The collapsed icon for JTree is not painted using `Icon.paintIcon(Component c, Graphics g, int x, int y)` in GTK LAF. The collapsed icon is returned from BasicTreeUI class which doesn't contain any icon image whereas the expanded icon is returned from SynthTreeUI class and expanded icon is rendered correctly. > The proposed fix is to return collapsed icon as an object of collapsed icon wrapper which implements synthIcon and is similar to the expanded icon implementation. > > Test mentioned in JBS is an applet based which is converted to main based now and extended for all installed LAFs on the system. > > No regression caused with the fix, link is attached in JBS . Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: ExpandedIconWrapper and CollapsedIconWrapper class merged together ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17294/files - new: https://git.openjdk.org/jdk/pull/17294/files/ed5caa98..2fa05f9f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17294&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17294&range=02-03 Stats: 76 lines in 1 file changed: 32 ins; 33 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/17294.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17294/head:pull/17294 PR: https://git.openjdk.org/jdk/pull/17294 From psadhukhan at openjdk.org Wed Jan 10 11:29:25 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 10 Jan 2024 11:29:25 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF [v4] In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 10:52:44 GMT, Abhishek Kumar wrote: >> The collapsed icon for JTree is not painted using `Icon.paintIcon(Component c, Graphics g, int x, int y)` in GTK LAF. The collapsed icon is returned from BasicTreeUI class which doesn't contain any icon image whereas the expanded icon is returned from SynthTreeUI class and expanded icon is rendered correctly. >> The proposed fix is to return collapsed icon as an object of collapsed icon wrapper which implements synthIcon and is similar to the expanded icon implementation. >> >> Test mentioned in JBS is an applet based which is converted to main based now and extended for all installed LAFs on the system. >> >> No regression caused with the fix, link is attached in JBS . > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > ExpandedIconWrapper and CollapsedIconWrapper class merged together src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTreeUI.java line 82: > 80: private Icon expandedIconWrapper = new IconWrapper(IconType.EXPANDED); > 81: > 82: private Icon collapsedIconWrapper = new IconWrapper(IconType.COLLAPSED); I guess you can pass in `collapsedIcon` or `expandedIcon` to `IconWrapper `class which can save it in `icon` field and Then IconWrapper class can just call `SynthGraphicsUtils.paintIcon(icon, context, g, x, y, w, h);` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17294#discussion_r1447249502 From jwaters at openjdk.org Wed Jan 10 12:04:21 2024 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 10 Jan 2024 12:04:21 GMT Subject: RFR: JDK-8323330: undo JDK-8276809 and bring back JNI warning In-Reply-To: <8WrmYE_8kPUOcMlaCHgCc6RS4UwuUJbu9AgHGuybAh0=.7f152b33-67a9-43a8-8283-28393973beb2@github.com> References: <8WrmYE_8kPUOcMlaCHgCc6RS4UwuUJbu9AgHGuybAh0=.7f152b33-67a9-43a8-8283-28393973beb2@github.com> Message-ID: On Wed, 10 Jan 2024 09:18:53 GMT, Matthias Baesken wrote: > There have been concerns raised about [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) , so bring back the old behavior. Not a review, just a quick tip: Such changes are by convention titled [BACKOUT] In this case that would be JDK-8323330: [BACKOUT] JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows ------------- PR Comment: https://git.openjdk.org/jdk/pull/17341#issuecomment-1884718987 From abhiscxk at openjdk.org Wed Jan 10 12:23:30 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 10 Jan 2024 12:23:30 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF [v4] In-Reply-To: References: Message-ID: <5RsIO82hrqgnhqJ940pcSPau_RHfDv6gaev_Le0FaKg=.79466f6f-c692-4d48-b8f6-a2a25fad6289@github.com> On Wed, 10 Jan 2024 11:26:17 GMT, Prasanta Sadhukhan wrote: >> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> ExpandedIconWrapper and CollapsedIconWrapper class merged together > > src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTreeUI.java line 82: > >> 80: private Icon expandedIconWrapper = new IconWrapper(IconType.EXPANDED); >> 81: >> 82: private Icon collapsedIconWrapper = new IconWrapper(IconType.COLLAPSED); > > I guess you can pass in `collapsedIcon` or `expandedIcon` to `IconWrapper `class which can save it in `icon` field and > Then IconWrapper class can just call `SynthGraphicsUtils.paintIcon(icon, context, g, x, y, w, h);` I tried with this approach first but images didn't render at all. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17294#discussion_r1447313431 From psadhukhan at openjdk.org Wed Jan 10 12:34:26 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 10 Jan 2024 12:34:26 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF [v4] In-Reply-To: <5RsIO82hrqgnhqJ940pcSPau_RHfDv6gaev_Le0FaKg=.79466f6f-c692-4d48-b8f6-a2a25fad6289@github.com> References: <5RsIO82hrqgnhqJ940pcSPau_RHfDv6gaev_Le0FaKg=.79466f6f-c692-4d48-b8f6-a2a25fad6289@github.com> Message-ID: <0reNtxGgHTG_rvmcRT96RIJiEmhfrksbJx4L8IYr-mw=.94007eea-3565-4e1c-89ec-9fb693fa9a5b@github.com> On Wed, 10 Jan 2024 12:20:28 GMT, Abhishek Kumar wrote: >> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTreeUI.java line 82: >> >>> 80: private Icon expandedIconWrapper = new IconWrapper(IconType.EXPANDED); >>> 81: >>> 82: private Icon collapsedIconWrapper = new IconWrapper(IconType.COLLAPSED); >> >> I guess you can pass in `collapsedIcon` or `expandedIcon` to `IconWrapper `class which can save it in `icon` field and >> Then IconWrapper class can just call `SynthGraphicsUtils.paintIcon(icon, context, g, x, y, w, h);` > > I tried with this approach first but images didn't render at all. I guess those might be null at class initialisation stage so it didn't render..you can try expandedIconWrapper = new IconWrapper(expandedIcon); collapsedIconWrappr - new IconWrapper(collapsedICon); in updateStyle() where it sets setExpandedIcon(style.getIcon(context, "Tree.expandedIcon")); setCollapsedIcon(style.getIcon(context, "Tree.collapsedIcon")); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17294#discussion_r1447325540 From mbaesken at openjdk.org Wed Jan 10 15:07:22 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 10 Jan 2024 15:07:22 GMT Subject: RFR: JDK-8323330: [BACKOUT] JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows In-Reply-To: References: <8WrmYE_8kPUOcMlaCHgCc6RS4UwuUJbu9AgHGuybAh0=.7f152b33-67a9-43a8-8283-28393973beb2@github.com> Message-ID: On Wed, 10 Jan 2024 12:01:47 GMT, Julian Waters wrote: > Not a review, just a quick tip: Such changes are by convention titled [BACKOUT] > > In this case that would be JDK-8323330: [BACKOUT] JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows Thanks, I changed the title. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17341#issuecomment-1885020738 From mbaesken at openjdk.org Wed Jan 10 15:13:30 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 10 Jan 2024 15:13:30 GMT Subject: RFR: JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows In-Reply-To: <8a61d5c2-b178-4399-8bc3-859b9c14c6b2@oracle.com> References: <5x-CDbd8ujYRMOO46Emn8ybYsqfkipVoHBnFylB1DTE=.fdc27846-0928-4901-84cc-98937c76e7d1@github.com> <8a61d5c2-b178-4399-8bc3-859b9c14c6b2@oracle.com> Message-ID: On Tue, 9 Jan 2024 06:35:12 GMT, Philip Race wrote: >reason for the exception which has NEVER been seen in our testing here and once understood I checked the new output of the jtr with this change (where ExceptionDescribe is called) but nothing is reported unfortunately. So I really wonder - is there a exception present that we could try to understand ? >rather than suppressing it needs an actual fix and yet here it is again in the form previously rejected. Without getting the exception (if there is one?) it is hard to propose a fix; it is not even totally clear if there is need for a fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17224#issuecomment-1885031083 From aivanov at openjdk.org Wed Jan 10 17:26:25 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 10 Jan 2024 17:26:25 GMT Subject: RFR: JDK-8320405: [Windows Server 2016] java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java shows issues in awt_Win32GraphicsDevice.cpp In-Reply-To: References: <2ZKWdemDZ7lxatijM7GPrGdGf8rE5kAROZrKHICui1Y=.1e0c86f2-a00b-4400-9873-aea76468adff@github.com> Message-ID: On Thu, 4 Jan 2024 14:40:59 GMT, Matthias Baesken wrote: > > It should be extended to include the possible failure in the preceding call to ::GetDIBits. > > I handle now also a failure of the first GetDIBits call; and also added braces at the if's mentioned. Sorry for my delayed reply. It's not what I expected. What I meant is that we shouldn't even call `::CreateCompatibleBitmap` if `hBMDC == NULL`. Then we shouldn't call `::GetDIBits` if `hBM == NULL`. Thus in this case, the _fallback_ code path should be taken. Perhaps, the code could be restructured? Yet I don't fully understand what's done here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17197#issuecomment-1885284337 From aivanov at openjdk.org Wed Jan 10 17:38:29 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 10 Jan 2024 17:38:29 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v13] In-Reply-To: References: Message-ID: On Tue, 9 Jan 2024 11:11:38 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. >> >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Fixed other two typos I merged master and ran the client tests?the tests are green. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16895#issuecomment-1885305466 From aivanov at openjdk.org Wed Jan 10 19:20:25 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 10 Jan 2024 19:20:25 GMT Subject: RFR: 8320673 : PageFormat/CustomPaper.java has no Pass/Fail buttons; multiple instructions In-Reply-To: References: Message-ID: <0ofyOsrKItR4WMwiHR-0T2KNfsg2HxJmC8T8yomo4GM=.da56b1a4-890c-477e-a0a8-60d081d696e6@github.com> On Wed, 27 Dec 2023 04:20:42 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > > I have updated the test case. Now test has pass/fail option also test will execute two time for covering different cases which are part of the test. > > Please review and let me know your suggestions. > > Regards, > Renjith. Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17194#pullrequestreview-1813963747 From serb at openjdk.org Wed Jan 10 19:53:26 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 10 Jan 2024 19:53:26 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 19:20:50 GMT, Sergey Bylokhov wrote: >> Hi Reviewers, >> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. >> >> Renjith. > > Can this patch be covered by the new test? >I'm not sure? We want the filter to take another path, there could be a list of filters applied, if I understand @mrserb correctly. Sergey could be able to provide a more detailed guidance. The current test validates two code paths: - wrapper>icc_color_space->wrapper - icc_color_space->icc_color_space->icc_color_space The color space in the middle is always icc_color_space: https://github.com/openjdk/jdk/pull/16895/files#diff-70b19b2642d6d3f44904de8b6eb2993e1c97320e3476898c4372db364c4288b7R130 If it we cover the wrapper for the middle as well we will cover this code path: https://github.com/openjdk/jdk/pull/16895/files#diff-e3d6eea060882cab00827c00e1a83b0e0a5b2a31fa9a9aa2122841bbd57c4a6dL853 ------------- PR Comment: https://git.openjdk.org/jdk/pull/16895#issuecomment-1885608696 From prr at openjdk.org Wed Jan 10 19:57:24 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 10 Jan 2024 19:57:24 GMT Subject: RFR: JDK-8323330: [BACKOUT] JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows In-Reply-To: <8WrmYE_8kPUOcMlaCHgCc6RS4UwuUJbu9AgHGuybAh0=.7f152b33-67a9-43a8-8283-28393973beb2@github.com> References: <8WrmYE_8kPUOcMlaCHgCc6RS4UwuUJbu9AgHGuybAh0=.7f152b33-67a9-43a8-8283-28393973beb2@github.com> Message-ID: On Wed, 10 Jan 2024 09:18:53 GMT, Matthias Baesken wrote: > There have been concerns raised about [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) , so bring back the old behavior. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17341#pullrequestreview-1814046509 From stuefe at openjdk.org Wed Jan 10 20:25:21 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 10 Jan 2024 20:25:21 GMT Subject: RFR: JDK-8323330: [BACKOUT] JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows In-Reply-To: <8WrmYE_8kPUOcMlaCHgCc6RS4UwuUJbu9AgHGuybAh0=.7f152b33-67a9-43a8-8283-28393973beb2@github.com> References: <8WrmYE_8kPUOcMlaCHgCc6RS4UwuUJbu9AgHGuybAh0=.7f152b33-67a9-43a8-8283-28393973beb2@github.com> Message-ID: On Wed, 10 Jan 2024 09:18:53 GMT, Matthias Baesken wrote: > There have been concerns raised about [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) , so bring back the old behavior. okay ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17341#pullrequestreview-1814102655 From achung at openjdk.org Wed Jan 10 21:08:35 2024 From: achung at openjdk.org (Alisen Chung) Date: Wed, 10 Jan 2024 21:08:35 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v2] In-Reply-To: References: Message-ID: <7dpKxrn8QG4b5Xkzv921rdgttZuZw-DwBBniheoTn8A=.f0daf114-7631-4214-8af9-57cb3ccd33f4@github.com> > SunToolkit.java is trying to post an event on the TrayIcon appContext, but the TrayIcon was already removed by the test, causing an error. The fix is to make SunToolkit skip posting the event if appContext is null. The test is also updated to remove applet usage and use PassFailJFrame instead. Alisen Chung has updated the pull request incrementally with two additional commits since the last revision: - spacing - updated test title, copyright year, removed redundant check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17329/files - new: https://git.openjdk.org/jdk/pull/17329/files/171a1554..53629e25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17329&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17329&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 4 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/17329.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17329/head:pull/17329 PR: https://git.openjdk.org/jdk/pull/17329 From achung at openjdk.org Wed Jan 10 21:08:36 2024 From: achung at openjdk.org (Alisen Chung) Date: Wed, 10 Jan 2024 21:08:36 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) In-Reply-To: References: Message-ID: On Tue, 9 Jan 2024 21:06:50 GMT, Alisen Chung wrote: > SunToolkit.java is trying to post an event on the TrayIcon appContext, but the TrayIcon was already removed by the test, causing an error. The fix is to make SunToolkit skip posting the event if appContext is null. The test is also updated to remove applet usage and use PassFailJFrame instead. Updated test, mach5 client tests are green ------------- PR Comment: https://git.openjdk.org/jdk/pull/17329#issuecomment-1885731191 From honkar at openjdk.org Wed Jan 10 21:43:39 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 10 Jan 2024 21:43:39 GMT Subject: RFR: JDK-8312518 : [macos13] setFullScreenWindow() shows black screen on macOS 13 & above Message-ID: A black screen is seen on newer versions of macOS (13.3 & above) when a window is set to full-screen using `setFullScreenWindow()`. The root cause was narrowed down to the shield level of the full-screen window vs the shield level of the captured display. Following solutions were explored - 1. Setting `kCGMaximumWindowLevelKey` as the shield level for the full screen window. But setting the fullscreen window to maximum available window level might cause z-order issues when other popup/screen savers are involved. int shieldLevel = CGWindowLevelForKey(kCGMaximumWindowLevelKey); window.preFullScreenLevel = [nsWindow level]; [nsWindow setLevel: shieldLevel]; 2. Raise the windows level slightly (shieldLevel + 1) above the system shield window. int shieldLevel = CGShieldingWindowLevel(); window.preFullScreenLevel = [nsWindow level]; [nsWindow setLevel: (shieldLevel + 1)]; 3. Keeping the shielding level as-is and bringing the window to the foreground after display is captured. The 3rd approach **(also the one Apple recommends)** ensures that the full screen window has focus as well as being visible and also maintains the correct z-order. This solution works as expected on older (< 13.3) and newer versions (13.3 & above) of macOS. if (CGDisplayCapture(aID) == kCGErrorSuccess) { ... ... int shieldLevel = CGShieldingWindowLevel(); window.preFullScreenLevel = [nsWindow level]; [nsWindow setLevel: shieldLevel]; [nsWindow makeKeyAndOrderFront: nil]; } ------------- Commit messages: - removed extra line - test changes - summary updated - test changes - initial changes Changes: https://git.openjdk.org/jdk/pull/17358/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17358&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312518 Stats: 91 lines in 2 files changed: 90 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17358.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17358/head:pull/17358 PR: https://git.openjdk.org/jdk/pull/17358 From serb at openjdk.org Wed Jan 10 23:48:21 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 10 Jan 2024 23:48:21 GMT Subject: RFR: JDK-8312518 : [macos13] setFullScreenWindow() shows black screen on macOS 13 & above In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 21:35:57 GMT, Harshitha Onkar wrote: > A black screen is seen on newer versions of macOS (13.3 & above) when a window is set to full-screen using `setFullScreenWindow()`. The root cause was narrowed down to the shield level of the full-screen window vs the shield level of the captured display. > > Following solutions were explored - > > 1. Setting `kCGMaximumWindowLevelKey` as the shield level for the full screen window. But setting the fullscreen window to maximum available window level might cause z-order issues when other popup/screen savers are involved. > > int shieldLevel = CGWindowLevelForKey(kCGMaximumWindowLevelKey); > window.preFullScreenLevel = [nsWindow level]; > [nsWindow setLevel: shieldLevel]; > > 2. Raise the window's level slightly (shieldLevel + 1) above the system shield window. > > int shieldLevel = CGShieldingWindowLevel(); > window.preFullScreenLevel = [nsWindow level]; > [nsWindow setLevel: (shieldLevel + 1)]; > > 3. Keeping the shielding level as-is and bringing the window to the foreground after display is captured. The 3rd approach **(also the one Apple recommends)** ensures that the full screen window has focus as well as being visible and also maintains the correct z-order. This solution works as expected on older (< 13.3) and newer versions (13.3 & above) of macOS. > > if (CGDisplayCapture(aID) == kCGErrorSuccess) { > ... > ... > int shieldLevel = CGShieldingWindowLevel(); > window.preFullScreenLevel = [nsWindow level]; > [nsWindow setLevel: shieldLevel]; > [nsWindow makeKeyAndOrderFront: nil]; > } How it will work now(and worked before) if the user will call toBack() on the such fullscreen window? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17358#issuecomment-1885934211 From serb at openjdk.org Thu Jan 11 00:13:33 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 11 Jan 2024 00:13:33 GMT Subject: RFR: 8323554: The typos in Javadoc: "@return if " Message-ID: The docs for the boolean methods are updated from this style: @return if the event has been consumed to this one @return {@code true} if the event has been consumed, otherwise {@code false} plus small cleanups here and there. ------------- Commit messages: - one more - one more typo - 8323554: The typos in Javadoc: "@return if " Changes: https://git.openjdk.org/jdk/pull/17357/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17357&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323554 Stats: 123 lines in 14 files changed: 23 ins; 16 del; 84 mod Patch: https://git.openjdk.org/jdk/pull/17357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17357/head:pull/17357 PR: https://git.openjdk.org/jdk/pull/17357 From honkar at openjdk.org Thu Jan 11 01:04:21 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 11 Jan 2024 01:04:21 GMT Subject: RFR: JDK-8312518 : [macos13] setFullScreenWindow() shows black screen on macOS 13 & above In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 23:45:57 GMT, Sergey Bylokhov wrote: >> A black screen is seen on newer versions of macOS (13.3 & above) when a window is set to full-screen using `setFullScreenWindow()`. The root cause was narrowed down to the shield level of the full-screen window vs the shield level of the captured display. >> >> Following solutions were explored - >> >> 1. Setting `kCGMaximumWindowLevelKey` as the shield level for the full screen window. But setting the fullscreen window to maximum available window level might cause z-order issues when other popup/screen savers are involved. >> >> int shieldLevel = CGWindowLevelForKey(kCGMaximumWindowLevelKey); >> window.preFullScreenLevel = [nsWindow level]; >> [nsWindow setLevel: shieldLevel]; >> >> 2. Raise the window's level slightly (shieldLevel + 1) above the system shield window. >> >> int shieldLevel = CGShieldingWindowLevel(); >> window.preFullScreenLevel = [nsWindow level]; >> [nsWindow setLevel: (shieldLevel + 1)]; >> >> 3. Keeping the shielding level as-is and bringing the window to the foreground after display is captured. The 3rd approach **(also the one Apple recommends)** ensures that the full screen window has focus as well as being visible and also maintains the correct z-order. This solution works as expected on older (< 13.3) and newer versions (13.3 & above) of macOS. >> >> if (CGDisplayCapture(aID) == kCGErrorSuccess) { >> ... >> ... >> int shieldLevel = CGShieldingWindowLevel(); >> window.preFullScreenLevel = [nsWindow level]; >> [nsWindow setLevel: shieldLevel]; >> [nsWindow makeKeyAndOrderFront: nil]; >> } > > How it will work now(and worked before) if the user will call toBack() on the such fullscreen window? @mrserb > How it will work now(and worked before) if the user will call toBack() on the such fullscreen window? Tested both cases - current fix on macOS 13.3 & above + fullScreenWindow.toBack() - original code on older macOS version (11.5) + fullScreenWindow.toBack() It works the same in both cases - the shield window becomes the topmost window and a black screen is seen. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17358#issuecomment-1886019314 From duke at openjdk.org Thu Jan 11 03:09:35 2024 From: duke at openjdk.org (duke) Date: Thu, 11 Jan 2024 03:09:35 GMT Subject: Withdrawn: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken wrote: > Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code. > Some examples : > Events::log_dll_message for hs-err files reporting > JFR event NativeLibraryLoad > There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ), > this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information > > Offer an interface (e.g. jvm.cpp) to support this. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/15264 From duke at openjdk.org Thu Jan 11 03:36:35 2024 From: duke at openjdk.org (duke) Date: Thu, 11 Jan 2024 03:36:35 GMT Subject: Withdrawn: 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea In-Reply-To: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com> References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com> Message-ID: On Thu, 16 Mar 2023 06:06:50 GMT, ??? wrote: > Candidat box can moving with caret on windows version. Someone must wrote codes for linux(ubuntu), but it doesn't work, so he didn't commit the codes. Why it doesn't work, is the key problem. > > 1, I wrote a example for linux: > https://github.com/quantum6/X11InputMethod > > I tried all parameters to test and as my research: > If you use XIMPreeditCallbacks to initiate, the box can't be moved with caret. > If you use XIMPreeditNothing, it works. > All examples use XIMPreeditCallbacks to initiate input method and candidate box can't moving. So I understand why he didn't commit the codes. > > 2, I traced the route of transfering caret coordites on windows version, then add codes for linux. > 3, Taishan Office(like Microsoft Office Word) is running on jdk, we tested for a long time, it works OK. > 4, I am not sure for AIX( no environment). > > > JDK-8264728 : When use chinese IME, the candidate box isn't moved with caret of JTextArea > Type: Bug > Component: client-libs > Sub-Component: java.awt:i18n > Affected Version: 8,9,15,16 > Priority: P3 > Status: Open > Resolution: Unresolved > OS: linux > CPU: x86_64 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/13055 From serb at openjdk.org Thu Jan 11 04:36:22 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 11 Jan 2024 04:36:22 GMT Subject: RFR: JDK-8312518 : [macos13] setFullScreenWindow() shows black screen on macOS 13 & above In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 21:35:57 GMT, Harshitha Onkar wrote: > A black screen is seen on newer versions of macOS (13.3 & above) when a window is set to full-screen using `setFullScreenWindow()`. The root cause was narrowed down to the shield level of the full-screen window vs the shield level of the captured display. > > Following solutions were explored - > > 1. Setting `kCGMaximumWindowLevelKey` as the shield level for the full screen window. But setting the fullscreen window to maximum available window level might cause z-order issues when other popup/screen savers are involved. > > int shieldLevel = CGWindowLevelForKey(kCGMaximumWindowLevelKey); > window.preFullScreenLevel = [nsWindow level]; > [nsWindow setLevel: shieldLevel]; > > 2. Raise the window's level slightly (shieldLevel + 1) above the system shield window. > > int shieldLevel = CGShieldingWindowLevel(); > window.preFullScreenLevel = [nsWindow level]; > [nsWindow setLevel: (shieldLevel + 1)]; > > 3. Keeping the shielding level as-is and bringing the window to the foreground after display is captured. The 3rd approach **(also the one Apple recommends)** ensures that the full screen window has focus as well as being visible and also maintains the correct z-order. This solution works as expected on older (< 13.3) and newer versions (13.3 & above) of macOS. > > if (CGDisplayCapture(aID) == kCGErrorSuccess) { > ... > ... > int shieldLevel = CGShieldingWindowLevel(); > window.preFullScreenLevel = [nsWindow level]; > [nsWindow setLevel: shieldLevel]; > [nsWindow makeKeyAndOrderFront: nil]; > } Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17358#pullrequestreview-1814647094 From serb at openjdk.org Thu Jan 11 04:36:24 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 11 Jan 2024 04:36:24 GMT Subject: RFR: JDK-8312518 : [macos13] setFullScreenWindow() shows black screen on macOS 13 & above In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 01:01:46 GMT, Harshitha Onkar wrote: >It works the same in both cases - the shield window becomes the topmost window and a black screen is seen. That probably is not right, but we can fix that separately. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17358#issuecomment-1886227441 From abhiscxk at openjdk.org Thu Jan 11 04:41:26 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 11 Jan 2024 04:41:26 GMT Subject: RFR: 8264102: JTable Keyboards Navigation differs with Test Instructions. [v6] In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 05:25:42 GMT, Tejesh R wrote: >> Updated the actions for "ctrl shift DOWN" to "`selectLastRowExtendSelection`" and "ctrl shift UP", "`selectFirstRowExtendSelection`" in Basic and other Look and feel. Tested in CI and no regressions found. >> Test to be used - [javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java) > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated review comments LGTM. ------------- Marked as reviewed by abhiscxk (Committer). PR Review: https://git.openjdk.org/jdk/pull/17236#pullrequestreview-1814651169 From tr at openjdk.org Thu Jan 11 04:54:40 2024 From: tr at openjdk.org (Tejesh R) Date: Thu, 11 Jan 2024 04:54:40 GMT Subject: RFR: 8295804: javax/swing/JFileChooser/JFileChooserSetLocationTest.java failed with "setLocation() is not working properly" Message-ID: The issue is that the doc area (in respect to the screen width which is 768px) which is at the bottom was causing the `JFileChooser `to be placed slightly above the set location. Was able to reproduce in local machine with reference to the failure image provided in the CI logs. The suggested fix is to place the main Frame slightly above the center of the screen than setting at the center of the screen. Several CI runs were made and no issue found. ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/17364/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17364&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295804 Stats: 9 lines in 1 file changed: 6 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17364.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17364/head:pull/17364 PR: https://git.openjdk.org/jdk/pull/17364 From abhiscxk at openjdk.org Thu Jan 11 05:21:51 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 11 Jan 2024 05:21:51 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF [v5] In-Reply-To: References: Message-ID: <-cvWbTu7GFAC0-m3H5l1SvfD2Nmu_k3FZpERUuBKDYM=.6bc08ac5-7ada-4622-8e66-26ef3447265e@github.com> > The collapsed icon for JTree is not painted using `Icon.paintIcon(Component c, Graphics g, int x, int y)` in GTK LAF. The collapsed icon is returned from BasicTreeUI class which doesn't contain any icon image whereas the expanded icon is returned from SynthTreeUI class and expanded icon is rendered correctly. > The proposed fix is to return collapsed icon as an object of collapsed icon wrapper which implements synthIcon and is similar to the expanded icon implementation. > > Test mentioned in JBS is an applet based which is converted to main based now and extended for all installed LAFs on the system. > > No regression caused with the fix, link is attached in JBS . Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Review comment fix and move file outside folder ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17294/files - new: https://git.openjdk.org/jdk/pull/17294/files/2fa05f9f..17d9bdc2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17294&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17294&range=03-04 Stats: 165 lines in 2 files changed: 5 ins; 152 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/17294.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17294/head:pull/17294 PR: https://git.openjdk.org/jdk/pull/17294 From abhiscxk at openjdk.org Thu Jan 11 05:21:51 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 11 Jan 2024 05:21:51 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF [v4] In-Reply-To: <0reNtxGgHTG_rvmcRT96RIJiEmhfrksbJx4L8IYr-mw=.94007eea-3565-4e1c-89ec-9fb693fa9a5b@github.com> References: <5RsIO82hrqgnhqJ940pcSPau_RHfDv6gaev_Le0FaKg=.79466f6f-c692-4d48-b8f6-a2a25fad6289@github.com> <0reNtxGgHTG_rvmcRT96RIJiEmhfrksbJx4L8IYr-mw=.94007eea-3565-4e1c-89ec-9fb693fa9a5b@github.com> Message-ID: On Wed, 10 Jan 2024 12:31:57 GMT, Prasanta Sadhukhan wrote: >> I tried with this approach first but images didn't render at all. > > I guess those might be null at class initialisation stage so it didn't render..you can try > > expandedIconWrapper = new IconWrapper(expandedIcon); > collapsedIconWrappr - new IconWrapper(collapsedICon); > > in updateStyle() where it sets > > setExpandedIcon(style.getIcon(context, "Tree.expandedIcon")); > setCollapsedIcon(style.getIcon(context, "Tree.collapsedIcon")); Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17294#discussion_r1448302768 From tr at openjdk.org Thu Jan 11 05:31:21 2024 From: tr at openjdk.org (Tejesh R) Date: Thu, 11 Jan 2024 05:31:21 GMT Subject: RFR: JDK-8312518 : [macos13] setFullScreenWindow() shows black screen on macOS 13 & above In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 21:35:57 GMT, Harshitha Onkar wrote: > A black screen is seen on newer versions of macOS (13.3 & above) when a window is set to full-screen using `setFullScreenWindow()`. The root cause was narrowed down to the shield level of the full-screen window vs the shield level of the captured display. > > Following solutions were explored - > > 1. Setting `kCGMaximumWindowLevelKey` as the shield level for the full screen window. But setting the fullscreen window to maximum available window level might cause z-order issues when other popup/screen savers are involved. > > int shieldLevel = CGWindowLevelForKey(kCGMaximumWindowLevelKey); > window.preFullScreenLevel = [nsWindow level]; > [nsWindow setLevel: shieldLevel]; > > 2. Raise the window's level slightly (shieldLevel + 1) above the system shield window. > > int shieldLevel = CGShieldingWindowLevel(); > window.preFullScreenLevel = [nsWindow level]; > [nsWindow setLevel: (shieldLevel + 1)]; > > 3. Keeping the shielding level as-is and bringing the window to the foreground after display is captured. The 3rd approach **(also the one Apple recommends)** ensures that the full screen window has focus as well as being visible and also maintains the correct z-order. This solution works as expected on older (< 13.3) and newer versions (13.3 & above) of macOS. > > if (CGDisplayCapture(aID) == kCGErrorSuccess) { > ... > ... > int shieldLevel = CGShieldingWindowLevel(); > window.preFullScreenLevel = [nsWindow level]; > [nsWindow setLevel: shieldLevel]; > [nsWindow makeKeyAndOrderFront: nil]; > } Looks good to me. Tested and its working as expected. ------------- Marked as reviewed by tr (Committer). PR Review: https://git.openjdk.org/jdk/pull/17358#pullrequestreview-1814687969 From abhiscxk at openjdk.org Thu Jan 11 05:34:21 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 11 Jan 2024 05:34:21 GMT Subject: RFR: 8295804: javax/swing/JFileChooser/JFileChooserSetLocationTest.java failed with "setLocation() is not working properly" In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 04:48:23 GMT, Tejesh R wrote: > The issue is that the doc area (`in respect to the screen width which is 768px`) which is at the bottom was causing the JFileChooser to be placed slightly above the set location. Is it with respect to height ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17364#issuecomment-1886273346 From tr at openjdk.org Thu Jan 11 05:47:25 2024 From: tr at openjdk.org (Tejesh R) Date: Thu, 11 Jan 2024 05:47:25 GMT Subject: RFR: 8295804: javax/swing/JFileChooser/JFileChooserSetLocationTest.java failed with "setLocation() is not working properly" In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 05:31:50 GMT, Abhishek Kumar wrote: > > The issue is that the doc area (`in respect to the screen width which is 768px`) which is at the bottom was causing the JFileChooser to be placed slightly above the set location. > > Is it with respect to height ? Yeah, corrected now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17364#issuecomment-1886326932 From abhiscxk at openjdk.org Thu Jan 11 06:17:20 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 11 Jan 2024 06:17:20 GMT Subject: RFR: 8295804: javax/swing/JFileChooser/JFileChooserSetLocationTest.java failed with "setLocation() is not working properly" In-Reply-To: References: Message-ID: <2fFrvAl4_upbnsFnfMd_U7onB7QKfycsEFN03Fz7aKw=.d0bcfeef-e6c8-4b37-aada-e785a3add40d@github.com> On Thu, 11 Jan 2024 04:48:23 GMT, Tejesh R wrote: > The issue is that the doc area (in respect to the screen height which is 768px) which is at the bottom was causing the `JFileChooser `to be placed slightly above the set location. Was able to reproduce in local machine with reference to the failure image provided in the CI logs. The suggested fix is to place the main Frame slightly above the center of the screen than setting at the center of the screen. Several CI runs were made and no issue found. Does the test fails only on the system which is 768px in height or in any other screen size also? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17364#issuecomment-1886362201 From tr at openjdk.org Thu Jan 11 06:28:21 2024 From: tr at openjdk.org (Tejesh R) Date: Thu, 11 Jan 2024 06:28:21 GMT Subject: RFR: 8295804: javax/swing/JFileChooser/JFileChooserSetLocationTest.java failed with "setLocation() is not working properly" In-Reply-To: <2fFrvAl4_upbnsFnfMd_U7onB7QKfycsEFN03Fz7aKw=.d0bcfeef-e6c8-4b37-aada-e785a3add40d@github.com> References: <2fFrvAl4_upbnsFnfMd_U7onB7QKfycsEFN03Fz7aKw=.d0bcfeef-e6c8-4b37-aada-e785a3add40d@github.com> Message-ID: On Thu, 11 Jan 2024 06:14:48 GMT, Abhishek Kumar wrote: > Does the test fails only on the system which is 768px in height or in any other screen size also? Not only on 768, whichever size isn't enough for the FileChooser to show up fully it'll fail. I was able to check till 720px in local machine where it fails. After fix I tested in all C machines and it is green. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17364#issuecomment-1886373685 From abhiscxk at openjdk.org Thu Jan 11 06:49:21 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 11 Jan 2024 06:49:21 GMT Subject: RFR: 8295804: javax/swing/JFileChooser/JFileChooserSetLocationTest.java failed with "setLocation() is not working properly" In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 04:48:23 GMT, Tejesh R wrote: > The issue is that the doc area (in respect to the screen height which is 768px) which is at the bottom was causing the `JFileChooser `to be placed slightly above the set location. Was able to reproduce in local machine with reference to the failure image provided in the CI logs. The suggested fix is to place the main Frame slightly above the center of the screen than setting at the center of the screen. Several CI runs were made and no issue found. test/jdk/javax/swing/JFileChooser/JFileChooserSetLocationTest.java line 217: > 215: int screenWidth = (int) screenSize.getWidth() / 2; > 216: int screenHeight = (int) screenSize.getHeight() / 2; > 217: frame = new JFrame(); Frame should have title. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17364#discussion_r1448363735 From rkannathpari at openjdk.org Thu Jan 11 06:56:26 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Thu, 11 Jan 2024 06:56:26 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 19:50:45 GMT, Sergey Bylokhov wrote: >> Can this patch be covered by the new test? > >>I'm not sure? We want the filter to take another path, there could be a list of filters applied, if I understand @mrserb correctly. Sergey could be able to provide a more detailed guidance. > > The current test validates two code paths: > - wrapper>icc_color_space->wrapper > - icc_color_space->icc_color_space->icc_color_space > > The color space in the middle is always icc_color_space: https://github.com/openjdk/jdk/pull/16895/files#diff-70b19b2642d6d3f44904de8b6eb2993e1c97320e3476898c4372db364c4288b7R130 > > If we will use the wrapper for the middle as well we will cover this code path: > https://github.com/openjdk/jdk/pull/16895/files#diff-e3d6eea060882cab00827c00e1a83b0e0a5b2a31fa9a9aa2122841bbd57c4a6dL853 @mrserb , Did you mean to use the wrapper for the middle like `ColorSpace mid = createCS(ColorSpaceSelector.WRAPPED_PYCC);` , So we can achieve : **Current** **New** wrapper->icc_color_space->wrapper > wrapper->wrapper->wrapper icc_color_space->icc_color_space->icc_color_space > icc_color_space->wrapper->icc_color_space Correct me if I am wrong ------------- PR Comment: https://git.openjdk.org/jdk/pull/16895#issuecomment-1886405188 From tr at openjdk.org Thu Jan 11 07:00:57 2024 From: tr at openjdk.org (Tejesh R) Date: Thu, 11 Jan 2024 07:00:57 GMT Subject: RFR: 8295804: javax/swing/JFileChooser/JFileChooserSetLocationTest.java failed with "setLocation() is not working properly" [v2] In-Reply-To: References: Message-ID: > The issue is that the doc area (in respect to the screen height which is 768px) which is at the bottom was causing the `JFileChooser `to be placed slightly above the set location. Was able to reproduce in local machine with reference to the failure image provided in the CI logs. The suggested fix is to place the main Frame slightly above the center of the screen than setting at the center of the screen. Several CI runs were made and no issue found. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Review fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17364/files - new: https://git.openjdk.org/jdk/pull/17364/files/77926ea3..b6a099e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17364&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17364&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17364.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17364/head:pull/17364 PR: https://git.openjdk.org/jdk/pull/17364 From tr at openjdk.org Thu Jan 11 07:37:31 2024 From: tr at openjdk.org (Tejesh R) Date: Thu, 11 Jan 2024 07:37:31 GMT Subject: Integrated: 8264102: JTable Keyboards Navigation differs with Test Instructions. In-Reply-To: References: Message-ID: On Wed, 3 Jan 2024 04:20:44 GMT, Tejesh R wrote: > Updated the actions for "ctrl shift DOWN" to "`selectLastRowExtendSelection`" and "ctrl shift UP", "`selectFirstRowExtendSelection`" in Basic and other Look and feel. Tested in CI and no regressions found. > Test to be used - [javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java) This pull request has now been integrated. Changeset: 2b7fc050 Author: Tejesh R URL: https://git.openjdk.org/jdk/commit/2b7fc0506ab37f1ec1e63542fb0dcd710c33ef93 Stats: 468 lines in 12 files changed: 238 ins; 213 del; 17 mod 8264102: JTable Keyboards Navigation differs with Test Instructions. Reviewed-by: psadhukhan, abhiscxk ------------- PR: https://git.openjdk.org/jdk/pull/17236 From mbaesken at openjdk.org Thu Jan 11 08:16:31 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 11 Jan 2024 08:16:31 GMT Subject: Integrated: JDK-8323330: [BACKOUT] JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows In-Reply-To: <8WrmYE_8kPUOcMlaCHgCc6RS4UwuUJbu9AgHGuybAh0=.7f152b33-67a9-43a8-8283-28393973beb2@github.com> References: <8WrmYE_8kPUOcMlaCHgCc6RS4UwuUJbu9AgHGuybAh0=.7f152b33-67a9-43a8-8283-28393973beb2@github.com> Message-ID: On Wed, 10 Jan 2024 09:18:53 GMT, Matthias Baesken wrote: > There have been concerns raised about [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) , so bring back the old behavior. This pull request has now been integrated. Changeset: cb1d25fc Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/cb1d25fcfafaa714d3f4dfd600c7dc7c936f8c5e Stats: 8 lines in 1 file changed: 0 ins; 6 del; 2 mod 8323330: [BACKOUT] JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows Reviewed-by: prr, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/17341 From jwaters at openjdk.org Thu Jan 11 08:24:42 2024 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 11 Jan 2024 08:24:42 GMT Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v46] In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: <5WJnl6Z9RyYzZrDStf9p74gus07Stz6S6NHwVpGQO3M=.0a04a120-77b5-48c3-9ae8-7d37c9646463@github.com> > We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 79 commits: - Merge branch 'openjdk:master' into patch-10 - Merge branch 'openjdk:master' into patch-10 - Fix awt_Window.cpp - Fix awt_PrintJob.cpp - -Zc:stringStrings no longer needed with -permissive- flags-cflags.m4 - Fix awt_Window.cpp - awt_Window.cpp - awt_PrintJob.cpp - awt_Frame.cpp - Whitespace awt_Component.cpp - ... and 69 more: https://git.openjdk.org/jdk/compare/35e96627...cbfbaee6 ------------- Changes: https://git.openjdk.org/jdk/pull/15096/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=45 Stats: 615 lines in 12 files changed: 461 ins; 38 del; 116 mod Patch: https://git.openjdk.org/jdk/pull/15096.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15096/head:pull/15096 PR: https://git.openjdk.org/jdk/pull/15096 From jwaters at openjdk.org Thu Jan 11 08:24:45 2024 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 11 Jan 2024 08:24:45 GMT Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v45] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: <7mUIzYDyC19EMMeaxhwrFTnSjicSEYtnlJEhW5yzoPQ=.b050642a-c647-461d-95e2-624c7f1d7914@github.com> On Mon, 4 Dec 2023 09:39:09 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits: > > - Merge branch 'openjdk:master' into patch-10 > - Fix awt_Window.cpp > - Fix awt_PrintJob.cpp > - -Zc:stringStrings no longer needed with -permissive- flags-cflags.m4 > - Fix awt_Window.cpp > - awt_Window.cpp > - awt_PrintJob.cpp > - awt_Frame.cpp > - Whitespace awt_Component.cpp > - awt_Frame.cpp > - ... and 68 more: https://git.openjdk.org/jdk/compare/ed5b8c3a...fda1ab0f Bumping ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1886600273 From psadhukhan at openjdk.org Thu Jan 11 11:31:28 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 11 Jan 2024 11:31:28 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF [v5] In-Reply-To: <-cvWbTu7GFAC0-m3H5l1SvfD2Nmu_k3FZpERUuBKDYM=.6bc08ac5-7ada-4622-8e66-26ef3447265e@github.com> References: <-cvWbTu7GFAC0-m3H5l1SvfD2Nmu_k3FZpERUuBKDYM=.6bc08ac5-7ada-4622-8e66-26ef3447265e@github.com> Message-ID: On Thu, 11 Jan 2024 05:21:51 GMT, Abhishek Kumar wrote: >> The collapsed icon for JTree is not painted using `Icon.paintIcon(Component c, Graphics g, int x, int y)` in GTK LAF. The collapsed icon is returned from BasicTreeUI class which doesn't contain any icon image whereas the expanded icon is returned from SynthTreeUI class and expanded icon is rendered correctly. >> The proposed fix is to return collapsed icon as an object of collapsed icon wrapper which implements synthIcon and is similar to the expanded icon implementation. >> >> Test mentioned in JBS is an applet based which is converted to main based now and extended for all installed LAFs on the system. >> >> No regression caused with the fix, link is attached in JBS . > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Review comment fix and move file outside folder src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTreeUI.java line 161: > 159: > 160: expandedIconWrapper = new IconWrapper(expandedIcon); > 161: collapsedIconWrapper = new IconWrapper(collapsedIcon); It seems `updateStyle` is called for all `propertyChange` event so it can cause memory leak by doing the class instantiation every time it is called.. Probably better place to instantiate this objects is in `installDefaults` after calling `updateStyle` src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTreeUI.java line 809: > 807: } > 808: else { > 809: SynthGraphicsUtils.paintIcon(iconType, context, g, x, y, w, h); Guess it can be further optimized in all these methods if (context == null) { context = getContext(tree); } SynthGraphicsUtils.paintIcon(iconType, context, g, x, y, w, h); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17294#discussion_r1448379415 PR Review Comment: https://git.openjdk.org/jdk/pull/17294#discussion_r1448380657 From psadhukhan at openjdk.org Thu Jan 11 11:38:21 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 11 Jan 2024 11:38:21 GMT Subject: RFR: 8318112: CSS percentage values are capped at 100% In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 09:19:20 GMT, Prasanta Sadhukhan wrote: > Java CSS where values can be displayed in percent are capped at 100% so "width: 200%" and "width: 100%" are equal, which is incorrect. > FIx is made to make sure parsing is not capped at 100% @aivanov-jdk Can you please review? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17299#issuecomment-1886951053 From aivanov at openjdk.org Thu Jan 11 11:45:37 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 11 Jan 2024 11:45:37 GMT Subject: RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java failed with 'Cannot invoke "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is null' In-Reply-To: References: <5oI1DxjQwGFXbXcRPM3cxdcRShLl7V38BstVpQ9k8to=.47da765f-b4e1-4c4b-a643-e317e902318d@github.com> Message-ID: On Thu, 4 Jan 2024 12:32:21 GMT, Alexey Ivanov wrote: > > Thank you, Karl, for bringing the problem in this PR. It already exist in JBS as [JDK-8320692](https://bugs.openjdk.org/browse/JDK-8320692): _Cannot invoke java.awt.Image.getWidth(java.awt.image.ImageObserver)_. > > I added my observations there. The problem is likely applicable to other file types which have per-instance icons, however, these are uncommon with the exception of exe files. The suggested fix won't work, there should be an icon but we have to handle the fallback gracefully. > > @DevCharly Although the exception comes from the same code line, the root cause is different. In this PR, the problem was that a valid icon handle had been interpreted as invalid, thus a valid icon wasn't extracted. In case you reference, there's no icon to extract; I expect the shell to fallback to the default app icon automatically, but it doesn't happen, so we have to provide the fallback ourselves. > > It is a new case that hasn't been encountered before. As [I commented in JBS](https://bugs.openjdk.org/browse/JDK-8320692?focusedId=14638065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14638065), the `NullPointerException` isn't thrown for .exe files without icon in 21+6 where .exe files without icons are displayed with a generic Swing icon. Yet NPE is thrown in 21+7 where this PR is integrated, this means the NPE you reported is a regression from this fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12010#issuecomment-1886961298 From ihse at openjdk.org Thu Jan 11 12:15:04 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 11 Jan 2024 12:15:04 GMT Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v46] In-Reply-To: <5WJnl6Z9RyYzZrDStf9p74gus07Stz6S6NHwVpGQO3M=.0a04a120-77b5-48c3-9ae8-7d37c9646463@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> <5WJnl6Z9RyYzZrDStf9p74gus07Stz6S6NHwVpGQO3M=.0a04a120-77b5-48c3-9ae8-7d37c9646463@github.com> Message-ID: <9FDohoewy_-GOgjWAoENoP2kqDcFzACI7iuFnjBlyyk=.0fba635c-d6ba-4ed6-9412-bdc1115150f0@github.com> On Thu, 11 Jan 2024 08:24:42 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 79 commits: > > - Merge branch 'openjdk:master' into patch-10 > - Merge branch 'openjdk:master' into patch-10 > - Fix awt_Window.cpp > - Fix awt_PrintJob.cpp > - -Zc:stringStrings no longer needed with -permissive- flags-cflags.m4 > - Fix awt_Window.cpp > - awt_Window.cpp > - awt_PrintJob.cpp > - awt_Frame.cpp > - Whitespace awt_Component.cpp > - ... and 69 more: https://git.openjdk.org/jdk/compare/35e96627...cbfbaee6 What is remaining to get this PR committable? It has such a long history that it is hard to get a grasp on the remaining issues. @TheShermanTanker Could you perhaps summarize the remaining hurdles? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1887030877 From jwaters at openjdk.org Thu Jan 11 12:25:08 2024 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 11 Jan 2024 12:25:08 GMT Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v46] In-Reply-To: <9FDohoewy_-GOgjWAoENoP2kqDcFzACI7iuFnjBlyyk=.0fba635c-d6ba-4ed6-9412-bdc1115150f0@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> <5WJnl6Z9RyYzZrDStf9p74gus07Stz6S6NHwVpGQO3M=.0a04a120-77b5-48c3-9ae8-7d37c9646463@github.com> <9FDohoewy_-GOgjWAoENoP2kqDcFzACI7iuFnjBlyyk=.0fba635c-d6ba-4ed6-9412-bdc1115150f0@github.com> Message-ID: On Thu, 11 Jan 2024 12:11:17 GMT, Magnus Ihse Bursie wrote: > What is remaining to get this PR committable? It has such a long history that it is hard to get a grasp on the remaining issues. > > @TheShermanTanker Could you perhaps summarize the remaining hurdles? It's largely complete by now, just waiting for approval from @prrace for the awt parts of the codebase. The vast majority of this is just hand-inlining macros in awt to avoid jumping across locals with gotos, it's very messy on the surface, sorry about that :( And of course, as soon as I say that I get a mass JTReg failure that makes nearly every run on GHA turn red, thanks for the heart attack JTReg ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1887046380 From abhiscxk at openjdk.org Thu Jan 11 15:21:46 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 11 Jan 2024 15:21:46 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF [v6] In-Reply-To: References: Message-ID: > The collapsed icon for JTree is not painted using `Icon.paintIcon(Component c, Graphics g, int x, int y)` in GTK LAF. The collapsed icon is returned from BasicTreeUI class which doesn't contain any icon image whereas the expanded icon is returned from SynthTreeUI class and expanded icon is rendered correctly. > The proposed fix is to return collapsed icon as an object of collapsed icon wrapper which implements synthIcon and is similar to the expanded icon implementation. > > Test mentioned in JBS is an applet based which is converted to main based now and extended for all installed LAFs on the system. > > No regression caused with the fix, link is attached in JBS . Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Review comment update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17294/files - new: https://git.openjdk.org/jdk/pull/17294/files/17d9bdc2..33bd4e3d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17294&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17294&range=04-05 Stats: 143 lines in 2 files changed: 124 ins; 17 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17294.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17294/head:pull/17294 PR: https://git.openjdk.org/jdk/pull/17294 From abhiscxk at openjdk.org Thu Jan 11 15:21:50 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 11 Jan 2024 15:21:50 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF [v5] In-Reply-To: References: <-cvWbTu7GFAC0-m3H5l1SvfD2Nmu_k3FZpERUuBKDYM=.6bc08ac5-7ada-4622-8e66-26ef3447265e@github.com> Message-ID: On Thu, 11 Jan 2024 07:07:10 GMT, Prasanta Sadhukhan wrote: >> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comment fix and move file outside folder > > src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTreeUI.java line 161: > >> 159: >> 160: expandedIconWrapper = new IconWrapper(expandedIcon); >> 161: collapsedIconWrapper = new IconWrapper(collapsedIcon); > > It seems `updateStyle` is called for all `propertyChange` event so it can cause memory leak by doing the class instantiation every time it is called.. > Probably better place to instantiate this objects is in `installDefaults` after calling `updateStyle` Updated. > src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTreeUI.java line 809: > >> 807: } >> 808: else { >> 809: SynthGraphicsUtils.paintIcon(iconType, context, g, x, y, w, h); > > Guess it can be further optimized in all these methods > > if (context == null) { > context = getContext(tree); > } > SynthGraphicsUtils.paintIcon(iconType, context, g, x, y, w, h); Updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17294#discussion_r1449015436 PR Review Comment: https://git.openjdk.org/jdk/pull/17294#discussion_r1449015571 From mbaesken at openjdk.org Thu Jan 11 16:52:40 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 11 Jan 2024 16:52:40 GMT Subject: RFR: JDK-8320405: [Windows Server 2016] java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java shows issues in awt_Win32GraphicsDevice.cpp [v3] In-Reply-To: References: Message-ID: > When running with fastdebug binaries we run intermittent into the issue below in > jtreg test java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java . > Seems we miss checking of successful HBITMAP creation before calling GetDIBits. > > HDC hBMDC = this->GetDC(); > HBITMAP hBM = ::CreateCompatibleBitmap(hBMDC, 1, 1); > VERIFY(::GetDIBits(hBMDC, hBM, 0, 1, NULL, gpBitmapInfo, DIB_RGB_COLORS)); > > in awt_Win32GraphicsDevice.cpp . Thats why the releast of hBMDC / hBM fails as well at the end of the function causing the seond and third warning. > > > Sat Nov 18 17:29:23 CET 2023 > > ********************* > AWT Assertion Failure > ********************* > ::GetDIBits(hBMDC, hBM, 0, 1, 0, gpBitmapInfo, 0) > File 'e:\openjdk\openjdk-21u-windows_x86_64-dbg\jdk\src\java.desktop\windows\native\libawt\windows\awt_Win32GraphicsDevice.cpp', at line 184 > GetLastError() is 57 : The parameter is incorrect. > > Do you want to break into the debugger? > ********************* > ********************* > AWT Assertion Failure > ********************* > ::DeleteObject(hBM) > File 'e:\openjdk\openjdk-21u-windows_x86_64-dbg\jdk\src\java.desktop\windows\native\libawt\windows\awt_Win32GraphicsDevice.cpp', at line 297 > GetLastError() is 57 : The parameter is incorrect. > > So it seems, we should have some additional checks/tracing. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: do not call CreateCompatibleBitmap if hBMDC is NULL, do not call GetDIBits if hBM is NULL ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17197/files - new: https://git.openjdk.org/jdk/pull/17197/files/2e0d83f1..f7a5b7e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17197&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17197&range=01-02 Stats: 10 lines in 1 file changed: 4 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/17197.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17197/head:pull/17197 PR: https://git.openjdk.org/jdk/pull/17197 From mark.yagnatinsky at barclays.com Thu Jan 11 18:43:47 2024 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Thu, 11 Jan 2024 18:43:47 +0000 Subject: the easiest ways to play an audio clip are the discouraged ones In-Reply-To: References: Message-ID: Thanks for raising that. Since I can?t comment on that issue directly, let me respond here to the claim by Alex Z. that ?it?s not so bad?: I agree that the code snippet he posted doesn?t look too bad, at least for the async case. But!! Consider the following: 1. We never closed the stream. Is this ?fine? or are we leaking an OS file handle? We also never closed the clip. Who knows what that leaks? Maybe a thread or two? (If we need not close these, the docs should make that clearer; I think we do.) I see the JDK code has a concept of an auto-closing clip but the docs don?t mention it. 2. But of course, we can?t close the clip or the stream, or else playback ends. Thus we must wait for it to finish. So the whole async approach is not viable. The REAL way to do async is to actually to do sync, but on another thread. 3. So how do we do sync then? The example code by Alex Z uses busy looping. Nice and simple for short clips, but pretty rude if the clip lasts more than a few seconds. Easy fix: try{Thread.sleep(clip. getMicrosecondLength/1000);} catch(InterruptedException impossible){Thread.currentThread.interrupt();} 4. This works for .wav files but not some of the more obscure file types that Java supports. (In fact I don?t think it?s even guaranteed to work for ALL wav files.) It works only for files encoded using PCM. If you try to open a .au file, you?ll likely get an exception during playback. To support EVERYTHING, we need to basically copy/paste the implementation of com.sun.media.sound.Toolkit#getPCMConvertedAudioInputStream Not so simple any more. From: Philip Race Sent: Monday, January 8, 2024 3:05 PM To: Yagnatinsky, Mark : Markets Pre Trade ; mickleness at gmail.com Cc: client-libs-dev at openjdk.org Subject: Re: the easiest ways to play an audio clip are the discouraged ones CAUTION: This email originated from outside our organisation - philip.race at oracle.com Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. Mark, It does seem like there's an ease of use gap here that will widen considerably when Applet is removed. The Applet AudioClip code is actually built on top of javax.sound public APIs so we should at least find an alternative place to surface that functionality. I submitted https://bugs.openjdk.org/browse/JDK-8323215 -phil. On 1/1/24 10:27 PM, mark.yagnatinsky at barclays.com wrote: Thanks Julian (and sorry for messing up the message threading? I?ll try not to do that next time). It looks like you built a ?full-fledged? audio player, and it took hundreds of lines of code. Maybe that?s reasonable for a full-fledged audio player. But it?s unfortunate that even a basic ?fire and forget? feature to play an audio file should take lots of lines. This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. For important disclosures, please see: https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com. __________________________________________________________________________________ If you are incorporated or operating in Australia, read these important disclosures: https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html. __________________________________________________________________________________ For more details about how we use personal information, see our privacy notice: https://www.cib.barclays/disclosures/personal-information-use.html. __________________________________________________________________________________ This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. For important disclosures, please see: https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com. __________________________________________________________________________________ If you are incorporated or operating in Australia, read these important disclosures: https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html. __________________________________________________________________________________ For more details about how we use personal information, see our privacy notice: https://www.cib.barclays/disclosures/personal-information-use.html. __________________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmahajan at openjdk.org Thu Jan 11 18:47:40 2024 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Thu, 11 Jan 2024 18:47:40 GMT Subject: RFR: 8301994: Remove unused code from awt_List.cpp Message-ID: Remove commented out/ unused code from awt_List.cpp, which has been commented out since 2007, when the code was moved to Mercurial. The test ScrollPaneLimitation.java has been opened under [JDK-8306137](https://bugs.openjdk.org/browse/JDK-8306137), and it should be safe to remove this code now. ------------- Commit messages: - Remove unused code from awt_List.cpp Changes: https://git.openjdk.org/jdk/pull/17378/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17378&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301994 Stats: 10 lines in 1 file changed: 0 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17378.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17378/head:pull/17378 PR: https://git.openjdk.org/jdk/pull/17378 From azvegint at openjdk.org Thu Jan 11 18:54:22 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 11 Jan 2024 18:54:22 GMT Subject: RFR: JDK-8312518 : [macos13] setFullScreenWindow() shows black screen on macOS 13 & above In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 21:35:57 GMT, Harshitha Onkar wrote: > A black screen is seen on newer versions of macOS (13.3 & above) when a window is set to full-screen using `setFullScreenWindow()`. The root cause was narrowed down to the shield level of the full-screen window vs the shield level of the captured display. > > Following solutions were explored - > > 1. Setting `kCGMaximumWindowLevelKey` as the shield level for the full screen window. But setting the fullscreen window to maximum available window level might cause z-order issues when other popup/screen savers are involved. > > int shieldLevel = CGWindowLevelForKey(kCGMaximumWindowLevelKey); > window.preFullScreenLevel = [nsWindow level]; > [nsWindow setLevel: shieldLevel]; > > 2. Raise the window's level slightly (shieldLevel + 1) above the system shield window. > > int shieldLevel = CGShieldingWindowLevel(); > window.preFullScreenLevel = [nsWindow level]; > [nsWindow setLevel: (shieldLevel + 1)]; > > 3. Keeping the shielding level as-is and bringing the window to the foreground after display is captured. The 3rd approach **(also the one Apple recommends)** ensures that the full screen window has focus as well as being visible and also maintains the correct z-order. This solution works as expected on older (< 13.3) and newer versions (13.3 & above) of macOS. > > if (CGDisplayCapture(aID) == kCGErrorSuccess) { > ... > ... > int shieldLevel = CGShieldingWindowLevel(); > window.preFullScreenLevel = [nsWindow level]; > [nsWindow setLevel: shieldLevel]; > [nsWindow makeKeyAndOrderFront: nil]; > } Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17358#pullrequestreview-1816318868 From vdyakov at openjdk.org Thu Jan 11 19:15:25 2024 From: vdyakov at openjdk.org (Victor Dyakov) Date: Thu, 11 Jan 2024 19:15:25 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v2] In-Reply-To: <7dpKxrn8QG4b5Xkzv921rdgttZuZw-DwBBniheoTn8A=.f0daf114-7631-4214-8af9-57cb3ccd33f4@github.com> References: <7dpKxrn8QG4b5Xkzv921rdgttZuZw-DwBBniheoTn8A=.f0daf114-7631-4214-8af9-57cb3ccd33f4@github.com> Message-ID: <0-5j7Zjqe8RBbPGWZ_Zqcgn1_AocsJc3qqwwzK885S8=.184fcdcb-1e36-44ea-9975-fbc177da69d2@github.com> On Wed, 10 Jan 2024 21:08:35 GMT, Alisen Chung wrote: >> SunToolkit.java is trying to post an event on the TrayIcon appContext, but the TrayIcon was already removed by the test, causing an error. The fix is to make SunToolkit skip posting the event if appContext is null. The test is also updated to remove applet usage and use PassFailJFrame instead. > > Alisen Chung has updated the pull request incrementally with two additional commits since the last revision: > > - spacing > - updated test title, copyright year, removed redundant check @azuev-java please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/17329#issuecomment-1887796333 From honkar at openjdk.org Thu Jan 11 20:30:19 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 11 Jan 2024 20:30:19 GMT Subject: RFR: JDK-8320056 : [macos14] Add missing null checks to GetMousePositionWithPopup.java test Message-ID: This test passes on the latest version of macOS (14.2). The reason as to why this passes on the latest version of macOS is the order in which native Mouse Moved event is received. Details and native event logs added to the JBS issue. While looking into it noticed missing null checks in test hence adding them as part of this PR. ------------- Commit messages: - null checks added Changes: https://git.openjdk.org/jdk/pull/17380/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17380&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320056 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/17380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17380/head:pull/17380 PR: https://git.openjdk.org/jdk/pull/17380 From honkar at openjdk.org Thu Jan 11 20:30:20 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 11 Jan 2024 20:30:20 GMT Subject: RFR: JDK-8320056 : [macos14] Add missing null checks to GetMousePositionWithPopup.java test In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 20:04:56 GMT, Harshitha Onkar wrote: > This test passes on the latest version of macOS (14.2). The reason as to why this passes on the latest version of macOS is the order in which native Mouse Moved event is received. Details and native event logs added to the JBS issue. > > While looking into it noticed missing null checks in test hence adding them as part of this PR. The missing null check will cause an NPE in finally block when frame2 is not created in case mouse move event is not received. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17380#issuecomment-1887891690 From serb at openjdk.org Thu Jan 11 21:32:18 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 11 Jan 2024 21:32:18 GMT Subject: RFR: JDK-8323617 : Add missing null checks to GetMousePositionWithPopup.java test In-Reply-To: References: Message-ID: <1DEeR-et-9_z0gYwfhDSnu4k_9oqgLRTQYT2xzuqgr4=.5e5234e8-5ac6-45ee-a4be-9716ffd35879@github.com> On Thu, 11 Jan 2024 20:04:56 GMT, Harshitha Onkar wrote: > While investigating a macOS 14 issue noticed missing null checks in java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java > > The missing null check will cause an NPE in finally block when frame2 is not created in the event that mouse move is not received. > > PS: This test passes on the latest version of macOS (14.2) Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17380#pullrequestreview-1816753248 From serb at openjdk.org Thu Jan 11 22:11:20 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 11 Jan 2024 22:11:20 GMT Subject: RFR: 8301994: Remove unused code from awt_List.cpp In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 18:43:00 GMT, Rajat Mahajan wrote: > Remove commented out/ unused code from awt_List.cpp, which has been commented out since 2007, when the code was moved to Mercurial. > The test ScrollPaneLimitation.java has been opened under [JDK-8306137](https://bugs.openjdk.org/browse/JDK-8306137), and it should be safe to remove this code now. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17378#pullrequestreview-1816857059 From achung at openjdk.org Thu Jan 11 22:28:25 2024 From: achung at openjdk.org (Alisen Chung) Date: Thu, 11 Jan 2024 22:28:25 GMT Subject: RFR: 8321489: Update LCMS to 2.16 Message-ID: Update LCMS, mach5 client tests are green ------------- Commit messages: - update - init commit Changes: https://git.openjdk.org/jdk/pull/17382/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17382&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321489 Stats: 1599 lines in 21 files changed: 1240 ins; 134 del; 225 mod Patch: https://git.openjdk.org/jdk/pull/17382.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17382/head:pull/17382 PR: https://git.openjdk.org/jdk/pull/17382 From prr at openjdk.org Thu Jan 11 23:24:19 2024 From: prr at openjdk.org (Phil Race) Date: Thu, 11 Jan 2024 23:24:19 GMT Subject: RFR: 8301994: Remove unused code from awt_List.cpp In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 18:43:00 GMT, Rajat Mahajan wrote: > Remove commented out/ unused code from awt_List.cpp, which has been commented out since 2007, when the code was moved to Mercurial. > The test ScrollPaneLimitation.java has been opened under [JDK-8306137](https://bugs.openjdk.org/browse/JDK-8306137), and it should be safe to remove this code now. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17378#pullrequestreview-1817008050 From serb at openjdk.org Fri Jan 12 01:22:24 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 12 Jan 2024 01:22:24 GMT Subject: RFR: 8295804: javax/swing/JFileChooser/JFileChooserSetLocationTest.java failed with "setLocation() is not working properly" [v2] In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 06:46:43 GMT, Abhishek Kumar wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Review fix > > test/jdk/javax/swing/JFileChooser/JFileChooserSetLocationTest.java line 217: > >> 215: int screenWidth = (int) screenSize.getWidth() / 2; >> 216: int screenHeight = (int) screenSize.getHeight() / 2; >> 217: frame = new JFrame(); > > Frame should have title. "screenWidth" and "screenHeight" seems not the width and height, it is better to use some other name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17364#discussion_r1449629687 From serb at openjdk.org Fri Jan 12 02:58:23 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 12 Jan 2024 02:58:23 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 06:53:22 GMT, Renjith Kannath Pariyangad wrote: >Did you mean to use the wrapper for the middle like ColorSpace mid = createCS(ColorSpaceSelector.WRAPPED_PYCC); , So we can achieve : Just repeat existed checks using wrapper. So you will have all combinations: > wrapper->icc_color_space->wrapper > icc_color_space->icc_color_space->icc_color_space > wrapper->wrapper->wrapper > icc_color_space->wrapper->icc_color_space ------------- PR Comment: https://git.openjdk.org/jdk/pull/16895#issuecomment-1888355107 From rkannathpari at openjdk.org Fri Jan 12 02:58:29 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Fri, 12 Jan 2024 02:58:29 GMT Subject: Integrated: 8320673 : PageFormat/CustomPaper.java has no Pass/Fail buttons; multiple instructions In-Reply-To: References: Message-ID: On Wed, 27 Dec 2023 04:20:42 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > > I have updated the test case. Now test has pass/fail option also test will execute two time for covering different cases which are part of the test. > > Please review and let me know your suggestions. > > Regards, > Renjith. This pull request has now been integrated. Changeset: 0ff2deab Author: Renjith Kannath Pariyangad Committer: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/0ff2deab5d6b8228ddfed9ae08820d2adf2330c2 Stats: 279 lines in 1 file changed: 82 ins; 144 del; 53 mod 8320673: PageFormat/CustomPaper.java has no Pass/Fail buttons; multiple instructions Reviewed-by: serb, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/17194 From psadhukhan at openjdk.org Fri Jan 12 03:12:22 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 12 Jan 2024 03:12:22 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF [v6] In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 15:21:46 GMT, Abhishek Kumar wrote: >> The collapsed icon for JTree is not painted using `Icon.paintIcon(Component c, Graphics g, int x, int y)` in GTK LAF. The collapsed icon is returned from BasicTreeUI class which doesn't contain any icon image whereas the expanded icon is returned from SynthTreeUI class and expanded icon is rendered correctly. >> The proposed fix is to return collapsed icon as an object of collapsed icon wrapper which implements synthIcon and is similar to the expanded icon implementation. >> >> Test mentioned in JBS is an applet based which is converted to main based now and extended for all installed LAFs on the system. >> >> No regression caused with the fix, link is attached in JBS . > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Review comment update Marked as reviewed by psadhukhan (Reviewer). src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTreeUI.java line 791: > 789: // > 790: // BasicTreeUI directly uses expandIcon outside of the Synth methods. > 791: // To get the correct context we return an instance of this that fetches We need to add collapsedIcon in the comment too now.. ------------- PR Review: https://git.openjdk.org/jdk/pull/17294#pullrequestreview-1816110275 PR Review Comment: https://git.openjdk.org/jdk/pull/17294#discussion_r1449180647 From abhiscxk at openjdk.org Fri Jan 12 04:10:09 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 12 Jan 2024 04:10:09 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF [v7] In-Reply-To: References: Message-ID: > The collapsed icon for JTree is not painted using `Icon.paintIcon(Component c, Graphics g, int x, int y)` in GTK LAF. The collapsed icon is returned from BasicTreeUI class which doesn't contain any icon image whereas the expanded icon is returned from SynthTreeUI class and expanded icon is rendered correctly. > The proposed fix is to return collapsed icon as an object of collapsed icon wrapper which implements synthIcon and is similar to the expanded icon implementation. > > Test mentioned in JBS is an applet based which is converted to main based now and extended for all installed LAFs on the system. > > No regression caused with the fix, link is attached in JBS . Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: comment added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17294/files - new: https://git.openjdk.org/jdk/pull/17294/files/33bd4e3d..5ae0304f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17294&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17294&range=05-06 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17294.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17294/head:pull/17294 PR: https://git.openjdk.org/jdk/pull/17294 From abhiscxk at openjdk.org Fri Jan 12 04:10:12 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 12 Jan 2024 04:10:12 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF [v6] In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 17:28:42 GMT, Prasanta Sadhukhan wrote: >> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comment update > > src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTreeUI.java line 791: > >> 789: // >> 790: // BasicTreeUI directly uses expandIcon outside of the Synth methods. >> 791: // To get the correct context we return an instance of this that fetches > > We need to add collapsedIcon in the comment too now.. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17294#discussion_r1449786050 From abhiscxk at openjdk.org Fri Jan 12 04:16:19 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 12 Jan 2024 04:16:19 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v2] In-Reply-To: <7dpKxrn8QG4b5Xkzv921rdgttZuZw-DwBBniheoTn8A=.f0daf114-7631-4214-8af9-57cb3ccd33f4@github.com> References: <7dpKxrn8QG4b5Xkzv921rdgttZuZw-DwBBniheoTn8A=.f0daf114-7631-4214-8af9-57cb3ccd33f4@github.com> Message-ID: On Wed, 10 Jan 2024 21:08:35 GMT, Alisen Chung wrote: >> SunToolkit.java is trying to post an event on the TrayIcon appContext, but the TrayIcon was already removed by the test, causing an error. The fix is to make SunToolkit skip posting the event if appContext is null. The test is also updated to remove applet usage and use PassFailJFrame instead. > > Alisen Chung has updated the pull request incrementally with two additional commits since the last revision: > > - spacing > - updated test title, copyright year, removed redundant check Extra blank lines can be removed else looks good to me. Since `html` file has been removed, I guess the java file can be taken out of `ShowAfterDisposeTest` folder. ------------- Marked as reviewed by abhiscxk (Committer). PR Review: https://git.openjdk.org/jdk/pull/17329#pullrequestreview-1817331918 PR Comment: https://git.openjdk.org/jdk/pull/17329#issuecomment-1888406196 From tr at openjdk.org Fri Jan 12 04:59:25 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 12 Jan 2024 04:59:25 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF [v7] In-Reply-To: References: Message-ID: On Fri, 12 Jan 2024 04:10:09 GMT, Abhishek Kumar wrote: >> The collapsed icon for JTree is not painted using `Icon.paintIcon(Component c, Graphics g, int x, int y)` in GTK LAF. The collapsed icon is returned from BasicTreeUI class which doesn't contain any icon image whereas the expanded icon is returned from SynthTreeUI class and expanded icon is rendered correctly. >> The proposed fix is to return collapsed icon as an object of collapsed icon wrapper which implements synthIcon and is similar to the expanded icon implementation. >> >> Test mentioned in JBS is an applet based which is converted to main based now and extended for all installed LAFs on the system. >> >> No regression caused with the fix, link is attached in JBS . > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > comment added test/jdk/javax/swing/JTree/bug8038113.java line 48: > 46: */ > 47: > 48: public class bug8038113 { Will it be better to change the file & class name to something meaningful instead of bug id since now two bugs refer to same test? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17294#discussion_r1449842428 From tr at openjdk.org Fri Jan 12 05:12:40 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 12 Jan 2024 05:12:40 GMT Subject: RFR: 8295804: javax/swing/JFileChooser/JFileChooserSetLocationTest.java failed with "setLocation() is not working properly" [v3] In-Reply-To: References: Message-ID: > The issue is that the doc area (in respect to the screen height which is 768px) which is at the bottom was causing the `JFileChooser `to be placed slightly above the set location. Was able to reproduce in local machine with reference to the failure image provided in the CI logs. The suggested fix is to place the main Frame slightly above the center of the screen than setting at the center of the screen. Several CI runs were made and no issue found. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Review fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17364/files - new: https://git.openjdk.org/jdk/pull/17364/files/b6a099e9..e8dfd6b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17364&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17364&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17364.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17364/head:pull/17364 PR: https://git.openjdk.org/jdk/pull/17364 From abhiscxk at openjdk.org Fri Jan 12 05:16:23 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 12 Jan 2024 05:16:23 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF [v7] In-Reply-To: References: Message-ID: <1wOqi9mc_fbCmw2Uh387eHw1r4tE02grDOtIQN_6T-c=.9533d5b5-1129-4463-b65d-f8d95bf21a55@github.com> On Fri, 12 Jan 2024 04:56:23 GMT, Tejesh R wrote: >> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> comment added > > test/jdk/javax/swing/JTree/bug8038113.java line 48: > >> 46: */ >> 47: >> 48: public class bug8038113 { > > Will it be better to change the file & class name to something meaningful instead of bug id since now two bugs refer to same test? Don't think so. Since I am converting the test from applet based it should be ok to just mention the new bug id in jtreg tags. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17294#discussion_r1449852202 From tr at openjdk.org Fri Jan 12 05:22:21 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 12 Jan 2024 05:22:21 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF [v7] In-Reply-To: References: Message-ID: On Fri, 12 Jan 2024 04:10:09 GMT, Abhishek Kumar wrote: >> The collapsed icon for JTree is not painted using `Icon.paintIcon(Component c, Graphics g, int x, int y)` in GTK LAF. The collapsed icon is returned from BasicTreeUI class which doesn't contain any icon image whereas the expanded icon is returned from SynthTreeUI class and expanded icon is rendered correctly. >> The proposed fix is to return collapsed icon as an object of collapsed icon wrapper which implements synthIcon and is similar to the expanded icon implementation. >> >> Test mentioned in JBS is an applet based which is converted to main based now and extended for all installed LAFs on the system. >> >> No regression caused with the fix, link is attached in JBS . > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > comment added Marked as reviewed by tr (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17294#pullrequestreview-1817419435 From tr at openjdk.org Fri Jan 12 05:22:24 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 12 Jan 2024 05:22:24 GMT Subject: RFR: 8258979: The image didn't show correctly with GTK LAF [v7] In-Reply-To: <1wOqi9mc_fbCmw2Uh387eHw1r4tE02grDOtIQN_6T-c=.9533d5b5-1129-4463-b65d-f8d95bf21a55@github.com> References: <1wOqi9mc_fbCmw2Uh387eHw1r4tE02grDOtIQN_6T-c=.9533d5b5-1129-4463-b65d-f8d95bf21a55@github.com> Message-ID: On Fri, 12 Jan 2024 05:13:20 GMT, Abhishek Kumar wrote: >> test/jdk/javax/swing/JTree/bug8038113.java line 48: >> >>> 46: */ >>> 47: >>> 48: public class bug8038113 { >> >> Will it be better to change the file & class name to something meaningful instead of bug id since now two bugs refer to same test? > > Don't think so. Since I am converting the test from applet based it should be ok to just mention the new bug id in jtreg tags. Ok, else it look good to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17294#discussion_r1449854677 From abhiscxk at openjdk.org Fri Jan 12 06:35:26 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 12 Jan 2024 06:35:26 GMT Subject: RFR: 8187759: Background not refreshed when painting over a transparent JFrame In-Reply-To: References: Message-ID: <3187PRMY_lVo9Q6qLLeR4SvARG-daaS6ERyj2ONVjD8=.450e9e6e-8abb-4129-a89e-02a5816300a9@github.com> On Tue, 12 Dec 2023 13:04:26 GMT, Tejesh R wrote: > This is happening in linux where `BuffereStrategyPaintManager` is used to paint to offscreen. Here `bsg` bufferStrategy SunGraphics2D is used to paint to offscreen where the background is not refreshed, which does only clipping and then paints to offscreen. In order to handle the screen updated/clear the buffer, `setBackground` to component background color and `clearRect` against the clip area is used which solves the issue without causing any regression. > CI is green for the fix and manual test is provided. test/jdk/javax/swing/JFrame/JFrameBackgroundRefreshTest.java line 89: > 87: frame.addMouseMotionListener(new MouseDragListener()); > 88: frame.setVisible(true); > 89: May not require. test/jdk/javax/swing/JFrame/JFrameBackgroundRefreshTest.java line 90: > 88: frame.setVisible(true); > 89: > 90: } Blank line before method. test/jdk/javax/swing/JFrame/JFrameBackgroundRefreshTest.java line 101: > 99: /** Capture an image of any component **/ > 100: private static BufferedImage getImage(Component c) { > 101: if(c==null) return null; Suggestion: if (c == null) { return null; } test/jdk/javax/swing/JFrame/JFrameBackgroundRefreshTest.java line 122: > 120: public TranslucentPane() { > 121: setOpaque(false); > 122: } Blank line after this. test/jdk/javax/swing/JFrame/JFrameBackgroundRefreshTest.java line 129: > 127: g2d.setColor(new Color(0,0,0,0)); > 128: g2d.fillRect(0, 0, getWidth(), getHeight()); > 129: g2d.drawImage(test, p.x, p.y, this); should we dispose `Graphics2D` object? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17081#discussion_r1449902105 PR Review Comment: https://git.openjdk.org/jdk/pull/17081#discussion_r1449901861 PR Review Comment: https://git.openjdk.org/jdk/pull/17081#discussion_r1449902602 PR Review Comment: https://git.openjdk.org/jdk/pull/17081#discussion_r1449903249 PR Review Comment: https://git.openjdk.org/jdk/pull/17081#discussion_r1449904073 From tr at openjdk.org Fri Jan 12 07:17:37 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 12 Jan 2024 07:17:37 GMT Subject: RFR: 8187759: Background not refreshed when painting over a transparent JFrame [v2] In-Reply-To: References: Message-ID: > This is happening in linux where `BuffereStrategyPaintManager` is used to paint to offscreen. Here `bsg` bufferStrategy SunGraphics2D is used to paint to offscreen where the background is not refreshed, which does only clipping and then paints to offscreen. In order to handle the screen updated/clear the buffer, `setBackground` to component background color and `clearRect` against the clip area is used which solves the issue without causing any regression. > CI is green for the fix and manual test is provided. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Review fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17081/files - new: https://git.openjdk.org/jdk/pull/17081/files/925b1b06..c72d9295 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17081&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17081&range=00-01 Stats: 7 lines in 1 file changed: 5 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17081.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17081/head:pull/17081 PR: https://git.openjdk.org/jdk/pull/17081 From tr at openjdk.org Fri Jan 12 07:17:39 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 12 Jan 2024 07:17:39 GMT Subject: RFR: 8187759: Background not refreshed when painting over a transparent JFrame [v2] In-Reply-To: <3187PRMY_lVo9Q6qLLeR4SvARG-daaS6ERyj2ONVjD8=.450e9e6e-8abb-4129-a89e-02a5816300a9@github.com> References: <3187PRMY_lVo9Q6qLLeR4SvARG-daaS6ERyj2ONVjD8=.450e9e6e-8abb-4129-a89e-02a5816300a9@github.com> Message-ID: On Fri, 12 Jan 2024 06:32:55 GMT, Abhishek Kumar wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Review fix > > test/jdk/javax/swing/JFrame/JFrameBackgroundRefreshTest.java line 129: > >> 127: g2d.setColor(new Color(0,0,0,0)); >> 128: g2d.fillRect(0, 0, getWidth(), getHeight()); >> 129: g2d.drawImage(test, p.x, p.y, this); > > should we dispose `Graphics2D` object? Yes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17081#discussion_r1449949585 From abhiscxk at openjdk.org Fri Jan 12 07:56:29 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 12 Jan 2024 07:56:29 GMT Subject: Integrated: 8258979: The image didn't show correctly with GTK LAF In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 07:29:13 GMT, Abhishek Kumar wrote: > The collapsed icon for JTree is not painted using `Icon.paintIcon(Component c, Graphics g, int x, int y)` in GTK LAF. The collapsed icon is returned from BasicTreeUI class which doesn't contain any icon image whereas the expanded icon is returned from SynthTreeUI class and expanded icon is rendered correctly. > The proposed fix is to return collapsed icon as an object of collapsed icon wrapper which implements synthIcon and is similar to the expanded icon implementation. > > Test mentioned in JBS is an applet based which is converted to main based now and extended for all installed LAFs on the system. > > No regression caused with the fix, link is attached in JBS . This pull request has now been integrated. Changeset: 82a63a03 Author: Abhishek Kumar URL: https://git.openjdk.org/jdk/commit/82a63a03c0155288e8e43b9f766c8be70be50b6a Stats: 276 lines in 4 files changed: 139 ins; 132 del; 5 mod 8258979: The image didn't show correctly with GTK LAF Reviewed-by: psadhukhan, tr ------------- PR: https://git.openjdk.org/jdk/pull/17294 From rkannathpari at openjdk.org Fri Jan 12 09:53:46 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Fri, 12 Jan 2024 09:53:46 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v14] In-Reply-To: References: Message-ID: > Hi Reviewers, > There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. > > Renjith. Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Included wrapper check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16895/files - new: https://git.openjdk.org/jdk/pull/16895/files/6d47f16b..bec09a31 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=12-13 Stats: 19 lines in 1 file changed: 16 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16895.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16895/head:pull/16895 PR: https://git.openjdk.org/jdk/pull/16895 From rkannathpari at openjdk.org Fri Jan 12 09:53:47 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Fri, 12 Jan 2024 09:53:47 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix In-Reply-To: References: Message-ID: <-CEdkqsoxNsVRMnjua-onpIWXLPYUkU7uVjYk9O1BJM=.f2a3f146-f519-4e4e-8434-0c80f4311c77@github.com> On Fri, 12 Jan 2024 02:55:59 GMT, Sergey Bylokhov wrote: >> @mrserb , >> >> Did you mean to use the wrapper for the middle like `ColorSpace mid = createCS(ColorSpaceSelector.WRAPPED_PYCC);` , So we can achieve : >> >> **From** >> wrapper->icc_color_space->wrapper >> icc_color_space->icc_color_space->icc_color_space >> >> **To** : >> wrapper->wrapper->wrapper >> icc_color_space->wrapper->icc_color_space >> >> Correct me if I am wrong > >>Did you mean to use the wrapper for the middle like ColorSpace mid = createCS(ColorSpaceSelector.WRAPPED_PYCC); , So we can achieve : > > Just repeat existed checks using wrapper. So you will have all combinations: > >> wrapper->icc_color_space->wrapper >> icc_color_space->icc_color_space->icc_color_space >> wrapper->wrapper->wrapper >> icc_color_space->wrapper->icc_color_space @mrserb thank you for clarifying, repeated the check for covering all cases please review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16895#issuecomment-1888770449 From perini.davide at dpsoftware.org Fri Jan 12 11:40:09 2024 From: perini.davide at dpsoftware.org (Davide Perini) Date: Fri, 12 Jan 2024 12:40:09 +0100 Subject: Windows 11: Notifications vanishes after few seconds. In-Reply-To: <310e0659-fd0f-45c7-b462-7755a0144c34@dpsoftware.org> References: <9ecd6e22-3eb1-489b-b166-652a2fd1bf22@dpsoftware.org> <77e4ab4a-3813-4e83-b464-a4400dbe05f2@oracle.com> <310e0659-fd0f-45c7-b462-7755a0144c34@dpsoftware.org> Message-ID: <07b98c88-3129-4aec-90d9-4b614443cb7d@dpsoftware.org> I wrote to Microsoft and they suggested to use the New APIs (ToastNotification) meant for the purpose https://learn.microsoft.com/en-us/windows/apps/design/shell/tiles-and-notifications/toast-notifications-overview https://learn.microsoft.com/en-us/windows/apps/design/shell/tiles-and-notifications/send-local-toast-desktop-cpp-wrl Shell_NotifyIcon API is clearly unsupported after 25/30 years on a modern OS. If you are a Java programmer, you can't send an OS notification. OS Notifications are very crucial to most apps this days, I can't imagine how Java can overlook it. Since you don't accept it as a bug (Oracle is closing all the bug reports from people on this), I opened a feature request on this in the hope that someone wise will look at it. Kind Regards, Davide Il 08/01/2024 22:05, Davide Perini ha scritto: > Thanks for the explanation?Aleksei > but can you explain me what is the OpenJDK direction please? > > Suppose that you have a feature like this one, a simple notifications. > Java worked well with Windows notifications until Win10, > then Microsoft changed the APIs for notifications in Win11. > > Isn't OpenJDK supposed to adapt to the new Windows APIs? > > Does OpenJDK supports Windows 11 or not? > > It's a little "weird" to close an issue by saying that Java uses the > same way to do the same thing since Windows 95 > and that it's a Microsoft problem if they changed the way to send > notifications to the OS. > > Java should support Microsoft Windows, it isn't Microsoft Windows that > should support Java, > isn't it? > > Other languages adapted their APIs for the new notifications system, > like everyone should expect from a modern language, > after 2 years from the release of Win 11, > Oracle says that it worked since Windows 95, so it is ok to have a > broken API in JDK because it worked before, they are the ones who > broke it (Microsoft). > > Does Java offers a correct way to send Notifications in Win10? Answer: Yes > Does Java offers a correct way to send Notifications in Win11? Answer: No > Does other languages offers a correct way to send Notifications in > Win11? Answer: Yes > Does current JDK APIs works as expected in Win11? > Answer: No because JDK uses an old API born with Win95 (30 years ago + > or -) with a new OS born in 2021, this results in an unexcpected > behaviour that doesn't work as supposed initially by the API. > > In the bug report you wrote: > "I can't see what Java can do to change the behaviour." > > The answer is: > "By implementing the correct API for the correct OS". > > > Java is currently not able to correctly send a Notification in Windows 11. > > > I see a bug there, if you don't see it, > I'm pretty worried of the new JDK direction. > > Thanks > Davide > > > Il 08/01/2024 20:55, Aleksei Ivanov ha scritto: >> On 2024-01-08 19:30, Davide Perini wrote: >>> Thanks for the Answer Aleksei, >>> I have a lot of Windows apps that uses notifications without problems. >>> >>> even a simple python program like this works correctly. >>> from win11toastimport toast >>> >>> toast('Hello','Click to run python script') >> >> Python could use newer WinRT APIs [6], in particular >> ToastNotification class [7] which provide richer interface for the >> toast notifications. The package name ?toast? hints it uses the newer >> APIs. >> >>> is it possible that Microsoft changed the way how to create >>> Notifications in Windows 11 and Java still uses the way it worked in >>> Windows 7? >> >> Perhaps, Microsoft changed how they handle notifications in Windows >> 11. In Windows 10, the notifications created with a Java app remain >> in Action / Notification centre. >> >> Java uses Shell_NotifyIcon [8] function that has been available since >> Windows 95. >> >> -- >> Regards, >> Alexey >> >> [6] https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/ >> [7] >> https://learn.microsoft.com/en-us/uwp/api/windows.ui.notifications.toastnotification?view=winrt-22621 >> [8] >> https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shell_notifyiconw >> >>> >>> Thanks >>> Davide >>> >>> >>> >>> Il 08/01/2024 17:59, Aleksei Ivanov ha scritto: >>>> Hi Davide, >>>> >>>> The bug that you reported has been moved to JDK project in JBS, you >>>> can view it as JDK-8315647 [1]. You should've received a link to it. >>>> >>>>> Is there a way to workaround this JDK bug? >>>>> I opened a bug report months ago but no one answered. >>>> >>>> What kind of answer did you expect to receive? >>>> >>>> You already asked this question on this mailing list in August [2]. >>>> I replied to your question [3]. Nothing has changed since August. >>>> It is not a bug in Java because a native Win32 app behaves the same >>>> way. >>>> >>>> I compiled and tested the sample [4], it behaves in Windows 11 as >>>> Java does: the displayed balloon notification does not go to >>>> notification centre. However, if I open notification centre while >>>> the balloon is displayed, it remains there. If I disable "Show >>>> notification banners" and leave "Show notifications in notification >>>> centre" enabled, the balloon goes directly to notification centre >>>> without displaying a banner. >>>> >>>> You can compile and test the sample too: >>>> >>>> git clone --filter=blob:none --sparse >>>> https://github.com/microsoft/Windows-classic-samples.git >>>> windows-samples >>>> cd windows-samples >>>> git sparse-checkout add >>>> Samples/Win7Samples/winui/shell/appshellintegration/NotificationIcon >>>> >>>> Navigate to the NotificationIcon folder and open >>>> NotificationIcon.sln in Visual Studio to compile and run it. >>>> >>>> If required, I can attach the compiled version of the application. >>>> >>>> >>>> I have closed JDK-8315647 as duplicate of JDK-8310352 [5]. >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From linkuntju at gmail.com Fri Jan 12 12:56:19 2024 From: linkuntju at gmail.com (=?UTF-8?B?5p6Xa3Vybg==?=) Date: Fri, 12 Jan 2024 20:56:19 +0800 Subject: Windows and Linux: Physical font does not have fallback fonts. Message-ID: Hi everyone, I am doing GUI development based on Java on Ubuntu, and I find some problems in it. Would it be possible for me to discuss with you? 1. There is no fallback font on Windows and Linux when using physical fonts. The FileFont class does not implements FontSubstitution interface, so there are no substituting glyphs from another font at render time(in GlyphLayout::layout). For example, when "jTextField.setFont(new Font("Ubuntu Mono", Font.PLAIN, 20))" on Ubuntu, all the CJK characters will show as tofu in this jTextField. Almost every font does not contain all possible inputs, adding some fallbacks font may help those who don't just use one language. 2. The fonts that JDK does not found are mapped to the ?Dialog? font. As https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/Font.html#%3Cinit%3E(java.lang.String,int,int) shows, If the name parameter represents something other than a logical font, i.e. is interpreted as a physical font face or family, and this cannot be mapped by the implementation to a physical font or a compatible alternative, then the font system will map the Font instance to "Dialog". On Linux, get map fonts by fontconfig may be more flexible, more configurable. For the two questions above, I have a preliminary patch. I added a new fallback form ?FONTCONFIGURATION_FALLBACK? and implemented it for Linux system, it creates a composite font by obtaining map fonts info for the specified name and style through fontconfig. And I make the FileFont class implement the FontSubstitution interface, reuse the FONTCONFIGURATION_FALLBACK code. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Optimizes-how-information-is-retrieved-from-fontconf.patch Type: application/octet-stream Size: 10989 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Adds-a-new-fallback-form-FONTCONFIGURATION_FALLBACK.patch Type: application/octet-stream Size: 2837 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Enables-glyphs-fallback-for-FileFont.patch Type: application/octet-stream Size: 2260 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Implements-the-FONTCONFIGURATION_FALLBACK-on-Linux.patch Type: application/octet-stream Size: 8946 bytes Desc: not available URL: From aivanov at openjdk.org Fri Jan 12 14:53:24 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 12 Jan 2024 14:53:24 GMT Subject: RFR: 8301994: Remove unused code from awt_List.cpp In-Reply-To: References: Message-ID: <3P1gOTGj_OUkFwYHH9rCNkeYO8fxYWNcWXaGBKfec2w=.d12a4c41-a283-497f-9a56-7393c0b9645d@github.com> On Thu, 11 Jan 2024 18:43:00 GMT, Rajat Mahajan wrote: > Remove commented out/ unused code from awt_List.cpp, which has been commented out since 2007, when the code was moved to Mercurial. > The test ScrollPaneLimitation.java has been opened under [JDK-8306137](https://bugs.openjdk.org/browse/JDK-8306137), and it should be safe to remove this code now. src/java.desktop/windows/native/libawt/windows/awt_List.cpp line 173: > 171: { > 172: AwtComponent::Reshape(x, y, w, h); > 173: I would also remove the blank line in the end of the function, it's uncommon to end a function with a blank line. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17378#discussion_r1450551900 From rmahajan at openjdk.org Fri Jan 12 16:35:34 2024 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Fri, 12 Jan 2024 16:35:34 GMT Subject: RFR: 8301994: Remove unused code from awt_List.cpp [v2] In-Reply-To: References: Message-ID: > Remove commented out/ unused code from awt_List.cpp, which has been commented out since 2007, when the code was moved to Mercurial. > The test ScrollPaneLimitation.java has been opened under [JDK-8306137](https://bugs.openjdk.org/browse/JDK-8306137), and it should be safe to remove this code now. Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: Update awt_List.cpp removed extra blank line at the end of the function. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17378/files - new: https://git.openjdk.org/jdk/pull/17378/files/6d1045d0..fe1ec21c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17378&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17378&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17378.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17378/head:pull/17378 PR: https://git.openjdk.org/jdk/pull/17378 From aivanov at openjdk.org Fri Jan 12 17:04:20 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 12 Jan 2024 17:04:20 GMT Subject: RFR: 8301994: Remove unused code from awt_List.cpp [v2] In-Reply-To: References: Message-ID: On Fri, 12 Jan 2024 16:35:34 GMT, Rajat Mahajan wrote: >> Remove commented out/ unused code from awt_List.cpp, which has been commented out since 2007, when the code was moved to Mercurial. >> The test ScrollPaneLimitation.java has been opened under [JDK-8306137](https://bugs.openjdk.org/browse/JDK-8306137), and it should be safe to remove this code now. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > Update awt_List.cpp > > removed extra blank line at the end of the function. Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17378#pullrequestreview-1818685678 From rmahajan at openjdk.org Fri Jan 12 17:17:29 2024 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Fri, 12 Jan 2024 17:17:29 GMT Subject: Integrated: 8301994: Remove unused code from awt_List.cpp In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 18:43:00 GMT, Rajat Mahajan wrote: > Remove commented out/ unused code from awt_List.cpp, which has been commented out since 2007, when the code was moved to Mercurial. > The test ScrollPaneLimitation.java has been opened under [JDK-8306137](https://bugs.openjdk.org/browse/JDK-8306137), and it should be safe to remove this code now. This pull request has now been integrated. Changeset: 8b6293f6 Author: Rajat Mahajan Committer: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/8b6293f6bfb7b7628c6604e6c44401fc96d85cf4 Stats: 11 lines in 1 file changed: 0 ins; 11 del; 0 mod 8301994: Remove unused code from awt_List.cpp Reviewed-by: serb, prr, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/17378 From clanger at openjdk.org Fri Jan 12 17:52:52 2024 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 12 Jan 2024 17:52:52 GMT Subject: RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations Message-ID: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> This picks up fixing the issue of [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) again. A fix had been integrated with #17224 but @prrace had concerns and so it was backed out. I have now spent quite some thoughts into the problem and end up with the [initial commit](https://github.com/openjdk/jdk/pull/6306/commits/5d18a76cb967e9ede6394cbd6c28bb61facf785c) of #6306 as the most elegant and least intrusive solution. Why is this? The JNI warning we observe in the test is: `[WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 22.0.1-internal/Native Method) at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:95) at sun.awt.Win32GraphicsEnvironment.(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:63) ... at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)` This happens because obviously the test FreeTypeScalerJNICheck runs with `-Xcheck:jni` and in the scenario where we're observing the warning, a missing exception check for the JNI call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged` at awt_Win32GraphicsEnv.cpp#L129 https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L129 is airing up. Omitting the exception check would not be a problem if it could be guaranteed that after this call no other JNI->Java call was being made. But seemingly in this very particular configuration on some of our Windows servers, there must be JNI->Java calls that follow the call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged`, likely from the subsequent call to [initScreens](https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L149) in `sun.awt.Win32GraphicsEnvironment::initDisplay`. https://github.com/openjdk/jdk/blob/8b6293f6bfb7b7628c6604e6c44401fc96d85cf4/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L141 Maybe the usual control flow would call the wrapping native method `DWMIsComposition Enabled()` from somewhere else initially such that the initialization of `Win32GraphicsEnvironment` would not go through `initScreens` or similar. In any case, I think triggering the invocation of JNI's `ExceptionCheck` by passing a non NULL value as second argument to JNU_CallStaticMethodByName https://github.com/openjdk/jdk/blob/8b6293f6bfb7b7628c6604e6c44401fc96d85cf4/src/java.base/share/native/libjava/jni_util.c#L200 is the correct thing to do to get rid of the -Xcheck:jni warning. Note that we don't clear the exception by this. So, should there really be an unchecked exception thrown (unlikely for this call of a simple getter method, but who knows), it would still bubble up to the calling Java code. @prrace please have a second look. Also cc @schmelter-sap @MBaesken ------------- Commit messages: - JDK-8323664 Changes: https://git.openjdk.org/jdk/pull/17404/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17404&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323664 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17404.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17404/head:pull/17404 PR: https://git.openjdk.org/jdk/pull/17404 From honkar at openjdk.org Fri Jan 12 17:59:32 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 12 Jan 2024 17:59:32 GMT Subject: Integrated: JDK-8312518 : [macos13] setFullScreenWindow() shows black screen on macOS 13 & above In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 21:35:57 GMT, Harshitha Onkar wrote: > A black screen is seen on newer versions of macOS (13.3 & above) when a window is set to full-screen using `setFullScreenWindow()`. The root cause was narrowed down to the shield level of the full-screen window vs the shield level of the captured display. > > Following solutions were explored - > > 1. Setting `kCGMaximumWindowLevelKey` as the shield level for the full screen window. But setting the fullscreen window to maximum available window level might cause z-order issues when other popup/screen savers are involved. > > int shieldLevel = CGWindowLevelForKey(kCGMaximumWindowLevelKey); > window.preFullScreenLevel = [nsWindow level]; > [nsWindow setLevel: shieldLevel]; > > 2. Raise the window's level slightly (shieldLevel + 1) above the system shield window. > > int shieldLevel = CGShieldingWindowLevel(); > window.preFullScreenLevel = [nsWindow level]; > [nsWindow setLevel: (shieldLevel + 1)]; > > 3. Keeping the shielding level as-is and bringing the window to the foreground after display is captured. The 3rd approach **(also the one Apple recommends)** ensures that the full screen window has focus as well as being visible and also maintains the correct z-order. This solution works as expected on older (< 13.3) and newer versions (13.3 & above) of macOS. > > if (CGDisplayCapture(aID) == kCGErrorSuccess) { > ... > ... > int shieldLevel = CGShieldingWindowLevel(); > window.preFullScreenLevel = [nsWindow level]; > [nsWindow setLevel: shieldLevel]; > [nsWindow makeKeyAndOrderFront: nil]; > } This pull request has now been integrated. Changeset: 999e556b Author: Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/999e556be4302de4b6911e6d62ee5ca556a76469 Stats: 91 lines in 2 files changed: 90 ins; 0 del; 1 mod 8312518: [macos13] setFullScreenWindow() shows black screen on macOS 13 & above Reviewed-by: serb, tr, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/17358 From vdyakov at openjdk.org Fri Jan 12 18:17:21 2024 From: vdyakov at openjdk.org (Victor Dyakov) Date: Fri, 12 Jan 2024 18:17:21 GMT Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination [v7] In-Reply-To: References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> <4_Xhk9SMIvvOthojgfccDt2kRA6DXR5xA7TDG4ujKCU=.465bafb2-7a81-4b72-8413-8216d11d6b07@github.com> Message-ID: On Mon, 4 Dec 2023 05:35:08 GMT, songpv-imt wrote: >>>The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. >> >> Why this issue can be reproduced in macOS 14? What was changed in that version? > >> Why this issue can be reproduced in macOS 14? What was changed in that version? > > I am uncertain about the exact code modifications in MacOS 14 that make this issue reproducible. Nevertheless, considering the underlying code logic, this issue could occur on any version of MacOS, contingent on timing factors, if the fix is not applied. @songpv-imt any plans to resume your work on this fix? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16396#issuecomment-1889748897 From vdyakov at openjdk.org Fri Jan 12 18:27:19 2024 From: vdyakov at openjdk.org (Victor Dyakov) Date: Fri, 12 Jan 2024 18:27:19 GMT Subject: RFR: 8317771 [macos14] Expand/collapse a JTree using keyboard freezes the application in macOS 14 Sonoma In-Reply-To: <7kSAuBxx0uNV2pNBUDuOi-K03gJQDqRZ54DweVziqbg=.796551db-f918-4cb9-99d8-2ac89596854d@github.com> References: <7kSAuBxx0uNV2pNBUDuOi-K03gJQDqRZ54DweVziqbg=.796551db-f918-4cb9-99d8-2ac89596854d@github.com> Message-ID: On Wed, 20 Dec 2023 09:28:47 GMT, Artem Semenov wrote: > NSAccessibility Outline is an accessibility representation of trees. > This representation requires that the visible children be represented as a flat array. > The child linearization algorithm available in ```CAccessibility.getChildrenAndRolesRecursive()``` is universal, i.e. suitable for any object with the role of a tree, but is not efficient, since it traverses the entire tree and selects suitable children. > For JTree, this algorithm can be optimized by using TreePath, but the old algorithm will have to be retained to maintain versatility. @azuev-java @savoptik will be good to intense a code review / making revisions a little bit since it is a serious P3 issue on macOS 14.X ------------- PR Comment: https://git.openjdk.org/jdk/pull/17165#issuecomment-1889762208 From aivanov at openjdk.org Fri Jan 12 18:38:17 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 12 Jan 2024 18:38:17 GMT Subject: RFR: JDK-8323617 : Add missing null checks to GetMousePositionWithPopup.java test In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 20:04:56 GMT, Harshitha Onkar wrote: > While investigating a macOS 14 issue noticed missing null checks in java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java > > The missing null check will cause an NPE in finally block when frame2 is not created in the event that mouse move is not received. > > PS: This test passes on the latest version of macOS (14.2) Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17380#pullrequestreview-1818828684 From philip.race at oracle.com Fri Jan 12 19:10:51 2024 From: philip.race at oracle.com (Philip Race) Date: Fri, 12 Jan 2024 11:10:51 -0800 Subject: Windows and Linux: Physical font does not have fallback fonts. In-Reply-To: References: Message-ID: Right. This is on purpose.? We do not want to change that behaviour. A font should not lie about what glyphs it contains and provide no way for apps to know if that is REALLY from this font. Proper text rendering is not possible if you lie to the app. JDK on MacOS does things differently because that's the implementation we unfortunately inherited from Apple. It is a real pain. Swing implements an implicit fall back for most uses by controls where it is safer to assume they just want to display some glyph, but a change to do that globally for Java 2D is not going to be accepted, and even the Swing one causes some problems as there's no way to tell it has a fall back. The fall back to "Dialog" if a font is not found cannot be changed. It is specified. https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/Font.html#%3Cinit%3E(java.lang.String,int,int) "If the|name|parameter represents something other than a logical font, i.e. is interpreted as a physical font face or family, and this cannot be mapped by the implementation to a physical font or a compatible alternative, then the font system will map the Font instance to "Dialog", such that for example, the family as reported by|getFamily| will be "Dialog". -phil. On 1/12/24 4:56 AM, ?kurn wrote: > Hi everyone, > > I am doing GUI development based on Java on Ubuntu, and I find some > problems in it. > Would it be possible for me to discuss with you? > > 1. There is no fallback font on Windows and Linux when using physical > fonts. > The FileFont class does not implements FontSubstitution interface, so > there are no substituting glyphs from another font at render time(in > GlyphLayout::layout). > For example, when "jTextField.setFont(new Font("Ubuntu Mono", > Font.PLAIN, 20))" on Ubuntu, all the CJK characters will show as tofu > in this jTextField. Almost every font does not contain all possible > inputs, adding some fallbacks font may help those who don't just use > one language. > > 2. The fonts that JDK does not found are mapped to the ?Dialog? font. > As > https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/Font.html#%3Cinit%3E(java.lang.String,int,int) > shows,?If the name parameter represents something other than a logical > font, i.e. is interpreted as a physical font face or family, and this > cannot be mapped by the implementation to a physical font or a > compatible alternative, then the font system will map the Font > instance to "Dialog". > On Linux, get map fonts by fontconfig may be more flexible, more > configurable. > > For the two questions above, I have a preliminary patch. > > I added a new fallback form ?FONTCONFIGURATION_FALLBACK? > and?implemented it for Linux system, it creates a composite font by > obtaining map fonts info for the specified name and style through > fontconfig. > And I make the FileFont class implement the FontSubstitution > interface, reuse the FONTCONFIGURATION_FALLBACK code. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dnguyen at openjdk.org Fri Jan 12 19:14:19 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 12 Jan 2024 19:14:19 GMT Subject: RFR: 8321489: Update LCMS to 2.16 In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 22:22:53 GMT, Alisen Chung wrote: > Update LCMS, mach5 client tests are green Changes LGTM ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/17382#pullrequestreview-1818877551 From dnguyen at openjdk.org Fri Jan 12 19:15:21 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 12 Jan 2024 19:15:21 GMT Subject: RFR: JDK-8323617 : Add missing null checks to GetMousePositionWithPopup.java test In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 20:04:56 GMT, Harshitha Onkar wrote: > While investigating a macOS 14 issue noticed missing null checks in java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java > > The missing null check will cause an NPE in finally block when frame2 is not created in the event that mouse move is not received. > > PS: This test passes on the latest version of macOS (14.2) Logical addition. Tested and still works as expected ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/17380#pullrequestreview-1818879022 From rmahajan at openjdk.org Fri Jan 12 19:23:28 2024 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Fri, 12 Jan 2024 19:23:28 GMT Subject: RFR: 8320328: Restore interrupted flag in ImageIcon.loadImage Message-ID: <_xn5gOvor_Sgp_AkFYsPbM_xGbf7_GhGgx5qpCBr6d8=.0253d8d3-42ae-49f7-b878-ba8987a403d6@github.com> ImageIcon.loadImage used to handle InterruptedException only by printing a message to the console. JDK-8236987 handled the interrupted state more gracefully, but it didn't restore the interrupted flag. This change restores the interrupted flag that will allow the following code to handle interruption and exit the thread; otherwise, the thread will continue to run. ------------- Commit messages: - Restore the interrupted flag. Changes: https://git.openjdk.org/jdk/pull/17406/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17406&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320328 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17406.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17406/head:pull/17406 PR: https://git.openjdk.org/jdk/pull/17406 From honkar at openjdk.org Fri Jan 12 19:24:28 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 12 Jan 2024 19:24:28 GMT Subject: Integrated: JDK-8323617 : Add missing null checks to GetMousePositionWithPopup.java test In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 20:04:56 GMT, Harshitha Onkar wrote: > While investigating a macOS 14 issue noticed missing null checks in java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java > > The missing null check will cause an NPE in finally block when frame2 is not created in the event that mouse move is not received. > > PS: This test passes on the latest version of macOS (14.2) This pull request has now been integrated. Changeset: c54bca6f Author: Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/c54bca6f7f5a7e4f47e804608e7ea370dcc32897 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod 8323617: Add missing null checks to GetMousePositionWithPopup.java test Reviewed-by: serb, aivanov, dnguyen ------------- PR: https://git.openjdk.org/jdk/pull/17380 From serb at openjdk.org Fri Jan 12 19:42:35 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 12 Jan 2024 19:42:35 GMT Subject: RFR: 4760025: sRGB conversions to and from CIE XYZ incorrect Message-ID: <0pH-ce3ZKwh7NqRAndPp-pFCRBRTHl3VgDytBBMPeAA=.f2d03283-bdd8-469d-89d9-279af8fbfb21@github.com> Since the time the bug was reported color conversion accuracy for the sRGB profile and specific values from the report increased by x100. This is a request to add the code from the report as a test case. ------------- Commit messages: - 4760025: sRGB conversions to and from CIE XYZ incorrect Changes: https://git.openjdk.org/jdk/pull/17388/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17388&range=00 Issue: https://bugs.openjdk.org/browse/JDK-4760025 Stats: 57 lines in 1 file changed: 57 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17388/head:pull/17388 PR: https://git.openjdk.org/jdk/pull/17388 From aivanov at openjdk.org Fri Jan 12 19:47:18 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 12 Jan 2024 19:47:18 GMT Subject: RFR: 8320328: Restore interrupted flag in ImageIcon.loadImage In-Reply-To: <_xn5gOvor_Sgp_AkFYsPbM_xGbf7_GhGgx5qpCBr6d8=.0253d8d3-42ae-49f7-b878-ba8987a403d6@github.com> References: <_xn5gOvor_Sgp_AkFYsPbM_xGbf7_GhGgx5qpCBr6d8=.0253d8d3-42ae-49f7-b878-ba8987a403d6@github.com> Message-ID: On Fri, 12 Jan 2024 19:17:24 GMT, Rajat Mahajan wrote: > ImageIcon.loadImage used to handle InterruptedException only by printing a message to the console. JDK-8236987 handled the interrupted state more gracefully, but it didn't restore the interrupted flag. > This change restores the interrupted flag that will allow the following code to handle interruption and exit the thread; otherwise, the thread will continue to run. Looks good to me. Could you update the [`LoadInterruptTest.java`](https://github.com/openjdk/jdk/blob/f26403172f2e19e2ed4efd0f06f00beaebde1031/test/jdk/javax/swing/ImageIcon/LoadInterruptTest.java) test to verify that the thread remains interrupted? ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17406#pullrequestreview-1818937822 From honkar at openjdk.org Fri Jan 12 20:21:52 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 12 Jan 2024 20:21:52 GMT Subject: RFR: JDK-8320113: [macos14] : ShapeNotSetSometimes.java fails intermittently on macOS 14 [v2] In-Reply-To: References: Message-ID: <-XwORy2eQahQ3dyJWrE20h41kdSMFNbyHQ9FGZ0z2aA=.4596d9dd-b4da-4ff1-bae5-508fa4bae37b@github.com> > ShapeNotSetSometimes.java fails intermittently on macOS 14. Following is a test stabilization fix for macOS 14. With the added delays ShapeNotSetSometimes.java passes on older versions of macOS as well as on macOS 14.1, 14.2. Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: test stabilization fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17180/files - new: https://git.openjdk.org/jdk/pull/17180/files/2f25e61e..9831cffd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17180&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17180&range=00-01 Stats: 42 lines in 1 file changed: 25 ins; 12 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/17180.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17180/head:pull/17180 PR: https://git.openjdk.org/jdk/pull/17180 From honkar at openjdk.org Fri Jan 12 20:21:52 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 12 Jan 2024 20:21:52 GMT Subject: RFR: JDK-8320113: [macos14] : ShapeNotSetSometimes.java fails intermittently on macOS 14 In-Reply-To: References: Message-ID: On Thu, 21 Dec 2023 20:33:53 GMT, Harshitha Onkar wrote: > ShapeNotSetSometimes.java fails intermittently on macOS 14. Following is a test stabilization fix for macOS 14. With the added delays ShapeNotSetSometimes.java passes on older versions of macOS as well as on macOS 14.1, 14.2. > This test is fails intermittently on linux with the current fix. Running the test on all platforms with slightly different delay values. In this test `colorCheck()` is repeated for 50 iterations. In the rare event, color check fails at random attempt no. (and happens to pass on previous iterations (as shown below). To stabilize the test on various platforms and machines, the constraint that **colorcheck() needs to pass for all the 50 iterations** is relaxed by allowing the test to continue until 3 failed attempts. The test throws RuntimeException after 3 failed attempts. CI Testing with the stabilization fix looks good on all platforms including macOS 14. Attempt 8 Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] Checking 150, 20, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] Checking 280, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] Checking 150, 250, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] Checking 20, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] Checking 62, 62, java.awt.Color[r=0,g=244,b=0] should not be java.awt.Color[r=255,g=255,b=255] Checking 240, 185, java.awt.Color[r=0,g=232,b=0] should not be java.awt.Color[r=255,g=255,b=255] Attempt 9 Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] Checking 150, 20, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] Checking 280, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] Checking 150, 250, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] Checking 20, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] Checking 62, 62, java.awt.Color[r=0,g=240,b=0] should not be java.awt.Color[r=255,g=255,b=255] Checking 240, 185, java.awt.Color[r=0,g=228,b=0] should not be java.awt.Color[r=255,g=255,b=255] Attempt 10 Checking 150, 130, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=255,g=255,b=255] window.getX() = 220, window.getY() = 400 Checking for transparency failed: point: 370, 530 actual java.awt.Color[r=0,g=255,b=0] expected java.awt.Color[r=255,g=255,b=255] java.lang.RuntimeException: Test failed. The shape has not been applied. at ShapeNotSetSometimes.colorCheck(ShapeNotSetSometimes.java:185) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17180#issuecomment-1889898329 From honkar at openjdk.org Fri Jan 12 20:27:20 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 12 Jan 2024 20:27:20 GMT Subject: RFR: JDK-8320113: [macos14] : ShapeNotSetSometimes.java fails intermittently on macOS 14 [v2] In-Reply-To: References: Message-ID: On Fri, 22 Dec 2023 19:28:16 GMT, Alexander Zuev wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> test stabilization fix > > Looks good @azuev-java @azvegint @DamonGuy Please re-review the updated test stabilization fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17180#issuecomment-1889905124 From rmahajan at openjdk.org Fri Jan 12 20:36:41 2024 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Fri, 12 Jan 2024 20:36:41 GMT Subject: RFR: 8320328: Restore interrupted flag in ImageIcon.loadImage [v2] In-Reply-To: <_xn5gOvor_Sgp_AkFYsPbM_xGbf7_GhGgx5qpCBr6d8=.0253d8d3-42ae-49f7-b878-ba8987a403d6@github.com> References: <_xn5gOvor_Sgp_AkFYsPbM_xGbf7_GhGgx5qpCBr6d8=.0253d8d3-42ae-49f7-b878-ba8987a403d6@github.com> Message-ID: <4yVEJeP08pEln6gR7vxzVxM3tJbcZNpykBQWzkvuMAo=.404ffbe5-c43c-49df-870f-68324f2d742d@github.com> > ImageIcon.loadImage used to handle InterruptedException only by printing a message to the console. JDK-8236987 handled the interrupted state more gracefully, but it didn't restore the interrupted flag. > This change restores the interrupted flag that will allow the following code to handle interruption and exit the thread; otherwise, the thread will continue to run. Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: Update copyright year. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17406/files - new: https://git.openjdk.org/jdk/pull/17406/files/5b264f24..0a8d9702 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17406&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17406&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17406.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17406/head:pull/17406 PR: https://git.openjdk.org/jdk/pull/17406 From prr at openjdk.org Fri Jan 12 20:48:19 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 12 Jan 2024 20:48:19 GMT Subject: RFR: 4760025: sRGB conversions to and from CIE XYZ incorrect In-Reply-To: <0pH-ce3ZKwh7NqRAndPp-pFCRBRTHl3VgDytBBMPeAA=.f2d03283-bdd8-469d-89d9-279af8fbfb21@github.com> References: <0pH-ce3ZKwh7NqRAndPp-pFCRBRTHl3VgDytBBMPeAA=.f2d03283-bdd8-469d-89d9-279af8fbfb21@github.com> Message-ID: On Fri, 12 Jan 2024 07:37:13 GMT, Sergey Bylokhov wrote: > Since the time the bug was reported color conversion accuracy for the sRGB profile and specific values from the report increased by x100. This is a request to add the code from the report as a test case. test/jdk/java/awt/color/ICC_ColorSpace/SimpleSRGBToFromCIEXYZ.java line 2: > 1: /* > 2: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. The test is fine but since as you note, it is based on a test from JBS, written by an (at the time) Sun employee, I'd expect to see (c) Oracle here .. or at least joint (c). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17388#discussion_r1450908721 From serb at openjdk.org Fri Jan 12 20:51:38 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 12 Jan 2024 20:51:38 GMT Subject: RFR: 4760025: sRGB conversions to and from CIE XYZ incorrect [v2] In-Reply-To: <0pH-ce3ZKwh7NqRAndPp-pFCRBRTHl3VgDytBBMPeAA=.f2d03283-bdd8-469d-89d9-279af8fbfb21@github.com> References: <0pH-ce3ZKwh7NqRAndPp-pFCRBRTHl3VgDytBBMPeAA=.f2d03283-bdd8-469d-89d9-279af8fbfb21@github.com> Message-ID: > Since the time the bug was reported color conversion accuracy for the sRGB profile and specific values from the report increased by x100. This is a request to add the code from the report as a test case. Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: Update SimpleSRGBToFromCIEXYZ.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17388/files - new: https://git.openjdk.org/jdk/pull/17388/files/e099466a..8925fbd5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17388&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17388&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17388/head:pull/17388 PR: https://git.openjdk.org/jdk/pull/17388 From serb at openjdk.org Fri Jan 12 20:51:40 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 12 Jan 2024 20:51:40 GMT Subject: RFR: 4760025: sRGB conversions to and from CIE XYZ incorrect [v2] In-Reply-To: References: <0pH-ce3ZKwh7NqRAndPp-pFCRBRTHl3VgDytBBMPeAA=.f2d03283-bdd8-469d-89d9-279af8fbfb21@github.com> Message-ID: On Fri, 12 Jan 2024 20:45:13 GMT, Phil Race wrote: >> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: >> >> Update SimpleSRGBToFromCIEXYZ.java > > test/jdk/java/awt/color/ICC_ColorSpace/SimpleSRGBToFromCIEXYZ.java line 2: > >> 1: /* >> 2: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > The test is fine but since as you note, it is based on a test from JBS, written by an (at the time) Sun employee, I'd expect to see (c) Oracle here .. or at least joint (c). Sure. the test is updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17388#discussion_r1450911387 From serb at openjdk.org Fri Jan 12 20:56:24 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 12 Jan 2024 20:56:24 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v14] In-Reply-To: References: Message-ID: On Fri, 12 Jan 2024 09:53:46 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. >> >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Included wrapper check Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16895#pullrequestreview-1819028509 From prr at openjdk.org Fri Jan 12 21:00:20 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 12 Jan 2024 21:00:20 GMT Subject: RFR: 4760025: sRGB conversions to and from CIE XYZ incorrect [v2] In-Reply-To: References: <0pH-ce3ZKwh7NqRAndPp-pFCRBRTHl3VgDytBBMPeAA=.f2d03283-bdd8-469d-89d9-279af8fbfb21@github.com> Message-ID: On Fri, 12 Jan 2024 20:51:38 GMT, Sergey Bylokhov wrote: >> Since the time the bug was reported color conversion accuracy for the sRGB profile and specific values from the report increased by x100. This is a request to add the code from the report as a test case. > > Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: > > Update SimpleSRGBToFromCIEXYZ.java Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17388#pullrequestreview-1819033074 From kizune at openjdk.org Fri Jan 12 21:07:19 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Fri, 12 Jan 2024 21:07:19 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v2] In-Reply-To: <7dpKxrn8QG4b5Xkzv921rdgttZuZw-DwBBniheoTn8A=.f0daf114-7631-4214-8af9-57cb3ccd33f4@github.com> References: <7dpKxrn8QG4b5Xkzv921rdgttZuZw-DwBBniheoTn8A=.f0daf114-7631-4214-8af9-57cb3ccd33f4@github.com> Message-ID: On Wed, 10 Jan 2024 21:08:35 GMT, Alisen Chung wrote: >> SunToolkit.java is trying to post an event on the TrayIcon appContext, but the TrayIcon was already removed by the test, causing an error. The fix is to make SunToolkit skip posting the event if appContext is null. The test is also updated to remove applet usage and use PassFailJFrame instead. > > Alisen Chung has updated the pull request incrementally with two additional commits since the last revision: > > - spacing > - updated test title, copyright year, removed redundant check Looks good. ------------- Marked as reviewed by kizune (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17329#pullrequestreview-1819041585 From aivanov at openjdk.org Fri Jan 12 21:08:25 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 12 Jan 2024 21:08:25 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v14] In-Reply-To: References: Message-ID: On Fri, 12 Jan 2024 09:53:46 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. >> >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Included wrapper check Changes requested by aivanov (Reviewer). test/jdk/java/awt/color/NonICCFilterTest.java line 140: > 138: > 139: ColorConvertOp gold = new ColorConvertOp(mid, null); > 140: gold.filter(srcGold, destGold); Shouldn't both filter use `gold` instead? Then later, you create `test` with a wrapper instead? test/jdk/java/awt/color/NonICCFilterTest.java line 151: > 149: > 150: gold = new ColorConvertOp(mid, null); > 151: gold.filter(srcGold, destGold); Should both filter use the same instance of `ColorConvertOp` where the first one is `gold` and is applied to both `gold-` and `test-` images, then the next instance `ColorConvertOp` is a `test` with the wrapper which is again applied to both images? Wouldn't it be clearer? Suggestion: ColorConvertOp gold = new ColorConvertOp(createCS(ColorSpaceSelector.PYCC), null); gold.filter(srcTest, destTest); gold.filter(srcGold, destGold); if (!areImagesEqual(destTest, destGold)) { throw new RuntimeException("ICC test failed"); } ColorConvertOp test = new ColorConvertOp(createCS(ColorSpaceSelector.WRAPPED_PYCC), null); test.filter(srcTest, destTest); test.filter(srcGold, destGold); Currently, we have `test` and `gold` which use the same `ColorSpace` which could be plain or wrapper for both cases. It looks confusing to me. What do you think, @mrserb? ------------- PR Review: https://git.openjdk.org/jdk/pull/16895#pullrequestreview-1819034007 PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1450918862 PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1450923724 From dnguyen at openjdk.org Fri Jan 12 21:16:20 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 12 Jan 2024 21:16:20 GMT Subject: RFR: 8259550: The content of the print out displayed incomplete with the NimbusLAF In-Reply-To: References: Message-ID: On Mon, 11 Dec 2023 11:25:34 GMT, Tejesh R wrote: > The issue is w.r.t to way that Synth prints the table. In Synth, the printing of Table happens column wise by painting blocks of columns which is due to the fact that Graphics used which is `ProxyGrpahics2D` (which get selected in `RasterPrinterJob `class, otherwise it would be `WPathGraphics` for other Look and feel). Since the printing happens in block wise and the columns where the x position is greater than the `table.bounds` doesn't gets painted because of the intersection check condition `!bounds.intersects(clip)`. Hence only droplines are painted instead of cells and gridlines. I couldn't find any reason for adding the intersection check here and when removed it didn't cause any regression too, rather it solves the issue and actually made sense too. In other Look and Feel its not required to apply the fix (in `BasicTableUI `class) because its not affecting anything yet since the painting happens for whole table. Hence proposing the fix for only SynthTableUI class. > ([PrintManualTest_FitWidthMultiple.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java)) test is been used for testing. I see no difference in Nimbus LAF PrintManualTest_FitWidthMultiple.java with this change. Is there anything else that needs changing other than in SynthTableUI.java? Or any missing configuration on my end? ------------- PR Review: https://git.openjdk.org/jdk/pull/17053#pullrequestreview-1819050923 From aivanov at openjdk.org Fri Jan 12 21:19:23 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 12 Jan 2024 21:19:23 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v14] In-Reply-To: References: Message-ID: On Fri, 12 Jan 2024 09:53:46 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. >> >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Included wrapper check The diffs are rather long above, this is how the `main` method should look like: https://github.com/aivanov-jdk/jdk/blob/e3f9b66089311949d5ff99a77511e309219247ba/test/jdk/java/awt/color/NonICCFilterTest.java#L128-L150 That is a `gold` color converter is created with the plain `ICC_ColorSpace` and it's applied to both images. Next, a `test` color converter is created with the wrapper and again it's applied to both images. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16895#issuecomment-1889960387 From prr at openjdk.org Fri Jan 12 21:30:18 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 12 Jan 2024 21:30:18 GMT Subject: RFR: 8321489: Update LCMS to 2.16 In-Reply-To: References: Message-ID: <6ra07BlzZa2NKyn_s36Gs0i4zeGJoQdWMpYcilPHI4U=.22b5364c-7f72-4078-a53c-c2f8554d2b04@github.com> On Thu, 11 Jan 2024 22:22:53 GMT, Alisen Chung wrote: > Update LCMS, mach5 client tests are green Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17382#pullrequestreview-1819067670 From aivanov at openjdk.org Fri Jan 12 21:36:24 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 12 Jan 2024 21:36:24 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v2] In-Reply-To: <7dpKxrn8QG4b5Xkzv921rdgttZuZw-DwBBniheoTn8A=.f0daf114-7631-4214-8af9-57cb3ccd33f4@github.com> References: <7dpKxrn8QG4b5Xkzv921rdgttZuZw-DwBBniheoTn8A=.f0daf114-7631-4214-8af9-57cb3ccd33f4@github.com> Message-ID: On Wed, 10 Jan 2024 21:08:35 GMT, Alisen Chung wrote: >> SunToolkit.java is trying to post an event on the TrayIcon appContext, but the TrayIcon was already removed by the test, causing an error. The fix is to make SunToolkit skip posting the event if appContext is null. The test is also updated to remove applet usage and use PassFailJFrame instead. > > Alisen Chung has updated the pull request incrementally with two additional commits since the last revision: > > - spacing > - updated test title, copyright year, removed redundant check Please update the copyright year in `SunToolkit.java` too. I haven't looked through all the code in the test. Note: I've edited the JBS subject to correct ?and? to ?an? and to remove double space. test/jdk/java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.java line 2: > 1: /* > 2: * Copyright (c) 2013, 2024 Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2013, 2024, Oracle and/or its affiliates. All rights reserved. There must be another comma after the second copyright year. test/jdk/java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.java line 58: > 56: System.out.println("The test cannot be run because SystemTray is not supported."); > 57: return; > 58: } I'd rather move this entire check into the `main` method and throw `jtreg.SkippedException` instead. ------------- PR Review: https://git.openjdk.org/jdk/pull/17329#pullrequestreview-1819063454 PR Review Comment: https://git.openjdk.org/jdk/pull/17329#discussion_r1450937261 PR Review Comment: https://git.openjdk.org/jdk/pull/17329#discussion_r1450939638 From aivanov at openjdk.org Fri Jan 12 21:41:24 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 12 Jan 2024 21:41:24 GMT Subject: RFR: 4760025: sRGB conversions to and from CIE XYZ incorrect [v2] In-Reply-To: References: <0pH-ce3ZKwh7NqRAndPp-pFCRBRTHl3VgDytBBMPeAA=.f2d03283-bdd8-469d-89d9-279af8fbfb21@github.com> Message-ID: On Fri, 12 Jan 2024 20:51:38 GMT, Sergey Bylokhov wrote: >> Since the time the bug was reported color conversion accuracy for the sRGB profile and specific values from the report increased by x100. This is a request to add the code from the report as a test case. > > Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: > > Update SimpleSRGBToFromCIEXYZ.java Marked as reviewed by aivanov (Reviewer). test/jdk/java/awt/color/ICC_ColorSpace/SimpleSRGBToFromCIEXYZ.java line 42: > 40: > 41: if (inv[0] != 0 || Math.abs(inv[1] - g) > 0.0001f || inv[2] != 0) { > 42: System.err.println("Expected color:\t" + toString(rgb)); `Arrays.toString(rgb)` instead of custom `toString`? ------------- PR Review: https://git.openjdk.org/jdk/pull/17388#pullrequestreview-1819090964 PR Review Comment: https://git.openjdk.org/jdk/pull/17388#discussion_r1450946738 From kizune at openjdk.org Fri Jan 12 21:41:21 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Fri, 12 Jan 2024 21:41:21 GMT Subject: RFR: 8317771 [macos14] Expand/collapse a JTree using keyboard freezes the application in macOS 14 Sonoma In-Reply-To: <7kSAuBxx0uNV2pNBUDuOi-K03gJQDqRZ54DweVziqbg=.796551db-f918-4cb9-99d8-2ac89596854d@github.com> References: <7kSAuBxx0uNV2pNBUDuOi-K03gJQDqRZ54DweVziqbg=.796551db-f918-4cb9-99d8-2ac89596854d@github.com> Message-ID: On Wed, 20 Dec 2023 09:28:47 GMT, Artem Semenov wrote: > NSAccessibility Outline is an accessibility representation of trees. > This representation requires that the visible children be represented as a flat array. > The child linearization algorithm available in ```CAccessibility.getChildrenAndRolesRecursive()``` is universal, i.e. suitable for any object with the role of a tree, but is not efficient, since it traverses the entire tree and selects suitable children. > For JTree, this algorithm can be optimized by using TreePath, but the old algorithm will have to be retained to maintain versatility. Approving on a condition that a followup bug requesting a proper fix will be filed before the integration. ------------- Marked as reviewed by kizune (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17165#pullrequestreview-1819093656 From kizune at openjdk.org Fri Jan 12 21:41:23 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Fri, 12 Jan 2024 21:41:23 GMT Subject: RFR: 8317771 [macos14] Expand/collapse a JTree using keyboard freezes the application in macOS 14 Sonoma In-Reply-To: <_TnQXl6SK395WUSKc9tolVFx6L9BODof-CNefNaELWM=.30f29b5e-fd2d-465c-b1da-57e18fc12043@github.com> References: <7kSAuBxx0uNV2pNBUDuOi-K03gJQDqRZ54DweVziqbg=.796551db-f918-4cb9-99d8-2ac89596854d@github.com> <_TnQXl6SK395WUSKc9tolVFx6L9BODof-CNefNaELWM=.30f29b5e-fd2d-465c-b1da-57e18fc12043@github.com> Message-ID: On Mon, 25 Dec 2023 12:27:59 GMT, Artem Semenov wrote: >> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 799: >> >>> 797: for (int i = 0; i < count; i++) { >>> 798: TreePath path = tree.getPathForRow(i); >>> 799: Accessible an = createAccessibleTreeNode(tree, path); >> >> I see that you are creating the accessible tree node with reflection calling its constructor. Can you just elaborate if it is the only way to get hold of it and why getting a tree.getAccessible().getAccessibleChild(i) does not work or what kind of problem getting the tree node this way creates? > > A little lower, the access algorithm is implemented in the way you showed. > But to speed things up, I want to avoid recursion through the native and for this it is easier to initialize those nodes that are present in the tree path through the constructor. Why do I propose to use reflection? Otherwise, you will either have to make the constructor of a double-nested class public, or create a chain of methods that allow you to instantiate this class through a new call in CAccessibility. I can't say i like the approach but i can accept it as a hotfix to eliminate the situation but only if we create a followup bug to fix it properly - even if it will require a new public accessor to be added to the JTree class that will instantiate the tree node accessibility peer for a given TreePath without the need to use a reflection. Using reflection like this really breaks the encapsulation and logic separation principles introducing the unneeded dependency on the implementation details in the unrelated class. So as a bottom line - i will approve that as a hotfix but the followup bug to properly eliminate the implementation dependency and getting rid of the reflection call to be filled and addressed in the next release. If that will require a CSR - let there be CSR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17165#discussion_r1450947083 From rmahajan at openjdk.org Fri Jan 12 21:43:36 2024 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Fri, 12 Jan 2024 21:43:36 GMT Subject: RFR: 8320328: Restore interrupted flag in ImageIcon.loadImage [v3] In-Reply-To: <_xn5gOvor_Sgp_AkFYsPbM_xGbf7_GhGgx5qpCBr6d8=.0253d8d3-42ae-49f7-b878-ba8987a403d6@github.com> References: <_xn5gOvor_Sgp_AkFYsPbM_xGbf7_GhGgx5qpCBr6d8=.0253d8d3-42ae-49f7-b878-ba8987a403d6@github.com> Message-ID: > ImageIcon.loadImage used to handle InterruptedException only by printing a message to the console. JDK-8236987 handled the interrupted state more gracefully, but it didn't restore the interrupted flag. > This change restores the interrupted flag that will allow the following code to handle interruption and exit the thread; otherwise, the thread will continue to run. Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: add test case for this change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17406/files - new: https://git.openjdk.org/jdk/pull/17406/files/0a8d9702..93a874c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17406&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17406&range=01-02 Stats: 9 lines in 1 file changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17406.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17406/head:pull/17406 PR: https://git.openjdk.org/jdk/pull/17406 From rmahajan at openjdk.org Fri Jan 12 21:53:44 2024 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Fri, 12 Jan 2024 21:53:44 GMT Subject: RFR: 8320328: Restore interrupted flag in ImageIcon.loadImage [v4] In-Reply-To: <_xn5gOvor_Sgp_AkFYsPbM_xGbf7_GhGgx5qpCBr6d8=.0253d8d3-42ae-49f7-b878-ba8987a403d6@github.com> References: <_xn5gOvor_Sgp_AkFYsPbM_xGbf7_GhGgx5qpCBr6d8=.0253d8d3-42ae-49f7-b878-ba8987a403d6@github.com> Message-ID: <8930jQBNzUPpOPOgzXwJz1os6i3cT1d1ycI9864nePw=.8711e8f1-6e5e-44ac-838b-d92af44240ae@github.com> > ImageIcon.loadImage used to handle InterruptedException only by printing a message to the console. JDK-8236987 handled the interrupted state more gracefully, but it didn't restore the interrupted flag. > This change restores the interrupted flag that will allow the following code to handle interruption and exit the thread; otherwise, the thread will continue to run. Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: Update LoadInterruptTest.java removed extra blank lines. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17406/files - new: https://git.openjdk.org/jdk/pull/17406/files/93a874c0..e5833ac0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17406&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17406&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17406.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17406/head:pull/17406 PR: https://git.openjdk.org/jdk/pull/17406 From aivanov at openjdk.org Fri Jan 12 21:53:44 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 12 Jan 2024 21:53:44 GMT Subject: RFR: 8320328: Restore interrupted flag in ImageIcon.loadImage [v4] In-Reply-To: <8930jQBNzUPpOPOgzXwJz1os6i3cT1d1ycI9864nePw=.8711e8f1-6e5e-44ac-838b-d92af44240ae@github.com> References: <_xn5gOvor_Sgp_AkFYsPbM_xGbf7_GhGgx5qpCBr6d8=.0253d8d3-42ae-49f7-b878-ba8987a403d6@github.com> <8930jQBNzUPpOPOgzXwJz1os6i3cT1d1ycI9864nePw=.8711e8f1-6e5e-44ac-838b-d92af44240ae@github.com> Message-ID: On Fri, 12 Jan 2024 21:51:07 GMT, Rajat Mahajan wrote: >> ImageIcon.loadImage used to handle InterruptedException only by printing a message to the console. JDK-8236987 handled the interrupted state more gracefully, but it didn't restore the interrupted flag. >> This change restores the interrupted flag that will allow the following code to handle interruption and exit the thread; otherwise, the thread will continue to run. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > Update LoadInterruptTest.java > > removed extra blank lines. Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17406#pullrequestreview-1819115492 From achung at openjdk.org Fri Jan 12 22:04:37 2024 From: achung at openjdk.org (Alisen Chung) Date: Fri, 12 Jan 2024 22:04:37 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws an exception on Mac OS 14(x64, aarch64) [v3] In-Reply-To: References: Message-ID: > SunToolkit.java is trying to post an event on the TrayIcon appContext, but the TrayIcon was already removed by the test, causing an error. The fix is to make SunToolkit skip posting the event if appContext is null. The test is also updated to remove applet usage and use PassFailJFrame instead. Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: removed extra newlines, moved test out of folder ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17329/files - new: https://git.openjdk.org/jdk/pull/17329/files/53629e25..05d18e68 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17329&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17329&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17329.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17329/head:pull/17329 PR: https://git.openjdk.org/jdk/pull/17329 From achung at openjdk.org Fri Jan 12 22:18:04 2024 From: achung at openjdk.org (Alisen Chung) Date: Fri, 12 Jan 2024 22:18:04 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v4] In-Reply-To: References: Message-ID: > SunToolkit.java is trying to post an event on the TrayIcon appContext, but the TrayIcon was already removed by the test, causing an error. The fix is to make SunToolkit skip posting the event if appContext is null. The test is also updated to remove applet usage and use PassFailJFrame instead. Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: used jtreg.SkippedException, updated copyright years ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17329/files - new: https://git.openjdk.org/jdk/pull/17329/files/05d18e68..1ec7943a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17329&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17329&range=02-03 Stats: 16 lines in 2 files changed: 5 ins; 7 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/17329.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17329/head:pull/17329 PR: https://git.openjdk.org/jdk/pull/17329 From achung at openjdk.org Fri Jan 12 22:19:26 2024 From: achung at openjdk.org (Alisen Chung) Date: Fri, 12 Jan 2024 22:19:26 GMT Subject: Integrated: 8321489: Update LCMS to 2.16 In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 22:22:53 GMT, Alisen Chung wrote: > Update LCMS, mach5 client tests are green This pull request has now been integrated. Changeset: dc7d3b18 Author: Alisen Chung URL: https://git.openjdk.org/jdk/commit/dc7d3b182d226253ca246dd854c85c4dd964f10e Stats: 1599 lines in 21 files changed: 1240 ins; 134 del; 225 mod 8321489: Update LCMS to 2.16 Reviewed-by: serb, dnguyen, prr ------------- PR: https://git.openjdk.org/jdk/pull/17382 From serb at openjdk.org Fri Jan 12 22:35:34 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 12 Jan 2024 22:35:34 GMT Subject: RFR: 4760025: sRGB conversions to and from CIE XYZ incorrect [v3] In-Reply-To: <0pH-ce3ZKwh7NqRAndPp-pFCRBRTHl3VgDytBBMPeAA=.f2d03283-bdd8-469d-89d9-279af8fbfb21@github.com> References: <0pH-ce3ZKwh7NqRAndPp-pFCRBRTHl3VgDytBBMPeAA=.f2d03283-bdd8-469d-89d9-279af8fbfb21@github.com> Message-ID: > Since the time the bug was reported color conversion accuracy for the sRGB profile and specific values from the report increased by x100. This is a request to add the code from the report as a test case. Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: Arrays.toString ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17388/files - new: https://git.openjdk.org/jdk/pull/17388/files/8925fbd5..726f461e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17388&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17388&range=01-02 Stats: 14 lines in 1 file changed: 1 ins; 9 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/17388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17388/head:pull/17388 PR: https://git.openjdk.org/jdk/pull/17388 From serb at openjdk.org Fri Jan 12 22:35:36 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 12 Jan 2024 22:35:36 GMT Subject: RFR: 4760025: sRGB conversions to and from CIE XYZ incorrect [v2] In-Reply-To: References: <0pH-ce3ZKwh7NqRAndPp-pFCRBRTHl3VgDytBBMPeAA=.f2d03283-bdd8-469d-89d9-279af8fbfb21@github.com> Message-ID: <5ZzIWrunB3VaXyvMkqspIVOcllBdl8RdQ5IrsCvF3C8=.dcce94c6-4f9c-44a3-bbe3-e922e0c287a2@github.com> On Fri, 12 Jan 2024 21:37:45 GMT, Alexey Ivanov wrote: >> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: >> >> Update SimpleSRGBToFromCIEXYZ.java > > test/jdk/java/awt/color/ICC_ColorSpace/SimpleSRGBToFromCIEXYZ.java line 42: > >> 40: >> 41: if (inv[0] != 0 || Math.abs(inv[1] - g) > 0.0001f || inv[2] != 0) { >> 42: System.err.println("Expected color:\t" + toString(rgb)); > > `Arrays.toString(rgb)` instead of custom `toString`? +1 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17388#discussion_r1450983454 From aivanov at openjdk.org Fri Jan 12 22:55:20 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 12 Jan 2024 22:55:20 GMT Subject: RFR: 4760025: sRGB conversions to and from CIE XYZ incorrect [v3] In-Reply-To: References: <0pH-ce3ZKwh7NqRAndPp-pFCRBRTHl3VgDytBBMPeAA=.f2d03283-bdd8-469d-89d9-279af8fbfb21@github.com> Message-ID: On Fri, 12 Jan 2024 22:35:34 GMT, Sergey Bylokhov wrote: >> Since the time the bug was reported color conversion accuracy for the sRGB profile and specific values from the report increased by x100. This is a request to add the code from the report as a test case. > > Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: > > Arrays.toString test/jdk/java/awt/color/ICC_ColorSpace/SimpleSRGBToFromCIEXYZ.java line 46: > 44: System.err.println("XYZ color:\t\t" + Arrays.toString(xyz)); > 45: System.err.println("Actual color:\t" + Arrays.toString(inv)); > 46: throw new java.lang.Error("Wrong color"); Is the full class name required? All classes from `java.lang` are imported, aren't they? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17388#discussion_r1450994550 From serb at openjdk.org Fri Jan 12 23:48:49 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 12 Jan 2024 23:48:49 GMT Subject: RFR: 4760025: sRGB conversions to and from CIE XYZ incorrect [v4] In-Reply-To: <0pH-ce3ZKwh7NqRAndPp-pFCRBRTHl3VgDytBBMPeAA=.f2d03283-bdd8-469d-89d9-279af8fbfb21@github.com> References: <0pH-ce3ZKwh7NqRAndPp-pFCRBRTHl3VgDytBBMPeAA=.f2d03283-bdd8-469d-89d9-279af8fbfb21@github.com> Message-ID: <-RwxGwUfms-5wYbxF-2xqaLEEiQOsHxgfoGiz7AQBXE=.6d6e6deb-2475-41aa-8f09-8ccf4de2392b@github.com> > Since the time the bug was reported color conversion accuracy for the sRGB profile and specific values from the report increased by x100. This is a request to add the code from the report as a test case. Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: Update SimpleSRGBToFromCIEXYZ.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17388/files - new: https://git.openjdk.org/jdk/pull/17388/files/726f461e..8e48839f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17388&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17388&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17388/head:pull/17388 PR: https://git.openjdk.org/jdk/pull/17388 From serb at openjdk.org Fri Jan 12 23:48:49 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 12 Jan 2024 23:48:49 GMT Subject: RFR: 4760025: sRGB conversions to and from CIE XYZ incorrect [v3] In-Reply-To: References: <0pH-ce3ZKwh7NqRAndPp-pFCRBRTHl3VgDytBBMPeAA=.f2d03283-bdd8-469d-89d9-279af8fbfb21@github.com> Message-ID: On Fri, 12 Jan 2024 22:53:08 GMT, Alexey Ivanov wrote: >> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: >> >> Arrays.toString > > test/jdk/java/awt/color/ICC_ColorSpace/SimpleSRGBToFromCIEXYZ.java line 46: > >> 44: System.err.println("XYZ color:\t\t" + Arrays.toString(xyz)); >> 45: System.err.println("Actual color:\t" + Arrays.toString(inv)); >> 46: throw new java.lang.Error("Wrong color"); > > Is the full class name required? All classes from `java.lang` are imported, aren't they? for test execution it does not matter but when opened in ide it conflicts with some other Error classes from the tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17388#discussion_r1451033233 From linkuntju at gmail.com Sat Jan 13 02:14:56 2024 From: linkuntju at gmail.com (=?UTF-8?B?5p6Xa3Vybg==?=) Date: Sat, 13 Jan 2024 10:14:56 +0800 Subject: Windows and Linux: Physical font does not have fallback fonts. In-Reply-To: References: Message-ID: Thank you for your help. I am a new hand on java, you mentioned ?Swing implements an implicit fall back for most uses by controls where it is safer to assume they just want to display some glyph?, it means swing implicitly uses logical font to fallback? Philip Race ?2024?1?13??? 03:10??? > Right. This is on purpose. We do not want to change that behaviour. > A font should not lie about what glyphs it contains and provide no way for > apps > to know if that is REALLY from this font. Proper text rendering is not > possible > if you lie to the app. > > JDK on MacOS does things differently because that's the implementation we > unfortunately inherited > from Apple. It is a real pain. > > Swing implements an implicit fall back for most uses by controls where it > is safer to assume > they just want to display some glyph, but a change to do that globally for > Java 2D is not going to be accepted, > and even the Swing one causes some problems as there's no way to tell it > has a fall back. > > The fall back to "Dialog" if a font is not found cannot be changed. It is > specified. > > > https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/Font.html#%3Cinit%3E(java.lang.String,int,int) > > "If the name parameter represents something other than a logical font, > i.e. is interpreted as a physical font face or family, and this cannot be > mapped by the implementation to a physical font or a compatible > alternative, then the font system will map the Font instance to "Dialog", > such that for example, the family as reported by getFamily > > will be "Dialog". > > -phil. > > > On 1/12/24 4:56 AM, ?kurn wrote: > > Hi everyone, > > I am doing GUI development based on Java on Ubuntu, and I find some > problems in it. > Would it be possible for me to discuss with you? > > 1. There is no fallback font on Windows and Linux when using physical > fonts. > The FileFont class does not implements FontSubstitution interface, so > there are no substituting glyphs from another font at render time(in > GlyphLayout::layout). > For example, when "jTextField.setFont(new Font("Ubuntu Mono", Font.PLAIN, > 20))" on Ubuntu, all the CJK characters will show as tofu in this > jTextField. Almost every font does not contain all possible inputs, adding > some fallbacks font may help those who don't just use one language. > > 2. The fonts that JDK does not found are mapped to the ?Dialog? font. > As > https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/Font.html#%3Cinit%3E(java.lang.String,int,int) > shows, If the name parameter represents something other than a logical > font, i.e. is interpreted as a physical font face or family, and this > cannot be mapped by the implementation to a physical font or a compatible > alternative, then the font system will map the Font instance to "Dialog". > On Linux, get map fonts by fontconfig may be more flexible, more > configurable. > > For the two questions above, I have a preliminary patch. > > I added a new fallback form ?FONTCONFIGURATION_FALLBACK? and implemented > it for Linux system, it creates a composite font by obtaining map fonts > info for the specified name and style through fontconfig. > And I make the FileFont class implement the FontSubstitution interface, > reuse the FONTCONFIGURATION_FALLBACK code. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serb at openjdk.org Sat Jan 13 05:05:19 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 13 Jan 2024 05:05:19 GMT Subject: RFR: 8320328: Restore interrupted flag in ImageIcon.loadImage [v4] In-Reply-To: <8930jQBNzUPpOPOgzXwJz1os6i3cT1d1ycI9864nePw=.8711e8f1-6e5e-44ac-838b-d92af44240ae@github.com> References: <_xn5gOvor_Sgp_AkFYsPbM_xGbf7_GhGgx5qpCBr6d8=.0253d8d3-42ae-49f7-b878-ba8987a403d6@github.com> <8930jQBNzUPpOPOgzXwJz1os6i3cT1d1ycI9864nePw=.8711e8f1-6e5e-44ac-838b-d92af44240ae@github.com> Message-ID: On Fri, 12 Jan 2024 21:53:44 GMT, Rajat Mahajan wrote: >> ImageIcon.loadImage used to handle InterruptedException only by printing a message to the console. JDK-8236987 handled the interrupted state more gracefully, but it didn't restore the interrupted flag. >> This change restores the interrupted flag that will allow the following code to handle interruption and exit the thread; otherwise, the thread will continue to run. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > Update LoadInterruptTest.java > > removed extra blank lines. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17406#pullrequestreview-1819802879 From serb at openjdk.org Sat Jan 13 05:09:21 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 13 Jan 2024 05:09:21 GMT Subject: RFR: 8295804: javax/swing/JFileChooser/JFileChooserSetLocationTest.java failed with "setLocation() is not working properly" [v3] In-Reply-To: References: Message-ID: <-LrBPbYLxXGwBVgKvkTNjp3S45nXjY-M7bLTBjxhP48=.4922adeb-0f04-41a9-8bd2-80e3f5463306@github.com> On Fri, 12 Jan 2024 05:12:40 GMT, Tejesh R wrote: >> The issue is that the doc area (in respect to the screen height which is 768px) which is at the bottom was causing the `JFileChooser `to be placed slightly above the set location. Was able to reproduce in local machine with reference to the failure image provided in the CI logs. The suggested fix is to place the main Frame slightly above the center of the screen than setting at the center of the screen. Several CI runs were made and no issue found. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix test/jdk/javax/swing/JFileChooser/JFileChooserSetLocationTest.java line 216: > 214: > 215: int width = (int) screenSize.getWidth() / 2; > 216: int height = (int) screenSize.getHeight() / 2; This is not the width and height, this is the kind of point(x,y) where the frame will be located. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17364#discussion_r1451242135 From lbourges at openjdk.org Sat Jan 13 14:44:25 2024 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Sat, 13 Jan 2024 14:44:25 GMT Subject: RFR: JDK-8323695 RenderPerf (2D) enhancements (23.12) Message-ID: <13rvTg4QWBKawohFsLhUv8n_7j5xhbcJzTm1IpZQtMo=.2fc70458-f4a1-41ab-bb4b-8e4f49db0148@github.com> - new executor modes (buffer & volatile) - support parallel rendering on several frames and / or screens - added robot calibration + optionally use rounded duration to min frame latency (120Hz) - give more statistics in verbose (-v) - added new command-line arguments - added version + help information ------------- Commit messages: - RenderPerf 23.12 enhancements: Changes: https://git.openjdk.org/jdk/pull/17408/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17408&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323695 Stats: 1533 lines in 1 file changed: 1236 ins; 61 del; 236 mod Patch: https://git.openjdk.org/jdk/pull/17408.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17408/head:pull/17408 PR: https://git.openjdk.org/jdk/pull/17408 From lbourges at openjdk.org Sat Jan 13 17:32:19 2024 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Sat, 13 Jan 2024 17:32:19 GMT Subject: RFR: JDK-8323695 RenderPerf (2D) enhancements (23.12) In-Reply-To: <13rvTg4QWBKawohFsLhUv8n_7j5xhbcJzTm1IpZQtMo=.2fc70458-f4a1-41ab-bb4b-8e4f49db0148@github.com> References: <13rvTg4QWBKawohFsLhUv8n_7j5xhbcJzTm1IpZQtMo=.2fc70458-f4a1-41ab-bb4b-8e4f49db0148@github.com> Message-ID: <2kU-plwQKkwXc3BEp07T9k8uqiGNsU1DqdO5hZIUZxs=.36172202-a0da-4674-94f0-ca291d810efc@github.com> On Fri, 12 Jan 2024 21:34:32 GMT, Laurent Bourg?s wrote: > - new executor modes (buffer & volatile) > - support parallel rendering on several frames and / or screens > - added robot calibration + optionally use rounded duration to min frame latency (120Hz) > - give more statistics in verbose (-v) > - added new command-line arguments > - added version + help information @prrace here it the renderperf patch. @mrserb ------------- PR Comment: https://git.openjdk.org/jdk/pull/17408#issuecomment-1890601519 From serb at openjdk.org Sat Jan 13 18:47:18 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 13 Jan 2024 18:47:18 GMT Subject: RFR: 8323170 - j2dbench is using outdated javac source/target to be able to build by itself In-Reply-To: References: Message-ID: On Tue, 9 Jan 2024 09:31:30 GMT, Ji?? Van?k wrote: >I think j2dbench should go in spirit of in-tree jtregs and shold be ok for jdk it is cloned from. Anybody who wishes to run it on older jdk, can clone it from older jdk. The code in the j2dbench is maintained in a way that every new feature/tests added to it should work on the old JDK version, or be skipped. That helps to compare the performance of say JDK21 vs JDK8 with the new tests. and the old source/target helps to check that the new java lang features are not added to it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17303#issuecomment-1890692486 From jvanek at openjdk.org Sat Jan 13 20:19:18 2024 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Sat, 13 Jan 2024 20:19:18 GMT Subject: RFR: 8323170 - j2dbench is using outdated javac source/target to be able to build by itself In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 13:03:22 GMT, Ji?? Van?k wrote: > This PR is fixig to-old values of javac source/target for jdk22. > Note, that jdk21 suffers the same, only the target values have to be 8. I will be happy to backport this cange to jdk17 later. > > Note, that considering the rolling release of jdk and the reached threshold of bytecode compatibility, we will be forced to do this bump every STS, so best would be to drop this hardcoded limitation. As it obtains a bit more coding, I had filled the [JDK-8323169](https://bugs.openjdk.org/browse/JDK-8323169) - [ j2dbench need constant updating of javac source/target ](https://bugs.openjdk.org/browse/JDK-8323169) and will be happy to fit it for jdk asap once this direct fix bubbles to jdk21 Thanx! I quite agree, then ------------- PR Comment: https://git.openjdk.org/jdk/pull/17303#issuecomment-1890757466 From serb at openjdk.org Sun Jan 14 09:34:26 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 14 Jan 2024 09:34:26 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v14] In-Reply-To: References: Message-ID: On Fri, 12 Jan 2024 21:05:19 GMT, Alexey Ivanov wrote: > Currently, we have test and gold which use the same ColorSpace which could be plain or wrapper for both cases. It looks confusing to me. That could be fine. We can create a gold image first, then parametrize the test method by different src/mid/dst and compare the result vs gold, so we will cover all possible combinations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1451693480 From aivanov at openjdk.org Sun Jan 14 20:28:19 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Sun, 14 Jan 2024 20:28:19 GMT Subject: RFR: 4760025: sRGB conversions to and from CIE XYZ incorrect [v4] In-Reply-To: <-RwxGwUfms-5wYbxF-2xqaLEEiQOsHxgfoGiz7AQBXE=.6d6e6deb-2475-41aa-8f09-8ccf4de2392b@github.com> References: <0pH-ce3ZKwh7NqRAndPp-pFCRBRTHl3VgDytBBMPeAA=.f2d03283-bdd8-469d-89d9-279af8fbfb21@github.com> <-RwxGwUfms-5wYbxF-2xqaLEEiQOsHxgfoGiz7AQBXE=.6d6e6deb-2475-41aa-8f09-8ccf4de2392b@github.com> Message-ID: On Fri, 12 Jan 2024 23:48:49 GMT, Sergey Bylokhov wrote: >> Since the time the bug was reported color conversion accuracy for the sRGB profile and specific values from the report increased by x100. This is a request to add the code from the report as a test case. > > Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: > > Update SimpleSRGBToFromCIEXYZ.java Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17388#pullrequestreview-1820296015 From aivanov at openjdk.org Sun Jan 14 20:34:23 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Sun, 14 Jan 2024 20:34:23 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v14] In-Reply-To: References: Message-ID: On Sun, 14 Jan 2024 09:31:29 GMT, Sergey Bylokhov wrote: > > Currently, we have test and gold which use the same ColorSpace which could be plain or wrapper for both cases. It looks confusing to me. > > That could be fine. We can create a gold image first, then parametrize the test method by different src/mid/dst and compare the result vs gold, so we will cover all possible combinations. It tried it? with for-loop over `ColorSpaceSelector.PYCC` and `ColorSpaceSelector.WRAPPED_PYCC` and I didn't like the result. Although I kept all the images inside the loop to be safe. The approach above repeats several lines, however, it's more straightforward and reporting errors is easier: you'll the the line where exception occurred. If it's in the loop, the exception could happen on the same line but with different parameters. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1451798570 From serb at openjdk.org Sun Jan 14 23:08:33 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 14 Jan 2024 23:08:33 GMT Subject: Integrated: 4760025: sRGB conversions to and from CIE XYZ incorrect In-Reply-To: <0pH-ce3ZKwh7NqRAndPp-pFCRBRTHl3VgDytBBMPeAA=.f2d03283-bdd8-469d-89d9-279af8fbfb21@github.com> References: <0pH-ce3ZKwh7NqRAndPp-pFCRBRTHl3VgDytBBMPeAA=.f2d03283-bdd8-469d-89d9-279af8fbfb21@github.com> Message-ID: On Fri, 12 Jan 2024 07:37:13 GMT, Sergey Bylokhov wrote: > Since the time the bug was reported color conversion accuracy for the sRGB profile and specific values from the report increased by x100. This is a request to add the code from the report as a test case. This pull request has now been integrated. Changeset: bdee968e Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/bdee968e3e969784df130c75a5cf6a1d2847bd29 Stats: 50 lines in 1 file changed: 50 ins; 0 del; 0 mod 4760025: sRGB conversions to and from CIE XYZ incorrect Reviewed-by: prr, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/17388 From duke at openjdk.org Mon Jan 15 04:47:22 2024 From: duke at openjdk.org (songpv-imt) Date: Mon, 15 Jan 2024 04:47:22 GMT Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination [v7] In-Reply-To: References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> <4_Xhk9SMIvvOthojgfccDt2kRA6DXR5xA7TDG4ujKCU=.465bafb2-7a81-4b72-8413-8216d11d6b07@github.com> Message-ID: On Fri, 12 Jan 2024 18:14:20 GMT, Victor Dyakov wrote: >>> Why this issue can be reproduced in macOS 14? What was changed in that version? >> >> I am uncertain about the exact code modifications in MacOS 14 that make this issue reproducible. Nevertheless, considering the underlying code logic, this issue could occur on any version of MacOS, contingent on timing factors, if the fix is not applied. > > @songpv-imt any plans to resume your work on this fix? @victordyakov, hmm... I think I have addressed all comments from the reviewers. Any other action I need to follow up? Thank. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16396#issuecomment-1891294787 From aturbanov at openjdk.org Mon Jan 15 07:35:26 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 15 Jan 2024 07:35:26 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v4] In-Reply-To: References: Message-ID: On Fri, 12 Jan 2024 22:18:04 GMT, Alisen Chung wrote: >> SunToolkit.java is trying to post an event on the TrayIcon appContext, but the TrayIcon was already removed by the test, causing an error. The fix is to make SunToolkit skip posting the event if appContext is null. The test is also updated to remove applet usage and use PassFailJFrame instead. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > used jtreg.SkippedException, updated copyright years test/jdk/java/awt/TrayIcon/ShowAfterDisposeTest.java line 85: > 83: frame.setLayout(new BorderLayout()); > 84: > 85: frame.setSize(200,200); Suggestion: frame.setSize(200, 200); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17329#discussion_r1452008059 From aturbanov at openjdk.org Mon Jan 15 08:00:21 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 15 Jan 2024 08:00:21 GMT Subject: RFR: JDK-8320113: [macos14] : ShapeNotSetSometimes.java fails intermittently on macOS 14 [v2] In-Reply-To: <-XwORy2eQahQ3dyJWrE20h41kdSMFNbyHQ9FGZ0z2aA=.4596d9dd-b4da-4ff1-bae5-508fa4bae37b@github.com> References: <-XwORy2eQahQ3dyJWrE20h41kdSMFNbyHQ9FGZ0z2aA=.4596d9dd-b4da-4ff1-bae5-508fa4bae37b@github.com> Message-ID: On Fri, 12 Jan 2024 20:21:52 GMT, Harshitha Onkar wrote: >> ShapeNotSetSometimes.java fails intermittently on macOS 14. Following is a test stabilization fix for macOS 14. With the added delays ShapeNotSetSometimes.java passes on older versions of macOS as well as on macOS 14.1, 14.2. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > test stabilization fix test/jdk/java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java line 128: > 126: robot = new Robot(); > 127: > 128: for(int i = 1; i <= 50; i++) { Suggestion: for (int i = 1; i <= 50; i++) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17180#discussion_r1452027437 From lbourges at openjdk.org Mon Jan 15 08:24:20 2024 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Mon, 15 Jan 2024 08:24:20 GMT Subject: RFR: JDK-8320113: [macos14] : ShapeNotSetSometimes.java fails intermittently on macOS 14 [v2] In-Reply-To: <-XwORy2eQahQ3dyJWrE20h41kdSMFNbyHQ9FGZ0z2aA=.4596d9dd-b4da-4ff1-bae5-508fa4bae37b@github.com> References: <-XwORy2eQahQ3dyJWrE20h41kdSMFNbyHQ9FGZ0z2aA=.4596d9dd-b4da-4ff1-bae5-508fa4bae37b@github.com> Message-ID: On Fri, 12 Jan 2024 20:21:52 GMT, Harshitha Onkar wrote: >> ShapeNotSetSometimes.java fails intermittently on macOS 14. Following is a test stabilization fix for macOS 14. With the added delays ShapeNotSetSometimes.java passes on older versions of macOS as well as on macOS 14.1, 14.2. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > test stabilization fix Looks better, not an official reviewer ------------- PR Comment: https://git.openjdk.org/jdk/pull/17180#issuecomment-1891544249 From serb at openjdk.org Mon Jan 15 11:30:20 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 15 Jan 2024 11:30:20 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v4] In-Reply-To: References: Message-ID: On Fri, 12 Jan 2024 22:18:04 GMT, Alisen Chung wrote: >> SunToolkit.java is trying to post an event on the TrayIcon appContext, but the TrayIcon was already removed by the test, causing an error. The fix is to make SunToolkit skip posting the event if appContext is null. The test is also updated to remove applet usage and use PassFailJFrame instead. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > used jtreg.SkippedException, updated copyright years src/java.desktop/share/classes/sun/awt/SunToolkit.java line 450: > 448: if (appContext == null) { > 449: return; > 450: } I think we should check why the appcontext is null here, the event comes from the native peer, so when the event was created the peer was there, if the peer exists the target should have an appconext as well. Maybe the problem is that we try to jump on EDT twice? First time from CTrayIcon.postEvent-> SunToolkit.executeOnEventHandlerThread and then one more time via SunToolkit.postEvent(). Can deletion of the executeOnEventHandlerThread solve the problem? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17329#discussion_r1452259491 From serb at openjdk.org Mon Jan 15 11:36:23 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 15 Jan 2024 11:36:23 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v4] In-Reply-To: References: Message-ID: On Mon, 15 Jan 2024 11:27:43 GMT, Sergey Bylokhov wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> used jtreg.SkippedException, updated copyright years > > src/java.desktop/share/classes/sun/awt/SunToolkit.java line 450: > >> 448: if (appContext == null) { >> 449: return; >> 450: } > > I think we should check why the appcontext is null here, the event comes from the native peer, so when the event was created the peer was there, if the peer exists the target should have an appconext as well. > > Maybe the problem is that we try to jump on EDT twice? First time from CTrayIcon.postEvent-> SunToolkit.executeOnEventHandlerThread and then one more time via SunToolkit.postEvent(). > > Can deletion of the executeOnEventHandlerThread solve the problem? Or maybe it is a lack of synchronization? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17329#discussion_r1452264759 From avu at openjdk.org Mon Jan 15 11:43:19 2024 From: avu at openjdk.org (Alexey Ushakov) Date: Mon, 15 Jan 2024 11:43:19 GMT Subject: RFR: JDK-8323695 RenderPerf (2D) enhancements (23.12) In-Reply-To: <13rvTg4QWBKawohFsLhUv8n_7j5xhbcJzTm1IpZQtMo=.2fc70458-f4a1-41ab-bb4b-8e4f49db0148@github.com> References: <13rvTg4QWBKawohFsLhUv8n_7j5xhbcJzTm1IpZQtMo=.2fc70458-f4a1-41ab-bb4b-8e4f49db0148@github.com> Message-ID: On Fri, 12 Jan 2024 21:34:32 GMT, Laurent Bourg?s wrote: > - new executor modes (buffer & volatile) > - support parallel rendering on several frames and / or screens > - added robot calibration + optionally use rounded duration to min frame latency (120Hz) > - give more statistics in verbose (-v) > - added new command-line arguments > - added version + help information test/jdk/performance/client/RenderPerfTest/src/renderperf/RenderPerfTest.java line 1246: > 1244: nData); > 1245: } > 1246: return String.format("%-25s : %.3f (%.3f) %s", name, scores[0], scores[1], (USE_FPS ? "FPS" : "ms")); Just a minor note: It's not easy to understand the meaning of the value in brackets from the output. Some hints like a table header with column names printed before the results could be useful here. java -jar dist/RenderPerfTest.jar Using GraphicsConfiguration(s): [0:0][MTLGraphicsConfig[Display 1]] ArgbSurfaceBlitImage[1] : 60.497 (10.408) FPS ArgbSwBlitImage[1] : 11.226 (0.569) FPS BgrSurfaceBlitImage[1] : 59.700 (10.446) FPS ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17408#discussion_r1452246743 From lbourges at openjdk.org Mon Jan 15 12:29:21 2024 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Mon, 15 Jan 2024 12:29:21 GMT Subject: RFR: JDK-8323695 RenderPerf (2D) enhancements (23.12) In-Reply-To: <13rvTg4QWBKawohFsLhUv8n_7j5xhbcJzTm1IpZQtMo=.2fc70458-f4a1-41ab-bb4b-8e4f49db0148@github.com> References: <13rvTg4QWBKawohFsLhUv8n_7j5xhbcJzTm1IpZQtMo=.2fc70458-f4a1-41ab-bb4b-8e4f49db0148@github.com> Message-ID: <06inRdRcqDzD57ZNByCsdFHVuyq1ZyPDnYg5W-ZAoao=.7dd8f6b2-df94-4333-b11b-394d8064c9e8@github.com> On Fri, 12 Jan 2024 21:34:32 GMT, Laurent Bourg?s wrote: > - new executor modes (buffer & volatile) > - support parallel rendering on several frames and / or screens > - added robot calibration + optionally use rounded duration to min frame latency (120Hz) > - give more statistics in verbose (-v) > - added new command-line arguments > - added version + help information I updated my RenderPerf git with release 23.12: https://github.com/bourgesl/RenderPerf https://github.com/bourgesl/RenderPerf/releases/tag/v23_12 Works on jdk8+ ------------- PR Comment: https://git.openjdk.org/jdk/pull/17408#issuecomment-1892079806 From rmahajan at openjdk.org Mon Jan 15 13:11:29 2024 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Mon, 15 Jan 2024 13:11:29 GMT Subject: Integrated: 8320328: Restore interrupted flag in ImageIcon.loadImage In-Reply-To: <_xn5gOvor_Sgp_AkFYsPbM_xGbf7_GhGgx5qpCBr6d8=.0253d8d3-42ae-49f7-b878-ba8987a403d6@github.com> References: <_xn5gOvor_Sgp_AkFYsPbM_xGbf7_GhGgx5qpCBr6d8=.0253d8d3-42ae-49f7-b878-ba8987a403d6@github.com> Message-ID: On Fri, 12 Jan 2024 19:17:24 GMT, Rajat Mahajan wrote: > ImageIcon.loadImage used to handle InterruptedException only by printing a message to the console. JDK-8236987 handled the interrupted state more gracefully, but it didn't restore the interrupted flag. > This change restores the interrupted flag that will allow the following code to handle interruption and exit the thread; otherwise, the thread will continue to run. This pull request has now been integrated. Changeset: f368a0c1 Author: Rajat Mahajan Committer: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/f368a0c12e0c51054fa89dfae8d4116fa535debf Stats: 11 lines in 2 files changed: 7 ins; 1 del; 3 mod 8320328: Restore interrupted flag in ImageIcon.loadImage Reviewed-by: aivanov, serb ------------- PR: https://git.openjdk.org/jdk/pull/17406 From kcr at openjdk.org Mon Jan 15 16:05:28 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 15 Jan 2024 16:05:28 GMT Subject: RFR: 8221261: deadlock of CInputMethod.characterIndexForPoint and webkit.InputMethodClientImpl.getLocationOffset In-Reply-To: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com> References: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com> Message-ID: On Fri, 22 Dec 2023 11:27:00 GMT, Johannes Bechberger wrote: > A dead-lock is caused by the interaction of MacOS, the AWTEventQueue and JavaFX when the users pressed the Caps Lock key while the AWTEventQueue is processing another event (more on this in the issue). The bug depends on the specific timing of the event sending and can apparently be prevented by finishing all incoming OS events directly while the LWCToolkit.invokeAndWait method is executed. > > This fix is tested and fixes the issue. > > I attached a small > [reproducer](https://github.com/openjdk/jdk/files/13751865/Archive.zip), just run it with `mvn install package javafx:run`. We were able to fix this entirely in JavaFX via openjdk/jfx#1327 , which is now integrated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17184#issuecomment-1892435484 From goetz at openjdk.org Mon Jan 15 16:05:32 2024 From: goetz at openjdk.org (Goetz Lindenmaier) Date: Mon, 15 Jan 2024 16:05:32 GMT Subject: RFR: 8318590: JButton ignores margin when painting HTML text [v5] In-Reply-To: <5LcDM9RyprALVI-ORxap7LCRQiNF3xtAHMqenYUKzXY=.0e733ade-053b-4210-895c-3bbceb4aefdd@github.com> References: <5LcDM9RyprALVI-ORxap7LCRQiNF3xtAHMqenYUKzXY=.0e733ade-053b-4210-895c-3bbceb4aefdd@github.com> Message-ID: On Tue, 5 Dec 2023 19:07:07 GMT, Damon Nguyen wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Re-add test because still valid > > I also have updated the copyright year for BasicButtonUI. I believe that's the only case of copyright years that needs to be updated. Hi @DamonGuy, in the end, the test was deleted, although you added a commit re-adding it. Was this intended or a prank by GitHub? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16869#issuecomment-1892436068 From aivanov at openjdk.org Mon Jan 15 18:29:30 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 15 Jan 2024 18:29:30 GMT Subject: RFR: 4760025: sRGB conversions to and from CIE XYZ incorrect [v3] In-Reply-To: References: <0pH-ce3ZKwh7NqRAndPp-pFCRBRTHl3VgDytBBMPeAA=.f2d03283-bdd8-469d-89d9-279af8fbfb21@github.com> Message-ID: <_GFqDeTVfaGasT96u56Hnr-IrKjt3VtIOMBVnUFOt7o=.cafbc4f6-4e75-45e2-8792-421e0df1d549@github.com> On Fri, 12 Jan 2024 23:46:06 GMT, Sergey Bylokhov wrote: > for test execution it does not matter but when opened in ide it conflicts with some other Error classes from the tests. I feel your pain! I suggest refactoring those tests and make their private `Error` class a static member of the test class itself. This is why I'm for having only one public class in a test file and no other top-level classes ? to avoid such naming clashes, which makes it easier to edit and run tests from an IDE. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17388#discussion_r1452660551 From philip.race at oracle.com Mon Jan 15 20:01:47 2024 From: philip.race at oracle.com (Philip Race) Date: Mon, 15 Jan 2024 12:01:47 -0800 Subject: RFR: 8318590: JButton ignores margin when painting HTML text [v5] In-Reply-To: References: <5LcDM9RyprALVI-ORxap7LCRQiNF3xtAHMqenYUKzXY=.0e733ade-053b-4210-895c-3bbceb4aefdd@github.com> Message-ID: There are 2 different tests involved with names that are similar so you need to look closely One was deleted in the initial commit and never restored : test/jdk/javax/swing/JButton/HtmlButtonImageTest/HtmlButtonImageTest.java That is what you see deleted in the integration. The 2nd test was deleted in a later commit and then restored after that test/jdk/javax/swing/JButton/HtmlButtonWithTextAndIcon.java It does not appear in the integration. -phil. On 1/15/24 8:05 AM, Goetz Lindenmaier wrote: > On Tue, 5 Dec 2023 19:07:07 GMT, Damon Nguyen wrote: > >>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Re-add test because still valid >> I also have updated the copyright year for BasicButtonUI. I believe that's the only case of copyright years that needs to be updated. > Hi @DamonGuy, in the end, the test was deleted, although you added a commit re-adding it. Was this intended or a prank by GitHub? > > ------------- > > PR Comment: https://git.openjdk.org/jdk/pull/16869#issuecomment-1892436068 From aivanov at openjdk.org Mon Jan 15 21:15:22 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 15 Jan 2024 21:15:22 GMT Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination [v9] In-Reply-To: <2N2LTQWDWIXcKiHYD-adxUpwq49-GN-YwE88LhB-LrU=.543ae6c1-624d-481b-9e70-3df93b5c3d79@github.com> References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> <2N2LTQWDWIXcKiHYD-adxUpwq49-GN-YwE88LhB-LrU=.543ae6c1-624d-481b-9e70-3df93b5c3d79@github.com> Message-ID: On Tue, 19 Dec 2023 02:09:08 GMT, songpv-imt wrote: >> The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method. >> >> JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287) > > songpv-imt has updated the pull request incrementally with one additional commit since the last revision: > > Update InterJVMGetDropSuccessTest.java > - Update success1 and success2 to volatile I reproduced the failure on macOS 14.1, drag isn't started. With the fix to the test, drag is started as expected, and the test passes successfully. Yet I'd like to understand the test logic better. I think the test could be improved further, however, lots of refactoring could change the test logic. A couple of points that can be improved though. Instead of using `robot.setWaitForIdle(true)`, it should be enough to add `robot.waitForIdle()` after `mouseMove`. This way, the test should execute quicker since there'll be no implicit `waitForIdle` between each event generated by robot. I believe `robot.delay(50)` could be removed from the for-loop which moves the mouse. What I suggest is: Robot robot = new Robot(); robot.mouseMove(sourcePoint.x, sourcePoint.y); robot.waitForIdle(); robot.delay(50); robot.mousePress(InputEvent.BUTTON1_DOWN_MASK); for (Point p = new Point(sourcePoint); !p.equals(targetPoint); p.translate(Util.sign(targetPoint.x - p.x), Util.sign(targetPoint.y - p.y))) { robot.mouseMove(p.x, p.y); } The initial FRAME_ACTIVATION_TIMEOUT could also be reduced to 1_000 with an additional `robot.waitForIdle()`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16396#issuecomment-1892769787 From aivanov at openjdk.org Mon Jan 15 21:21:21 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 15 Jan 2024 21:21:21 GMT Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination [v9] In-Reply-To: <2N2LTQWDWIXcKiHYD-adxUpwq49-GN-YwE88LhB-LrU=.543ae6c1-624d-481b-9e70-3df93b5c3d79@github.com> References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> <2N2LTQWDWIXcKiHYD-adxUpwq49-GN-YwE88LhB-LrU=.543ae6c1-624d-481b-9e70-3df93b5c3d79@github.com> Message-ID: On Tue, 19 Dec 2023 02:09:08 GMT, songpv-imt wrote: >> The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method. >> >> JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287) > > songpv-imt has updated the pull request incrementally with one additional commit since the last revision: > > Update InterJVMGetDropSuccessTest.java > - Update success1 and success2 to volatile Please update the copyright year in both files to 2024. test/jdk/java/awt/dnd/InterJVMGetDropSuccessTest/InterJVMGetDropSuccessTest.java line 301: > 299: for (Point p = new Point(sourcePoint); !p.equals(targetPoint); > 300: p.translate(Util.sign(targetPoint.x - p.x), > 301: Util.sign(targetPoint.y - p.y))) { Suggestion: p.translate(Util.sign(targetPoint.x - p.x), Util.sign(targetPoint.y - p.y))) { Align the second parameter on the wrapped line to the first one on the first line. ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16396#pullrequestreview-1822259995 PR Review Comment: https://git.openjdk.org/jdk/pull/16396#discussion_r1452746985 From aivanov at openjdk.org Mon Jan 15 22:10:22 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 15 Jan 2024 22:10:22 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v4] In-Reply-To: References: Message-ID: <1Epf2gicQK7_d_zOhKh17_TfFpvNt2BINqkzbMqJDdU=.7ec03add-baca-4aad-9009-76efb8c74f06@github.com> On Fri, 12 Jan 2024 22:18:04 GMT, Alisen Chung wrote: >> SunToolkit.java is trying to post an event on the TrayIcon appContext, but the TrayIcon was already removed by the test, causing an error. The fix is to make SunToolkit skip posting the event if appContext is null. The test is also updated to remove applet usage and use PassFailJFrame instead. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > used jtreg.SkippedException, updated copyright years Changes requested by aivanov (Reviewer). test/jdk/java/awt/TrayIcon/ShowAfterDisposeTest.java line 49: > 47: public static void main(String[] args) throws Exception { > 48: boolean traySupported = SystemTray.isSupported(); > 49: if (!traySupported) { Suggestion: if (!SystemTray.isSupported()) { The local variable is redundant. ------------- PR Review: https://git.openjdk.org/jdk/pull/17329#pullrequestreview-1822226261 PR Review Comment: https://git.openjdk.org/jdk/pull/17329#discussion_r1452725453 From aivanov at openjdk.org Mon Jan 15 22:10:25 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 15 Jan 2024 22:10:25 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v3] In-Reply-To: References: Message-ID: On Fri, 12 Jan 2024 22:04:37 GMT, Alisen Chung wrote: >> SunToolkit.java is trying to post an event on the TrayIcon appContext, but the TrayIcon was already removed by the test, causing an error. The fix is to make SunToolkit skip posting the event if appContext is null. The test is also updated to remove applet usage and use PassFailJFrame instead. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > removed extra newlines, moved test out of folder test/jdk/java/awt/TrayIcon/ShowAfterDisposeTest.java line 1: > 1: /* I am for keeping the original location of the file to preserve its history. New tests use the flat layout, the old tests (usually) are left at their original location. If you move tests to the flat layout, I would prefer doing it without any additional changes to the test themselves. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17329#discussion_r1452724666 From aivanov at openjdk.org Mon Jan 15 22:34:22 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 15 Jan 2024 22:34:22 GMT Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination [v9] In-Reply-To: <2N2LTQWDWIXcKiHYD-adxUpwq49-GN-YwE88LhB-LrU=.543ae6c1-624d-481b-9e70-3df93b5c3d79@github.com> References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> <2N2LTQWDWIXcKiHYD-adxUpwq49-GN-YwE88LhB-LrU=.543ae6c1-624d-481b-9e70-3df93b5c3d79@github.com> Message-ID: On Tue, 19 Dec 2023 02:09:08 GMT, songpv-imt wrote: >> The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method. >> >> JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287) > > songpv-imt has updated the pull request incrementally with one additional commit since the last revision: > > Update InterJVMGetDropSuccessTest.java > - Update success1 and success2 to volatile Changes requested by aivanov (Reviewer). test/jdk/java/awt/dnd/InterJVMGetDropSuccessTest/InterJVMGetDropSuccessTest.java line 1: > 1: /* GitHub doesn't allow leaving comments to unmodified lines therefore I'm leaving a file comment: 1. Please organise imports: use per-class imports instead of wildcard imports. 2. Use Java-style array declaration for `successCodes` and declare it as `final` to resolve IDE warnings. 3. Remove unused `successCodes` field and `reset` method. 4. Remove unused `pointInComponent` and `pointInComponentImpl` methods. ------------- PR Review: https://git.openjdk.org/jdk/pull/16396#pullrequestreview-1822311145 PR Review Comment: https://git.openjdk.org/jdk/pull/16396#discussion_r1452779145 From rkannathpari at openjdk.org Tue Jan 16 04:21:48 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 16 Jan 2024 04:21:48 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v15] In-Reply-To: References: Message-ID: > Hi Reviewers, > There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. > > Renjith. Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Updated the code with latest suggestion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16895/files - new: https://git.openjdk.org/jdk/pull/16895/files/bec09a31..895de12f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=13-14 Stats: 10 lines in 1 file changed: 0 ins; 6 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16895.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16895/head:pull/16895 PR: https://git.openjdk.org/jdk/pull/16895 From tr at openjdk.org Tue Jan 16 05:33:23 2024 From: tr at openjdk.org (Tejesh R) Date: Tue, 16 Jan 2024 05:33:23 GMT Subject: RFR: 8259550: The content of the print out displayed incomplete with the NimbusLAF In-Reply-To: References: Message-ID: On Fri, 12 Jan 2024 21:13:33 GMT, Damon Nguyen wrote: > Is there anything else that needs changing other than in SynthTableUI.java? Or any missing configuration on my end? Not any specific configuration is required, just can print it on a pdf for testing and see that few of the last column cells wont be printed without the fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17053#issuecomment-1893095899 From tr at openjdk.org Tue Jan 16 05:58:45 2024 From: tr at openjdk.org (Tejesh R) Date: Tue, 16 Jan 2024 05:58:45 GMT Subject: RFR: 8295804: javax/swing/JFileChooser/JFileChooserSetLocationTest.java failed with "setLocation() is not working properly" [v4] In-Reply-To: References: Message-ID: > The issue is that the doc area (in respect to the screen height which is 768px) which is at the bottom was causing the `JFileChooser `to be placed slightly above the set location. Was able to reproduce in local machine with reference to the failure image provided in the CI logs. The suggested fix is to place the main Frame slightly above the center of the screen than setting at the center of the screen. Several CI runs were made and no issue found. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Review fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17364/files - new: https://git.openjdk.org/jdk/pull/17364/files/e8dfd6b7..06188daa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17364&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17364&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17364.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17364/head:pull/17364 PR: https://git.openjdk.org/jdk/pull/17364 From tr at openjdk.org Tue Jan 16 05:58:47 2024 From: tr at openjdk.org (Tejesh R) Date: Tue, 16 Jan 2024 05:58:47 GMT Subject: RFR: 8295804: javax/swing/JFileChooser/JFileChooserSetLocationTest.java failed with "setLocation() is not working properly" [v3] In-Reply-To: <-LrBPbYLxXGwBVgKvkTNjp3S45nXjY-M7bLTBjxhP48=.4922adeb-0f04-41a9-8bd2-80e3f5463306@github.com> References: <-LrBPbYLxXGwBVgKvkTNjp3S45nXjY-M7bLTBjxhP48=.4922adeb-0f04-41a9-8bd2-80e3f5463306@github.com> Message-ID: On Sat, 13 Jan 2024 05:06:10 GMT, Sergey Bylokhov wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Review fix > > test/jdk/javax/swing/JFileChooser/JFileChooserSetLocationTest.java line 216: > >> 214: >> 215: int width = (int) screenSize.getWidth() / 2; >> 216: int height = (int) screenSize.getHeight() / 2; > > This is not the width and height, this is the kind of point(x,y) where the frame will be located. Yeah, I got it now. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17364#discussion_r1452956890 From jwaters at openjdk.org Tue Jan 16 06:26:58 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 16 Jan 2024 06:26:58 GMT Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v26] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> <4XtsPdwNattIdWDDPwNFl5uWX_GDIoVQurOK8_gp5hE=.12c78269-70d1-4a2e-9b9b-d62c8abe359d@github.com> Message-ID: On Thu, 16 Nov 2023 03:44:53 GMT, Phil Race wrote: >> I happened to ask around on the build-dev mailing lists about whether we include msvcp.dll with the JDK, here is Erik's response: >> >>> Back in JDK 8 when we used Visual Studio 2010, we used to not ship >>> msvcp*.dll. This changed when I added support for building with Visual >>> Studio 2013 [1] in JDK 9. In the patch for that bug I found this text: >>> >>>+ # If building with Visual Studio 2010, we can still use >>> _STATIC_CPPLIB to >>>+ # avoid bundling msvcpNNN.dll. Doesn't work with newer versions of >>> visual >>>+ # studio. >>> >>> So since we switched to Visual Studio 2013, we started to bundle >>> msvcp*.dll. It was only ever possible to not bundle it if you built with >>> Visual Studio 2010 (or older I suppose). It's pretty safe to say that >>> the current mainline JDK build requires msvcp.dll to be bundled. Looking >>> at the configure logic, configure will fail unless we find it and the >>> copying in open/make/modules/java.base/Copy.gmk is unconditional. >>> >>> /Erik >>> >>> [1] https://bugs.openjdk.org/browse/JDK-8042707 >> >> This may be unrelated, but I really think we should kill the std::bad_alloc hack in awt.dll as such > >> I happened to ask around on the build-dev mailing lists about whether we include msvcp.dll with the JDK, here is Erik's response: > > Yes, I saw that. It doesn't make any difference. > Although BTW the comment points out we shouldn't be doing static linking anymore. > > >> This may be unrelated, but I really think we should kill the std::bad_alloc hack in awt.dll as such > > seems unrelated, yes, but I'd have to look at that, to see if there's a reason to touch it. Itchy fingers are not a valid reason. @prrace ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1893138028 From duke at openjdk.org Tue Jan 16 10:52:34 2024 From: duke at openjdk.org (songpv-imt) Date: Tue, 16 Jan 2024 10:52:34 GMT Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination [v10] In-Reply-To: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> Message-ID: > The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method. > > JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287) songpv-imt has updated the pull request incrementally with one additional commit since the last revision: Update InterJVMGetDropSuccessTest.java - Remove robot.setWaitForIdle(true) and add robot.waitForIdle() after mouseMove - Change FRAME_ACTIVATION_TIMEOUT to 1000 - Remove unused pointInComponent and pointInComponentImpl methods - Use Java-style array declaration for successCodes - Use per-class imports instead of wildcard imports ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16396/files - new: https://git.openjdk.org/jdk/pull/16396/files/83ad763b..16a1ec70 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16396&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16396&range=08-09 Stats: 66 lines in 1 file changed: 23 ins; 33 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/16396.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16396/head:pull/16396 PR: https://git.openjdk.org/jdk/pull/16396 From aivanov at openjdk.org Tue Jan 16 12:51:23 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 16 Jan 2024 12:51:23 GMT Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination [v10] In-Reply-To: References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> Message-ID: On Tue, 16 Jan 2024 10:52:34 GMT, songpv-imt wrote: >> The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method. >> >> JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287) > > songpv-imt has updated the pull request incrementally with one additional commit since the last revision: > > Update InterJVMGetDropSuccessTest.java > - Remove robot.setWaitForIdle(true) and add robot.waitForIdle() after mouseMove > - Change FRAME_ACTIVATION_TIMEOUT to 1000 > - Remove unused pointInComponent and pointInComponentImpl methods > - Use Java-style array declaration for successCodes > - Use per-class imports instead of wildcard imports Changes requested by aivanov (Reviewer). test/jdk/java/awt/dnd/InterJVMGetDropSuccessTest/InterJVMGetDropSuccessTest.java line 1: > 1: /* You missed two spots that I talked about: @@ -89,7 +68,9 @@ public void start() { frame.setVisible(true); try { - Thread.sleep(Util.FRAME_ACTIVATION_TIMEOUT); + Robot robot = new Robot(); + robot.waitForIdle(); + robot.delay(Util.FRAME_ACTIVATION_TIMEOUT); Point p = frame.getLocationOnScreen(); Dimension d = frame.getSize(); @@ -250,13 +230,14 @@ public void run(String[] args) { frame.setBounds(300, 200, 150, 150); frame.setVisible(true); - Thread.sleep(Util.FRAME_ACTIVATION_TIMEOUT); + Robot robot = new Robot(); + robot.waitForIdle(); + robot.delay(Util.FRAME_ACTIVATION_TIMEOUT); Point sourcePoint = Util.getCenterLocationOnScreen(frame); Point targetPoint = new Point(x + w / 2, y + h / 2); - Robot robot = new Robot(); robot.mouseMove(sourcePoint.x, sourcePoint.y); robot.waitForIdle(); robot.delay(50); --- `MOUSE_RELEASE_TIMEOUT` is still present in the test but it's unused. test/jdk/java/awt/dnd/InterJVMGetDropSuccessTest/InterJVMGetDropSuccessTest.java line 57: > 55: import java.awt.dnd.DragGestureEvent; > 56: import java.io.File; > 57: import java.io.InputStream; The imports are sorted alphabetically, to make it easier for you, this is how my IDE organises imports: ```suggestion import java.awt.Frame; import java.awt.Component; import java.awt.Point; import java.awt.Dimension; import java.awt.EventQueue; import java.awt.Toolkit; import java.awt.AWTEvent; import java.awt.Robot; import java.awt.event.AWTEventListener; import java.awt.event.InputEvent; import java.awt.event.MouseEvent; import java.awt.datatransfer.StringSelection; import java.awt.datatransfer.Transferable; import java.awt.dnd.DropTarget; import java.awt.dnd.DragGestureListener; import java.awt.dnd.DragSourceAdapter; import java.awt.dnd.DragSourceDropEvent; import java.awt.dnd.DnDConstants; import java.awt.dnd.DropTargetDropEvent; import java.awt.dnd.DropTargetAdapter; import java.awt.dnd.DragGestureRecognizer; import java.awt.dnd.DragSource; import java.awt.dnd.DropTargetListener; import java.awt.dnd.DragGestureEvent; import java.io.File; import java.io.InputStream; test/jdk/java/awt/dnd/InterJVMGetDropSuccessTest/InterJVMGetDropSuccessTest.java line 62: > 60: > 61: private int returnCode = Util.CODE_NOT_RETURNED; > 62: private final boolean successCodes[] = new boolean[]{ true, false }; Suggestion: private final boolean[] successCodes = { true, false }; Use Java-style array declaration; it means the brackets are with the type `boolean[]` rather than the field/variable name. ------------- PR Review: https://git.openjdk.org/jdk/pull/16396#pullrequestreview-1823245946 PR Review Comment: https://git.openjdk.org/jdk/pull/16396#discussion_r1453379932 PR Review Comment: https://git.openjdk.org/jdk/pull/16396#discussion_r1453377254 PR Review Comment: https://git.openjdk.org/jdk/pull/16396#discussion_r1453375260 From aivanov at openjdk.org Tue Jan 16 12:51:25 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 16 Jan 2024 12:51:25 GMT Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination [v10] In-Reply-To: References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> Message-ID: <7H3RywGpUEOBiT_ZkTRfR5Oul8mivTp_qKdAKhshKW4=.d006aa0e-321d-4ca3-9d73-64494c34b382@github.com> On Tue, 16 Jan 2024 12:46:30 GMT, Alexey Ivanov wrote: >> songpv-imt has updated the pull request incrementally with one additional commit since the last revision: >> >> Update InterJVMGetDropSuccessTest.java >> - Remove robot.setWaitForIdle(true) and add robot.waitForIdle() after mouseMove >> - Change FRAME_ACTIVATION_TIMEOUT to 1000 >> - Remove unused pointInComponent and pointInComponentImpl methods >> - Use Java-style array declaration for successCodes >> - Use per-class imports instead of wildcard imports > > test/jdk/java/awt/dnd/InterJVMGetDropSuccessTest/InterJVMGetDropSuccessTest.java line 1: > >> 1: /* > > You missed two spots that I talked about: > > > @@ -89,7 +68,9 @@ public void start() { > frame.setVisible(true); > > try { > - Thread.sleep(Util.FRAME_ACTIVATION_TIMEOUT); > + Robot robot = new Robot(); > + robot.waitForIdle(); > + robot.delay(Util.FRAME_ACTIVATION_TIMEOUT); > > Point p = frame.getLocationOnScreen(); > Dimension d = frame.getSize(); > @@ -250,13 +230,14 @@ public void run(String[] args) { > frame.setBounds(300, 200, 150, 150); > frame.setVisible(true); > > - Thread.sleep(Util.FRAME_ACTIVATION_TIMEOUT); > + Robot robot = new Robot(); > + robot.waitForIdle(); > + robot.delay(Util.FRAME_ACTIVATION_TIMEOUT); > > Point sourcePoint = Util.getCenterLocationOnScreen(frame); > > Point targetPoint = new Point(x + w / 2, y + h / 2); > > - Robot robot = new Robot(); > robot.mouseMove(sourcePoint.x, sourcePoint.y); > robot.waitForIdle(); > robot.delay(50); > > > --- > > `MOUSE_RELEASE_TIMEOUT` is still present in the test but it's unused. In addition to this, I propose removing `robot.delay(50);` from the for-loops, or at least reducing this value, let's say, to 5. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16396#discussion_r1453381385 From aivanov at openjdk.org Tue Jan 16 13:30:26 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 16 Jan 2024 13:30:26 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v4] In-Reply-To: References: Message-ID: <77ss7H_hje0Hww37XHsD1DGLgeoAqTVpO1hmFeZARnE=.2c4ea2c4-137a-4fba-b1c8-5753dea74f97@github.com> On Fri, 12 Jan 2024 22:18:04 GMT, Alisen Chung wrote: >> SunToolkit.java is trying to post an event on the TrayIcon appContext, but the TrayIcon was already removed by the test, causing an error. The fix is to make SunToolkit skip posting the event if appContext is null. The test is also updated to remove applet usage and use PassFailJFrame instead. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > used jtreg.SkippedException, updated copyright years test/jdk/java/awt/TrayIcon/ShowAfterDisposeTest.java line 77: > 75: .build(); > 76: showFrameAndIcon(); > 77: passFailJFrame.awaitAndCheck(); May I suggest simplifying it even further? Suggestion: PassFailJFrame.builder() .title("Test Instructions Frame") .instructions(instructions) .testTimeOut(10) .rows(10) .columns(45) .testUI(ShowAfterDisposeTest::showFrameAndIcon) .build() .awaitAndCheck(); where `showFrameAndIcon` is modified like this: private static JFrame showFrameAndIcon() { JFrame frame = new JFrame("ShowAfterDisposeTest"); frame.setLayout(new BorderLayout()); // Rest of the code and no `invokeAndWait` // You'll have to add a try block around `tray.add(icon)` to catch and // wrap AWTException into RuntimeException. return frame; } Essentially, the additional frame is not required at all, it can be dropped but I haven't explored it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17329#discussion_r1453427141 From aivanov at openjdk.org Tue Jan 16 14:26:26 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 16 Jan 2024 14:26:26 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v15] In-Reply-To: References: Message-ID: On Tue, 16 Jan 2024 04:21:48 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. >> >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Updated the code with latest suggestion Looks good to me, except for a minor nit. ------------- PR Review: https://git.openjdk.org/jdk/pull/16895#pullrequestreview-1823557429 From aivanov at openjdk.org Tue Jan 16 14:26:30 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 16 Jan 2024 14:26:30 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v7] In-Reply-To: <_gm-Utdk0aGY3B2jkYv58Tqj--Hm_nyDLmGDl5S7nWA=.f701d994-c052-496d-b5fa-9fc3d4f08bf6@github.com> References: <_gm-Utdk0aGY3B2jkYv58Tqj--Hm_nyDLmGDl5S7nWA=.f701d994-c052-496d-b5fa-9fc3d4f08bf6@github.com> Message-ID: On Wed, 3 Jan 2024 19:21:47 GMT, Alexey Ivanov wrote: >> Renjith Kannath Pariyangad has updated the pull request incrementally with two additional commits since the last revision: >> >> - Copyright year updated >> - Review suggestions implemented > > test/jdk/java/awt/color/NonICCFilterTest.java line 38: > >> 36: * @test >> 37: * @bug 8316497 >> 38: * @summary Verifies Color filter on Non ICC profile > > Suggestion: > > * @summary Verifies Color filter on non-ICC profile Let's bring back this change: _non-ICC_ instead of _Non ICC_. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1453500039 From aivanov at openjdk.org Tue Jan 16 14:44:22 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 16 Jan 2024 14:44:22 GMT Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination [v10] In-Reply-To: <7H3RywGpUEOBiT_ZkTRfR5Oul8mivTp_qKdAKhshKW4=.d006aa0e-321d-4ca3-9d73-64494c34b382@github.com> References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> <7H3RywGpUEOBiT_ZkTRfR5Oul8mivTp_qKdAKhshKW4=.d006aa0e-321d-4ca3-9d73-64494c34b382@github.com> Message-ID: On Tue, 16 Jan 2024 12:47:50 GMT, Alexey Ivanov wrote: > In addition to this, I propose removing `robot.delay(50);` from the for-loops, or at least reducing this value, let's say, to 5. The test is unstable without a delay inside the for-loop. `robot.delay(5)` does the trick. The test passes successfully with 50 repeats. The above changes make the test significantly quicker. - Original version takes **25 minutes** for 50 repeats; - Yesterday's version ? 30 minutes; - Today's version ? 22 minutes; - With `delay(5)` ? **7 minutes**; - ~~No delay ? 5 minutes (*unstable*)~~. Thus, the modified version with `robot.delay(5)` instead of `robot.delay(50)` completes nearly twice as quick compared to the original test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16396#discussion_r1453527575 From rkannathpari at openjdk.org Tue Jan 16 15:41:50 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 16 Jan 2024 15:41:50 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v16] In-Reply-To: References: Message-ID: > Hi Reviewers, > There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. > > Renjith. Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Fixed small typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16895/files - new: https://git.openjdk.org/jdk/pull/16895/files/895de12f..c0ac3b03 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=14-15 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16895.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16895/head:pull/16895 PR: https://git.openjdk.org/jdk/pull/16895 From aivanov at openjdk.org Tue Jan 16 15:48:25 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 16 Jan 2024 15:48:25 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix [v16] In-Reply-To: References: Message-ID: On Tue, 16 Jan 2024 15:41:50 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. >> >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Fixed small typo Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16895#pullrequestreview-1823846459 From duke at openjdk.org Tue Jan 16 17:29:50 2024 From: duke at openjdk.org (songpv-imt) Date: Tue, 16 Jan 2024 17:29:50 GMT Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination [v11] In-Reply-To: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> Message-ID: > The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method. > > JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287) songpv-imt has updated the pull request incrementally with one additional commit since the last revision: Update InterJVMGetDropSuccessTest.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16396/files - new: https://git.openjdk.org/jdk/pull/16396/files/16a1ec70..51c97fb1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16396&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16396&range=09-10 Stats: 33 lines in 1 file changed: 9 ins; 11 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/16396.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16396/head:pull/16396 PR: https://git.openjdk.org/jdk/pull/16396 From duke at openjdk.org Tue Jan 16 17:29:52 2024 From: duke at openjdk.org (songpv-imt) Date: Tue, 16 Jan 2024 17:29:52 GMT Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination [v10] In-Reply-To: References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> <7H3RywGpUEOBiT_ZkTRfR5Oul8mivTp_qKdAKhshKW4=.d006aa0e-321d-4ca3-9d73-64494c34b382@github.com> Message-ID: On Tue, 16 Jan 2024 14:42:07 GMT, Alexey Ivanov wrote: >> In addition to this, I propose removing `robot.delay(50);` from the for-loops, or at least reducing this value, let's say, to 5. > >> In addition to this, I propose removing `robot.delay(50);` from the for-loops, or at least reducing this value, let's say, to 5. > > The test is unstable without a delay inside the for-loop. > > `robot.delay(5)` does the trick. The test passes successfully with 50 repeats. > > The above changes make the test significantly quicker. > > - Original version takes **25 minutes** for 50 repeats; > - Yesterday's version ? 30 minutes; > - Today's version ? 22 minutes; > - With `delay(5)` ? **7 minutes**; > - ~~No delay ? 5 minutes (*unstable*)~~. > > Thus, the modified version with `robot.delay(5)` instead of `robot.delay(50)` completes nearly twice as quick compared to the original test. Thank you, the code has been updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16396#discussion_r1453747130 From aivanov at openjdk.org Tue Jan 16 17:51:27 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 16 Jan 2024 17:51:27 GMT Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination [v11] In-Reply-To: References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> Message-ID: On Tue, 16 Jan 2024 17:29:50 GMT, songpv-imt wrote: >> The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method. >> >> JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287) > > songpv-imt has updated the pull request incrementally with one additional commit since the last revision: > > Update InterJVMGetDropSuccessTest.java Marked as reviewed by aivanov (Reviewer). test/jdk/java/awt/dnd/InterJVMGetDropSuccessTest/InterJVMGetDropSuccessTest.java line 143: > 141: static final Object SYNC_LOCK = new Object(); > 142: static final int MOUSE_RELEASE_TIMEOUT = 1000; > 143: I'd rather preserve these blank lines because they separate blocks of fields: exit codes, timeout, sync object. ------------- PR Review: https://git.openjdk.org/jdk/pull/16396#pullrequestreview-1824415165 PR Review Comment: https://git.openjdk.org/jdk/pull/16396#discussion_r1453768811 From honkar at openjdk.org Tue Jan 16 18:03:24 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 16 Jan 2024 18:03:24 GMT Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination [v11] In-Reply-To: References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> Message-ID: On Tue, 16 Jan 2024 17:29:50 GMT, songpv-imt wrote: >> The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method. >> >> JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287) > > songpv-imt has updated the pull request incrementally with one additional commit since the last revision: > > Update InterJVMGetDropSuccessTest.java Ran the updated test on macOS 13 and 14.2, it works well with the stabilization fix done for macOS 14.1. Changes look good. ------------- Marked as reviewed by honkar (Committer). PR Review: https://git.openjdk.org/jdk/pull/16396#pullrequestreview-1824464083 From aivanov at openjdk.org Tue Jan 16 18:03:25 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 16 Jan 2024 18:03:25 GMT Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination [v11] In-Reply-To: References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> Message-ID: On Tue, 16 Jan 2024 17:58:37 GMT, Harshitha Onkar wrote: > Ran the updated test on macOS 13 and 14.2, it works well with the stabilization fix done for macOS 14.1. Changes look good. I ran a job with 50 repeats of the test in our CI, the test passes. I've submitted a new job, just in a case, with the most recent changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16396#issuecomment-1894241361 From duke at openjdk.org Tue Jan 16 18:39:49 2024 From: duke at openjdk.org (songpv-imt) Date: Tue, 16 Jan 2024 18:39:49 GMT Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination [v12] In-Reply-To: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> Message-ID: > The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method. > > JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287) songpv-imt has updated the pull request incrementally with one additional commit since the last revision: Update InterJVMGetDropSuccessTest.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16396/files - new: https://git.openjdk.org/jdk/pull/16396/files/51c97fb1..46bb7901 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16396&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16396&range=10-11 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16396.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16396/head:pull/16396 PR: https://git.openjdk.org/jdk/pull/16396 From duke at openjdk.org Tue Jan 16 18:54:42 2024 From: duke at openjdk.org (songpv-imt) Date: Tue, 16 Jan 2024 18:54:42 GMT Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination [v13] In-Reply-To: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> Message-ID: > The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method. > > JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287) songpv-imt has updated the pull request incrementally with one additional commit since the last revision: Update InterJVMGetDropSuccessTest.java - Fix whitespace errors ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16396/files - new: https://git.openjdk.org/jdk/pull/16396/files/46bb7901..2bd0e22b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16396&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16396&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16396.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16396/head:pull/16396 PR: https://git.openjdk.org/jdk/pull/16396 From aivanov at openjdk.org Tue Jan 16 20:39:55 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 16 Jan 2024 20:39:55 GMT Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination [v13] In-Reply-To: References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> Message-ID: <4GLSuVII3hOAamKc6cAI091CoKS2KX9s2nHwtTc4TPE=.3b9610de-fb7d-46c0-b28c-114efcfe4326@github.com> On Tue, 16 Jan 2024 18:54:42 GMT, songpv-imt wrote: >> The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method. >> >> JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287) > > songpv-imt has updated the pull request incrementally with one additional commit since the last revision: > > Update InterJVMGetDropSuccessTest.java > - Fix whitespace errors test/jdk/java/awt/dnd/InterJVMGetDropSuccessTest/InterJVMGetDropSuccessTest.java line 164: > 162: > 163: static final Object SYNC_LOCK = new Object(); > 164: static final Util theInstance = new Util(); Could you please add the blank lines as they were so that this piece of code looks like this: public static final int CODE_FIRST_SUCCESS = 0x2; public static final int CODE_SECOND_SUCCESS = 0x2; public static final int CODE_FAILURE = 0x1; public static final int FRAME_ACTIVATION_TIMEOUT = 1000; static final Object SYNC_LOCK = new Object(); static final Util theInstance = new Util(); With blank lines separating logical blocks of fields. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16396#discussion_r1454000543 From prr at openjdk.org Tue Jan 16 20:56:49 2024 From: prr at openjdk.org (Phil Race) Date: Tue, 16 Jan 2024 20:56:49 GMT Subject: RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations In-Reply-To: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> References: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> Message-ID: On Fri, 12 Jan 2024 17:47:23 GMT, Christoph Langer wrote: > Maybe the usual control flow would call the wrapping native method DWMIsCompositionEnabled() from somewhere else initially such that the initialization of Win32GraphicsEnvironment would not go through initScreens or similar. I have not worked out how this can actually happen. I've built JDK in fast-debug mode and added java.awt.headless=true and added a bunch of printfs to be sure the code is going where I think it is but I can't make this test fail. I am running my current tests locally on Windows 11, but our CI testing does run this on Windows Server (various versions, 2016, 2019 and 2022) The only way I can make this fail is to ACTUALLY add a 2nd JNI call in there - I was beginning to wonder if somehow we were missing the WARNING, but in fact that is working. So your code path is different but what is the exact reason ? That is what we should understand. Maybe it will be 'ho hum, now I see' or maybe it will point to something we need to address. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17404#issuecomment-1894497216 From prr at openjdk.org Tue Jan 16 21:41:51 2024 From: prr at openjdk.org (Phil Race) Date: Tue, 16 Jan 2024 21:41:51 GMT Subject: RFR: 8323554: The typos in Javadoc: "@return if " In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 21:35:56 GMT, Sergey Bylokhov wrote: > The docs for the boolean methods are updated from this style: > > @return if the event has been consumed > > to this one > > @return {@code true} if the event has been consumed, otherwise > {@code false} > > plus small cleanups here and there. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17357#pullrequestreview-1825200634 From prr at openjdk.org Tue Jan 16 21:55:51 2024 From: prr at openjdk.org (Phil Race) Date: Tue, 16 Jan 2024 21:55:51 GMT Subject: RFR: JDK-8323695 RenderPerf (2D) enhancements (23.12) In-Reply-To: <13rvTg4QWBKawohFsLhUv8n_7j5xhbcJzTm1IpZQtMo=.2fc70458-f4a1-41ab-bb4b-8e4f49db0148@github.com> References: <13rvTg4QWBKawohFsLhUv8n_7j5xhbcJzTm1IpZQtMo=.2fc70458-f4a1-41ab-bb4b-8e4f49db0148@github.com> Message-ID: <9f_Ek67AqpjSx-dGyKQD61-vhTTNXD5zi9BilQAt04Y=.c7679726-54b8-4e35-a486-7f876564ed1f@github.com> On Fri, 12 Jan 2024 21:34:32 GMT, Laurent Bourg?s wrote: > - new executor modes (buffer & volatile) > - support parallel rendering on several frames and / or screens > - added robot calibration + optionally use rounded duration to min frame latency (120Hz) > - give more statistics in verbose (-v) > - added new command-line arguments > - added version + help information test/jdk/performance/client/RenderPerfTest/src/renderperf/RenderPerfTest.java line 204: > 202: enabled ? RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB > 203: : RenderingHints.VALUE_TEXT_ANTIALIAS_DEFAULT); > 204: } Although it makes no practical difference, I am wondering why in this case, enabled==false sets "DEFAULT" and in the case above it sets "OFF" ? test/jdk/performance/client/RenderPerfTest/src/renderperf/RenderPerfTest.java line 460: > 458: if (id % 100 != 0) return; > 459: if (font == null) { > 460: font = new Font("LucidaGrande", Font.PLAIN, 32); I see this is pre-existing, but we should change this. That's a font available only on macOS. You should either look up a font to use on the system at run time, or use a logical font. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17408#discussion_r1454084838 PR Review Comment: https://git.openjdk.org/jdk/pull/17408#discussion_r1454088478 From achung at openjdk.org Tue Jan 16 21:56:51 2024 From: achung at openjdk.org (Alisen Chung) Date: Tue, 16 Jan 2024 21:56:51 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v5] In-Reply-To: References: Message-ID: > SunToolkit.java is trying to post an event on the TrayIcon appContext, but the TrayIcon was already removed by the test, causing an error. The fix is to make SunToolkit skip posting the event if appContext is null. The test is also updated to remove applet usage and use PassFailJFrame instead. Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: added suggested changes, moved test back into folder ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17329/files - new: https://git.openjdk.org/jdk/pull/17329/files/1ec7943a..36ce7e1b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17329&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17329&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17329.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17329/head:pull/17329 PR: https://git.openjdk.org/jdk/pull/17329 From dnguyen at openjdk.org Tue Jan 16 21:56:55 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 16 Jan 2024 21:56:55 GMT Subject: RFR: JDK-8320113: [macos14] : ShapeNotSetSometimes.java fails intermittently on macOS 14 [v2] In-Reply-To: <-XwORy2eQahQ3dyJWrE20h41kdSMFNbyHQ9FGZ0z2aA=.4596d9dd-b4da-4ff1-bae5-508fa4bae37b@github.com> References: <-XwORy2eQahQ3dyJWrE20h41kdSMFNbyHQ9FGZ0z2aA=.4596d9dd-b4da-4ff1-bae5-508fa4bae37b@github.com> Message-ID: On Fri, 12 Jan 2024 20:21:52 GMT, Harshitha Onkar wrote: >> ShapeNotSetSometimes.java fails intermittently on macOS 14. Following is a test stabilization fix for macOS 14. With the added delays ShapeNotSetSometimes.java passes on older versions of macOS as well as on macOS 14.1, 14.2. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > test stabilization fix Tested the updated test changes. Still working as expected with 0 fails. Can I get some insight for the numOfFailedAttempts count being more or less than 3? Why is 3 significant? ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/17180#pullrequestreview-1825274417 From prr at openjdk.org Tue Jan 16 21:58:49 2024 From: prr at openjdk.org (Phil Race) Date: Tue, 16 Jan 2024 21:58:49 GMT Subject: RFR: 8318112: CSS percentage values are capped at 100% In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 09:19:20 GMT, Prasanta Sadhukhan wrote: > Java CSS where values can be displayed in percent are capped at 100% so "width: 200%" and "width: 100%" are equal, which is incorrect. > FIx is made to make sure parsing is not capped at 100% I hope no one is relying on this bug. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17299#pullrequestreview-1825286439 From prr at openjdk.org Tue Jan 16 21:59:57 2024 From: prr at openjdk.org (Phil Race) Date: Tue, 16 Jan 2024 21:59:57 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v2] In-Reply-To: References: Message-ID: On Thu, 28 Sep 2023 06:14:45 GMT, ScientificWare wrote: >> ScientificWare has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/java.desktop/share/classes/javax/swing/text/html/FormView.java >> >> FormView.java : Remove a redundant space. >> >> Co-authored-by: Andrey Turbanov > > Waiting for a review. @scientificware - are you still working on this ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15319#issuecomment-1894580771 From clanger at openjdk.org Tue Jan 16 22:05:53 2024 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 16 Jan 2024 22:05:53 GMT Subject: RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations In-Reply-To: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> References: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> Message-ID: On Fri, 12 Jan 2024 17:47:23 GMT, Christoph Langer wrote: > This picks up fixing the issue of [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) again. A fix had been integrated with #17224 but @prrace had concerns and so it was backed out. > > I have now spent quite some thoughts into the problem and end up with the [initial commit](https://github.com/openjdk/jdk/pull/6306/commits/5d18a76cb967e9ede6394cbd6c28bb61facf785c) of #6306 as the most elegant and least intrusive solution. > > Why is this? > > The JNI warning we observe in the test is: > `[WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV > at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 22.0.1-internal/Native Method) > at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:95) > at sun.awt.Win32GraphicsEnvironment.(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:63) > ... > at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) > at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)` > > This happens because obviously the test FreeTypeScalerJNICheck runs with `-Xcheck:jni` and in the scenario where we're observing the warning, a missing exception check for the JNI call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged` at awt_Win32GraphicsEnv.cpp#L129 > https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L129 is airing up. Omitting the exception check would not be a problem if it could be guaranteed that after this call no other JNI->Java call was being made. But seemingly in this very particular configuration on some of our Windows servers, there must be JNI->Java calls that follow the call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged`, likely from the subsequent call to [initScreens](https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L149) in `sun.awt.Win32GraphicsEnvironment::initDisplay`. https://github.com/openjdk/jdk/blob/8b6293f6bfb7b7628c6604e6c44401fc96d85cf4/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L141 Maybe the usual control flow would call the wrapping native method `DWMIsCompositi onEnabled()` from somewhere else initially such that the initialization of `Win32GraphicsEnvironment` would not go through `initScreens` or similar. > ... The test is only failing on a few boxes in our CI infrastructure. And also only in the setup of the nightly tests, not if one would connect to the box and run the test there standalone. But I'll try to run the tests with some more instrumentation to get a better understanding. Stay tuned... ------------- PR Comment: https://git.openjdk.org/jdk/pull/17404#issuecomment-1894592669 From achung at openjdk.org Tue Jan 16 22:11:19 2024 From: achung at openjdk.org (Alisen Chung) Date: Tue, 16 Jan 2024 22:11:19 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v6] In-Reply-To: References: Message-ID: > SunToolkit.java is trying to post an event on the TrayIcon appContext, but the TrayIcon was already removed by the test, causing an error. The fix is to make SunToolkit skip posting the event if appContext is null. The test is also updated to remove applet usage and use PassFailJFrame instead. Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: added suggested changes, moved test back into folder ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17329/files - new: https://git.openjdk.org/jdk/pull/17329/files/36ce7e1b..a9693565 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17329&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17329&range=04-05 Stats: 26 lines in 1 file changed: 7 ins; 9 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/17329.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17329/head:pull/17329 PR: https://git.openjdk.org/jdk/pull/17329 From honkar at openjdk.org Tue Jan 16 22:13:49 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 16 Jan 2024 22:13:49 GMT Subject: RFR: JDK-8320113: [macos14] : ShapeNotSetSometimes.java fails intermittently on macOS 14 [v2] In-Reply-To: References: <-XwORy2eQahQ3dyJWrE20h41kdSMFNbyHQ9FGZ0z2aA=.4596d9dd-b4da-4ff1-bae5-508fa4bae37b@github.com> Message-ID: On Tue, 16 Jan 2024 21:53:53 GMT, Damon Nguyen wrote: > Tested the updated test changes. Still working as expected with 0 fails. Can I get some insight for the numOfFailedAttempts count being more or less than 3? Why is 3 significant? As explained [here](https://github.com/openjdk/jdk/pull/17180#issuecomment-1889898329) earlier, I'm unable to reproduce the intermittent issue on CI testing (as before) but taking into account that this is an intermittent issue, I believe a 3/50 failed attempts is less strict and prevents the test to fail instantly due to glitches during any given attempt. A 5 or 10 failed attempts might be relaxing the constraint too much hence 3 was chosen. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17180#issuecomment-1894600119 From dnguyen at openjdk.org Tue Jan 16 22:40:59 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 16 Jan 2024 22:40:59 GMT Subject: RFR: 8318590: JButton ignores margin when painting HTML text [v5] In-Reply-To: <5LcDM9RyprALVI-ORxap7LCRQiNF3xtAHMqenYUKzXY=.0e733ade-053b-4210-895c-3bbceb4aefdd@github.com> References: <5LcDM9RyprALVI-ORxap7LCRQiNF3xtAHMqenYUKzXY=.0e733ade-053b-4210-895c-3bbceb4aefdd@github.com> Message-ID: On Tue, 5 Dec 2023 19:07:07 GMT, Damon Nguyen wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Re-add test because still valid > > I also have updated the copyright year for BasicButtonUI. I believe that's the only case of copyright years that needs to be updated. > Hi @DamonGuy, in the end, the test was deleted, although you added a commit re-adding it. Was this intended or a prank by GitHub? What Phil said is correct. The PR as shown right now is as intended. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16869#issuecomment-1894634811 From prr at openjdk.org Tue Jan 16 22:44:49 2024 From: prr at openjdk.org (Phil Race) Date: Tue, 16 Jan 2024 22:44:49 GMT Subject: RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations In-Reply-To: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> References: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> Message-ID: On Fri, 12 Jan 2024 17:47:23 GMT, Christoph Langer wrote: > This picks up fixing the issue of [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) again. A fix had been integrated with #17224 but @prrace had concerns and so it was backed out. > > I have now spent quite some thoughts into the problem and end up with the [initial commit](https://github.com/openjdk/jdk/pull/6306/commits/5d18a76cb967e9ede6394cbd6c28bb61facf785c) of #6306 as the most elegant and least intrusive solution. > > Why is this? > > The JNI warning we observe in the test is: > `[WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV > at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 22.0.1-internal/Native Method) > at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:95) > at sun.awt.Win32GraphicsEnvironment.(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:63) > ... > at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) > at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)` > > This happens because obviously the test FreeTypeScalerJNICheck runs with `-Xcheck:jni` and in the scenario where we're observing the warning, a missing exception check for the JNI call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged` at awt_Win32GraphicsEnv.cpp#L129 > https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L129 is airing up. Omitting the exception check would not be a problem if it could be guaranteed that after this call no other JNI->Java call was being made. But seemingly in this very particular configuration on some of our Windows servers, there must be JNI->Java calls that follow the call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged`, likely from the subsequent call to [initScreens](https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L149) in `sun.awt.Win32GraphicsEnvironment::initDisplay`. https://github.com/openjdk/jdk/blob/8b6293f6bfb7b7628c6604e6c44401fc96d85cf4/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L141 Maybe the usual control flow would call the wrapping native method `DWMIsCompositi onEnabled()` from somewhere else initially such that the initialization of `Win32GraphicsEnvironment` would not go through `initScreens` or similar. > ... Note that because the test is looking for the string WARNING, it captures all the output of the running VM into a log file, and jtreg will leave that log file there. So you should be able to add instrumentation (ie printf's) into the JDK itself to help understand the internal code flow, and let the test run in that CI environment and capture everything for your later inspection ------------- PR Comment: https://git.openjdk.org/jdk/pull/17404#issuecomment-1894638253 From serb at openjdk.org Wed Jan 17 00:28:59 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 17 Jan 2024 00:28:59 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v4] In-Reply-To: References: Message-ID: <00pjcBeEzOeDQ_FLh12p5daGx5e_Un2txgLlfzMBXBw=.23f90bc2-a6f2-4d4f-9ed2-bfaf177222eb@github.com> On Mon, 15 Jan 2024 11:33:31 GMT, Sergey Bylokhov wrote: >> src/java.desktop/share/classes/sun/awt/SunToolkit.java line 450: >> >>> 448: if (appContext == null) { >>> 449: return; >>> 450: } >> >> I think we should check why the appcontext is null here, the event comes from the native peer, so when the event was created the peer was there, if the peer exists the target should have an appconext as well. >> >> Maybe the problem is that we try to jump on EDT twice? First time from CTrayIcon.postEvent-> SunToolkit.executeOnEventHandlerThread and then one more time via SunToolkit.postEvent(). >> >> Can deletion of the executeOnEventHandlerThread solve the problem? > > Or maybe it is a lack of synchronization? So what is the root cause of null context here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17329#discussion_r1454251585 From dnguyen at openjdk.org Wed Jan 17 00:35:50 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 17 Jan 2024 00:35:50 GMT Subject: RFR: 8259550: The content of the print out displayed incomplete with the NimbusLAF In-Reply-To: References: Message-ID: On Mon, 11 Dec 2023 11:25:34 GMT, Tejesh R wrote: > The issue is w.r.t to way that Synth prints the table. In Synth, the printing of Table happens column wise by painting blocks of columns which is due to the fact that Graphics used which is `ProxyGrpahics2D` (which get selected in `RasterPrinterJob `class, otherwise it would be `WPathGraphics` for other Look and feel). Since the printing happens in block wise and the columns where the x position is greater than the `table.bounds` doesn't gets painted because of the intersection check condition `!bounds.intersects(clip)`. Hence only droplines are painted instead of cells and gridlines. I couldn't find any reason for adding the intersection check here and when removed it didn't cause any regression too, rather it solves the issue and actually made sense too. In other Look and Feel its not required to apply the fix (in `BasicTableUI `class) because its not affecting anything yet since the painting happens for whole table. Hence proposing the fix for only SynthTableUI class. > ([PrintManualTest_FitWidthMultiple.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java)) test is been used for testing. This was my output without the fix: Screenshot 2024-01-16 at 3 32 33?PM This was my output with the fix: Screenshot 2024-01-16 at 3 33 13?PM Comparing it to the description/example you gave on the difference, I can't seem to recreate that change. These screenshots were generated by using the ```Print``` option on the test and outputting to a PDF file. Any insights for why I'm not seeing the same thing? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17053#issuecomment-1894738624 From duke at openjdk.org Wed Jan 17 01:56:25 2024 From: duke at openjdk.org (songpv-imt) Date: Wed, 17 Jan 2024 01:56:25 GMT Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination [v14] In-Reply-To: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> Message-ID: > The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method. > > JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287) songpv-imt has updated the pull request incrementally with one additional commit since the last revision: Update InterJVMGetDropSuccessTest.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16396/files - new: https://git.openjdk.org/jdk/pull/16396/files/2bd0e22b..8d44f4c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16396&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16396&range=12-13 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16396.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16396/head:pull/16396 PR: https://git.openjdk.org/jdk/pull/16396 From psadhukhan at openjdk.org Wed Jan 17 02:32:00 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 17 Jan 2024 02:32:00 GMT Subject: Integrated: 8318112: CSS percentage values are capped at 100% In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 09:19:20 GMT, Prasanta Sadhukhan wrote: > Java CSS where values can be displayed in percent are capped at 100% so "width: 200%" and "width: 100%" are equal, which is incorrect. > FIx is made to make sure parsing is not capped at 100% This pull request has now been integrated. Changeset: f70667ea Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/f70667ea68a4e23391d45937cdaa66904f75b33d Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod 8318112: CSS percentage values are capped at 100% Reviewed-by: tr, prr ------------- PR: https://git.openjdk.org/jdk/pull/17299 From tr at openjdk.org Wed Jan 17 05:11:51 2024 From: tr at openjdk.org (Tejesh R) Date: Wed, 17 Jan 2024 05:11:51 GMT Subject: RFR: 8259550: The content of the print out displayed incomplete with the NimbusLAF In-Reply-To: References: Message-ID: <1NPZ_EyrnliJclG7mPKc54IhvD-IcajQCBi5s6Qarto=.ad720600-9866-46c6-b54a-d5cc1e426989@github.com> On Mon, 11 Dec 2023 11:25:34 GMT, Tejesh R wrote: > The issue is w.r.t to way that Synth prints the table. In Synth, the printing of Table happens column wise by painting blocks of columns which is due to the fact that Graphics used which is `ProxyGrpahics2D` (which get selected in `RasterPrinterJob `class, otherwise it would be `WPathGraphics` for other Look and feel). Since the printing happens in block wise and the columns where the x position is greater than the `table.bounds` doesn't gets painted because of the intersection check condition `!bounds.intersects(clip)`. Hence only droplines are painted instead of cells and gridlines. I couldn't find any reason for adding the intersection check here and when removed it didn't cause any regression too, rather it solves the issue and actually made sense too. In other Look and Feel its not required to apply the fix (in `BasicTableUI `class) because its not affecting anything yet since the painting happens for whole table. Hence proposing the fix for only SynthTableUI class. > ([PrintManualTest_FitWidthMultiple.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java)) test is been used for testing. > This was my output without the fix: Screenshot 2024-01-16 at 3 32 33?PM > > This was my output with the fix: Screenshot 2024-01-16 at 3 33 13?PM > > Comparing it to the description/example you gave on the difference, I can't seem to recreate that change. These screenshots were generated by using the `Print` option on the test and outputting to a PDF file. Any insights for why I'm not seeing the same thing? > This was my output without the fix: Screenshot 2024-01-16 at 3 32 33?PM > > This was my output with the fix: Screenshot 2024-01-16 at 3 33 13?PM > > Comparing it to the description/example you gave on the difference, I can't seem to recreate that change. These screenshots were generated by using the `Print` option on the test and outputting to a PDF file. Any insights for why I'm not seeing the same thing? I guess the frame size when you give to print is quite more enough for it to print all of the columns. The size of frame where the issue can be reproduced is around 720x730 px. Can you check the frame size before giving it to print. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17053#issuecomment-1894951054 From psadhukhan at openjdk.org Wed Jan 17 07:27:28 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 17 Jan 2024 07:27:28 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI Message-ID: When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak. When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500) FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method.. ------------- Commit messages: - 6507038: Memory Leak in JTree / BasicTreeUI Changes: https://git.openjdk.org/jdk/pull/17458/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17458&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6507038 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17458.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17458/head:pull/17458 PR: https://git.openjdk.org/jdk/pull/17458 From asemenov at openjdk.org Wed Jan 17 08:55:52 2024 From: asemenov at openjdk.org (Artem Semenov) Date: Wed, 17 Jan 2024 08:55:52 GMT Subject: RFR: 8317771 [macos14] Expand/collapse a JTree using keyboard freezes the application in macOS 14 Sonoma In-Reply-To: <7kSAuBxx0uNV2pNBUDuOi-K03gJQDqRZ54DweVziqbg=.796551db-f918-4cb9-99d8-2ac89596854d@github.com> References: <7kSAuBxx0uNV2pNBUDuOi-K03gJQDqRZ54DweVziqbg=.796551db-f918-4cb9-99d8-2ac89596854d@github.com> Message-ID: On Wed, 20 Dec 2023 09:28:47 GMT, Artem Semenov wrote: > NSAccessibility Outline is an accessibility representation of trees. > This representation requires that the visible children be represented as a flat array. > The child linearization algorithm available in ```CAccessibility.getChildrenAndRolesRecursive()``` is universal, i.e. suitable for any object with the role of a tree, but is not efficient, since it traverses the entire tree and selects suitable children. > For JTree, this algorithm can be optimized by using TreePath, but the old algorithm will have to be retained to maintain versatility. I created a bug [JDK-8323965](https://bugs.openjdk.org/browse/JDK-8323965) @azuev-java Please check and if everything is good, I will integrate the current solution. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17165#issuecomment-1895357988 From aivanov at openjdk.org Wed Jan 17 10:35:54 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 17 Jan 2024 10:35:54 GMT Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination [v14] In-Reply-To: References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> Message-ID: <5emeDqaZLQbTnqLz_Z5cH0kiekL_vNd5ZAJWRvziTOw=.bf179733-4c25-43e3-b574-5246de0eb471@github.com> On Wed, 17 Jan 2024 01:56:25 GMT, songpv-imt wrote: >> The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method. >> >> JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287) > > songpv-imt has updated the pull request incrementally with one additional commit since the last revision: > > Update InterJVMGetDropSuccessTest.java Thank you for updating it. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16396#pullrequestreview-1826984213 From goetz at openjdk.org Wed Jan 17 12:54:02 2024 From: goetz at openjdk.org (Goetz Lindenmaier) Date: Wed, 17 Jan 2024 12:54:02 GMT Subject: RFR: 8318590: JButton ignores margin when painting HTML text [v6] In-Reply-To: References: Message-ID: On Tue, 5 Dec 2023 19:11:48 GMT, Damon Nguyen wrote: >> The initial issue was a padding issue for JButton when HTML content was set as the button's text. [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854), and [JDK-8302173](https://bugs.openjdk.org/browse/JDK-8302173) are the issues related to the fix. The initial bug report was for Metal L&F, since it has a drastically different button margin from the rest (2, 14, 2, 14). This left and right margin of 14px led to the initial bug report. However, it was determined that the issue was not an issue, and instead, a problem with the reporter's implementation since they weren't aware of the difference in Metal's button margins versus other L&Fs. >> >> This PR reverts these changes since it was determined in [this PR](https://github.com/JFormDesigner/FlatLaf/issues/746) that the fix causes a new issue regarding JButton contents' positioning. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year Thanks for the clarification :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/16869#issuecomment-1895748277 From tr at openjdk.org Wed Jan 17 13:08:27 2024 From: tr at openjdk.org (Tejesh R) Date: Wed, 17 Jan 2024 13:08:27 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException Message-ID: Suggested fix [JDK-8307091](https://bugs.openjdk.org/browse/JDK-8307091) also created concurrent exception intermittently (monthly once/quarterly once) on CI system. The issue was not able to be reproduced yet, hence proposing an alternative fix which uses iterators to compare the List. CI testing shows green. ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/17462/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17462&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323670 Stats: 17 lines in 1 file changed: 13 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/17462.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17462/head:pull/17462 PR: https://git.openjdk.org/jdk/pull/17462 From asemenov at openjdk.org Wed Jan 17 16:46:57 2024 From: asemenov at openjdk.org (Artem Semenov) Date: Wed, 17 Jan 2024 16:46:57 GMT Subject: Integrated: 8317771 [macos14] Expand/collapse a JTree using keyboard freezes the application in macOS 14 Sonoma In-Reply-To: <7kSAuBxx0uNV2pNBUDuOi-K03gJQDqRZ54DweVziqbg=.796551db-f918-4cb9-99d8-2ac89596854d@github.com> References: <7kSAuBxx0uNV2pNBUDuOi-K03gJQDqRZ54DweVziqbg=.796551db-f918-4cb9-99d8-2ac89596854d@github.com> Message-ID: On Wed, 20 Dec 2023 09:28:47 GMT, Artem Semenov wrote: > NSAccessibility Outline is an accessibility representation of trees. > This representation requires that the visible children be represented as a flat array. > The child linearization algorithm available in ```CAccessibility.getChildrenAndRolesRecursive()``` is universal, i.e. suitable for any object with the role of a tree, but is not efficient, since it traverses the entire tree and selects suitable children. > For JTree, this algorithm can be optimized by using TreePath, but the old algorithm will have to be retained to maintain versatility. This pull request has now been integrated. Changeset: ffa33d7b Author: Artem Semenov URL: https://git.openjdk.org/jdk/commit/ffa33d7b807bfef6ff05c9adba869dddf813cf68 Stats: 65 lines in 1 file changed: 64 ins; 1 del; 0 mod 8317771: [macos14] Expand/collapse a JTree using keyboard freezes the application in macOS 14 Sonoma Reviewed-by: kizune ------------- PR: https://git.openjdk.org/jdk/pull/17165 From simon at cjnash.com Wed Jan 17 17:53:43 2024 From: simon at cjnash.com (Simon Nash) Date: Wed, 17 Jan 2024 17:53:43 +0000 Subject: Integrated: 8321151: JDK-8294427 breaks Windows L&F on all older Windows versions In-Reply-To: References: Message-ID: <6b212b32-ec15-229b-8b39-321d7232ddab@cjnash.com> On 22/12/2023 20:19, Rajat Mahajan wrote: > On Thu, 21 Dec 2023 01:19:40 GMT, Rajat Mahajan wrote: > This pull request has now been integrated. > > Changeset: f695ca58 > Author: Rajat Mahajan > Committer: Alexey Ivanov > URL: https://git.openjdk.org/jdk/commit/f695ca588453265d6ad791c6a396197e8a53ba39 > Stats: 54 lines in 1 file changed: 43 ins; 2 del; 9 mod > > 8321151: JDK-8294427 breaks Windows L&F on all older Windows versions > > Reviewed-by: aivanov, achung > > ------------- > > PR: https://git.openjdk.org/jdk/pull/17173 I have tested this using JDK 23 build 5 and it works as expected. As I understand it, the original change JDK-8294427 has been backported to JDK 21u, 17u and 11u. What needs to happen to backport this change to 22u and also these older versions? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Wed Jan 17 18:08:22 2024 From: alexey.ivanov at oracle.com (Aleksei Ivanov) Date: Wed, 17 Jan 2024 18:08:22 +0000 Subject: [External] : Re: Windows 11: Notifications vanishes after few seconds. In-Reply-To: <310e0659-fd0f-45c7-b462-7755a0144c34@dpsoftware.org> References: <9ecd6e22-3eb1-489b-b166-652a2fd1bf22@dpsoftware.org> <77e4ab4a-3813-4e83-b464-a4400dbe05f2@oracle.com> <310e0659-fd0f-45c7-b462-7755a0144c34@dpsoftware.org> Message-ID: Hi Davide, On 2024-01-08 21:05, Davide Perini wrote: > Thanks for the explanation?Aleksei > but can you explain me what is the OpenJDK direction please? > > Suppose that you have a feature like this one, a simple notifications. > Java worked well with Windows notifications until Win10, > then Microsoft changed the APIs for notifications in Win11. It is a change by Microsoft, JDK has no control over how Windows treats notifications. These notifications were introduced in Windows XP and were meant to provide a quick status update, the notifications were not preserved, therefore apps should not rely on the notifications as the only means to communicate status to users. Windows 10 allowed notifications displayed with Shell_NotifyIcon to be preserved in the notification centre. With Windows 11, such notifications are again temporary as they were before Windows 10 and are gone after a short timeout. The API that Java uses to display notifications hasn't changed, yet the way Windows treats these notifications has changed. > Isn't OpenJDK supposed to adapt to the new Windows APIs? Updating to newer APIs isn't free. > Does OpenJDK supports Windows 11 or not? JDK supports Windows 11. At the same time, JDK can still have bugs. > It's a little "weird" to close an issue by saying that Java uses the > same way to do the same thing since Windows 95 > and that it's a Microsoft problem if they changed the way to send > notifications to the OS. > > Java should support Microsoft Windows, it isn't Microsoft Windows that > should support Java, > isn't it? I demonstrated that it's not a bug in JDK, it's the way notifications from Win32 API are handled in Windows 11. Any application that uses Win32 API, Shell_NotifyIcon in particular, is affected. It is not limited to Java. A C++ app has exactly the same behaviour; an app developed in another language or framework which uses Shell_NotifyIcon under the hood is affected too. ----- I'd like to remind you that this mailing list is where you contribute fixes for OpenJDK. You can contact Oracle for support. Regards, Alexey > Other languages adapted their APIs for the new notifications system, > like everyone should expect from a modern language, > after 2 years from the release of Win 11, > Oracle says that it worked since Windows 95, so it is ok to have a > broken API in JDK because it worked before, they are the ones who > broke it (Microsoft). > > Does Java offers a correct way to send Notifications in Win10? Answer: Yes > Does Java offers a correct way to send Notifications in Win11? Answer: No > Does other languages offers a correct way to send Notifications in > Win11? Answer: Yes > Does current JDK APIs works as expected in Win11? > Answer: No because JDK uses an old API born with Win95 (30 years ago + > or -) with a new OS born in 2021, this results in an unexcpected > behaviour that doesn't work as supposed initially by the API. > > In the bug report you wrote: > "I can't see what Java can do to change the behaviour." > > The answer is: > "By implementing the correct API for the correct OS". > > > Java is currently not able to correctly send a Notification in Windows 11. > > > I see a bug there, if you don't see it, > I'm pretty worried of the new JDK direction. > > Thanks > Davide > > > Il 08/01/2024 20:55, Aleksei Ivanov ha scritto: >> On 2024-01-08 19:30, Davide Perini wrote: >>> Thanks for the Answer Aleksei, >>> I have a lot of Windows apps that uses notifications without problems. >>> >>> even a simple python program like this works correctly. >>> from win11toastimport toast >>> >>> toast('Hello','Click to run python script') >> >> Python could use newer WinRT APIs [6], in particular >> ToastNotification class [7] which provide richer interface for the >> toast notifications. The package name ?toast? hints it uses the newer >> APIs. >> >>> is it possible that Microsoft changed the way how to create >>> Notifications in Windows 11 and Java still uses the way it worked in >>> Windows 7? >> >> Perhaps, Microsoft changed how they handle notifications in Windows >> 11. In Windows 10, the notifications created with a Java app remain >> in Action / Notification centre. >> >> Java uses Shell_NotifyIcon [8] function that has been available since >> Windows 95. >> >> -- >> Regards, >> Alexey >> >> [6] https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/ >> [7] >> https://learn.microsoft.com/en-us/uwp/api/windows.ui.notifications.toastnotification?view=winrt-22621 >> [8] >> https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shell_notifyiconw >> >>> >>> Thanks >>> Davide >>> >>> >>> >>> Il 08/01/2024 17:59, Aleksei Ivanov ha scritto: >>>> Hi Davide, >>>> >>>> The bug that you reported has been moved to JDK project in JBS, you >>>> can view it as JDK-8315647 [1]. You should've received a link to it. >>>> >>>>> Is there a way to workaround this JDK bug? >>>>> I opened a bug report months ago but no one answered. >>>> >>>> What kind of answer did you expect to receive? >>>> >>>> You already asked this question on this mailing list in August [2]. >>>> I replied to your question [3]. Nothing has changed since August. >>>> It is not a bug in Java because a native Win32 app behaves the same >>>> way. >>>> >>>> I compiled and tested the sample [4], it behaves in Windows 11 as >>>> Java does: the displayed balloon notification does not go to >>>> notification centre. However, if I open notification centre while >>>> the balloon is displayed, it remains there. If I disable "Show >>>> notification banners" and leave "Show notifications in notification >>>> centre" enabled, the balloon goes directly to notification centre >>>> without displaying a banner. >>>> >>>> You can compile and test the sample too: >>>> >>>> git clone --filter=blob:none --sparse >>>> https://github.com/microsoft/Windows-classic-samples.git >>>> windows-samples >>>> cd windows-samples >>>> git sparse-checkout add >>>> Samples/Win7Samples/winui/shell/appshellintegration/NotificationIcon >>>> >>>> Navigate to the NotificationIcon folder and open >>>> NotificationIcon.sln in Visual Studio to compile and run it. >>>> >>>> If required, I can attach the compiled version of the application. >>>> >>>> >>>> I have closed JDK-8315647 as duplicate of JDK-8310352 [5]. >>>> >>> >> > From alexey.ivanov at oracle.com Wed Jan 17 18:12:56 2024 From: alexey.ivanov at oracle.com (Aleksei Ivanov) Date: Wed, 17 Jan 2024 18:12:56 +0000 Subject: [External] : Re: Windows 11: Notifications vanishes after few seconds. In-Reply-To: References: <9ecd6e22-3eb1-489b-b166-652a2fd1bf22@dpsoftware.org> <77e4ab4a-3813-4e83-b464-a4400dbe05f2@oracle.com> <310e0659-fd0f-45c7-b462-7755a0144c34@dpsoftware.org> Message-ID: Thank you, SWinxy. It is a helpful reference, I didn't know such an enhancement already existed: JDK-8266423: Triggering OS toast notifications without the use of SystemTray On 2024-01-09 21:50, SWinxy wrote: > Back in mid-2021 I submitted a feature request > to add new APIs for > toast notifications on macOS and Windows /without/?using SystemTray. > It's something I'd like to implement. Apple introduced its > notification APIs > ?in > macOS 10.8. Never worked with the WinRT before, though. -- Regards, Alexey From alexey.ivanov at oracle.com Wed Jan 17 18:30:56 2024 From: alexey.ivanov at oracle.com (Aleksei Ivanov) Date: Wed, 17 Jan 2024 18:30:56 +0000 Subject: Windows 11: Notifications vanishes after few seconds. In-Reply-To: <07b98c88-3129-4aec-90d9-4b614443cb7d@dpsoftware.org> References: <9ecd6e22-3eb1-489b-b166-652a2fd1bf22@dpsoftware.org> <77e4ab4a-3813-4e83-b464-a4400dbe05f2@oracle.com> <310e0659-fd0f-45c7-b462-7755a0144c34@dpsoftware.org> <07b98c88-3129-4aec-90d9-4b614443cb7d@dpsoftware.org> Message-ID: <83e859d8-0b56-47ef-b56d-0f2c5b606978@oracle.com> Hi Davide, The enhancement you submitted is now available in JBS: https://bugs.openjdk.org/browse/JDK-8323821 Use toast notifications on Windows 11 I updated the subject so that it sounds like an enhancement rather than a bug. JDK-8323821 is more specific than https://bugs.openjdk.org/browse/JDK-8266423 which talks about both macOS and Windows. If you have ideas on how to implement toast notifications for JDK, feel free to discuss the ideas further. Contributions are welcome. -- Regards, Alexey On 2024-01-12 11:40, Davide Perini wrote: > I wrote to Microsoft and they suggested to use the New APIs > (ToastNotification) meant for the purpose > > https://learn.microsoft.com/en-us/windows/apps/design/shell/tiles-and-notifications/toast-notifications-overview > > https://learn.microsoft.com/en-us/windows/apps/design/shell/tiles-and-notifications/send-local-toast-desktop-cpp-wrl > > Shell_NotifyIcon API is clearly unsupported after 25/30 years on a > modern OS. > > If you are a Java programmer, you can't send an OS notification. > > OS Notifications are very crucial to most apps this days, > I can't imagine how Java can overlook it. > > Since you don't accept it as a bug (Oracle is closing all the bug > reports from people on this), > I opened a feature request on this in the hope that someone wise will > look at it. > > Kind Regards, > Davide > > > Il 08/01/2024 22:05, Davide Perini ha scritto: >> Thanks for the explanation?Aleksei >> but can you explain me what is the OpenJDK direction please? >> >> Suppose that you have a feature like this one, a simple notifications. >> Java worked well with Windows notifications until Win10, >> then Microsoft changed the APIs for notifications in Win11. >> >> Isn't OpenJDK supposed to adapt to the new Windows APIs? >> >> Does OpenJDK supports Windows 11 or not? >> >> It's a little "weird" to close an issue by saying that Java uses the >> same way to do the same thing since Windows 95 >> and that it's a Microsoft problem if they changed the way to send >> notifications to the OS. >> >> Java should support Microsoft Windows, it isn't Microsoft Windows >> that should support Java, >> isn't it? >> >> Other languages adapted their APIs for the new notifications system, >> like everyone should expect from a modern language, >> after 2 years from the release of Win 11, >> Oracle says that it worked since Windows 95, so it is ok to have a >> broken API in JDK because it worked before, they are the ones who >> broke it (Microsoft). >> >> Does Java offers a correct way to send Notifications in Win10? >> Answer: Yes >> Does Java offers a correct way to send Notifications in Win11? Answer: No >> Does other languages offers a correct way to send Notifications in >> Win11? Answer: Yes >> Does current JDK APIs works as expected in Win11? >> Answer: No because JDK uses an old API born with Win95 (30 years ago >> + or -) with a new OS born in 2021, this results in an unexcpected >> behaviour that doesn't work as supposed initially by the API. >> >> In the bug report you wrote: >> "I can't see what Java can do to change the behaviour." >> >> The answer is: >> "By implementing the correct API for the correct OS". >> >> >> Java is currently not able to correctly send a Notification in >> Windows 11. >> >> >> I see a bug there, if you don't see it, >> I'm pretty worried of the new JDK direction. >> >> Thanks >> Davide >> >> >> Il 08/01/2024 20:55, Aleksei Ivanov ha scritto: >>> On 2024-01-08 19:30, Davide Perini wrote: >>>> Thanks for the Answer Aleksei, >>>> I have a lot of Windows apps that uses notifications without problems. >>>> >>>> even a simple python program like this works correctly. >>>> from win11toastimport toast >>>> >>>> toast('Hello','Click to run python script') >>> >>> Python could use newer WinRT APIs [6], in particular >>> ToastNotification class [7] which provide richer interface for the >>> toast notifications. The package name ?toast? hints it uses the >>> newer APIs. >>> >>>> is it possible that Microsoft changed the way how to create >>>> Notifications in Windows 11 and Java still uses the way it worked >>>> in Windows 7? >>> >>> Perhaps, Microsoft changed how they handle notifications in Windows >>> 11. In Windows 10, the notifications created with a Java app remain >>> in Action / Notification centre. >>> >>> Java uses Shell_NotifyIcon [8] function that has been available >>> since Windows 95. >>> >>> -- >>> Regards, >>> Alexey >>> >>> [6] https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/ >>> [7] >>> https://learn.microsoft.com/en-us/uwp/api/windows.ui.notifications.toastnotification?view=winrt-22621 >>> [8] >>> https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shell_notifyiconw >>> >>>> >>>> Thanks >>>> Davide >>>> >>>> >>>> >>>> Il 08/01/2024 17:59, Aleksei Ivanov ha scritto: >>>>> Hi Davide, >>>>> >>>>> The bug that you reported has been moved to JDK project in JBS, >>>>> you can view it as JDK-8315647 [1]. You should've received a link >>>>> to it. >>>>> >>>>>> Is there a way to workaround this JDK bug? >>>>>> I opened a bug report months ago but no one answered. >>>>> >>>>> What kind of answer did you expect to receive? >>>>> >>>>> You already asked this question on this mailing list in August >>>>> [2]. I replied to your question [3]. Nothing has changed since >>>>> August. It is not a bug in Java because a native Win32 app behaves >>>>> the same way. >>>>> >>>>> I compiled and tested the sample [4], it behaves in Windows 11 as >>>>> Java does: the displayed balloon notification does not go to >>>>> notification centre. However, if I open notification centre while >>>>> the balloon is displayed, it remains there. If I disable "Show >>>>> notification banners" and leave "Show notifications in >>>>> notification centre" enabled, the balloon goes directly to >>>>> notification centre without displaying a banner. >>>>> >>>>> You can compile and test the sample too: >>>>> >>>>> git clone --filter=blob:none --sparse >>>>> https://github.com/microsoft/Windows-classic-samples.git >>>>> windows-samples >>>>> cd windows-samples >>>>> git sparse-checkout add >>>>> Samples/Win7Samples/winui/shell/appshellintegration/NotificationIcon >>>>> >>>>> Navigate to the NotificationIcon folder and open >>>>> NotificationIcon.sln in Visual Studio to compile and run it. >>>>> >>>>> If required, I can attach the compiled version of the application. >>>>> >>>>> >>>>> I have closed JDK-8315647 as duplicate of JDK-8310352 [5]. >>>>> >>>> >>> >> > From achung at openjdk.org Wed Jan 17 18:51:53 2024 From: achung at openjdk.org (Alisen Chung) Date: Wed, 17 Jan 2024 18:51:53 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v4] In-Reply-To: <00pjcBeEzOeDQ_FLh12p5daGx5e_Un2txgLlfzMBXBw=.23f90bc2-a6f2-4d4f-9ed2-bfaf177222eb@github.com> References: <00pjcBeEzOeDQ_FLh12p5daGx5e_Un2txgLlfzMBXBw=.23f90bc2-a6f2-4d4f-9ed2-bfaf177222eb@github.com> Message-ID: On Wed, 17 Jan 2024 00:26:20 GMT, Sergey Bylokhov wrote: >> Or maybe it is a lack of synchronization? > > So what is the root cause of null context here? I'm checking to see if removing executeOnEventHandlerThread solves the issue. In this test the source of the appcontext (trayIcon) is deleted via an actionPerformed listener, so probably the deletion of the trayIcon comes first then the mouseEvent is trying to be posted onto the trayIcon and throwing an error ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17329#discussion_r1456305879 From serb at openjdk.org Wed Jan 17 19:37:58 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 17 Jan 2024 19:37:58 GMT Subject: Integrated: 8323554: The typos in Javadoc: "@return if " In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 21:35:56 GMT, Sergey Bylokhov wrote: > The docs for the boolean methods are updated from this style: > > @return if the event has been consumed > > to this one > > @return {@code true} if the event has been consumed, otherwise > {@code false} > > plus small cleanups here and there. This pull request has now been integrated. Changeset: de237fb0 Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/de237fb058c74b87ea65a6020939264a5dfe3796 Stats: 123 lines in 14 files changed: 23 ins; 16 del; 84 mod 8323554: The typos in Javadoc: "@return if " Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/17357 From alexey.ivanov at oracle.com Wed Jan 17 20:08:18 2024 From: alexey.ivanov at oracle.com (Aleksei Ivanov) Date: Wed, 17 Jan 2024 20:08:18 +0000 Subject: Integrated: 8321151: JDK-8294427 breaks Windows L&F on all older Windows versions In-Reply-To: <6b212b32-ec15-229b-8b39-321d7232ddab@cjnash.com> References: <6b212b32-ec15-229b-8b39-321d7232ddab@cjnash.com> Message-ID: Hi Simon, On 2024-01-17 17:53, Simon Nash wrote: > I have tested this using JDK 23 build 5 and it works as expected. > > As I understand it, the original change JDK-8294427 has been > backported to JDK 21u, 17u and 11u. What needs to happen to backport > this change to 22u and also these older versions? Rajat is backporting this fix to 22u. He will also backport it to Oracle JDK 21u, 17u and 11u. For OpenJDK-based releases, you or anyone from the OpenJDK community needs to backport the fix into corresponding releases. For more information, see Backporting section in OpenJDK Developers? Guide, in particular ?Requesting approvals for backports? and ?Using the Skara tooling to help with backports?: https://openjdk.org/guide/#backporting https://openjdk.org/guide/#requesting-approvals-for-backports https://openjdk.org/guide/#using-the-skara-tooling-to-help-with-backports -- Regards, Alexey From prr at openjdk.org Wed Jan 17 20:12:57 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 17 Jan 2024 20:12:57 GMT Subject: RFR: 8323108: BufferedImage.setData(Raster) should not cast float and double values to integers In-Reply-To: References: Message-ID: On Thu, 4 May 2023 10:14:10 GMT, Martin Desruisseaux wrote: > The `BufferedImage` Javadoc does not mention any constraint about the data type. In practice, `BufferedImage` with floating point values can be rendered by Java2D as well as integers, provided that a compatible `ColorModel` was supplied at construction time. However calls to `setData(Raster)` unexpectedly cast floating point values to integers. For example sample value 0.8 become 0. This is demonstrated by the `SetData` test case in this pull request. > > An easy fix, which is proposed in this pull request, is to replace the whole `BufferedImage.setData(Raster)` method body by a simple call to `WritableRaster.setRect(Raster)`, which handles all `DataBuffer` types correctly. The method contracts documented in their respective Javadoc are compatible. Furthermore an examination of their source code shows that they are equivalent, except for the differences noted in the _Behavioural changes_ section below. > > # Source code comparison > For demonstrating that delegating to `WritableRaster.setRect(Raster)` would be equivalent to the current code, one can copy the method body and apply the following changes: > > * Remove `dx` parameter, replaced by 0. > * Remove `dy` parameter, replaced by 0. > * Rename `srcRaster` parameter as `r` (like in `BufferedImage`). > * Rename `startY` variable as `i` (like in `BufferedImage`). > * Rename `srcOffX` variable as `startX` (like in `BufferedImage`). > * Rename `srcOffY` variable as `startY` (like in `BufferedImage`). > * Replace `this.minX` by 0 and simplify. > * Replace `this.minY` by 0 and simplify. > * Remove the `switch` statement, keeping only the `TYPE_INT` case. > > Then compare with `BufferedImage.setData(Raster)`. The modified block of code from `WritableRaster` is: > > > int width = r.getWidth(); > int height = r.getHeight(); > int startX = r.getMinX(); > int startY = r.getMinY(); > > We can see that above code is identical to `BufferedImage`. The next modified block of code from `WritableRaster`: > > > int dstOffX = startX; > int dstOffY = startY; > > // Clip to this raster > if (dstOffX < 0) { > width += dstOffX; > startX -= dstOffX; // = 0 because dstOffX == startX > dstOffX = 0; > } > if (dstOffY < 0) { > height += dstOffY; > startY -= dstOffY; // = 0 because dstOffY == startY > dstOffY = 0; > } > if (dstOffX+width > this.width) { > width = this.width - dstOffX; > } > if (dstOffY+height > this.height) { > height = this.height - dstOffY; > } > if (width <= 0 || height <= 0) { > return; > } > > > Above is equivalent to the following code from `BufferedImage`, ex... This all seems reasonable to me, and passes my testing. I would however like Brian Burkhalter to take a look before it is integrated ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13797#pullrequestreview-1828097281 From achung at openjdk.org Wed Jan 17 21:58:52 2024 From: achung at openjdk.org (Alisen Chung) Date: Wed, 17 Jan 2024 21:58:52 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v4] In-Reply-To: References: <00pjcBeEzOeDQ_FLh12p5daGx5e_Un2txgLlfzMBXBw=.23f90bc2-a6f2-4d4f-9ed2-bfaf177222eb@github.com> Message-ID: On Wed, 17 Jan 2024 18:49:06 GMT, Alisen Chung wrote: >> So what is the root cause of null context here? > > I'm checking to see if removing executeOnEventHandlerThread solves the issue. In this test the source of the appcontext (trayIcon) is deleted via an actionPerformed listener, so probably the deletion of the trayIcon comes first then the mouseEvent is trying to be posted onto the trayIcon and throwing an error if the SunToolkit.executeOnEventHandlerThread is removed, then the test doesn't throw an exception, but the icon doesn't disappear (test fails) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17329#discussion_r1456531020 From honkar at openjdk.org Thu Jan 18 00:26:40 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 18 Jan 2024 00:26:40 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI In-Reply-To: References: Message-ID: On Wed, 17 Jan 2024 07:19:21 GMT, Prasanta Sadhukhan wrote: > When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak. > When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. > Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500) > > FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method.. Ran the reproducer attached to JBS without and with the fix. The "Live Label count" seem to increase in both cases. After running the test, I switched to tab 2, which makes tab 1 (with JTree) inactive but during this time the Live label count increase. Will a test case be added as part of this fix? Live TestLabels:0 Live TestLabels:74 Live TestLabels:57 Live TestLabels:21 Live TestLabels:60 Live TestLabels:46 Live TestLabels:62 Live TestLabels:102 Live TestLabels:140 Live TestLabels:180 Live TestLabels:218 Live TestLabels:256 Live TestLabels:296 Live TestLabels:334 Live TestLabels:374 Live TestLabels:412 Live TestLabels:452 Live TestLabels:490 ------------- PR Review: https://git.openjdk.org/jdk/pull/17458#pullrequestreview-1828473222 From kizune at openjdk.org Thu Jan 18 00:56:19 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 18 Jan 2024 00:56:19 GMT Subject: RFR: 8320692: Null icon returned for .exe without custom icon Message-ID: Replaced asserts with NullPointerException calls because outside of testing that would be more informative - i do not think many people running their applications with assertions in system libraries enabled; Added a code that will analyze the result of the getIcon and will fall back to the default icon for the file type retrieved from the ShellFolder; Added a test case made by Aleksei Ivanov. ------------- Commit messages: - 8320692: Null icon returned for .exe without custom icon Changes: https://git.openjdk.org/jdk/pull/17475/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17475&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320692 Stats: 286 lines in 2 files changed: 280 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/17475.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17475/head:pull/17475 PR: https://git.openjdk.org/jdk/pull/17475 From rkannathpari at openjdk.org Thu Jan 18 01:26:24 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Thu, 18 Jan 2024 01:26:24 GMT Subject: Integrated: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 03:34:08 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. > > Renjith. This pull request has now been integrated. Changeset: dadd9cd1 Author: Renjith Kannath Pariyangad Committer: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/dadd9cd1e8434cffaafc7406a864eaa55954cfb8 Stats: 155 lines in 2 files changed: 151 ins; 0 del; 4 mod 8316497: ColorConvertOp - typo for non-ICC conversions needs one-line fix Co-authored-by: Sergey Bylokhov Co-authored-by: Alexey Ivanov Reviewed-by: aivanov, serb ------------- PR: https://git.openjdk.org/jdk/pull/16895 From serb at openjdk.org Thu Jan 18 01:33:20 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 18 Jan 2024 01:33:20 GMT Subject: RFR: 8323108: BufferedImage.setData(Raster) should not cast float and double values to integers In-Reply-To: References: Message-ID: <-Z3p7ao9k_4HzDRR9dv9akht9FRPWEX1ajUWXVe11Ns=.f066f485-d5df-4c2e-ba9c-77cc3f256309@github.com> On Mon, 13 Nov 2023 14:53:22 GMT, Martin Desruisseaux wrote: >> The `BufferedImage` Javadoc does not mention any constraint about the data type. In practice, `BufferedImage` with floating point values can be rendered by Java2D as well as integers, provided that a compatible `ColorModel` was supplied at construction time. However calls to `setData(Raster)` unexpectedly cast floating point values to integers. For example sample value 0.8 become 0. This is demonstrated by the `SetData` test case in this pull request. >> >> An easy fix, which is proposed in this pull request, is to replace the whole `BufferedImage.setData(Raster)` method body by a simple call to `WritableRaster.setRect(Raster)`, which handles all `DataBuffer` types correctly. The method contracts documented in their respective Javadoc are compatible. Furthermore an examination of their source code shows that they are equivalent, except for the differences noted in the _Behavioural changes_ section below. >> >> # Source code comparison >> For demonstrating that delegating to `WritableRaster.setRect(Raster)` would be equivalent to the current code, one can copy the method body and apply the following changes: >> >> * Remove `dx` parameter, replaced by 0. >> * Remove `dy` parameter, replaced by 0. >> * Rename `srcRaster` parameter as `r` (like in `BufferedImage`). >> * Rename `startY` variable as `i` (like in `BufferedImage`). >> * Rename `srcOffX` variable as `startX` (like in `BufferedImage`). >> * Rename `srcOffY` variable as `startY` (like in `BufferedImage`). >> * Replace `this.minX` by 0 and simplify. >> * Replace `this.minY` by 0 and simplify. >> * Remove the `switch` statement, keeping only the `TYPE_INT` case. >> >> Then compare with `BufferedImage.setData(Raster)`. The modified block of code from `WritableRaster` is: >> >> >> int width = r.getWidth(); >> int height = r.getHeight(); >> int startX = r.getMinX(); >> int startY = r.getMinY(); >> >> We can see that above code is identical to `BufferedImage`. The next modified block of code from `WritableRaster`: >> >> >> int dstOffX = startX; >> int dstOffY = startY; >> >> // Clip to this raster >> if (dstOffX < 0) { >> width += dstOffX; >> startX -= dstOffX; // = 0 because dstOffX == startX >> dstOffX = 0; >> } >> if (dstOffY < 0) { >> height += dstOffY; >> startY -= dstOffY; // = 0 because dstOffY == startY >> dstOffY = 0; >> } >> if (dstOffX+width > this.width) { >> width = this.width - dstOffX; >> } >> if (dstOffY+height > this.height) { >> height = this.height - dstOffY; >> } >> if (width <= 0 ||... > > Added a commit doing the replacement of handcrafter intersection in `WritableRaster.setRect(?)` by a call to `Rectangle.intersection(?)`. I couldn't run the jtreg tests however. I tried for a few hours, but I presume that I didn't configured correctly. > > Note that `setRect(?)` is overridden in `sun.awt.image.ByteInterleavedRaster` and `sun.awt.image.BytePackedRaster` for optimization purposes. Those methods use the same handcrafter intersection code than the one replaced by this commit. However I didn't updated the code in those subclasses. They should not be subject to underflow / overflow because users should not extend these classes and thus access to the protected fields. We could update those methods anyway for consistency, but I do not know what is the OpenJDK policy in that case. > > Regarding `BufferedImage.getData()`, I remember the issue. That method does not have the lost of precision issue documented in this pull request. But it would nevertheless benefit from the same change (delegate to `WritableRaster.setRect(?)`) for performance reasons, because of optimizations in above-cited `ByteInterleavedRaster` and `BytePackedRaster` subclasses. @desruisseaux please enable the github actions in your fork, it seems the "Pre-submit test status" was skipped. https://github.com/openjdk/jdk/pull/13797/checks?check_run_id=18627782594 ------------- PR Comment: https://git.openjdk.org/jdk/pull/13797#issuecomment-1897610914 From psadhukhan at openjdk.org Thu Jan 18 02:51:14 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 18 Jan 2024 02:51:14 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI In-Reply-To: References: Message-ID: <1JzcyghEppNun0LjWPUGmHGrW0QE4HluhN_rYR42wqg=.56dd91b0-53cc-43ed-851c-16e528dcd29a@github.com> On Wed, 17 Jan 2024 07:19:21 GMT, Prasanta Sadhukhan wrote: > When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak. > When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. > Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500) > > FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method.. As mentioned in the comment https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284 the components are to be removed when UI changes, so I guess it is expected to increase if UI is not changing (ie. in case tree is not visible) so I have removed at end when component is uninstalled at which point it is a leak too, if not removed.. A testcase is hard to provide for this leak..it's all notional.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17458#issuecomment-1897684665 From kizune at openjdk.org Thu Jan 18 04:12:16 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 18 Jan 2024 04:12:16 GMT Subject: RFR: JDK-8320113: [macos14] : ShapeNotSetSometimes.java fails intermittently on macOS 14 [v2] In-Reply-To: <-XwORy2eQahQ3dyJWrE20h41kdSMFNbyHQ9FGZ0z2aA=.4596d9dd-b4da-4ff1-bae5-508fa4bae37b@github.com> References: <-XwORy2eQahQ3dyJWrE20h41kdSMFNbyHQ9FGZ0z2aA=.4596d9dd-b4da-4ff1-bae5-508fa4bae37b@github.com> Message-ID: <9yBWZgZSnYD5yMTPg4jjx4p01_z3Yp3k5sMcbZcGAQc=.326c2d1a-c91a-468e-887e-feec2735429f@github.com> On Fri, 12 Jan 2024 20:21:52 GMT, Harshitha Onkar wrote: >> ShapeNotSetSometimes.java fails intermittently on macOS 14. Following is a test stabilization fix for macOS 14. With the added delays ShapeNotSetSometimes.java passes on older versions of macOS as well as on macOS 14.1, 14.2. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > test stabilization fix Marked as reviewed by kizune (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17180#pullrequestreview-1828746482 From serb at openjdk.org Thu Jan 18 08:50:13 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 18 Jan 2024 08:50:13 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v4] In-Reply-To: References: <00pjcBeEzOeDQ_FLh12p5daGx5e_Un2txgLlfzMBXBw=.23f90bc2-a6f2-4d4f-9ed2-bfaf177222eb@github.com> Message-ID: On Wed, 17 Jan 2024 21:56:25 GMT, Alisen Chung wrote: >> I'm checking to see if removing executeOnEventHandlerThread solves the issue. In this test the source of the appcontext (trayIcon) is deleted via an actionPerformed listener, so probably the deletion of the trayIcon comes first then the mouseEvent is trying to be posted onto the trayIcon and throwing an error > > if the SunToolkit.executeOnEventHandlerThread is removed, then the test doesn't throw an exception, but the icon doesn't disappear (test fails) then it should be checked what is going on there. The context should not just become null for the existing component. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17329#discussion_r1457110113 From lbourges at openjdk.org Thu Jan 18 09:02:18 2024 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Thu, 18 Jan 2024 09:02:18 GMT Subject: RFR: JDK-8323695 RenderPerf (2D) enhancements (23.12) In-Reply-To: <9f_Ek67AqpjSx-dGyKQD61-vhTTNXD5zi9BilQAt04Y=.c7679726-54b8-4e35-a486-7f876564ed1f@github.com> References: <13rvTg4QWBKawohFsLhUv8n_7j5xhbcJzTm1IpZQtMo=.2fc70458-f4a1-41ab-bb4b-8e4f49db0148@github.com> <9f_Ek67AqpjSx-dGyKQD61-vhTTNXD5zi9BilQAt04Y=.c7679726-54b8-4e35-a486-7f876564ed1f@github.com> Message-ID: On Tue, 16 Jan 2024 21:46:24 GMT, Phil Race wrote: >> - new executor modes (buffer & volatile) >> - support parallel rendering on several frames and / or screens >> - added robot calibration + optionally use rounded duration to min frame latency (120Hz) >> - give more statistics in verbose (-v) >> - added new command-line arguments >> - added version + help information > > test/jdk/performance/client/RenderPerfTest/src/renderperf/RenderPerfTest.java line 204: > >> 202: enabled ? RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB >> 203: : RenderingHints.VALUE_TEXT_ANTIALIAS_DEFAULT); >> 204: } > > Although it makes no practical difference, I am wondering why in this case, enabled==false sets "DEFAULT" and in the case above it sets "OFF" ? Will check > test/jdk/performance/client/RenderPerfTest/src/renderperf/RenderPerfTest.java line 460: > >> 458: if (id % 100 != 0) return; >> 459: if (font == null) { >> 460: font = new Font("LucidaGrande", Font.PLAIN, 32); > > I see this is pre-existing, but we should change this. > That's a font available only on macOS. You should either look up a font to use on the system at run time, > or use a logical font. Of course, I will make constant Font instances (no new Font() in benchmark code!) and use family name (Dialog or SansSerif), what do you prefer? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17408#discussion_r1457122289 PR Review Comment: https://git.openjdk.org/jdk/pull/17408#discussion_r1457123987 From lbourges at openjdk.org Thu Jan 18 09:02:20 2024 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Thu, 18 Jan 2024 09:02:20 GMT Subject: RFR: JDK-8323695 RenderPerf (2D) enhancements (23.12) In-Reply-To: References: <13rvTg4QWBKawohFsLhUv8n_7j5xhbcJzTm1IpZQtMo=.2fc70458-f4a1-41ab-bb4b-8e4f49db0148@github.com> Message-ID: On Mon, 15 Jan 2024 11:14:40 GMT, Alexey Ushakov wrote: >> - new executor modes (buffer & volatile) >> - support parallel rendering on several frames and / or screens >> - added robot calibration + optionally use rounded duration to min frame latency (120Hz) >> - give more statistics in verbose (-v) >> - added new command-line arguments >> - added version + help information > > test/jdk/performance/client/RenderPerfTest/src/renderperf/RenderPerfTest.java line 1246: > >> 1244: nData); >> 1245: } >> 1246: return String.format("%-25s : %.3f (%.3f) %s", name, scores[0], scores[1], (USE_FPS ? "FPS" : "ms")); > > Just a minor note: > It's not easy to understand the meaning of the value in brackets from the output. Some hints like a table header with column names printed before the results could be useful here. > > java -jar dist/RenderPerfTest.jar > Using GraphicsConfiguration(s): [0:0][MTLGraphicsConfig[Display 1]] > ArgbSurfaceBlitImage[1] : 60.497 (10.408) FPS > ArgbSwBlitImage[1] : 11.226 (0.569) FPS > BgrSurfaceBlitImage[1] : 59.700 (10.446) FPS I will add table header and also refine statistics to give MAD (Median absolute deviation) to give a robust estimator for result dispersion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17408#discussion_r1457121695 From duke at openjdk.org Thu Jan 18 09:31:22 2024 From: duke at openjdk.org (Martin Desruisseaux) Date: Thu, 18 Jan 2024 09:31:22 GMT Subject: RFR: 8323108: BufferedImage.setData(Raster) should not cast float and double values to integers In-Reply-To: References: Message-ID: On Thu, 4 May 2023 10:14:10 GMT, Martin Desruisseaux wrote: > The `BufferedImage` Javadoc does not mention any constraint about the data type. In practice, `BufferedImage` with floating point values can be rendered by Java2D as well as integers, provided that a compatible `ColorModel` was supplied at construction time. However calls to `setData(Raster)` unexpectedly cast floating point values to integers. For example sample value 0.8 become 0. This is demonstrated by the `SetData` test case in this pull request. > > An easy fix, which is proposed in this pull request, is to replace the whole `BufferedImage.setData(Raster)` method body by a simple call to `WritableRaster.setRect(Raster)`, which handles all `DataBuffer` types correctly. The method contracts documented in their respective Javadoc are compatible. Furthermore an examination of their source code shows that they are equivalent, except for the differences noted in the _Behavioural changes_ section below. > > # Source code comparison > For demonstrating that delegating to `WritableRaster.setRect(Raster)` would be equivalent to the current code, one can copy the method body and apply the following changes: > > * Remove `dx` parameter, replaced by 0. > * Remove `dy` parameter, replaced by 0. > * Rename `srcRaster` parameter as `r` (like in `BufferedImage`). > * Rename `startY` variable as `i` (like in `BufferedImage`). > * Rename `srcOffX` variable as `startX` (like in `BufferedImage`). > * Rename `srcOffY` variable as `startY` (like in `BufferedImage`). > * Replace `this.minX` by 0 and simplify. > * Replace `this.minY` by 0 and simplify. > * Remove the `switch` statement, keeping only the `TYPE_INT` case. > > Then compare with `BufferedImage.setData(Raster)`. The modified block of code from `WritableRaster` is: > > > int width = r.getWidth(); > int height = r.getHeight(); > int startX = r.getMinX(); > int startY = r.getMinY(); > > We can see that above code is identical to `BufferedImage`. The next modified block of code from `WritableRaster`: > > > int dstOffX = startX; > int dstOffY = startY; > > // Clip to this raster > if (dstOffX < 0) { > width += dstOffX; > startX -= dstOffX; // = 0 because dstOffX == startX > dstOffX = 0; > } > if (dstOffY < 0) { > height += dstOffY; > startY -= dstOffY; // = 0 because dstOffY == startY > dstOffY = 0; > } > if (dstOffX+width > this.width) { > width = this.width - dstOffX; > } > if (dstOffY+height > this.height) { > height = this.height - dstOffY; > } > if (width <= 0 || height <= 0) { > return; > } > > > Above is equivalent to the following code from `BufferedImage`, ex... Thanks, done. Waiting for the "okay" from Brian before to launch "/integrate". ------------- PR Comment: https://git.openjdk.org/jdk/pull/13797#issuecomment-1898107013 From duke at openjdk.org Thu Jan 18 10:06:28 2024 From: duke at openjdk.org (songpv-imt) Date: Thu, 18 Jan 2024 10:06:28 GMT Subject: Integrated: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination In-Reply-To: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com> Message-ID: On Fri, 27 Oct 2023 10:36:58 GMT, songpv-imt wrote: > The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method. > > JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287) This pull request has now been integrated. Changeset: cbfddf4e Author: Song Pham URL: https://git.openjdk.org/jdk/commit/cbfddf4e1d3ff8dddb95bcb9242b31c175b768fc Stats: 104 lines in 1 file changed: 40 ins; 38 del; 26 mod 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination Reviewed-by: honkar, aivanov, shurailine ------------- PR: https://git.openjdk.org/jdk/pull/16396 From aivanov at openjdk.org Thu Jan 18 10:10:30 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 18 Jan 2024 10:10:30 GMT Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix In-Reply-To: References: Message-ID: On Fri, 12 Jan 2024 02:55:59 GMT, Sergey Bylokhov wrote: >> @mrserb , >> >> Did you mean to use the wrapper for the middle like `ColorSpace mid = createCS(ColorSpaceSelector.WRAPPED_PYCC);` , So we can achieve : >> >> **From** >> wrapper->icc_color_space->wrapper >> icc_color_space->icc_color_space->icc_color_space >> >> **To** : >> wrapper->wrapper->wrapper >> icc_color_space->wrapper->icc_color_space >> >> Correct me if I am wrong > >>Did you mean to use the wrapper for the middle like ColorSpace mid = createCS(ColorSpaceSelector.WRAPPED_PYCC); , So we can achieve : > > Just repeat existed checks using wrapper. So you will have all combinations: > >> wrapper->icc_color_space->wrapper >> icc_color_space->icc_color_space->icc_color_space >> wrapper->wrapper->wrapper >> icc_color_space->wrapper->icc_color_space Thank you, @mrserb, for the valuable review, the fix and the test have become more comprehensive as the result. Greatly appreciated! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16895#issuecomment-1898170895 From jvanek at openjdk.org Thu Jan 18 10:56:13 2024 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Thu, 18 Jan 2024 10:56:13 GMT Subject: RFR: 8323170 - j2dbench is using outdated javac source/target to be able to build by itself In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 13:03:22 GMT, Ji?? Van?k wrote: > This PR is fixig to-old values of javac source/target for jdk22. > Note, that jdk21 suffers the same, only the target values have to be 8. I will be happy to backport this cange to jdk17 later. > > Note, that considering the rolling release of jdk and the reached threshold of bytecode compatibility, we will be forced to do this bump every STS, so best would be to drop this hardcoded limitation. As it obtains a bit more coding, I had filled the [JDK-8323169](https://bugs.openjdk.org/browse/JDK-8323169) - [ j2dbench need constant updating of javac source/target ](https://bugs.openjdk.org/browse/JDK-8323169) and will be happy to fit it for jdk asap once this direct fix bubbles to jdk21 Maybe it have sense to move j2d bench out of the jdk as [jmh](https://github.com/openjdk/jmh) did? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17303#issuecomment-1898246859 From psadhukhan at openjdk.org Thu Jan 18 11:26:22 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 18 Jan 2024 11:26:22 GMT Subject: RFR: 8309460: JScrollBar leaves behind clutter for non-integer UI scales Message-ID: Lines are left behind when moving the scrollbar in the positive direction. but are cleaned up on mouse release. Additonally, with right arrow clicks too, the lines are left behind. Seems like for mouseDragged and scrollByUnit, the dirty region of the scrollbar is not repainted leading to artifacts which is being done in this fix.. ------------- Commit messages: - fix - 8309460: JScrollBar leaves behind clutter for non-integer UI scales Changes: https://git.openjdk.org/jdk/pull/17484/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17484&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309460 Stats: 82 lines in 2 files changed: 82 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17484.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17484/head:pull/17484 PR: https://git.openjdk.org/jdk/pull/17484 From lbourges at openjdk.org Thu Jan 18 12:29:13 2024 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Thu, 18 Jan 2024 12:29:13 GMT Subject: RFR: 8323170 - j2dbench is using outdated javac source/target to be able to build by itself In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 13:03:22 GMT, Ji?? Van?k wrote: > This PR is fixig to-old values of javac source/target for jdk22. > Note, that jdk21 suffers the same, only the target values have to be 8. I will be happy to backport this cange to jdk17 later. > > Note, that considering the rolling release of jdk and the reached threshold of bytecode compatibility, we will be forced to do this bump every STS, so best would be to drop this hardcoded limitation. As it obtains a bit more coding, I had filled the [JDK-8323169](https://bugs.openjdk.org/browse/JDK-8323169) - [ j2dbench need constant updating of javac source/target ](https://bugs.openjdk.org/browse/JDK-8323169) and will be happy to fit it for jdk asap once this direct fix bubbles to jdk21 Many swing demo or benchmarks like J2DBench, J2DDemo & RenderPerf are compatible accross jdk (8-23). Having an openjdk common or shared tools could be great ------------- PR Comment: https://git.openjdk.org/jdk/pull/17303#issuecomment-1898386642 From jbechberger at openjdk.org Thu Jan 18 14:14:26 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 18 Jan 2024 14:14:26 GMT Subject: RFR: 8317771 [macos14] Expand/collapse a JTree using keyboard freezes the application in macOS 14 Sonoma In-Reply-To: <7kSAuBxx0uNV2pNBUDuOi-K03gJQDqRZ54DweVziqbg=.796551db-f918-4cb9-99d8-2ac89596854d@github.com> References: <7kSAuBxx0uNV2pNBUDuOi-K03gJQDqRZ54DweVziqbg=.796551db-f918-4cb9-99d8-2ac89596854d@github.com> Message-ID: On Wed, 20 Dec 2023 09:28:47 GMT, Artem Semenov wrote: > NSAccessibility Outline is an accessibility representation of trees. > This representation requires that the visible children be represented as a flat array. > The child linearization algorithm available in ```CAccessibility.getChildrenAndRolesRecursive()``` is universal, i.e. suitable for any object with the role of a tree, but is not efficient, since it traverses the entire tree and selects suitable children. > For JTree, this algorithm can be optimized by using TreePath, but the old algorithm will have to be retained to maintain versatility. Fixed code is not present in JDK11, therefore no backport there. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17165#issuecomment-1898553850 From jvanek at openjdk.org Thu Jan 18 16:15:19 2024 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Thu, 18 Jan 2024 16:15:19 GMT Subject: RFR: 8323170 - j2dbench is using outdated javac source/target to be able to build by itself In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 13:03:22 GMT, Ji?? Van?k wrote: > This PR is fixig to-old values of javac source/target for jdk22. > Note, that jdk21 suffers the same, only the target values have to be 8. I will be happy to backport this cange to jdk17 later. > > Note, that considering the rolling release of jdk and the reached threshold of bytecode compatibility, we will be forced to do this bump every STS, so best would be to drop this hardcoded limitation. As it obtains a bit more coding, I had filled the [JDK-8323169](https://bugs.openjdk.org/browse/JDK-8323169) - [ j2dbench need constant updating of javac source/target ](https://bugs.openjdk.org/browse/JDK-8323169) and will be happy to fit it for jdk asap once this direct fix bubbles to jdk21 Yes! Except the jdk7 source target :) Thats no go for jdk 21,22 and 23... So what now? My proposal is to merge this(to make it working in 8-21). Backport it to jdk21, and for jkd23 write a JEP and move it out of the jdk repo to its own repo or repos, and solve any source/target like problems here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17303#issuecomment-1898786466 From achung at openjdk.org Thu Jan 18 16:41:17 2024 From: achung at openjdk.org (Alisen Chung) Date: Thu, 18 Jan 2024 16:41:17 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v4] In-Reply-To: References: <00pjcBeEzOeDQ_FLh12p5daGx5e_Un2txgLlfzMBXBw=.23f90bc2-a6f2-4d4f-9ed2-bfaf177222eb@github.com> Message-ID: <8oX6Lb94AH15qK0Wq1Wf1u6fd-xy0fNj6UZGl5YNIfI=.653b780c-407d-41ef-bd92-b8d535207d3e@github.com> On Thu, 18 Jan 2024 08:47:40 GMT, Sergey Bylokhov wrote: >> if the SunToolkit.executeOnEventHandlerThread is removed, then the test doesn't throw an exception, but the icon doesn't disappear (test fails) > > then it should be checked what is going on there. The context should not just become null for the existing component. I think the context became null because the component doesn't exist anymore ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17329#discussion_r1457712060 From aivanov at openjdk.org Thu Jan 18 17:39:13 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 18 Jan 2024 17:39:13 GMT Subject: RFR: 8320692: Null icon returned for .exe without custom icon In-Reply-To: References: Message-ID: <18I-cEBXW3WS0TTyUT0wI69EcCebEGHrQAM6ccoYSH0=.0d124a58-91cd-4c52-8d37-ad61f8f54378@github.com> On Thu, 18 Jan 2024 00:47:00 GMT, Alexander Zuev wrote: > Replaced asserts with NullPointerException calls because outside of testing that would be more informative - i do not think many people running their applications with assertions in system libraries enabled; > Added a code that will analyze the result of the getIcon and will fall back to the default icon for the file type retrieved from the ShellFolder; > Added a test case made by Aleksei Ivanov. src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1208: > 1206: } else { > 1207: return new MultiResolutionIconImage(size, multiResolutionIcon); > 1208: } Can we return `null` immediately if an icon that we're about to put into `multiResolutionIcon` is `null`? That is change the line 1198(1195) https://github.com/openjdk/jdk/blob/1640fbb1d4b1bcc5196b0055858403a4bd524359/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1198 to if (newIcon == null) { return null; } multiResolutionIcon.put(s, newIcon); I assume if `newIcon == null` then `hIcon` is also `null`, in which case we can move this condition to the line 1195(1192) https://github.com/openjdk/jdk/blob/1640fbb1d4b1bcc5196b0055858403a4bd524359/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1195 before calling `makeIcon`. src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1423: > 1421: if (resolutionVariants.containsValue(null)) { > 1422: throw new NullPointerException("There are null icons in the MRI variants map"); > 1423: } I'm unsure about this. The idea with assert was to provide a debugging aid without affecting regular runtime. We control all the paths that call this constructor and, therefore, we should ensure it's never called if `resolutionVariants` contains `null`. It's exactly what you've done in this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17475#discussion_r1457770744 PR Review Comment: https://git.openjdk.org/jdk/pull/17475#discussion_r1457775052 From azvegint at openjdk.org Thu Jan 18 19:14:14 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 18 Jan 2024 19:14:14 GMT Subject: RFR: JDK-8320113: [macos14] : ShapeNotSetSometimes.java fails intermittently on macOS 14 [v2] In-Reply-To: <-XwORy2eQahQ3dyJWrE20h41kdSMFNbyHQ9FGZ0z2aA=.4596d9dd-b4da-4ff1-bae5-508fa4bae37b@github.com> References: <-XwORy2eQahQ3dyJWrE20h41kdSMFNbyHQ9FGZ0z2aA=.4596d9dd-b4da-4ff1-bae5-508fa4bae37b@github.com> Message-ID: <1MZ-FnW1QgqIeEhMPxIK9ZxugFtsZ6IHsRxxTr7OTmU=.e900506b-06ca-49ca-8bc8-4dd94a6826b0@github.com> On Fri, 12 Jan 2024 20:21:52 GMT, Harshitha Onkar wrote: >> ShapeNotSetSometimes.java fails intermittently on macOS 14. Following is a test stabilization fix for macOS 14. With the added delays ShapeNotSetSometimes.java passes on older versions of macOS as well as on macOS 14.1, 14.2. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > test stabilization fix I found out from our offline discussion that it failed only on Linux and not on other platforms. Since it's **very** intermittent failure, and the test hasn't been on the problem list [since April](https://bugs.openjdk.org/browse/JDK-8144030), and there have been no reported incidents on Linux since then, I think we should not hide such failures behind additional attempts until we find out the cause. I suggest adding some additional debugging information, such as saving a screenshot of what actually happened before the exception was thrown. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17180#issuecomment-1899059781 From kizune at openjdk.org Thu Jan 18 19:27:16 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 18 Jan 2024 19:27:16 GMT Subject: RFR: 8320692: Null icon returned for .exe without custom icon In-Reply-To: <18I-cEBXW3WS0TTyUT0wI69EcCebEGHrQAM6ccoYSH0=.0d124a58-91cd-4c52-8d37-ad61f8f54378@github.com> References: <18I-cEBXW3WS0TTyUT0wI69EcCebEGHrQAM6ccoYSH0=.0d124a58-91cd-4c52-8d37-ad61f8f54378@github.com> Message-ID: On Thu, 18 Jan 2024 17:30:11 GMT, Alexey Ivanov wrote: >> Replaced asserts with NullPointerException calls because outside of testing that would be more informative - i do not think many people running their applications with assertions in system libraries enabled; >> Added a code that will analyze the result of the getIcon and will fall back to the default icon for the file type retrieved from the ShellFolder; >> Added a test case made by Aleksei Ivanov. > > src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1423: > >> 1421: if (resolutionVariants.containsValue(null)) { >> 1422: throw new NullPointerException("There are null icons in the MRI variants map"); >> 1423: } > > I'm unsure about this. The idea with assert was to provide a debugging aid without affecting regular runtime. We control all the paths that call this constructor and, therefore, we should ensure it's never called if `resolutionVariants` contains `null`. > > It's exactly what you've done in this PR. Ok, i will revert that part. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17475#discussion_r1457888450 From kizune at openjdk.org Thu Jan 18 19:37:29 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 18 Jan 2024 19:37:29 GMT Subject: RFR: 8320692: Null icon returned for .exe without custom icon In-Reply-To: <18I-cEBXW3WS0TTyUT0wI69EcCebEGHrQAM6ccoYSH0=.0d124a58-91cd-4c52-8d37-ad61f8f54378@github.com> References: <18I-cEBXW3WS0TTyUT0wI69EcCebEGHrQAM6ccoYSH0=.0d124a58-91cd-4c52-8d37-ad61f8f54378@github.com> Message-ID: On Thu, 18 Jan 2024 17:26:30 GMT, Alexey Ivanov wrote: >> Replaced asserts with NullPointerException calls because outside of testing that would be more informative - i do not think many people running their applications with assertions in system libraries enabled; >> Added a code that will analyze the result of the getIcon and will fall back to the default icon for the file type retrieved from the ShellFolder; >> Added a test case made by Aleksei Ivanov. > > src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1208: > >> 1206: } else { >> 1207: return new MultiResolutionIconImage(size, multiResolutionIcon); >> 1208: } > > Can we return `null` immediately if an icon that we're about to put into `multiResolutionIcon` is `null`? > > That is change the line 1198(1195) > https://github.com/openjdk/jdk/blob/1640fbb1d4b1bcc5196b0055858403a4bd524359/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1198 > > to > > > if (newIcon == null) { > return null; > } > multiResolutionIcon.put(s, newIcon); > > > I assume if `newIcon == null` then `hIcon` is also `null`, in which case we can move this condition to the line 1195(1192) > > https://github.com/openjdk/jdk/blob/1640fbb1d4b1bcc5196b0055858403a4bd524359/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1195 > > before calling `makeIcon`. Ok, i will move it to the line 1198 because i can not guarantee that we do not need to dispose hIcon if we can not make icon out of it so i would rather avoid potential resource leak. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17475#discussion_r1457897661 From kizune at openjdk.org Thu Jan 18 19:40:40 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 18 Jan 2024 19:40:40 GMT Subject: RFR: 8320692: Null icon returned for .exe without custom icon [v2] In-Reply-To: References: Message-ID: > Replaced asserts with NullPointerException calls because outside of testing that would be more informative - i do not think many people running their applications with assertions in system libraries enabled; > Added a code that will analyze the result of the getIcon and will fall back to the default icon for the file type retrieved from the ShellFolder; > Added a test case made by Aleksei Ivanov. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Revert NPE to asserts Move null check inside the loop so we do not retrieve extra icons if we encounter a null one ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17475/files - new: https://git.openjdk.org/jdk/pull/17475/files/1640fbb1..b9e453de Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17475&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17475&range=00-01 Stats: 14 lines in 1 file changed: 3 ins; 7 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/17475.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17475/head:pull/17475 PR: https://git.openjdk.org/jdk/pull/17475 From honkar at openjdk.org Thu Jan 18 20:25:24 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 18 Jan 2024 20:25:24 GMT Subject: RFR: JDK-8324169 : Remove macOS from ProblemList for CycleDMIMage.java when fix is available for JDK-8312518 Message-ID: CycleDMIMage.java passes on macOS after [JDK-8312518](https://bugs.openjdk.org/browse/JDK-8312518), [PR#17358](https://github.com/openjdk/jdk/pull/17358). It is de-problemlisted for macOS only. CI testing looks good. ------------- Commit messages: - CycleDMImage deproblemlisted for macOS Changes: https://git.openjdk.org/jdk/pull/17493/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17493&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324169 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17493.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17493/head:pull/17493 PR: https://git.openjdk.org/jdk/pull/17493 From prr at openjdk.org Thu Jan 18 21:38:24 2024 From: prr at openjdk.org (Phil Race) Date: Thu, 18 Jan 2024 21:38:24 GMT Subject: RFR: JDK-8323695 RenderPerf (2D) enhancements (23.12) In-Reply-To: References: <13rvTg4QWBKawohFsLhUv8n_7j5xhbcJzTm1IpZQtMo=.2fc70458-f4a1-41ab-bb4b-8e4f49db0148@github.com> <9f_Ek67AqpjSx-dGyKQD61-vhTTNXD5zi9BilQAt04Y=.c7679726-54b8-4e35-a486-7f876564ed1f@github.com> Message-ID: On Thu, 18 Jan 2024 08:59:07 GMT, Laurent Bourg?s wrote: >> test/jdk/performance/client/RenderPerfTest/src/renderperf/RenderPerfTest.java line 460: >> >>> 458: if (id % 100 != 0) return; >>> 459: if (font == null) { >>> 460: font = new Font("LucidaGrande", Font.PLAIN, 32); >> >> I see this is pre-existing, but we should change this. >> That's a font available only on macOS. You should either look up a font to use on the system at run time, >> or use a logical font. > > Of course, I will make constant Font instances (no new Font() in benchmark code!) and use family name (Dialog or SansSerif), what do you prefer? either dialog or sansserif. Dialog is the default font so perhaps that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17408#discussion_r1458001361 From prr at openjdk.org Thu Jan 18 21:49:52 2024 From: prr at openjdk.org (Phil Race) Date: Thu, 18 Jan 2024 21:49:52 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v8] In-Reply-To: <4qlxE0k7KXnrw916s7DAGfYQbgLdrPmcSDfQdIRGTkw=.a21d1290-750f-4ae9-9f75-5f97ee2e8734@github.com> References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> <4qlxE0k7KXnrw916s7DAGfYQbgLdrPmcSDfQdIRGTkw=.a21d1290-750f-4ae9-9f75-5f97ee2e8734@github.com> Message-ID: On Wed, 3 Jan 2024 05:33:04 GMT, Prasanta Sadhukhan wrote: >> javadoc contract for JComponent.setMinimumSize(Dimension) states: >> >> "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..." >> >> However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize() >> >> Fix is made to check if mnimumSize is set and if so, honour it.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Honour max/min size if set by user src/java.desktop/share/classes/javax/swing/JScrollBar.java line 763: > 761: * that subsequent calls to getMinimumSize will return the > 762: * same value as set in {@code JComponent.setMinimumSize} > 763: */ You should add @param src/java.desktop/share/classes/javax/swing/JScrollBar.java line 776: > 774: * same value as set in {@code JComponent.setMaximumSize} > 775: */ > 776: public void setMaximumSize(Dimension maximumSize) { same here src/java.desktop/share/classes/javax/swing/JScrollBar.java line 784: > 782: * rigid along the other axis. > 783: */ > 784: public Dimension getMinimumSize() { Since we are here, you should fix this to add the @return. This does not need to be part of the CSR src/java.desktop/share/classes/javax/swing/JScrollBar.java line 800: > 798: * rigid along the other axis. > 799: */ > 800: public Dimension getMaximumSize() { Since we are here, you should fix this to add the @return. This does not need to be part of the CSR ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1458009696 PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1458009898 PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1458010423 PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1458010508 From prr at openjdk.org Thu Jan 18 21:58:10 2024 From: prr at openjdk.org (Phil Race) Date: Thu, 18 Jan 2024 21:58:10 GMT Subject: RFR: JDK-8324169 : Remove macOS from ProblemList for CycleDMIMage.java when fix is available for JDK-8312518 In-Reply-To: References: Message-ID: <905gGtYuqqmBZr5btIFOC_ddKL_ooT4ZqnfnQnQtTlo=.46bb1594-b4f5-4a7e-91a7-16f7a7474cf9@github.com> On Thu, 18 Jan 2024 20:18:20 GMT, Harshitha Onkar wrote: > CycleDMIMage.java passes on macOS after [JDK-8312518](https://bugs.openjdk.org/browse/JDK-8312518), [PR#17358](https://github.com/openjdk/jdk/pull/17358). It is de-problemlisted for macOS only. > > > CI testing looks good. test/jdk/ProblemList.txt line 436: > 434: java/awt/Frame/DisposeParentGC/DisposeParentGC.java 8079786 macosx-all > 435: > 436: java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java 7099223,8274106 macosx-all,linux-all,windows-all it seems odd to remove macOS from the list when one of the bugs here is specifically against macOS - https://bugs.openjdk.org/browse/JDK-8274106 If the test still fails on some retina displays, then this needs to remain problem listed. If not, then remove the reference to 8274106 Wait 7099223 is also about macOS. So why is this test problem listed on all platforms ? If it passes always on macOS we also should close out those bugs. Please check it on all platforms and de-list it for all platforms that pass and if it does fail on Windows or Linux, create a bug for that platform's problems. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17493#discussion_r1458017529 From honkar at openjdk.org Thu Jan 18 22:08:39 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 18 Jan 2024 22:08:39 GMT Subject: RFR: JDK-8320113: [macos14] : ShapeNotSetSometimes.java fails intermittently on macOS 14 [v3] In-Reply-To: References: Message-ID: > ShapeNotSetSometimes.java fails intermittently on macOS 14. Following is a test stabilization fix for macOS 14. With the added delays ShapeNotSetSometimes.java passes on older versions of macOS as well as on macOS 14.1, 14.2. Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: added screenCapture ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17180/files - new: https://git.openjdk.org/jdk/pull/17180/files/9831cffd..9970fbcd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17180&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17180&range=01-02 Stats: 32 lines in 1 file changed: 15 ins; 10 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/17180.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17180/head:pull/17180 PR: https://git.openjdk.org/jdk/pull/17180 From honkar at openjdk.org Thu Jan 18 22:12:41 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 18 Jan 2024 22:12:41 GMT Subject: RFR: JDK-8320113: [macos14] : ShapeNotSetSometimes.java fails intermittently on macOS 14 [v2] In-Reply-To: <1MZ-FnW1QgqIeEhMPxIK9ZxugFtsZ6IHsRxxTr7OTmU=.e900506b-06ca-49ca-8bc8-4dd94a6826b0@github.com> References: <-XwORy2eQahQ3dyJWrE20h41kdSMFNbyHQ9FGZ0z2aA=.4596d9dd-b4da-4ff1-bae5-508fa4bae37b@github.com> <1MZ-FnW1QgqIeEhMPxIK9ZxugFtsZ6IHsRxxTr7OTmU=.e900506b-06ca-49ca-8bc8-4dd94a6826b0@github.com> Message-ID: On Thu, 18 Jan 2024 19:11:53 GMT, Alexander Zvegintsev wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> test stabilization fix > > I found out from our offline discussion that it failed only on Linux and not on other platforms. > > Since it's **very** intermittent failure, and the test hasn't been on the problem list [since April](https://bugs.openjdk.org/browse/JDK-8144030), and there have been no reported incidents on Linux since then, I think we should not hide such failures behind additional attempts until we find out the cause. > > I suggest adding some additional debugging information, such as saving a screenshot of what actually happened before the exception was thrown. Test updated according to @azvegint [suggestions](https://github.com/openjdk/jdk/pull/17180#issuecomment-1899059781). ------------- PR Comment: https://git.openjdk.org/jdk/pull/17180#issuecomment-1899300936 From honkar at openjdk.org Thu Jan 18 22:28:32 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 18 Jan 2024 22:28:32 GMT Subject: RFR: JDK-8324169 : Remove macOS from ProblemList for CycleDMIMage.java when fix is available for JDK-8312518 In-Reply-To: <905gGtYuqqmBZr5btIFOC_ddKL_ooT4ZqnfnQnQtTlo=.46bb1594-b4f5-4a7e-91a7-16f7a7474cf9@github.com> References: <905gGtYuqqmBZr5btIFOC_ddKL_ooT4ZqnfnQnQtTlo=.46bb1594-b4f5-4a7e-91a7-16f7a7474cf9@github.com> Message-ID: On Thu, 18 Jan 2024 21:55:42 GMT, Phil Race wrote: >> CycleDMIMage.java passes on macOS after [JDK-8312518](https://bugs.openjdk.org/browse/JDK-8312518), [PR#17358](https://github.com/openjdk/jdk/pull/17358). It is de-problemlisted for macOS only. >> >> >> CI testing looks good. > > test/jdk/ProblemList.txt line 436: > >> 434: java/awt/Frame/DisposeParentGC/DisposeParentGC.java 8079786 macosx-all >> 435: >> 436: java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java 7099223,8274106 macosx-all,linux-all,windows-all > > it seems odd to remove macOS from the list when one of the bugs here is specifically against macOS - https://bugs.openjdk.org/browse/JDK-8274106 > If the test still fails on some retina displays, then this needs to remain problem listed. > If not, then remove the reference to 8274106 > > Wait 7099223 is also about macOS. > So why is this test problem listed on all platforms ? > If it passes always on macOS we also should close out those bugs. > Please check it on all platforms and de-list it for all platforms that pass and if it does fail on Windows or Linux, create a bug for that platform's problems. There are couple of JBS issues related to CycleDMImage.java [JDK-7099223](https://bugs.openjdk.org/browse/JDK-7099223) - listed for all platforms [JDK-8312459](https://bugs.openjdk.org/browse/JDK-8312459) - subtask to problemlist on macOS but the JBS number itself is not included in problemlist. [JDK-8274106](https://bugs.openjdk.org/browse/JDK-8274106) - The one you mentioned earlier. > Please check it on all platforms and de-list it for all platforms that pass and if it does fail on Windows or Linux, create a bug for that platform's problems. Checking it again on all platforms. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17493#discussion_r1458039811 From prr at openjdk.org Thu Jan 18 22:37:29 2024 From: prr at openjdk.org (Phil Race) Date: Thu, 18 Jan 2024 22:37:29 GMT Subject: RFR: JDK-8324169 : Remove macOS from ProblemList for CycleDMIMage.java when fix is available for JDK-8312518 In-Reply-To: References: <905gGtYuqqmBZr5btIFOC_ddKL_ooT4ZqnfnQnQtTlo=.46bb1594-b4f5-4a7e-91a7-16f7a7474cf9@github.com> Message-ID: <43DYBnCJNkUGt0iBj08t-Yw1z9qKwy5XXRaImdtRc-E=.893dff66-dfe2-4ac2-be9c-420dade809f7@github.com> On Thu, 18 Jan 2024 22:25:16 GMT, Harshitha Onkar wrote: >> test/jdk/ProblemList.txt line 436: >> >>> 434: java/awt/Frame/DisposeParentGC/DisposeParentGC.java 8079786 macosx-all >>> 435: >>> 436: java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java 7099223,8274106 macosx-all,linux-all,windows-all >> >> it seems odd to remove macOS from the list when one of the bugs here is specifically against macOS - https://bugs.openjdk.org/browse/JDK-8274106 >> If the test still fails on some retina displays, then this needs to remain problem listed. >> If not, then remove the reference to 8274106 >> >> Wait 7099223 is also about macOS. >> So why is this test problem listed on all platforms ? >> If it passes always on macOS we also should close out those bugs. >> Please check it on all platforms and de-list it for all platforms that pass and if it does fail on Windows or Linux, create a bug for that platform's problems. > > There are couple of JBS issues related to CycleDMImage.java > [JDK-7099223](https://bugs.openjdk.org/browse/JDK-7099223) - listed for all platforms > [JDK-8312459](https://bugs.openjdk.org/browse/JDK-8312459) - subtask to problemlist on macOS but the JBS number itself is not included in problemlist. > [JDK-8274106](https://bugs.openjdk.org/browse/JDK-8274106) - The one you mentioned earlier. > >> Please check it on all platforms and de-list it for all platforms that pass and if it does fail on Windows or Linux, create a bug for that platform's problems. > > Checking it again on all platforms. 7099223 was noted in 2011 (!) as failing on solaris (doesn't matter anymore) , passing on Linux (so why is linux problem listed ?) and mentions Windows (in 2011) but nothing since then. Since 2019 it has ONLY been reported on macOS. Perhaps because it has been problem listed all that time on windows and linux :-), but now is the time to re-check all of this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17493#discussion_r1458046940 From prr at openjdk.org Thu Jan 18 22:57:27 2024 From: prr at openjdk.org (Phil Race) Date: Thu, 18 Jan 2024 22:57:27 GMT Subject: RFR: 8295804: javax/swing/JFileChooser/JFileChooserSetLocationTest.java failed with "setLocation() is not working properly" [v4] In-Reply-To: References: Message-ID: On Tue, 16 Jan 2024 05:58:45 GMT, Tejesh R wrote: >> The issue is that the doc area (in respect to the screen height which is 768px) which is at the bottom was causing the `JFileChooser `to be placed slightly above the set location. Was able to reproduce in local machine with reference to the failure image provided in the CI logs. The suggested fix is to place the main Frame slightly above the center of the screen than setting at the center of the screen. Several CI runs were made and no issue found. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix I suppose you can't know exactly how much space you need since the dialog size is out of your control. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17364#pullrequestreview-1830687939 From prr at openjdk.org Thu Jan 18 23:08:30 2024 From: prr at openjdk.org (Phil Race) Date: Thu, 18 Jan 2024 23:08:30 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v4] In-Reply-To: <8oX6Lb94AH15qK0Wq1Wf1u6fd-xy0fNj6UZGl5YNIfI=.653b780c-407d-41ef-bd92-b8d535207d3e@github.com> References: <00pjcBeEzOeDQ_FLh12p5daGx5e_Un2txgLlfzMBXBw=.23f90bc2-a6f2-4d4f-9ed2-bfaf177222eb@github.com> <8oX6Lb94AH15qK0Wq1Wf1u6fd-xy0fNj6UZGl5YNIfI=.653b780c-407d-41ef-bd92-b8d535207d3e@github.com> Message-ID: On Thu, 18 Jan 2024 16:38:37 GMT, Alisen Chung wrote: >> then it should be checked what is going on there. The context should not just become null for the existing component. > > I think the context became null because the component doesn't exist anymore Somehow we have null passed in. So something looked up appcontext and got null. Likely because some other code removed the app context from a map or similar. First step is to find exactly where that happened, then we can start to reason about how we managed to still post an event. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17329#discussion_r1458067337 From serb at openjdk.org Thu Jan 18 23:56:25 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 18 Jan 2024 23:56:25 GMT Subject: RFR: 8309460: JScrollBar leaves behind clutter for non-integer UI scales In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 11:09:12 GMT, Prasanta Sadhukhan wrote: > Lines are left behind when moving the scrollbar in the positive direction. but are cleaned up on mouse release. > Additonally, with right arrow clicks too, the lines are left behind. > Seems like for mouseDragged and scrollByUnit, the dirty region of the scrollbar is not repainted leading to artifacts > which is being done in this fix.. Why the bug is reproduced only if non-integer UI is used? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17484#issuecomment-1899402031 From serb at openjdk.org Fri Jan 19 00:15:27 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 19 Jan 2024 00:15:27 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: On Wed, 17 Jan 2024 12:55:52 GMT, Tejesh R wrote: > Suggested fix [JDK-8307091](https://bugs.openjdk.org/browse/JDK-8307091) also created concurrent exception intermittently (monthly once/quarterly once) on CI system. The issue was not able to be reproduced yet, hence proposing an alternative fix which uses iterators to compare the List. > CI testing shows green. What is the code path which modifies the vector when we iterate it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17462#issuecomment-1899421133 From serb at openjdk.org Fri Jan 19 00:44:27 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 19 Jan 2024 00:44:27 GMT Subject: RFR: 8295804: javax/swing/JFileChooser/JFileChooserSetLocationTest.java failed with "setLocation() is not working properly" [v4] In-Reply-To: References: Message-ID: On Tue, 16 Jan 2024 05:58:45 GMT, Tejesh R wrote: >> The issue is that the doc area (in respect to the screen height which is 768px) which is at the bottom was causing the `JFileChooser `to be placed slightly above the set location. Was able to reproduce in local machine with reference to the failure image provided in the CI logs. The suggested fix is to place the main Frame slightly above the center of the screen than setting at the center of the screen. Several CI runs were made and no issue found. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17364#pullrequestreview-1830878417 From serb at openjdk.org Fri Jan 19 00:53:25 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 19 Jan 2024 00:53:25 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI In-Reply-To: References: Message-ID: On Wed, 17 Jan 2024 07:19:21 GMT, Prasanta Sadhukhan wrote: > When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak. > When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. > Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500) > > FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method.. can we trigger this memory leak by some new or existed tests? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17458#issuecomment-1899457212 From serb at openjdk.org Fri Jan 19 01:47:29 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 19 Jan 2024 01:47:29 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v4] In-Reply-To: References: <00pjcBeEzOeDQ_FLh12p5daGx5e_Un2txgLlfzMBXBw=.23f90bc2-a6f2-4d4f-9ed2-bfaf177222eb@github.com> <8oX6Lb94AH15qK0Wq1Wf1u6fd-xy0fNj6UZGl5YNIfI=.653b780c-407d-41ef-bd92-b8d535207d3e@github.com> Message-ID: On Thu, 18 Jan 2024 23:06:07 GMT, Phil Race wrote: >> I think the context became null because the component doesn't exist anymore > > Somehow we have null passed in. > So something looked up appcontext and got null. > Likely because some other code removed the app context from a map or similar. > First step is to find exactly where that happened, then we can start to reason about how we managed to still post an event. Note that it does not fail with NPE but instead this code trigger the bug: AppContext eventContext = targetToAppContext(event.getSource()); if (eventContext != null && !eventContext.equals(appContext)) { throw new RuntimeException("Event posted on wrong app context : " + event); } The source of the event is TrayIcon, and the appconteext for it is non-null as well. This is the code where we post an event: @Override public void dispose() { dummyFrame.dispose(); if (popup != null) { popup.removeNotify(); } LWCToolkit.targetDisposedPeer(target, this); target = null; super.dispose(); } private void postEvent(final AWTEvent event) { SunToolkit.executeOnEventHandlerThread(target, new Runnable() { public void run() { SunToolkit.postEvent(SunToolkit.targetToAppContext(target), event); } }); } Note that we also call SunToolkit.targetToAppContext(target), and the target should be a TrayIcon and have a non-null appcontext, because later we successfully fetch it. So the problem here is not in the null appcontext, but that we set target to null in the peer in dispose(), at the time we still processing the events. - So we should check how all this should be synchronized, to prevent such race - Or we should not set target to null, this is why the bug is not reproduced on other platforms. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17329#discussion_r1458182051 From serb at openjdk.org Fri Jan 19 01:55:27 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 19 Jan 2024 01:55:27 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v4] In-Reply-To: References: <00pjcBeEzOeDQ_FLh12p5daGx5e_Un2txgLlfzMBXBw=.23f90bc2-a6f2-4d4f-9ed2-bfaf177222eb@github.com> <8oX6Lb94AH15qK0Wq1Wf1u6fd-xy0fNj6UZGl5YNIfI=.653b780c-407d-41ef-bd92-b8d535207d3e@github.com> Message-ID: On Fri, 19 Jan 2024 01:43:48 GMT, Sergey Bylokhov wrote: >> Somehow we have null passed in. >> So something looked up appcontext and got null. >> Likely because some other code removed the app context from a map or similar. >> First step is to find exactly where that happened, then we can start to reason about how we managed to still post an event. > > Note that it does not fail with NPE but instead this code trigger the bug: > > AppContext eventContext = targetToAppContext(event.getSource()); > if (eventContext != null && !eventContext.equals(appContext)) { > throw new RuntimeException("Event posted on wrong app context : " + event); > } > > The source of the event is TrayIcon, and the appconteext for it is non-null as well. > > This is the code where we post an event: > > @Override > public void dispose() { > dummyFrame.dispose(); > > if (popup != null) { > popup.removeNotify(); > } > > LWCToolkit.targetDisposedPeer(target, this); > target = null; > > super.dispose(); > } > > private void postEvent(final AWTEvent event) { > SunToolkit.executeOnEventHandlerThread(target, new Runnable() { > public void run() { > SunToolkit.postEvent(SunToolkit.targetToAppContext(target), event); > } > }); > } > > > Note that we also call SunToolkit.targetToAppContext(target), and the target should be a TrayIcon and have a non-null appcontext, because later we successfully fetch it. > > > So the problem here is not in the null appcontext, but that we set target to null in the peer in dispose(), at the time we still processing the events. > - So we should check how all this should be synchronized, to prevent such race > - Or we should not set target to null as on Windows > - Or call dispose on EDT like on Linux. I think we should set the target once and use it forever. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17329#discussion_r1458186579 From psadhukhan at openjdk.org Fri Jan 19 04:48:40 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 19 Jan 2024 04:48:40 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v9] In-Reply-To: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> Message-ID: > javadoc contract for JComponent.setMinimumSize(Dimension) states: > > "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..." > > However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize() > > Fix is made to check if mnimumSize is set and if so, honour it.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: javadoc updated ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15325/files - new: https://git.openjdk.org/jdk/pull/15325/files/0e4df2a1..1a7bc6e8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15325&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15325&range=07-08 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15325/head:pull/15325 PR: https://git.openjdk.org/jdk/pull/15325 From psadhukhan at openjdk.org Fri Jan 19 04:48:42 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 19 Jan 2024 04:48:42 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v8] In-Reply-To: References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> <4qlxE0k7KXnrw916s7DAGfYQbgLdrPmcSDfQdIRGTkw=.a21d1290-750f-4ae9-9f75-5f97ee2e8734@github.com> Message-ID: On Thu, 18 Jan 2024 21:46:47 GMT, Phil Race wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Honour max/min size if set by user > > src/java.desktop/share/classes/javax/swing/JScrollBar.java line 800: > >> 798: * rigid along the other axis. >> 799: */ >> 800: public Dimension getMaximumSize() { > > Since we are here, you should fix this to add the @return. This does not need to be part of the CSR Added @param and @return ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1458339631 From tr at openjdk.org Fri Jan 19 04:57:25 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 19 Jan 2024 04:57:25 GMT Subject: RFR: 8295804: javax/swing/JFileChooser/JFileChooserSetLocationTest.java failed with "setLocation() is not working properly" [v4] In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 22:54:57 GMT, Phil Race wrote: > I suppose you can't know exactly how much space you need since the dialog size is out of your control. Yes, I've fixed screen center position - 200 based on my test runs with multiple screen size. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17364#issuecomment-1899768927 From psadhukhan at openjdk.org Fri Jan 19 05:55:26 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 19 Jan 2024 05:55:26 GMT Subject: RFR: 8309460: JScrollBar leaves behind clutter for non-integer UI scales In-Reply-To: References: Message-ID: <8W2UV6PmGUlWlSbinEsOZ9nNIDwTml9xzcLcApKz5gw=.959fda59-a216-4676-ac99-f67e62aee8ee@github.com> On Thu, 18 Jan 2024 11:09:12 GMT, Prasanta Sadhukhan wrote: > Lines are left behind when moving the scrollbar in the positive direction. but are cleaned up on mouse release. > Additonally, with right arrow clicks too, the lines are left behind. > Seems like for mouseDragged and scrollByUnit, the dirty region of the scrollbar is not repainted leading to artifacts > which is being done in this fix.. I/m not sure but in 2 cases where it cannot be reproduced ie during mouseRelease and block increment, they do the dirty region painting which I guess should be done here too irrespectively.. https://github.com/openjdk/jdk/blob/9efdd242fb40a8270e489cc071ff1c891878e24f/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java#L1255-L1256 and https://github.com/openjdk/jdk/blob/9efdd242fb40a8270e489cc071ff1c891878e24f/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java#L1122-L1123 ------------- PR Comment: https://git.openjdk.org/jdk/pull/17484#issuecomment-1899811431 From tr at openjdk.org Fri Jan 19 05:59:35 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 19 Jan 2024 05:59:35 GMT Subject: Integrated: 8295804: javax/swing/JFileChooser/JFileChooserSetLocationTest.java failed with "setLocation() is not working properly" In-Reply-To: References: Message-ID: <8zGWd7MmDxCH2tuuUWEemgKGaVjCBzFJ-1_-rPMabXs=.06a2fe59-f509-4869-89b9-4ff0f35c5b44@github.com> On Thu, 11 Jan 2024 04:48:23 GMT, Tejesh R wrote: > The issue is that the doc area (in respect to the screen height which is 768px) which is at the bottom was causing the `JFileChooser `to be placed slightly above the set location. Was able to reproduce in local machine with reference to the failure image provided in the CI logs. The suggested fix is to place the main Frame slightly above the center of the screen than setting at the center of the screen. Several CI runs were made and no issue found. This pull request has now been integrated. Changeset: 05dad67c Author: Tejesh R URL: https://git.openjdk.org/jdk/commit/05dad67cc23fb49627fabfb306acee247ff67aef Stats: 10 lines in 1 file changed: 6 ins; 2 del; 2 mod 8295804: javax/swing/JFileChooser/JFileChooserSetLocationTest.java failed with "setLocation() is not working properly" Reviewed-by: prr, serb ------------- PR: https://git.openjdk.org/jdk/pull/17364 From tr at openjdk.org Fri Jan 19 07:26:26 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 19 Jan 2024 07:26:26 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: On Fri, 19 Jan 2024 00:13:10 GMT, Sergey Bylokhov wrote: > What is the code path which modifies the vector when we iterate it? I don't think we are able to trace it out, since the issue intermittent and previously I had made a copy of the vector list before checking for equality of the list. There was again an issue in the code which I used to copy to a temporary vector. So now instead of using` AbstractList.equals` I'm using iterators and comparing every element within synchronized method. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17462#issuecomment-1899895294 From psadhukhan at openjdk.org Fri Jan 19 10:10:27 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 19 Jan 2024 10:10:27 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI In-Reply-To: References: Message-ID: On Wed, 17 Jan 2024 07:19:21 GMT, Prasanta Sadhukhan wrote: > When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak. > When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. > Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500) > > FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method.. I cant see any nor can I think of any..you have any idea? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17458#issuecomment-1900114056 From azvegint at openjdk.org Fri Jan 19 16:51:29 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 19 Jan 2024 16:51:29 GMT Subject: RFR: JDK-8320113: [macos14] : ShapeNotSetSometimes.java fails intermittently on macOS 14 [v3] In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 22:08:39 GMT, Harshitha Onkar wrote: >> ShapeNotSetSometimes.java fails intermittently on macOS 14. Following is a test stabilization fix for macOS 14. With the added delays ShapeNotSetSometimes.java passes on older versions of macOS as well as on macOS 14.1, 14.2. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > added screenCapture > Test updated according to @azvegint [suggestions](https://github.com/openjdk/jdk/pull/17180#issuecomment-1899059781). Thank you! ------------- Marked as reviewed by azvegint (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17180#pullrequestreview-1833243970 From aivanov at openjdk.org Fri Jan 19 17:46:29 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 19 Jan 2024 17:46:29 GMT Subject: RFR: 8320692: Null icon returned for .exe without custom icon [v2] In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 19:40:40 GMT, Alexander Zuev wrote: >> Replaced asserts with NullPointerException calls because outside of testing that would be more informative - i do not think many people running their applications with assertions in system libraries enabled; >> Added a code that will analyze the result of the getIcon and will fall back to the default icon for the file type retrieved from the ShellFolder; >> Added a test case made by Aleksei Ivanov. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Revert NPE to asserts > Move null check inside the loop so we do not retrieve extra > icons if we encounter a null one Marked as reviewed by aivanov (Reviewer). src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1421: > 1419: public MultiResolutionIconImage(int baseSize, Map resolutionVariants) { > 1420: assert !resolutionVariants.containsValue(null) > 1421: : "There are null icons in the MRI variants map"; Here's an extra space. The colon aligned with `!` which starts the condition. Could you please revert it too? ------------- PR Review: https://git.openjdk.org/jdk/pull/17475#pullrequestreview-1833346740 PR Review Comment: https://git.openjdk.org/jdk/pull/17475#discussion_r1459428926 From aivanov at openjdk.org Fri Jan 19 17:52:27 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 19 Jan 2024 17:52:27 GMT Subject: RFR: 8320692: Null icon returned for .exe without custom icon [v2] In-Reply-To: References: <18I-cEBXW3WS0TTyUT0wI69EcCebEGHrQAM6ccoYSH0=.0d124a58-91cd-4c52-8d37-ad61f8f54378@github.com> Message-ID: On Thu, 18 Jan 2024 19:34:11 GMT, Alexander Zuev wrote: >> src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1208: >> >>> 1206: } else { >>> 1207: return new MultiResolutionIconImage(size, multiResolutionIcon); >>> 1208: } >> >> Can we return `null` immediately if an icon that we're about to put into `multiResolutionIcon` is `null`? >> >> That is change the line 1198(1195) >> https://github.com/openjdk/jdk/blob/1640fbb1d4b1bcc5196b0055858403a4bd524359/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1198 >> >> to >> >> >> if (newIcon == null) { >> return null; >> } >> multiResolutionIcon.put(s, newIcon); >> >> >> I assume if `newIcon == null` then `hIcon` is also `null`, in which case we can move this condition to the line 1195(1192) >> >> https://github.com/openjdk/jdk/blob/1640fbb1d4b1bcc5196b0055858403a4bd524359/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1195 >> >> before calling `makeIcon`. > > Ok, i will move it to the line 1198 because i can not guarantee that we do not need to dispose hIcon if we can not make icon out of it so i would rather avoid potential resource leak. We need to dispose of `hIcon` if it's non-null. I see that in this case `hIcon` is not null yet `makeIcon` fails to get the bitmap for whatever reason. It would be good to understand why `makeIcon` fails even though `hIcon` is not null. It is possible that `makeIcon` fails to extract an icon, so the added null-check ensures `null` is returned instead of returning a broken MRI. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17475#discussion_r1459441089 From bpb at openjdk.org Fri Jan 19 17:53:36 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 19 Jan 2024 17:53:36 GMT Subject: RFR: 8323108: BufferedImage.setData(Raster) should not cast float and double values to integers In-Reply-To: References: Message-ID: On Thu, 4 May 2023 10:14:10 GMT, Martin Desruisseaux wrote: > The `BufferedImage` Javadoc does not mention any constraint about the data type. In practice, `BufferedImage` with floating point values can be rendered by Java2D as well as integers, provided that a compatible `ColorModel` was supplied at construction time. However calls to `setData(Raster)` unexpectedly cast floating point values to integers. For example sample value 0.8 become 0. This is demonstrated by the `SetData` test case in this pull request. > > An easy fix, which is proposed in this pull request, is to replace the whole `BufferedImage.setData(Raster)` method body by a simple call to `WritableRaster.setRect(Raster)`, which handles all `DataBuffer` types correctly. The method contracts documented in their respective Javadoc are compatible. Furthermore an examination of their source code shows that they are equivalent, except for the differences noted in the _Behavioural changes_ section below. > > # Source code comparison > For demonstrating that delegating to `WritableRaster.setRect(Raster)` would be equivalent to the current code, one can copy the method body and apply the following changes: > > * Remove `dx` parameter, replaced by 0. > * Remove `dy` parameter, replaced by 0. > * Rename `srcRaster` parameter as `r` (like in `BufferedImage`). > * Rename `startY` variable as `i` (like in `BufferedImage`). > * Rename `srcOffX` variable as `startX` (like in `BufferedImage`). > * Rename `srcOffY` variable as `startY` (like in `BufferedImage`). > * Replace `this.minX` by 0 and simplify. > * Replace `this.minY` by 0 and simplify. > * Remove the `switch` statement, keeping only the `TYPE_INT` case. > > Then compare with `BufferedImage.setData(Raster)`. The modified block of code from `WritableRaster` is: > > > int width = r.getWidth(); > int height = r.getHeight(); > int startX = r.getMinX(); > int startY = r.getMinY(); > > We can see that above code is identical to `BufferedImage`. The next modified block of code from `WritableRaster`: > > > int dstOffX = startX; > int dstOffY = startY; > > // Clip to this raster > if (dstOffX < 0) { > width += dstOffX; > startX -= dstOffX; // = 0 because dstOffX == startX > dstOffX = 0; > } > if (dstOffY < 0) { > height += dstOffY; > startY -= dstOffY; // = 0 because dstOffY == startY > dstOffY = 0; > } > if (dstOffX+width > this.width) { > width = this.width - dstOffX; > } > if (dstOffY+height > this.height) { > height = this.height - dstOffY; > } > if (width <= 0 || height <= 0) { > return; > } > > > Above is equivalent to the following code from `BufferedImage`, ex... This looks all right to me except I think the copyright years might need to be updated. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13797#pullrequestreview-1833358376 From prr at openjdk.org Fri Jan 19 18:06:31 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 19 Jan 2024 18:06:31 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v8] In-Reply-To: References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> <4qlxE0k7KXnrw916s7DAGfYQbgLdrPmcSDfQdIRGTkw=.a21d1290-750f-4ae9-9f75-5f97ee2e8734@github.com> Message-ID: On Thu, 18 Jan 2024 21:46:39 GMT, Phil Race wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Honour max/min size if set by user > > src/java.desktop/share/classes/javax/swing/JScrollBar.java line 784: > >> 782: * rigid along the other axis. >> 783: */ >> 784: public Dimension getMinimumSize() { > > Since we are here, you should fix this to add the @return. This does not need to be part of the CSR I've changed my mind on not including these in the CSR based on what is written there - I think we should include it. We wouldn't have needed to include a simple "@return the minimum size" but you do need the extra words somewhere so either way this method needs to be in the CSR ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1459462649 From serb at openjdk.org Fri Jan 19 19:09:30 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 19 Jan 2024 19:09:30 GMT Subject: RFR: 8323108: BufferedImage.setData(Raster) should not cast float and double values to integers In-Reply-To: References: Message-ID: On Thu, 4 May 2023 10:14:10 GMT, Martin Desruisseaux wrote: > The `BufferedImage` Javadoc does not mention any constraint about the data type. In practice, `BufferedImage` with floating point values can be rendered by Java2D as well as integers, provided that a compatible `ColorModel` was supplied at construction time. However calls to `setData(Raster)` unexpectedly cast floating point values to integers. For example sample value 0.8 become 0. This is demonstrated by the `SetData` test case in this pull request. > > An easy fix, which is proposed in this pull request, is to replace the whole `BufferedImage.setData(Raster)` method body by a simple call to `WritableRaster.setRect(Raster)`, which handles all `DataBuffer` types correctly. The method contracts documented in their respective Javadoc are compatible. Furthermore an examination of their source code shows that they are equivalent, except for the differences noted in the _Behavioural changes_ section below. > > # Source code comparison > For demonstrating that delegating to `WritableRaster.setRect(Raster)` would be equivalent to the current code, one can copy the method body and apply the following changes: > > * Remove `dx` parameter, replaced by 0. > * Remove `dy` parameter, replaced by 0. > * Rename `srcRaster` parameter as `r` (like in `BufferedImage`). > * Rename `startY` variable as `i` (like in `BufferedImage`). > * Rename `srcOffX` variable as `startX` (like in `BufferedImage`). > * Rename `srcOffY` variable as `startY` (like in `BufferedImage`). > * Replace `this.minX` by 0 and simplify. > * Replace `this.minY` by 0 and simplify. > * Remove the `switch` statement, keeping only the `TYPE_INT` case. > > Then compare with `BufferedImage.setData(Raster)`. The modified block of code from `WritableRaster` is: > > > int width = r.getWidth(); > int height = r.getHeight(); > int startX = r.getMinX(); > int startY = r.getMinY(); > > We can see that above code is identical to `BufferedImage`. The next modified block of code from `WritableRaster`: > > > int dstOffX = startX; > int dstOffY = startY; > > // Clip to this raster > if (dstOffX < 0) { > width += dstOffX; > startX -= dstOffX; // = 0 because dstOffX == startX > dstOffX = 0; > } > if (dstOffY < 0) { > height += dstOffY; > startY -= dstOffY; // = 0 because dstOffY == startY > dstOffY = 0; > } > if (dstOffX+width > this.width) { > width = this.width - dstOffX; > } > if (dstOffY+height > this.height) { > height = this.height - dstOffY; > } > if (width <= 0 || height <= 0) { > return; > } > > > Above is equivalent to the following code from `BufferedImage`, ex... Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13797#pullrequestreview-1833501028 From duke at openjdk.org Fri Jan 19 19:30:29 2024 From: duke at openjdk.org (ScientificWare) Date: Fri, 19 Jan 2024 19:30:29 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v2] In-Reply-To: References: Message-ID: On Tue, 16 Jan 2024 21:57:31 GMT, Phil Race wrote: >> Waiting for a review. > > @scientificware - are you still working on this ? @prrace Yes but I have to postpone this work. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15319#issuecomment-1900986622 From honkar at openjdk.org Fri Jan 19 21:47:40 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 19 Jan 2024 21:47:40 GMT Subject: Integrated: JDK-8320113: [macos14] : ShapeNotSetSometimes.java fails intermittently on macOS 14 In-Reply-To: References: Message-ID: On Thu, 21 Dec 2023 20:33:53 GMT, Harshitha Onkar wrote: > ShapeNotSetSometimes.java fails intermittently on macOS 14. Following is a test stabilization fix for macOS 14. With the added delays ShapeNotSetSometimes.java passes on older versions of macOS as well as on macOS 14.1, 14.2. This pull request has now been integrated. Changeset: f1b73350 Author: Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/f1b73350c237021c04ceac2f29f1f378630bd651 Stats: 45 lines in 1 file changed: 30 ins; 12 del; 3 mod 8320113: [macos14] : ShapeNotSetSometimes.java fails intermittently on macOS 14 Reviewed-by: dnguyen, azvegint, kizune ------------- PR: https://git.openjdk.org/jdk/pull/17180 From prr at openjdk.org Fri Jan 19 22:19:30 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 19 Jan 2024 22:19:30 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI In-Reply-To: References: Message-ID: <_2WabLf2ATFrCDd5TfnVm5M7CoOEOlCx-IOb32c3Jco=.2e4486f0-0898-4e5e-9552-83a43133799b@github.com> On Wed, 17 Jan 2024 07:19:21 GMT, Prasanta Sadhukhan wrote: > When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak. > When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. > Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500) > > FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method.. src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java line 1338: > 1336: if(rendererPane != null) { > 1337: if (!tree.isVisible()) { > 1338: rendererPane.removeAll(); if( -> if ( Is it actually necessary to check visibility ? But more importantly, in the case of the test in the bug, how and when does this uninstallComponents() method get called ? It isn't clear to me how it changes the reported behaviour of that test. I thought uninstallComponents() is just part of uninstallUI() like when tearing down and freeing the tree, or at least switching L&F .. whereas the submitter seems to be implying nodeChanged() is the problem ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1459885494 From prr at openjdk.org Sat Jan 20 00:44:07 2024 From: prr at openjdk.org (Phil Race) Date: Sat, 20 Jan 2024 00:44:07 GMT Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v46] In-Reply-To: <5WJnl6Z9RyYzZrDStf9p74gus07Stz6S6NHwVpGQO3M=.0a04a120-77b5-48c3-9ae8-7d37c9646463@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> <5WJnl6Z9RyYzZrDStf9p74gus07Stz6S6NHwVpGQO3M=.0a04a120-77b5-48c3-9ae8-7d37c9646463@github.com> Message-ID: On Thu, 11 Jan 2024 08:24:42 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 79 commits: > > - Merge branch 'openjdk:master' into patch-10 > - Merge branch 'openjdk:master' into patch-10 > - Fix awt_Window.cpp > - Fix awt_PrintJob.cpp > - -Zc:stringStrings no longer needed with -permissive- flags-cflags.m4 > - Fix awt_Window.cpp > - awt_Window.cpp > - awt_PrintJob.cpp > - awt_Frame.cpp > - Whitespace awt_Component.cpp > - ... and 69 more: https://git.openjdk.org/jdk/compare/35e96627...cbfbaee6 Changes requested by prr (Reviewer). src/java.desktop/windows/native/libawt/windows/awt_Canvas.cpp line 206: > 204: > 205: void AwtCanvas::_SetEraseBackground(void *param) { > 206: JNIEnv *env = (JNIEnv *) JNU_GetEnv(jvm, JNI_VERSION_1_2); Nits (1) I see no reason to have moved the { - it is now inconsistent with all the rest of the code. (2) Why do we need a SPACE for the cast ? It isn't usual. These things just add to the changes that need to be looked at. Please revert. src/java.desktop/windows/native/libawt/windows/awt_Component.cpp line 6361: > 6359: void AwtComponent::_SetParent(void * param) { > 6360: if (AwtToolkit::IsMainThread()) { > 6361: JNIEnv *env = (JNIEnv *) JNU_GetEnv(jvm, JNI_VERSION_1_2); superflous space again src/java.desktop/windows/native/libawt/windows/awt_Component.cpp line 6366: > 6364: jobject parent = data->parentComp; > 6365: > 6366: AwtComponent *awtComponent = nullptr; Looking at it (not tested) here through 6403 could be simplified as if (self == NULL || parent == NULL) { env->ExceptionClear(); JNU_ThrowNullPointerException(env, "peer"); env->DeleteGlobalRef(self); env->DeleteGlobalRef(parent); delete data; return; } AwtComponent *awtComponent = (AwtComponent *)JNI_GET_PDATA(self); if (awtComponent == NULL) { THROW_NULL_PDATA_IF_NOT_DESTROYED(self); env->DeleteGlobalRef(self); env->DeleteGlobalRef(parent); delete data; return; } AwtComponent *awtParent = (AwtComponent *)JNI_GET_PDATA(parent); if (awtParent == NULL) { THROW_NULL_PDATA_IF_NOT_DESTROYED(parent); env->DeleteGlobalRef(self); env->DeleteGlobalRef(parent); delete data; return; } I think I prefer that over BOOL error = FALSE; AwtComponent *awtComponent = nullptr; AwtComponent *awtParent = nullptr; if (self == NULL || parent == NULL) { env->ExceptionClear(); JNU_ThrowNullPointerException(env, "peer"); error = TRUE; } if (!error) { awtComponent = (AwtComponent *)JNI_GET_PDATA(self); if (awtComponent == NULL) { THROW_NULL_PDATA_IF_NOT_DESTROYED(self); error = TRUE; } } if (!error) { awtParent = (AwtComponent *)JNI_GET_PDATA(parent); if (awtParent == NULL) { THROW_NULL_PDATA_IF_NOT_DESTROYED(parent); error = TRUE; } if (error) { env->DeleteGlobalRef(self); env->DeleteGlobalRef(parent); delete data; return; } src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp line 1340: > 1338: > 1339: void AwtFrame::_SetState(void *param) { > 1340: JNIEnv *env = (JNIEnv *) JNU_GetEnv(jvm, JNI_VERSION_1_2); more un-needed reformatting src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp line 1365: > 1363: f = (AwtFrame *) pData; > 1364: HWND hwnd = f->GetHWnd(); > 1365: if (::IsWindow(hwnd)) { more formatting to revert src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp line 1581: > 1579: void AwtFrame::_NotifyModalBlocked(void *param) > 1580: { > 1581: JNIEnv *env = (JNIEnv *) JNU_GetEnv(jvm, JNI_VERSION_1_2); again .. src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp line 1600: > 1598: return; > 1599: } else { > 1600: pData = JNI_GET_PDATA(peer); like in my recoded case above, we no longer need the "pData" var which was there only because that name is magically known to the macro. src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp line 1624: > 1622: return; > 1623: } else { > 1624: pData = JNI_GET_PDATA(blockerPeer); can directly set dialog src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 1018: > 1016: > 1017: void AwtWindow::_RepositionSecurityWarning(void* param) { > 1018: JNIEnv *env = (JNIEnv *) JNU_GetEnv(jvm, JNI_VERSION_1_2); formatting .. src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 1032: > 1030: } else { > 1031: pData = JNI_GET_PDATA(self); > 1032: if (pData == NULL) { directly set window src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 3127: > 3125: > 3126: void AwtWindow::_ModalDisable(void *param) { > 3127: JNIEnv *env = (JNIEnv *) JNU_GetEnv(jvm, JNI_VERSION_1_2); formatting src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 3137: > 3135: > 3136: PDATA pData = JNI_GET_PDATA(self); > 3137: if (self == NULL) { Surely line 3136 above should have been deleted ? It is replaced by line 3143 below. And then you can also directly set window, pData isn't needed, as discussed in similar cases above src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 3163: > 3161: > 3162: void AwtWindow::_ModalEnable(void *param) { > 3163: JNIEnv *env = (JNIEnv *) JNU_GetEnv(jvm, JNI_VERSION_1_2); fomatting src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 3171: > 3169: > 3170: PDATA pData = JNI_GET_PDATA(self); > 3171: if (self == NULL) { like the method above line 3170 seems wrong. src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 3223: > 3221: > 3222: void AwtWindow::_SetOpaque(void* param) { > 3223: JNIEnv *env = (JNIEnv *) JNU_GetEnv(jvm, JNI_VERSION_1_2); formatting src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 3237: > 3235: } else { > 3236: pData = JNI_GET_PDATA(self); > 3237: if (pData == NULL) { set directly src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 3253: > 3251: > 3252: void AwtWindow::_UpdateWindow(void* param) { > 3253: JNIEnv *env = (JNIEnv *) JNU_GetEnv(jvm, JNI_VERSION_1_2); formatting src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 3269: > 3267: return; > 3268: } else { > 3269: pData = JNI_GET_PDATA(self); set directly src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 3308: > 3306: return; > 3307: } else { > 3308: pData = JNI_GET_PDATA(self); set directly ------------- PR Review: https://git.openjdk.org/jdk/pull/15096#pullrequestreview-1833960495 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1460013033 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1460023492 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1460050708 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1460082135 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1460082645 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1460082873 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1460083533 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1460084160 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1460085276 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1460085458 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1460085719 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1460087127 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1460087785 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1460088414 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1460088776 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1460088996 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1460089073 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1460089276 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1460089490 From honkar at openjdk.org Sat Jan 20 01:11:26 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Sat, 20 Jan 2024 01:11:26 GMT Subject: RFR: 8309460: JScrollBar leaves behind clutter for non-integer UI scales In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 11:09:12 GMT, Prasanta Sadhukhan wrote: > Lines are left behind when moving the scrollbar in the positive direction. but are cleaned up on mouse release. > Additonally, with right arrow clicks too, the lines are left behind. > Seems like for mouseDragged and scrollByUnit, the dirty region of the scrollbar is not repainted leading to artifacts > which is being done in this fix.. test/jdk/javax/swing/JScrollBar/JScrollBarArtifactTest.java line 33: > 31: * @test > 32: * @bug 8309460 > 33: * @summary Verifies clicking JComboBox during frame closure causes Exception summary needs to be updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17484#discussion_r1460107777 From duke at openjdk.org Sat Jan 20 10:43:49 2024 From: duke at openjdk.org (Martin Desruisseaux) Date: Sat, 20 Jan 2024 10:43:49 GMT Subject: RFR: 8323108: BufferedImage.setData(Raster) should not cast float and double values to integers [v2] In-Reply-To: References: Message-ID: <4tOXAOexBnZJNjGQeShDQ7ATQH4Bu0XpUW_HWEQ3ZWM=.2ed252f8-b6ed-44b7-8846-a5b22dd584c4@github.com> > The `BufferedImage` Javadoc does not mention any constraint about the data type. In practice, `BufferedImage` with floating point values can be rendered by Java2D as well as integers, provided that a compatible `ColorModel` was supplied at construction time. However calls to `setData(Raster)` unexpectedly cast floating point values to integers. For example sample value 0.8 become 0. This is demonstrated by the `SetData` test case in this pull request. > > An easy fix, which is proposed in this pull request, is to replace the whole `BufferedImage.setData(Raster)` method body by a simple call to `WritableRaster.setRect(Raster)`, which handles all `DataBuffer` types correctly. The method contracts documented in their respective Javadoc are compatible. Furthermore an examination of their source code shows that they are equivalent, except for the differences noted in the _Behavioural changes_ section below. > > # Source code comparison > For demonstrating that delegating to `WritableRaster.setRect(Raster)` would be equivalent to the current code, one can copy the method body and apply the following changes: > > * Remove `dx` parameter, replaced by 0. > * Remove `dy` parameter, replaced by 0. > * Rename `srcRaster` parameter as `r` (like in `BufferedImage`). > * Rename `startY` variable as `i` (like in `BufferedImage`). > * Rename `srcOffX` variable as `startX` (like in `BufferedImage`). > * Rename `srcOffY` variable as `startY` (like in `BufferedImage`). > * Replace `this.minX` by 0 and simplify. > * Replace `this.minY` by 0 and simplify. > * Remove the `switch` statement, keeping only the `TYPE_INT` case. > > Then compare with `BufferedImage.setData(Raster)`. The modified block of code from `WritableRaster` is: > > > int width = r.getWidth(); > int height = r.getHeight(); > int startX = r.getMinX(); > int startY = r.getMinY(); > > We can see that above code is identical to `BufferedImage`. The next modified block of code from `WritableRaster`: > > > int dstOffX = startX; > int dstOffY = startY; > > // Clip to this raster > if (dstOffX < 0) { > width += dstOffX; > startX -= dstOffX; // = 0 because dstOffX == startX > dstOffX = 0; > } > if (dstOffY < 0) { > height += dstOffY; > startY -= dstOffY; // = 0 because dstOffY == startY > dstOffY = 0; > } > if (dstOffX+width > this.width) { > width = this.width - dstOffX; > } > if (dstOffY+height > this.height) { > height = this.height - dstOffY; > } > if (width <= 0 || height <= 0) { > return; > } > > > Above is equivalent to the following code from `BufferedImage`, ex... Martin Desruisseaux has updated the pull request incrementally with one additional commit since the last revision: Update copyright years. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13797/files - new: https://git.openjdk.org/jdk/pull/13797/files/65eb0072..5d69f631 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13797&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13797&range=00-01 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13797.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13797/head:pull/13797 PR: https://git.openjdk.org/jdk/pull/13797 From duke at openjdk.org Sat Jan 20 11:48:30 2024 From: duke at openjdk.org (Martin Desruisseaux) Date: Sat, 20 Jan 2024 11:48:30 GMT Subject: RFR: 8323108: BufferedImage.setData(Raster) should not cast float and double values to integers [v2] In-Reply-To: <4tOXAOexBnZJNjGQeShDQ7ATQH4Bu0XpUW_HWEQ3ZWM=.2ed252f8-b6ed-44b7-8846-a5b22dd584c4@github.com> References: <4tOXAOexBnZJNjGQeShDQ7ATQH4Bu0XpUW_HWEQ3ZWM=.2ed252f8-b6ed-44b7-8846-a5b22dd584c4@github.com> Message-ID: On Sat, 20 Jan 2024 10:43:49 GMT, Martin Desruisseaux wrote: >> The `BufferedImage` Javadoc does not mention any constraint about the data type. In practice, `BufferedImage` with floating point values can be rendered by Java2D as well as integers, provided that a compatible `ColorModel` was supplied at construction time. However calls to `setData(Raster)` unexpectedly cast floating point values to integers. For example sample value 0.8 become 0. This is demonstrated by the `SetData` test case in this pull request. >> >> An easy fix, which is proposed in this pull request, is to replace the whole `BufferedImage.setData(Raster)` method body by a simple call to `WritableRaster.setRect(Raster)`, which handles all `DataBuffer` types correctly. The method contracts documented in their respective Javadoc are compatible. Furthermore an examination of their source code shows that they are equivalent, except for the differences noted in the _Behavioural changes_ section below. >> >> # Source code comparison >> For demonstrating that delegating to `WritableRaster.setRect(Raster)` would be equivalent to the current code, one can copy the method body and apply the following changes: >> >> * Remove `dx` parameter, replaced by 0. >> * Remove `dy` parameter, replaced by 0. >> * Rename `srcRaster` parameter as `r` (like in `BufferedImage`). >> * Rename `startY` variable as `i` (like in `BufferedImage`). >> * Rename `srcOffX` variable as `startX` (like in `BufferedImage`). >> * Rename `srcOffY` variable as `startY` (like in `BufferedImage`). >> * Replace `this.minX` by 0 and simplify. >> * Replace `this.minY` by 0 and simplify. >> * Remove the `switch` statement, keeping only the `TYPE_INT` case. >> >> Then compare with `BufferedImage.setData(Raster)`. The modified block of code from `WritableRaster` is: >> >> >> int width = r.getWidth(); >> int height = r.getHeight(); >> int startX = r.getMinX(); >> int startY = r.getMinY(); >> >> We can see that above code is identical to `BufferedImage`. The next modified block of code from `WritableRaster`: >> >> >> int dstOffX = startX; >> int dstOffY = startY; >> >> // Clip to this raster >> if (dstOffX < 0) { >> width += dstOffX; >> startX -= dstOffX; // = 0 because dstOffX == startX >> dstOffX = 0; >> } >> if (dstOffY < 0) { >> height += dstOffY; >> startY -= dstOffY; // = 0 because dstOffY == startY >> dstOffY = 0; >> } >> if (dstOffX+width > this.width) { >> width = this.width - dstOffX; >> } >> if (dstOffY+height > this.height) { >> height = this.height - dstOffY; >> } >> if (width <= 0 ||... > > Martin Desruisseaux has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright years. Updated the copyright years to 2024. The pre-submit tests are failing, but I believe that it is because the branch is 8 months old. Should I commit a merge from master? (a test on my local machine suggests that it fixes the issues). ------------- PR Comment: https://git.openjdk.org/jdk/pull/13797#issuecomment-1902073920 From aturbanov at openjdk.org Sat Jan 20 15:07:26 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Sat, 20 Jan 2024 15:07:26 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: On Wed, 17 Jan 2024 12:55:52 GMT, Tejesh R wrote: > Suggested fix [JDK-8307091](https://bugs.openjdk.org/browse/JDK-8307091) also created concurrent exception intermittently (monthly once/quarterly once) on CI system. The issue was not able to be reproduced yet, hence proposing an alternative fix which uses iterators to compare the List. > CI testing shows green. src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java line 417: > 415: } > 416: > 417: private synchronized boolean compareIterators(Iterator iterator1, Iterator iterator2) { I'm not sure I understand, how this `synchronized` helps to avoid the issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1460487345 From serb at openjdk.org Sun Jan 21 00:24:32 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 21 Jan 2024 00:24:32 GMT Subject: RFR: 8323108: BufferedImage.setData(Raster) should not cast float and double values to integers [v2] In-Reply-To: References: <4tOXAOexBnZJNjGQeShDQ7ATQH4Bu0XpUW_HWEQ3ZWM=.2ed252f8-b6ed-44b7-8846-a5b22dd584c4@github.com> Message-ID: On Sat, 20 Jan 2024 11:46:12 GMT, Martin Desruisseaux wrote: > Updated the copyright years to 2024. The pre-submit tests are failing, but I believe that it is because the branch is 8 months old. Should I commit a merge from master? (a test on my local machine suggests that it fixes the issues). Yes, you can merge the master. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13797#issuecomment-1902459971 From serb at openjdk.org Sun Jan 21 00:42:25 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 21 Jan 2024 00:42:25 GMT Subject: RFR: 8309460: JScrollBar leaves behind clutter for non-integer UI scales In-Reply-To: <8W2UV6PmGUlWlSbinEsOZ9nNIDwTml9xzcLcApKz5gw=.959fda59-a216-4676-ac99-f67e62aee8ee@github.com> References: <8W2UV6PmGUlWlSbinEsOZ9nNIDwTml9xzcLcApKz5gw=.959fda59-a216-4676-ac99-f67e62aee8ee@github.com> Message-ID: On Fri, 19 Jan 2024 05:52:34 GMT, Prasanta Sadhukhan wrote: > Also, it might be the case the scrollbar methods like getUnitIncrement, scrollBar.getValue scrollbar.setValue setThumbBounds sets or returns or uses integer value despite scale being non-integer, so I guess repainting dirty region should be done to refresh the artifacts But in the fix and in the places you pointed out we also use the int values, so why is the bug reproduced only when the float scale is used? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17484#issuecomment-1902463567 From honkar at openjdk.org Sun Jan 21 05:14:28 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Sun, 21 Jan 2024 05:14:28 GMT Subject: RFR: 8309460: JScrollBar leaves behind clutter for non-integer UI scales In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 11:09:12 GMT, Prasanta Sadhukhan wrote: > Lines are left behind when moving the scrollbar in the positive direction. but are cleaned up on mouse release. > Additonally, with right arrow clicks too, the lines are left behind. > Seems like for mouseDragged and scrollByUnit, the dirty region of the scrollbar is not repainted leading to artifacts > which is being done in this fix.. The fix works fine. The artifacts or lines are no longer visible. But noticed a couple of things when testing. (Win 11) 1. The lines happen to occur for **non-standard fractional scales** (2.3, 2.7) but work fine for **standard fractional scales** supported by windows (1.25,1.75, 2.25...) 2. The lines are left behind only in one direction - right for horizontal scroll and down for vertical scroll. 3. With the present fix repaint is called each time mouse is dragged or clicked, this results in a lot of calls to repaint during scrolling action. test/jdk/javax/swing/JScrollBar/JScrollBarArtifactTest.java line 42: > 40: private static final String instructionsText = """ > 41: This test is used to verify that dragging scrollbar or clicking > 42: on right scrollbar thumb does nto leave behing lines or artifacts. Suggestion: on right scrollbar thumb does not leave behind lines or artifacts. ------------- PR Review: https://git.openjdk.org/jdk/pull/17484#pullrequestreview-1834275178 PR Review Comment: https://git.openjdk.org/jdk/pull/17484#discussion_r1460131311 From jwaters at openjdk.org Sun Jan 21 07:45:14 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 21 Jan 2024 07:45:14 GMT Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v47] In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: <92qTOlwPdWHJjKXVYfgo5f1sbes1sAdUxfK_LAV2bGQ=.4835dc82-93ad-4ae2-bbb6-baba635d26aa@github.com> > We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. Julian Waters has updated the pull request incrementally with two additional commits since the last revision: - awt_Component.cpp - awt_Canvas.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15096/files - new: https://git.openjdk.org/jdk/pull/15096/files/cbfbaee6..07b00de2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=46 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=45-46 Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15096.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15096/head:pull/15096 PR: https://git.openjdk.org/jdk/pull/15096 From jwaters at openjdk.org Sun Jan 21 07:51:14 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 21 Jan 2024 07:51:14 GMT Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v48] In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: > We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: awt_Frame.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15096/files - new: https://git.openjdk.org/jdk/pull/15096/files/07b00de2..ffe5ef13 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=47 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=46-47 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/15096.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15096/head:pull/15096 PR: https://git.openjdk.org/jdk/pull/15096 From jwaters at openjdk.org Sun Jan 21 07:55:13 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 21 Jan 2024 07:55:13 GMT Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v49] In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: > We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: awt_Window.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15096/files - new: https://git.openjdk.org/jdk/pull/15096/files/ffe5ef13..470c8bb2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=48 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=47-48 Stats: 15 lines in 1 file changed: 5 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/15096.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15096/head:pull/15096 PR: https://git.openjdk.org/jdk/pull/15096 From jwaters at openjdk.org Sun Jan 21 07:58:11 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 21 Jan 2024 07:58:11 GMT Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v50] In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: > We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 84 commits: - Merge branch 'openjdk:master' into patch-10 - awt_Window.cpp - awt_Frame.cpp - awt_Component.cpp - awt_Canvas.cpp - Merge branch 'openjdk:master' into patch-10 - Merge branch 'openjdk:master' into patch-10 - Fix awt_Window.cpp - Fix awt_PrintJob.cpp - -Zc:stringStrings no longer needed with -permissive- flags-cflags.m4 - ... and 74 more: https://git.openjdk.org/jdk/compare/a474b372...0f34608b ------------- Changes: https://git.openjdk.org/jdk/pull/15096/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=49 Stats: 590 lines in 12 files changed: 461 ins; 30 del; 99 mod Patch: https://git.openjdk.org/jdk/pull/15096.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15096/head:pull/15096 PR: https://git.openjdk.org/jdk/pull/15096 From jwaters at openjdk.org Sun Jan 21 07:58:11 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 21 Jan 2024 07:58:11 GMT Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v49] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Sun, 21 Jan 2024 07:55:13 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > awt_Window.cpp Fixed the formatting (at least in the marked cases), but am unsure what you mean by set directly? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1902545943 From lbourges at openjdk.org Sun Jan 21 10:56:26 2024 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Sun, 21 Jan 2024 10:56:26 GMT Subject: RFR: JDK-8323695 RenderPerf (2D) enhancements (23.12) In-Reply-To: References: <13rvTg4QWBKawohFsLhUv8n_7j5xhbcJzTm1IpZQtMo=.2fc70458-f4a1-41ab-bb4b-8e4f49db0148@github.com> <9f_Ek67AqpjSx-dGyKQD61-vhTTNXD5zi9BilQAt04Y=.c7679726-54b8-4e35-a486-7f876564ed1f@github.com> Message-ID: On Thu, 18 Jan 2024 21:35:37 GMT, Phil Race wrote: >> Of course, I will make constant Font instances (no new Font() in benchmark code!) and use family name (Dialog or SansSerif), what do you prefer? > > either dialog or sansserif. Dialog is the default font so perhaps that. Dialog by default. After discussion, it may be useful to have new cli args: --font=name --fontSize=... --text="" Special fonts with ligature or complex cases could then be tested... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17408#discussion_r1460807639 From duke at openjdk.org Sun Jan 21 12:20:57 2024 From: duke at openjdk.org (Martin Desruisseaux) Date: Sun, 21 Jan 2024 12:20:57 GMT Subject: RFR: 8323108: BufferedImage.setData(Raster) should not cast float and double values to integers [v3] In-Reply-To: References: Message-ID: <9GzkUdUrHRGLQu2LO-5Gs1GW7mGx8qpxPBqFvnZDa_4=.16da0e72-09c8-4ffe-9004-0a03105b7ee6@github.com> > The `BufferedImage` Javadoc does not mention any constraint about the data type. In practice, `BufferedImage` with floating point values can be rendered by Java2D as well as integers, provided that a compatible `ColorModel` was supplied at construction time. However calls to `setData(Raster)` unexpectedly cast floating point values to integers. For example sample value 0.8 become 0. This is demonstrated by the `SetData` test case in this pull request. > > An easy fix, which is proposed in this pull request, is to replace the whole `BufferedImage.setData(Raster)` method body by a simple call to `WritableRaster.setRect(Raster)`, which handles all `DataBuffer` types correctly. The method contracts documented in their respective Javadoc are compatible. Furthermore an examination of their source code shows that they are equivalent, except for the differences noted in the _Behavioural changes_ section below. > > # Source code comparison > For demonstrating that delegating to `WritableRaster.setRect(Raster)` would be equivalent to the current code, one can copy the method body and apply the following changes: > > * Remove `dx` parameter, replaced by 0. > * Remove `dy` parameter, replaced by 0. > * Rename `srcRaster` parameter as `r` (like in `BufferedImage`). > * Rename `startY` variable as `i` (like in `BufferedImage`). > * Rename `srcOffX` variable as `startX` (like in `BufferedImage`). > * Rename `srcOffY` variable as `startY` (like in `BufferedImage`). > * Replace `this.minX` by 0 and simplify. > * Replace `this.minY` by 0 and simplify. > * Remove the `switch` statement, keeping only the `TYPE_INT` case. > > Then compare with `BufferedImage.setData(Raster)`. The modified block of code from `WritableRaster` is: > > > int width = r.getWidth(); > int height = r.getHeight(); > int startX = r.getMinX(); > int startY = r.getMinY(); > > We can see that above code is identical to `BufferedImage`. The next modified block of code from `WritableRaster`: > > > int dstOffX = startX; > int dstOffY = startY; > > // Clip to this raster > if (dstOffX < 0) { > width += dstOffX; > startX -= dstOffX; // = 0 because dstOffX == startX > dstOffX = 0; > } > if (dstOffY < 0) { > height += dstOffY; > startY -= dstOffY; // = 0 because dstOffY == startY > dstOffY = 0; > } > if (dstOffX+width > this.width) { > width = this.width - dstOffX; > } > if (dstOffY+height > this.height) { > height = this.height - dstOffY; > } > if (width <= 0 || height <= 0) { > return; > } > > > Above is equivalent to the following code from `BufferedImage`, ex... Martin Desruisseaux has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into fix/set-data - Update copyright years. - Use Rectangle.intersection(Rectangle) in WritableRaster.setRect(int, int, Raster) for safety against integer underflow/overflow. That commit reproduces the safety that existed in the BufferedImage.setData(Raster) method which has been replaced in previous commit. - `BufferedImage.setData(Raster)` should not cast float and double values to integers. The easiest fix is to delegate to `WritableRaster.setRect(Raster)`. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13797/files - new: https://git.openjdk.org/jdk/pull/13797/files/5d69f631..fd0b8045 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13797&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13797&range=01-02 Stats: 1431853 lines in 13587 files changed: 555220 ins; 698691 del; 177942 mod Patch: https://git.openjdk.org/jdk/pull/13797.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13797/head:pull/13797 PR: https://git.openjdk.org/jdk/pull/13797 From duke at openjdk.org Sun Jan 21 16:38:36 2024 From: duke at openjdk.org (Sam James) Date: Sun, 21 Jan 2024 16:38:36 GMT Subject: RFR: 8324243: Fix GCC 14 build Message-ID: This fixes building with GCC 14: * Cherry-pick a fix from Harfbuzz upstream * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses -Werror. The calloc prototype is: void *calloc(size_t nmemb, size_t size); So, just swap the number of members and size arguments to match the prototype, as we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're not doing anything wrong. ------------- Commit messages: - 8324243: Fix -Wcalloc-transposed-args (GCC 14 build) - harfbuzz: Cherry-pick upstream fix for GCC 14 Changes: https://git.openjdk.org/jdk/pull/17506/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17506&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324243 Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/17506.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17506/head:pull/17506 PR: https://git.openjdk.org/jdk/pull/17506 From jwaters at openjdk.org Sun Jan 21 16:38:36 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 21 Jan 2024 16:38:36 GMT Subject: RFR: 8324243: Fix GCC 14 build In-Reply-To: References: Message-ID: On Sat, 20 Jan 2024 10:15:02 GMT, Sam James wrote: > This fixes building with GCC 14: > * Cherry-pick a fix from Harfbuzz upstream > * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources > > -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses > -Werror. > > The calloc prototype is: > > void *calloc(size_t nmemb, size_t size); > > > So, just swap the number of members and size arguments to match the prototype, as > we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're not > doing anything wrong. @thesamesam Unfortunately we can't fix the harfbuzz sources, since they are third party code. Your changes to harfbuzz code wouldn't be accepted by the client team :( I don't believe harfbuzz has been bumped into a specific commit before, so I'm not sure about that. Perhaps you could wait till Phil sees this, for a conclusive answer You'd need a issue on the tracker to connect to this Pull Request for anyone to see this (most reviewers don't go through these manually, they come from the mailing lists). Are you able to create one yourself, or should I create one for you? No problem! Just change your Pull Request title to 8324243 (The literal number) and watch the magic happen :) By the way, your name strikes me as familiar. Have I seen you before on the gcc mailing lists? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17506#issuecomment-1902511768 PR Comment: https://git.openjdk.org/jdk/pull/17506#issuecomment-1902513832 PR Comment: https://git.openjdk.org/jdk/pull/17506#issuecomment-1902515437 PR Comment: https://git.openjdk.org/jdk/pull/17506#issuecomment-1902537711 From duke at openjdk.org Sun Jan 21 16:38:37 2024 From: duke at openjdk.org (Sam James) Date: Sun, 21 Jan 2024 16:38:37 GMT Subject: RFR: 8324243: Fix GCC 14 build In-Reply-To: References: Message-ID: <_pgy2Noft99jumD5FE-jphaZHdAaWMGLIAhizxYK8i8=.4e874b21-62bd-4d15-8037-00a75a314516@github.com> On Sun, 21 Jan 2024 04:57:26 GMT, Julian Waters wrote: > @thesamesam Unfortunately we can't fix the harfbuzz sources, since they are third party code. Your changes to harfbuzz code wouldn't be accepted by the client team :( Bleh. I don't suppose any exception can be made given it's a cherry-pick (i.e. my changes there are _not_ original, they're upstream, just not in a release)? If not, I can just drop that bit, and we can wait until a new Harfbuzz release is made and propagates into OpenJDK. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17506#issuecomment-1902512887 From duke at openjdk.org Sun Jan 21 16:38:38 2024 From: duke at openjdk.org (Sam James) Date: Sun, 21 Jan 2024 16:38:38 GMT Subject: RFR: 8324243: Fix GCC 14 build In-Reply-To: References: Message-ID: <8b9dRQBHIO20GAfd23dzSMxuVOo2_wWSH7PqDp6XyTc=.b209ff4f-28fe-4540-8b64-87e00e6a255a@github.com> On Sat, 20 Jan 2024 10:15:02 GMT, Sam James wrote: > This fixes building with GCC 14: > * Cherry-pick a fix from Harfbuzz upstream > * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources > > -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses > -Werror. > > The calloc prototype is: > > void *calloc(size_t nmemb, size_t size); > > > So, just swap the number of members and size arguments to match the prototype, as > we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're not > doing anything wrong. ok - if I have to drop it, so be it, not the end of the world. I guess it's also tricky because of cherry-picking one change vs bumping to some git commit upstream as a whole. I'll wait a little bit then just drop if nobody chimes in. Thank you! Would you be so kind to file one for me please? I don't have access yet. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17506#issuecomment-1902514432 PR Comment: https://git.openjdk.org/jdk/pull/17506#issuecomment-1902516320 From duke at openjdk.org Sun Jan 21 16:45:25 2024 From: duke at openjdk.org (Sam James) Date: Sun, 21 Jan 2024 16:45:25 GMT Subject: RFR: 8324243: Fix GCC 14 build In-Reply-To: References: Message-ID: On Sun, 21 Jan 2024 07:09:54 GMT, Julian Waters wrote: > No problem! > Many thanks! > Just change your Pull Request title to 8324243 (The literal number) and watch the magic happen :) > > By the way, your name strikes me as familiar. Have I seen you before on the gcc mailing lists? You know, now you say it, I think we have interacted before actually - either on the GCC ML or bugzilla! I tend to pop up in a lot of places just because we have a lot of users with a lot of different odd and interesting environments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17506#issuecomment-1902690933 From jwaters at openjdk.org Sun Jan 21 16:53:24 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 21 Jan 2024 16:53:24 GMT Subject: RFR: 8324243: Fix GCC 14 build In-Reply-To: References: Message-ID: On Sat, 20 Jan 2024 10:15:02 GMT, Sam James wrote: > This fixes building with GCC 14: > * Cherry-pick a fix from Harfbuzz upstream > * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources > > -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses > -Werror. > > The calloc prototype is: > > void *calloc(size_t nmemb, size_t size); > > > So, just swap the number of members and size arguments to match the prototype, as > we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're not > doing anything wrong. Marked as reviewed by jwaters (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17506#pullrequestreview-1835378385 From jwaters at openjdk.org Sun Jan 21 16:53:26 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 21 Jan 2024 16:53:26 GMT Subject: RFR: 8324243: Fix GCC 14 build In-Reply-To: References: Message-ID: On Sun, 21 Jan 2024 16:42:40 GMT, Sam James wrote: > > No problem! > > Many thanks! > > > Just change your Pull Request title to 8324243 (The literal number) and watch the magic happen :) > > By the way, your name strikes me as familiar. Have I seen you before on the gcc mailing lists? > > You know, now you say it, I think we have interacted before actually - either on the GCC ML or bugzilla! I tend to pop up in a lot of places just because we have a lot of users with a lot of different odd and interesting environments. Ah! I think you might be the same Sam James in my thread about adding the invalid-noreturn warning to gcc (Which ultimately didn't get anywhere). Glad to meet you again! :) This Pull Request might be related to client libs code, but given its nature I'd consider it a build-dev issue too, in which case, have a thumbs up from me, since that is my domain. Thanks, and welcome to OpenJDK if you're new here! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17506#issuecomment-1902693542 From duke at openjdk.org Sun Jan 21 16:58:24 2024 From: duke at openjdk.org (Sam James) Date: Sun, 21 Jan 2024 16:58:24 GMT Subject: RFR: 8324243: Fix GCC 14 build In-Reply-To: References: Message-ID: <5kNFvGNmbfMBSsbDDQdI9zFRT_MGovHUIqj0x71qTR4=.60349dfd-45e6-4e8d-b012-f13691387554@github.com> On Sat, 20 Jan 2024 10:15:02 GMT, Sam James wrote: > This fixes building with GCC 14: > * Cherry-pick a fix from Harfbuzz upstream > * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources > > -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses > -Werror. > > The calloc prototype is: > > void *calloc(size_t nmemb, size_t size); > > > So, just swap the number of members and size arguments to match the prototype, as > we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're not > doing anything wrong. Ah, yes! FWIW, I'm still disappointed about that as well (I don't have any sort of power, just tend to do a lot of triage). Do consider sending it again when stage 1 opens again after GCC 14 is out. Persistence is key with GCC, even if your change isn't an objectionable one. It took me a little while to get used to that.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17506#issuecomment-1902694647 From prr at openjdk.org Sun Jan 21 19:53:02 2024 From: prr at openjdk.org (Phil Race) Date: Sun, 21 Jan 2024 19:53:02 GMT Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v49] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Sun, 21 Jan 2024 07:55:16 GMT, Julian Waters wrote: > Fixed the formatting (at least in the marked cases), but am unsure what you mean by set directly? See my comment "like in my recoded case above, we no longer need the "pData" var which was there only because that name is magically known to the macro." so skip (and get rid of) the pData var and just set the target var directly ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1902742055 From duke at openjdk.org Sun Jan 21 23:50:40 2024 From: duke at openjdk.org (Martin Desruisseaux) Date: Sun, 21 Jan 2024 23:50:40 GMT Subject: Integrated: 8323108: BufferedImage.setData(Raster) should not cast float and double values to integers In-Reply-To: References: Message-ID: On Thu, 4 May 2023 10:14:10 GMT, Martin Desruisseaux wrote: > The `BufferedImage` Javadoc does not mention any constraint about the data type. In practice, `BufferedImage` with floating point values can be rendered by Java2D as well as integers, provided that a compatible `ColorModel` was supplied at construction time. However calls to `setData(Raster)` unexpectedly cast floating point values to integers. For example sample value 0.8 become 0. This is demonstrated by the `SetData` test case in this pull request. > > An easy fix, which is proposed in this pull request, is to replace the whole `BufferedImage.setData(Raster)` method body by a simple call to `WritableRaster.setRect(Raster)`, which handles all `DataBuffer` types correctly. The method contracts documented in their respective Javadoc are compatible. Furthermore an examination of their source code shows that they are equivalent, except for the differences noted in the _Behavioural changes_ section below. > > # Source code comparison > For demonstrating that delegating to `WritableRaster.setRect(Raster)` would be equivalent to the current code, one can copy the method body and apply the following changes: > > * Remove `dx` parameter, replaced by 0. > * Remove `dy` parameter, replaced by 0. > * Rename `srcRaster` parameter as `r` (like in `BufferedImage`). > * Rename `startY` variable as `i` (like in `BufferedImage`). > * Rename `srcOffX` variable as `startX` (like in `BufferedImage`). > * Rename `srcOffY` variable as `startY` (like in `BufferedImage`). > * Replace `this.minX` by 0 and simplify. > * Replace `this.minY` by 0 and simplify. > * Remove the `switch` statement, keeping only the `TYPE_INT` case. > > Then compare with `BufferedImage.setData(Raster)`. The modified block of code from `WritableRaster` is: > > > int width = r.getWidth(); > int height = r.getHeight(); > int startX = r.getMinX(); > int startY = r.getMinY(); > > We can see that above code is identical to `BufferedImage`. The next modified block of code from `WritableRaster`: > > > int dstOffX = startX; > int dstOffY = startY; > > // Clip to this raster > if (dstOffX < 0) { > width += dstOffX; > startX -= dstOffX; // = 0 because dstOffX == startX > dstOffX = 0; > } > if (dstOffY < 0) { > height += dstOffY; > startY -= dstOffY; // = 0 because dstOffY == startY > dstOffY = 0; > } > if (dstOffX+width > this.width) { > width = this.width - dstOffX; > } > if (dstOffY+height > this.height) { > height = this.height - dstOffY; > } > if (width <= 0 || height <= 0) { > return; > } > > > Above is equivalent to the following code from `BufferedImage`, ex... This pull request has now been integrated. Changeset: 2003610b Author: Martin Desruisseaux Committer: Phil Race URL: https://git.openjdk.org/jdk/commit/2003610b3b52eed04de6713a2a36151d0d86d7c9 Stats: 173 lines in 3 files changed: 120 ins; 47 del; 6 mod 8323108: BufferedImage.setData(Raster) should not cast float and double values to integers Reviewed-by: prr, bpb, serb ------------- PR: https://git.openjdk.org/jdk/pull/13797 From serb at openjdk.org Mon Jan 22 00:36:28 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 22 Jan 2024 00:36:28 GMT Subject: RFR: 8320692: Null icon returned for .exe without custom icon [v2] In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 19:40:40 GMT, Alexander Zuev wrote: >> Replaced asserts with NullPointerException calls because outside of testing that would be more informative - i do not think many people running their applications with assertions in system libraries enabled; >> Added a code that will analyze the result of the getIcon and will fall back to the default icon for the file type retrieved from the ShellFolder; >> Added a test case made by Aleksei Ivanov. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Revert NPE to asserts > Move null check inside the loop so we do not retrieve extra > icons if we encounter a null one test/jdk/javax/swing/JFileChooser/FileSystemView/NoIconExeNPE.java line 264: > 262: FileSystemView fsv = FileSystemView.getFileSystemView(); > 263: // No NullPointerException is expected > 264: fsv.getSystemIcon(hello.toFile()); Maybe we should check that something useful is returned? at least non-null VS null value? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17475#discussion_r1461241572 From duke at openjdk.org Mon Jan 22 05:39:25 2024 From: duke at openjdk.org (vtstydev) Date: Mon, 22 Jan 2024 05:39:25 GMT Subject: RFR: 8307246 : Printing: banded raster path doesn't account for device offset values In-Reply-To: References: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com> Message-ID: <7UFF5tqngpQSmNxDpLnPk3zYdDM1C713Y0OaTDA9VU0=.856b4b31-c502-4706-b877-15f7636c40f0@github.com> On Fri, 8 Dec 2023 21:55:31 GMT, Phil Race wrote: >> More correct way to take in consideration nonzero PHYSICALOFFSETX, PHYSICALOFFSETY of device for banded-raster printing loop. Only on Windows platform under certain conditions real device prints shifted image on paper. > > The PR title needs to change to match the bug. > Actually the bug summary is awful, so I'll fix that first then the PR needs to change to match what I've done there. @prrace The system is about to close this PR. Is there a chance for your time to be taken for it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17030#issuecomment-1903294320 From psadhukhan at openjdk.org Mon Jan 22 06:20:31 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 22 Jan 2024 06:20:31 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v8] In-Reply-To: References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> <4qlxE0k7KXnrw916s7DAGfYQbgLdrPmcSDfQdIRGTkw=.a21d1290-750f-4ae9-9f75-5f97ee2e8734@github.com> Message-ID: On Fri, 19 Jan 2024 18:03:37 GMT, Phil Race wrote: >> src/java.desktop/share/classes/javax/swing/JScrollBar.java line 784: >> >>> 782: * rigid along the other axis. >>> 783: */ >>> 784: public Dimension getMinimumSize() { >> >> Since we are here, you should fix this to add the @return. This does not need to be part of the CSR > > I've changed my mind on not including these in the CSR based on what is written there - I think we should include it. > We wouldn't have needed to include a simple > "@return the minimum size" > > but you do need the extra words somewhere so either way this method needs to be in the CSR I have added @return javadoc change in the CSR.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1461391606 From psadhukhan at openjdk.org Mon Jan 22 06:32:26 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 22 Jan 2024 06:32:26 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI In-Reply-To: <_2WabLf2ATFrCDd5TfnVm5M7CoOEOlCx-IOb32c3Jco=.2e4486f0-0898-4e5e-9552-83a43133799b@github.com> References: <_2WabLf2ATFrCDd5TfnVm5M7CoOEOlCx-IOb32c3Jco=.2e4486f0-0898-4e5e-9552-83a43133799b@github.com> Message-ID: On Fri, 19 Jan 2024 22:16:46 GMT, Phil Race wrote: >> When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak. >> When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. >> Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500) >> >> FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method.. > > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java line 1338: > >> 1336: if(rendererPane != null) { >> 1337: if (!tree.isVisible()) { >> 1338: rendererPane.removeAll(); > > if( -> if ( > > Is it actually necessary to check visibility ? > > But more importantly, in the case of the test in the bug, how and when does this uninstallComponents() method get called ? It isn't clear to me how it changes the reported behaviour of that test. > > I thought uninstallComponents() is just part of uninstallUI() like when tearing down and freeing the tree, or at least switching L&F .. whereas the submitter seems to be implying nodeChanged() is the problem Yes, the submitter mentioned during nodeChanged() but I mentioned it before [in this comment](https://github.com/openjdk/jdk/pull/17458#issuecomment-1897684665) that the comment present, implied it's not an issue, if the component is not removed if UI is not changed (as it is in the case when tree is not visible)...I am not sure why it was added and when but should we ignore that comment and try to remove the component even if tree is not visible (and UI is not changing)? I went with the thought that the coder meant what he said and I freed the components at the end (as you told during tearing down) so that there is no leak.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1461398341 From tr at openjdk.org Mon Jan 22 06:53:26 2024 From: tr at openjdk.org (Tejesh R) Date: Mon, 22 Jan 2024 06:53:26 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: On Sat, 20 Jan 2024 15:05:09 GMT, Andrey Turbanov wrote: >> Suggested fix [JDK-8307091](https://bugs.openjdk.org/browse/JDK-8307091) also created concurrent exception intermittently (monthly once/quarterly once) on CI system. The issue was not able to be reproduced yet, hence proposing an alternative fix which uses iterators to compare the List. >> CI testing shows green. > > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java line 417: > >> 415: } >> 416: >> 417: private synchronized boolean compareIterators(Iterator iterator1, Iterator iterator2) { > > I'm not sure I understand, how this `synchronized` helps to avoid the issue. Since concurrent modification exception is thrown, it is clear that the List is being modified while comparing two list. Hence instead of copying the list locally, I have used iterators and comparing element by element in a `synchronized` method which ensures single thread is accessing the iterators. Without `synchronized` I guess it would again cause `concurrentModificationException`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1461412618 From aturbanov at openjdk.org Mon Jan 22 07:13:28 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 22 Jan 2024 07:13:28 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: On Mon, 22 Jan 2024 06:50:21 GMT, Tejesh R wrote: >> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java line 417: >> >>> 415: } >>> 416: >>> 417: private synchronized boolean compareIterators(Iterator iterator1, Iterator iterator2) { >> >> I'm not sure I understand, how this `synchronized` helps to avoid the issue. > > Since concurrent modification exception is thrown, it is clear that the List is being modified while comparing two list. Hence instead of copying the list locally, I have used iterators and comparing element by element in a `synchronized` method which ensures single thread is accessing the iterators. Without `synchronized` I guess it would again cause `concurrentModificationException`. Vector.iterator and Vector.subList.iterator are still check for modification on iteration (see usages of the method `java.util.AbstractList.SubList#checkForComodification`). It means, if vector was concurrently modified during iteration - iteration will fail with the `ConcurrentModificationException` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1461427786 From tr at openjdk.org Mon Jan 22 07:30:26 2024 From: tr at openjdk.org (Tejesh R) Date: Mon, 22 Jan 2024 07:30:26 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: On Mon, 22 Jan 2024 07:11:08 GMT, Andrey Turbanov wrote: >> Since concurrent modification exception is thrown, it is clear that the List is being modified while comparing two list. Hence instead of copying the list locally, I have used iterators and comparing element by element in a `synchronized` method which ensures single thread is accessing the iterators. Without `synchronized` I guess it would again cause `concurrentModificationException`. > > Vector.iterator and Vector.subList.iterator are still check for modification on iteration (see usages of the method `java.util.AbstractList.SubList#checkForComodification`). It means, if vector was concurrently modified during iteration - iteration will fail with the `ConcurrentModificationException` Yes, which is why I am using Synchronized to handle `concurrentModificationException`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1461440337 From aturbanov at openjdk.org Mon Jan 22 07:41:26 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 22 Jan 2024 07:41:26 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: On Mon, 22 Jan 2024 07:27:50 GMT, Tejesh R wrote: >> Vector.iterator and Vector.subList.iterator are still check for modification on iteration (see usages of the method `java.util.AbstractList.SubList#checkForComodification`). It means, if vector was concurrently modified during iteration - iteration will fail with the `ConcurrentModificationException` > > Yes, which is why I am using Synchronized to handle `concurrentModificationException`. It doesn't work like this. Modification happen in another thread in another method. This `synchronized` doesn't affect another method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1461448973 From tr at openjdk.org Mon Jan 22 08:36:26 2024 From: tr at openjdk.org (Tejesh R) Date: Mon, 22 Jan 2024 08:36:26 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: On Mon, 22 Jan 2024 07:39:04 GMT, Andrey Turbanov wrote: >> Yes, which is why I am using Synchronized to handle `concurrentModificationException`. > > It doesn't work like this. Modification happen in another thread in another method. This `synchronized` doesn't affect another method. "_Synchronized methods enable a simple strategy for preventing thread interference and memory consistency errors: if an object is visible to more than one thread, all reads or writes to that object's variables are done through synchronized methods_" as per this statement from the doc ([Synchronized Methods](https://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html)) it should be handled right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1461496876 From aturbanov at openjdk.org Mon Jan 22 08:36:27 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 22 Jan 2024 08:36:27 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: On Mon, 22 Jan 2024 08:30:05 GMT, Tejesh R wrote: >> It doesn't work like this. Modification happen in another thread in another method. This `synchronized` doesn't affect another method. > > "_Synchronized methods enable a simple strategy for preventing thread interference and memory consistency errors: if an object is visible to more than one thread, all reads or writes to that object's variables are done through synchronized methods_" as per this statement from the doc ([Synchronized Methods](https://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html)) it should be handled right? _all reads or writes to that object's variables are done through synchronized methods_ This is a key requirement. In your case you have added `synchronized` only to a method, which reads that object. But a writer is not `synchronized` in you case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1461498796 From tr at openjdk.org Mon Jan 22 08:40:27 2024 From: tr at openjdk.org (Tejesh R) Date: Mon, 22 Jan 2024 08:40:27 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: On Mon, 22 Jan 2024 08:31:57 GMT, Andrey Turbanov wrote: >> "_Synchronized methods enable a simple strategy for preventing thread interference and memory consistency errors: if an object is visible to more than one thread, all reads or writes to that object's variables are done through synchronized methods_" as per this statement from the doc ([Synchronized Methods](https://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html)) it should be handled right? > > _all reads or writes to that object's variables are done through synchronized methods_ > > This is a key requirement. In your case you have added `synchronized` only to a method, which reads that object. But a writer is not `synchronized` in you case. As per my analysis `fileCache` is synchronized in other places also. Do you notice any places where it is not synchronized? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1461504502 From aturbanov at openjdk.org Mon Jan 22 09:22:27 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 22 Jan 2024 09:22:27 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: On Mon, 22 Jan 2024 08:37:24 GMT, Tejesh R wrote: >> _all reads or writes to that object's variables are done through synchronized methods_ >> >> This is a key requirement. In your case you have added `synchronized` only to a method, which reads that object. But a writer is not `synchronized` in you case. > > As per my analysis `fileCache` is synchronized in other places also. Do you notice any places where it is not synchronized? `synchronized` _works_ only if synchronized object is the same in all places. In the new method "synchronized object" - is an instance of `FilesLoader`, while in other places `fileCache` is accessed under `synchronized(fileCache)`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1461554583 From tr at openjdk.org Mon Jan 22 09:37:26 2024 From: tr at openjdk.org (Tejesh R) Date: Mon, 22 Jan 2024 09:37:26 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: On Mon, 22 Jan 2024 09:19:26 GMT, Andrey Turbanov wrote: >> As per my analysis `fileCache` is synchronized in other places also. Do you notice any places where it is not synchronized? > > `synchronized` _works_ only if synchronized object is the same in all places. In the new method "synchronized object" - is an instance of `FilesLoader`, while in other places `fileCache` is accessed under `synchronized(fileCache)`. Then adding `synchronized(fileCache)` in `FilesLoader` where list comparison happens would be better idea? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1461574564 From aivanov at openjdk.org Mon Jan 22 16:25:32 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 22 Jan 2024 16:25:32 GMT Subject: RFR: 8320692: Null icon returned for .exe without custom icon [v2] In-Reply-To: References: Message-ID: On Mon, 22 Jan 2024 00:33:34 GMT, Sergey Bylokhov wrote: > Maybe we should check that something useful is returned? at least non-null VS null value? Makes sense to ensure the returned value is not `null`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17475#discussion_r1462102856 From aivanov at openjdk.org Mon Jan 22 17:47:29 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 22 Jan 2024 17:47:29 GMT Subject: RFR: 8309460: JScrollBar leaves behind clutter for non-integer UI scales In-Reply-To: References: <8W2UV6PmGUlWlSbinEsOZ9nNIDwTml9xzcLcApKz5gw=.959fda59-a216-4676-ac99-f67e62aee8ee@github.com> Message-ID: On Sun, 21 Jan 2024 00:39:38 GMT, Sergey Bylokhov wrote: > > Also, it might be the case the scrollbar methods like getUnitIncrement, scrollBar.getValue scrollbar.setValue setThumbBounds sets or returns or uses integer value despite scale being non-integer, so I guess repainting dirty region should be done to refresh the artifacts > > But in the fix and in the places you pointed out we also use the int values, so why is the bug reproduced only when the float scale is used? Because float scale results in fractional pixels? If the scale is 1.25, then 1 pixel is 1.25 physical pixels; 2 pixels are 2.5 physical pixels and so on. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17484#issuecomment-1904501940 From aivanov at openjdk.org Mon Jan 22 18:13:26 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 22 Jan 2024 18:13:26 GMT Subject: RFR: 8309460: JScrollBar leaves behind clutter for non-integer UI scales In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 11:09:12 GMT, Prasanta Sadhukhan wrote: > Lines are left behind when moving the scrollbar in the positive direction. but are cleaned up on mouse release. > Additonally, with right arrow clicks too, the lines are left behind. > Seems like for mouseDragged and scrollByUnit, the dirty region of the scrollbar is not repainted leading to artifacts > which is being done in this fix.. However, I don't quite understand how repainting helps. I could understand if you enlarged the rectangle along the orientation axis by 1 pixel in either direction, this would ensure any fractional pixels would always be repainted. Is this bug similar to [JDK-8032219](https://bugs.openjdk.org/browse/JDK-8032219)? src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1192: > 1190: scrollByUnits(scrollbar, direction, 1, false); > 1191: Rectangle r = getTrackBounds(); > 1192: scrollbar.repaint(r.x, r.y, r.width, r.height); Suggestion: scrollbar.repaint(getTrackBounds()); ------------- PR Review: https://git.openjdk.org/jdk/pull/17484#pullrequestreview-1837060367 PR Review Comment: https://git.openjdk.org/jdk/pull/17484#discussion_r1462226407 From aivanov at openjdk.org Mon Jan 22 18:28:28 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 22 Jan 2024 18:28:28 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI In-Reply-To: References: Message-ID: <-7uQOOWcTCl_5TYeYXVYYwx9OKE4wir9WGEdHYtql80=.9a42231f-b3b4-4fb3-ac9b-b426a78e3663@github.com> On Wed, 17 Jan 2024 07:19:21 GMT, Prasanta Sadhukhan wrote: > When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak. > When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. > Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500) > > FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method.. src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java line 1338: > 1336: if(rendererPane != null) { > 1337: if (!tree.isVisible()) { > 1338: rendererPane.removeAll(); Wouldn't it be enough to remove `rendererPane` from and assign `null` to it? It's done this way in `BasicTableUI` and `BasicListUI`: https://github.com/openjdk/jdk/blob/0d8543d6773a516dad54038070dce507179d0709/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java#L1656-L1658 and https://github.com/openjdk/jdk/blob/0d8543d6773a516dad54038070dce507179d0709/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicListUI.java#L986-L988 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1462246022 From aivanov at openjdk.org Mon Jan 22 18:37:25 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 22 Jan 2024 18:37:25 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI In-Reply-To: References: Message-ID: <5MSk5-lrj1cQspd5nee8TuKIBVT39UtaF-24WAAv2fk=.3a224a4a-d8d3-4e2e-bcd2-814095443249@github.com> On Wed, 17 Jan 2024 07:19:21 GMT, Prasanta Sadhukhan wrote: > When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak. > When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. > Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500) > > FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method.. > > can we trigger this memory leak by some new or existed tests? > > I cant see any nor can I think of any..you have any idea? As far as I understand, the renderer component is leaked. Usually, the renderer isn't re-created each time `getTreeCellRendererComponent()` is called. So, we can create a renderer component and store a weak/phantom reference to it. After `tree.uninstallUI` is called, the renderer component should be freed. You can use [`ForceGC`](https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/util/ForceGC.java) class for it. A sample usage of `ForceGC` can be found in [`AwtListGarbageCollectionTest.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java) or other tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17458#issuecomment-1904580067 From aivanov at openjdk.org Mon Jan 22 19:38:34 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 22 Jan 2024 19:38:34 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v9] In-Reply-To: References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> Message-ID: On Fri, 19 Jan 2024 04:48:40 GMT, Prasanta Sadhukhan wrote: >> javadoc contract for JComponent.setMinimumSize(Dimension) states: >> >> "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..." >> >> However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize() >> >> Fix is made to check if mnimumSize is set and if so, honour it.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > javadoc updated I admit I'm lost? Do we implement the hybrid approach? That is `getMinimumSize` and `getMaximumSize` return a value derived from `getPreferredSize` (modifying it so that the scroll bar is flexible along its scrolling axis rather than returning it directly as `ComponentUI` does). If minimum or maximum size is set, the set value is returned. Is it correct? If it is, do we even need to override `setMinimumSize` and `setMaximumSize`? The contract specified in `JComponent` is satisfied. Yet, *not in full*: neither of these methods returns `ui.get*Size()`, either method calls `getPreferredSize` (which in its turn calls `ui.getPreferredSize`) and adjusts the value. Hence, we still need to override them to update get min/max size to say the value is derived from preferred size rather than `ui` delegate's min/max size. (This can be asserted with a unit test.) src/java.desktop/share/classes/javax/swing/JScrollBar.java line 762: > 760: * Thus, it overrides {@code JComponent.setMinimumSize} contract > 761: * that subsequent calls to getMinimumSize will return the > 762: * same value as set in {@code JComponent.setMinimumSize} Doesn't the javadoc contradict the implementation? This fix has restored the contract of `setMinimumSize` / `getMinimumSize`, so `JScrollBar` is now like other components. What we can add though is how the size is calculated when it's not set, however, it's documented in the `get-` methods. src/java.desktop/share/classes/javax/swing/JScrollBar.java line 785: > 783: > 784: /** > 785: * The scrollbar is flexible along it's scrolling axis and Suggestion: * The scrollbar is flexible along its scrolling axis and Let's fix it too. src/java.desktop/share/classes/javax/swing/JScrollBar.java line 790: > 788: * @return the value of the {@code minimumSize} property if set by user > 789: * or if not set, minimum size derived from > 790: * preferred size in one axis and fixed size in another axis I think you should refer the derived size first is the most common returned value, and then mention `minimumSize` if it's set. src/java.desktop/share/classes/javax/swing/JScrollBar.java line 805: > 803: > 804: /** > 805: * The scrollbar is flexible along it's scrolling axis and Suggestion: * The scrollbar is flexible along its scrolling axis and ------------- PR Review: https://git.openjdk.org/jdk/pull/15325#pullrequestreview-1837127605 PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1462295939 PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1462310181 PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1462268856 PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1462310500 From kizune at openjdk.org Mon Jan 22 19:50:30 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 22 Jan 2024 19:50:30 GMT Subject: RFR: 8320692: Null icon returned for .exe without custom icon [v2] In-Reply-To: References: Message-ID: On Fri, 19 Jan 2024 17:42:58 GMT, Alexey Ivanov wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert NPE to asserts >> Move null check inside the loop so we do not retrieve extra >> icons if we encounter a null one > > src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1421: > >> 1419: public MultiResolutionIconImage(int baseSize, Map resolutionVariants) { >> 1420: assert !resolutionVariants.containsValue(null) >> 1421: : "There are null icons in the MRI variants map"; > > Here's an extra space. The colon aligned with `!` which starts the condition. > > Could you please revert it too? Sure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17475#discussion_r1462340795 From kizune at openjdk.org Mon Jan 22 21:07:03 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 22 Jan 2024 21:07:03 GMT Subject: RFR: 8320692: Null icon returned for .exe without custom icon [v3] In-Reply-To: References: Message-ID: > Replaced asserts with NullPointerException calls because outside of testing that would be more informative - i do not think many people running their applications with assertions in system libraries enabled; > Added a code that will analyze the result of the getIcon and will fall back to the default icon for the file type retrieved from the ShellFolder; > Added a test case made by Aleksei Ivanov. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Fixed indentation Test now checks for returned icon not to be null ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17475/files - new: https://git.openjdk.org/jdk/pull/17475/files/b9e453de..83998a2e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17475&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17475&range=01-02 Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17475.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17475/head:pull/17475 PR: https://git.openjdk.org/jdk/pull/17475 From kizune at openjdk.org Mon Jan 22 21:07:04 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 22 Jan 2024 21:07:04 GMT Subject: RFR: 8320692: Null icon returned for .exe without custom icon [v2] In-Reply-To: References: Message-ID: On Mon, 22 Jan 2024 16:22:31 GMT, Alexey Ivanov wrote: >> test/jdk/javax/swing/JFileChooser/FileSystemView/NoIconExeNPE.java line 264: >> >>> 262: FileSystemView fsv = FileSystemView.getFileSystemView(); >>> 263: // No NullPointerException is expected >>> 264: fsv.getSystemIcon(hello.toFile()); >> >> Maybe we should check that something useful is returned? at least non-null VS null value? > >> Maybe we should check that something useful is returned? at least non-null VS null value? > > Makes sense to ensure the returned value is not `null`. Sure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17475#discussion_r1462417222 From prr at openjdk.org Mon Jan 22 21:30:34 2024 From: prr at openjdk.org (Phil Race) Date: Mon, 22 Jan 2024 21:30:34 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v9] In-Reply-To: References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> Message-ID: On Fri, 19 Jan 2024 04:48:40 GMT, Prasanta Sadhukhan wrote: >> javadoc contract for JComponent.setMinimumSize(Dimension) states: >> >> "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..." >> >> However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize() >> >> Fix is made to check if mnimumSize is set and if so, honour it.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > javadoc updated Changes requested by prr (Reviewer). src/java.desktop/share/classes/javax/swing/JScrollBar.java line 773: > 771: * Unlike most components, JScrollBar will derive the maximum size from > 772: * the preferred size in one axis and a fixed maximum size in the other > 773: * unless otherwise set by the user. that last line (unless ...) needs to go if we adopt what I suggest below src/java.desktop/share/classes/javax/swing/JScrollBar.java line 789: > 787: * > 788: * @return the value of the {@code minimumSize} property if set by user > 789: * or if not set, minimum size derived from Seems we are not there yet. What is in this PR now is internally inconsistent. It adopts doc on set*Size that reads as if get*Size will always ignore the super-class contract, but on the get*Size methods we have new doc and implementation that actually in large part honours it. One of these needs to change and then the CSR needs to match. So, revisiting old ground, ie we've been back and forth on this. we can keep the current PR code which is "if the user calls set*Size, then honour it, accepting the low risk, OR we can keep the long standing behaviour, which is as near as we can get to no risk. I'm still a bit on the fence, but I think I never want to hear about JScrollBar size again, :-) So can we delete the new code in the get*Size methods and copy some of the wording from set* *JScrollBar will derive the maximum size from * the preferred size in one axis and a fixed maximum size in the other then the return doc can reduce to @ return the minimum size calculated as described above. ------------- PR Review: https://git.openjdk.org/jdk/pull/15325#pullrequestreview-1837300085 PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1462420459 PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1462419893 From prr at openjdk.org Mon Jan 22 21:30:37 2024 From: prr at openjdk.org (Phil Race) Date: Mon, 22 Jan 2024 21:30:37 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v9] In-Reply-To: References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> Message-ID: On Mon, 22 Jan 2024 19:27:06 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> javadoc updated > > src/java.desktop/share/classes/javax/swing/JScrollBar.java line 805: > >> 803: >> 804: /** >> 805: * The scrollbar is flexible along it's scrolling axis and > > Suggestion: > > * The scrollbar is flexible along its scrolling axis and Yes, I just noticed that too. Pre-existing but clearly not correct grammar. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1462377860 From honkar at openjdk.org Mon Jan 22 22:22:27 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 22 Jan 2024 22:22:27 GMT Subject: RFR: 8309460: JScrollBar leaves behind clutter for non-integer UI scales In-Reply-To: References: <8W2UV6PmGUlWlSbinEsOZ9nNIDwTml9xzcLcApKz5gw=.959fda59-a216-4676-ac99-f67e62aee8ee@github.com> Message-ID: <7lC5zsFnbcVCqGtiuwwhTonInsQCq5YhkFod1aBR1vs=.da7bd484-c9de-488d-96a0-f352c87fc0eb@github.com> On Mon, 22 Jan 2024 17:44:39 GMT, Alexey Ivanov wrote: > Because float scale results in fractional pixels? > > If the scale is 1.25, then 1 pixel is 1.25 physical pixels; 2 pixels are 2.5 physical pixels and so on. Initially this issue looked similar to fractional scaling issues such as border rendering issues observed on windows previously but it seems to happen only on non-standard fractional UI scales such as 2.3, 2.7 and not on standard fractional scales supported on windows (1.25,1.75,2.25 ..) https://github.com/openjdk/jdk/pull/17484#pullrequestreview-1834275178. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17484#issuecomment-1904926732 From prr at openjdk.org Tue Jan 23 00:45:25 2024 From: prr at openjdk.org (Phil Race) Date: Tue, 23 Jan 2024 00:45:25 GMT Subject: RFR: 8307246 : Printing: banded raster path doesn't account for device offset values In-Reply-To: References: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com> Message-ID: On Mon, 11 Dec 2023 05:32:20 GMT, vtstydev wrote: > > This is going to require manual verification. Likely we'll need to test all possible page orientations too - did you try that ? > > I printed some documents, that renders with banded-raster printing loop, both orientations on Windows and Linux. They were printed well. I was hoping (!) you would write a test. In fact there needs to be one. Comparison of opaque vs translucent in all orientations. And clearly it needs to be a manual test, that means user instructions are needed. It should use PassFailJFrame The test probably also needs to display the print dialog, so the user can agree on which printer to use. I've not done those last 3 things but here's a test which starts with what you had in the bug report. It needs to be updated to be a proper jtreg test. mport java.awt.BasicStroke; import java.awt.Color; import java.awt.Graphics; import java.awt.Graphics2D; import java.awt.Rectangle; import java.awt.Stroke; import java.awt.print.Book; import java.awt.print.Pageable; import java.awt.print.PageFormat; import static java.awt.print.PageFormat.*; import java.awt.print.Paper; import java.awt.print.Printable; import static java.awt.print.Printable.*; import java.awt.print.PrinterException; import java.awt.print.PrinterJob; import javax.print.attribute.HashPrintRequestAttributeSet; import javax.print.attribute.PrintRequestAttributeSet; import javax.print.attribute.standard.Sides; public class AlphaPrintingOffsets implements Printable { private static final Color OPAQUE_COLOR = Color.black; private static final Color ALPHA_COLOR = new Color(0, 0, 0, 200); private static AlphaPrintingOffsets opaque = new AlphaPrintingOffsets(OPAQUE_COLOR); private static AlphaPrintingOffsets alpha = new AlphaPrintingOffsets(ALPHA_COLOR); private Color color; public AlphaPrintingOffsets(Color c) { color = c; } private static String getOrientStr(int orient) { switch (orient) { case PORTRAIT: return "PORTRAIT"; case LANDSCAPE: return "LANDSCAPE"; case REVERSE_LANDSCAPE: return "REVERSE_LANDSCAPE"; default : return "BAD Orientation"; } } @Override public int print(Graphics graphics, PageFormat pageFormat, int pageIndex) throws PrinterException { Graphics2D g2d = (Graphics2D)graphics; g2d.setColor(OPAQUE_COLOR); Stroke oldstroke = g2d.getStroke(); g2d.setStroke(new BasicStroke(10)); g2d.translate(15, 0); g2d.drawLine(0, 0 ,0, 300); //LEFT margin line g2d.translate(-15, 0); g2d.translate(0, -15); Paper paper = pageFormat.getPaper(); int orient = pageFormat.getOrientation(); int iw = (int)paper.getImageableWidth(); int ih = (int)paper.getImageableHeight(); int bm = orient == PORTRAIT ? ih : iw; //BOTTOM margin line g2d.drawLine(0, bm, 300, bm); g2d.translate(0, 15); g2d.setStroke(oldstroke); String msg = "Orient= " + getOrientStr(orient); msg += " Color="+ (color.getAlpha() != 255 ? " ALPHA" : " OPAQUE"); g2d.drawString(msg, 300, 300); g2d.setColor(color); g2d.fill(new Rectangle(0, 0, 200, 200)); return PAGE_EXISTS; } public static void main(String[] argv) { test(PORTRAIT); test(LANDSCAPE); test(REVERSE_LANDSCAPE); } static void test(int orient) { PrinterJob printJob = PrinterJob.getPrinterJob(); PageFormat pageFormat = printJob.defaultPage(); Paper paper = pageFormat.getPaper(); paper.setImageableArea(0,0,paper.getWidth(),paper.getHeight()); pageFormat.setOrientation(orient); pageFormat.setPaper(paper); Book book = new Book(); book.append(opaque, pageFormat); book.append(alpha, pageFormat); printJob.setPageable(book); PrintRequestAttributeSet aset = new HashPrintRequestAttributeSet(); aset.add(Sides.ONE_SIDED); try { printJob.print(aset); } catch (PrinterException e) { e.printStackTrace(); } } } ------------- PR Comment: https://git.openjdk.org/jdk/pull/17030#issuecomment-1905088271 From psadhukhan at openjdk.org Tue Jan 23 03:32:47 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 23 Jan 2024 03:32:47 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v10] In-Reply-To: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> Message-ID: > javadoc contract for JComponent.setMinimumSize(Dimension) states: > > "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..." > > However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize() > > Fix is made to check if mnimumSize is set and if so, honour it.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: PR update as per review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15325/files - new: https://git.openjdk.org/jdk/pull/15325/files/1a7bc6e8..c6511063 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15325&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15325&range=08-09 Stats: 24 lines in 1 file changed: 6 ins; 12 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15325/head:pull/15325 PR: https://git.openjdk.org/jdk/pull/15325 From psadhukhan at openjdk.org Tue Jan 23 03:37:45 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 23 Jan 2024 03:37:45 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v11] In-Reply-To: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> Message-ID: > javadoc contract for JComponent.setMinimumSize(Dimension) states: > > "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..." > > However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize() > > Fix is made to check if mnimumSize is set and if so, honour it.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: PR update as per review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15325/files - new: https://git.openjdk.org/jdk/pull/15325/files/c6511063..2a42f5c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15325&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15325&range=09-10 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15325/head:pull/15325 PR: https://git.openjdk.org/jdk/pull/15325 From psadhukhan at openjdk.org Tue Jan 23 03:37:46 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 23 Jan 2024 03:37:46 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v9] In-Reply-To: References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> Message-ID: On Mon, 22 Jan 2024 21:03:10 GMT, Phil Race wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> javadoc updated > > src/java.desktop/share/classes/javax/swing/JScrollBar.java line 789: > >> 787: * >> 788: * @return the value of the {@code minimumSize} property if set by user >> 789: * or if not set, minimum size derived from > > Seems we are not there yet. What is in this PR now is internally inconsistent. > It adopts doc on set*Size that reads as if get*Size will always ignore the super-class contract, > but on the get*Size methods we have new doc and implementation that actually in large part honours it. > One of these needs to change and then the CSR needs to match. > > So, revisiting old ground, ie we've been back and forth on this. > we can keep the current PR code which is "if the user calls set*Size, then honour it, accepting the low risk, OR > we can keep the long standing behaviour, which is as near as we can get to no risk. > > I'm still a bit on the fence, but I think I never want to hear about JScrollBar size again, :-) > So can we delete the new code in the get*Size methods and copy some of the wording from set* > *JScrollBar will derive the maximum size from > * the preferred size in one axis and a fixed maximum size in the other > > then the return doc can reduce to > @ return the minimum size calculated as described above. > So can we delete the new code in the get_Size methods and copy some of the wording from set_ *JScrollBar will derive the maximum size from * the preferred size in one axis and a fixed maximum size in the other > > then the return doc can reduce to @ return the minimum size calculated as described above. Updated as per suggestion.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1462686437 From psadhukhan at openjdk.org Tue Jan 23 04:34:26 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 23 Jan 2024 04:34:26 GMT Subject: RFR: 8309460: JScrollBar leaves behind clutter for non-integer UI scales In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 11:09:12 GMT, Prasanta Sadhukhan wrote: > Lines are left behind when moving the scrollbar in the positive direction. but are cleaned up on mouse release. > Additonally, with right arrow clicks too, the lines are left behind. > Seems like for mouseDragged and scrollByUnit, the dirty region of the scrollbar is not repainted leading to artifacts > which is being done in this fix.. Looks to be related to 8032219: [macosx] Scrollbars looks bad under retina which changes the way scrollbar is drawn for Metal and Motif L&F by using fillRect instead of drawLine and the current issue also happens for Metal and Motif L&F but not for say, Windows and Nimbus L&F ------------- PR Comment: https://git.openjdk.org/jdk/pull/17484#issuecomment-1905274881 From psadhukhan at openjdk.org Tue Jan 23 05:00:26 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 23 Jan 2024 05:00:26 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI In-Reply-To: <-7uQOOWcTCl_5TYeYXVYYwx9OKE4wir9WGEdHYtql80=.9a42231f-b3b4-4fb3-ac9b-b426a78e3663@github.com> References: <-7uQOOWcTCl_5TYeYXVYYwx9OKE4wir9WGEdHYtql80=.9a42231f-b3b4-4fb3-ac9b-b426a78e3663@github.com> Message-ID: On Mon, 22 Jan 2024 18:25:29 GMT, Alexey Ivanov wrote: >> When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak. >> When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. >> Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500) >> >> FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method.. > > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java line 1338: > >> 1336: if(rendererPane != null) { >> 1337: if (!tree.isVisible()) { >> 1338: rendererPane.removeAll(); > > Wouldn't it be enough to remove `rendererPane` from and assign `null` to it? > > It's done this way in `BasicTableUI` and `BasicListUI`: > https://github.com/openjdk/jdk/blob/0d8543d6773a516dad54038070dce507179d0709/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java#L1656-L1658 > and > https://github.com/openjdk/jdk/blob/0d8543d6773a516dad54038070dce507179d0709/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicListUI.java#L986-L988 It is already been done in `completeUIUninstall` called from `uninstallUI` `rendererPane.removeAll `is done to remove all components that are added in `getNodeDImensions` which gets removed in `paint` but if tree is not visible, then `paint `is not called so those components are not removed, which I am trying to do now in `uninstallUI `by checking tree visibility condition ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1462726516 From psadhukhan at openjdk.org Tue Jan 23 06:19:26 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 23 Jan 2024 06:19:26 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI In-Reply-To: <5MSk5-lrj1cQspd5nee8TuKIBVT39UtaF-24WAAv2fk=.3a224a4a-d8d3-4e2e-bcd2-814095443249@github.com> References: <5MSk5-lrj1cQspd5nee8TuKIBVT39UtaF-24WAAv2fk=.3a224a4a-d8d3-4e2e-bcd2-814095443249@github.com> Message-ID: On Mon, 22 Jan 2024 18:34:28 GMT, Alexey Ivanov wrote: > As far as I understand, the renderer component is leaked. It's not the renderer component but the components added to renderer component which are being leaked...In the reproducer, the JLabel's added to the tree are being leaked if tree is not visible.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17458#issuecomment-1905358862 From psadhukhan at openjdk.org Tue Jan 23 08:23:49 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 23 Jan 2024 08:23:49 GMT Subject: RFR: 8233177: JTextField's size is computed incorrectly when it contains Indic or Thai characters Message-ID: Existing regression test is failing because textfield height is not as per test's expectation..Seems like the indic character being tried to render is not being loaded (probably because of missing glyphs) leading to 0 preferredSpan from [BoxView](https://github.com/openjdk/jdk/blame/5a74c2a67ebcb47e51732f03c4be694bdf920469/src/java.desktop/share/classes/javax/swing/text/BoxView.java#L545-L552) which is superclass for `i18nFieldVIew`, the field view for Indic characters. Tried block character in the test which is now being loaded properly leading to correct height.. ------------- Commit messages: - 8233177: JTextField's size is computed incorrectly when it contains Indic or Thai characters Changes: https://git.openjdk.org/jdk/pull/17528/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17528&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8233177 Stats: 25 lines in 2 files changed: 13 ins; 4 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/17528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17528/head:pull/17528 PR: https://git.openjdk.org/jdk/pull/17528 From aturbanov at openjdk.org Tue Jan 23 08:43:26 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 23 Jan 2024 08:43:26 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: On Mon, 22 Jan 2024 09:34:48 GMT, Tejesh R wrote: >> `synchronized` _works_ only if synchronized object is the same in all places. In the new method "synchronized object" - is an instance of `FilesLoader`, while in other places `fileCache` is accessed under `synchronized(fileCache)`. > > Then adding `synchronized(fileCache)` in `FilesLoader` where list comparison happens would be better idea? Yes. If you go with `synchronized` then it should be `synchronized (fileCache)` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1462913181 From abhiscxk at openjdk.org Tue Jan 23 09:37:28 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 23 Jan 2024 09:37:28 GMT Subject: RFR: 8233177: JTextField's size is computed incorrectly when it contains Indic or Thai characters In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 08:18:33 GMT, Prasanta Sadhukhan wrote: > Existing regression test is failing because textfield height is not as per test's expectation..Seems like the indic character being tried to render is not being loaded (probably because of missing glyphs) leading to 0 preferredSpan from [BoxView](https://github.com/openjdk/jdk/blame/5a74c2a67ebcb47e51732f03c4be694bdf920469/src/java.desktop/share/classes/javax/swing/text/BoxView.java#L545-L552) which is superclass for `i18nFieldVIew`, the field view for Indic characters. > Tried block character in the test which is now being loaded properly leading to correct height.. test/jdk/javax/swing/plaf/basic/BasicTextUI/8001470/bug8001470.java line 35: > 33: import javax.swing.JTextField; > 34: import javax.swing.SwingUtilities; > 35: import javax.swing.JPanel; Plz sort imports. test/jdk/javax/swing/plaf/basic/BasicTextUI/8001470/bug8001470.java line 56: > 54: container.setLayout(new GridLayout(2,1)); > 55: > 56: Blank line can be removed. test/jdk/javax/swing/plaf/basic/BasicTextUI/8001470/bug8001470.java line 71: > 69: height2 = textField2.getHeight(); > 70: }); > 71: if( height1 < 10 || height2 < 10 ) { Suggestion: if ( height1 < 10 || height2 < 10 ) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17528#discussion_r1462981003 PR Review Comment: https://git.openjdk.org/jdk/pull/17528#discussion_r1462981581 PR Review Comment: https://git.openjdk.org/jdk/pull/17528#discussion_r1462982046 From aivanov at openjdk.org Tue Jan 23 11:16:31 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 23 Jan 2024 11:16:31 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI In-Reply-To: References: <-7uQOOWcTCl_5TYeYXVYYwx9OKE4wir9WGEdHYtql80=.9a42231f-b3b4-4fb3-ac9b-b426a78e3663@github.com> Message-ID: On Tue, 23 Jan 2024 04:58:00 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java line 1338: >> >>> 1336: if(rendererPane != null) { >>> 1337: if (!tree.isVisible()) { >>> 1338: rendererPane.removeAll(); >> >> Wouldn't it be enough to remove `rendererPane` from and assign `null` to it? >> >> It's done this way in `BasicTableUI` and `BasicListUI`: >> https://github.com/openjdk/jdk/blob/0d8543d6773a516dad54038070dce507179d0709/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java#L1656-L1658 >> and >> https://github.com/openjdk/jdk/blob/0d8543d6773a516dad54038070dce507179d0709/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicListUI.java#L986-L988 > > It is already been done in `completeUIUninstall` called from `uninstallUI` > `rendererPane.removeAll `is done to remove all components that are added in `getNodeDImensions` which gets removed in `paint` but if tree is not visible, then `paint `is not called so those components are not removed, which I am trying to do now in `uninstallUI `by checking tree visibility condition Okay, I see it. Then the added lines in `uninstallComponents` aren't needed because `rendererPane` is assigned `null` in `completeUIUninstall` which is called right after `uninstallComponents`, therefore `rendererPane` itself and all the components added into it are eligible for garbage collection. Where is the memory leak then? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1463114166 From aivanov at openjdk.org Tue Jan 23 11:25:26 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 23 Jan 2024 11:25:26 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI In-Reply-To: <1JzcyghEppNun0LjWPUGmHGrW0QE4HluhN_rYR42wqg=.56dd91b0-53cc-43ed-851c-16e528dcd29a@github.com> References: <1JzcyghEppNun0LjWPUGmHGrW0QE4HluhN_rYR42wqg=.56dd91b0-53cc-43ed-851c-16e528dcd29a@github.com> Message-ID: On Thu, 18 Jan 2024 02:48:26 GMT, Prasanta Sadhukhan wrote: > As mentioned in the comment > > https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284 > > the components are to be removed when UI changes, so I guess it is expected to increase if UI is not changing (ie. in case tree is not visible) so I have removed at end when component is uninstalled at which point it is a leak too, if not removed.. > A testcase is hard to provide for this leak..it's all notional.. This is an interesting part? If the renderer component is added over and over again into `rendererPane` this creates a leak, especially if `currentCellRenderer.getTreeCellRendererComponent` returns a new component each time it's called. To me, `rendererPane` should contain only one component ? the one that's returned by appropriate cell renderer and that is currently used for painting, measuring etc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17458#issuecomment-1905835853 From aivanov at openjdk.org Tue Jan 23 11:31:27 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 23 Jan 2024 11:31:27 GMT Subject: RFR: 8320692: Null icon returned for .exe without custom icon [v3] In-Reply-To: References: Message-ID: On Mon, 22 Jan 2024 21:07:03 GMT, Alexander Zuev wrote: >> Replaced asserts with NullPointerException calls because outside of testing that would be more informative - i do not think many people running their applications with assertions in system libraries enabled; >> Added a code that will analyze the result of the getIcon and will fall back to the default icon for the file type retrieved from the ShellFolder; >> Added a test case made by Aleksei Ivanov. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Fixed indentation > Test now checks for returned icon not to be null Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17475#pullrequestreview-1838527056 From prr at openjdk.org Tue Jan 23 19:16:29 2024 From: prr at openjdk.org (Phil Race) Date: Tue, 23 Jan 2024 19:16:29 GMT Subject: RFR: 8324243: Fix GCC 14 build In-Reply-To: References: Message-ID: On Sat, 20 Jan 2024 10:15:02 GMT, Sam James wrote: > This fixes building with GCC 14: > * Cherry-pick a fix from Harfbuzz upstream > * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources > > -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses > -Werror. > > The calloc prototype is: > > void *calloc(size_t nmemb, size_t size); > > > So, just swap the number of members and size arguments to match the prototype, as > we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're not > doing anything wrong. src/java.desktop/share/native/libharfbuzz/hb-object.hh line 328: > 326: if (unlikely (!user_data)) > 327: { > 328: user_data = (hb_user_data_array_t *) hb_calloc (sizeof (hb_user_data_array_t), 1); Note (1) We don't cherry pick unless it is critical. (2) I doubt you have ownership of harfbuzz code such that you can contribute any part of it to JDK in accordance with the OCA you signed. Accordingly, the right thing to do here is disable the warning for this library and tool chain. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17506#discussion_r1463867176 From duke at openjdk.org Tue Jan 23 19:20:33 2024 From: duke at openjdk.org (Sam James) Date: Tue, 23 Jan 2024 19:20:33 GMT Subject: RFR: 8324243: Fix GCC 14 build In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 19:13:40 GMT, Phil Race wrote: >> This fixes building with GCC 14: >> * Cherry-pick a fix from Harfbuzz upstream >> * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources >> >> -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses >> -Werror. >> >> The calloc prototype is: >> >> void *calloc(size_t nmemb, size_t size); >> >> >> So, just swap the number of members and size arguments to match the prototype, as >> we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're not >> doing anything wrong. > > src/java.desktop/share/native/libharfbuzz/hb-object.hh line 328: > >> 326: if (unlikely (!user_data)) >> 327: { >> 328: user_data = (hb_user_data_array_t *) hb_calloc (sizeof (hb_user_data_array_t), 1); > > Note > (1) We don't cherry pick unless it is critical. > (2) I doubt you have ownership of harfbuzz code such that you can contribute any part of it to JDK in accordance with the OCA you signed. > > Accordingly, the right thing to do here is disable the warning for this library and tool chain. Sure, I wasn't exactly hiding that it was cherry-picked. I did not consider (2) to be an issue given OpenJDK wholesale imports releases, but w/e. (The fix is also trivial and essentially the only possible fix...) Anyway, happy to do that. Can you suggest what the idiomatic way of doing that in the OpenJDK codebase is for imported libs? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17506#discussion_r1463871450 From prr at openjdk.org Tue Jan 23 19:29:32 2024 From: prr at openjdk.org (Phil Race) Date: Tue, 23 Jan 2024 19:29:32 GMT Subject: RFR: 8324243: Fix GCC 14 build In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 19:17:06 GMT, Sam James wrote: >> src/java.desktop/share/native/libharfbuzz/hb-object.hh line 328: >> >>> 326: if (unlikely (!user_data)) >>> 327: { >>> 328: user_data = (hb_user_data_array_t *) hb_calloc (sizeof (hb_user_data_array_t), 1); >> >> Note >> (1) We don't cherry pick unless it is critical. >> (2) I doubt you have ownership of harfbuzz code such that you can contribute any part of it to JDK in accordance with the OCA you signed. >> >> Accordingly, the right thing to do here is disable the warning for this library and tool chain. > > Sure, I wasn't exactly hiding that it was cherry-picked. I did not consider (2) to be an issue given OpenJDK wholesale imports releases, but w/e. (The fix is also trivial and essentially the only possible fix...) > > Anyway, happy to do that. Can you suggest what the idiomatic way of doing that in the OpenJDK codebase is for imported libs? add the warning here https://github.com/openjdk/jdk/blob/8b9bf758801400e4491326cd4c90fc117b9d97e1/make/modules/java.desktop/lib/Awt2dLibraries.gmk#L506 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17506#discussion_r1463888153 From prr at openjdk.org Tue Jan 23 19:29:33 2024 From: prr at openjdk.org (Phil Race) Date: Tue, 23 Jan 2024 19:29:33 GMT Subject: RFR: 8324243: Fix GCC 14 build In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 19:24:09 GMT, Phil Race wrote: >> Sure, I wasn't exactly hiding that it was cherry-picked. I did not consider (2) to be an issue given OpenJDK wholesale imports releases, but w/e. (The fix is also trivial and essentially the only possible fix...) >> >> Anyway, happy to do that. Can you suggest what the idiomatic way of doing that in the OpenJDK codebase is for imported libs? > > add the warning here > https://github.com/openjdk/jdk/blob/8b9bf758801400e4491326cd4c90fc117b9d97e1/make/modules/java.desktop/lib/Awt2dLibraries.gmk#L506 PS make sure you include a comment which toolchain / version required this ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17506#discussion_r1463890815 From prr at openjdk.org Tue Jan 23 22:10:33 2024 From: prr at openjdk.org (Phil Race) Date: Tue, 23 Jan 2024 22:10:33 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v11] In-Reply-To: References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> Message-ID: On Tue, 23 Jan 2024 03:37:45 GMT, Prasanta Sadhukhan wrote: >> javadoc contract for JComponent.setMinimumSize(Dimension) states: >> >> "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..." >> >> However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize() >> >> Fix is made to check if mnimumSize is set and if so, honour it.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > PR update as per review I've also reviewed the CSR. I think that can be finalized but Joe may yet ask us to add some more info in the JComponent methods. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15325#pullrequestreview-1840030473 From prr at openjdk.org Tue Jan 23 22:56:27 2024 From: prr at openjdk.org (Phil Race) Date: Tue, 23 Jan 2024 22:56:27 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI In-Reply-To: References: Message-ID: On Wed, 17 Jan 2024 07:19:21 GMT, Prasanta Sadhukhan wrote: > When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak. > When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. > Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500) > > FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method.. I am not sure what "notional" means - do you mean there is no actual leak ? If there's no actual leak we don't need a fix. If we have just one component that is sitting in a list owned by renderPane that's not much of a "leak". I am not sure this is worth "fixing". But if somehow - as discussed above repeated calls to renderPane.add(Component) accumulate components when there should only ever be one, what would that mean in a program which then DOES display the tree after adding (eg) 5 components ? If having 5 makes no sense, can we (should we ?) stop more than one from being added ? I think that may also be Alexei's point. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17458#issuecomment-1907053439 From prr at openjdk.org Tue Jan 23 22:56:29 2024 From: prr at openjdk.org (Phil Race) Date: Tue, 23 Jan 2024 22:56:29 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI In-Reply-To: References: <_2WabLf2ATFrCDd5TfnVm5M7CoOEOlCx-IOb32c3Jco=.2e4486f0-0898-4e5e-9552-83a43133799b@github.com> Message-ID: On Mon, 22 Jan 2024 06:29:40 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java line 1338: >> >>> 1336: if(rendererPane != null) { >>> 1337: if (!tree.isVisible()) { >>> 1338: rendererPane.removeAll(); >> >> if( -> if ( >> >> Is it actually necessary to check visibility ? >> >> But more importantly, in the case of the test in the bug, how and when does this uninstallComponents() method get called ? It isn't clear to me how it changes the reported behaviour of that test. >> >> I thought uninstallComponents() is just part of uninstallUI() like when tearing down and freeing the tree, or at least switching L&F .. whereas the submitter seems to be implying nodeChanged() is the problem > > Yes, the submitter mentioned during nodeChanged() but I mentioned it before [in this comment](https://github.com/openjdk/jdk/pull/17458#issuecomment-1897684665) > that the comment present, implied it's not an issue, if the component is not removed if UI is not changed (as it is in the case when tree is not visible)...I am not sure why it was added and when but should we ignore that comment and try to remove the component even if tree is not visible (and UI is not changing)? > > I went with the thought that the coder meant what he said and I freed the components at the end (as you told during tearing down) so that there is no leak.. My point is not about whether this is the only case we need to address, I am asking what harm could come from removing the isVisible() test here ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1464089825 From serb at openjdk.org Wed Jan 24 02:39:27 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 24 Jan 2024 02:39:27 GMT Subject: RFR: 8233177: JTextField's size is computed incorrectly when it contains Indic or Thai characters In-Reply-To: References: Message-ID: <1tSDJFfu0pZi2sg4m1qlPDMeq0xvw4ifMlC4LOTOfLQ=.53bc95ea-ab2b-48d6-9d54-a61f59e44789@github.com> On Tue, 23 Jan 2024 08:18:33 GMT, Prasanta Sadhukhan wrote: > Existing regression test is failing because textfield height is not as per test's expectation..Seems like the indic character being tried to render is not being loaded (probably because of missing glyphs) leading to 0 preferredSpan from [BoxView](https://github.com/openjdk/jdk/blame/5a74c2a67ebcb47e51732f03c4be694bdf920469/src/java.desktop/share/classes/javax/swing/text/BoxView.java#L545-L552) which is superclass for `i18nFieldVIew`, the field view for Indic characters. > Tried block character in the test which is now being loaded properly leading to correct height.. Can you please check that the updated test can verify the initial bug? When I run the reproducer from the JBS for that bug on JDK8+macOS then I can reproduce it. But if I update the characters as suggested in this PR the bug stops reproducing. test/jdk/javax/swing/plaf/basic/BasicTextUI/8001470/bug8001470.java line 58: > 56: > 57: textField1 = new JTextField("\u2588"); > 58: textField2 = new JTextField("\u2588"); You do not need to test the same character twice ------------- PR Comment: https://git.openjdk.org/jdk/pull/17528#issuecomment-1907252071 PR Review Comment: https://git.openjdk.org/jdk/pull/17528#discussion_r1464225554 From psadhukhan at openjdk.org Wed Jan 24 05:30:45 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 24 Jan 2024 05:30:45 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI [v2] In-Reply-To: References: Message-ID: > When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak. > When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. > Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500) > > FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Retain last component in rendererPane. Testcase added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17458/files - new: https://git.openjdk.org/jdk/pull/17458/files/923be22e..301ecbce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17458&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17458&range=00-01 Stats: 213 lines in 2 files changed: 210 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17458.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17458/head:pull/17458 PR: https://git.openjdk.org/jdk/pull/17458 From psadhukhan at openjdk.org Wed Jan 24 05:35:42 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 24 Jan 2024 05:35:42 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI [v3] In-Reply-To: References: Message-ID: <1xfZ5RyTcjtAZ87SQYOMdNYYRnc76Fxr0m05vbktyZQ=.4e4e71a5-351f-4654-90e6-c21e2a199894@github.com> > When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak. > When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. > Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500) > > FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Retain last component in rendererPane. Testcase added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17458/files - new: https://git.openjdk.org/jdk/pull/17458/files/301ecbce..de37cc96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17458&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17458&range=01-02 Stats: 17 lines in 1 file changed: 0 ins; 1 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/17458.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17458/head:pull/17458 PR: https://git.openjdk.org/jdk/pull/17458 From psadhukhan at openjdk.org Wed Jan 24 05:35:44 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 24 Jan 2024 05:35:44 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI [v2] In-Reply-To: References: Message-ID: On Wed, 24 Jan 2024 05:30:45 GMT, Prasanta Sadhukhan wrote: >> When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak. >> When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. >> Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500) >> >> FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Retain last component in rendererPane. Testcase added Yes, seems like rendererPane should retain the last rendering component..No regression is observed in SwingSet2 or in other tree tests.. Updated PR to stop more than one component being added. Testcase added too.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17458#issuecomment-1907407484 From aivanov at openjdk.org Wed Jan 24 14:44:38 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 24 Jan 2024 14:44:38 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v11] In-Reply-To: References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> Message-ID: On Tue, 23 Jan 2024 03:37:45 GMT, Prasanta Sadhukhan wrote: >> javadoc contract for JComponent.setMinimumSize(Dimension) states: >> >> "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..." >> >> However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize() >> >> Fix is made to check if mnimumSize is set and if so, honour it.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > PR update as per review Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/JScrollBar.java line 761: > 759: * Thus, it overrides {@code JComponent.setMinimumSize} contract > 760: * that subsequent calls to getMinimumSize will return the > 761: * same value as set in {@code JComponent.setMinimumSize} Suggestion: * Unlike most components, {@code JScrollBar} derives the minimum size from * the preferred size in one axis and a fixed minimum size in the other. * Thus, it overrides {@code JComponent.setMinimumSize} contract * that subsequent calls to {@code getMinimumSize} will return the * same value as set in {@code JComponent.setMinimumSize}. @prrace Should the first sentence use the present tense instead of the future? There should be a period in the end of the sentence. Should we add a paragraph saying, calling `setMinimumSize` has no effect? src/java.desktop/share/classes/javax/swing/JScrollBar.java line 789: > 787: * fixed minimum size in the other. > 788: * > 789: * @return the minimum size as specified above. The first sentence of the javadoc is put into the method summary, therefore the first sentence should explain what is returned. Is it worth addressing it too? Something like: Returns the minimum size for the {@code JScrollBar}. The minimum size is equal to a fixed minimum value along its scrolling axis and the preferred size along the other axis. src/java.desktop/share/classes/javax/swing/JScrollBar.java line 807: > 805: * fixed maximum size in the other. > 806: * > 807: * @return the maximum size as specified above. This can be amended in a similar way to `getMinimumSize`. Returns the maximum size for the {@code JScrollBar}. The maximum size is equal to a fixed maximum value its scrolling axis and the preferred size along the other axis. This makes the scrollbar flexible along its scrolling axis and rigid along the other axis. ------------- PR Review: https://git.openjdk.org/jdk/pull/15325#pullrequestreview-1841501224 PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1464989992 PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1465006089 PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1465014788 From aivanov at openjdk.org Wed Jan 24 15:29:27 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 24 Jan 2024 15:29:27 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 08:41:02 GMT, Andrey Turbanov wrote: >> Then adding `synchronized(fileCache)` in `FilesLoader` where list comparison happens would be better idea? > > Yes. If you go with `synchronized` then it should be `synchronized (fileCache)` This is my concern as well. It looks as if synchronisation is missing where it's required and therefore it allows for concurrent modification. Moreover, when you make a copy of `Vector`, you have to do it in a synchronised block with the `Vector` as the monitor: copying is iterating all the values, and you want to ensure it's done in an atomic way. Therefore, as @turbanoff noted, equals must be invoked while you hold the object monitor. It looks as if the previous fix didn't actually fix the problem, because `equals` is still called several times on `fileCache` or with it without proper synchronisation. It seems the entire `call` that's passed to `ShellFolder.invoke` needs to be inside `synchronized (fileCache)` ? its size, its elements are accessed many times while the method is executed. If another thread can modify `fileCache` concurrently, the assumptions inside the code could be broken. The method starts with `oldSize = fileCache.size()` and then iterates over elements in `fileCache` with `i < oldSize`. What if the number of elements in `fileCache` reduces and becomes less than `oldSize`. Probably, the method should make its own local copy of `fileCache`, do its work using the unsynchronised local copy. When complete, perform another sanity check _inside a synchronized block_ at least to ensure the size hasn't changed and then The variables `newFileCache` and `newFiles` could be `ArrayList` instead of `Vector` to avoid synchronisation penalty where it's not needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1465088991 From clanger at openjdk.org Wed Jan 24 16:34:27 2024 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 24 Jan 2024 16:34:27 GMT Subject: RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations In-Reply-To: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> References: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> Message-ID: On Fri, 12 Jan 2024 17:47:23 GMT, Christoph Langer wrote: > This picks up fixing the issue of [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) again. A fix had been integrated with #17224 but @prrace had concerns and so it was backed out. > > I have now spent quite some thoughts into the problem and end up with the [initial commit](https://github.com/openjdk/jdk/pull/6306/commits/5d18a76cb967e9ede6394cbd6c28bb61facf785c) of #6306 as the most elegant and least intrusive solution. > > Why is this? > > The JNI warning we observe in the test is: > `[WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV > at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 22.0.1-internal/Native Method) > at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:95) > at sun.awt.Win32GraphicsEnvironment.(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:63) > ... > at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) > at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)` > > This happens because obviously the test FreeTypeScalerJNICheck runs with `-Xcheck:jni` and in the scenario where we're observing the warning, a missing exception check for the JNI call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged` at awt_Win32GraphicsEnv.cpp#L129 > https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L129 is airing up. Omitting the exception check would not be a problem if it could be guaranteed that after this call no other JNI->Java call was being made. But seemingly in this very particular configuration on some of our Windows servers, there must be JNI->Java calls that follow the call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged`, likely from the subsequent call to [initScreens](https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L149) in `sun.awt.Win32GraphicsEnvironment::initDisplay`. https://github.com/openjdk/jdk/blob/8b6293f6bfb7b7628c6604e6c44401fc96d85cf4/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L141 Maybe the usual control flow would call the wrapping native method `DWMIsCompositi onEnabled()` from somewhere else initially such that the initialization of `Win32GraphicsEnvironment` would not go through `initScreens` or similar. > ... OK, finally it's understood what's happening. Here's the story: We basically run into the assertion reported in [JDK-8185862](https://bugs.openjdk.org/browse/JDK-8185862). It causes the JNI warning through a [CallStaticBooleanMethod](https://github.com/openjdk/jdk/blob/bccd823c8e40863bed70ff5b24772843203871a5/src/java.desktop/windows/native/libawt/windows/awt_Debug.cpp#L163C25-L163C48) in its depths. In detail: Via [initScreens](https://github.com/openjdk/jdk/blob/bccd823c8e40863bed70ff5b24772843203871a5/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L40), called by [initDisplay](https://github.com/openjdk/jdk/blob/bccd823c8e40863bed70ff5b24772843203871a5/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L149), we call [Devices::UpdateInstance](https://github.com/openjdk/jdk/blob/bccd823c8e40863bed70ff5b24772843203871a5/src/java.desktop/windows/native/libawt/windows/Devices.cpp#L216) that triggers [AwtWin32GraphicsDevice::Initialize](https://github.com/openjdk/jdk/blob/bccd823c8e40863bed70ff5b2477284 3203871a5/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp#L163) and here we run into the assertion. The assertion is fired by [this VERIFY](https://github.com/openjdk/jdk/blob/bccd823c8e40863bed70ff5b24772843203871a5/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp#L183). In Windows we have an [assertion callback](https://github.com/openjdk/jdk/blob/bccd823c8e40863bed70ff5b24772843203871a5/src/java.desktop/windows/native/libawt/windows/awt_Debug.cpp#L142) installed and it calls Java in [isHeadless()](https://github.com/openjdk/jdk/blob/bccd823c8e40863bed70ff5b24772843203871a5/src/java.desktop/windows/native/libawt/windows/awt_Debug.cpp#L183) which brings up the assertion. So, how to continue? I think the assertion itself should be addressed through [JDK-8185862](https://bugs.openjdk.org/browse/JDK-8185862). We could maybe make the assert [callback](https://github.com/openjdk/jdk/blob/bccd823c8e40863bed70ff5b24772843203871a5/src/java.desktop/windows/native/libawt/windows/awt_Debug.cpp#L171) more robust by checking for a pending exception before [calling the isHeadless function](https://github.com/openjdk/jdk/blob/bccd823c8e40863bed70ff5b24772843203871a5/src/java.desktop/windows/native/libawt/windows/awt_Debug.cpp#L163C25-L163C48). But I think the currently proposed exception check on calling dwmCompositionChanged is also a viable solution. Or we could remove the dwmCompositionChanged call altogether and set the isDWMCompositionEnabled field through JNI's setField function directly. Furthermore, the test FreeTypeScalerJNICheck could also check for "Assertion" in its output, in addition to "Warning". Then it would bail out on both, JNI Warnings and AWT a ssertions. WDYT? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17404#issuecomment-1908491604 From tr at openjdk.org Wed Jan 24 16:53:26 2024 From: tr at openjdk.org (Tejesh R) Date: Wed, 24 Jan 2024 16:53:26 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: <2QdFzdTMRaDSB2icdnkWhvjPId7_Ua2Ss4FdR4vnSPU=.d91a11c8-254b-4a1f-ba89-5e29adcb036b@github.com> On Wed, 24 Jan 2024 15:26:23 GMT, Alexey Ivanov wrote: >> Yes. If you go with `synchronized` then it should be `synchronized (fileCache)` > > This is my concern as well. It looks as if synchronisation is missing where it's required and therefore it allows for concurrent modification. > > Moreover, when you make a copy of `Vector`, you have to do it in a synchronised block with the `Vector` as the monitor: copying is iterating all the values, and you want to ensure it's done in an atomic way. > > Therefore, as @turbanoff noted, equals must be invoked while you hold the object monitor. > > It looks as if the previous fix didn't actually fix the problem, because `equals` is still called several times on `fileCache` or with it without proper synchronisation. > > It seems the entire `call` that's passed to `ShellFolder.invoke` needs to be inside `synchronized (fileCache)` ? its size, its elements are accessed many times while the method is executed. If another thread can modify `fileCache` concurrently, the assumptions inside the code could be broken. The method starts with `oldSize = fileCache.size()` and then iterates over elements in `fileCache` with `i < oldSize`. What if the number of elements in `fileCache` reduces and becomes less than `oldSize`. > > Probably, the method should make its own local copy of `fileCache`, do its work using the unsynchronised local copy. When complete, perform another sanity check _inside a synchronized block_ at least to ensure the size hasn't changed and then > > The variables `newFileCache` and `newFiles` could be `ArrayList` instead of `Vector` to avoid synchronisation penalty where it's not needed. Using `synchronized (fileCache)` inside `ShellFolder.invoke` would be better and one solution right? Than making local copy and again doing sanity checks/changing to `ArrayList`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1465253231 From clanger at openjdk.org Wed Jan 24 16:59:30 2024 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 24 Jan 2024 16:59:30 GMT Subject: RFR: JDK-8320405: [Windows Server 2016] java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java shows issues in awt_Win32GraphicsDevice.cpp [v3] In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 16:52:40 GMT, Matthias Baesken wrote: >> When running with fastdebug binaries we run intermittent into the issue below in >> jtreg test java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java . >> Seems we miss checking of successful HBITMAP creation before calling GetDIBits. >> >> HDC hBMDC = this->GetDC(); >> HBITMAP hBM = ::CreateCompatibleBitmap(hBMDC, 1, 1); >> VERIFY(::GetDIBits(hBMDC, hBM, 0, 1, NULL, gpBitmapInfo, DIB_RGB_COLORS)); >> >> in awt_Win32GraphicsDevice.cpp . Thats why the releast of hBMDC / hBM fails as well at the end of the function causing the seond and third warning. >> >> >> Sat Nov 18 17:29:23 CET 2023 >> >> ********************* >> AWT Assertion Failure >> ********************* >> ::GetDIBits(hBMDC, hBM, 0, 1, 0, gpBitmapInfo, 0) >> File 'e:\openjdk\openjdk-21u-windows_x86_64-dbg\jdk\src\java.desktop\windows\native\libawt\windows\awt_Win32GraphicsDevice.cpp', at line 184 >> GetLastError() is 57 : The parameter is incorrect. >> >> Do you want to break into the debugger? >> ********************* >> ********************* >> AWT Assertion Failure >> ********************* >> ::DeleteObject(hBM) >> File 'e:\openjdk\openjdk-21u-windows_x86_64-dbg\jdk\src\java.desktop\windows\native\libawt\windows\awt_Win32GraphicsDevice.cpp', at line 297 >> GetLastError() is 57 : The parameter is incorrect. >> >> So it seems, we should have some additional checks/tracing. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > do not call CreateCompatibleBitmap if hBMDC is NULL, do not call GetDIBits if hBM is NULL I have closed [JDK-8320405](https://bugs.openjdk.org/browse/JDK-8320405) as it does not match the synopsis of the issue addressed here. [JDK-8185862](https://bugs.openjdk.org/browse/JDK-8185862) is a better fit. I suggest to also close this PR and reboot on [JDK-8185862](https://bugs.openjdk.org/browse/JDK-8185862). Technically, I agree, if `hBMDC` is NULL, we should return right away. However, the question is, how critical such a situation is. I think we need an understanding about the environment in which that can happen and whether we can accept it without assertions. E.g. what it means when mieInfo.szDevice=`WinDisc` in a call to `HDC hDC = CreateDC(mieInfo.szDevice, NULL, NULL, NULL); ` which obviously yields NULL for hDC. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17197#issuecomment-1908545443 From aivanov at openjdk.org Wed Jan 24 19:03:26 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 24 Jan 2024 19:03:26 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: <2QdFzdTMRaDSB2icdnkWhvjPId7_Ua2Ss4FdR4vnSPU=.d91a11c8-254b-4a1f-ba89-5e29adcb036b@github.com> References: <2QdFzdTMRaDSB2icdnkWhvjPId7_Ua2Ss4FdR4vnSPU=.d91a11c8-254b-4a1f-ba89-5e29adcb036b@github.com> Message-ID: On Wed, 24 Jan 2024 16:51:15 GMT, Tejesh R wrote: > Using `synchronized (fileCache)` inside `ShellFolder.invoke` would be better and one solution right? Than making local copy and again doing sanity checks/changing to `ArrayList`? I'm afraid I can't answer this question without more details on what is achieved by this code. We need to look closely into what was done for [JDK-8240690](https://bugs.openjdk.org/browse/JDK-8240690): _Race condition between EDT and BasicDirectoryModel.FilesLoader.run0()_. Putting the entire method into `synchronized (fileCache)` is an easy solution. Yet any other thread which accesses `fileCache` will be blocked until the code exits the synchronized block in the `call` method. This somewhat defeats updating the file list in the background, doesn't it? Even if you'll go this route, I'm for replacing `Vector` with `ArrayList` for the `newFileCache` and `newFiles` variables. These are local variables, they're not accessed concurrently. Yet they're accessed from two threads: the current one and the one where `ShellFolder.invoke` runs, so there could be a need to use another synchronisation technique to ensure thread-safety between these two threads. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1465414103 From aivanov at openjdk.org Wed Jan 24 19:28:30 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 24 Jan 2024 19:28:30 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: <65jk1AciEgx1CoNsD40OTkoPiZG4OaCLHDhROWbDw2k=.af97d8c1-11d0-4474-aa32-2ca2600934ba@github.com> On Wed, 17 Jan 2024 12:55:52 GMT, Tejesh R wrote: > Suggested fix [JDK-8307091](https://bugs.openjdk.org/browse/JDK-8307091) also created concurrent exception intermittently (monthly once/quarterly once) on CI system. The issue was not able to be reproduced yet, hence proposing an alternative fix which uses iterators to compare the List. > CI testing shows green. In [JDK-8307091](https://bugs.openjdk.org/browse/JDK-8307091), `ConcurrentModificationException` is thrown from `equals`, likely from this line: https://github.com/openjdk/jdk/blob/2a799e5c82395919b807561da4a062e0fe6da31d/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java#L364 Here, `fileCache` is passed as a parameter, it can be modified while `newFileCache.subList().equals()` runs. You could've put this into `synchronized(fileCache)` to solve the problem. In [JDK-8323670](https://bugs.openjdk.org/browse/JDK-8323670), the exception is thrown from `Vector` constructor: https://github.com/openjdk/jdk/blob/c702dcabf8befc2db2baf53655f20391ee5d2d09/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java#L365 Here, we have exactly the same problem: `fileCache`, well `fileCache.subList` to be exact, is iterated without locking. (The `subList` uses the same object as the lock object, which is `fileCache`.) If you move this line into `synchronized(fileCache)`, the problem would resolved. --- However, as I pointed out above, the code in the `call` method may still fail. There are at least two bugs where `ConcurrentModificationException` is thrown, which means `fileCache` can be modified. The `for`-loops access elements in `fileCache` using the variable `oldSize` as the size of the collection. Since the size can grow _or shrink_, it is _possible_ that the code requests an element which is not in the `fileCache` any more. Yes, putting everything into `synchronized(fileCache)` will resolve this problem too. Is it the best solution? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17462#issuecomment-1908778630 From honkar at openjdk.org Wed Jan 24 20:01:27 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 24 Jan 2024 20:01:27 GMT Subject: RFR: 8309460: JScrollBar leaves behind clutter for non-integer UI scales In-Reply-To: References: Message-ID: <3xh6UXlQQDjOAEf98G_mqA82GhxcQbnh0LYoGmgafQY=.3b8b96a8-d24f-4924-b8a6-cd1543137747@github.com> On Tue, 23 Jan 2024 04:31:45 GMT, Prasanta Sadhukhan wrote: >> Lines are left behind when moving the scrollbar in the positive direction. but are cleaned up on mouse release. >> Additonally, with right arrow clicks too, the lines are left behind. >> Seems like for mouseDragged and scrollByUnit, the dirty region of the scrollbar is not repainted leading to artifacts >> which is being done in this fix.. > > Looks to be related to > 8032219: [macosx] Scrollbars looks bad under retina > which changes the way scrollbar is drawn for Metal and Motif L&F by using fillRect instead of drawLine > > and the current issue also happens for Metal and Motif L&F > but not for say, Windows and Nimbus L&F @prsadhuk @aivanov-jdk I have a clarification regarding the proposed fix. With the original solution the scrollbar repaint is done only when mouse is released or scrolled by a block, with the proposed fix the repaint is called continuously as long as the mouse is dragged or scrolled by a unit. Won't this create a lot of calls to repaint and thus cause an overhead? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17484#issuecomment-1908821523 From honkar at openjdk.org Wed Jan 24 20:18:27 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 24 Jan 2024 20:18:27 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI [v3] In-Reply-To: <1xfZ5RyTcjtAZ87SQYOMdNYYRnc76Fxr0m05vbktyZQ=.4e4e71a5-351f-4654-90e6-c21e2a199894@github.com> References: <1xfZ5RyTcjtAZ87SQYOMdNYYRnc76Fxr0m05vbktyZQ=.4e4e71a5-351f-4654-90e6-c21e2a199894@github.com> Message-ID: <5uJA1P_-3Z3BefdsjssRzc5LtDPMDnvKkwJqoYPiecg=.11ef9138-1989-421a-8047-191ce866e922@github.com> On Wed, 24 Jan 2024 05:35:42 GMT, Prasanta Sadhukhan wrote: >> When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak. >> When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. >> Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500) >> >> FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Retain last component in rendererPane. Testcase added test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 62: > 60: } > 61: > 62: public void finalize( ) { Suggestion: public void finalize() { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1465453254 From honkar at openjdk.org Wed Jan 24 20:21:29 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 24 Jan 2024 20:21:29 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI [v3] In-Reply-To: <1xfZ5RyTcjtAZ87SQYOMdNYYRnc76Fxr0m05vbktyZQ=.4e4e71a5-351f-4654-90e6-c21e2a199894@github.com> References: <1xfZ5RyTcjtAZ87SQYOMdNYYRnc76Fxr0m05vbktyZQ=.4e4e71a5-351f-4654-90e6-c21e2a199894@github.com> Message-ID: <-DgMO0SEs-iLodUrZkhFH61AO6KlbamuyYfz10wQ5h0=.3d5be14a-6bb7-46d9-83c1-2ab4eb4ec660@github.com> On Wed, 24 Jan 2024 05:35:42 GMT, Prasanta Sadhukhan wrote: >> When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak. >> When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. >> Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500) >> >> FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Retain last component in rendererPane. Testcase added test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 99: > 97: Thread updateThread = new Thread(new Runnable( ) { > 98: public void run( ) { > 99: runChanges( ); Suggestion: jTree1.setCellRenderer(new TreeCellRenderer()); Thread updateThread = new Thread(new Runnable() { public void run() { runChanges(); There are few other places in the test where the extra space needs to be removed. test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 106: > 104: Thread infoThread = new Thread(new Runnable( ) { > 105: public void run( ) { > 106: runInfo( ); Extra space ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1465491674 PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1465492054 From aivanov at openjdk.org Wed Jan 24 20:38:33 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 24 Jan 2024 20:38:33 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI [v3] In-Reply-To: <1xfZ5RyTcjtAZ87SQYOMdNYYRnc76Fxr0m05vbktyZQ=.4e4e71a5-351f-4654-90e6-c21e2a199894@github.com> References: <1xfZ5RyTcjtAZ87SQYOMdNYYRnc76Fxr0m05vbktyZQ=.4e4e71a5-351f-4654-90e6-c21e2a199894@github.com> Message-ID: On Wed, 24 Jan 2024 05:35:42 GMT, Prasanta Sadhukhan wrote: >> When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak. >> When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. >> Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500) >> >> FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Retain last component in rendererPane. Testcase added Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java line 3285: > 3283: for (int i = 0; i < rendererPane.getComponentCount(); i++) { > 3284: rendererPane.remove(i); > 3285: } rendererPane.removeAll()? Suggestion: rendererPane.removeAll(); test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 62: > 60: } > 61: > 62: public void finalize( ) { The `finalize` method is deprecated. Can't we use `Reference` API for this purpose? Store a list of [`PhantomReference`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/ref/PhantomReference.html). The size of the list is the number of `JLabel` objects created. Once you receive a reference via the [`ReferenceQueue`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/ref/ReferenceQueue.html), remove it from the list. test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 90: > 88: } > 89: > 90: return label; Here, before returning the `label` object, create a `PhantomReference` and add it to a list of references. test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 101: > 99: runChanges( ); > 100: } > 101: }); This could be a method reference: Suggestion: Thread updateThread = new Thread(this::runChanges); test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 108: > 106: runInfo( ); > 107: } > 108: }); Suggestion: Thread infoThread = new Thread(this::runInfo); test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 150: > 148: while (!done) { > 149: Thread.sleep(100); > 150: } Can't we use [`CountDownLatch`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/CountDownLatch.html) instead of a boolean flag and busy-waiting? test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 183: > 181: } catch (Exception ex) { > 182: ex.printStackTrace(); > 183: } You may want to handle `InterruptedException` by exiting from the thread? test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 191: > 189: public void runInfo( ) { > 190: long time = System.currentTimeMillis(); > 191: long initialCnt = smCount; Access to `smCount` or a list of references need to be synchronised. ------------- PR Review: https://git.openjdk.org/jdk/pull/17458#pullrequestreview-1842292468 PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1465491797 PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1465498201 PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1465504463 PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1465505654 PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1465506021 PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1465499294 PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1465507807 PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1465501423 From achung at openjdk.org Wed Jan 24 20:43:29 2024 From: achung at openjdk.org (Alisen Chung) Date: Wed, 24 Jan 2024 20:43:29 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v4] In-Reply-To: References: <00pjcBeEzOeDQ_FLh12p5daGx5e_Un2txgLlfzMBXBw=.23f90bc2-a6f2-4d4f-9ed2-bfaf177222eb@github.com> <8oX6Lb94AH15qK0Wq1Wf1u6fd-xy0fNj6UZGl5YNIfI=.653b780c-407d-41ef-bd92-b8d535207d3e@github.com> Message-ID: On Fri, 19 Jan 2024 01:52:47 GMT, Sergey Bylokhov wrote: >> Note that it does not fail with NPE but instead this code trigger the bug: >> >> AppContext eventContext = targetToAppContext(event.getSource()); >> if (eventContext != null && !eventContext.equals(appContext)) { >> throw new RuntimeException("Event posted on wrong app context : " + event); >> } >> >> The source of the event is TrayIcon, and the appconteext for it is non-null as well. >> >> This is the code where we post an event: >> >> @Override >> public void dispose() { >> dummyFrame.dispose(); >> >> if (popup != null) { >> popup.removeNotify(); >> } >> >> LWCToolkit.targetDisposedPeer(target, this); >> target = null; >> >> super.dispose(); >> } >> >> private void postEvent(final AWTEvent event) { >> SunToolkit.executeOnEventHandlerThread(target, new Runnable() { >> public void run() { >> SunToolkit.postEvent(SunToolkit.targetToAppContext(target), event); >> } >> }); >> } >> >> >> Note that we also call SunToolkit.targetToAppContext(target), and the target should be a TrayIcon and have a non-null appcontext, because later we successfully fetch it. >> >> >> So the problem here is not in the null appcontext, but that we set target to null in the peer in dispose(), at the time we still processing the events. >> - So we should check how all this should be synchronized, to prevent such race >> - Or we should not set target to null as on Windows >> - Or call dispose on EDT like on Linux. > > I think we should set the target once and use it forever. ok, i'll try removing the target = null ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17329#discussion_r1465513295 From aivanov at openjdk.org Wed Jan 24 21:06:26 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 24 Jan 2024 21:06:26 GMT Subject: RFR: 8309460: JScrollBar leaves behind clutter for non-integer UI scales In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 04:31:45 GMT, Prasanta Sadhukhan wrote: >> Lines are left behind when moving the scrollbar in the positive direction. but are cleaned up on mouse release. >> Additonally, with right arrow clicks too, the lines are left behind. >> Seems like for mouseDragged and scrollByUnit, the dirty region of the scrollbar is not repainted leading to artifacts >> which is being done in this fix.. > > Looks to be related to > 8032219: [macosx] Scrollbars looks bad under retina > which changes the way scrollbar is drawn for Metal and Motif L&F by using fillRect instead of drawLine > > and the current issue also happens for Metal and Motif L&F > but not for say, Windows and Nimbus L&F > @prsadhuk @aivanov-jdk I have a clarification regarding the proposed fix. > > With the original solution the scrollbar repaint is done only when mouse is released or scrolled by a block, with the proposed fix the repaint is called continuously as long as the mouse is dragged or scrolled by a unit. Won't this result in a lot of calls to repaint and thus cause an overhead? Additional repaints can create an additional overhead. On the other hand, repaint requests are coalesced. If the scrollbar wasn't repainted, you wouldn't see the thumb move, so there are repaints. What I don't understand is why those repaints aren't enough and adding one more, apparently at the same location, solves the problem. When you drag the thumb, to paint it in the new location, you need to paint the background over the old location and then the thumb in the new location. The suggested fix adds one more repaint of the rectangle where the scroll thumb is currently located. Or maybe not, and `getTrackBounds` returns the new rectangle by the time it's called in `scrollByUnit`. The call to `scrollByUnits` one line above updates the location of the thumb, which changes the model and eventually should call repaint for the old position of the thumb and for the new position of the thumb. The dragging code could handle repaints in an optimised way though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17484#issuecomment-1908910540 From aivanov at openjdk.org Wed Jan 24 21:14:26 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 24 Jan 2024 21:14:26 GMT Subject: RFR: 8309460: JScrollBar leaves behind clutter for non-integer UI scales In-Reply-To: References: Message-ID: <_6SbN6tphlitPw-J5TpQvgj3UMurM1t5kh-GtGlfs5s=.2464e138-4db5-44f6-8967-c7fc7e4f5caa@github.com> On Thu, 18 Jan 2024 11:09:12 GMT, Prasanta Sadhukhan wrote: > Lines are left behind when moving the scrollbar in the positive direction. but are cleaned up on mouse release. > Additonally, with right arrow clicks too, the lines are left behind. > Seems like for mouseDragged and scrollByUnit, the dirty region of the scrollbar is not repainted leading to artifacts > which is being done in this fix.. > > Because float scale results in fractional pixels? > > If the scale is 1.25, then 1 pixel is 1.25 physical pixels; 2 pixels are 2.5 physical pixels and so on. > > Initially this issue looked similar to fractional scaling issues such as border rendering issues observed on windows previously but it seems to happen only on non-standard fractional UI scales such as 2.3, 2.7 and not on standard fractional scales supported on windows (1.25,1.75,2.25 ..) [#17484 (review)](https://github.com/openjdk/jdk/pull/17484#pullrequestreview-1834275178). The underlying problem is still the same: there are fractional pixels. I haven't run the test case myself. The attached screenshot has a pattern? not every pixel remains visible. Likely, these pixels are where the fractional pixels add up to produce a new full pixel. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17484#issuecomment-1908921963 From aivanov at openjdk.org Wed Jan 24 21:17:27 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 24 Jan 2024 21:17:27 GMT Subject: RFR: 8309460: JScrollBar leaves behind clutter for non-integer UI scales In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 11:09:12 GMT, Prasanta Sadhukhan wrote: > Lines are left behind when moving the scrollbar in the positive direction. but are cleaned up on mouse release. > Additonally, with right arrow clicks too, the lines are left behind. > Seems like for mouseDragged and scrollByUnit, the dirty region of the scrollbar is not repainted leading to artifacts > which is being done in this fix.. I wonder if the problem can be reproduced by programmatically moving the thumb instead of dragging it with the mouse. Playing with the window size, uiScale, and the max value of the scrollbar could be required? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17484#issuecomment-1908925831 From honkar at openjdk.org Wed Jan 24 21:38:26 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 24 Jan 2024 21:38:26 GMT Subject: RFR: 8309460: JScrollBar leaves behind clutter for non-integer UI scales In-Reply-To: References: Message-ID: On Wed, 24 Jan 2024 21:03:39 GMT, Alexey Ivanov wrote: > The suggested fix adds one more repaint of the rectangle where the scroll thumb is currently located. Or maybe not, and `getTrackBounds` returns the new rectangle by the time it's called in `scrollByUnit`. This seems like a possible cause. > I wonder if the problem can be reproduced by programmatically moving the thumb instead of dragging it with the mouse. Playing with the window size, uiScale, and the max value of the scrollbar could be required? Good idea. I agree, especially with the case of max value of scroll bar. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17484#issuecomment-1908953767 From kizune at openjdk.org Wed Jan 24 22:13:36 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 24 Jan 2024 22:13:36 GMT Subject: Integrated: 8320692: Null icon returned for .exe without custom icon In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 00:47:00 GMT, Alexander Zuev wrote: > Replaced asserts with NullPointerException calls because outside of testing that would be more informative - i do not think many people running their applications with assertions in system libraries enabled; > Added a code that will analyze the result of the getIcon and will fall back to the default icon for the file type retrieved from the ShellFolder; > Added a test case made by Aleksei Ivanov. This pull request has now been integrated. Changeset: 6212264c Author: Alexander Zuev URL: https://git.openjdk.org/jdk/commit/6212264cc6fe428e8d15b7f33e2979c081e432d7 Stats: 282 lines in 2 files changed: 280 ins; 0 del; 2 mod 8320692: Null icon returned for .exe without custom icon Co-authored-by: Alexey Ivanov Reviewed-by: aivanov ------------- PR: https://git.openjdk.org/jdk/pull/17475 From prr at openjdk.org Wed Jan 24 23:24:36 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 24 Jan 2024 23:24:36 GMT Subject: RFR: JDK-8320405: [Windows Server 2016] java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java shows issues in awt_Win32GraphicsDevice.cpp [v3] In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 16:52:40 GMT, Matthias Baesken wrote: >> When running with fastdebug binaries we run intermittent into the issue below in >> jtreg test java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java . >> Seems we miss checking of successful HBITMAP creation before calling GetDIBits. >> >> HDC hBMDC = this->GetDC(); >> HBITMAP hBM = ::CreateCompatibleBitmap(hBMDC, 1, 1); >> VERIFY(::GetDIBits(hBMDC, hBM, 0, 1, NULL, gpBitmapInfo, DIB_RGB_COLORS)); >> >> in awt_Win32GraphicsDevice.cpp . Thats why the releast of hBMDC / hBM fails as well at the end of the function causing the seond and third warning. >> >> >> Sat Nov 18 17:29:23 CET 2023 >> >> ********************* >> AWT Assertion Failure >> ********************* >> ::GetDIBits(hBMDC, hBM, 0, 1, 0, gpBitmapInfo, 0) >> File 'e:\openjdk\openjdk-21u-windows_x86_64-dbg\jdk\src\java.desktop\windows\native\libawt\windows\awt_Win32GraphicsDevice.cpp', at line 184 >> GetLastError() is 57 : The parameter is incorrect. >> >> Do you want to break into the debugger? >> ********************* >> ********************* >> AWT Assertion Failure >> ********************* >> ::DeleteObject(hBM) >> File 'e:\openjdk\openjdk-21u-windows_x86_64-dbg\jdk\src\java.desktop\windows\native\libawt\windows\awt_Win32GraphicsDevice.cpp', at line 297 >> GetLastError() is 57 : The parameter is incorrect. >> >> So it seems, we should have some additional checks/tracing. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > do not call CreateCompatibleBitmap if hBMDC is NULL, do not call GetDIBits if hBM is NULL There are multiple levels of problem here At the highest level there's an entire code path we should not have entered if this is headless, but on windows the AWT implementation is not doing a good job of this. I don't know off-hand exactly what a fix for it would look like but changing this code without looking at the bigger picture seems premature If we handle that, then we would not be here and would not have an issue in your environment and moreover since we would not see the failure, we would not have an assert to deal with. It is then a separate issue unrelated to the debug build that we don't check for failure but I really doubt we'd ever see a failure here on a headful config. I do not agree with adding the headful keyword because this is a common code path and it essentially means we'd keep adding it to a load of headful tests because of this AWT problem. Our answer to this to date has been do not run AWT tests on debug builds. Arguably this has "worked" as much by luck as anything else since clearly the call can fail on product builds too, but it has never caused any problems that I have heard of. That doesn't make it satisfactory, but it also doesn't make a point fix the right fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17197#issuecomment-1909073511 From prr at openjdk.org Wed Jan 24 23:40:27 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 24 Jan 2024 23:40:27 GMT Subject: RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations In-Reply-To: References: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> Message-ID: On Wed, 24 Jan 2024 16:31:21 GMT, Christoph Langer wrote: > by checking for a pending exception before [calling the isHeadless function] I think that is an acceptable solution for this case. The isHeadless() code has no guaranteed context as to how it got here and there maybe other places where we'd have to patch and clearly the call needs to be made even if there's a pending exception, so I would do that. The broader problem is the reason we get here in this situation in the first place. It is the combination of (1) the debug build having asserts, (2) a "headless" env where calls fail that trigger the asserts We really need to fix (2) so that headless doesn't get here. In the absence of (2) it is likely that testing AWT on debug builds + headless will hit more problems. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17404#issuecomment-1909101855 From serb at openjdk.org Thu Jan 25 00:10:36 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 25 Jan 2024 00:10:36 GMT Subject: RFR: 8324347: Enable "maybe-uninitialized" warning for FreeType 2.13.1 Message-ID: <_UaZh-rx7c8ThmcPsVzPaNu8F_e0QZi_5RbPaD0HhEI=.d4b61526-1eee-4304-8b76-ab79dd65d284@github.com> The next bug in freetype was fixed upstream and fix already merged to OpeenJDK: https://gitlab.freedesktop.org/freetype/freetype/-/issues/1245 So now we can revert the workaround in the JDK: https://bugs.openjdk.org/browse/JDK-8313576 Tested with "--with-freetype=bundled", "--with-freetype=system" and w/o option on the system where the bug was reproduced. ------------- Commit messages: - Revert "8313576: GCC 7 reports compiler warning in bundled freetype 2.13.0" Changes: https://git.openjdk.org/jdk/pull/17525/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17525&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324347 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17525.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17525/head:pull/17525 PR: https://git.openjdk.org/jdk/pull/17525 From honkar at openjdk.org Thu Jan 25 01:12:42 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 25 Jan 2024 01:12:42 GMT Subject: RFR: JDK-8324238 : [macOS] java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails with the shape has not been applied msg Message-ID: <2X4lZKPcvcBCgjNBbezJGso48upOQIByUORAeXTOQuQ=.c7cf91b4-1b6b-4d31-95d7-04b2634f8eed@github.com> ShapeNotSetSometimes.java fails on macOS 11 on a random iteration of `colorCheck()` as shown below. The `colorCheck()` is repeated for about 50 times in the test. It is observed to pass on previous attempts and fail on a random attempt such as Attempt# 29 shown here. Here the point (150, 20) is well in the green area hence the slight color diff picked up by `robot.getPixelColor()` is not due to sampling of color at the edge (which sometimes causes robot to pick up slightly different color). Attempt 29 Checking 150, 20, java.awt.Color[r=0,g=255,b=1] should be java.awt.Color[r=0,g=255,b=0] Due to the above, I have kept the color sampling points at the same location as earlier and made the following changes to the test: - Moved the frame to the center of the screen. - Instead of comparing exact RGB values, used `colorCompare()` which allows a difference of 2 per color component to accommodate slight variations when comparing actual vs expected colors. Attempt 27 Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] Checking 150, 20, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] Checking 280, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] Checking 150, 250, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] Checking 20, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] Checking 62, 62, java.awt.Color[r=0,g=243,b=0] should not be java.awt.Color[r=255,g=255,b=255] Checking 240, 185, java.awt.Color[r=0,g=229,b=0] should not be java.awt.Color[r=255,g=255,b=255] Attempt 28 Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] Checking 150, 20, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] Checking 280, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] Checking 150, 250, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] Checking 20, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] Checking 62, 62, java.awt.Color[r=0,g=241,b=0] should not be java.awt.Color[r=255,g=255,b=255] Checking 240, 185, java.awt.Color[r=0,g=227,b=0] should not be java.awt.Color[r=255,g=255,b=255] Attempt 29 Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] Checking 150, 20, java.awt.Color[r=0,g=255,b=1] should be java.awt.Color[r=0,g=255,b=0] ----------System.err:(16/962)---------- Checking for transparency failed: point: 370, 420 actual java.awt.Color[r=0,g=255,b=1] expected java.awt.Color[r=0,g=255,b=0] java.lang.RuntimeException: Test failed. The shape has not been applied. ------------- Commit messages: - initial test fix Changes: https://git.openjdk.org/jdk/pull/17563/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17563&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324238 Stats: 33 lines in 1 file changed: 20 ins; 4 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/17563.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17563/head:pull/17563 PR: https://git.openjdk.org/jdk/pull/17563 From tr at openjdk.org Thu Jan 25 04:36:25 2024 From: tr at openjdk.org (Tejesh R) Date: Thu, 25 Jan 2024 04:36:25 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: <2QdFzdTMRaDSB2icdnkWhvjPId7_Ua2Ss4FdR4vnSPU=.d91a11c8-254b-4a1f-ba89-5e29adcb036b@github.com> Message-ID: <_eM6PSqBeIcRlegDs2Xlzfzkc2uYNNsdH4BbzpW4uwE=.602319fe-8f7d-4f13-9203-12e8d5801ca8@github.com> On Wed, 24 Jan 2024 19:01:09 GMT, Alexey Ivanov wrote: > Even if you'll go this route, I'm for replacing `Vector` with `ArrayList` for the `newFileCache` and `newFiles` variables. These are local variables, they're not accessed concurrently. Yet they're accessed from two threads: the current one and the one where `ShellFolder.invoke` runs, so there could be a need to use another synchronisation technique to ensure thread-safety between these two threads. Another Synchronization technique even after `synchronized (fileCache)`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1465829427 From tr at openjdk.org Thu Jan 25 04:46:26 2024 From: tr at openjdk.org (Tejesh R) Date: Thu, 25 Jan 2024 04:46:26 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: On Wed, 17 Jan 2024 12:55:52 GMT, Tejesh R wrote: > Suggested fix [JDK-8307091](https://bugs.openjdk.org/browse/JDK-8307091) also created concurrent exception intermittently (monthly once/quarterly once) on CI system. The issue was not able to be reproduced yet, hence proposing an alternative fix which uses iterators to compare the List. > CI testing shows green. Instead of putting everything into `synchronized(fileCache)`, I guess the better solution would be to wrap this line https://github.com/openjdk/jdk/blob/c702dcabf8befc2db2baf53655f20391ee5d2d09/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java#L365 into `synchronized(fileCache)`. With this we can ensure that a local copy would be made before comparing two fileCache list, since we cannot/shouldn't depend on any addition/deletion from `fileCache`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17462#issuecomment-1909345561 From rkannathpari at openjdk.org Thu Jan 25 04:56:35 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Thu, 25 Jan 2024 04:56:35 GMT Subject: RFR: 8320676 : Manual printer tests have no Pass/Fail buttons, instructions close Message-ID: Hi Reviewers, Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured. Please review and let me know your suggestions. Regards, Renjith ------------- Commit messages: - JDK-8320676 : Manual printer tests have no Pass/Fail buttons, instructions close Changes: https://git.openjdk.org/jdk/pull/17565/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17565&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320676 Stats: 4255 lines in 17 files changed: 805 ins; 2546 del; 904 mod Patch: https://git.openjdk.org/jdk/pull/17565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17565/head:pull/17565 PR: https://git.openjdk.org/jdk/pull/17565 From rkannathpari at openjdk.org Thu Jan 25 05:30:49 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Thu, 25 Jan 2024 05:30:49 GMT Subject: RFR: 8320676 : Manual printer tests have no Pass/Fail buttons, instructions close [v2] In-Reply-To: References: Message-ID: > Hi Reviewers, > > Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured. > > Please review and let me know your suggestions. > > Regards, > Renjith Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Removed window close handler from Collate2DPrintingTest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17565/files - new: https://git.openjdk.org/jdk/pull/17565/files/8d861959..92720ce9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17565&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17565&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17565/head:pull/17565 PR: https://git.openjdk.org/jdk/pull/17565 From rkannathpari at openjdk.org Thu Jan 25 05:37:40 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Thu, 25 Jan 2024 05:37:40 GMT Subject: RFR: 8320676 : Manual printer tests have no Pass/Fail buttons, instructions close [v3] In-Reply-To: References: Message-ID: <2wXUf4vAMV71MSxsWLestkIC08y7ZxIkOk3XKGJPXeI=.a7cad7de-3bcc-41be-850c-3c68fb254194@github.com> > Hi Reviewers, > > Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured. > > Please review and let me know your suggestions. > > Regards, > Renjith Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Fixed whitespace errors ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17565/files - new: https://git.openjdk.org/jdk/pull/17565/files/92720ce9..35c5c47e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17565&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17565&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17565/head:pull/17565 PR: https://git.openjdk.org/jdk/pull/17565 From clanger at openjdk.org Thu Jan 25 06:16:27 2024 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 25 Jan 2024 06:16:27 GMT Subject: RFR: JDK-8320405: [Windows Server 2016] java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java shows issues in awt_Win32GraphicsDevice.cpp [v3] In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 16:52:40 GMT, Matthias Baesken wrote: >> When running with fastdebug binaries we run intermittent into the issue below in >> jtreg test java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java . >> Seems we miss checking of successful HBITMAP creation before calling GetDIBits. >> >> HDC hBMDC = this->GetDC(); >> HBITMAP hBM = ::CreateCompatibleBitmap(hBMDC, 1, 1); >> VERIFY(::GetDIBits(hBMDC, hBM, 0, 1, NULL, gpBitmapInfo, DIB_RGB_COLORS)); >> >> in awt_Win32GraphicsDevice.cpp . Thats why the releast of hBMDC / hBM fails as well at the end of the function causing the seond and third warning. >> >> >> Sat Nov 18 17:29:23 CET 2023 >> >> ********************* >> AWT Assertion Failure >> ********************* >> ::GetDIBits(hBMDC, hBM, 0, 1, 0, gpBitmapInfo, 0) >> File 'e:\openjdk\openjdk-21u-windows_x86_64-dbg\jdk\src\java.desktop\windows\native\libawt\windows\awt_Win32GraphicsDevice.cpp', at line 184 >> GetLastError() is 57 : The parameter is incorrect. >> >> Do you want to break into the debugger? >> ********************* >> ********************* >> AWT Assertion Failure >> ********************* >> ::DeleteObject(hBM) >> File 'e:\openjdk\openjdk-21u-windows_x86_64-dbg\jdk\src\java.desktop\windows\native\libawt\windows\awt_Win32GraphicsDevice.cpp', at line 297 >> GetLastError() is 57 : The parameter is incorrect. >> >> So it seems, we should have some additional checks/tracing. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > do not call CreateCompatibleBitmap if hBMDC is NULL, do not call GetDIBits if hBM is NULL I agree, maybe in that kind of headless environment it could make sense to not initialize screens. I'll play with it and hopefully come back with something on [JDK-8185862](https://bugs.openjdk.org/browse/JDK-8185862). At least it seems we have such an environment in our configuration, so I can test there. Let's close this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17197#issuecomment-1909421356 From clanger at openjdk.org Thu Jan 25 06:36:36 2024 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 25 Jan 2024 06:36:36 GMT Subject: RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations [v2] In-Reply-To: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> References: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> Message-ID: > This picks up fixing the issue of [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) again. A fix had been integrated with #17224 but @prrace had concerns and so it was backed out. > > I have now spent quite some thoughts into the problem and end up with the [initial commit](https://github.com/openjdk/jdk/pull/6306/commits/5d18a76cb967e9ede6394cbd6c28bb61facf785c) of #6306 as the most elegant and least intrusive solution. > > Why is this? > > The JNI warning we observe in the test is: > `[WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV > at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 22.0.1-internal/Native Method) > at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:95) > at sun.awt.Win32GraphicsEnvironment.(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:63) > ... > at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) > at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)` > > This happens because obviously the test FreeTypeScalerJNICheck runs with `-Xcheck:jni` and in the scenario where we're observing the warning, a missing exception check for the JNI call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged` at awt_Win32GraphicsEnv.cpp#L129 > https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L129 is airing up. Omitting the exception check would not be a problem if it could be guaranteed that after this call no other JNI->Java call was being made. But seemingly in this very particular configuration on some of our Windows servers, there must be JNI->Java calls that follow the call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged`, likely from the subsequent call to [initScreens](https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L149) in `sun.awt.Win32GraphicsEnvironment::initDisplay`. https://github.com/openjdk/jdk/blob/8b6293f6bfb7b7628c6604e6c44401fc96d85cf4/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L141 Maybe the usual control flow would call the wrapping native method `DWMIsCompositi onEnabled()` from somewhere else initially such that the initialization of `Win32GraphicsEnvironment` would not go through `initScreens` or similar. > ... Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Changes to assertion function and test as discussed - Revert "JDK-8323664" This reverts commit 32128744252d75104e0d19f5eb701ffdc7b3d417. - Merge branch 'master' into JDK-8323664 - JDK-8323664 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17404/files - new: https://git.openjdk.org/jdk/pull/17404/files/32128744..74e28e13 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17404&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17404&range=00-01 Stats: 16919 lines in 526 files changed: 8868 ins; 6037 del; 2014 mod Patch: https://git.openjdk.org/jdk/pull/17404.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17404/head:pull/17404 PR: https://git.openjdk.org/jdk/pull/17404 From duke at openjdk.org Thu Jan 25 09:50:56 2024 From: duke at openjdk.org (vtstydev) Date: Thu, 25 Jan 2024 09:50:56 GMT Subject: RFR: 8307246 : Printing: banded raster path doesn't account for device offset values [v5] In-Reply-To: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com> References: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com> Message-ID: <9nbuG7Xh6X_5upW8hNaQsuB1CHdyIMr0-FVEPg6eQkA=.e377b4fe-6996-4339-bacc-e5232a73a7c0@github.com> > More correct way to take in consideration nonzero PHYSICALOFFSETX, PHYSICALOFFSETY of device for banded-raster printing loop. Only on Windows platform under certain conditions real device prints shifted image on paper. vtstydev has updated the pull request incrementally with one additional commit since the last revision: Add test for comparing offsets of images ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17030/files - new: https://git.openjdk.org/jdk/pull/17030/files/220a283b..58b84296 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17030&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17030&range=03-04 Stats: 199 lines in 1 file changed: 199 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17030.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17030/head:pull/17030 PR: https://git.openjdk.org/jdk/pull/17030 From aivanov at openjdk.org Thu Jan 25 09:58:39 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 25 Jan 2024 09:58:39 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: <_eM6PSqBeIcRlegDs2Xlzfzkc2uYNNsdH4BbzpW4uwE=.602319fe-8f7d-4f13-9203-12e8d5801ca8@github.com> References: <2QdFzdTMRaDSB2icdnkWhvjPId7_Ua2Ss4FdR4vnSPU=.d91a11c8-254b-4a1f-ba89-5e29adcb036b@github.com> <_eM6PSqBeIcRlegDs2Xlzfzkc2uYNNsdH4BbzpW4uwE=.602319fe-8f7d-4f13-9203-12e8d5801ca8@github.com> Message-ID: On Thu, 25 Jan 2024 04:33:25 GMT, Tejesh R wrote: > > Even if you'll go this route, I'm for replacing `Vector` with `ArrayList` for the `newFileCache` and `newFiles` variables. These are local variables, they're not accessed concurrently. Yet they're accessed from two threads: the current one and the one where `ShellFolder.invoke` runs, so there could be a need to use another synchronisation technique to ensure thread-safety between these two threads. > > Another Synchronization technique even after `synchronized (fileCache)`? Yes, even after. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1466117839 From aivanov at openjdk.org Thu Jan 25 10:53:27 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 25 Jan 2024 10:53:27 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: On Thu, 25 Jan 2024 04:43:59 GMT, Tejesh R wrote: > Instead of putting everything into `synchronized(fileCache)`, I guess the better solution would be to wrap this line > > https://github.com/openjdk/jdk/blob/c702dcabf8befc2db2baf53655f20391ee5d2d09/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java#L365 > > into `synchronized(fileCache)`. With this we can ensure that a local copy would be made before comparing two fileCache list, since we cannot/shouldn't depend on any addition/deletion from `fileCache`. But this won't resolve the problem completely. A better solution could still be creating a local copy of `fileCache` and then use it to calculating the diffs. There's still a problem: if `fileCache` is mutated again, the diffs become outdated. It's not taken into account by the current code. We can still ignore it. Then I haven't figured it out for what the calculated diffs are used. I also see that the evaluation can be cancelled. In fact, I see more thread-safety issues in the implementation? There are some fields and variables which are accessed without proper synchronisation. I looked at the code once again after reading @mrserb's [code review](https://mail.openjdk.org/pipermail/swing-dev/2020-March/010163.html) for [JDK-8240690](https://bugs.openjdk.org/browse/JDK-8240690), it seems that it goes like this: 1. The loader thread is created. Its `run0` method populates the files from file system. (It does so using `fileSystem.getFiles` which may be not thread-safe as well.) 2. The list of files is filtered (which also uses possibly non-thread-safe methods from `JFileChooser`). 3. The list of files is sorted. 4. The code inside `ShellFolder.invoke` is run on yet another thread. It calculates the diffs between the current `fileCache` and `newFileCache` created up to step 3. 5. The result of step 4 is an object of `DoChangeContents` which contains a snapshot of added or removed files. The object implements `Runnable` interface and is assigned to the field `runnable`. 6. This `runnable` is posted to be executed on EDT via `invokeLater`. It updates `fileCache`. Step 6 uses `doFire` variable, it could be set to false using the `cancel` method, which is synchronized. As such, reading the value of `doFire` must also be synchronised. Looking at the methods of `BasicDirectoryModel`, I can see that some methods use synchronized(fileCache) before accessing the field but others (`getSize`, `contains`, `indexOf`, `getElementAt`), which makes the `BasicDirectoryModel` class not thread-safe; it is especially dangerous with `contains` and `indexOf` where the contents of the `fileCache` can be changed while the method is iterating over the values inside `fileCache`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17462#issuecomment-1909906871 From aivanov at openjdk.org Thu Jan 25 10:59:28 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 25 Jan 2024 10:59:28 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: On Wed, 17 Jan 2024 12:55:52 GMT, Tejesh R wrote: > Suggested fix [JDK-8307091](https://bugs.openjdk.org/browse/JDK-8307091) also created concurrent exception intermittently (monthly once/quarterly once) on CI system. The issue was not able to be reproduced yet, hence proposing an alternative fix which uses iterators to compare the List. > CI testing shows green. Taking the above into account, I appears that the code inside `ShellFolder.invoke.call` should actually be inside `synchronized (fileCache)`. It would resolve `ConcurrentModificationException`. And you should revert the changes you made in [JDK-8323670](https://bugs.openjdk.org/browse/JDK-8323670). This bug is the proof that fix didn't help. Ideally, we should have a test which reproduces the problem? Yet, as with all concurrency issues, writing such a test could be very hard. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17462#issuecomment-1909916062 From duke at openjdk.org Thu Jan 25 11:01:48 2024 From: duke at openjdk.org (vtstydev) Date: Thu, 25 Jan 2024 11:01:48 GMT Subject: RFR: 8307246 : Printing: banded raster path doesn't account for device offset values [v6] In-Reply-To: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com> References: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com> Message-ID: <445CUFKGv0Ky0-F0p66JPpQkScZ3HcUkq84f2rWuKUU=.93d33607-d08c-4a41-9f96-e0627928acd2@github.com> > More correct way to take in consideration nonzero PHYSICALOFFSETX, PHYSICALOFFSETY of device for banded-raster printing loop. Only on Windows platform under certain conditions real device prints shifted image on paper. vtstydev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Add test for comparing offsets of images ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17030/files - new: https://git.openjdk.org/jdk/pull/17030/files/58b84296..62168fb3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17030&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17030&range=04-05 Stats: 199 lines in 1 file changed: 0 ins; 0 del; 199 mod Patch: https://git.openjdk.org/jdk/pull/17030.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17030/head:pull/17030 PR: https://git.openjdk.org/jdk/pull/17030 From tr at openjdk.org Thu Jan 25 11:12:34 2024 From: tr at openjdk.org (Tejesh R) Date: Thu, 25 Jan 2024 11:12:34 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: <7QBjy3TZgZt2sNs7mYVGRF58zI8moYhfnNHMT7iyDRk=.c64ff5da-d7ef-4719-8bbd-0d5a843d146f@github.com> On Thu, 25 Jan 2024 10:56:33 GMT, Alexey Ivanov wrote: > Taking the above into account, I appears that the code inside `ShellFolder.invoke.call` should actually be inside `synchronized (fileCache)`. It would resolve `ConcurrentModificationException`. > > And you should revert the changes you made in [JDK-8323670](https://bugs.openjdk.org/browse/JDK-8323670). This bug is the proof that fix didn't help. > > Ideally, we should have a test which reproduces the problem? Yet, as with all concurrency issues, writing such a test could be very hard. Yeah, sure then I'll revert the changes and update the changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17462#issuecomment-1909937365 From aivanov at openjdk.org Thu Jan 25 12:10:35 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 25 Jan 2024 12:10:35 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: On Thu, 25 Jan 2024 10:50:32 GMT, Alexey Ivanov wrote: > Looking at the methods of `BasicDirectoryModel`, I can see that some methods use `synchronized(fileCache)` before accessing the field but others (`getSize`, `contains`, `indexOf`, `getElementAt`), which makes the `BasicDirectoryModel` class not thread-safe; it is especially dangerous with `contains` and `indexOf` where the contents of the `fileCache` can be changed while the method is iterating over the values inside `fileCache`. I've just submitted [JDK-8324719](https://bugs.openjdk.org/browse/JDK-8324719): _Missing synchronized block in BasicDirectoryModel_ to address this synchronisation issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17462#issuecomment-1910070320 From aivanov at openjdk.org Thu Jan 25 12:13:37 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 25 Jan 2024 12:13:37 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: On Thu, 25 Jan 2024 10:50:32 GMT, Alexey Ivanov wrote: > Step 6 uses `doFire` variable, it could be set to false using the `cancel` method, which is synchronized. As such, reading the value of `doFire` must also be synchronised. It's not a problem, the `run` method is synchronized. There's a bug against it: [JDK-8238169](https://bugs.openjdk.org/browse/JDK-8238169): _BasicDirectoryModel getDirectories and DoChangeContents.run can deadlock_. Does `run` need to be synchronised? Probably not, only reading the value of `doFire` needs to be. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17462#issuecomment-1910079621 From erikj at openjdk.org Thu Jan 25 13:32:35 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 25 Jan 2024 13:32:35 GMT Subject: RFR: 8324347: Enable "maybe-uninitialized" warning for FreeType 2.13.1 In-Reply-To: <_UaZh-rx7c8ThmcPsVzPaNu8F_e0QZi_5RbPaD0HhEI=.d4b61526-1eee-4304-8b76-ab79dd65d284@github.com> References: <_UaZh-rx7c8ThmcPsVzPaNu8F_e0QZi_5RbPaD0HhEI=.d4b61526-1eee-4304-8b76-ab79dd65d284@github.com> Message-ID: On Tue, 23 Jan 2024 00:58:27 GMT, Sergey Bylokhov wrote: > The next bug in freetype was fixed upstream and fix already merged to OpenJDK: > https://gitlab.freedesktop.org/freetype/freetype/-/issues/1245 > So now we can revert the workaround in the JDK: > https://bugs.openjdk.org/browse/JDK-8313576 > > Tested with "--with-freetype=bundled", "--with-freetype=system" and w/o option on the system where the bug was reproduced. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17525#pullrequestreview-1843752053 From azvegint at openjdk.org Thu Jan 25 13:46:34 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 25 Jan 2024 13:46:34 GMT Subject: RFR: 8324347: Enable "maybe-uninitialized" warning for FreeType 2.13.1 In-Reply-To: <_UaZh-rx7c8ThmcPsVzPaNu8F_e0QZi_5RbPaD0HhEI=.d4b61526-1eee-4304-8b76-ab79dd65d284@github.com> References: <_UaZh-rx7c8ThmcPsVzPaNu8F_e0QZi_5RbPaD0HhEI=.d4b61526-1eee-4304-8b76-ab79dd65d284@github.com> Message-ID: On Tue, 23 Jan 2024 00:58:27 GMT, Sergey Bylokhov wrote: > The next bug in freetype was fixed upstream and fix already merged to OpenJDK: > https://gitlab.freedesktop.org/freetype/freetype/-/issues/1245 > So now we can revert the workaround in the JDK: > https://bugs.openjdk.org/browse/JDK-8313576 > > Tested with "--with-freetype=bundled", "--with-freetype=system" and w/o option on the system where the bug was reproduced. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17525#pullrequestreview-1843779778 From jwaters at openjdk.org Thu Jan 25 13:56:27 2024 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 25 Jan 2024 13:56:27 GMT Subject: RFR: 8324347: Enable "maybe-uninitialized" warning for FreeType 2.13.1 In-Reply-To: <_UaZh-rx7c8ThmcPsVzPaNu8F_e0QZi_5RbPaD0HhEI=.d4b61526-1eee-4304-8b76-ab79dd65d284@github.com> References: <_UaZh-rx7c8ThmcPsVzPaNu8F_e0QZi_5RbPaD0HhEI=.d4b61526-1eee-4304-8b76-ab79dd65d284@github.com> Message-ID: <7feuPPNwHpcVmnm3FwsxzJ7F8sux6q1fD48aNyCHDTk=.d880710b-9a0b-44c1-b9c2-5ce297448de8@github.com> On Tue, 23 Jan 2024 00:58:27 GMT, Sergey Bylokhov wrote: > The next bug in freetype was fixed upstream and fix already merged to OpenJDK: > https://gitlab.freedesktop.org/freetype/freetype/-/issues/1245 > So now we can revert the workaround in the JDK: > https://bugs.openjdk.org/browse/JDK-8313576 > > Tested with "--with-freetype=bundled", "--with-freetype=system" and w/o option on the system where the bug was reproduced. Marked as reviewed by jwaters (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17525#pullrequestreview-1843798687 From tr at openjdk.org Thu Jan 25 13:58:50 2024 From: tr at openjdk.org (Tejesh R) Date: Thu, 25 Jan 2024 13:58:50 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException [v2] In-Reply-To: References: Message-ID: > Suggested fix [JDK-8307091](https://bugs.openjdk.org/browse/JDK-8307091) also created concurrent exception intermittently (monthly once/quarterly once) on CI system. The issue was not able to be reproduced yet, hence proposing an alternative fix which uses iterators to compare the List. > CI testing shows green. Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Revert fix 8307091 + Synchronised filecache - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8323670 - Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17462/files - new: https://git.openjdk.org/jdk/pull/17462/files/7d70560b..9cf570fb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17462&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17462&range=00-01 Stats: 25510 lines in 669 files changed: 14131 ins; 8678 del; 2701 mod Patch: https://git.openjdk.org/jdk/pull/17462.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17462/head:pull/17462 PR: https://git.openjdk.org/jdk/pull/17462 From aivanov at openjdk.org Thu Jan 25 14:00:37 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 25 Jan 2024 14:00:37 GMT Subject: RFR: 8324347: Enable "maybe-uninitialized" warning for FreeType 2.13.1 In-Reply-To: <_UaZh-rx7c8ThmcPsVzPaNu8F_e0QZi_5RbPaD0HhEI=.d4b61526-1eee-4304-8b76-ab79dd65d284@github.com> References: <_UaZh-rx7c8ThmcPsVzPaNu8F_e0QZi_5RbPaD0HhEI=.d4b61526-1eee-4304-8b76-ab79dd65d284@github.com> Message-ID: On Tue, 23 Jan 2024 00:58:27 GMT, Sergey Bylokhov wrote: > The next bug in freetype was fixed upstream and fix already merged to OpenJDK: > https://gitlab.freedesktop.org/freetype/freetype/-/issues/1245 > So now we can revert the workaround in the JDK: > https://bugs.openjdk.org/browse/JDK-8313576 > > Tested with "--with-freetype=bundled", "--with-freetype=system" and w/o option on the system where the bug was reproduced. Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17525#pullrequestreview-1843808498 From azvegint at openjdk.org Thu Jan 25 18:30:34 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 25 Jan 2024 18:30:34 GMT Subject: RFR: JDK-8324238 : [macOS] java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails with the shape has not been applied msg In-Reply-To: <2X4lZKPcvcBCgjNBbezJGso48upOQIByUORAeXTOQuQ=.c7cf91b4-1b6b-4d31-95d7-04b2634f8eed@github.com> References: <2X4lZKPcvcBCgjNBbezJGso48upOQIByUORAeXTOQuQ=.c7cf91b4-1b6b-4d31-95d7-04b2634f8eed@github.com> Message-ID: On Thu, 25 Jan 2024 01:03:28 GMT, Harshitha Onkar wrote: > ShapeNotSetSometimes.java fails on macOS 11 on a random iteration of `colorCheck()` as shown below. The `colorCheck()` is repeated for about 50 times in the test. It is observed to pass on previous attempts and fail on a random attempt such as Attempt# 29 shown here. > > Here the point (150, 20) is well in the green area hence the slight color diff picked up by `robot.getPixelColor()` is not due to sampling of color at the edge (which sometimes causes robot to pick up slightly different color). > > > Attempt 29 > Checking 150, 20, java.awt.Color[r=0,g=255,b=1] should be java.awt.Color[r=0,g=255,b=0] > > > Due to the above, I have kept the color sampling points at the same location as earlier and made the following changes to the test: > > - Moved the frame to the center of the screen. > - Instead of comparing exact RGB values, used `colorCompare()` which allows color tolerance of 2 per color component to accommodate slight variations when comparing actual vs expected colors. > > > > Attempt 27 > Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] > Checking 150, 20, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 280, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 150, 250, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 20, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 62, 62, java.awt.Color[r=0,g=243,b=0] should not be java.awt.Color[r=255,g=255,b=255] > Checking 240, 185, java.awt.Color[r=0,g=229,b=0] should not be java.awt.Color[r=255,g=255,b=255] > Attempt 28 > Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] > Checking 150, 20, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 280, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 150, 250, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 20, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 62, 62, java.awt.Color[r=0,g=241,b=0] should not be java.awt.Color[r=255,g=255,b=255] > Checking 240, 185, java.awt.Color[r=0,g=227,b=0] should not be java.awt.Color[r=255,g=255,b=255] > Attempt 29 > Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] > Checking 150, 20, java.awt.Color[r=0,g=255,b=1] should be java.awt.Color[r=0,g=255,b=0] > ----------System.er... Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17563#pullrequestreview-1844385835 From duke at openjdk.org Thu Jan 25 19:23:28 2024 From: duke at openjdk.org (Karl T) Date: Thu, 25 Jan 2024 19:23:28 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI [v3] In-Reply-To: <1xfZ5RyTcjtAZ87SQYOMdNYYRnc76Fxr0m05vbktyZQ=.4e4e71a5-351f-4654-90e6-c21e2a199894@github.com> References: <1xfZ5RyTcjtAZ87SQYOMdNYYRnc76Fxr0m05vbktyZQ=.4e4e71a5-351f-4654-90e6-c21e2a199894@github.com> Message-ID: On Wed, 24 Jan 2024 05:35:42 GMT, Prasanta Sadhukhan wrote: >> When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak. >> When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. >> Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500) >> >> FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Retain last component in rendererPane. Testcase added src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java line 3285: > 3283: for (int i = 0; i < rendererPane.getComponentCount(); i++) { > 3284: rendererPane.remove(i); > 3285: } ~~~java for (int i = 0; i < rendererPane.getComponentCount(); i++) { rendererPane.remove(i); } ~~~ This code will not work for two or more children! For two children It does: 1. `i = 0` 2. `remove(i)` removes first child, which shifts other children and decrements component count to `1`! 3. `i++` so `i` is now `1` 4. check `i < rendererPane.getComponentCount()`, which is `1 < 1`. So loop is quit and one child is not removed. For three children It does: 1. `i = 0` 2. `remove(i)` removes first child, which shifts other children and decrements component count to `2`! 3. `i++` so `i` is now `1` 4. check `i < rendererPane.getComponentCount()`, which is `1 < 2` 5. `remove(i)` removes second child, which was the third child initially and decrements component count to `1` 6. `i++` so `i` is now `2` 7. check `i < rendererPane.getComponentCount()`, which is `2 < 1` . So loop is quit and one child is not removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1466820969 From honkar at openjdk.org Fri Jan 26 00:30:37 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 26 Jan 2024 00:30:37 GMT Subject: RFR: 8320676 : Manual printer tests have no Pass/Fail buttons, instructions close [v3] In-Reply-To: <2wXUf4vAMV71MSxsWLestkIC08y7ZxIkOk3XKGJPXeI=.a7cad7de-3bcc-41be-850c-3c68fb254194@github.com> References: <2wXUf4vAMV71MSxsWLestkIC08y7ZxIkOk3XKGJPXeI=.a7cad7de-3bcc-41be-850c-3c68fb254194@github.com> Message-ID: On Thu, 25 Jan 2024 05:37:40 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> >> Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured. >> >> Please review and let me know your suggestions. >> >> Regards, >> Renjith > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Fixed whitespace errors @Renjithkannath There are many test changes in a single PR, it would be easier to review if the tests are split into different PRs. For instance one PR/JBS issue per 5-6 tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17565#issuecomment-1911218955 From serb at openjdk.org Fri Jan 26 08:49:35 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 26 Jan 2024 08:49:35 GMT Subject: Integrated: 8324347: Enable "maybe-uninitialized" warning for FreeType 2.13.1 In-Reply-To: <_UaZh-rx7c8ThmcPsVzPaNu8F_e0QZi_5RbPaD0HhEI=.d4b61526-1eee-4304-8b76-ab79dd65d284@github.com> References: <_UaZh-rx7c8ThmcPsVzPaNu8F_e0QZi_5RbPaD0HhEI=.d4b61526-1eee-4304-8b76-ab79dd65d284@github.com> Message-ID: On Tue, 23 Jan 2024 00:58:27 GMT, Sergey Bylokhov wrote: > The next bug in freetype was fixed upstream and fix already merged to OpenJDK: > https://gitlab.freedesktop.org/freetype/freetype/-/issues/1245 > So now we can revert the workaround in the JDK: > https://bugs.openjdk.org/browse/JDK-8313576 > > Tested with "--with-freetype=bundled", "--with-freetype=system" and w/o option on the system where the bug was reproduced. This pull request has now been integrated. Changeset: 781f368d Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/781f368d421a94857929e4168974f43e890637d8 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8324347: Enable "maybe-uninitialized" warning for FreeType 2.13.1 Reviewed-by: erikj, azvegint, jwaters, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/17525 From coleenp at openjdk.org Fri Jan 26 20:13:59 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 26 Jan 2024 20:13:59 GMT Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test native code files Message-ID: This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code. This didn't attempt to change NULL in comments or strings to just null. If you run into this and it bothers you after this push, you can change it in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated. Ran tier1-4 testing. ------------- Commit messages: - 8324681: Replace NULL with nullptr in HotSpot jtreg test native code files Changes: https://git.openjdk.org/jdk/pull/17593/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17593&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324681 Stats: 8196 lines in 750 files changed: 0 ins; 7 del; 8189 mod Patch: https://git.openjdk.org/jdk/pull/17593.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17593/head:pull/17593 PR: https://git.openjdk.org/jdk/pull/17593 From prr at openjdk.org Fri Jan 26 20:18:37 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 26 Jan 2024 20:18:37 GMT Subject: RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations [v2] In-Reply-To: References: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> Message-ID: On Thu, 25 Jan 2024 06:36:36 GMT, Christoph Langer wrote: >> This picks up fixing the issue of [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) again. A fix had been integrated with #17224 but @prrace had concerns and so it was backed out. >> >> I have now spent quite some thoughts into the problem and end up with the [initial commit](https://github.com/openjdk/jdk/pull/6306/commits/5d18a76cb967e9ede6394cbd6c28bb61facf785c) of #6306 as the most elegant and least intrusive solution. >> >> Why is this? >> >> The JNI warning we observe in the test is: >> `[WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV >> at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 22.0.1-internal/Native Method) >> at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:95) >> at sun.awt.Win32GraphicsEnvironment.(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:63) >> ... >> at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) >> at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)` >> >> This happens because obviously the test FreeTypeScalerJNICheck runs with `-Xcheck:jni` and in the scenario where we're observing the warning, a missing exception check for the JNI call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged` at awt_Win32GraphicsEnv.cpp#L129 >> https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L129 is airing up. Omitting the exception check would not be a problem if it could be guaranteed that after this call no other JNI->Java call was being made. But seemingly in this very particular configuration on some of our Windows servers, there must be JNI->Java calls that follow the call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged`, likely from the subsequent call to [initScreens](https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L149) in `sun.awt.Win32GraphicsEnvironment::initDisplay`. https://github.com/openjdk/jdk/blob/8b6293f6bfb7b7628c6604e6c44401fc96d85cf4/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L141 Maybe the usual control flow would call the wrapping native method `DWMIsComposit ionEnabled()` from somewhere else initially such that the initialization of `Win32GraphicsEnvironment` would not go ... > > Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Changes to assertion function and test as discussed > - Revert "JDK-8323664" > > This reverts commit 32128744252d75104e0d19f5eb701ffdc7b3d417. > - Merge branch 'master' into JDK-8323664 > - JDK-8323664 Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17404#pullrequestreview-1846478583 From duke at openjdk.org Fri Jan 26 20:20:47 2024 From: duke at openjdk.org (MustavData) Date: Fri, 26 Jan 2024 20:20:47 GMT Subject: RFR: 8270269: Desktop.browse method fails if earlier CoInitialize call as COINIT_MULTITHREADED [v3] In-Reply-To: <6kleKtEG40OwclwIOss4ttDnXwdGsTicuIfIqTpFDgw=.adcd6f38-aed2-4686-b178-d724ddff5710@github.com> References: <6kleKtEG40OwclwIOss4ttDnXwdGsTicuIfIqTpFDgw=.adcd6f38-aed2-4686-b178-d724ddff5710@github.com> Message-ID: On Fri, 8 Dec 2023 17:12:29 GMT, Sergey Bylokhov wrote: >> The fix for a regression caused by the https://bugs.openjdk.org/browse/JDK-6508941. it does not take into account RPC_E_CHANGED_MODE when COM was already initialized using COINIT_MULTITHREADED mode. >> >> @aivanov-jdk please take a look. > > Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.desktop/windows/native/libawt/windows/awt_Desktop.cpp > > date > > Co-authored-by: Alexey Ivanov I am working to verify the initial fix of JDK-8270269 in OpenJDK 23 (beta). The basic environment is: OpenJDK: "Azul Systems, Inc.", "Zulu23+11-CA", "23-beta+1", "x86_64", ".:git:e278d5994c10+" OS: Windows 11, version 22H2, Build 22621.3007, VC++ 2015-2022 Runtime version 14.38.33130.0 The test application is a Java client with the user successfully logged in, following initial launch, against a web application. Here are the basic tests that need to pass: 1. Re-authentication after the standard web app timeout of 30 minutes, typically triggered when returning from lunch 2. Re-authentication after numerous hours, typically triggered when returning to work the next morning Results so far: 1. Without the initial fix, the Test 1 fails as reported in JDK-8270269 2. With the initial fix, Test 1 succeeds, and Test 2 fails with a `java.io.IOException` thrown upon a failure in `CoInitializeEx()` Here is the stack trace from the Test 2 failure: java.io.IOException: Failed to open https://. Error message: CoInitializeEx() failed. at java.desktop/sun.awt.windows.WDesktopPeer.ShellExecute(WDesktopPeer.java:115) at java.desktop/sun.awt.windows.WDesktopPeer.browse(WDesktopPeer.java:101) at java.desktop/java.awt.Desktop.browse(Desktop.java:533) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17010#issuecomment-1912630377 From coleenp at openjdk.org Fri Jan 26 20:26:17 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 26 Jan 2024 20:26:17 GMT Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test native code files [v2] In-Reply-To: References: Message-ID: > This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code. This didn't attempt to change NULL in comments or strings to just null. If you run into this and it bothers you after this push, you can change it in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated. > > Ran tier1-4 testing. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix the comments to "null" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17593/files - new: https://git.openjdk.org/jdk/pull/17593/files/079b8931..e15a3a0b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17593&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17593&range=00-01 Stats: 229 lines in 103 files changed: 0 ins; 0 del; 229 mod Patch: https://git.openjdk.org/jdk/pull/17593.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17593/head:pull/17593 PR: https://git.openjdk.org/jdk/pull/17593 From honkar at openjdk.org Fri Jan 26 20:34:44 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 26 Jan 2024 20:34:44 GMT Subject: RFR: JDK-8324733 : [macos14] Problem list tests which fail due to macOS bug described in JDK-8322653 Message-ID: Following tests fail on macOS 14 and thus being problemlisted. The reason for the failures is tracked as an external macOS platform bug by [JDK-8322653](https://bugs.openjdk.org/browse/JDK-8322653). ------------- Commit messages: - problemlist tests on macOS Changes: https://git.openjdk.org/jdk/pull/17597/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17597&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324733 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17597.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17597/head:pull/17597 PR: https://git.openjdk.org/jdk/pull/17597 From prr at openjdk.org Fri Jan 26 20:35:37 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 26 Jan 2024 20:35:37 GMT Subject: RFR: 8307246 : Printing: banded raster path doesn't account for device offset values [v6] In-Reply-To: <445CUFKGv0Ky0-F0p66JPpQkScZ3HcUkq84f2rWuKUU=.93d33607-d08c-4a41-9f96-e0627928acd2@github.com> References: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com> <445CUFKGv0Ky0-F0p66JPpQkScZ3HcUkq84f2rWuKUU=.93d33607-d08c-4a41-9f96-e0627928acd2@github.com> Message-ID: On Thu, 25 Jan 2024 11:01:48 GMT, vtstydev wrote: >> More correct way to take in consideration nonzero PHYSICALOFFSETX, PHYSICALOFFSETY of device for banded-raster printing loop. Only on Windows platform under certain conditions real device prints shifted image on paper. > > vtstydev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Add test for comparing offsets of images Very close (!) I see just a couple of minor things I need you to fix. test/jdk/java/awt/print/PrinterJob/ImagePrinting/AlphaPrintingOffsets.java line 2: > 1: /* > 2: * Copyright (c) 2007, 2022, Oracle and/or its affiliates. All rights reserved. I guess you copied the header including "2007, 2022," from some other file. This is a new test so it should just be "2024," test/jdk/java/awt/print/PrinterJob/ImagePrinting/AlphaPrintingOffsets.java line 28: > 26: import javax.print.attribute.standard.Sides; > 27: import javax.swing.*; > 28: import java.awt.*; We don't use wildcard imports - the example I pasted had none ! So please explicitly list all imports and we "sort" these. generally alphabetically at least for the same module. So the order of the packages should be java.awt java.awt.event java.awt.print javax.print javax.swing ------------- PR Review: https://git.openjdk.org/jdk/pull/17030#pullrequestreview-1846502348 PR Review Comment: https://git.openjdk.org/jdk/pull/17030#discussion_r1468117611 PR Review Comment: https://git.openjdk.org/jdk/pull/17030#discussion_r1468119702 From coleenp at openjdk.org Fri Jan 26 21:06:00 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 26 Jan 2024 21:06:00 GMT Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test native code files [v3] In-Reply-To: References: Message-ID: <9n3_W-gEDmcSZz8z5V_d-93x1Gy2Zl005gPEepDdIC4=.f7906413-3999-4e0d-acf3-bc7d8cc1d89b@github.com> > This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code. This didn't attempt to change NULL in comments or strings to just null. If you run into this and it bothers you after this push, you can change it in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated. > > Ran tier1-4 testing. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix nullptr only contained in strings. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17593/files - new: https://git.openjdk.org/jdk/pull/17593/files/e15a3a0b..33786c7d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17593&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17593&range=01-02 Stats: 19 lines in 3 files changed: 0 ins; 0 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/17593.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17593/head:pull/17593 PR: https://git.openjdk.org/jdk/pull/17593 From prr at openjdk.org Fri Jan 26 22:52:33 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 26 Jan 2024 22:52:33 GMT Subject: RFR: JDK-8324733 : [macos14] Problem list tests which fail due to macOS bug described in JDK-8322653 In-Reply-To: References: Message-ID: On Fri, 26 Jan 2024 20:25:12 GMT, Harshitha Onkar wrote: > Following tests fail on macOS 14 and thus being problemlisted. The reason for the failures is tracked as an external macOS platform bug by [JDK-8322653](https://bugs.openjdk.org/browse/JDK-8322653). Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17597#pullrequestreview-1846690468 From serb at openjdk.org Fri Jan 26 23:00:24 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 26 Jan 2024 23:00:24 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: On Fri, 19 Jan 2024 07:24:14 GMT, Tejesh R wrote: > I don't think we are able to trace it out, since the issue intermittent and previously I had made a copy of the vector list before checking for equality of the list. There was again an issue in the code which I used to copy to a temporary vector. So now instead of using` AbstractList.equals` I'm using iterators and comparing every element within synchronized method. I think we should start investigating this one, probably by adding special delays/asserts into the JDK to track down on what threads the data is modified and used. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17462#issuecomment-1912802507 From prr at openjdk.org Fri Jan 26 23:08:24 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 26 Jan 2024 23:08:24 GMT Subject: RFR: 8233177: JTextField's size is computed incorrectly when it contains Indic or Thai characters In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 08:18:33 GMT, Prasanta Sadhukhan wrote: > Existing regression test is failing because textfield height is not as per test's expectation..Seems like the indic character being tried to render is not being loaded (probably because of missing glyphs) leading to 0 preferredSpan from [BoxView](https://github.com/openjdk/jdk/blame/5a74c2a67ebcb47e51732f03c4be694bdf920469/src/java.desktop/share/classes/javax/swing/text/BoxView.java#L545-L552) which is superclass for `i18nFieldVIew`, the field view for Indic characters. > Tried block character in the test which is now being loaded properly leading to correct height.. "[JDK-8233177] JTextField's size is computed incorrectly when it contains Indic or Thai characters" This seems to be a copy of the original bug, but surely all we have now is a test bug ?? JDK-8233177 should be re-titled to something like "Test case for bug JDK-8001470 fails if there are missing glyphs" and the description really should be about that problem NOT the original problem. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17528#issuecomment-1912809231 From prr at openjdk.org Fri Jan 26 23:11:35 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 26 Jan 2024 23:11:35 GMT Subject: RFR: 8233177: JTextField's size is computed incorrectly when it contains Indic or Thai characters In-Reply-To: <1tSDJFfu0pZi2sg4m1qlPDMeq0xvw4ifMlC4LOTOfLQ=.53bc95ea-ab2b-48d6-9d54-a61f59e44789@github.com> References: <1tSDJFfu0pZi2sg4m1qlPDMeq0xvw4ifMlC4LOTOfLQ=.53bc95ea-ab2b-48d6-9d54-a61f59e44789@github.com> Message-ID: On Wed, 24 Jan 2024 02:35:17 GMT, Sergey Bylokhov wrote: >> Existing regression test is failing because textfield height is not as per test's expectation..Seems like the indic character being tried to render is not being loaded (probably because of missing glyphs) leading to 0 preferredSpan from [BoxView](https://github.com/openjdk/jdk/blame/5a74c2a67ebcb47e51732f03c4be694bdf920469/src/java.desktop/share/classes/javax/swing/text/BoxView.java#L545-L552) which is superclass for `i18nFieldVIew`, the field view for Indic characters. >> Tried block character in the test which is now being loaded properly leading to correct height.. > > test/jdk/javax/swing/plaf/basic/BasicTextUI/8001470/bug8001470.java line 58: > >> 56: >> 57: textField1 = new JTextField("\u2588"); >> 58: textField2 = new JTextField("\u2588"); > > You do not need to test the same character twice This isn't right. The test MUST use the Indic and Thai characters else the test is pointless. The problem of them being unavailable in the font should be solved by using Font.canDisplay(char) to find a font that DOES support them. If no font supports them, then it becomes a question of policy .. do you want the test to silently pass or should the test fail because the system running this test really should have those fonts. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17528#discussion_r1468227213 From aivanov at openjdk.org Fri Jan 26 23:21:33 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 26 Jan 2024 23:21:33 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: On Fri, 26 Jan 2024 22:57:49 GMT, Sergey Bylokhov wrote: > > I don't think we are able to trace it out, since the issue intermittent and previously I had made a copy of the vector list before checking for equality of the list. There was again an issue in the code which I used to copy to a temporary vector. So now instead of using` AbstractList.equals` I'm using iterators and comparing every element within synchronized method. > > I think we should start investigating this one, probably by adding special delays/asserts into the JDK to track down on what threads the data is modified and used. According to my analysis above, there there are two threads. (The third thread is also possible if `validateFileCache` is called not on EDT.) The only thread that modifies `fileCache` is EDT with `DoChangeContents`. Then the `ShellFolder` thread reads from `fileCache` *without synchronisation*, which allows the contents of `fileCache` to be modified concurrently. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17462#issuecomment-1912818487 From achung at openjdk.org Sat Jan 27 05:44:49 2024 From: achung at openjdk.org (Alisen Chung) Date: Sat, 27 Jan 2024 05:44:49 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v7] In-Reply-To: References: Message-ID: > SunToolkit.java is trying to post an event on the TrayIcon appContext, but the TrayIcon was already removed by the test, causing an error. The fix is to make SunToolkit skip posting the event if appContext is null. The test is also updated to remove applet usage and use PassFailJFrame instead. Alisen Chung 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 ten additional commits since the last revision: - remove null check in SunToolkit, remove setting target to null in CTrayIcon - Merge branch 'master' of https://github.com/openjdk/jdk into 8316931 - added suggested changes, moved test back into folder - added suggested changes, moved test back into folder - used jtreg.SkippedException, updated copyright years - removed extra newlines, moved test out of folder - spacing - updated test title, copyright year, removed redundant check - removed applet usage in test, fixed event posted on wrong app context bug ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17329/files - new: https://git.openjdk.org/jdk/pull/17329/files/a9693565..fed411c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17329&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17329&range=05-06 Stats: 33627 lines in 1063 files changed: 19094 ins; 10650 del; 3883 mod Patch: https://git.openjdk.org/jdk/pull/17329.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17329/head:pull/17329 PR: https://git.openjdk.org/jdk/pull/17329 From achung at openjdk.org Sat Jan 27 05:57:51 2024 From: achung at openjdk.org (Alisen Chung) Date: Sat, 27 Jan 2024 05:57:51 GMT Subject: RFR: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws and exception on Mac OS 14(x64, aarch64) [v8] In-Reply-To: References: Message-ID: > SunToolkit.java is trying to post an event on the TrayIcon appContext, but the TrayIcon was already removed by the test, causing an error. The fix is to make SunToolkit skip posting the event if appContext is null. The test is also updated to remove applet usage and use PassFailJFrame instead. Alisen Chung 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 10 additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into 8316931 - remove null check in SunToolkit, remove setting target to null in CTrayIcon - Merge branch 'master' of https://github.com/openjdk/jdk into 8316931 - added suggested changes, moved test back into folder - added suggested changes, moved test back into folder - used jtreg.SkippedException, updated copyright years - removed extra newlines, moved test out of folder - spacing - updated test title, copyright year, removed redundant check - removed applet usage in test, fixed event posted on wrong app context bug ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17329/files - new: https://git.openjdk.org/jdk/pull/17329/files/fed411c1..96e0590d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17329&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17329&range=06-07 Stats: 18 lines in 2 files changed: 15 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17329.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17329/head:pull/17329 PR: https://git.openjdk.org/jdk/pull/17329 From clanger at openjdk.org Sat Jan 27 06:47:34 2024 From: clanger at openjdk.org (Christoph Langer) Date: Sat, 27 Jan 2024 06:47:34 GMT Subject: RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations [v2] In-Reply-To: References: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> Message-ID: On Thu, 25 Jan 2024 06:36:36 GMT, Christoph Langer wrote: >> This picks up fixing the issue of [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) again. A fix had been integrated with #17224 but @prrace had concerns and so it was backed out. >> >> I have now spent quite some thoughts into the problem and end up with the [initial commit](https://github.com/openjdk/jdk/pull/6306/commits/5d18a76cb967e9ede6394cbd6c28bb61facf785c) of #6306 as the most elegant and least intrusive solution. >> >> Why is this? >> >> The JNI warning we observe in the test is: >> `[WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV >> at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 22.0.1-internal/Native Method) >> at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:95) >> at sun.awt.Win32GraphicsEnvironment.(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:63) >> ... >> at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) >> at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)` >> >> This happens because obviously the test FreeTypeScalerJNICheck runs with `-Xcheck:jni` and in the scenario where we're observing the warning, a missing exception check for the JNI call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged` at awt_Win32GraphicsEnv.cpp#L129 >> https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L129 is airing up. Omitting the exception check would not be a problem if it could be guaranteed that after this call no other JNI->Java call was being made. But seemingly in this very particular configuration on some of our Windows servers, there must be JNI->Java calls that follow the call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged`, likely from the subsequent call to [initScreens](https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L149) in `sun.awt.Win32GraphicsEnvironment::initDisplay`. https://github.com/openjdk/jdk/blob/8b6293f6bfb7b7628c6604e6c44401fc96d85cf4/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L141 Maybe the usual control flow would call the wrapping native method `DWMIsComposit ionEnabled()` from somewhere else initially such that the initialization of `Win32GraphicsEnvironment` would not go ... > > Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Changes to assertion function and test as discussed > - Revert "JDK-8323664" > > This reverts commit 32128744252d75104e0d19f5eb701ffdc7b3d417. > - Merge branch 'master' into JDK-8323664 > - JDK-8323664 Thanks for the review. For some reason, however, I still saw the jni warning in our env with the patch applied. Still looking into it to understand what I'm missing... ------------- PR Comment: https://git.openjdk.org/jdk/pull/17404#issuecomment-1913036374 From kevinw at openjdk.org Sat Jan 27 11:57:35 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Sat, 27 Jan 2024 11:57:35 GMT Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test native code files [v3] In-Reply-To: <9n3_W-gEDmcSZz8z5V_d-93x1Gy2Zl005gPEepDdIC4=.f7906413-3999-4e0d-acf3-bc7d8cc1d89b@github.com> References: <9n3_W-gEDmcSZz8z5V_d-93x1Gy2Zl005gPEepDdIC4=.f7906413-3999-4e0d-acf3-bc7d8cc1d89b@github.com> Message-ID: <8G5I-7bp7jVg891XRUkSWJ6DMOoOBkhfkpNPNt40Ti0=.9e8391a5-9034-4b49-b0ee-ae3a62f37c32@github.com> On Fri, 26 Jan 2024 21:06:00 GMT, Coleen Phillimore wrote: >> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code. This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say. It does attempt to change NULL to "null" rather than "nullptr" in strings. Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated. >> >> Ran tier1-4 testing. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix nullptr only contained in strings. test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTest/libVThreadTest.cpp line 426: > 424: } > 425: > 426: // #5: Test JVMTI GetLocalObject function with nullptr value_ptr "with null value_ptr" ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17593#discussion_r1468449036 From kevinw at openjdk.org Sat Jan 27 12:24:34 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Sat, 27 Jan 2024 12:24:34 GMT Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test native code files [v3] In-Reply-To: <9n3_W-gEDmcSZz8z5V_d-93x1Gy2Zl005gPEepDdIC4=.f7906413-3999-4e0d-acf3-bc7d8cc1d89b@github.com> References: <9n3_W-gEDmcSZz8z5V_d-93x1Gy2Zl005gPEepDdIC4=.f7906413-3999-4e0d-acf3-bc7d8cc1d89b@github.com> Message-ID: On Fri, 26 Jan 2024 21:06:00 GMT, Coleen Phillimore wrote: >> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code. This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say. It does attempt to change NULL to "null" rather than "nullptr" in strings. Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated. >> >> Ran tier1-4 testing. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix nullptr only contained in strings. That is long. Hypnotic to read. One very trivial nit, use or ignore as required, but all good that I can see. ------------- Marked as reviewed by kevinw (Committer). PR Review: https://git.openjdk.org/jdk/pull/17593#pullrequestreview-1847074612 From coleenp at openjdk.org Sat Jan 27 18:24:45 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sat, 27 Jan 2024 18:24:45 GMT Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test native code files [v4] In-Reply-To: References: Message-ID: > This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code. This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say. It does attempt to change NULL to "null" rather than "nullptr" in strings. Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated. > > Ran tier1-4 testing. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix one nullptr in comments as found by @kevinw ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17593/files - new: https://git.openjdk.org/jdk/pull/17593/files/33786c7d..6eb051ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17593&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17593&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17593.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17593/head:pull/17593 PR: https://git.openjdk.org/jdk/pull/17593 From kbarrett at openjdk.org Sun Jan 28 20:28:26 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 28 Jan 2024 20:28:26 GMT Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test native code files [v4] In-Reply-To: References: Message-ID: On Sat, 27 Jan 2024 18:24:45 GMT, Coleen Phillimore wrote: >> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code. This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say. It does attempt to change NULL to "null" rather than "nullptr" in strings. Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated. >> >> Ran tier1-4 testing. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix one nullptr in comments as found by @kevinw Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17593#pullrequestreview-1847625136 From rkannathpari at openjdk.org Mon Jan 29 05:00:42 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Mon, 29 Jan 2024 05:00:42 GMT Subject: RFR: 8320676 : Manual printer tests have no Pass/Fail buttons, instructions close [v3] In-Reply-To: References: <2wXUf4vAMV71MSxsWLestkIC08y7ZxIkOk3XKGJPXeI=.a7cad7de-3bcc-41be-850c-3c68fb254194@github.com> Message-ID: On Fri, 26 Jan 2024 00:27:45 GMT, Harshitha Onkar wrote: >> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed whitespace errors > > @Renjithkannath There are many test changes in a single PR, it would be easier to review if the tests are split into different PRs. For instance one PR/JBS issue per 5-6 tests. @honkar-jdk Thank you for your suggestion will split this into 3 separate set for easy to review. Closing this ------------- PR Comment: https://git.openjdk.org/jdk/pull/17565#issuecomment-1913961900 From rkannathpari at openjdk.org Mon Jan 29 05:00:42 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Mon, 29 Jan 2024 05:00:42 GMT Subject: Withdrawn: 8320676 : Manual printer tests have no Pass/Fail buttons, instructions close In-Reply-To: References: Message-ID: On Thu, 25 Jan 2024 04:52:15 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > > Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured. > > Please review and let me know your suggestions. > > Regards, > Renjith This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/17565 From dholmes at openjdk.org Mon Jan 29 05:32:34 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 Jan 2024 05:32:34 GMT Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test native code files [v4] In-Reply-To: References: Message-ID: On Sat, 27 Jan 2024 18:24:45 GMT, Coleen Phillimore wrote: >> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code. This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say. It does attempt to change NULL to "null" rather than "nullptr" in strings. Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated. >> >> Ran tier1-4 testing. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix one nullptr in comments as found by @kevinw Looks good. Thanks for doing the text changes as well, they are a necessary part of the cleanup. A number of files are missing copyright updates - the ones I spotted all had a single copyright year so maybe your script missed them? My browser found 21 places where nullptr is cast to something else, which should no longer be needed. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17593#pullrequestreview-1847855251 From psadhukhan at openjdk.org Mon Jan 29 06:18:50 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 29 Jan 2024 06:18:50 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI [v4] In-Reply-To: References: Message-ID: > When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak. > When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. > Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500) > > FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Use removeAll and testcase modified ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17458/files - new: https://git.openjdk.org/jdk/pull/17458/files/de37cc96..9d49e61a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17458&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17458&range=02-03 Stats: 61 lines in 2 files changed: 21 ins; 21 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/17458.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17458/head:pull/17458 PR: https://git.openjdk.org/jdk/pull/17458 From psadhukhan at openjdk.org Mon Jan 29 06:18:50 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 29 Jan 2024 06:18:50 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI [v3] In-Reply-To: References: <1xfZ5RyTcjtAZ87SQYOMdNYYRnc76Fxr0m05vbktyZQ=.4e4e71a5-351f-4654-90e6-c21e2a199894@github.com> Message-ID: On Wed, 24 Jan 2024 20:25:26 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Retain last component in rendererPane. Testcase added > > test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 62: > >> 60: } >> 61: >> 62: public void finalize( ) { > > The `finalize` method is deprecated. Can't we use `Reference` API for this purpose? > > Store a list of [`PhantomReference`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/ref/PhantomReference.html). The size of the list is the number of `JLabel` objects created. Once you receive a reference via the [`ReferenceQueue`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/ref/ReferenceQueue.html), remove it from the list. I was not sure of the nuances of PhantomReference and ReferenceQueue, so have used WeakReference logic in the test which I think is more simpler.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1469118605 From rkannathpari at openjdk.org Mon Jan 29 06:29:45 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Mon, 29 Jan 2024 06:29:45 GMT Subject: RFR: 8320676 : Manual printer tests have no Pass/Fail buttons, instructions close Message-ID: Hi Reviewers, Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured. Please review and let me know your suggestions. Regards, Renjith ------------- Commit messages: - JDK-8320676 : Manual printer tests have no Pass/Fail buttons, instructions close Changes: https://git.openjdk.org/jdk/pull/17607/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17607&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320676 Stats: 1650 lines in 5 files changed: 401 ins; 885 del; 364 mod Patch: https://git.openjdk.org/jdk/pull/17607.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17607/head:pull/17607 PR: https://git.openjdk.org/jdk/pull/17607 From psadhukhan at openjdk.org Mon Jan 29 06:47:50 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 29 Jan 2024 06:47:50 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v12] In-Reply-To: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> Message-ID: > javadoc contract for JComponent.setMinimumSize(Dimension) states: > > "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..." > > However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize() > > Fix is made to check if mnimumSize is set and if so, honour it.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: javadoc update in JScrollbar and JComponent ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15325/files - new: https://git.openjdk.org/jdk/pull/15325/files/2a42f5c5..10b670c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15325&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15325&range=10-11 Stats: 16 lines in 2 files changed: 6 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/15325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15325/head:pull/15325 PR: https://git.openjdk.org/jdk/pull/15325 From psadhukhan at openjdk.org Mon Jan 29 06:47:50 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 29 Jan 2024 06:47:50 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v11] In-Reply-To: References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> Message-ID: On Tue, 23 Jan 2024 03:37:45 GMT, Prasanta Sadhukhan wrote: >> javadoc contract for JComponent.setMinimumSize(Dimension) states: >> >> "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..." >> >> However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize() >> >> Fix is made to check if mnimumSize is set and if so, honour it.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > PR update as per review Added JComponent clarification to address CSR concern.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15325#issuecomment-1914059351 From duke at openjdk.org Mon Jan 29 06:56:58 2024 From: duke at openjdk.org (vtstydev) Date: Mon, 29 Jan 2024 06:56:58 GMT Subject: RFR: 8307246 : Printing: banded raster path doesn't account for device offset values [v7] In-Reply-To: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com> References: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com> Message-ID: > More correct way to take in consideration nonzero PHYSICALOFFSETX, PHYSICALOFFSETY of device for banded-raster printing loop. Only on Windows platform under certain conditions real device prints shifted image on paper. vtstydev has updated the pull request incrementally with one additional commit since the last revision: Fix header and imports section in AlphaPrintingOffsets ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17030/files - new: https://git.openjdk.org/jdk/pull/17030/files/62168fb3..57659d33 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17030&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17030&range=05-06 Stats: 40 lines in 1 file changed: 15 ins; 4 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/17030.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17030/head:pull/17030 PR: https://git.openjdk.org/jdk/pull/17030 From rkannathpari at openjdk.org Mon Jan 29 06:59:54 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Mon, 29 Jan 2024 06:59:54 GMT Subject: RFR: 8324807 : Manual printer tests have no Pass/Fail buttons, instructions close set 2 Message-ID: Hi Reviewers, Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured. Please review and let me know your suggestions. Regards, Renjith ------------- Commit messages: - JDK-8324807 : Manual printer tests have no Pass/Fail buttons, instructions close set 2 Changes: https://git.openjdk.org/jdk/pull/17608/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17608&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324807 Stats: 1181 lines in 6 files changed: 201 ins; 825 del; 155 mod Patch: https://git.openjdk.org/jdk/pull/17608.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17608/head:pull/17608 PR: https://git.openjdk.org/jdk/pull/17608 From clanger at openjdk.org Mon Jan 29 07:13:49 2024 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 29 Jan 2024 07:13:49 GMT Subject: RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations [v3] In-Reply-To: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> References: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> Message-ID: > This picks up fixing the issue of [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) again. A fix had been integrated with #17224 but @prrace had concerns and so it was backed out. > > I have now spent quite some thoughts into the problem and end up with the [initial commit](https://github.com/openjdk/jdk/pull/6306/commits/5d18a76cb967e9ede6394cbd6c28bb61facf785c) of #6306 as the most elegant and least intrusive solution. > > Why is this? > > The JNI warning we observe in the test is: > `[WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV > at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 22.0.1-internal/Native Method) > at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:95) > at sun.awt.Win32GraphicsEnvironment.(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:63) > ... > at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) > at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)` > > This happens because obviously the test FreeTypeScalerJNICheck runs with `-Xcheck:jni` and in the scenario where we're observing the warning, a missing exception check for the JNI call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged` at awt_Win32GraphicsEnv.cpp#L129 > https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L129 is airing up. Omitting the exception check would not be a problem if it could be guaranteed that after this call no other JNI->Java call was being made. But seemingly in this very particular configuration on some of our Windows servers, there must be JNI->Java calls that follow the call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged`, likely from the subsequent call to [initScreens](https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L149) in `sun.awt.Win32GraphicsEnvironment::initDisplay`. https://github.com/openjdk/jdk/blob/8b6293f6bfb7b7628c6604e6c44401fc96d85cf4/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L141 Maybe the usual control flow would call the wrapping native method `DWMIsCompositi onEnabled()` from somewhere else initially such that the initialization of `Win32GraphicsEnvironment` would not go through `initScreens` or similar. > ... Christoph Langer 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: - Move Exception Check to the right place - Merge branch 'master' into JDK-8323664 - Changes to assertion function and test as discussed - Revert "JDK-8323664" This reverts commit 32128744252d75104e0d19f5eb701ffdc7b3d417. - Merge branch 'master' into JDK-8323664 - JDK-8323664 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17404/files - new: https://git.openjdk.org/jdk/pull/17404/files/74e28e13..528f25bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17404&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17404&range=01-02 Stats: 3518 lines in 240 files changed: 2468 ins; 488 del; 562 mod Patch: https://git.openjdk.org/jdk/pull/17404.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17404/head:pull/17404 PR: https://git.openjdk.org/jdk/pull/17404 From clanger at openjdk.org Mon Jan 29 07:13:50 2024 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 29 Jan 2024 07:13:50 GMT Subject: RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations [v2] In-Reply-To: References: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> Message-ID: On Sat, 27 Jan 2024 06:44:59 GMT, Christoph Langer wrote: > Thanks for the review. For some reason, however, I still saw the jni warning in our env with the patch applied. Still looking into it to understand what I'm missing... OK, got it. The exception check needs to be before the call to FindClass. Now the patch is correct and does what it is supposed to do. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17404#issuecomment-1914087545 From rkannathpari at openjdk.org Mon Jan 29 07:27:54 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Mon, 29 Jan 2024 07:27:54 GMT Subject: RFR: 8324808 : Manual printer tests have no Pass/Fail buttons, instructions close set 3 Message-ID: Hi Reviewers, Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured. Please review and let me know your suggestions. Regards, Renjith ------------- Commit messages: - JDK-8324808 : Manual printer tests have no Pass/Fail buttons, instructions close set 3 Changes: https://git.openjdk.org/jdk/pull/17609/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17609&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324808 Stats: 1427 lines in 6 files changed: 203 ins; 841 del; 383 mod Patch: https://git.openjdk.org/jdk/pull/17609.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17609/head:pull/17609 PR: https://git.openjdk.org/jdk/pull/17609 From aivanov at openjdk.org Mon Jan 29 10:10:32 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 29 Jan 2024 10:10:32 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v12] In-Reply-To: References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> Message-ID: On Mon, 29 Jan 2024 06:47:50 GMT, Prasanta Sadhukhan wrote: >> javadoc contract for JComponent.setMinimumSize(Dimension) states: >> >> "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..." >> >> However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize() >> >> Fix is made to check if mnimumSize is set and if so, honour it.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > javadoc update in JScrollbar and JComponent Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/JComponent.java line 1: > 1: /* Update the copyright year. src/java.desktop/share/classes/javax/swing/JComponent.java line 1747: > 1745: * Subclasses may choose to override this by returning its own maximum size > 1746: * in its {@code getMaximumSize} method. > 1747: * Setting the maximum size to null restores the default behavior. I'd leave null-related where it was because it belongs to the description of the default behaviour. And subclasses can override the default behaviour. Suggestion: * to compute it. Setting the maximum size to null * restores the default behavior. *

* Subclasses may choose to override this by returning its own maximum size * in its {@code getMaximumSize} method. Add `

` to start a new paragraph in the javadoc so that the statement is easier to notice. I suggest to keep one style, either use `` or `{@code}` everywhere. Using different styles doesn't look good. Since the modern way is to use `{@code}`, it makes sense to update the entire method doc. Yet it will make it harder to find the important changes. src/java.desktop/share/classes/javax/swing/JScrollBar.java line 1: > 1: /* Update the copyright year. src/java.desktop/share/classes/javax/swing/JScrollBar.java line 785: > 783: * Returns the minimum size for the {@code JScrollBar}. > 784: * The scrollbar is flexible along its scrolling axis and > 785: * rigid along the other axis. I would rather clarify this property by describing how the returned value is derived from the preferred size. Does it make sense? Should it be an `@implNote` rather than a spec? Or is it completely unnecessary? src/java.desktop/share/classes/javax/swing/JScrollBar.java line 786: > 784: * The scrollbar is flexible along its scrolling axis and > 785: * rigid along the other axis. > 786: * As specified in {@code setMinimumSize} JScrollBar will derive the This doesn't look good to me. It is `getMinimumSize` that specifies what is returned; `setMinimumSize` just warns the programmer that `getMinimumSize` ignores the value passed to the `set-` method. ------------- PR Review: https://git.openjdk.org/jdk/pull/15325#pullrequestreview-1848268260 PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1469346534 PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1469344802 PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1469346296 PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1469358497 PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1469351797 From psadhukhan at openjdk.org Mon Jan 29 10:20:52 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 29 Jan 2024 10:20:52 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v13] In-Reply-To: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> Message-ID: > javadoc contract for JComponent.setMinimumSize(Dimension) states: > > "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..." > > However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize() > > Fix is made to check if mnimumSize is set and if so, honour it.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: javadoc change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15325/files - new: https://git.openjdk.org/jdk/pull/15325/files/10b670c1..66a50bce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15325&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15325&range=11-12 Stats: 12 lines in 2 files changed: 4 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15325/head:pull/15325 PR: https://git.openjdk.org/jdk/pull/15325 From psadhukhan at openjdk.org Mon Jan 29 10:20:53 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 29 Jan 2024 10:20:53 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v12] In-Reply-To: References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> Message-ID: <_3W99VzW6qV2MJdOIgDyAhlPUcXCk8f3Kio5P93vl0U=.baa185d4-2ca0-4373-b652-cd6646e72f45@github.com> On Mon, 29 Jan 2024 10:07:35 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> javadoc update in JScrollbar and JComponent > > src/java.desktop/share/classes/javax/swing/JScrollBar.java line 785: > >> 783: * Returns the minimum size for the {@code JScrollBar}. >> 784: * The scrollbar is flexible along its scrolling axis and >> 785: * rigid along the other axis. > > I would rather clarify this property by describing how the returned value is derived from the preferred size. Does it make sense? Should it be an `@implNote` rather than a spec? Or is it completely unnecessary? Not sure..Since it is already reviewed and approved by Phil, I chose to keep it same.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1469371280 From psadhukhan at openjdk.org Mon Jan 29 10:26:54 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 29 Jan 2024 10:26:54 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v14] In-Reply-To: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> Message-ID: > javadoc contract for JComponent.setMinimumSize(Dimension) states: > > "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..." > > However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize() > > Fix is made to check if mnimumSize is set and if so, honour it.. Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - Merge master - javadoc change - javadoc update in JScrollbar and JComponent - PR update as per review - PR update as per review - javadoc updated - Honour max/min size if set by user - Override set*Methods and update spec - Reinstate setEnabled - Remove unneeded methods - ... and 10 more: https://git.openjdk.org/jdk/compare/3066d49c...1d8fff40 ------------- Changes: https://git.openjdk.org/jdk/pull/15325/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15325&range=13 Stats: 51 lines in 2 files changed: 42 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/15325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15325/head:pull/15325 PR: https://git.openjdk.org/jdk/pull/15325 From tr at openjdk.org Mon Jan 29 10:31:26 2024 From: tr at openjdk.org (Tejesh R) Date: Mon, 29 Jan 2024 10:31:26 GMT Subject: RFR: JDK-8324733 : [macos14] Problem list tests which fail due to macOS bug described in JDK-8322653 In-Reply-To: References: Message-ID: On Fri, 26 Jan 2024 20:25:12 GMT, Harshitha Onkar wrote: > Following tests fail on macOS 14 and thus being problemlisted. The reason for the failures is tracked as an external macOS platform bug by [JDK-8322653](https://bugs.openjdk.org/browse/JDK-8322653). Marked as reviewed by tr (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17597#pullrequestreview-1848337622 From aivanov at openjdk.org Mon Jan 29 11:35:48 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 29 Jan 2024 11:35:48 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v14] In-Reply-To: References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> Message-ID: On Mon, 29 Jan 2024 10:26:54 GMT, Prasanta Sadhukhan wrote: >> javadoc contract for JComponent.setMinimumSize(Dimension) states: >> >> "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..." >> >> However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize() >> >> Fix is made to check if mnimumSize is set and if so, honour it.. > > Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge master > - javadoc change > - javadoc update in JScrollbar and JComponent > - PR update as per review > - PR update as per review > - javadoc updated > - Honour max/min size if set by user > - Override set*Methods and update spec > - Reinstate setEnabled > - Remove unneeded methods > - ... and 10 more: https://git.openjdk.org/jdk/compare/3066d49c...1d8fff40 Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/JComponent.java line 1748: > 1746: *

> 1747: * Subclasses may choose to override this by returning its own maximum size > 1748: * in its {@code getMaximumSize} method. Suggestion: * Subclasses may choose to override this by returning their own maximum size * in the {@code getMaximumSize} method. ?Subclasses? is plural and therefore requires plural possessive pronoun. src/java.desktop/share/classes/javax/swing/JComponent.java line 1792: > 1790: *

> 1791: * Subclasses may choose to override this by returning its own minimum size > 1792: * in its {@code getMinimumSize} method. Suggestion: * Subclasses may choose to override this by returning their own minimum size * in the {@code getMinimumSize} method. src/java.desktop/share/classes/javax/swing/JScrollBar.java line 790: > 788: * fixed minimum size in the other. > 789: * > 790: * @return the minimum size as specified above. Suggestion: * @return the minimum size as specified above `@return` tags usually don't have a period in the end. Let's follow it for consistency. ------------- PR Review: https://git.openjdk.org/jdk/pull/15325#pullrequestreview-1848427511 PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1469441820 PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1469442444 PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1469454747 From aivanov at openjdk.org Mon Jan 29 11:35:49 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 29 Jan 2024 11:35:49 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v12] In-Reply-To: <_3W99VzW6qV2MJdOIgDyAhlPUcXCk8f3Kio5P93vl0U=.baa185d4-2ca0-4373-b652-cd6646e72f45@github.com> References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> <_3W99VzW6qV2MJdOIgDyAhlPUcXCk8f3Kio5P93vl0U=.baa185d4-2ca0-4373-b652-cd6646e72f45@github.com> Message-ID: <5xNTmunLRaBKAcXau1hH4OGyCBRDaWBapnXui5W2_Jc=.d4755364-8223-47ce-a656-11a260eaa873@github.com> On Mon, 29 Jan 2024 10:17:29 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/share/classes/javax/swing/JScrollBar.java line 785: >> >>> 783: * Returns the minimum size for the {@code JScrollBar}. >>> 784: * The scrollbar is flexible along its scrolling axis and >>> 785: * rigid along the other axis. >> >> I would rather clarify this property by describing how the returned value is derived from the preferred size. Does it make sense? Should it be an `@implNote` rather than a spec? Or is it completely unnecessary? > > Not sure..Since it is already reviewed and approved by Phil, I chose to keep it same.. This change requires a CSR which hasn't been approved yet. It's an opportunity to improve the specification for `getMinimumSize` and `getMaximumSize`. After the CSR is approved, further updates will be more of a hassle. This is why I'm asking these questions here. ?No, we don't want to update,? is also a valid answer. Let's see what @prrace has to say. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15325#discussion_r1469448996 From psadhukhan at openjdk.org Mon Jan 29 13:10:03 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 29 Jan 2024 13:10:03 GMT Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v15] In-Reply-To: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com> Message-ID: > javadoc contract for JComponent.setMinimumSize(Dimension) states: > > "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..." > > However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize() > > Fix is made to check if mnimumSize is set and if so, honour it.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: review update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15325/files - new: https://git.openjdk.org/jdk/pull/15325/files/1d8fff40..4937fccc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15325&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15325&range=13-14 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15325/head:pull/15325 PR: https://git.openjdk.org/jdk/pull/15325 From coleenp at openjdk.org Mon Jan 29 13:47:10 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 29 Jan 2024 13:47:10 GMT Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test native code files [v5] In-Reply-To: References: Message-ID: > This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code. This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say. It does attempt to change NULL to "null" rather than "nullptr" in strings. Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated. > > Ran tier1-4 testing. Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision: - Fix some casts unnecessary with nullptr - Fix copyrights ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17593/files - new: https://git.openjdk.org/jdk/pull/17593/files/6eb051ed..6ac8aa85 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17593&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17593&range=03-04 Stats: 32 lines in 27 files changed: 0 ins; 0 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/17593.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17593/head:pull/17593 PR: https://git.openjdk.org/jdk/pull/17593 From coleenp at openjdk.org Mon Jan 29 14:26:38 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 29 Jan 2024 14:26:38 GMT Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test native code files [v5] In-Reply-To: References: Message-ID: On Mon, 29 Jan 2024 13:47:10 GMT, Coleen Phillimore wrote: >> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code. This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say. It does attempt to change NULL to "null" rather than "nullptr" in strings. Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated. >> >> Ran tier1-4 testing. > > Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision: > > - Fix some casts unnecessary with nullptr > - Fix copyrights Thanks Kevin, Kim and David for wading through this. If there are other changes we can address them separately preserving your eyeballs. My copyright script was broken so I fixed it. I'll wait for GHA to make sure I didn't break anything before integrating. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17593#issuecomment-1914798074 From aivanov at openjdk.org Mon Jan 29 14:27:28 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 29 Jan 2024 14:27:28 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException [v2] In-Reply-To: References: Message-ID: On Thu, 25 Jan 2024 13:58:50 GMT, Tejesh R wrote: >> Suggested fix [JDK-8307091](https://bugs.openjdk.org/browse/JDK-8307091) also created concurrent exception intermittently (monthly once/quarterly once) on CI system. The issue was not able to be reproduced yet, hence proposing an alternative fix which uses iterators to compare the List. >> CI testing shows green. > > Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Revert fix 8307091 + Synchronised filecache > - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8323670 > - Fix > > > I don't think we are able to trace it out, since the issue intermittent and previously I had made a copy of the vector list before checking for equality of the list. There was again an issue in the code which I used to copy to a temporary vector. So now instead of using` AbstractList.equals` I'm using iterators and comparing every element within synchronized method. > > > > > > I think we should start investigating this one, probably by adding special delays/asserts into the JDK to track down on what threads the data is modified and used. > > According to my analysis above, there there are two threads. (The third thread is also possible if `validateFileCache` is called not on EDT.) The only thread that modifies `fileCache` is EDT with `DoChangeContents`. Then the `ShellFolder` thread reads from `fileCache` _without synchronisation_, which allows the contents of `fileCache` to be modified concurrently. Upon further testing, I found out that `ShellFolder.invoke` runs in the calling thread on Linux and macOS, on Windows it runs on the COM thread where Windows Shell is accessed. In addition to this, there's [`AquaFileSystemModel`](https://github.com/openjdk/jdk/blob/master/src/java.desktop/macosx/classes/com/apple/laf/AquaFileSystemModel.java). This class is used in Aqua Look-and-Feel on macOS. According to this comment https://github.com/openjdk/jdk/blob/fe0eec7e20bc4c39d6c2b58d81ffd5c0ef1fdeda/src/java.desktop/macosx/classes/com/apple/laf/AquaFileSystemModel.java#L41 the class contains portions of code copied from `BasicDirectoryModel` and therefore could have a similar synchronisation issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17462#issuecomment-1914799788 From clanger at openjdk.org Mon Jan 29 14:30:08 2024 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 29 Jan 2024 14:30:08 GMT Subject: RFR: 8185862: AWT Assertion Failure in ::GetDIBits(hBMDC, hBM, 0, 1, 0, gpBitmapInfo, 0) 'awt_Win32GraphicsDevice.cpp', at line 185 Message-ID: The assertions reported in the bug were observed spuriously and here and there broke tests in some Windows configurations. For instance [JDK-8266129](https://bugs.openjdk.org/browse/JDK-8266129), [JDK-8269529](https://bugs.openjdk.org/browse/JDK-8269529) or [JDK-8323664](https://bugs.openjdk.org/browse/JDK-8323664) came up due to this. The problem is that in Windows environments without a valid display, e.g. started by system services or via PowerShell Remoting, one sees a Monitor with name 'Windisc' in `EnumDisplayMonitors`. However, it seems to be some kind of a pseudo device where you can not get a DC via `CreateDC`. This behavior/monitor type doesn't seem to be well documented, though. I hereby modify the device initialization code to only count/detect monitors where CreateDC returns non-NULL in Devices.cpp. I also add some more checking/error handling to AwtWin32GraphicsDevice::Initialize() for correctness. Furthermore, I re-enable the test `javax/swing/reliability/HangDuringStaticInitialization.java` for Windows Debug VMs, which reverts the fix from JDK-8269529 that should not be necessary any more. ------------- Commit messages: - JDK-8185862 Changes: https://git.openjdk.org/jdk/pull/17614/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17614&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8185862 Stats: 60 lines in 3 files changed: 34 ins; 13 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/17614.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17614/head:pull/17614 PR: https://git.openjdk.org/jdk/pull/17614 From aivanov at openjdk.org Mon Jan 29 14:49:47 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 29 Jan 2024 14:49:47 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: On Fri, 26 Jan 2024 22:57:49 GMT, Sergey Bylokhov wrote: >>> What is the code path which modifies the vector when we iterate it? >> >> I don't think we are able to trace it out, since the issue intermittent and previously I had made a copy of the vector list before checking for equality of the list. There was again an issue in the code which I used to copy to a temporary vector. So now instead of using` AbstractList.equals` I'm using iterators and comparing every element within synchronized method. > >> I don't think we are able to trace it out, since the issue intermittent and previously I had made a copy of the vector list before checking for equality of the list. There was again an issue in the code which I used to copy to a temporary vector. So now instead of using` AbstractList.equals` I'm using iterators and comparing every element within synchronized method. > > I think we should start investigating this one, probably by adding special delays/asserts into the JDK to track down on what threads the data is modified and used. @mrserb I've been trying to write a regression test for this problem. Have I succeeded? Not quite? I am unable to get `ConcurrentModificationException` on any platform when I run the test locally. However, the test fails in the Oracle CI on macOS and Linux, both x86_64 and aarch64, especially when run with `JTREG=REPEAT_COUNT=50`. On Windows, it fails with `OutOfMemoryError`. In the CI on macOS, the test runs in headless mode, in this case `BasicDirectoryModel` is used instead of `AquaFileSystemModel`. Thus, the test is not stable enough. Yet it still allows testing the fix. The test does not fail with `ConcurrentModificationException` when run on the build with the proposed fix in this PR. Could you please run the test too? git fetch https://github.com/aivanov-jdk/jdk.git 8323670-BasicDirectoryModel-concurrency:8323670-BasicDirectoryModel-concurrency git checkout 8323670-BasicDirectoryModel-concurrency java test/jdk/javax/swing/JFileChooser/FileSystemView/BasicDirectoryModelConcurrency.java The commands above are similar to those provided in ?Reviewing using Git? section in PRs on GitHub. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17462#issuecomment-1914844026 From mbaesken at openjdk.org Mon Jan 29 14:49:47 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 29 Jan 2024 14:49:47 GMT Subject: RFR: 8185862: AWT Assertion Failure in ::GetDIBits(hBMDC, hBM, 0, 1, 0, gpBitmapInfo, 0) 'awt_Win32GraphicsDevice.cpp', at line 185 In-Reply-To: References: Message-ID: On Mon, 29 Jan 2024 14:24:43 GMT, Christoph Langer wrote: >However, it seems to be some kind of a pseudo device where you can not get a DC via CreateDC. This behavior/monitor type > doesn't seem to be well documented, though. This was my observation too, but is it always the case ? Unfortunately I couldn't find some documentation on this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17614#issuecomment-1914843748 From mbaesken at openjdk.org Mon Jan 29 14:52:42 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 29 Jan 2024 14:52:42 GMT Subject: RFR: 8185862: AWT Assertion Failure in ::GetDIBits(hBMDC, hBM, 0, 1, 0, gpBitmapInfo, 0) 'awt_Win32GraphicsDevice.cpp', at line 185 In-Reply-To: References: Message-ID: <1GwX2V5VloW4S-R_nBDaKqlI7XB8saZTgZi-V-0M0zo=.51939831-a2d7-4268-a95f-adb85dc13851@github.com> On Mon, 29 Jan 2024 14:24:43 GMT, Christoph Langer wrote: > The assertions reported in the bug were observed spuriously and here and there broke tests in some Windows configurations. > For instance [JDK-8266129](https://bugs.openjdk.org/browse/JDK-8266129), [JDK-8269529](https://bugs.openjdk.org/browse/JDK-8269529) or [JDK-8323664](https://bugs.openjdk.org/browse/JDK-8323664) came up due to this. > > The problem is that in Windows environments without a valid display, e.g. started by system services or via PowerShell Remoting, one sees a Monitor with name 'Windisc' in `EnumDisplayMonitors`. > However, it seems to be some kind of a pseudo device where you can not get a DC via `CreateDC`. This behavior/monitor type doesn't seem to be well documented, though. > > I hereby modify the device initialization code to only count/detect monitors where CreateDC returns non-NULL in Devices.cpp. I also add some more checking/error handling to AwtWin32GraphicsDevice::Initialize() for correctness. > > Furthermore, I re-enable the test `javax/swing/reliability/HangDuringStaticInitialization.java` for Windows Debug VMs, which reverts the fix from JDK-8269529 that should not be necessary any more. Maybe add some comment about the monitor counting, that it only considers now certain monitors with 'good' capabilities ? Or even rename the count function and use a better name indicating what it does now ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17614#issuecomment-1914850222 From mbaesken at openjdk.org Mon Jan 29 15:08:46 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 29 Jan 2024 15:08:46 GMT Subject: RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations [v3] In-Reply-To: References: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> Message-ID: On Mon, 29 Jan 2024 07:13:49 GMT, Christoph Langer wrote: >> This picks up fixing the issue of [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) again. A fix had been integrated with #17224 but @prrace had concerns and so it was backed out. >> >> I have now spent quite some thoughts into the problem and end up with the [initial commit](https://github.com/openjdk/jdk/pull/6306/commits/5d18a76cb967e9ede6394cbd6c28bb61facf785c) of #6306 as the most elegant and least intrusive solution. >> >> Why is this? >> >> The JNI warning we observe in the test is: >> `[WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV >> at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 22.0.1-internal/Native Method) >> at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:95) >> at sun.awt.Win32GraphicsEnvironment.(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:63) >> ... >> at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) >> at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)` >> >> This happens because obviously the test FreeTypeScalerJNICheck runs with `-Xcheck:jni` and in the scenario where we're observing the warning, a missing exception check for the JNI call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged` at awt_Win32GraphicsEnv.cpp#L129 >> https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L129 is airing up. Omitting the exception check would not be a problem if it could be guaranteed that after this call no other JNI->Java call was being made. But seemingly in this very particular configuration on some of our Windows servers, there must be JNI->Java calls that follow the call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged`, likely from the subsequent call to [initScreens](https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L149) in `sun.awt.Win32GraphicsEnvironment::initDisplay`. https://github.com/openjdk/jdk/blob/8b6293f6bfb7b7628c6604e6c44401fc96d85cf4/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L141 Maybe the usual control flow would call the wrapping native method `DWMIsComposit ionEnabled()` from somewhere else initially such that the initialization of `Win32GraphicsEnvironment` would not go ... > > Christoph Langer 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: > > - Move Exception Check to the right place > - Merge branch 'master' into JDK-8323664 > - Changes to assertion function and test as discussed > - Revert "JDK-8323664" > > This reverts commit 32128744252d75104e0d19f5eb701ffdc7b3d417. > - Merge branch 'master' into JDK-8323664 > - JDK-8323664 Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17404#pullrequestreview-1848902722 From coleenp at openjdk.org Mon Jan 29 17:10:42 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 29 Jan 2024 17:10:42 GMT Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test native code files [v5] In-Reply-To: References: Message-ID: On Mon, 29 Jan 2024 13:47:10 GMT, Coleen Phillimore wrote: >> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code. This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say. It does attempt to change NULL to "null" rather than "nullptr" in strings. Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated. >> >> Ran tier1-4 testing. > > Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision: > > - Fix some casts unnecessary with nullptr > - Fix copyrights macos-aarch64 build failure in GHA appears unrelated, internal testing passed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17593#issuecomment-1915186403 From coleenp at openjdk.org Mon Jan 29 17:10:43 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 29 Jan 2024 17:10:43 GMT Subject: Integrated: 8324681: Replace NULL with nullptr in HotSpot jtreg test native code files In-Reply-To: References: Message-ID: On Fri, 26 Jan 2024 16:40:32 GMT, Coleen Phillimore wrote: > This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code. This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say. It does attempt to change NULL to "null" rather than "nullptr" in strings. Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated. > > Ran tier1-4 testing. This pull request has now been integrated. Changeset: a6bdee48 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/a6bdee48f39993128d8095d40ab417f0102af0f4 Stats: 8218 lines in 750 files changed: 0 ins; 7 del; 8211 mod 8324681: Replace NULL with nullptr in HotSpot jtreg test native code files Reviewed-by: kevinw, kbarrett, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/17593 From prr at openjdk.org Mon Jan 29 17:26:45 2024 From: prr at openjdk.org (Phil Race) Date: Mon, 29 Jan 2024 17:26:45 GMT Subject: RFR: 8307246 : Printing: banded raster path doesn't account for device offset values [v7] In-Reply-To: References: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com> Message-ID: On Mon, 29 Jan 2024 06:56:58 GMT, vtstydev wrote: >> More correct way to take in consideration nonzero PHYSICALOFFSETX, PHYSICALOFFSETY of device for banded-raster printing loop. Only on Windows platform under certain conditions real device prints shifted image on paper. > > vtstydev has updated the pull request incrementally with one additional commit since the last revision: > > Fix header and imports section in AlphaPrintingOffsets LGTM @prsadhuk please be the required 2nd reviewer. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17030#pullrequestreview-1849309780 From honkar at openjdk.org Mon Jan 29 18:06:36 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 29 Jan 2024 18:06:36 GMT Subject: Integrated: JDK-8324733 : [macos14] Problem list tests which fail due to macOS bug described in JDK-8322653 In-Reply-To: References: Message-ID: <0ihYb_wBZmFpASi_IrGmM2Y7eEVus5qr7ddo4Sf4Lm0=.b364bc15-3e6c-463b-9938-7af7831f74f4@github.com> On Fri, 26 Jan 2024 20:25:12 GMT, Harshitha Onkar wrote: > Following tests fail on macOS 14 and thus being problemlisted. The reason for the failures is tracked as an external macOS platform bug by [JDK-8322653](https://bugs.openjdk.org/browse/JDK-8322653). This pull request has now been integrated. Changeset: d1e67636 Author: Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/d1e676360d5143cf12655ab1175a4a60bf402473 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod 8324733: [macos14] Problem list tests which fail due to macOS bug described in JDK-8322653 Reviewed-by: prr, tr ------------- PR: https://git.openjdk.org/jdk/pull/17597 From dnguyen at openjdk.org Mon Jan 29 18:40:36 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 29 Jan 2024 18:40:36 GMT Subject: RFR: JDK-8324238 : [macOS] java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails with the shape has not been applied msg In-Reply-To: <2X4lZKPcvcBCgjNBbezJGso48upOQIByUORAeXTOQuQ=.c7cf91b4-1b6b-4d31-95d7-04b2634f8eed@github.com> References: <2X4lZKPcvcBCgjNBbezJGso48upOQIByUORAeXTOQuQ=.c7cf91b4-1b6b-4d31-95d7-04b2634f8eed@github.com> Message-ID: On Thu, 25 Jan 2024 01:03:28 GMT, Harshitha Onkar wrote: > ShapeNotSetSometimes.java fails on macOS 11 on a random iteration of `colorCheck()` as shown below. The `colorCheck()` is repeated for about 50 times in the test. It is observed to pass on previous attempts and fail on a random attempt such as Attempt# 29 shown here. > > Here the point (150, 20) is well in the green area hence the slight color diff picked up by `robot.getPixelColor()` is not due to sampling of color at the edge (which sometimes causes robot to pick up slightly different color). > > > Attempt 29 > Checking 150, 20, java.awt.Color[r=0,g=255,b=1] should be java.awt.Color[r=0,g=255,b=0] > > > Due to the above, I have kept the color sampling points at the same location as earlier and made the following changes to the test: > > - Moved the frame to the center of the screen. > - Instead of comparing exact RGB values, used `colorCompare()` which allows color tolerance of 2 per color component to accommodate slight variations when comparing actual vs expected colors. > > > > Attempt 27 > Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] > Checking 150, 20, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 280, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 150, 250, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 20, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 62, 62, java.awt.Color[r=0,g=243,b=0] should not be java.awt.Color[r=255,g=255,b=255] > Checking 240, 185, java.awt.Color[r=0,g=229,b=0] should not be java.awt.Color[r=255,g=255,b=255] > Attempt 28 > Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] > Checking 150, 20, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 280, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 150, 250, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 20, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 62, 62, java.awt.Color[r=0,g=241,b=0] should not be java.awt.Color[r=255,g=255,b=255] > Checking 240, 185, java.awt.Color[r=0,g=227,b=0] should not be java.awt.Color[r=255,g=255,b=255] > Attempt 29 > Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] > Checking 150, 20, java.awt.Color[r=0,g=255,b=1] should be java.awt.Color[r=0,g=255,b=0] > ----------System.er... Changes LGTM ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/17563#pullrequestreview-1849516266 From aivanov at openjdk.org Mon Jan 29 19:54:26 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 29 Jan 2024 19:54:26 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException [v2] In-Reply-To: References: Message-ID: On Thu, 25 Jan 2024 13:58:50 GMT, Tejesh R wrote: >> Suggested fix [JDK-8307091](https://bugs.openjdk.org/browse/JDK-8307091) also created concurrent exception intermittently (monthly once/quarterly once) on CI system. The issue was not able to be reproduced yet, hence proposing an alternative fix which uses iterators to compare the List. >> CI testing shows green. > > Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Revert fix 8307091 + Synchronised filecache > - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8323670 > - Fix Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java line 1: > 1: /* Please update copyright year. src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java line 32: > 30: import java.beans.PropertyChangeSupport; > 31: import java.io.File; > 32: import java.util.Iterator; Unused import. src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java line 344: > 342: // execute the whole block on the COM thread > 343: runnable = ShellFolder.invoke(new Callable() { > 344: public DoChangeContents call() { To reduce indentation level, you may convert the anonymous class to a lambda expression or even to a method in `FilesLoader` in which case you could use method reference. src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java line 367: > 365: > 366: if (start >= 0 && end > start && newFileCache.subList(end, newSize) > 367: .equals(fileCache.subList(start, oldSize))) { I suggest following the style used before your first fix: Suggestion: if (start >= 0 && end > start && newFileCache.subList(end, newSize) .equals(fileCache.subList(start, oldSize))) { That is wrap at `&&` operator. Then wrap before `.equals` to make the line fit into 80-column limit. src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java line 372: > 370: } > 371: return new DoChangeContents(newFileCache > 372: .subList(start, end), start, null, 0, fid); I don't like such wrapping style. When you read this statement, you miss `newFileCache`, you may think that the call to `subList` is on `DoChangeContents`, which is not the case. I suggest wrapping after the call to `subList`, that is after the first parameter; or wrap before `newFileCache` so that all the parameters are on the next line. src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java line 387: > 385: > 386: if (start >= 0 && end > start && fileCache.subList(end, oldSize) > 387: .equals(newFileCache.subList(start, newSize))) { The same as above: Suggestion: if (start >= 0 && end > start && fileCache.subList(end, oldSize) .equals(newFileCache.subList(start, newSize))) { src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java line 392: > 390: } > 391: return new DoChangeContents(null, 0, new Vector<>(fileCache > 392: .subList(start, end)), start, fid); Wrapping at higher level is preferable: Suggestion: return new DoChangeContents(null, 0, new Vector<>(fileCache.subList(start, end)), start, fid); ------------- PR Review: https://git.openjdk.org/jdk/pull/17462#pullrequestreview-1849605557 PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1470124921 PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1470101630 PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1470123895 PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1470107213 PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1470111897 PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1470117703 PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1470119698 From aivanov at openjdk.org Mon Jan 29 20:49:32 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 29 Jan 2024 20:49:32 GMT Subject: RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations [v3] In-Reply-To: References: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> Message-ID: On Mon, 29 Jan 2024 07:13:49 GMT, Christoph Langer wrote: >> This picks up fixing the issue of [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) again. A fix had been integrated with #17224 but @prrace had concerns and so it was backed out. >> >> I have now spent quite some thoughts into the problem and end up with the [initial commit](https://github.com/openjdk/jdk/pull/6306/commits/5d18a76cb967e9ede6394cbd6c28bb61facf785c) of #6306 as the most elegant and least intrusive solution. >> >> Why is this? >> >> The JNI warning we observe in the test is: >> `[WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV >> at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 22.0.1-internal/Native Method) >> at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:95) >> at sun.awt.Win32GraphicsEnvironment.(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:63) >> ... >> at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) >> at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)` >> >> This happens because obviously the test FreeTypeScalerJNICheck runs with `-Xcheck:jni` and in the scenario where we're observing the warning, a missing exception check for the JNI call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged` at awt_Win32GraphicsEnv.cpp#L129 >> https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L129 is airing up. Omitting the exception check would not be a problem if it could be guaranteed that after this call no other JNI->Java call was being made. But seemingly in this very particular configuration on some of our Windows servers, there must be JNI->Java calls that follow the call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged`, likely from the subsequent call to [initScreens](https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L149) in `sun.awt.Win32GraphicsEnvironment::initDisplay`. https://github.com/openjdk/jdk/blob/8b6293f6bfb7b7628c6604e6c44401fc96d85cf4/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L141 Maybe the usual control flow would call the wrapping native method `DWMIsComposit ionEnabled()` from somewhere else initially such that the initialization of `Win32GraphicsEnvironment` would not go ... > > Christoph Langer 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: > > - Move Exception Check to the right place > - Merge branch 'master' into JDK-8323664 > - Changes to assertion function and test as discussed > - Revert "JDK-8323664" > > This reverts commit 32128744252d75104e0d19f5eb701ffdc7b3d417. > - Merge branch 'master' into JDK-8323664 > - JDK-8323664 Marked as reviewed by aivanov (Reviewer). test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java line 48: > 46: ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder("-Xcheck:jni", FreeTypeScalerJNICheck.class.getName(), "runtest"); > 47: OutputAnalyzer oa = ProcessTools.executeProcess(pb); > 48: oa.shouldContain("Done").shouldNotContain("WARNING").shouldNotContain("AWT Assertion").shouldHaveExitValue(0); Maybe wrap each condition to its own line? Suggestion: oa.shouldContain("Done") .shouldNotContain("WARNING") .shouldNotContain("AWT Assertion") .shouldHaveExitValue(0); This way each verified condition stands out. ------------- PR Review: https://git.openjdk.org/jdk/pull/17404#pullrequestreview-1849728445 PR Review Comment: https://git.openjdk.org/jdk/pull/17404#discussion_r1470188088 From aivanov at openjdk.org Mon Jan 29 20:59:44 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 29 Jan 2024 20:59:44 GMT Subject: RFR: 8270269: Desktop.browse method fails if earlier CoInitialize call as COINIT_MULTITHREADED [v3] In-Reply-To: References: <6kleKtEG40OwclwIOss4ttDnXwdGsTicuIfIqTpFDgw=.adcd6f38-aed2-4686-b178-d724ddff5710@github.com> Message-ID: On Fri, 26 Jan 2024 20:11:07 GMT, MustavData wrote: >> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/java.desktop/windows/native/libawt/windows/awt_Desktop.cpp >> >> date >> >> Co-authored-by: Alexey Ivanov > > I am working to verify the initial fix of JDK-8270269 in OpenJDK 23 (beta). The basic environment is: > > OpenJDK: "Azul Systems, Inc.", "Zulu23+11-CA", "23-beta+1", "x86_64", ".:git:e278d5994c10+" > OS: Windows 11, version 22H2, Build 22621.3007, VC++ 2015-2022 Runtime version 14.38.33130.0 > > The test application is a Java client with the user successfully logged in, following initial launch, against a web application. Here are the basic tests that need to pass: > > 1. Re-authentication after the standard web app timeout of 30 minutes, typically triggered when returning from lunch > 2. Re-authentication after numerous hours, typically triggered when returning to work the next morning > > Results so far: > > 1. Without the initial fix, the Test 1 fails as reported in JDK-8270269 > 2. With the initial fix, Test 1 succeeds, and Test 2 fails with a `java.io.IOException` thrown upon a failure in `CoInitializeEx()` > > Here is the stack trace from the Test 2 failure: > > > java.io.IOException: Failed to open https://. Error message: CoInitializeEx() failed. > at java.desktop/sun.awt.windows.WDesktopPeer.ShellExecute(WDesktopPeer.java:115) > at java.desktop/sun.awt.windows.WDesktopPeer.browse(WDesktopPeer.java:101) > at java.desktop/java.awt.Desktop.browse(Desktop.java:533) @MustavData, according to the line number, you're using a build without Segey's fix: https://github.com/openjdk/jdk/blob/bff7725b4d81c12c0c826933fc2ad4f49a227536/src/java.desktop/windows/classes/sun/awt/windows/WDesktopPeer.java#L114-L117 In the file with this fix, the line number where the exception is thrown is 119: https://github.com/openjdk/jdk/blob/b25ed57b764fc485e4e8ca4118ffb1cc70fdfe7f/src/java.desktop/windows/classes/sun/awt/windows/WDesktopPeer.java#L118-L121 ------------- PR Comment: https://git.openjdk.org/jdk/pull/17010#issuecomment-1915552689 From prr at openjdk.org Mon Jan 29 21:32:42 2024 From: prr at openjdk.org (Phil Race) Date: Mon, 29 Jan 2024 21:32:42 GMT Subject: RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations [v3] In-Reply-To: References: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> Message-ID: On Mon, 29 Jan 2024 07:13:49 GMT, Christoph Langer wrote: >> This picks up fixing the issue of [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) again. A fix had been integrated with #17224 but @prrace had concerns and so it was backed out. >> >> I have now spent quite some thoughts into the problem and end up with the [initial commit](https://github.com/openjdk/jdk/pull/6306/commits/5d18a76cb967e9ede6394cbd6c28bb61facf785c) of #6306 as the most elegant and least intrusive solution. >> >> Why is this? >> >> The JNI warning we observe in the test is: >> `[WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV >> at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 22.0.1-internal/Native Method) >> at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:95) >> at sun.awt.Win32GraphicsEnvironment.(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:63) >> ... >> at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) >> at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)` >> >> This happens because obviously the test FreeTypeScalerJNICheck runs with `-Xcheck:jni` and in the scenario where we're observing the warning, a missing exception check for the JNI call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged` at awt_Win32GraphicsEnv.cpp#L129 >> https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L129 is airing up. Omitting the exception check would not be a problem if it could be guaranteed that after this call no other JNI->Java call was being made. But seemingly in this very particular configuration on some of our Windows servers, there must be JNI->Java calls that follow the call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged`, likely from the subsequent call to [initScreens](https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L149) in `sun.awt.Win32GraphicsEnvironment::initDisplay`. https://github.com/openjdk/jdk/blob/8b6293f6bfb7b7628c6604e6c44401fc96d85cf4/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L141 Maybe the usual control flow would call the wrapping native method `DWMIsComposit ionEnabled()` from somewhere else initially such that the initialization of `Win32GraphicsEnvironment` would not go ... > > Christoph Langer 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: > > - Move Exception Check to the right place > - Merge branch 'master' into JDK-8323664 > - Changes to assertion function and test as discussed > - Revert "JDK-8323664" > > This reverts commit 32128744252d75104e0d19f5eb701ffdc7b3d417. > - Merge branch 'master' into JDK-8323664 > - JDK-8323664 src/java.desktop/windows/native/libawt/windows/awt_Debug.cpp line 160: > 158: env->ExceptionCheck(); > 159: jclass graphicsEnvClass = env->FindClass("java/awt/GraphicsEnvironment"); > 160: FindClass may also throw an Exception, (see https://docs.oracle.com/en/java/javase/21/docs/specs/jni/functions.html#findclass) and in fact so can GetStaticMethodID. So now I'm wondering why these don't also get complained about .. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17404#discussion_r1470241503 From honkar at openjdk.org Tue Jan 30 00:26:42 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 30 Jan 2024 00:26:42 GMT Subject: RFR: 8320676 : Manual printer tests have no Pass/Fail buttons, instructions close In-Reply-To: References: Message-ID: On Mon, 29 Jan 2024 06:24:29 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > > Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured. > > Please review and let me know your suggestions. > > Regards, > Renjith test/jdk/java/awt/print/PageFormat/PageSetupDialog.java line 30: > 28: * @bug 6358747 > 29: * @bug 6574633 > 30: * @summary Page setup dialog settings bug-ids can be added to a single line `@bug 4197377 4299145 6358747 6574633` test/jdk/java/awt/print/PageFormat/PageSetupDialog.java line 77: > 75: boolean reverse = false; > 76: > 77: private static final String instructions = Capitalize static final vars Suggestion: private static final String INSTRUCTIONS = test/jdk/java/awt/print/PageFormat/PageSetupDialog.java line 159: > 157: c.add(pgbm = new Label()); > 158: > 159: reverseCB.addItemListener(new ItemListener() { Can be replaced by lambda expression. There are few other places in the test that require similar changes Suggestion: reverseCB.addItemListener(e -> { test/jdk/java/awt/print/PageFormat/PageSetupDialog.java line 174: > 172: Panel panel = new Panel(); > 173: Button pageButton = new Button("Page Setup..."); > 174: pageButton.addActionListener(new ActionListener() { Suggestion: pageButton.addActionListener(e -> { test/jdk/java/awt/print/PageFormat/PageSetupDialog.java line 181: > 179: }); > 180: Button printButton = new Button("Print ..."); > 181: printButton.addActionListener(new ActionListener() { Here as well. test/jdk/java/awt/print/PageFormat/PageSetupDialog.java line 254: > 252: .instructions(instructions) > 253: .testUI(PageSetupDialog::new) > 254: .testTimeOut(5) Since the default timeout in PassFailJFrame is set to 5 mins, `.testTimeOut(5)` is not necessary. test/jdk/java/awt/print/PrinterJob/Cancel/PrinterJobCancel.java line 61: > 59: "tests apparently aren't supposed to call System.exit()"; > 60: > 61: public static void main(String args[]) throws Exception { Suggestion: public static void main(String[] args) throws Exception { test/jdk/java/awt/print/PrinterJob/PrintAllFonts.java line 35: > 33: > 34: /* > 35: * Remove the extra asterisk '*' test/jdk/java/awt/print/PrinterJob/PrintAllFonts.java line 70: > 68: .title("PrintAllFonts Test Instructions") > 69: .instructions(instructions) > 70: .testTimeOut(5) .testTimeOut(5) can be omitted since default timeout is 5 mins test/jdk/java/awt/print/PrinterJob/ValidatePage/ValidatePage.java line 209: > 207: > 208: Button chooseButton = new Button("Printer.."); > 209: chooseButton.addActionListener(new ActionListener() { Same changes at other places as well Suggestion: chooseButton.addActionListener(e -> { test/jdk/java/awt/print/PrinterJob/ValidatePage/ValidatePage.java line 263: > 261: ta.setEditable(false); > 262: add(ta); > 263: setSize(500, 650); Set paper and Print options are not visible with current frame size. Suggestion: setSize(680, 500); test/jdk/java/awt/print/PrinterJob/raster/RasterTest.java line 65: > 63: "The printed output should match the on-screen display, although\n" + > 64: "only colour printers will be able to accurately reproduce the\n" + > 65: "subtle color changes."; When saved to pdf the gradient square color looks different from the one in the test window. Probably it works as expected on a color printer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17607#discussion_r1470374379 PR Review Comment: https://git.openjdk.org/jdk/pull/17607#discussion_r1470375632 PR Review Comment: https://git.openjdk.org/jdk/pull/17607#discussion_r1470379063 PR Review Comment: https://git.openjdk.org/jdk/pull/17607#discussion_r1470377804 PR Review Comment: https://git.openjdk.org/jdk/pull/17607#discussion_r1470377835 PR Review Comment: https://git.openjdk.org/jdk/pull/17607#discussion_r1470382538 PR Review Comment: https://git.openjdk.org/jdk/pull/17607#discussion_r1470387961 PR Review Comment: https://git.openjdk.org/jdk/pull/17607#discussion_r1470390245 PR Review Comment: https://git.openjdk.org/jdk/pull/17607#discussion_r1470390856 PR Review Comment: https://git.openjdk.org/jdk/pull/17607#discussion_r1470401708 PR Review Comment: https://git.openjdk.org/jdk/pull/17607#discussion_r1470400268 PR Review Comment: https://git.openjdk.org/jdk/pull/17607#discussion_r1470407737 From psadhukhan at openjdk.org Tue Jan 30 04:19:41 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 30 Jan 2024 04:19:41 GMT Subject: RFR: 8259550: The content of the print out displayed incomplete with the NimbusLAF In-Reply-To: References: Message-ID: On Mon, 11 Dec 2023 11:25:34 GMT, Tejesh R wrote: > The issue is w.r.t to way that Synth prints the table. In Synth, the printing of Table happens column wise by painting blocks of columns which is due to the fact that Graphics used which is `ProxyGrpahics2D` (which get selected in `RasterPrinterJob `class, otherwise it would be `WPathGraphics` for other Look and feel). Since the printing happens in block wise and the columns where the x position is greater than the `table.bounds` doesn't gets painted because of the intersection check condition `!bounds.intersects(clip)`. Hence only droplines are painted instead of cells and gridlines. I couldn't find any reason for adding the intersection check here and when removed it didn't cause any regression too, rather it solves the issue and actually made sense too. In other Look and Feel its not required to apply the fix (in `BasicTableUI `class) because its not affecting anything yet since the painting happens for whole table. Hence proposing the fix for only SynthTableUI class. > ([PrintManualTest_FitWidthMultiple.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java)) test is been used for testing. I am also not able to reproduce the problem now with latest jdk without the fix and getting the same full output without any missing columns (same as damon is seeing). ------------- PR Comment: https://git.openjdk.org/jdk/pull/17053#issuecomment-1916044745 From psadhukhan at openjdk.org Tue Jan 30 04:33:43 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 30 Jan 2024 04:33:43 GMT Subject: RFR: 8259550: The content of the print out displayed incomplete with the NimbusLAF In-Reply-To: References: Message-ID: <9rQKIfIOKJV7BChmFI04OoO2NZDUUymATqUH-BGLvUQ=.65e5ba41-60a5-49c2-96fe-5b8639f4841b@github.com> On Mon, 11 Dec 2023 11:25:34 GMT, Tejesh R wrote: > The issue is w.r.t to way that Synth prints the table. In Synth, the printing of Table happens column wise by painting blocks of columns which is due to the fact that Graphics used which is `ProxyGrpahics2D` (which get selected in `RasterPrinterJob `class, otherwise it would be `WPathGraphics` for other Look and feel). Since the printing happens in block wise and the columns where the x position is greater than the `table.bounds` doesn't gets painted because of the intersection check condition `!bounds.intersects(clip)`. Hence only droplines are painted instead of cells and gridlines. I couldn't find any reason for adding the intersection check here and when removed it didn't cause any regression too, rather it solves the issue and actually made sense too. In other Look and Feel its not required to apply the fix (in `BasicTableUI `class) because its not affecting anything yet since the painting happens for whole table. Hence proposing the fix for only SynthTableUI class. > ([PrintManualTest_FitWidthMultiple.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java)) test is been used for testing. Please add this bugid to [PrintManualTest_FitWidthMultiple.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java) ------------- Marked as reviewed by psadhukhan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17053#pullrequestreview-1850208386 From psadhukhan at openjdk.org Tue Jan 30 04:38:42 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 30 Jan 2024 04:38:42 GMT Subject: RFR: 8307246 : Printing: banded raster path doesn't account for device offset values [v7] In-Reply-To: References: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com> Message-ID: <6lSf0r8L-nIkin7RgPv6rDapWvcWIx8T2c1Hf_jkPiA=.7ecd7db0-9051-4905-b680-4aecefd55ce8@github.com> On Mon, 29 Jan 2024 06:56:58 GMT, vtstydev wrote: >> More correct way to take in consideration nonzero PHYSICALOFFSETX, PHYSICALOFFSETY of device for banded-raster printing loop. Only on Windows platform under certain conditions real device prints shifted image on paper. > > vtstydev has updated the pull request incrementally with one additional commit since the last revision: > > Fix header and imports section in AlphaPrintingOffsets src/java.desktop/share/classes/sun/print/RasterPrinterJob.java line 2399: > 2397: */ > 2398: bandGraphics.setTransform(uniformTransform); > 2399: bandGraphics.translate(-deviceAddressableX,deviceAddressableY); a is needed between 2 arguments as per coding guidelines.. src/java.desktop/share/classes/sun/print/RasterPrinterJob.java line 2424: > 2422: int bandX = deviceLeft; > 2423: if (bandX < 0) { > 2424: bandGraphics.translate(bandX/xScale,0); Did we test this path where another translate is being done on the same object after it is done in l2399? test/jdk/java/awt/print/PrinterJob/ImagePrinting/AlphaPrintingOffsets.java line 73: > 71: System.out.println("Printer not configured or available." > 72: + " Test cannot continue."); > 73: PassFailJFrame.forcePass(); I guess it is now being preferred to throw jtreg.SkippedException instead of forcePass for printers not available scenarios?! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17030#discussion_r1470578878 PR Review Comment: https://git.openjdk.org/jdk/pull/17030#discussion_r1470578522 PR Review Comment: https://git.openjdk.org/jdk/pull/17030#discussion_r1470579615 From psadhukhan at openjdk.org Tue Jan 30 04:47:42 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 30 Jan 2024 04:47:42 GMT Subject: RFR: 8307246 : Printing: banded raster path doesn't account for device offset values [v7] In-Reply-To: References: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com> Message-ID: <8rmJPJExUnK5wib0jdQgOVisfvARmYKy79-kQ-7HUUo=.03c85ccd-1dba-4b80-b754-a3b12ce588a2@github.com> On Mon, 29 Jan 2024 06:56:58 GMT, vtstydev wrote: >> More correct way to take in consideration nonzero PHYSICALOFFSETX, PHYSICALOFFSETY of device for banded-raster printing loop. Only on Windows platform under certain conditions real device prints shifted image on paper. > > vtstydev has updated the pull request incrementally with one additional commit since the last revision: > > Fix header and imports section in AlphaPrintingOffsets > Only on Windows platform under certain conditions real device prints shifted image on paper. Also, if it affects only windows platform, will it not be more advisable to do in WPrinterJob class instead of RasterPrinterJob? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17030#issuecomment-1916066411 From tr at openjdk.org Tue Jan 30 04:54:05 2024 From: tr at openjdk.org (Tejesh R) Date: Tue, 30 Jan 2024 04:54:05 GMT Subject: RFR: 8259550: The content of the print out displayed incomplete with the NimbusLAF [v2] In-Reply-To: References: Message-ID: > The issue is w.r.t to way that Synth prints the table. In Synth, the printing of Table happens column wise by painting blocks of columns which is due to the fact that Graphics used which is `ProxyGrpahics2D` (which get selected in `RasterPrinterJob `class, otherwise it would be `WPathGraphics` for other Look and feel). Since the printing happens in block wise and the columns where the x position is greater than the `table.bounds` doesn't gets painted because of the intersection check condition `!bounds.intersects(clip)`. Hence only droplines are painted instead of cells and gridlines. I couldn't find any reason for adding the intersection check here and when removed it didn't cause any regression too, rather it solves the issue and actually made sense too. In other Look and Feel its not required to apply the fix (in `BasicTableUI `class) because its not affecting anything yet since the painting happens for whole table. Hence proposing the fix for only SynthTableUI class. > ([PrintManualTest_FitWidthMultiple.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java)) test is been used for testing. Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Test copywrite year and bug id updated - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8259550 - Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17053/files - new: https://git.openjdk.org/jdk/pull/17053/files/bb22d322..1b8324ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17053&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17053&range=00-01 Stats: 937125 lines in 8007 files changed: 258308 ins; 571395 del; 107422 mod Patch: https://git.openjdk.org/jdk/pull/17053.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17053/head:pull/17053 PR: https://git.openjdk.org/jdk/pull/17053 From psadhukhan at openjdk.org Tue Jan 30 05:53:44 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 30 Jan 2024 05:53:44 GMT Subject: RFR: 8259550: The content of the print out displayed incomplete with the NimbusLAF [v2] In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 04:54:05 GMT, Tejesh R wrote: >> The issue is w.r.t to way that Synth prints the table. In Synth, the printing of Table happens column wise by painting blocks of columns which is due to the fact that Graphics used which is `ProxyGrpahics2D` (which get selected in `RasterPrinterJob `class, otherwise it would be `WPathGraphics` for other Look and feel). Since the printing happens in block wise and the columns where the x position is greater than the `table.bounds` doesn't gets painted because of the intersection check condition `!bounds.intersects(clip)`. Hence only droplines are painted instead of cells and gridlines. I couldn't find any reason for adding the intersection check here and when removed it didn't cause any regression too, rather it solves the issue and actually made sense too. In other Look and Feel its not required to apply the fix (in `BasicTableUI `class) because its not affecting anything yet since the painting happens for whole table. Hence proposing the fix for only SynthTableUI class. >> ([PrintManualTest_FitWidthMultiple.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java)) test is been used for testing. > > Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Test copywrite year and bug id updated > - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8259550 > - Fix I guess it will be better to add additional testing to this test in view of this fix so that it doesn't go under the radar in future incase something change in Nimbus or in printing code.. * @run main/manual PrintManualTest_FitWidthMultiple + * @run main/othervm/manual -Dswing.defaultlaf=javax.swing.plaf.nimbus.NimbusLookAndFeel PrintManualTest_FitWidthMultipl ------------- PR Comment: https://git.openjdk.org/jdk/pull/17053#issuecomment-1916125597 From abhiscxk at openjdk.org Tue Jan 30 06:12:44 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 30 Jan 2024 06:12:44 GMT Subject: RFR: 8259550: The content of the print out displayed incomplete with the NimbusLAF [v2] In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 04:54:05 GMT, Tejesh R wrote: >> The issue is w.r.t to way that Synth prints the table. In Synth, the printing of Table happens column wise by painting blocks of columns which is due to the fact that Graphics used which is `ProxyGrpahics2D` (which get selected in `RasterPrinterJob `class, otherwise it would be `WPathGraphics` for other Look and feel). Since the printing happens in block wise and the columns where the x position is greater than the `table.bounds` doesn't gets painted because of the intersection check condition `!bounds.intersects(clip)`. Hence only droplines are painted instead of cells and gridlines. I couldn't find any reason for adding the intersection check here and when removed it didn't cause any regression too, rather it solves the issue and actually made sense too. In other Look and Feel its not required to apply the fix (in `BasicTableUI `class) because its not affecting anything yet since the painting happens for whole table. Hence proposing the fix for only SynthTableUI class. >> ([PrintManualTest_FitWidthMultiple.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java)) test is been used for testing. > > Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Test copywrite year and bug id updated > - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8259550 > - Fix Since you are updating the test file, you can check for the spacing as per coding standard. test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java line 23: > 21: * questions. > 22: */ > 23: /* Can add a blank line before this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17053#issuecomment-1916143633 PR Review Comment: https://git.openjdk.org/jdk/pull/17053#discussion_r1470634555 From rkannathpari at openjdk.org Tue Jan 30 06:30:00 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 30 Jan 2024 06:30:00 GMT Subject: RFR: 8320676 : Manual printer tests have no Pass/Fail buttons, instructions close [v2] In-Reply-To: References: Message-ID: > Hi Reviewers, > > Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured. > > Please review and let me know your suggestions. > > Regards, > Renjith Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Suggestions integrated ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17607/files - new: https://git.openjdk.org/jdk/pull/17607/files/64b68c79..bf42b41e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17607&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17607&range=00-01 Stats: 120 lines in 5 files changed: 4 ins; 46 del; 70 mod Patch: https://git.openjdk.org/jdk/pull/17607.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17607/head:pull/17607 PR: https://git.openjdk.org/jdk/pull/17607 From abhiscxk at openjdk.org Tue Jan 30 06:44:41 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 30 Jan 2024 06:44:41 GMT Subject: RFR: 8259550: The content of the print out displayed incomplete with the NimbusLAF In-Reply-To: <1NPZ_EyrnliJclG7mPKc54IhvD-IcajQCBi5s6Qarto=.ad720600-9866-46c6-b54a-d5cc1e426989@github.com> References: <1NPZ_EyrnliJclG7mPKc54IhvD-IcajQCBi5s6Qarto=.ad720600-9866-46c6-b54a-d5cc1e426989@github.com> Message-ID: <21yyOuwdiqE8IewEVmIVnI8jKZ9SVS2FdoW9DMkkUtg=.09f7f936-afe2-482d-a43b-cca3325b6130@github.com> On Wed, 17 Jan 2024 05:09:02 GMT, Tejesh R wrote: > Comparing it to the description/example you gave on the difference, I can't seem to recreate that change. These screenshots were generated by using the `Print` option on the test and outputting to a PDF file. Any insights for why I'm not seeing the same thing? I guess you are testing on Mac OS on which there is no difference in pdf files with or without fix. Able to reproduce on windows 11 and ubuntu 22.04 as mentioned. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17053#issuecomment-1916176002 From tr at openjdk.org Tue Jan 30 06:52:26 2024 From: tr at openjdk.org (Tejesh R) Date: Tue, 30 Jan 2024 06:52:26 GMT Subject: RFR: 8259550: The content of the print out displayed incomplete with the NimbusLAF In-Reply-To: <21yyOuwdiqE8IewEVmIVnI8jKZ9SVS2FdoW9DMkkUtg=.09f7f936-afe2-482d-a43b-cca3325b6130@github.com> References: <1NPZ_EyrnliJclG7mPKc54IhvD-IcajQCBi5s6Qarto=.ad720600-9866-46c6-b54a-d5cc1e426989@github.com> <21yyOuwdiqE8IewEVmIVnI8jKZ9SVS2FdoW9DMkkUtg=.09f7f936-afe2-482d-a43b-cca3325b6130@github.com> Message-ID: On Tue, 30 Jan 2024 06:42:01 GMT, Abhishek Kumar wrote: > > Comparing it to the description/example you gave on the difference, I can't seem to recreate that change. These screenshots were generated by using the `Print` option on the test and outputting to a PDF file. Any insights for why I'm not seeing the same thing? > > I guess you are testing on Mac OS on which there is no difference in pdf files with or without fix. Able to reproduce on windows 11 and ubuntu 22.04 as mentioned. @DamonGuy said he is not able to reproduce in Windows OS. Might be some settings related, not sure (As suggested in meeting might be of paper size A4). ------------- PR Comment: https://git.openjdk.org/jdk/pull/17053#issuecomment-1916183616 From rkannathpari at openjdk.org Tue Jan 30 07:02:36 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 30 Jan 2024 07:02:36 GMT Subject: RFR: 8324807 : Manual printer tests have no Pass/Fail buttons, instructions close set 2 [v2] In-Reply-To: References: Message-ID: <3dRlBPCn8DVfrzQdoOPGwruNAWi9xtrIP6MFRc7XrJI=.cf9a3846-ee6d-40e2-a8e1-f63107b47ca8@github.com> > Hi Reviewers, > > Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured. > > Please review and let me know your suggestions. > > Regards, > Renjith Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Capitalized static final variables ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17608/files - new: https://git.openjdk.org/jdk/pull/17608/files/5522649d..85cf485c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17608&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17608&range=00-01 Stats: 48 lines in 6 files changed: 2 ins; 18 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/17608.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17608/head:pull/17608 PR: https://git.openjdk.org/jdk/pull/17608 From rkannathpari at openjdk.org Tue Jan 30 07:05:31 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 30 Jan 2024 07:05:31 GMT Subject: RFR: 8320676 : Manual printer tests have no Pass/Fail buttons, instructions close [v2] In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 06:30:00 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> >> Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured. >> >> Please review and let me know your suggestions. >> >> Regards, >> Renjith > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Suggestions integrated @honkar-jdk Thank you for your review and valuable suggestions. I have updated the code ------------- PR Comment: https://git.openjdk.org/jdk/pull/17607#issuecomment-1916197020 From tr at openjdk.org Tue Jan 30 07:28:43 2024 From: tr at openjdk.org (Tejesh R) Date: Tue, 30 Jan 2024 07:28:43 GMT Subject: RFR: 8259550: The content of the print out displayed incomplete with the NimbusLAF [v3] In-Reply-To: References: Message-ID: > The issue is w.r.t to way that Synth prints the table. In Synth, the printing of Table happens column wise by painting blocks of columns which is due to the fact that Graphics used which is `ProxyGrpahics2D` (which get selected in `RasterPrinterJob `class, otherwise it would be `WPathGraphics` for other Look and feel). Since the printing happens in block wise and the columns where the x position is greater than the `table.bounds` doesn't gets painted because of the intersection check condition `!bounds.intersects(clip)`. Hence only droplines are painted instead of cells and gridlines. I couldn't find any reason for adding the intersection check here and when removed it didn't cause any regression too, rather it solves the issue and actually made sense too. In other Look and Feel its not required to apply the fix (in `BasicTableUI `class) because its not affecting anything yet since the painting happens for whole table. Hence proposing the fix for only SynthTableUI class. > ([PrintManualTest_FitWidthMultiple.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java)) test is been used for testing. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Test file updated w.r.t indentations and line spacing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17053/files - new: https://git.openjdk.org/jdk/pull/17053/files/1b8324ef..628f657c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17053&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17053&range=01-02 Stats: 27 lines in 1 file changed: 8 ins; 0 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/17053.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17053/head:pull/17053 PR: https://git.openjdk.org/jdk/pull/17053 From rkannathpari at openjdk.org Tue Jan 30 08:00:32 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 30 Jan 2024 08:00:32 GMT Subject: RFR: 8320676 : Manual printer tests have no Pass/Fail buttons, instructions close [v2] In-Reply-To: References: Message-ID: <9COHj3H4UD50eCr3kefzsCJZ2KNKhuynf9RQpv496yE=.e1ba80e0-1396-4af7-a26e-c0af9ab16e40@github.com> On Tue, 30 Jan 2024 00:14:05 GMT, Harshitha Onkar wrote: >> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: >> >> Suggestions integrated > > test/jdk/java/awt/print/PrinterJob/ValidatePage/ValidatePage.java line 263: > >> 261: ta.setEditable(false); >> 262: add(ta); >> 263: setSize(500, 650); > > Set paper and Print options are not visible with current frame size. > > Suggestion: > > setSize(680, 500); Updating the size impacting layouts, its visible in my system. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17607#discussion_r1470729593 From rkannathpari at openjdk.org Tue Jan 30 09:17:46 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 30 Jan 2024 09:17:46 GMT Subject: RFR: 8324808 : Manual printer tests have no Pass/Fail buttons, instructions close set 3 [v2] In-Reply-To: References: Message-ID: > Hi Reviewers, > > Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured. > > Please review and let me know your suggestions. > > Regards, > Renjith Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Capitalized static final variables ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17609/files - new: https://git.openjdk.org/jdk/pull/17609/files/1785a63a..8f6e94c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17609&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17609&range=00-01 Stats: 31 lines in 6 files changed: 0 ins; 12 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/17609.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17609/head:pull/17609 PR: https://git.openjdk.org/jdk/pull/17609 From tr at openjdk.org Tue Jan 30 09:28:58 2024 From: tr at openjdk.org (Tejesh R) Date: Tue, 30 Jan 2024 09:28:58 GMT Subject: RFR: 8259550: The content of the print out displayed incomplete with the NimbusLAF [v4] In-Reply-To: References: Message-ID: > The issue is w.r.t to way that Synth prints the table. In Synth, the printing of Table happens column wise by painting blocks of columns which is due to the fact that Graphics used which is `ProxyGrpahics2D` (which get selected in `RasterPrinterJob `class, otherwise it would be `WPathGraphics` for other Look and feel). Since the printing happens in block wise and the columns where the x position is greater than the `table.bounds` doesn't gets painted because of the intersection check condition `!bounds.intersects(clip)`. Hence only droplines are painted instead of cells and gridlines. I couldn't find any reason for adding the intersection check here and when removed it didn't cause any regression too, rather it solves the issue and actually made sense too. In other Look and Feel its not required to apply the fix (in `BasicTableUI `class) because its not affecting anything yet since the painting happens for whole table. Hence proposing the fix for only SynthTableUI class. > ([PrintManualTest_FitWidthMultiple.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java)) test is been used for testing. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Typo correction ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17053/files - new: https://git.openjdk.org/jdk/pull/17053/files/628f657c..e8161035 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17053&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17053&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17053.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17053/head:pull/17053 PR: https://git.openjdk.org/jdk/pull/17053 From abhiscxk at openjdk.org Tue Jan 30 09:28:59 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 30 Jan 2024 09:28:59 GMT Subject: RFR: 8259550: The content of the print out displayed incomplete with the NimbusLAF [v3] In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 07:28:43 GMT, Tejesh R wrote: >> The issue is w.r.t to way that Synth prints the table. In Synth, the printing of Table happens column wise by painting blocks of columns which is due to the fact that Graphics used which is `ProxyGrpahics2D` (which get selected in `RasterPrinterJob `class, otherwise it would be `WPathGraphics` for other Look and feel). Since the printing happens in block wise and the columns where the x position is greater than the `table.bounds` doesn't gets painted because of the intersection check condition `!bounds.intersects(clip)`. Hence only droplines are painted instead of cells and gridlines. I couldn't find any reason for adding the intersection check here and when removed it didn't cause any regression too, rather it solves the issue and actually made sense too. In other Look and Feel its not required to apply the fix (in `BasicTableUI `class) because its not affecting anything yet since the painting happens for whole table. Hence proposing the fix for only SynthTableUI class. >> ([PrintManualTest_FitWidthMultiple.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java)) test is been used for testing. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Test file updated w.r.t indentations and line spacing Minor comments else test is verified on windows and linux platform. test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java line 30: > 28: * printed for PrintMode.FIT_WIDTH > 29: * @run main/othervm/manual -Dswing.defaultlaf=javax.swing.plaf.nimbus.NimbusLookAndFeel PrintManualTest_FitWidthMultiple > 30: Merg Looks like some typo mistake. test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java line 148: > 146: JPanel btnpanel = new JPanel(); > 147: btnpanel.add(printButton); > 148: fr.getContentPane().add(btnpanel,BorderLayout.SOUTH); Suggestion: fr.getContentPane().add(btnpanel, BorderLayout.SOUTH); May be you can fix this here and other places as well. space after `,`. ------------- Marked as reviewed by abhiscxk (Committer). PR Review: https://git.openjdk.org/jdk/pull/17053#pullrequestreview-1850616137 PR Review Comment: https://git.openjdk.org/jdk/pull/17053#discussion_r1470834957 PR Review Comment: https://git.openjdk.org/jdk/pull/17053#discussion_r1470837624 From tr at openjdk.org Tue Jan 30 09:35:55 2024 From: tr at openjdk.org (Tejesh R) Date: Tue, 30 Jan 2024 09:35:55 GMT Subject: RFR: 8259550: The content of the print out displayed incomplete with the NimbusLAF [v5] In-Reply-To: References: Message-ID: > The issue is w.r.t to way that Synth prints the table. In Synth, the printing of Table happens column wise by painting blocks of columns which is due to the fact that Graphics used which is `ProxyGrpahics2D` (which get selected in `RasterPrinterJob `class, otherwise it would be `WPathGraphics` for other Look and feel). Since the printing happens in block wise and the columns where the x position is greater than the `table.bounds` doesn't gets painted because of the intersection check condition `!bounds.intersects(clip)`. Hence only droplines are painted instead of cells and gridlines. I couldn't find any reason for adding the intersection check here and when removed it didn't cause any regression too, rather it solves the issue and actually made sense too. In other Look and Feel its not required to apply the fix (in `BasicTableUI `class) because its not affecting anything yet since the painting happens for whole table. Hence proposing the fix for only SynthTableUI class. > ([PrintManualTest_FitWidthMultiple.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java)) test is been used for testing. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Test file updated ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17053/files - new: https://git.openjdk.org/jdk/pull/17053/files/e8161035..835ffaaa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17053&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17053&range=03-04 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/17053.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17053/head:pull/17053 PR: https://git.openjdk.org/jdk/pull/17053 From tr at openjdk.org Tue Jan 30 09:54:40 2024 From: tr at openjdk.org (Tejesh R) Date: Tue, 30 Jan 2024 09:54:40 GMT Subject: RFR: 8324807 : Manual printer tests have no Pass/Fail buttons, instructions close set 2 [v2] In-Reply-To: <3dRlBPCn8DVfrzQdoOPGwruNAWi9xtrIP6MFRc7XrJI=.cf9a3846-ee6d-40e2-a8e1-f63107b47ca8@github.com> References: <3dRlBPCn8DVfrzQdoOPGwruNAWi9xtrIP6MFRc7XrJI=.cf9a3846-ee6d-40e2-a8e1-f63107b47ca8@github.com> Message-ID: On Tue, 30 Jan 2024 07:02:36 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> >> Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured. >> >> Please review and let me know your suggestions. >> >> Regards, >> Renjith > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Capitalized static final variables Looks good to me. ------------- Marked as reviewed by tr (Committer). PR Review: https://git.openjdk.org/jdk/pull/17608#pullrequestreview-1850707501 From psadhukhan at openjdk.org Tue Jan 30 10:01:42 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 30 Jan 2024 10:01:42 GMT Subject: RFR: 8259550: The content of the print out displayed incomplete with the NimbusLAF [v5] In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 09:35:55 GMT, Tejesh R wrote: >> The issue is w.r.t to way that Synth prints the table. In Synth, the printing of Table happens column wise by painting blocks of columns which is due to the fact that Graphics used which is `ProxyGrpahics2D` (which get selected in `RasterPrinterJob `class, otherwise it would be `WPathGraphics` for other Look and feel). Since the printing happens in block wise and the columns where the x position is greater than the `table.bounds` doesn't gets painted because of the intersection check condition `!bounds.intersects(clip)`. Hence only droplines are painted instead of cells and gridlines. I couldn't find any reason for adding the intersection check here and when removed it didn't cause any regression too, rather it solves the issue and actually made sense too. In other Look and Feel its not required to apply the fix (in `BasicTableUI `class) because its not affecting anything yet since the painting happens for whole table. Hence proposing the fix for only SynthTableUI class. >> ([PrintManualTest_FitWidthMultiple.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java)) test is been used for testing. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Test file updated test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java line 29: > 27: * @summary Verify if printed content is within border and all columns are > 28: * printed for PrintMode.FIT_WIDTH > 29: * @run main/othervm/manual -Dswing.defaultlaf=javax.swing.plaf.nimbus.NimbusLookAndFeel PrintManualTest_FitWidthMultiple You need to keep both not only Nimbus ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17053#discussion_r1470912862 From tr at openjdk.org Tue Jan 30 10:11:44 2024 From: tr at openjdk.org (Tejesh R) Date: Tue, 30 Jan 2024 10:11:44 GMT Subject: RFR: 8259550: The content of the print out displayed incomplete with the NimbusLAF [v5] In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 09:58:33 GMT, Prasanta Sadhukhan wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Test file updated > > test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java line 29: > >> 27: * @summary Verify if printed content is within border and all columns are >> 28: * printed for PrintMode.FIT_WIDTH >> 29: * @run main/othervm/manual -Dswing.defaultlaf=javax.swing.plaf.nimbus.NimbusLookAndFeel PrintManualTest_FitWidthMultiple > > You need to keep both not only Nimbus Meaning with default and Nimbus L&F? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17053#discussion_r1470935607 From psadhukhan at openjdk.org Tue Jan 30 10:11:44 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 30 Jan 2024 10:11:44 GMT Subject: RFR: 8259550: The content of the print out displayed incomplete with the NimbusLAF [v5] In-Reply-To: References: Message-ID: <8xF-ODqPQdhZCUwXpxb_2pnxD-gfP68MIYAb5cD2WOc=.bdde9163-f6c9-4702-b823-1fd157e72ded@github.com> On Tue, 30 Jan 2024 10:08:51 GMT, Tejesh R wrote: >> test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java line 29: >> >>> 27: * @summary Verify if printed content is within border and all columns are >>> 28: * printed for PrintMode.FIT_WIDTH >>> 29: * @run main/othervm/manual -Dswing.defaultlaf=javax.swing.plaf.nimbus.NimbusLookAndFeel PrintManualTest_FitWidthMultiple >> >> You need to keep both not only Nimbus > > Meaning with default and Nimbus L&F? yes ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17053#discussion_r1470936844 From aivanov at openjdk.org Tue Jan 30 10:40:42 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 30 Jan 2024 10:40:42 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI [v3] In-Reply-To: References: <1xfZ5RyTcjtAZ87SQYOMdNYYRnc76Fxr0m05vbktyZQ=.4e4e71a5-351f-4654-90e6-c21e2a199894@github.com> Message-ID: On Mon, 29 Jan 2024 06:16:04 GMT, Prasanta Sadhukhan wrote: >> test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 62: >> >>> 60: } >>> 61: >>> 62: public void finalize( ) { >> >> The `finalize` method is deprecated. Can't we use `Reference` API for this purpose? >> >> Store a list of [`PhantomReference`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/ref/PhantomReference.html). The size of the list is the number of `JLabel` objects created. Once you receive a reference via the [`ReferenceQueue`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/ref/ReferenceQueue.html), remove it from the list. > > I was not sure of the nuances of PhantomReference and ReferenceQueue, so have used WeakReference logic in the test which I think is more simpler.. It's simpler with `PhantomReference`. This type of reference does not allow getting its referent, and it's not needed in this case. When the referent of a reference is cleared by the GC, the reference is added into the associated reference queue. This is true for any type of `Reference`, but `PhantomReference` has to use a reference queue. Here's how to use them: https://github.com/aivanov-jdk/jdk/commit/b0da8b30fdcf03abffa663eb5ba42df1fe4a9971 I keep the references in a list. The size of the list is the number of live `JLabel` objects. On each iteration, I poll the reference queue and remove the _dead_ references from the list. https://github.com/openjdk/jdk/blob/b0da8b30fdcf03abffa663eb5ba42df1fe4a9971/test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java#L193-L201 If the number of removed references is zero, the test fails because objects are leaked. Otherwise, the test passes. This aligns with your latest changes. Your code also does the job. I'd approve it if you don't want to use `PhantomReference`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1470982713 From tr at openjdk.org Tue Jan 30 11:41:44 2024 From: tr at openjdk.org (Tejesh R) Date: Tue, 30 Jan 2024 11:41:44 GMT Subject: RFR: 8259550: The content of the print out displayed incomplete with the NimbusLAF [v6] In-Reply-To: References: Message-ID: <_1NWDKGJYR92i0e0fJ3pMuAf1zehGLlX1dd_kZxQpqM=.1e9ac5ad-8a1e-4d70-b485-0d9da9f0da85@github.com> > The issue is w.r.t to way that Synth prints the table. In Synth, the printing of Table happens column wise by painting blocks of columns which is due to the fact that Graphics used which is `ProxyGrpahics2D` (which get selected in `RasterPrinterJob `class, otherwise it would be `WPathGraphics` for other Look and feel). Since the printing happens in block wise and the columns where the x position is greater than the `table.bounds` doesn't gets painted because of the intersection check condition `!bounds.intersects(clip)`. Hence only droplines are painted instead of cells and gridlines. I couldn't find any reason for adding the intersection check here and when removed it didn't cause any regression too, rather it solves the issue and actually made sense too. In other Look and Feel its not required to apply the fix (in `BasicTableUI `class) because its not affecting anything yet since the painting happens for whole table. Hence proposing the fix for only SynthTableUI class. > ([PrintManualTest_FitWidthMultiple.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java)) test is been used for testing. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Test updated for default L&F ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17053/files - new: https://git.openjdk.org/jdk/pull/17053/files/835ffaaa..7219f597 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17053&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17053&range=04-05 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17053.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17053/head:pull/17053 PR: https://git.openjdk.org/jdk/pull/17053 From aivanov at openjdk.org Tue Jan 30 13:17:42 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 30 Jan 2024 13:17:42 GMT Subject: RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations [v3] In-Reply-To: References: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> Message-ID: <3xvCOTZxAghqFhnhAHQXsqeBwbphdDtN73_KawaiOx8=.72d5561d-7663-4142-98cf-caaf77eb44c9@github.com> On Mon, 29 Jan 2024 21:29:53 GMT, Phil Race wrote: >> Christoph Langer 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: >> >> - Move Exception Check to the right place >> - Merge branch 'master' into JDK-8323664 >> - Changes to assertion function and test as discussed >> - Revert "JDK-8323664" >> >> This reverts commit 32128744252d75104e0d19f5eb701ffdc7b3d417. >> - Merge branch 'master' into JDK-8323664 >> - JDK-8323664 > > src/java.desktop/windows/native/libawt/windows/awt_Debug.cpp line 160: > >> 158: env->ExceptionCheck(); >> 159: jclass graphicsEnvClass = env->FindClass("java/awt/GraphicsEnvironment"); >> 160: > > FindClass may also throw an Exception, (see https://docs.oracle.com/en/java/javase/21/docs/specs/jni/functions.html#findclass) > and in fact so can GetStaticMethodID. > > So now I'm wondering why these don't also get complained about .. In fact, any method can throw an exception? Is there a guide which clearly states where `ExceptionCheck` is required? The function returns a boolean indicating whether there's a pending exception. Shall we back out if there is? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17404#discussion_r1471187806 From tr at openjdk.org Tue Jan 30 13:47:05 2024 From: tr at openjdk.org (Tejesh R) Date: Tue, 30 Jan 2024 13:47:05 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException [v3] In-Reply-To: References: Message-ID: > Suggested fix [JDK-8307091](https://bugs.openjdk.org/browse/JDK-8307091) also created concurrent exception intermittently (monthly once/quarterly once) on CI system. The issue was not able to be reproduced yet, hence proposing an alternative fix which uses iterators to compare the List. > CI testing shows green. Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Review updates - Indentatioins and unused imports - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8323670 - Revert fix 8307091 + Synchronised filecache - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8323670 - Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17462/files - new: https://git.openjdk.org/jdk/pull/17462/files/9cf570fb..2aebfbce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17462&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17462&range=01-02 Stats: 14303 lines in 1142 files changed: 3524 ins; 1184 del; 9595 mod Patch: https://git.openjdk.org/jdk/pull/17462.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17462/head:pull/17462 PR: https://git.openjdk.org/jdk/pull/17462 From aivanov at openjdk.org Tue Jan 30 13:47:42 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 30 Jan 2024 13:47:42 GMT Subject: RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations [v3] In-Reply-To: <3xvCOTZxAghqFhnhAHQXsqeBwbphdDtN73_KawaiOx8=.72d5561d-7663-4142-98cf-caaf77eb44c9@github.com> References: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> <3xvCOTZxAghqFhnhAHQXsqeBwbphdDtN73_KawaiOx8=.72d5561d-7663-4142-98cf-caaf77eb44c9@github.com> Message-ID: On Tue, 30 Jan 2024 13:15:14 GMT, Alexey Ivanov wrote: > Is there a guide which clearly states where `ExceptionCheck` is required? I should've looked it up. [Java Native Interface Specification](https://docs.oracle.com/en/java/javase/21/docs/specs/jni/index.html), section on [handling Java Exception](https://docs.oracle.com/en/java/javase/21/docs/specs/jni/design.html#java-exceptions) says:

Certain JNI functions use the Java exception mechanism to report error conditions. In most cases, JNI functions report error conditions by returning an error code and throwing a Java exception. The error code is usually a special return value (such as NULL) that is outside of the range of normal return values. Therefore, the programmer can: * quickly check the return value of the last JNI call to determine if an error has occurred, and * call a function, `ExceptionOccurred()`, to obtain the exception object that contains a more detailed description of the error condition. There are two cases where the programmer needs to check for exceptions without being able to first check an error code: * The JNI functions that invoke a Java method return the result of the Java method. The programmer must call `ExceptionOccurred()` to check for possible exceptions that occurred during the execution of the Java method. * Some of the JNI array access functions do not return an error code, but may throw an `ArrayIndexOutOfBoundsException` or `ArrayStoreException`. In all other cases, a non-error return value guarantees that no exceptions have been thrown.
Thus, `FindClass` returns non-null value if no error occurred; if the returned value is null, an error occurred, and `FindClass` raised an exception on the Java side. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17404#discussion_r1471241316 From tr at openjdk.org Tue Jan 30 13:55:44 2024 From: tr at openjdk.org (Tejesh R) Date: Tue, 30 Jan 2024 13:55:44 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException [v2] In-Reply-To: References: Message-ID: <_0NhAu8sRpUoEH4vAuXpU0JY6f1T2J0_GNoPPFcKR4Y=.cc6e3b77-3ad9-4050-aa02-9a9bf3eba90a@github.com> On Mon, 29 Jan 2024 19:50:51 GMT, Alexey Ivanov wrote: >> Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Revert fix 8307091 + Synchronised filecache >> - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8323670 >> - Fix > > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java line 344: > >> 342: // execute the whole block on the COM thread >> 343: runnable = ShellFolder.invoke(new Callable() { >> 344: public DoChangeContents call() { > > To reduce indentation level, you may convert the anonymous class to a lambda expression or even to a method in `FilesLoader` in which case you could use method reference. Since I have updated the indentations now, I'll leave it that way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1471256172 From aivanov at openjdk.org Tue Jan 30 14:06:41 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 30 Jan 2024 14:06:41 GMT Subject: RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations [v3] In-Reply-To: References: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> Message-ID: On Mon, 29 Jan 2024 07:13:49 GMT, Christoph Langer wrote: >> This picks up fixing the issue of [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) again. A fix had been integrated with #17224 but @prrace had concerns and so it was backed out. >> >> I have now spent quite some thoughts into the problem and end up with the [initial commit](https://github.com/openjdk/jdk/pull/6306/commits/5d18a76cb967e9ede6394cbd6c28bb61facf785c) of #6306 as the most elegant and least intrusive solution. >> >> Why is this? >> >> The JNI warning we observe in the test is: >> `[WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV >> at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 22.0.1-internal/Native Method) >> at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:95) >> at sun.awt.Win32GraphicsEnvironment.(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:63) >> ... >> at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) >> at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)` >> >> This happens because obviously the test FreeTypeScalerJNICheck runs with `-Xcheck:jni` and in the scenario where we're observing the warning, a missing exception check for the JNI call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged` at awt_Win32GraphicsEnv.cpp#L129 >> https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L129 is airing up. Omitting the exception check would not be a problem if it could be guaranteed that after this call no other JNI->Java call was being made. But seemingly in this very particular configuration on some of our Windows servers, there must be JNI->Java calls that follow the call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged`, likely from the subsequent call to [initScreens](https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L149) in `sun.awt.Win32GraphicsEnvironment::initDisplay`. https://github.com/openjdk/jdk/blob/8b6293f6bfb7b7628c6604e6c44401fc96d85cf4/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L141 Maybe the usual control flow would call the wrapping native method `DWMIsComposit ionEnabled()` from somewhere else initially such that the initialization of `Win32GraphicsEnvironment` would not go ... > > Christoph Langer 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: > > - Move Exception Check to the right place > - Merge branch 'master' into JDK-8323664 > - Changes to assertion function and test as discussed > - Revert "JDK-8323664" > > This reverts commit 32128744252d75104e0d19f5eb701ffdc7b3d417. > - Merge branch 'master' into JDK-8323664 > - JDK-8323664 Now that I re-read the problem statement and the exception handling JNI, the fix doesn't look correct to me. What does the warning say? > WARNING in native method: JNI call made without checking exceptions when required to from `CallStaticVoidMethodV` at `sun.awt.Win32GraphicsEnvironment.initDisplay` To me, it means that `Win32GraphicsEnvironment.initDisplay` is the problem. You found that `DWMIsCompositionEnabled` calls a static method via `JNU_CallStaticMethodByName`. As far as I can see, it's the last statement of the `DWMIsCompositionEnabled` function. Then `Java_sun_awt_Win32GraphicsEnvironment_initDisplay` calls `initScreens` which, seemingly, can call other JNI methods. Wouldn't it be better to check if an exception occurred after `DWMIsCompositionEnabled` and bail out if it did? SetProcessDPIAwareProperty(); DWMIsCompositionEnabled(); if (env->ExceptionCheck()) { return; } initScreens(env); ------------- PR Comment: https://git.openjdk.org/jdk/pull/17404#issuecomment-1916930806 From aivanov at openjdk.org Tue Jan 30 14:15:43 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 30 Jan 2024 14:15:43 GMT Subject: RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations [v3] In-Reply-To: References: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> Message-ID: On Mon, 29 Jan 2024 07:13:49 GMT, Christoph Langer wrote: >> This picks up fixing the issue of [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) again. A fix had been integrated with #17224 but @prrace had concerns and so it was backed out. >> >> I have now spent quite some thoughts into the problem and end up with the [initial commit](https://github.com/openjdk/jdk/pull/6306/commits/5d18a76cb967e9ede6394cbd6c28bb61facf785c) of #6306 as the most elegant and least intrusive solution. >> >> Why is this? >> >> The JNI warning we observe in the test is: >> `[WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV >> at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 22.0.1-internal/Native Method) >> at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:95) >> at sun.awt.Win32GraphicsEnvironment.(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:63) >> ... >> at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) >> at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)` >> >> This happens because obviously the test FreeTypeScalerJNICheck runs with `-Xcheck:jni` and in the scenario where we're observing the warning, a missing exception check for the JNI call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged` at awt_Win32GraphicsEnv.cpp#L129 >> https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L129 is airing up. Omitting the exception check would not be a problem if it could be guaranteed that after this call no other JNI->Java call was being made. But seemingly in this very particular configuration on some of our Windows servers, there must be JNI->Java calls that follow the call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged`, likely from the subsequent call to [initScreens](https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L149) in `sun.awt.Win32GraphicsEnvironment::initDisplay`. https://github.com/openjdk/jdk/blob/8b6293f6bfb7b7628c6604e6c44401fc96d85cf4/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L141 Maybe the usual control flow would call the wrapping native method `DWMIsComposit ionEnabled()` from somewhere else initially such that the initialization of `Win32GraphicsEnvironment` would not go ... > > Christoph Langer 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: > > - Move Exception Check to the right place > - Merge branch 'master' into JDK-8323664 > - Changes to assertion function and test as discussed > - Revert "JDK-8323664" > > This reverts commit 32128744252d75104e0d19f5eb701ffdc7b3d417. > - Merge branch 'master' into JDK-8323664 > - JDK-8323664 src/java.desktop/windows/native/libawt/windows/awt_Debug.cpp line 158: > 156: // be on the safe side and avoid JNI warnings by calling ExceptionCheck > 157: // an accumulated exception is not cleared > 158: env->ExceptionCheck(); So, this doesn't actually do anything but avoids JNI warnings, does it? `AwtDebugSupport::AssertCallback` can be called *at any time*, hence calling JNI functions here is unsafe. Adding `env->ExceptionCheck()` doesn't change anything. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17404#discussion_r1471297169 From aivanov at openjdk.org Tue Jan 30 14:25:43 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 30 Jan 2024 14:25:43 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException [v3] In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 13:47:05 GMT, Tejesh R wrote: >> Suggested fix [JDK-8307091](https://bugs.openjdk.org/browse/JDK-8307091) also created concurrent exception intermittently (monthly once/quarterly once) on CI system. The issue was not able to be reproduced yet, hence proposing an alternative fix which uses iterators to compare the List. >> CI testing shows green. > > Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Review updates - Indentatioins and unused imports > - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8323670 > - Revert fix 8307091 + Synchronised filecache > - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8323670 > - Fix Looks good to me. I cannot get `ConcurrentModificationException` when running my test, `BasicDirectoryModelConcurrency.java`, on a build with the fix. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17462#pullrequestreview-1851418580 From aivanov at openjdk.org Tue Jan 30 16:16:56 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 30 Jan 2024 16:16:56 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException [v3] In-Reply-To: References: <2QdFzdTMRaDSB2icdnkWhvjPId7_Ua2Ss4FdR4vnSPU=.d91a11c8-254b-4a1f-ba89-5e29adcb036b@github.com> <_eM6PSqBeIcRlegDs2Xlzfzkc2uYNNsdH4BbzpW4uwE=.602319fe-8f7d-4f13-9203-12e8d5801ca8@github.com> Message-ID: <0J-_bbHw0aMKaTLIIQvVhjqkTvN74S3hKi8_9GsnNS4=.33b83020-baa2-4a08-ae1f-3fdfb3454def@github.com> On Thu, 25 Jan 2024 09:56:08 GMT, Alexey Ivanov wrote: > > > ?I'm for replacing `Vector` with `ArrayList` for the `newFileCache` and `newFiles` variables. These are local variables, they're not accessed concurrently. Yet they're accessed from two threads: the current one and the one where `ShellFolder.invoke` runs, so there could be a need to use another synchronisation technique to ensure thread-safety between these two threads. > > > > > > Another Synchronization technique even after `synchronized (fileCache)`? > > Yes, even after. No, it's not needed, actually. `ShellFolder.invoke` executes the code directly on the same thread or passes it to COM thread on Windows. When it's passed to the COM thread, a `Future` object is used, which ensures synchronisation. I submitted [JDK-8324973](https://bugs.openjdk.org/browse/JDK-8324973): _Replace Vector with ArrayList in BasicDirectoryModel.FilesLoader_. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17462#discussion_r1471379466 From aivanov at openjdk.org Tue Jan 30 16:17:07 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 30 Jan 2024 16:17:07 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI [v4] In-Reply-To: References: Message-ID: <8qGWOGVTHhrIiUdLjoGPyeHqMxAGakea8cp8FPBN0W0=.16909f0a-354a-4be0-ae62-02df0b9902ff@github.com> On Mon, 29 Jan 2024 06:18:50 GMT, Prasanta Sadhukhan wrote: >> When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak. >> When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. >> Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500) >> >> FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Use removeAll and testcase modified Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java line 1: > 1: /* Update the copyright year in `BasicTreeUI`. test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 51: > 49: public class TreeCellRendererLeakTest { > 50: > 51: static int smCount = 0; What does `sm-` prefix mean? test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 60: > 58: private JTree jTree1; > 59: > 60: static CountDownLatch testDone; Suggestion: static final CountDownLatch testDone = new CountDownLatch(1); test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 62: > 60: static CountDownLatch testDone; > 61: > 62: ArrayList> weakRefArrLabel = new ArrayList(50); Suggestion: final List> weakRefArrLabel = new ArrayList<>(50); The type could be `List`. Use the diamond operator on the right side. I suggest a simpler name: `labelList`, `labelRefList`, _`weakRefList`_. test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 86: > 84: } > 85: > 86: weakRefArrLabel.add(smCount++, new WeakReference(label)); Suggestion: synchronized (weakRefArrLabel) { weakRefArrLabel.add(new WeakReference(label)); } You have to add items in a synchronized block; you read from the list in another thread. (Reading has be done inside a synchronized block too.) Just add to the end of the list. test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 136: > 134: testDone = new CountDownLatch(1); > 135: SwingUtilities.invokeAndWait(() -> { > 136: TreeCellRendererLeakTest tf = new TreeCellRendererLeakTest(); Suggestion: new TreeCellRendererLeakTest(); The variable is unused and can safely be removed. The side effects of calling the constructor won't disappear. test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 164: > 162: model.nodeChanged(n); > 163: } > 164: }); The anonymous class can be a lambda expression. The code inside the `Runnable` can be reduced to n.setUserObject("runcount " + currentCount); model.nodeChanged(n); This implies, you make `n` a field and initialise it in `initComponents`; or after calling `initComponents`. test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 181: > 179: public void runInfo() { > 180: long time = System.currentTimeMillis(); > 181: long initialCnt = smCount; `initialCnt` is unused in the current version. test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 184: > 182: while ((System.currentTimeMillis() - time) < (15 * 1000)) { > 183: System.gc(); > 184: System.out.println("Live JLabels:" + smCount); Access to `smCount` has to be synchronized between the two threads. test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 204: > 202: count++; > 203: } > 204: } You have to iterate over `weakRefArrLabel` in a synchronized block. (No, declaring `weakRefArrLabel` as `volatile` is not enough.) Suggestion: synchronized (weakRefArrLabel) { for (WeakReference ref : weakRefArrLabel) { if (ref.get() == null) { count++; } } } ------------- PR Review: https://git.openjdk.org/jdk/pull/17458#pullrequestreview-1851588145 PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1471471871 PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1471467202 PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1471426426 PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1471432033 PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1471436951 PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1471438887 PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1471446967 PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1471468908 PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1471470295 PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1471458749 From aivanov at openjdk.org Tue Jan 30 16:17:09 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 30 Jan 2024 16:17:09 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI [v4] In-Reply-To: <8qGWOGVTHhrIiUdLjoGPyeHqMxAGakea8cp8FPBN0W0=.16909f0a-354a-4be0-ae62-02df0b9902ff@github.com> References: <8qGWOGVTHhrIiUdLjoGPyeHqMxAGakea8cp8FPBN0W0=.16909f0a-354a-4be0-ae62-02df0b9902ff@github.com> Message-ID: On Tue, 30 Jan 2024 15:35:54 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Use removeAll and testcase modified > > test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 204: > >> 202: count++; >> 203: } >> 204: } > > You have to iterate over `weakRefArrLabel` in a synchronized block. (No, declaring `weakRefArrLabel` as `volatile` is not enough.) > Suggestion: > > synchronized (weakRefArrLabel) { > for (WeakReference ref : weakRefArrLabel) { > if (ref.get() == null) { > count++; > } > } > } Alternatively, you can use Stream API: private long getCleanedUpLabelCount() { synchronized (weakRefArrLabel) { return weakRefArrLabel.stream() .filter(r -> r.get() != null) .count(); } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1471461777 From aivanov at openjdk.org Tue Jan 30 16:33:53 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 30 Jan 2024 16:33:53 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException [v3] In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 13:47:05 GMT, Tejesh R wrote: >> Suggested fix [JDK-8307091](https://bugs.openjdk.org/browse/JDK-8307091) also created concurrent exception intermittently (monthly once/quarterly once) on CI system. The issue was not able to be reproduced yet, hence proposing an alternative fix which uses iterators to compare the List. >> CI testing shows green. > > Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Review updates - Indentatioins and unused imports > - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8323670 > - Revert fix 8307091 + Synchronised filecache > - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8323670 > - Fix I forgot to add a direct link to the test: [`BasicDirectoryModelConcurrency.java`](https://github.com/aivanov-jdk/jdk/blob/7cdf8c3610898557e91190d2bae440829a663376/test/jdk/javax/swing/JFileChooser/FileSystemView/BasicDirectoryModelConcurrency.java) > @mrserb I've been trying to write a regression test for this problem. Have I succeeded? Not quite? I am unable to get `ConcurrentModificationException` on any platform when I run the test locally. I reproduced the issue a few times on macOS and once on Linux, on a local host rather than in CI. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17462#issuecomment-1917430560 From rmahajan at openjdk.org Tue Jan 30 22:19:22 2024 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Tue, 30 Jan 2024 22:19:22 GMT Subject: RFR: 8320342: Use PassFailJFrame for TruncatedPopupMenuTest.java Message-ID: Modified the test to use PassFailJFrame and moved it from closed to open. The test shows two windows, one for instructions and the other to perform testing on. Tested locally and it works fine. ------------- Commit messages: - 8320342: Use PassFailJFrame for TruncatedPopupMenuTest.java Changes: https://git.openjdk.org/jdk/pull/17641/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17641&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320342 Stats: 93 lines in 1 file changed: 93 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17641.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17641/head:pull/17641 PR: https://git.openjdk.org/jdk/pull/17641 From honkar at openjdk.org Tue Jan 30 23:19:10 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 30 Jan 2024 23:19:10 GMT Subject: RFR: 8320342: Use PassFailJFrame for TruncatedPopupMenuTest.java In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 21:49:12 GMT, Rajat Mahajan wrote: > Modified the test to use PassFailJFrame and open sourced it. > The test shows two windows, one for instructions and the other to perform testing on. > Tested locally and it works fine. Marked as reviewed by honkar (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17641#pullrequestreview-1852580879 From honkar at openjdk.org Wed Jan 31 01:08:13 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 31 Jan 2024 01:08:13 GMT Subject: RFR: JDK-8324238 : [macOS] java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails with the shape has not been applied msg [v2] In-Reply-To: <2X4lZKPcvcBCgjNBbezJGso48upOQIByUORAeXTOQuQ=.c7cf91b4-1b6b-4d31-95d7-04b2634f8eed@github.com> References: <2X4lZKPcvcBCgjNBbezJGso48upOQIByUORAeXTOQuQ=.c7cf91b4-1b6b-4d31-95d7-04b2634f8eed@github.com> Message-ID: > ShapeNotSetSometimes.java fails on macOS 11 on a random iteration of `colorCheck()` as shown below. The `colorCheck()` is repeated for about 50 times in the test. It is observed to pass on previous attempts and fail on a random attempt such as Attempt# 29 shown here. > > Here the point (150, 20) is well in the green area hence the slight color diff picked up by `robot.getPixelColor()` is not due to sampling of color at the edge (which sometimes causes robot to pick up slightly different color). > > > Attempt 29 > Checking 150, 20, java.awt.Color[r=0,g=255,b=1] should be java.awt.Color[r=0,g=255,b=0] > > > Due to the above, I have kept the color sampling points at the same location as earlier and made the following changes to the test: > > - Moved the frame to the center of the screen. > - Instead of comparing exact RGB values, used `colorCompare()` which allows color tolerance of 2 per color component to accommodate slight variations when comparing actual vs expected colors. > > > > Attempt 27 > Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] > Checking 150, 20, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 280, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 150, 250, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 20, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 62, 62, java.awt.Color[r=0,g=243,b=0] should not be java.awt.Color[r=255,g=255,b=255] > Checking 240, 185, java.awt.Color[r=0,g=229,b=0] should not be java.awt.Color[r=255,g=255,b=255] > Attempt 28 > Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] > Checking 150, 20, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 280, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 150, 250, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 20, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 62, 62, java.awt.Color[r=0,g=241,b=0] should not be java.awt.Color[r=255,g=255,b=255] > Checking 240, 185, java.awt.Color[r=0,g=227,b=0] should not be java.awt.Color[r=255,g=255,b=255] > Attempt 29 > Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] > Checking 150, 20, java.awt.Color[r=0,g=255,b=1] should be java.awt.Color[r=0,g=255,b=0] > ----------System.er... Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: test update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17563/files - new: https://git.openjdk.org/jdk/pull/17563/files/4f062636..32333ce8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17563&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17563&range=00-01 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17563.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17563/head:pull/17563 PR: https://git.openjdk.org/jdk/pull/17563 From honkar at openjdk.org Wed Jan 31 01:11:02 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 31 Jan 2024 01:11:02 GMT Subject: RFR: JDK-8324238 : [macOS] java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails with the shape has not been applied msg [v2] In-Reply-To: References: <2X4lZKPcvcBCgjNBbezJGso48upOQIByUORAeXTOQuQ=.c7cf91b4-1b6b-4d31-95d7-04b2634f8eed@github.com> Message-ID: On Wed, 31 Jan 2024 01:08:13 GMT, Harshitha Onkar wrote: >> ShapeNotSetSometimes.java fails on macOS 11 on a random iteration of `colorCheck()` as shown below. The `colorCheck()` is repeated for about 50 times in the test. It is observed to pass on previous attempts and fail on a random attempt such as Attempt# 29 shown here. >> >> Here the point (150, 20) is well in the green area hence the slight color diff picked up by `robot.getPixelColor()` is not due to sampling of color at the edge (which sometimes causes robot to pick up slightly different color). >> >> >> Attempt 29 >> Checking 150, 20, java.awt.Color[r=0,g=255,b=1] should be java.awt.Color[r=0,g=255,b=0] >> >> >> Due to the above, I have kept the color sampling points at the same location as earlier and made the following changes to the test: >> >> - Moved the frame to the center of the screen. >> - Instead of comparing exact RGB values, used `colorCompare()` which allows color tolerance of 2 per color component to accommodate slight variations when comparing actual vs expected colors. >> >> >> >> Attempt 27 >> Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] >> Checking 150, 20, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 280, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 150, 250, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 20, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 62, 62, java.awt.Color[r=0,g=243,b=0] should not be java.awt.Color[r=255,g=255,b=255] >> Checking 240, 185, java.awt.Color[r=0,g=229,b=0] should not be java.awt.Color[r=255,g=255,b=255] >> Attempt 28 >> Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] >> Checking 150, 20, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 280, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 150, 250, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 20, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 62, 62, java.awt.Color[r=0,g=241,b=0] should not be java.awt.Color[r=255,g=255,b=255] >> Checking 240, 185, java.awt.Color[r=0,g=227,b=0] should not be java.awt.Color[r=255,g=255,b=255] >> Attempt 29 >> Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] >> Checking 150, 20, java.awt.Color[r=0,... > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > test update I missed pushing the latest update to the test previously. Added it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17563#issuecomment-1918180791 From dnguyen at openjdk.org Wed Jan 31 01:22:05 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 31 Jan 2024 01:22:05 GMT Subject: RFR: 8259550: The content of the print out displayed incomplete with the NimbusLAF [v6] In-Reply-To: <_1NWDKGJYR92i0e0fJ3pMuAf1zehGLlX1dd_kZxQpqM=.1e9ac5ad-8a1e-4d70-b485-0d9da9f0da85@github.com> References: <_1NWDKGJYR92i0e0fJ3pMuAf1zehGLlX1dd_kZxQpqM=.1e9ac5ad-8a1e-4d70-b485-0d9da9f0da85@github.com> Message-ID: On Tue, 30 Jan 2024 11:41:44 GMT, Tejesh R wrote: >> The issue is w.r.t to way that Synth prints the table. In Synth, the printing of Table happens column wise by painting blocks of columns which is due to the fact that Graphics used which is `ProxyGrpahics2D` (which get selected in `RasterPrinterJob `class, otherwise it would be `WPathGraphics` for other Look and feel). Since the printing happens in block wise and the columns where the x position is greater than the `table.bounds` doesn't gets painted because of the intersection check condition `!bounds.intersects(clip)`. Hence only droplines are painted instead of cells and gridlines. I couldn't find any reason for adding the intersection check here and when removed it didn't cause any regression too, rather it solves the issue and actually made sense too. In other Look and Feel its not required to apply the fix (in `BasicTableUI `class) because its not affecting anything yet since the painting happens for whole table. Hence proposing the fix for only SynthTableUI class. >> ([PrintManualTest_FitWidthMultiple.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java)) test is been used for testing. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Test updated for default L&F I re-ran doing the same as Prasanta on Windows 11. LGTM now. ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/17053#pullrequestreview-1852727738 From dnguyen at openjdk.org Wed Jan 31 01:30:01 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 31 Jan 2024 01:30:01 GMT Subject: RFR: JDK-8324238 : [macOS] java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails with the shape has not been applied msg [v2] In-Reply-To: References: <2X4lZKPcvcBCgjNBbezJGso48upOQIByUORAeXTOQuQ=.c7cf91b4-1b6b-4d31-95d7-04b2634f8eed@github.com> Message-ID: On Wed, 31 Jan 2024 01:08:13 GMT, Harshitha Onkar wrote: >> ShapeNotSetSometimes.java fails on macOS 11 on a random iteration of `colorCheck()` as shown below. The `colorCheck()` is repeated for about 50 times in the test. It is observed to pass on previous attempts and fail on a random attempt such as Attempt# 29 shown here. >> >> Here the point (150, 20) is well in the green area hence the slight color diff picked up by `robot.getPixelColor()` is not due to sampling of color at the edge (which sometimes causes robot to pick up slightly different color). >> >> >> Attempt 29 >> Checking 150, 20, java.awt.Color[r=0,g=255,b=1] should be java.awt.Color[r=0,g=255,b=0] >> >> >> Due to the above, I have kept the color sampling points at the same location as earlier and made the following changes to the test: >> >> - Moved the frame to the center of the screen. >> - Instead of comparing exact RGB values, used `colorCompare()` which allows color tolerance of 2 per color component to accommodate slight variations when comparing actual vs expected colors. >> >> >> >> Attempt 27 >> Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] >> Checking 150, 20, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 280, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 150, 250, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 20, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 62, 62, java.awt.Color[r=0,g=243,b=0] should not be java.awt.Color[r=255,g=255,b=255] >> Checking 240, 185, java.awt.Color[r=0,g=229,b=0] should not be java.awt.Color[r=255,g=255,b=255] >> Attempt 28 >> Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] >> Checking 150, 20, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 280, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 150, 250, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 20, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 62, 62, java.awt.Color[r=0,g=241,b=0] should not be java.awt.Color[r=255,g=255,b=255] >> Checking 240, 185, java.awt.Color[r=0,g=227,b=0] should not be java.awt.Color[r=255,g=255,b=255] >> Attempt 29 >> Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] >> Checking 150, 20, java.awt.Color[r=0,... > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > test update I took the latest changes and ran the test again multiple times. Newest changes look like minor stability changes. Still passes. LGTM ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/17563#pullrequestreview-1852733589 From tr at openjdk.org Wed Jan 31 04:56:02 2024 From: tr at openjdk.org (Tejesh R) Date: Wed, 31 Jan 2024 04:56:02 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException [v3] In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 16:30:43 GMT, Alexey Ivanov wrote: > I forgot to add a direct link to the test: [`BasicDirectoryModelConcurrency.java`](https://github.com/aivanov-jdk/jdk/blob/7cdf8c3610898557e91190d2bae440829a663376/test/jdk/javax/swing/JFileChooser/FileSystemView/BasicDirectoryModelConcurrency.java) > > > @mrserb I've been trying to write a regression test for this problem. Have I succeeded? Not quite? I am unable to get `ConcurrentModificationException` on any platform when I run the test locally. > > I reproduced the issue a few times on macOS and once on Linux, on a local host rather than in CI. Not able to reproduce in CI? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17462#issuecomment-1918381738 From psadhukhan at openjdk.org Wed Jan 31 05:21:17 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 31 Jan 2024 05:21:17 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI [v5] In-Reply-To: References: Message-ID: > When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak. > When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. > Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500) > > FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Test updated ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17458/files - new: https://git.openjdk.org/jdk/pull/17458/files/9d49e61a..f7c9829b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17458&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17458&range=03-04 Stats: 58 lines in 2 files changed: 29 ins; 18 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/17458.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17458/head:pull/17458 PR: https://git.openjdk.org/jdk/pull/17458 From tr at openjdk.org Wed Jan 31 05:29:06 2024 From: tr at openjdk.org (Tejesh R) Date: Wed, 31 Jan 2024 05:29:06 GMT Subject: Integrated: 8259550: The content of the print out displayed incomplete with the NimbusLAF In-Reply-To: References: Message-ID: On Mon, 11 Dec 2023 11:25:34 GMT, Tejesh R wrote: > The issue is w.r.t to way that Synth prints the table. In Synth, the printing of Table happens column wise by painting blocks of columns which is due to the fact that Graphics used which is `ProxyGrpahics2D` (which get selected in `RasterPrinterJob `class, otherwise it would be `WPathGraphics` for other Look and feel). Since the printing happens in block wise and the columns where the x position is greater than the `table.bounds` doesn't gets painted because of the intersection check condition `!bounds.intersects(clip)`. Hence only droplines are painted instead of cells and gridlines. I couldn't find any reason for adding the intersection check here and when removed it didn't cause any regression too, rather it solves the issue and actually made sense too. In other Look and Feel its not required to apply the fix (in `BasicTableUI `class) because its not affecting anything yet since the painting happens for whole table. Hence proposing the fix for only SynthTableUI class. > ([PrintManualTest_FitWidthMultiple.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java)) test is been used for testing. This pull request has now been integrated. Changeset: 577de17d Author: Tejesh R URL: https://git.openjdk.org/jdk/commit/577de17d24e83c55ab10a5794f381243a298fc68 Stats: 39 lines in 2 files changed: 8 ins; 3 del; 28 mod 8259550: The content of the print out displayed incomplete with the NimbusLAF Reviewed-by: dnguyen, psadhukhan, abhiscxk ------------- PR: https://git.openjdk.org/jdk/pull/17053 From psadhukhan at openjdk.org Wed Jan 31 05:39:11 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 31 Jan 2024 05:39:11 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI [v6] In-Reply-To: References: Message-ID: > When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak. > When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. > Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500) > > FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Optimise test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17458/files - new: https://git.openjdk.org/jdk/pull/17458/files/f7c9829b..047e25b5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17458&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17458&range=04-05 Stats: 15 lines in 1 file changed: 6 ins; 5 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/17458.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17458/head:pull/17458 PR: https://git.openjdk.org/jdk/pull/17458 From psadhukhan at openjdk.org Wed Jan 31 05:39:12 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 31 Jan 2024 05:39:12 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI [v3] In-Reply-To: References: <1xfZ5RyTcjtAZ87SQYOMdNYYRnc76Fxr0m05vbktyZQ=.4e4e71a5-351f-4654-90e6-c21e2a199894@github.com> Message-ID: On Tue, 30 Jan 2024 10:38:03 GMT, Alexey Ivanov wrote: >> I was not sure of the nuances of PhantomReference and ReferenceQueue, so have used WeakReference logic in the test which I think is more simpler.. > > It's simpler with `PhantomReference`. This type of reference does not allow getting its referent, and it's not needed in this case. When the referent of a reference is cleared by the GC, the reference is added into the associated reference queue. This is true for any type of `Reference`, but `PhantomReference` has to use a reference queue. > > Here's how to use them: https://github.com/aivanov-jdk/jdk/commit/b0da8b30fdcf03abffa663eb5ba42df1fe4a9971 > > I keep the references in a list. The size of the list is the number of live `JLabel` objects. On each iteration, I poll the reference queue and remove the _dead_ references from the list. > > https://github.com/openjdk/jdk/blob/b0da8b30fdcf03abffa663eb5ba42df1fe4a9971/test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java#L193-L201 > > If the number of removed references is zero, the test fails because objects are leaked. Otherwise, the test passes. This aligns with your latest changes. > > Your code also does the job. I'll approve it if you don't want to use `PhantomReference`. Thanks for your "reference" on PhantomReference..Although my testcode is doing same thing (which you acknowledged) no harm in trying new way (for me) for my future reference so have updated the test to use PhantomReference. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1472325683 From duke at openjdk.org Wed Jan 31 06:03:04 2024 From: duke at openjdk.org (vtstydev) Date: Wed, 31 Jan 2024 06:03:04 GMT Subject: RFR: 8307246 : Printing: banded raster path doesn't account for device offset values [v7] In-Reply-To: <6lSf0r8L-nIkin7RgPv6rDapWvcWIx8T2c1Hf_jkPiA=.7ecd7db0-9051-4905-b680-4aecefd55ce8@github.com> References: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com> <6lSf0r8L-nIkin7RgPv6rDapWvcWIx8T2c1Hf_jkPiA=.7ecd7db0-9051-4905-b680-4aecefd55ce8@github.com> Message-ID: On Tue, 30 Jan 2024 04:32:50 GMT, Prasanta Sadhukhan wrote: >> vtstydev has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix header and imports section in AlphaPrintingOffsets > > src/java.desktop/share/classes/sun/print/RasterPrinterJob.java line 2424: > >> 2422: int bandX = deviceLeft; >> 2423: if (bandX < 0) { >> 2424: bandGraphics.translate(bandX/xScale,0); > > Did we test this path where another translate is being done on the same object after it is done in l2399? This snippet works when application sets negative start point of imageable area of paper. I have tested it using ` paper.setImageableArea(-50, -50, paper.getWidth(), paper.getHeight())` LANDSCAPE oriented and REVERSE_LANDSCAPE oriented images printed with transparency aren't the same as the corresponded images printed with opacity. They are shifted in the opposite direction. I suggest nobody tested printing with negative start point before. It's strange when start point is situated in the negative area in my opinion. Is there a sense to assume it may be used in such way? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17030#discussion_r1472340024 From clanger at openjdk.org Wed Jan 31 06:05:18 2024 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 31 Jan 2024 06:05:18 GMT Subject: RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations [v4] In-Reply-To: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> References: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> Message-ID: > This picks up fixing the issue of [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) again. A fix had been integrated with #17224 but @prrace had concerns and so it was backed out. > > I have now spent quite some thoughts into the problem and end up with the [initial commit](https://github.com/openjdk/jdk/pull/6306/commits/5d18a76cb967e9ede6394cbd6c28bb61facf785c) of #6306 as the most elegant and least intrusive solution. > > Why is this? > > The JNI warning we observe in the test is: > `[WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV > at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 22.0.1-internal/Native Method) > at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:95) > at sun.awt.Win32GraphicsEnvironment.(java.desktop at 22.0.1-internal/Win32GraphicsEnvironment.java:63) > ... > at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) > at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)` > > This happens because obviously the test FreeTypeScalerJNICheck runs with `-Xcheck:jni` and in the scenario where we're observing the warning, a missing exception check for the JNI call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged` at awt_Win32GraphicsEnv.cpp#L129 > https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L129 is airing up. Omitting the exception check would not be a problem if it could be guaranteed that after this call no other JNI->Java call was being made. But seemingly in this very particular configuration on some of our Windows servers, there must be JNI->Java calls that follow the call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged`, likely from the subsequent call to [initScreens](https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L149) in `sun.awt.Win32GraphicsEnvironment::initDisplay`. https://github.com/openjdk/jdk/blob/8b6293f6bfb7b7628c6604e6c44401fc96d85cf4/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L141 Maybe the usual control flow would call the wrapping native method `DWMIsCompositi onEnabled()` from somewhere else initially such that the initialization of `Win32GraphicsEnvironment` would not go through `initScreens` or similar. > ... Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: Add formatting suggestions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17404/files - new: https://git.openjdk.org/jdk/pull/17404/files/528f25bf..24dd7541 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17404&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17404&range=02-03 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17404.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17404/head:pull/17404 PR: https://git.openjdk.org/jdk/pull/17404 From clanger at openjdk.org Wed Jan 31 06:05:19 2024 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 31 Jan 2024 06:05:19 GMT Subject: RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations [v3] In-Reply-To: References: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> Message-ID: On Mon, 29 Jan 2024 20:45:18 GMT, Alexey Ivanov wrote: >> Christoph Langer 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: >> >> - Move Exception Check to the right place >> - Merge branch 'master' into JDK-8323664 >> - Changes to assertion function and test as discussed >> - Revert "JDK-8323664" >> >> This reverts commit 32128744252d75104e0d19f5eb701ffdc7b3d417. >> - Merge branch 'master' into JDK-8323664 >> - JDK-8323664 > > test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java line 48: > >> 46: ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder("-Xcheck:jni", FreeTypeScalerJNICheck.class.getName(), "runtest"); >> 47: OutputAnalyzer oa = ProcessTools.executeProcess(pb); >> 48: oa.shouldContain("Done").shouldNotContain("WARNING").shouldNotContain("AWT Assertion").shouldHaveExitValue(0); > > Maybe wrap each condition to its own line? > Suggestion: > > oa.shouldContain("Done") > .shouldNotContain("WARNING") > .shouldNotContain("AWT Assertion") > .shouldHaveExitValue(0); > > This way each verified condition stands out. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17404#discussion_r1472342402 From mdoerr at openjdk.org Wed Jan 31 06:11:08 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 31 Jan 2024 06:11:08 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs In-Reply-To: References: <4Pd7oVMUE2HYXJtde1fxURXSaS24X2bK5t2448kwT8s=.8a8c6fbc-3537-4289-8577-a978636f55a2@github.com> Message-ID: On Tue, 30 Jan 2024 14:02:41 GMT, Matthias Baesken wrote: >>> Yes there is a nice define in the AIX header >> >> *sigh* On linux, they go to some lengths to avoid this, using a __REDEFINE mechanism. Oh well. >> >> Anyway, I think this particular can be resolved by not including the standard includes in the header file (which is bad practice anyway!). I'm currently testing this build in our CI to see that it does not break anything else. I'd appreciate if you could take the latest version for a spin, particularly a debug build... > >> I'd appreciate if you could take the latest version for a spin, particularly a debug build... > > Yes we pick up the latest version of the PR in a couple of hours for the build+'lots of tests' (and this includes a fastdebug too). @MBaesken, @JoKern65: This seems to break the debug build (fast and slow) on AIX: jdk/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c:101:24: error: no member named 'open64' in 'SpanIteratorFuncs'; did you mean 'open'? srData = (*pFuncs->open)(env, si); ^~~~ open /usr/include/fcntl.h:115:14: note: expanded from macro 'open' #define open open64 ^ jdk/src/java.desktop/share/native/libawt/java2d/pipe/SpanIterator.h:37:17: note: 'open' declared here void *(*open)(JNIEnv *env, jobject iterator); ^ Ah, that has already been reported above. Yeah, interesting that the normal build has passed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1918443702 From clanger at openjdk.org Wed Jan 31 06:12:03 2024 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 31 Jan 2024 06:12:03 GMT Subject: RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations [v3] In-Reply-To: References: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> <3xvCOTZxAghqFhnhAHQXsqeBwbphdDtN73_KawaiOx8=.72d5561d-7663-4142-98cf-caaf77eb44c9@github.com> Message-ID: On Tue, 30 Jan 2024 13:44:22 GMT, Alexey Ivanov wrote: >> In fact, any method can throw an exception? >> >> Is there a guide which clearly states where `ExceptionCheck` is required? The function returns a boolean indicating whether there's a pending exception. Shall we back out if there is? > >> Is there a guide which clearly states where `ExceptionCheck` is required? > > I should've looked it up. [Java Native Interface Specification](https://docs.oracle.com/en/java/javase/21/docs/specs/jni/index.html), section on [handling Java Exception](https://docs.oracle.com/en/java/javase/21/docs/specs/jni/design.html#java-exceptions) says: > >
Certain JNI functions use the Java exception mechanism to report error conditions. In most cases, JNI functions report error conditions by returning an error code and throwing a Java exception. The error code is usually a special return value (such as NULL) that is outside of the range of normal return values. Therefore, the programmer can: > > * quickly check the return value of the last JNI call to determine if an error has occurred, and > * call a function, `ExceptionOccurred()`, to obtain the exception object that contains a more detailed description of the error condition. > > There are two cases where the programmer needs to check for exceptions without being able to first check an error code: > > * The JNI functions that invoke a Java method return the result of the Java method. The programmer must call `ExceptionOccurred()` to check for possible exceptions that occurred during the execution of the Java method. > * Some of the JNI array access functions do not return an error code, but may throw an `ArrayIndexOutOfBoundsException` or `ArrayStoreException`. > > In all other cases, a non-error return value guarantees that no exceptions have been thrown.
> > Thus, `FindClass` returns non-null value if no error occurred; if the returned value is null, an error occurred, and `FindClass` raised an exception on the Java side. As per https://docs.oracle.com/en/java/javase/21/docs/specs/jni/design.html#java-exceptions: There are two cases where the programmer needs to check for exceptions without being able to first check an error code: - The JNI functions that invoke a Java method return the result of the Java method. The programmer must call ExceptionOccurred() to check for possible exceptions that occurred during the execution of the Java method. - Some of the JNI array access functions do not return an error code, but may throw an ArrayIndexOutOfBoundsException or ArrayStoreException. In all other cases, a non-error return value guarantees that no exceptions have been thrown. So, the check is needed only after `JNU_CallStaticMethodByName` for `dwmCompositionChanged` (and before other JNI activity) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17404#discussion_r1472347241 From clanger at openjdk.org Wed Jan 31 06:15:04 2024 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 31 Jan 2024 06:15:04 GMT Subject: RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations [v3] In-Reply-To: References: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> Message-ID: On Tue, 30 Jan 2024 14:13:07 GMT, Alexey Ivanov wrote: >> Christoph Langer 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: >> >> - Move Exception Check to the right place >> - Merge branch 'master' into JDK-8323664 >> - Changes to assertion function and test as discussed >> - Revert "JDK-8323664" >> >> This reverts commit 32128744252d75104e0d19f5eb701ffdc7b3d417. >> - Merge branch 'master' into JDK-8323664 >> - JDK-8323664 > > src/java.desktop/windows/native/libawt/windows/awt_Debug.cpp line 158: > >> 156: // be on the safe side and avoid JNI warnings by calling ExceptionCheck >> 157: // an accumulated exception is not cleared >> 158: env->ExceptionCheck(); > > So, this doesn't actually do anything but avoids JNI warnings, does it? > > `AwtDebugSupport::AssertCallback` can be called *at any time*, hence calling JNI functions here is unsafe. Adding `env->ExceptionCheck()` doesn't change anything. Yes. However, it's "only" in the assertion callback that only exists in debug VMs. And an original exception isn't lost. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17404#discussion_r1472348927 From clanger at openjdk.org Wed Jan 31 06:27:01 2024 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 31 Jan 2024 06:27:01 GMT Subject: RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations [v3] In-Reply-To: References: <5lTIcTJ7gWg1AgwS9heWiI1Y2RqG0iYX3F4OunKF-3Q=.2438df45-9b02-4790-8b1b-3c7ed76efadc@github.com> Message-ID: On Tue, 30 Jan 2024 14:03:39 GMT, Alexey Ivanov wrote: > Now that I re-read the problem statement and the exception handling JNI, the fix doesn't look correct to me. > > What does the warning say? > > > WARNING in native method: JNI call made without checking exceptions when required to from `CallStaticVoidMethodV` at `sun.awt.Win32GraphicsEnvironment.initDisplay` > > To me, it means that `Win32GraphicsEnvironment.initDisplay` is the problem. You found that `DWMIsCompositionEnabled` calls a static method via `JNU_CallStaticMethodByName`. > > As far as I can see, it's the last statement of the `DWMIsCompositionEnabled` function. > > Then `Java_sun_awt_Win32GraphicsEnvironment_initDisplay` calls `initScreens` which, seemingly, can call other JNI methods. > Well, yes - however the initScreens only calls other JNI methods through the assert callback of debug builds, so not a general thing. The initial proposal for a fix was to add an exception check right to the call of [JNU_CallStaticMethodByName(...,"dwmCompositionChanged",...)](https://github.com/openjdk/jdk/pull/17404/commits/32128744252d75104e0d19f5eb701ffdc7b3d417) but was dismissed by @prrace I think the current proposal makes the assertion callback more resilient to JNI warnings in general, so I guess it's not bad. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17404#issuecomment-1918464139 From duke at openjdk.org Wed Jan 31 06:41:00 2024 From: duke at openjdk.org (vtstydev) Date: Wed, 31 Jan 2024 06:41:00 GMT Subject: RFR: 8307246 : Printing: banded raster path doesn't account for device offset values [v7] In-Reply-To: <8rmJPJExUnK5wib0jdQgOVisfvARmYKy79-kQ-7HUUo=.03c85ccd-1dba-4b80-b754-a3b12ce588a2@github.com> References: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com> <8rmJPJExUnK5wib0jdQgOVisfvARmYKy79-kQ-7HUUo=.03c85ccd-1dba-4b80-b754-a3b12ce588a2@github.com> Message-ID: On Tue, 30 Jan 2024 04:44:31 GMT, Prasanta Sadhukhan wrote: > > Only on Windows platform under certain conditions real device prints shifted image on paper. > > Also, if it affects only windows platform, will it not be more advisable to do in WPrinterJob class instead of RasterPrinterJob? It means that we will need to copy `protected int printPage(Pageable document, int pageIndex)` into 3 classes derived from RasterPrinterJob; namely WPrinterJob , CPrinterJob, PSPrinterJob. I think the most part of RasterPrinterJob code matches all platforms. Would be better to ask somebody who is well familiar with platform dependent print systems. Bug affected windows platform because only WPrinterJob's `getPhysicalPrintableX(Paper p), getPhysicalPrintableY(Paper p)` may return nonzero values. These values may be taken into account separately from this logic int bandX = deviceLeft - deviceAddressableX; if (bandX < 0) { bandGraphics.translate(bandX/xScale,0); bandX = 0; } int bandY = deviceTop + bandTop - deviceAddressableY; if (bandY < 0) { bandGraphics.translate(0,bandY/yScale); bandY = 0; } ------------- PR Comment: https://git.openjdk.org/jdk/pull/17030#issuecomment-1918479199 From duke at openjdk.org Wed Jan 31 06:52:03 2024 From: duke at openjdk.org (vtstydev) Date: Wed, 31 Jan 2024 06:52:03 GMT Subject: RFR: 8307246 : Printing: banded raster path doesn't account for device offset values [v7] In-Reply-To: <6lSf0r8L-nIkin7RgPv6rDapWvcWIx8T2c1Hf_jkPiA=.7ecd7db0-9051-4905-b680-4aecefd55ce8@github.com> References: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com> <6lSf0r8L-nIkin7RgPv6rDapWvcWIx8T2c1Hf_jkPiA=.7ecd7db0-9051-4905-b680-4aecefd55ce8@github.com> Message-ID: On Tue, 30 Jan 2024 04:35:02 GMT, Prasanta Sadhukhan wrote: >> vtstydev has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix header and imports section in AlphaPrintingOffsets > > test/jdk/java/awt/print/PrinterJob/ImagePrinting/AlphaPrintingOffsets.java line 73: > >> 71: System.out.println("Printer not configured or available." >> 72: + " Test cannot continue."); >> 73: PassFailJFrame.forcePass(); > > I guess it is now being preferred to throw jtreg.SkippedException instead of forcePass for printers not available scenarios?! PrintGlyphVectorTest, ClippedImages use `PassFailJFrame.forcePass();` I guided these samples. If you want I to to use `throw` istead. ok. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17030#discussion_r1472373915 From clanger at openjdk.org Wed Jan 31 07:23:13 2024 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 31 Jan 2024 07:23:13 GMT Subject: RFR: 8185862: AWT Assertion Failure in ::GetDIBits(hBMDC, hBM, 0, 1, 0, gpBitmapInfo, 0) 'awt_Win32GraphicsDevice.cpp', at line 185 [v2] In-Reply-To: References: Message-ID: > The assertions reported in the bug were observed spuriously and here and there broke tests in some Windows configurations. > For instance [JDK-8266129](https://bugs.openjdk.org/browse/JDK-8266129), [JDK-8269529](https://bugs.openjdk.org/browse/JDK-8269529) or [JDK-8323664](https://bugs.openjdk.org/browse/JDK-8323664) came up due to this. > > The problem is that in Windows environments without a valid display, e.g. started by system services or via PowerShell Remoting, one sees a Monitor with name 'Windisc' in `EnumDisplayMonitors`. > However, it seems to be some kind of a pseudo device where you can not get a DC via `CreateDC`. This behavior/monitor type doesn't seem to be well documented, though. > > I hereby modify the device initialization code to only count/detect monitors where CreateDC returns non-NULL in Devices.cpp. I also add some more checking/error handling to AwtWin32GraphicsDevice::Initialize() for correctness. > > Furthermore, I re-enable the test `javax/swing/reliability/HangDuringStaticInitialization.java` for Windows Debug VMs, which reverts the fix from JDK-8269529 that should not be necessary any more. Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: Add comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17614/files - new: https://git.openjdk.org/jdk/pull/17614/files/2a766183..ea8b6b2e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17614&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17614&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17614.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17614/head:pull/17614 PR: https://git.openjdk.org/jdk/pull/17614 From clanger at openjdk.org Wed Jan 31 07:29:03 2024 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 31 Jan 2024 07:29:03 GMT Subject: RFR: 8185862: AWT Assertion Failure in ::GetDIBits(hBMDC, hBM, 0, 1, 0, gpBitmapInfo, 0) 'awt_Win32GraphicsDevice.cpp', at line 185 [v2] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 07:23:13 GMT, Christoph Langer wrote: >> The assertions reported in the bug were observed spuriously and here and there broke tests in some Windows configurations. >> For instance [JDK-8266129](https://bugs.openjdk.org/browse/JDK-8266129), [JDK-8269529](https://bugs.openjdk.org/browse/JDK-8269529) or [JDK-8323664](https://bugs.openjdk.org/browse/JDK-8323664) came up due to this. >> >> The problem is that in Windows environments without a valid display, e.g. started by system services or via PowerShell Remoting, one sees a Monitor with name 'Windisc' in `EnumDisplayMonitors`. >> However, it seems to be some kind of a pseudo device where you can not get a DC via `CreateDC`. This behavior/monitor type doesn't seem to be well documented, though. >> >> I hereby modify the device initialization code to only count/detect monitors where CreateDC returns non-NULL in Devices.cpp. I also add some more checking/error handling to AwtWin32GraphicsDevice::Initialize() for correctness. >> >> Furthermore, I re-enable the test `javax/swing/reliability/HangDuringStaticInitialization.java` for Windows Debug VMs, which reverts the fix from JDK-8269529 that should not be necessary any more. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Add comments I added a comment to explain that we skip monitors where CreateDC fails. The fix runs successfully through SAP's testing with no regressions spotted. Looks like it even fixes the problems of test/jdk/java/awt/font/GlyphVector/LayoutCompatTest.java on Windows that we reported in the comments of https://bugs.openjdk.org/browse/JDK-8318364. @prrace Want to take a look here (or assign somebody from client group)? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17614#issuecomment-1918533151 From psadhukhan at openjdk.org Wed Jan 31 08:30:03 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 31 Jan 2024 08:30:03 GMT Subject: RFR: 8307246 : Printing: banded raster path doesn't account for device offset values [v7] In-Reply-To: References: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com> Message-ID: <9IxBAQGvXNgO3xUt-H_57DA2Y9N42u4Ja6mpZWfF1GE=.a0d5b72c-4246-4ce8-a0e5-d4e67d6e54dd@github.com> On Mon, 29 Jan 2024 06:56:58 GMT, vtstydev wrote: >> More correct way to take in consideration nonzero PHYSICALOFFSETX, PHYSICALOFFSETY of device for banded-raster printing loop. Only on Windows platform under certain conditions real device prints shifted image on paper. > > vtstydev has updated the pull request incrementally with one additional commit since the last revision: > > Fix header and imports section in AlphaPrintingOffsets I could not notice any difference related to "image" without fix and with fix as told in the test instructions. Only difference I noticed is in **margin rectangle** for "Landscape-Alpha" and "Reverse Landscape- Alpha" page 4 and 6 namely..What image difference should be looked for? I guess the instructions should be made more clearer for tester.. Attached are the printouts without the fix and with the fix [printout-withoutfix.pdf](https://github.com/openjdk/jdk/files/14108433/printout-withoutfix.pdf) [printout-withfix.pdf](https://github.com/openjdk/jdk/files/14108434/printout-withfix.pdf) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17030#issuecomment-1918615354 From psadhukhan at openjdk.org Wed Jan 31 08:30:03 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 31 Jan 2024 08:30:03 GMT Subject: RFR: 8307246 : Printing: banded raster path doesn't account for device offset values [v7] In-Reply-To: References: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com> <6lSf0r8L-nIkin7RgPv6rDapWvcWIx8T2c1Hf_jkPiA=.7ecd7db0-9051-4905-b680-4aecefd55ce8@github.com> Message-ID: On Wed, 31 Jan 2024 06:49:39 GMT, vtstydev wrote: >> test/jdk/java/awt/print/PrinterJob/ImagePrinting/AlphaPrintingOffsets.java line 73: >> >>> 71: System.out.println("Printer not configured or available." >>> 72: + " Test cannot continue."); >>> 73: PassFailJFrame.forcePass(); >> >> I guess it is now being preferred to throw jtreg.SkippedException instead of forcePass for printers not available scenarios?! > > PrintGlyphVectorTest, ClippedImages use `PassFailJFrame.forcePass();` > I guided these samples. > If you want I to to use `throw` istead. ok. I guess those are old tests which need to be migrated to the new SkippedException semantics... java/awt/print/PrinterJob/PageRangesDlgTest.java is relatively newer migrated test..and since it is mentioned in the test that it needs physical printer to reproduce and PDF printer will not do, then no point making it pass if physical printer is not present, that is my opinion ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17030#discussion_r1472461455 From mbaesken at openjdk.org Wed Jan 31 09:22:07 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 31 Jan 2024 09:22:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4] In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 14:15:57 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie 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 seven additional commits since the last revision: > > - Merge branch 'master' into jdk-FOB64 > - Move #include out of debug_util.h > - Restore AIX dirent64 et al defines > - Rollback AIX changes since they are now tracked in JDK-8324834 > - Remove superfluous setting of FOB64 > - Replace all foo64() with foo() for large-file functions in the JDK > - 8324539: Do not use LFS64 symbols in JDK libs After adding this additional patch I fully build fastdebug on AIX (hav to admit it does not look very nice). diff --git a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c index 823475b0a23..ee0109b6806 100644 --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c @@ -31,6 +31,10 @@ #include "SpanIterator.h" #include "Trace.h" +#if defined(_AIX) && defined(open) +#undef open +#endif + /* The "header" consists of a jint opcode and a jint span count value */ #define INTS_PER_HEADER 2 #define BYTES_PER_HEADER 8 ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1918699480 From tr at openjdk.org Wed Jan 31 09:26:03 2024 From: tr at openjdk.org (Tejesh R) Date: Wed, 31 Jan 2024 09:26:03 GMT Subject: RFR: 8324808 : Manual printer tests have no Pass/Fail buttons, instructions close set 3 [v2] In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 09:17:46 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> >> Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured. >> >> Please review and let me know your suggestions. >> >> Regards, >> Renjith > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Capitalized static final variables test/jdk/java/awt/print/PrinterJob/PrintNullString.java line 142: > 140: } catch (NullPointerException e) { > 141: g.drawString("caught expected NPE for null String, int", 20, 40); > 142: }/* catch (Exception e) { I guess u can remove these instead of commenting? Any reason for commenting these instead of removing? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17609#discussion_r1472528908 From duke at openjdk.org Wed Jan 31 09:34:03 2024 From: duke at openjdk.org (vtstydev) Date: Wed, 31 Jan 2024 09:34:03 GMT Subject: RFR: 8307246 : Printing: banded raster path doesn't account for device offset values [v7] In-Reply-To: <9IxBAQGvXNgO3xUt-H_57DA2Y9N42u4Ja6mpZWfF1GE=.a0d5b72c-4246-4ce8-a0e5-d4e67d6e54dd@github.com> References: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com> <9IxBAQGvXNgO3xUt-H_57DA2Y9N42u4Ja6mpZWfF1GE=.a0d5b72c-4246-4ce8-a0e5-d4e67d6e54dd@github.com> Message-ID: On Wed, 31 Jan 2024 08:26:51 GMT, Prasanta Sadhukhan wrote: > Only difference I noticed is in **margin rectangle** for "Landscape-Alpha" and "Reverse Landscape- Alpha" page 4 and 6 namely It's the essence of this bug. In printout-withoutfix (4 and 6 page)aren't seen all margins. If I replace test instruction `Check that 6 pages have the same image except text messages.` on `Check that all margins of biggest rectangle are visible on each paper` Is it ok? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17030#issuecomment-1918719481 From psadhukhan at openjdk.org Wed Jan 31 09:56:03 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 31 Jan 2024 09:56:03 GMT Subject: RFR: 8307246 : Printing: banded raster path doesn't account for device offset values [v7] In-Reply-To: References: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com> <9IxBAQGvXNgO3xUt-H_57DA2Y9N42u4Ja6mpZWfF1GE=.a0d5b72c-4246-4ce8-a0e5-d4e67d6e54dd@github.com> Message-ID: On Wed, 31 Jan 2024 09:31:30 GMT, vtstydev wrote: > > Only difference I noticed is in **margin rectangle** for "Landscape-Alpha" and "Reverse Landscape- Alpha" page 4 and 6 namely > > It's the essence of this bug. In printout-withoutfix (4 and 6 page)aren't seen all margins. > > If I replace test instruction `Check that 6 pages have the same image except text messages.` on `Check that all margins of biggest rectangle are visible on each paper` Is it ok? Maybe "Please check the page margin rectangle are properly drawn and visible on all sides on all pages" Also, is there any need of drawing the inner rectangle if there will not be any differences to it...it will be less confusing for the tester ------------- PR Comment: https://git.openjdk.org/jdk/pull/17030#issuecomment-1918759043 From azvegint at openjdk.org Wed Jan 31 09:57:02 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 31 Jan 2024 09:57:02 GMT Subject: RFR: JDK-8324238 : [macOS] java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails with the shape has not been applied msg [v2] In-Reply-To: References: <2X4lZKPcvcBCgjNBbezJGso48upOQIByUORAeXTOQuQ=.c7cf91b4-1b6b-4d31-95d7-04b2634f8eed@github.com> Message-ID: On Wed, 31 Jan 2024 01:08:13 GMT, Harshitha Onkar wrote: >> ShapeNotSetSometimes.java fails on macOS 11 on a random iteration of `colorCheck()` as shown below. The `colorCheck()` is repeated for about 50 times in the test. It is observed to pass on previous attempts and fail on a random attempt such as Attempt# 29 shown here. >> >> Here the point (150, 20) is well in the green area hence the slight color diff picked up by `robot.getPixelColor()` is not due to sampling of color at the edge (which sometimes causes robot to pick up slightly different color). >> >> >> Attempt 29 >> Checking 150, 20, java.awt.Color[r=0,g=255,b=1] should be java.awt.Color[r=0,g=255,b=0] >> >> >> Due to the above, I have kept the color sampling points at the same location as earlier and made the following changes to the test: >> >> - Moved the frame to the center of the screen. >> - Instead of comparing exact RGB values, used `colorCompare()` which allows color tolerance of 2 per color component to accommodate slight variations when comparing actual vs expected colors. >> >> >> >> Attempt 27 >> Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] >> Checking 150, 20, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 280, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 150, 250, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 20, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 62, 62, java.awt.Color[r=0,g=243,b=0] should not be java.awt.Color[r=255,g=255,b=255] >> Checking 240, 185, java.awt.Color[r=0,g=229,b=0] should not be java.awt.Color[r=255,g=255,b=255] >> Attempt 28 >> Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] >> Checking 150, 20, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 280, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 150, 250, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 20, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] >> Checking 62, 62, java.awt.Color[r=0,g=241,b=0] should not be java.awt.Color[r=255,g=255,b=255] >> Checking 240, 185, java.awt.Color[r=0,g=227,b=0] should not be java.awt.Color[r=255,g=255,b=255] >> Attempt 29 >> Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] >> Checking 150, 20, java.awt.Color[r=0,... > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > test update Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17563#pullrequestreview-1853319620 From rkannathpari at openjdk.org Wed Jan 31 10:52:02 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Wed, 31 Jan 2024 10:52:02 GMT Subject: RFR: 8324808 : Manual printer tests have no Pass/Fail buttons, instructions close set 3 [v2] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 09:22:41 GMT, Tejesh R wrote: >> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: >> >> Capitalized static final variables > > test/jdk/java/awt/print/PrinterJob/PrintNullString.java line 142: > >> 140: } catch (NullPointerException e) { >> 141: g.drawString("caught expected NPE for null String, int", 20, 40); >> 142: }/* catch (Exception e) { > > I guess u can remove these instead of commenting? Any reason for commenting these instead of removing? These lines are commented in existing code. Felt it may be useful for further debugging in case of failure, so kept as it is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17609#discussion_r1472645679 From tr at openjdk.org Wed Jan 31 11:04:03 2024 From: tr at openjdk.org (Tejesh R) Date: Wed, 31 Jan 2024 11:04:03 GMT Subject: RFR: 8324808 : Manual printer tests have no Pass/Fail buttons, instructions close set 3 [v2] In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 09:17:46 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> >> Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured. >> >> Please review and let me know your suggestions. >> >> Regards, >> Renjith > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Capitalized static final variables Marked as reviewed by tr (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17609#pullrequestreview-1853466180 From tr at openjdk.org Wed Jan 31 11:04:04 2024 From: tr at openjdk.org (Tejesh R) Date: Wed, 31 Jan 2024 11:04:04 GMT Subject: RFR: 8324808 : Manual printer tests have no Pass/Fail buttons, instructions close set 3 [v2] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 10:49:05 GMT, Renjith Kannath Pariyangad wrote: >> test/jdk/java/awt/print/PrinterJob/PrintNullString.java line 142: >> >>> 140: } catch (NullPointerException e) { >>> 141: g.drawString("caught expected NPE for null String, int", 20, 40); >>> 142: }/* catch (Exception e) { >> >> I guess u can remove these instead of commenting? Any reason for commenting these instead of removing? > > These lines are commented in existing code. Felt it may be useful for further debugging in case of failure, so kept as it is. Ok, else the fix is fine for me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17609#discussion_r1472660678 From duke at openjdk.org Wed Jan 31 11:06:04 2024 From: duke at openjdk.org (vtstydev) Date: Wed, 31 Jan 2024 11:06:04 GMT Subject: RFR: 8307246 : Printing: banded raster path doesn't account for device offset values [v7] In-Reply-To: References: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com> <9IxBAQGvXNgO3xUt-H_57DA2Y9N42u4Ja6mpZWfF1GE=.a0d5b72c-4246-4ce8-a0e5-d4e67d6e54dd@github.com> Message-ID: On Wed, 31 Jan 2024 09:53:09 GMT, Prasanta Sadhukhan wrote: > Also, is there any need of drawing the inner rectangle if there will not be any differences to it...it will be less confusing for the tester I need to draw something with opacity and something with transparency colors, otherwise I couldn't compare different ways for page printing. Honestly I don't know how to replace it with something invisible for tester except to reduce its size ------------- PR Comment: https://git.openjdk.org/jdk/pull/17030#issuecomment-1918882065 From aivanov at openjdk.org Wed Jan 31 11:22:03 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 31 Jan 2024 11:22:03 GMT Subject: RFR: 8323670: A few client tests intermittently throw ConcurrentModificationException [v3] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 04:53:44 GMT, Tejesh R wrote: > > I forgot to add a direct link to the test: [`BasicDirectoryModelConcurrency.java`](https://github.com/aivanov-jdk/jdk/blob/7cdf8c3610898557e91190d2bae440829a663376/test/jdk/javax/swing/JFileChooser/FileSystemView/BasicDirectoryModelConcurrency.java) > > > @mrserb I've been trying to write a regression test for this problem. Have I succeeded? Not quite? I am unable to get `ConcurrentModificationException` on any platform when I run the test locally. > > > > > > I reproduced the issue a few times on macOS and once on Linux, on a local host rather than in CI. > > Not able to reproduce in CI? The opposite. It fails in Oracle CI, yet it's still not stable enough. And the test doesn't clean up the files when it fails. So it needs additional work. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17462#issuecomment-1918906285 From aivanov at openjdk.org Wed Jan 31 16:44:06 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 31 Jan 2024 16:44:06 GMT Subject: RFR: 8320342: Use PassFailJFrame for TruncatedPopupMenuTest.java In-Reply-To: References: Message-ID: <8esiSc2gUS82n5FHu-r_aOLRq_62132ROhnzItkNTRA=.de3b9846-ed27-4ad5-90fe-59ed7f86f4db@github.com> On Tue, 30 Jan 2024 21:49:12 GMT, Rajat Mahajan wrote: > Modified the test to use PassFailJFrame and open sourced it. > The test shows two windows, one for instructions and the other to perform testing on. > Tested locally and it works fine. Looks good, except for minor nits. test/jdk/java/awt/PopupMenu/TruncatedPopupMenuTest.java line 31: > 29: import java.awt.event.MouseEvent; > 30: > 31: /* @test Suggestion: /* * @test Keep the first line of the comment empty; it's empty usually. test/jdk/java/awt/PopupMenu/TruncatedPopupMenuTest.java line 64: > 62: .awaitAndCheck(); > 63: > 64: } Suggestion: .awaitAndCheck(); } I suggest removing this blank line in the end of the method. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17641#pullrequestreview-1854195222 PR Review Comment: https://git.openjdk.org/jdk/pull/17641#discussion_r1473083371 PR Review Comment: https://git.openjdk.org/jdk/pull/17641#discussion_r1473081463 From rmahajan at openjdk.org Wed Jan 31 17:09:14 2024 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Wed, 31 Jan 2024 17:09:14 GMT Subject: RFR: 8320342: Use PassFailJFrame for TruncatedPopupMenuTest.java [v2] In-Reply-To: References: Message-ID: > Modified the test to use PassFailJFrame and open sourced it. > The test shows two windows, one for instructions and the other to perform testing on. > Tested locally and it works fine. Rajat Mahajan has updated the pull request incrementally with two additional commits since the last revision: - Update test/jdk/java/awt/PopupMenu/TruncatedPopupMenuTest.java Co-authored-by: Alexey Ivanov - Update test/jdk/java/awt/PopupMenu/TruncatedPopupMenuTest.java Co-authored-by: Alexey Ivanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17641/files - new: https://git.openjdk.org/jdk/pull/17641/files/6c021d98..f3d5308c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17641&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17641&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17641.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17641/head:pull/17641 PR: https://git.openjdk.org/jdk/pull/17641 From aivanov at openjdk.org Wed Jan 31 17:12:02 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 31 Jan 2024 17:12:02 GMT Subject: RFR: 8320342: Use PassFailJFrame for TruncatedPopupMenuTest.java [v2] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 17:09:14 GMT, Rajat Mahajan wrote: >> Modified the test to use PassFailJFrame and open sourced it. >> The test shows two windows, one for instructions and the other to perform testing on. >> Tested locally and it works fine. > > Rajat Mahajan has updated the pull request incrementally with two additional commits since the last revision: > > - Update test/jdk/java/awt/PopupMenu/TruncatedPopupMenuTest.java > > Co-authored-by: Alexey Ivanov > - Update test/jdk/java/awt/PopupMenu/TruncatedPopupMenuTest.java > > Co-authored-by: Alexey Ivanov Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17641#pullrequestreview-1854349224 From aivanov at openjdk.org Wed Jan 31 17:13:35 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 31 Jan 2024 17:13:35 GMT Subject: RFR: 8323801: tag doesn't strikethrough the text Message-ID: When `` tag is used inside ``, the `line-through` style is lost, and the text is rendered with `underline` only. However, if `` is used, the text is rendered with both `underline` and `line-through` styles. Both `` and `` should render the text the same way. ------------- Commit messages: - 8323801: Test case for vs - 8323801: Handle as Changes: https://git.openjdk.org/jdk/pull/17659/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17659&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323801 Stats: 127 lines in 2 files changed: 117 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/17659.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17659/head:pull/17659 PR: https://git.openjdk.org/jdk/pull/17659 From aivanov at openjdk.org Wed Jan 31 17:30:06 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 31 Jan 2024 17:30:06 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI [v6] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 05:39:11 GMT, Prasanta Sadhukhan wrote: >> When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak. >> When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. >> Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500) >> >> FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Optimise test Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java line 3284: > 3282: if(tree != null) { > 3283: rendererPane.removeAll(); > 3284: // Only ever removed when UI changes, this is OK! The comment no longer applies?you remove all the components from `rendererPane` on the line above. test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 75: > 73: > 74: // Create a new JLabel every time > 75: public Component getTreeCellRendererComponent( Suggestion: // Create a new JLabel every time @Override public Component getTreeCellRendererComponent( test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java line 220: > 218: } > 219: } > 220: One blank line in the end of a file is enough. ------------- PR Review: https://git.openjdk.org/jdk/pull/17458#pullrequestreview-1854359018 PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1473178234 PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1473181636 PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1473189670 From aivanov at openjdk.org Wed Jan 31 17:30:06 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 31 Jan 2024 17:30:06 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI [v6] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 17:13:55 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Optimise test > > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java line 3284: > >> 3282: if(tree != null) { >> 3283: rendererPane.removeAll(); >> 3284: // Only ever removed when UI changes, this is OK! > > The comment no longer applies?you remove all the components from `rendererPane` on the line above. This is the only important thing that prevents me from approving this PR. The comment is misleading now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1473193899 From aivanov at openjdk.org Wed Jan 31 17:30:07 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 31 Jan 2024 17:30:07 GMT Subject: RFR: 6507038: Memory Leak in JTree / BasicTreeUI [v3] In-Reply-To: References: <1xfZ5RyTcjtAZ87SQYOMdNYYRnc76Fxr0m05vbktyZQ=.4e4e71a5-351f-4654-90e6-c21e2a199894@github.com> Message-ID: On Wed, 31 Jan 2024 05:35:44 GMT, Prasanta Sadhukhan wrote: >> It's simpler with `PhantomReference`. This type of reference does not allow getting its referent, and it's not needed in this case. When the referent of a reference is cleared by the GC, the reference is added into the associated reference queue. This is true for any type of `Reference`, but `PhantomReference` has to use a reference queue. >> >> Here's how to use them: https://github.com/aivanov-jdk/jdk/commit/b0da8b30fdcf03abffa663eb5ba42df1fe4a9971 >> >> I keep the references in a list. The size of the list is the number of live `JLabel` objects. On each iteration, I poll the reference queue and remove the _dead_ references from the list. >> >> https://github.com/openjdk/jdk/blob/b0da8b30fdcf03abffa663eb5ba42df1fe4a9971/test/jdk/javax/swing/plaf/basic/BasicTreeUI/TreeCellRendererLeakTest.java#L193-L201 >> >> If the number of removed references is zero, the test fails because objects are leaked. Otherwise, the test passes. This aligns with your latest changes. >> >> Your code also does the job. I'll approve it if you don't want to use `PhantomReference`. > > Thanks for your "reference" on PhantomReference..Although my testcode is doing same thing (which you acknowledged) no harm in trying new way (for me) for my future reference so have updated the test to use PhantomReference. Could you add me as contributor, please? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17458#discussion_r1473192053 From rmahajan at openjdk.org Wed Jan 31 17:39:09 2024 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Wed, 31 Jan 2024 17:39:09 GMT Subject: Integrated: 8320342: Use PassFailJFrame for TruncatedPopupMenuTest.java In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 21:49:12 GMT, Rajat Mahajan wrote: > Modified the test to use PassFailJFrame and open sourced it. > The test shows two windows, one for instructions and the other to perform testing on. > Tested locally and it works fine. This pull request has now been integrated. Changeset: 1f2922ad Author: Rajat Mahajan Committer: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/1f2922ad8526d378ee7b616e5423ce56f20340db Stats: 93 lines in 1 file changed: 93 ins; 0 del; 0 mod 8320342: Use PassFailJFrame for TruncatedPopupMenuTest.java Reviewed-by: honkar, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/17641 From honkar at openjdk.org Wed Jan 31 17:45:07 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 31 Jan 2024 17:45:07 GMT Subject: Integrated: JDK-8324238 : [macOS] java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails with the shape has not been applied msg In-Reply-To: <2X4lZKPcvcBCgjNBbezJGso48upOQIByUORAeXTOQuQ=.c7cf91b4-1b6b-4d31-95d7-04b2634f8eed@github.com> References: <2X4lZKPcvcBCgjNBbezJGso48upOQIByUORAeXTOQuQ=.c7cf91b4-1b6b-4d31-95d7-04b2634f8eed@github.com> Message-ID: <8ncANELtlyUpKUAqsDFCgIgWYte2_YPJ_CU9aisNKT4=.cfbc97d4-16e5-4338-a645-12940ec8ffb5@github.com> On Thu, 25 Jan 2024 01:03:28 GMT, Harshitha Onkar wrote: > ShapeNotSetSometimes.java fails on macOS 11 on a random iteration of `colorCheck()` as shown below. The `colorCheck()` is repeated for about 50 times in the test. It is observed to pass on previous attempts and fail on a random attempt such as Attempt# 29 shown here. > > Here the point (150, 20) is well in the green area hence the slight color diff picked up by `robot.getPixelColor()` is not due to sampling of color at the edge (which sometimes causes robot to pick up slightly different color). > > > Attempt 29 > Checking 150, 20, java.awt.Color[r=0,g=255,b=1] should be java.awt.Color[r=0,g=255,b=0] > > > Due to the above, I have kept the color sampling points at the same location as earlier and made the following changes to the test: > > - Moved the frame to the center of the screen. > - Instead of comparing exact RGB values, used `colorCompare()` which allows color tolerance of 2 per color component to accommodate slight variations when comparing actual vs expected colors. > > > > Attempt 27 > Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] > Checking 150, 20, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 280, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 150, 250, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 20, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 62, 62, java.awt.Color[r=0,g=243,b=0] should not be java.awt.Color[r=255,g=255,b=255] > Checking 240, 185, java.awt.Color[r=0,g=229,b=0] should not be java.awt.Color[r=255,g=255,b=255] > Attempt 28 > Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] > Checking 150, 20, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 280, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 150, 250, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 20, 120, java.awt.Color[r=0,g=255,b=0] should be java.awt.Color[r=0,g=255,b=0] > Checking 62, 62, java.awt.Color[r=0,g=241,b=0] should not be java.awt.Color[r=255,g=255,b=255] > Checking 240, 185, java.awt.Color[r=0,g=227,b=0] should not be java.awt.Color[r=255,g=255,b=255] > Attempt 29 > Checking 150, 130, java.awt.Color[r=255,g=255,b=255] should be java.awt.Color[r=255,g=255,b=255] > Checking 150, 20, java.awt.Color[r=0,g=255,b=1] should be java.awt.Color[r=0,g=255,b=0] > ----------System.er... This pull request has now been integrated. Changeset: 62c9530c Author: Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/62c9530c056dbaaf65be0f43295af3d225326a4c Stats: 38 lines in 1 file changed: 24 ins; 4 del; 10 mod 8324238: [macOS] java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails with the shape has not been applied msg Reviewed-by: azvegint, dnguyen ------------- PR: https://git.openjdk.org/jdk/pull/17563 From achung at openjdk.org Wed Jan 31 21:42:04 2024 From: achung at openjdk.org (Alisen Chung) Date: Wed, 31 Jan 2024 21:42:04 GMT Subject: RFR: 8320676 : Manual printer tests have no Pass/Fail buttons, instructions close [v2] In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 06:30:00 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> >> Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured. >> >> Please review and let me know your suggestions. >> >> Regards, >> Renjith > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Suggestions integrated test/jdk/java/awt/print/PageFormat/PageSetupDialog.java line 48: > 46: * @key printer > 47: * @summary Page setup dialog settings > 48: * @library /java/awt/regtesthelpers i think both library lines can also be put on the same line test/jdk/java/awt/print/PageFormat/PageSetupDialog.java line 50: > 48: * @library /java/awt/regtesthelpers > 49: * @library /test/lib > 50: * @build PassFailJFrame same with build test/jdk/java/awt/print/PrinterJob/Cancel/PrinterJobCancel.java line 40: > 38: * @key printer > 39: * @summary PrinterJob not cancelled when PrinterJob.cancel() is used > 40: * @library /java/awt/regtesthelpers same lines for library and build ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17607#discussion_r1473495064 PR Review Comment: https://git.openjdk.org/jdk/pull/17607#discussion_r1473495547 PR Review Comment: https://git.openjdk.org/jdk/pull/17607#discussion_r1473497827 From achung at openjdk.org Wed Jan 31 21:56:02 2024 From: achung at openjdk.org (Alisen Chung) Date: Wed, 31 Jan 2024 21:56:02 GMT Subject: RFR: 8324807 : Manual printer tests have no Pass/Fail buttons, instructions close set 2 [v2] In-Reply-To: <3dRlBPCn8DVfrzQdoOPGwruNAWi9xtrIP6MFRc7XrJI=.cf9a3846-ee6d-40e2-a8e1-f63107b47ca8@github.com> References: <3dRlBPCn8DVfrzQdoOPGwruNAWi9xtrIP6MFRc7XrJI=.cf9a3846-ee6d-40e2-a8e1-f63107b47ca8@github.com> Message-ID: On Tue, 30 Jan 2024 07:02:36 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> >> Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured. >> >> Please review and let me know your suggestions. >> >> Regards, >> Renjith > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Capitalized static final variables test/jdk/java/awt/print/PrinterJob/Collate2DPrintingTest.java line 53: > 51: * @summary Collation should work. > 52: * @key printer > 53: * @library /java/awt/regtesthelpers same line on library test/jdk/java/awt/print/PrinterJob/DrawStringMethods.java line 70: > 68: .build(); > 69: > 70: PrinterJob pjob = PrinterJob.getPrinterJob(); i think this could be moved into a helper function and called by passFailJFrame builder via .testui(DrawStringMethods::helperFunction) test/jdk/java/awt/print/PrinterJob/InvalidPage.java line 73: > 71: pJob.print(); > 72: } > 73: } catch (PrinterException pe) { should this exception just be propagated into main? test/jdk/java/awt/print/PrinterJob/JobName/PrinterJobName.java line 62: > 60: .build(); > 61: > 62: PrinterJob job = PrinterJob.getPrinterJob(); this can be moved into helper function ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17608#discussion_r1473498972 PR Review Comment: https://git.openjdk.org/jdk/pull/17608#discussion_r1473511039 PR Review Comment: https://git.openjdk.org/jdk/pull/17608#discussion_r1473512904 PR Review Comment: https://git.openjdk.org/jdk/pull/17608#discussion_r1473513204 From achung at openjdk.org Wed Jan 31 22:02:07 2024 From: achung at openjdk.org (Alisen Chung) Date: Wed, 31 Jan 2024 22:02:07 GMT Subject: RFR: 8324808 : Manual printer tests have no Pass/Fail buttons, instructions close set 3 [v2] In-Reply-To: References: Message-ID: <__upDL04oJsLJv8CWRb7ibgme5lTpQpM9Grh1SeTc6Q=.53304c9e-40a8-410b-89f0-8cf5febbcce2@github.com> On Tue, 30 Jan 2024 09:17:46 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> >> Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured. >> >> Please review and let me know your suggestions. >> >> Regards, >> Renjith > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Capitalized static final variables test/jdk/java/awt/print/PrinterJob/PageDlgPrnButton.java line 38: > 36: * @bug 4956397 > 37: * @key printer > 38: * @library /java/awt/regtesthelpers library lines on same line test/jdk/java/awt/print/PrinterJob/PageDlgPrnButton.java line 63: > 61: > 62: new PageDlgPrnButton() ; > 63: passFailJFrame.awaitAndCheck(); simplifiable with PassFailJFrame.builder() .instructions(INSTRUCTIONS) .rows((int) INSTRUCTIONS.lines().count() + 1) .columns(45) .build() .awaitAndCheck(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17609#discussion_r1473513477 PR Review Comment: https://git.openjdk.org/jdk/pull/17609#discussion_r1473517506 From honkar at openjdk.org Wed Jan 31 22:52:01 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 31 Jan 2024 22:52:01 GMT Subject: RFR: 8323801: tag doesn't strikethrough the text In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 17:08:58 GMT, Alexey Ivanov wrote: > When `` tag is used inside ``, the `line-through` style is lost, and the text is rendered with `underline` only. However, if `` is used, the text is rendered with both `underline` and `line-through` styles. > > Both `` and `` should render the text the same way. Changes looks good. The `` tag works as expected as in the case of standard HTML with the fix. ------------- Marked as reviewed by honkar (Committer). PR Review: https://git.openjdk.org/jdk/pull/17659#pullrequestreview-1855024948 From honkar at openjdk.org Wed Jan 31 23:11:01 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 31 Jan 2024 23:11:01 GMT Subject: RFR: 8320676 : Manual printer tests have no Pass/Fail buttons, instructions close [v2] In-Reply-To: <9COHj3H4UD50eCr3kefzsCJZ2KNKhuynf9RQpv496yE=.e1ba80e0-1396-4af7-a26e-c0af9ab16e40@github.com> References: <9COHj3H4UD50eCr3kefzsCJZ2KNKhuynf9RQpv496yE=.e1ba80e0-1396-4af7-a26e-c0af9ab16e40@github.com> Message-ID: On Tue, 30 Jan 2024 07:58:12 GMT, Renjith Kannath Pariyangad wrote: >> test/jdk/java/awt/print/PrinterJob/ValidatePage/ValidatePage.java line 263: >> >>> 261: ta.setEditable(false); >>> 262: add(ta); >>> 263: setSize(500, 650); >> >> Set paper and Print options are not visible with current frame size. >> >> Suggestion: >> >> setSize(680, 500); > > Updating the size impacting layouts, its visible in my system. With the present frame size and layout settings, Set Paper" and "Print" options are not visible. ![image](https://github.com/openjdk/jdk/assets/95945681/b1bf6d28-858e-4b32-aec4-dd24dfdf7dc0) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17607#discussion_r1473592715