From prr at openjdk.org Tue Nov 1 03:08:23 2022 From: prr at openjdk.org (Phil Race) Date: Tue, 1 Nov 2022 03:08:23 GMT Subject: RFR: 8295737: macOS: Print content cut off when width > height with portrait orientation In-Reply-To: References: Message-ID: <-4hiGMpvdAYH9aGXPldPg1ndD3fTYYYyRwDD_3VF2hQ=.72ac6255-0b0a-48d3-b796-d9030c935ae4@github.com> On Fri, 21 Oct 2022 08:42:12 GMT, Alexander Scherbatiy wrote: > A printed content is truncated on macOS if the content paper size width larger than height with portrait orientation or width is less than height with landscape orientation. > > To reproduce the issue run the [CutOffImage](https://bugs.openjdk.org/secure/attachment/101145/CutOffImage.java) sample on MacOS. > > Four rectangles are printed: > 1. size 300x100, portrait orientation > 2. size 300x100, landscape orientation > 3. size 100x300, portrait orientation > 4. size 100x300, landscape orientation > > The first and fourth rectangles are truncated: [cut off content](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf) > > The reason is that NSPrintInfo class does not allow to set paper size and orientation independently. > Setting paper size width large than height changes NSPrintInfo orientation to landscape. > Setting paper size width less than height changes NSPrintInfo orientation to portrait. > Updating NSPrintInfo orientation from landscape to portrait or from portrait to landscape swaps NSPrintInfo paper width and height. > > The Cocoa code that shows NSPrintInfo behavior: > > #import > > int main() > { > NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; > NSApp = [NSApplication sharedApplication]; > > #ifdef __MAC_10_9 // code for SDK 10.9 or newer > #define NS_PORTRAIT NSPaperOrientationPortrait > #define NS_LANDSCAPE NSPaperOrientationLandscape > #else // code for SDK 10.8 or older > #define NS_PORTRAIT NSPortraitOrientation > #define NS_LANDSCAPE NSLandscapeOrientation > #endif > > printf("NS_PORTRAIT: %d\n", NS_PORTRAIT); > printf("NS_LANDSCAPE: %d\n", NS_LANDSCAPE); > > printf("create default print info\n"); > NSPrintInfo* defaultPrintInfo = [[NSPrintInfo sharedPrintInfo] copy]; > NSSize size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > printf("call setUpPrintOperationDefaultValues\n"); > [defaultPrintInfo setUpPrintOperationDefaultValues]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > double w = 300.0; > double h = 100.0; > printf("set size: [%f, %f]\n", w, h); > [defaultPrintInfo setPaperSize:NSMakeSize(w, h)]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > printf("Set NS_PORTRAIT orientation\n"); > [defaultPrintInfo setOrientation: NS_PORTRAIT]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > [NSApp run]; > > [NSApp release]; > [pool release]; > return(EXIT_SUCCESS); > } > > > On macOS Mojave 10.14.5 it prints: > > > NS_PORTRAIT: 0 > NS_LANDSCAPE: 1 > create default print info > orientation: 0, paper size: [612.000000, 792.000000] > call setUpPrintOperationDefaultValues > orientation: 0, paper size: [612.000000, 792.000000] > set size: [300.000000, 100.000000] > orientation: 1, paper size: [300.000000, 100.000000] // orientation flip > Set NS_PORTRAIT orientation > orientation: 0, paper size: [100.000000, 300.000000] // size flip > ``` > > There are four possible cases for printing a rectangle with different size and orientation: > 1. Input: paper size: (w > h), orientation portrait > [dstPrintInfo setPaperSize: NSMakeSize(w, h)] // size: (w, h), orientation: landscape > [dstPrintInfo setOrientation: NS_PORTRAIT] // size: (h, w), orientation: portrait > Note: width and height are swapped > 2. Input: paper size: (w > h), orientation landscape > [dstPrintInfo setPaperSize: NSMakeSize(h, w)] // size: (h, w), orientation: portrait > [dstPrintInfo setOrientation: NS_LANDSCAPE] // size: (w, h), orientation: landscape > 3. Input: paper size: (w < h), orientation portrait > [dstPrintInfo setPaperSize: NSMakeSize(w, h)] // size: (w, h), orientation: portrait > [dstPrintInfo setOrientation: NS_PORTRAIT] // size: (w, h), orientation: portrait > 4. Input: paper size: (w < h), orientation landscape > [dstPrintInfo setPaperSize: NSMakeSize(h, w)] // size: (h, w), orientation: landscape > [dstPrintInfo setOrientation: NS_LANDSCAPE] // size: (h, w), orientation: landscape > Note: width and height are swapped > > Only for cases 1 and 4 the final width and height are swapped. > The proposed fix enlarges height for cases 1 and 4 to not cut the printed rectangle. > > It is not full fix which draws rectangles for cases 1 and 4 in the requested size. > Setting requested size leads that subsequent orientation flips width and height. > The fix only enlarges the truncated area in height direction. The enlarged area in width is preserved as before the fix. > > Printed rectangles before and after the fix: > 1. size 300x100, portrait orientation: [before-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101157/before-fix-1.pdf), [after-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101162/after-fix-1.pdf) > 2. size 300x100, landscape orientation: [before-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101156/before-fix-2.pdf), [after-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101161/after-fix-2.pdf) > 3. size 100x300, portrait orientation: [before-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101155/before-fix-3.pdf), [after-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101160/after-fix-3.pdf) > 4. size 100x300, landscape orientation: [before-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101154/before-fix-4.pdf), [after-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101159/after-fix-4.pdf) > > All four rectangles: [before-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf), [after-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101158/after-fix-all.pdf) The analysis of the problem sounds fine but then it all gets confusing to me when I come to the fix. So first you capture the intended orientation in the switch but do not set it to the printer context. And I am lost as to why you do this NSPaperOrientation orientation = [dstPrintInfo orientation]; but promptly over-write the result in the switch statement. Then we get to this code :- NSSize size = [dstPrintInfo paperSize]; // Enlarge height only for cases 1 and 4. if ([dstPrintInfo orientation] == NS_LANDSCAPE && size.width > size.height) { size.height = size.width + ((orientation == NS_PORTRAIT) ? 1 : 0); [dstPrintInfo setPaperSize: size]; So case 1 is intended orientation of PORTRAIT but (1) You are only checking for landscape and (2) You are doing it on the current printer context, not what is intended. I am probably missing something but I'd like you to point out what it is. Also that last "+ .." condition is odd and un-explained. But then we get to the bigger question(s) Are all the settings in sync / agreement after this ? Is the clip correct ? What if the changed size now matches a different paper ? - The ability to set paper size at all here is a relic of when there was no way to find out the real paper sizes. Papers which don't exist should not be used. Continuous feed is probably the only reason for this and there we get into more complications. And why can't we handle all this by just applying an appropriate transform rather than hacking a non-existent size ? ------------- PR: https://git.openjdk.org/jdk/pull/10808 From alanb at openjdk.org Tue Nov 1 06:52:40 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 1 Nov 2022 06:52:40 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com> References: <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com> Message-ID: On Mon, 31 Oct 2022 22:00:01 GMT, Phil Race wrote: > You have jumped through some refactoring hoops to be able to apply the deprecation suppression to as little code as possible .. having made such changes, then why didn't you just make the recommended change instead ? > > Should I presume that the recommended route will have some nasty little incompatibilities we will need to be careful of first ? Converting these use-sites to URI will require care and working through issues on a case by case basis. This is because URI is strict and will reject bad input that URL may have handled differently. It may, for example, require changing the exception handling so that exceptions such as URISyntaxException (or IAE if code is changed to URI.create) maps to what is appropriate for code using URL. So slow and careful work for future PRs I think. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From dfuchs at openjdk.org Tue Nov 1 12:21:13 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 1 Nov 2022 12:21:13 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). >> >> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Remove check for .properties from jcheck" > > This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2. > - Change trailing space and tab in values to unicode encoding Changes to java (resp sun) .util.logging tests and javax.management tests look good to me. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.org/jdk/pull/10792 From dfuchs at openjdk.org Tue Nov 1 13:53:37 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 1 Nov 2022 13:53:37 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com> References: <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com> Message-ID: On Mon, 31 Oct 2022 22:00:01 GMT, Phil Race wrote: > Deprecate URL constructors. Developers are encouraged to use java.net.URI to parse or construct any URL. ... To construct a URL, using URI::toURL should be preferred. > > You have jumped through some refactoring hoops to be able to apply the deprecation suppression to as little code as possible .. having made such changes, then why didn't you just make the recommended change instead ? > > Should I presume that the recommended route will have some nasty little incompatibilities we will need to be careful of first ? Possibly yes. Using URI where it was not used before might cause some behavioral changes, that would need to be examined and possibly documented through separate CSRs. This is better handled on a case-by-case basis for each area affected. The changes as currently proposed will not lead to any behavioral difference. > > And what about Peter Firmstone's comment "We stopped using java.net.URI some years ago as it's obsolete.?" > > I can't reconcile that with the recommendation to use it .. URI implements RFC 2396 with some deviations, noted in its API documentation, which make it a crossbreed between RFC 2396 and RFC 3986. As Alan noted earlier, changing URI to strictly implement RFC 3986 is not a compatible move: it was attempted in JDK 6 but had to backed out quickly as it caused widespread breakage. But even if it doesn't implement the latest RFC strictly, it's still a much more modern API and implementation than java.net.URL. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From dfuchs at openjdk.org Tue Nov 1 13:53:40 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 1 Nov 2022 13:53:40 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: References: Message-ID: On Sat, 29 Oct 2022 14:14:22 GMT, Alan Bateman wrote: >> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml >> - Merge branch 'master' into deprecate-url-ctor-8294241 >> - Fix whitespace issues >> - 8294241 > > src/java.base/share/classes/java/net/URL.java line 885: > >> 883: >> 884: @SuppressWarnings("deprecation") >> 885: var result = new URL("jrt", host, port, file, null); > > The URL scheme for jrt does not have a port so we should look at that some time. Noted. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From dfuchs at openjdk.org Tue Nov 1 14:00:40 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 1 Nov 2022 14:00:40 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: References: Message-ID: On Sat, 29 Oct 2022 14:16:24 GMT, Alan Bateman wrote: >> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml >> - Merge branch 'master' into deprecate-url-ctor-8294241 >> - Fix whitespace issues >> - 8294241 > > src/java.base/share/classes/java/net/URL.java line 157: > >> 155: * The URL constructors are specified to throw >> 156: * {@link MalformedURLException} but the actual parsing/validation >> 157: * that are performed is implementation dependent. Some parsing/validation > > "the ... are performed" -> "the ... is performed". done > src/java.base/share/classes/java/net/URL.java line 852: > >> 850: * @since 20 >> 851: */ >> 852: public static URL of(URI uri, URLStreamHandler streamHandler) > > The parameter is named "handler" rather than "streamHandler" in constructors so we should probably keep it the same to avoid any confusion. done ------------- PR: https://git.openjdk.org/jdk/pull/10874 From dfuchs at openjdk.org Tue Nov 1 14:08:17 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 1 Nov 2022 14:08:17 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: References: Message-ID: On Sat, 29 Oct 2022 14:17:12 GMT, Alan Bateman wrote: >> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml >> - Merge branch 'master' into deprecate-url-ctor-8294241 >> - Fix whitespace issues >> - 8294241 > > src/java.base/share/classes/java/net/URL.java line 166: > >> 164: * The {@code java.net.URL} constructors are deprecated. >> 165: * Developers are encouraged to use {@link URI java.net.URI} to parse >> 166: * or construct any {@code URL}. In cases where an instance of {@code > > "any URL" -> "a URL" or "all URLs". done > src/java.base/share/classes/java/net/URL.java line 168: > >> 166: * or construct any {@code URL}. In cases where an instance of {@code >> 167: * java.net.URL} is needed to open a connection, {@link URI} can be used >> 168: * to construct or parse the URL string, possibly calling {@link > > I wonder if it might be clearer to say "url string", only to avoid anyone thinking they call URL::toString. I don't believe it would be syntactically correct to put it in all lower case since URL is an acronym. I could replace it with "URI string" instead but I'm not sure it would be better. What do you think? ------------- PR: https://git.openjdk.org/jdk/pull/10874 From dfuchs at openjdk.org Tue Nov 1 14:12:27 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 1 Nov 2022 14:12:27 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: References: Message-ID: On Sat, 29 Oct 2022 14:24:09 GMT, Alan Bateman wrote: >> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml >> - Merge branch 'master' into deprecate-url-ctor-8294241 >> - Fix whitespace issues >> - 8294241 > > src/java.base/share/classes/java/net/URL.java line 133: > >> 131: * specified. The optional fragment is not inherited. >> 132: * >> 133: *

Constructing instances of {@code URL}

> > Would it be better to move the anchor to line 164 (the line where it says that the URL constructors are deprecated? To be discussed: I actually wanted the deprecation link ( the link from `@deprecated` ) to lead here because I find that the whole section is relevant for developers who might want to decide whether to actually move away from using constructors, or be tempted to just use `@SuppressWarnings`. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From dfuchs at openjdk.org Tue Nov 1 14:26:09 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 1 Nov 2022 14:26:09 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: References: Message-ID: On Tue, 1 Nov 2022 14:10:01 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/java/net/URL.java line 133: >> >>> 131: * specified. The optional fragment is not inherited. >>> 132: * >>> 133: *

Constructing instances of {@code URL}

>> >> Would it be better to move the anchor to line 164 (the line where it says that the URL constructors are deprecated? > > To be discussed: I actually wanted the deprecation link ( the link from `@deprecated` ) to lead here because I find that the whole section is relevant for developers who might want to decide whether to actually move away from using constructors, or be tempted to just use `@SuppressWarnings`. Actually... Maybe I could move up the paragraph that says that URL constructors are deprecated up here, just after the <h2> title? Would that be better? ------------- PR: https://git.openjdk.org/jdk/pull/10874 From alanb at openjdk.org Tue Nov 1 14:51:20 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 1 Nov 2022 14:51:20 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: References: Message-ID: On Tue, 1 Nov 2022 14:22:18 GMT, Daniel Fuchs wrote: >> To be discussed: I actually wanted the deprecation link ( the link from `@deprecated` ) to lead here because I find that the whole section is relevant for developers who might want to decide whether to actually move away from using constructors, or be tempted to just use `@SuppressWarnings`. > > Actually... Maybe I could move up the paragraph that says that URL constructors are deprecated up here, just after the <h2> title? Would that be better? Try it, it might be better. I think the main thing is that link brings the reader to somewhere close to the deprecated message. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From alexsch at openjdk.org Tue Nov 1 15:38:34 2022 From: alexsch at openjdk.org (Alexander Scherbatiy) Date: Tue, 1 Nov 2022 15:38:34 GMT Subject: RFR: 8295737: macOS: Print content cut off when width > height with portrait orientation In-Reply-To: <-4hiGMpvdAYH9aGXPldPg1ndD3fTYYYyRwDD_3VF2hQ=.72ac6255-0b0a-48d3-b796-d9030c935ae4@github.com> References: <-4hiGMpvdAYH9aGXPldPg1ndD3fTYYYyRwDD_3VF2hQ=.72ac6255-0b0a-48d3-b796-d9030c935ae4@github.com> Message-ID: On Tue, 1 Nov 2022 03:06:16 GMT, Phil Race wrote: > The analysis of the problem sounds fine but then it all gets confusing to me when I come to the fix. > > So first you capture the intended orientation in the switch but do not set it to the printer context. The captured orientation is set to `dstPrintInfo` after code for enlarging the paper size in the end of the fix: [dstPrintInfo setOrientation:orientation]; > And I am lost as to why you do this NSPaperOrientation orientation = [dstPrintInfo orientation]; > but promptly over-write the result in the switch statement. Yes. The default value is not necessary for orientation in this case. I will update the code to `NSPaperOrientation orientation;` > Then we get to this code : NSSize size = [dstPrintInfo paperSize]; // Enlarge height only for cases 1 and 4. if ([dstPrintInfo orientation] == NS_LANDSCAPE && size.width > size.height) { size.height = size.width + ((orientation == NS_PORTRAIT) ? 1 : 0); [dstPrintInfo setPaperSize: size]; } > So case 1 is intended orientation of PORTRAIT but (1) You are only checking for landscape and The `dstPrintInfo` orientation value is checked after the paper size is applied but before the requested java orientation is set. The `dstPrintInfo` orientation at this point solely depends on the `dstPrintInfo` paper size. For the case 1 the `dstPrintInfo` orientation is landscape (width is greater than height). > (2) You are doing it on the current printer context, not what is intended. > I am probably missing something but I'd like you to point out what it is. This is the idea of the proposed fix. The fix checks if the `dstPrintInfo` page size is consistent with the requested orientation (for example, paper size with width > height does not work with portrait orientation) and enlarge the size for this case. > Also that last "+ .." condition is odd and un-explained. For the case 1. where width is greater than height and `dstPrintInfo` orientation is landscape (w>h) enlarging the paper size to [width x width] leaves the `dstPrintInfo` orientation as landscape and setting the requested portrait orientation leads that the rotated image is printed. Enlarging the paper size to [width x (width + 1)] updates the `dstPrintInfo` orientation to portrait which allows to print non rotated image after setting the requested portrait orientation. The idea of the "+" sign is to enlarge the paper size to be consistent with the requested orientation which is set after that. > But then we get to the bigger question(s) Are all the settings in sync / agreement after this ? Is the clip correct ? What if the changed size now matches a different paper ? - The ability to set paper size at all here is a relic of when there was no way to find out the real paper sizes. Papers which don't exist should not be used. Continuous feed is probably the only reason for this and there we get into more complications. The proposed fix suggests some intermediate solution between the right behavior (requested paper size and orientation are used) and the initial behavior where the default page size was always used (before JDK-8167102 and its dependent fixes). It is not clear for me how the right behavior can be implemented with NSPrintInfo class which does not allow to have both a paper size with width is greater than height and a portrait orientation at the same time. I agree that it would be better to find the solution which does not affect the requested paper size. To discuss the issue in general I prepared the pure Objective-C code which uses Cocoa NSPrint and NSPrintInfo classes to print an image and illustrates the issue with the paper size and orientation: [main.m](https://bugs.openjdk.org/secure/attachment/101275/main.m). The instruction to run the code on macOS is described in [JDK-8295737](https://bugs.openjdk.org/browse/JDK-8295737?focusedCommentId=14533578&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14533578). The code first sets the NSPrintInfo size to 300x100 and the orientation to portrait: [printInfo setPaperSize: imageSize]; [printInfo setOrientation: NS_PORTRAIT]; The output is: print info: set image size [300.000000, 100.000000] print info orientation: [1] NS_LANDSCAPE, size: [300.000000, 100.000000] print info: set orientation NS_PORTRAIT print info orientation: [0] NS_PORTRAIT, size: [100.000000, 300.000000] The papers size is changed from the requested 300x100 to 100x300. If the order of setting the paper size and orientation is manually reversed in the code: [printInfo setOrientation: NS_PORTRAIT]; [printInfo setPaperSize: imageSize]; The output is: print info: set orientation NS_PORTRAIT print info orientation: [0] NS_PORTRAIT, size: [612.000000, 792.000000] print info: set image size [300.000000, 100.000000] print info orientation: [1] NS_LANDSCAPE, size: [300.000000, 100.000000] The resulting orientation is landscape. What is not clear for me, what is the right way to set both 300x100 paper size and the portrait orientation in this case? > And why can't we handle all this by just applying an appropriate transform rather than hacking a non-existent size ? This is interesting idea. Could you give more details about it? What I see that the issue is not that a printed output is rotated in some way. The issue is that setting the paper size (width is greater than height) to NSPrintInfo first and the Portrait orientation after that leads to the swapped paper size in NSPrintInfo. So the image is correctly placed on the page but the paper size has been updated because it is not consistent with the requested orientation. Could transformations improve the situation? ------------- PR: https://git.openjdk.org/jdk/pull/10808 From aivanov at openjdk.org Tue Nov 1 15:40:28 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 1 Nov 2022 15:40:28 GMT Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0, Integer.MAX_VALUE) fails [v10] In-Reply-To: References: Message-ID: On Mon, 31 Oct 2022 08:59:31 GMT, Prasanta Sadhukhan wrote: >> DefaultListSelectionModel.removeIndexInterva accepts `int` value which allows it to take in Integer.MAX_VALUE theoratically but it does calculation with that value which can results in IOOBE. >> Fix is to make sure the calculation stays within bounds. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Review fix Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10409 From aivanov at openjdk.org Tue Nov 1 16:04:25 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 1 Nov 2022 16:04:25 GMT Subject: RFR: 8252075: Documentation error in LayoutManager2 interface [v5] In-Reply-To: References: Message-ID: On Mon, 31 Oct 2022 13:24:30 GMT, Renjith Kannath Pariyangad wrote: >> Updated the documentation with proper meaningful message for better understanding. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Updated documentation content which missed in previous check-in Looks good to me now. I believe this change doesn't require a CSR because it doesn't change the meaning. ------------- Marked as reviewed by aivanov (Reviewer). PR: https://git.openjdk.org/jdk/pull/10549 From dfuchs at openjdk.org Tue Nov 1 16:14:20 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 1 Nov 2022 16:14:20 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v3] In-Reply-To: References: Message-ID: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com> > Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. > > The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. > > This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. > > In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. > > In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. > > Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. > > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Integrated review feedback - Merge branch 'master' into deprecate-url-ctor-8294241 - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml - Merge branch 'master' into deprecate-url-ctor-8294241 - Fix whitespace issues - 8294241 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10874/files - new: https://git.openjdk.org/jdk/pull/10874/files/fd4ca287..f6b8a9f9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=01-02 Stats: 3893 lines in 203 files changed: 2469 ins; 611 del; 813 mod Patch: https://git.openjdk.org/jdk/pull/10874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10874/head:pull/10874 PR: https://git.openjdk.org/jdk/pull/10874 From prr at openjdk.org Tue Nov 1 16:14:21 2022 From: prr at openjdk.org (Phil Race) Date: Tue, 1 Nov 2022 16:14:21 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v3] In-Reply-To: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com> References: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com> Message-ID: On Tue, 1 Nov 2022 16:10:47 GMT, Daniel Fuchs wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. >> >> This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. >> >> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. >> >> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. >> >> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. >> >> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Integrated review feedback > - Merge branch 'master' into deprecate-url-ctor-8294241 > - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml > - Merge branch 'master' into deprecate-url-ctor-8294241 > - Fix whitespace issues > - 8294241 Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10874 From dfuchs at openjdk.org Tue Nov 1 16:14:22 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 1 Nov 2022 16:14:22 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: References: Message-ID: <2jUuJ4BHyWYygw4wAlZbgMBsxCyVgAOfhNFPl31yKLY=.5c5e0a58-e270-4e95-8cb6-d0c5f7a3bc23@github.com> On Tue, 1 Nov 2022 14:47:49 GMT, Alan Bateman wrote: >> Actually... Maybe I could move up the paragraph that says that URL constructors are deprecated up here, just after the <h2> title? Would that be better? > > Try it, it might be better. I think the main thing is that link brings the reader to somewhere close to the deprecated message. Done. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From aivanov at openjdk.org Tue Nov 1 16:31:52 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 1 Nov 2022 16:31:52 GMT Subject: RFR: 6201035: Document NPE for passing null insets to constructors and methods of several javax.swing.border.* classes [v5] In-Reply-To: References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com> Message-ID: <_d6PriCJT_JKqm8TXT-sy0xK5YWd35Kov9Xknx4p-kk=.5b683618-bed4-4454-93d1-d0f79ae91fc0@github.com> On Mon, 31 Oct 2022 07:48:38 GMT, Prasanta Sadhukhan wrote: >> The behavior of MatteBorder constructors taking Insets object as a parameter is undocumented. It would throw NPE if null object is passed to it, which should be documented in the spec. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Rectify javadoc of more border classes/methods `TitledBorder` is to be updates as well. I wonder why none of the classes uses `{@inheritDoc}` instead of copying the entire text without modification. And you don't want to use `{@inheritDoc}` either for the `@throws` clause without explaining why. src/java.desktop/share/classes/javax/swing/border/AbstractBorder.java line 87: > 85: * @param c the component for which this border insets value applies > 86: * @param insets the object to be reinitialized > 87: * @return the insets object Suggestion: * @return the {@code insets} object It makes sense to replace `` with `{@code}` as the `throws` clause uses the new syntax. src/java.desktop/share/classes/javax/swing/border/BevelBorder.java line 142: > 140: > 141: /** > 142: * Reinitialize the insets parameter with this Border's current Insets. To be consistent with the superclass: Suggestion: * Reinitializes the insets parameter with this Border's current Insets. I guess the entire javadoc can be inherited with {@inheritDoc}, it adds nothing to the text in `AbstractBorder`. src/java.desktop/share/classes/javax/swing/border/CompoundBorder.java line 137: > 135: > 136: /** > 137: * Reinitialize the insets parameter with this Border's current Insets. Suggestion: * Reinitializes the insets parameter with this Border's current Insets. The same: the verb at start of a javadoc is in third person singular. src/java.desktop/share/classes/javax/swing/border/EmptyBorder.java line 104: > 102: > 103: /** > 104: * Reinitialize the insets parameter with this Border's current Insets. Suggestion: * Reinitializes the insets parameter with this Border's current Insets. src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 210: > 208: /** > 209: * Reinitialize the insets parameter with this Border's current Insets. > 210: * Also add _?-s?_ ending to the verb in the line above. src/java.desktop/share/classes/javax/swing/border/LineBorder.java line 174: > 172: /** > 173: * Reinitialize the insets parameter with this Border's current Insets. > 174: * Also add _?-s?_ ending to the verb in the line above. src/java.desktop/share/classes/javax/swing/border/SoftBevelBorder.java line 152: > 150: > 151: /** > 152: * Reinitialize the insets parameter with this Border's current Insets. Suggestion: * Reinitializes the insets parameter with this Border's current Insets. ------------- Changes requested by aivanov (Reviewer). PR: https://git.openjdk.org/jdk/pull/10740 From aivanov at openjdk.org Tue Nov 1 16:42:33 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 1 Nov 2022 16:42:33 GMT Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v10] In-Reply-To: <_29_WvWhzoaKDCRsAplWwmgW4bd2xP0t_PLx8MOhM-Y=.70319c16-3b88-46e0-9024-ac4f768e1ebb@github.com> References: <_29_WvWhzoaKDCRsAplWwmgW4bd2xP0t_PLx8MOhM-Y=.70319c16-3b88-46e0-9024-ac4f768e1ebb@github.com> Message-ID: On Tue, 27 Sep 2022 03:17:26 GMT, ScientificWare wrote: >> This is referenced in Java Bug Database as >> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776) >> >> This is tracked in JBS as >> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776) >> >> Adds the 4 and 8 digits color hex notations to CSS.java, as described in : >> CSS Color Module Level 4 >> W3C Candidate Recommendation Snapshot, 5 July 2022 >> [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation) >> >> Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13) > > ScientificWare has updated the pull request incrementally with one additional commit since the last revision: > > Corrects a value in a message. > > A message is added to the result in case of failure only. The updated code does not output the actual value. The tested color is #f12a instead of #f00a. No, bot, it's not the time to close it. @scientificware, I am sorry for my being silent. I'll get back to it as soon as I can. ------------- PR: https://git.openjdk.org/jdk/pull/10317 From aivanov at openjdk.org Tue Nov 1 16:50:42 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 1 Nov 2022 16:50:42 GMT Subject: RFR: 6257207: JTable.getDefaultEditor throws NullPointerException [v3] In-Reply-To: <-_EIXOFFPEZ5uuvK42SJ4cNn_kA7k7rr6YOi8AY1M3M=.63eac53f-7abe-4f9d-8ecd-dcf06aadc762@github.com> References: <-_EIXOFFPEZ5uuvK42SJ4cNn_kA7k7rr6YOi8AY1M3M=.63eac53f-7abe-4f9d-8ecd-dcf06aadc762@github.com> Message-ID: On Mon, 31 Oct 2022 09:14:23 GMT, Prasanta Sadhukhan wrote: >> If getDefaultEditor() is called before the JTable model is setup, it results in NPE. >> >> This is because when JTable sets its model, which ends up firing a table changed event. The testcase is listening for tableChanged events and querying the editor. But the editor isn't installed until after the model is set which results in NPE. >> Fix is to ensure initializeLocalVars() which initializes default editor is setup before JTable sets its model. >> >> No regression is observed in jtreg/jck testsuite with this change. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Remove extra line Changes requested by aivanov (Reviewer). test/jdk/javax/swing/JTable/JTableEditorNPE.java line 62: > 60: }); > 61: } finally { > 62: Thread.sleep(1000); Is the `sleep` required? If NPE is thrown, no UI appears at all; if NPE is not thrown, the UI may be shown but not required. Would it be enough to add the table to the frame and call `validate()`? test/jdk/javax/swing/JTable/JTableEditorNPE.java line 118: > 116: comp = renderer.getTableCellRendererComponent( > 117: this, // table > 118: getModel().getValueAt(row,column), // value Suggestion: getModel().getValueAt(row, column), // value ------------- PR: https://git.openjdk.org/jdk/pull/10871 From aivanov at openjdk.org Tue Nov 1 16:50:42 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 1 Nov 2022 16:50:42 GMT Subject: RFR: 6257207: JTable.getDefaultEditor throws NullPointerException [v2] In-Reply-To: References: Message-ID: On Mon, 31 Oct 2022 09:11:21 GMT, Prasanta Sadhukhan wrote: >> If getDefaultEditor() is called before the JTable model is setup, it results in NPE. >> >> This is because when JTable sets its model, which ends up firing a table changed event. The testcase is listening for tableChanged events and querying the editor. But the editor isn't installed until after the model is set which results in NPE. >> Fix is to ensure initializeLocalVars() which initializes default editor is setup before JTable sets its model. >> >> No regression is observed in jtreg/jck testsuite with this change. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Review fix test/jdk/javax/swing/JTable/JTableEditorNPE.java line 83: > 81: resizeAll(); > 82: } > 83: else { Suggestion: } else { ------------- PR: https://git.openjdk.org/jdk/pull/10871 From honkar at openjdk.org Tue Nov 1 17:19:26 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 1 Nov 2022 17:19:26 GMT Subject: RFR: 8282958: Rendering issues of borders, TextFields on Windows High-DPI systems [v2] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 16:00:10 GMT, Rajat Mahajan wrote: >> This fix is based on a similar approach as described here https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648. >> We rescale the line border to render the Textfield border correctly, so that all sides of the Textfield border are of same thickness. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > Update test/jdk/javax/swing/border/LineBorder/ScaledLineBorderTest.java > > Co-authored-by: Alexey Ivanov Checked the saved images on paint.net, the border thickness is equal and uniform on 4 sides (no. of pixels painted) for different scales. Both tests look good. Copyright year needs to be updated for LineBorder. ------------- Changes requested by honkar (Author). PR: https://git.openjdk.org/jdk/pull/10681 From honkar at openjdk.org Tue Nov 1 17:25:30 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 1 Nov 2022 17:25:30 GMT Subject: RFR: 8282958: Rendering issues of borders, TextFields on Windows High-DPI systems [v2] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 16:00:10 GMT, Rajat Mahajan wrote: >> This fix is based on a similar approach as described here https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648. >> We rescale the line border to render the Textfield border correctly, so that all sides of the Textfield border are of same thickness. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > Update test/jdk/javax/swing/border/LineBorder/ScaledLineBorderTest.java > > Co-authored-by: Alexey Ivanov Marked as reviewed by honkar (Author). ------------- PR: https://git.openjdk.org/jdk/pull/10681 From duke at openjdk.org Tue Nov 1 17:43:03 2022 From: duke at openjdk.org (Rajat Mahajan) Date: Tue, 1 Nov 2022 17:43:03 GMT Subject: RFR: 8282958: Rendering issues of borders, TextFields on Windows High-DPI systems [v3] In-Reply-To: References: Message-ID: > This fix is based on a similar approach as described here https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648. > We rescale the line border to render the Textfield border correctly, so that all sides of the Textfield border are of same thickness. Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: updated copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10681/files - new: https://git.openjdk.org/jdk/pull/10681/files/0e8fb4e7..815b0d79 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10681&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10681&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10681.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10681/head:pull/10681 PR: https://git.openjdk.org/jdk/pull/10681 From kizune at openjdk.org Tue Nov 1 17:43:04 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 1 Nov 2022 17:43:04 GMT Subject: RFR: 8282958: Rendering issues of borders, TextFields on Windows High-DPI systems [v3] In-Reply-To: References: Message-ID: <373RGrgnOlAqOlEhnXtRX_uUtb_VsmwVvQrjw-PvIG0=.bf8dc45f-7214-494e-8ed3-2fe6e0a2b76e@github.com> On Tue, 1 Nov 2022 17:38:57 GMT, Rajat Mahajan wrote: >> This fix is based on a similar approach as described here https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648. >> We rescale the line border to render the Textfield border correctly, so that all sides of the Textfield border are of same thickness. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > updated copyright year Looks good to me. ------------- Marked as reviewed by kizune (Reviewer). PR: https://git.openjdk.org/jdk/pull/10681 From aivanov at openjdk.org Tue Nov 1 17:43:05 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 1 Nov 2022 17:43:05 GMT Subject: RFR: 8282958: Rendering issues of borders, TextFields on Windows High-DPI systems [v3] In-Reply-To: References: Message-ID: On Tue, 1 Nov 2022 17:38:57 GMT, Rajat Mahajan wrote: >> This fix is based on a similar approach as described here https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648. >> We rescale the line border to render the Textfield border correctly, so that all sides of the Textfield border are of same thickness. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > updated copyright year Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10681 From prr at openjdk.org Tue Nov 1 17:53:24 2022 From: prr at openjdk.org (Phil Race) Date: Tue, 1 Nov 2022 17:53:24 GMT Subject: RFR: 8295737: macOS: Print content cut off when width > height with portrait orientation In-Reply-To: References: Message-ID: On Fri, 21 Oct 2022 08:42:12 GMT, Alexander Scherbatiy wrote: > A printed content is truncated on macOS if the content paper size width larger than height with portrait orientation or width is less than height with landscape orientation. > > To reproduce the issue run the [CutOffImage](https://bugs.openjdk.org/secure/attachment/101145/CutOffImage.java) sample on MacOS. > > Four rectangles are printed: > 1. size 300x100, portrait orientation > 2. size 300x100, landscape orientation > 3. size 100x300, portrait orientation > 4. size 100x300, landscape orientation > > The first and fourth rectangles are truncated: [cut off content](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf) > > The reason is that NSPrintInfo class does not allow to set paper size and orientation independently. > Setting paper size width large than height changes NSPrintInfo orientation to landscape. > Setting paper size width less than height changes NSPrintInfo orientation to portrait. > Updating NSPrintInfo orientation from landscape to portrait or from portrait to landscape swaps NSPrintInfo paper width and height. > > The Cocoa code that shows NSPrintInfo behavior: > > #import > > int main() > { > NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; > NSApp = [NSApplication sharedApplication]; > > #ifdef __MAC_10_9 // code for SDK 10.9 or newer > #define NS_PORTRAIT NSPaperOrientationPortrait > #define NS_LANDSCAPE NSPaperOrientationLandscape > #else // code for SDK 10.8 or older > #define NS_PORTRAIT NSPortraitOrientation > #define NS_LANDSCAPE NSLandscapeOrientation > #endif > > printf("NS_PORTRAIT: %d\n", NS_PORTRAIT); > printf("NS_LANDSCAPE: %d\n", NS_LANDSCAPE); > > printf("create default print info\n"); > NSPrintInfo* defaultPrintInfo = [[NSPrintInfo sharedPrintInfo] copy]; > NSSize size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > printf("call setUpPrintOperationDefaultValues\n"); > [defaultPrintInfo setUpPrintOperationDefaultValues]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > double w = 300.0; > double h = 100.0; > printf("set size: [%f, %f]\n", w, h); > [defaultPrintInfo setPaperSize:NSMakeSize(w, h)]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > printf("Set NS_PORTRAIT orientation\n"); > [defaultPrintInfo setOrientation: NS_PORTRAIT]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > [NSApp run]; > > [NSApp release]; > [pool release]; > return(EXIT_SUCCESS); > } > > > On macOS Mojave 10.14.5 it prints: > > > NS_PORTRAIT: 0 > NS_LANDSCAPE: 1 > create default print info > orientation: 0, paper size: [612.000000, 792.000000] > call setUpPrintOperationDefaultValues > orientation: 0, paper size: [612.000000, 792.000000] > set size: [300.000000, 100.000000] > orientation: 1, paper size: [300.000000, 100.000000] // orientation flip > Set NS_PORTRAIT orientation > orientation: 0, paper size: [100.000000, 300.000000] // size flip > ``` > > There are four possible cases for printing a rectangle with different size and orientation: > 1. Input: paper size: (w > h), orientation portrait > [dstPrintInfo setPaperSize: NSMakeSize(w, h)] // size: (w, h), orientation: landscape > [dstPrintInfo setOrientation: NS_PORTRAIT] // size: (h, w), orientation: portrait > Note: width and height are swapped > 2. Input: paper size: (w > h), orientation landscape > [dstPrintInfo setPaperSize: NSMakeSize(h, w)] // size: (h, w), orientation: portrait > [dstPrintInfo setOrientation: NS_LANDSCAPE] // size: (w, h), orientation: landscape > 3. Input: paper size: (w < h), orientation portrait > [dstPrintInfo setPaperSize: NSMakeSize(w, h)] // size: (w, h), orientation: portrait > [dstPrintInfo setOrientation: NS_PORTRAIT] // size: (w, h), orientation: portrait > 4. Input: paper size: (w < h), orientation landscape > [dstPrintInfo setPaperSize: NSMakeSize(h, w)] // size: (h, w), orientation: landscape > [dstPrintInfo setOrientation: NS_LANDSCAPE] // size: (h, w), orientation: landscape > Note: width and height are swapped > > Only for cases 1 and 4 the final width and height are swapped. > The proposed fix enlarges height for cases 1 and 4 to not cut the printed rectangle. > > It is not full fix which draws rectangles for cases 1 and 4 in the requested size. > Setting requested size leads that subsequent orientation flips width and height. > The fix only enlarges the truncated area in height direction. The enlarged area in width is preserved as before the fix. > > Printed rectangles before and after the fix: > 1. size 300x100, portrait orientation: [before-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101157/before-fix-1.pdf), [after-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101162/after-fix-1.pdf) > 2. size 300x100, landscape orientation: [before-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101156/before-fix-2.pdf), [after-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101161/after-fix-2.pdf) > 3. size 100x300, portrait orientation: [before-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101155/before-fix-3.pdf), [after-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101160/after-fix-3.pdf) > 4. size 100x300, landscape orientation: [before-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101154/before-fix-4.pdf), [after-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101159/after-fix-4.pdf) > > All four rectangles: [before-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf), [after-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101158/after-fix-all.pdf) The printer doesn't pull paper from a different physically oriented tray when you request landscape. Landscape is just portrait rotated by +/- 90 degrees. And vice versa. Ultimately a transform is being applied to rotate the rendering so rather than changing the width and height instead rotate by 90 degrees. I'd have to hunt it down but somewhere .. some case .. some platform in the printing code I recall we do this for cases where the platform doesn't support an orientation - REVERSE_LANDSCAPE. That might help a little but I think that may be in shared code .. hmm .. looks like macOS code doesn't attempt to support that mode at all. > // AppKit printing doesn't support REVERSE_LANDSCAPE. Radar 2960295. Something else that could be fixed via a transform I am not 100% sure it can still be done solely in macOS specific code, It may need to touch something in the macOS CPrint* java classes if the Java-level graphics transform is what would need to be adjusted. But it could perhaps be handled by specifying a transform on the PrinterView (JDK's subclass of NSView) I don't have any more specific pointer than that .. I'd have to go try it .. which isn't on my radar .. ------------- PR: https://git.openjdk.org/jdk/pull/10808 From kizune at openjdk.org Tue Nov 1 18:29:35 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 1 Nov 2022 18:29:35 GMT Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of JInternalFrame [v11] In-Reply-To: <1T21tMiVjVBLFw5lOCScck46i9MSse56klmgbWRrsks=.de04fd0d-c624-4aa9-9277-6e8be6877a45@github.com> References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com> <1T21tMiVjVBLFw5lOCScck46i9MSse56klmgbWRrsks=.de04fd0d-c624-4aa9-9277-6e8be6877a45@github.com> Message-ID: On Fri, 21 Oct 2022 22:21:09 GMT, Harshitha Onkar wrote: >> JInternalFrame background color seems to overflow into the border region. This issue is more prominently seen on Windows - Metal LAF (with fractional scaling, as shown below). The primary reason is border scaling issue as observed in - [JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614) >> >> The fix involves a similar approach as described here https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648. The test checks the midpoint and corners of borders to check if the internal frame's background color is located out of JInternalFrame. >> >> ![image](https://user-images.githubusercontent.com/95945681/190233555-a7e00f2c-9003-4c11-84fb-207957838c2f.png) > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > new x,y and translate component added to fix pixel painting issue Marked as reviewed by kizune (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10274 From duke at openjdk.org Tue Nov 1 18:40:48 2022 From: duke at openjdk.org (Rajat Mahajan) Date: Tue, 1 Nov 2022 18:40:48 GMT Subject: Integrated: 8282958: Rendering issues of borders, TextFields on Windows High-DPI systems In-Reply-To: References: Message-ID: On Wed, 12 Oct 2022 16:41:52 GMT, Rajat Mahajan wrote: > This fix is based on a similar approach as described here https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648. > We rescale the line border to render the Textfield border correctly, so that all sides of the Textfield border are of same thickness. This pull request has now been integrated. Changeset: 9911405e Author: Rajat Mahajan Committer: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/9911405e543dbe07767808bad88534abbcc03c5a Stats: 664 lines in 3 files changed: 658 ins; 1 del; 5 mod 8282958: Rendering issues of borders, TextFields on Windows High-DPI systems Co-authored-by: Alexey Ivanov Reviewed-by: aivanov, honkar, kizune ------------- PR: https://git.openjdk.org/jdk/pull/10681 From duke at openjdk.org Tue Nov 1 20:10:00 2022 From: duke at openjdk.org (ScientificWare) Date: Tue, 1 Nov 2022 20:10:00 GMT Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v10] In-Reply-To: References: <_29_WvWhzoaKDCRsAplWwmgW4bd2xP0t_PLx8MOhM-Y=.70319c16-3b88-46e0-9024-ac4f768e1ebb@github.com> Message-ID: <4ZJ-n3DpKFBi3ysPAkMmLUVbej5KXp70531R41upZ5s=.f02cd270-027a-499d-bbe6-ab64256d07ec@github.com> On Tue, 1 Nov 2022 16:38:34 GMT, Alexey Ivanov wrote: >> ScientificWare has updated the pull request incrementally with one additional commit since the last revision: >> >> Corrects a value in a message. >> >> A message is added to the result in case of failure only. The updated code does not output the actual value. The tested color is #f12a instead of #f00a. > > No, bot, it's not the time to close it. > > @scientificware, I am sorry for my being silent. I'll get back to it as soon as I can. @aivanov-jdk At your convenience, - I updated my last comment. - Concurrently, I'm trying to finalize https://bugs.openjdk.org/browse/JDK-8294090 linked to https://github.com/openjdk/jdk/pull/9825#issuecomment-1268546792. ------------- PR: https://git.openjdk.org/jdk/pull/10317 From prr at openjdk.org Tue Nov 1 21:23:29 2022 From: prr at openjdk.org (Phil Race) Date: Tue, 1 Nov 2022 21:23:29 GMT Subject: RFR: 8294488: Delete KCMS transforms wrappers In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 03:12:55 GMT, Sergey Bylokhov wrote: > This is a request to cleanup the shared code for the colors conversions. That code still uses some wrappers which can be simplified and/or deleted after KCMS removal. For example, each conversion from one color space to another creates 3 wrappers - for the first color profile, the second color profile, and one to combine the first two. But for the lcms library we only need the list of color profiles and rendering intent -> only one transform object can be used. > > The new constructor for the LCMSTransform is [added](https://github.com/openjdk/jdk/pull/10459/files#diff-7448ea8346eb08c6ec1a518e3c3399d7d078a514c07956ee7e8e2b5be3d082e1R77) and now used everywhere: > `LCMSTransform(int renderingIntent, ICC_Profile... profiles)` > It will wrap the `cmsCreateMultiprofileTransform` [function ](https://github.com/openjdk/jdk/pull/10459/files#diff-eed6ddb15e9c5bdab9fc3b3930d5d959966165d9622ddd293e8572489adea98bR202) in LCMS library: > > I tried to preserve the current behavior, and as a result, two "workarounds" are used for the next bugs. > * [JDK-8216369](https://bugs.openjdk.org/browse/JDK-8216369): after the cleanup it became obvious that we use a hardcoded value for the first rendering [intent](https://github.com/openjdk/jdk/pull/10459/files#diff-e3d6eea060882cab00827c00e1a83b0e0a5b2a31fa9a9aa2122841bbd57c4a6dR473). There is a code to fetch the intent from the color profile but I postponed use it for now because some of our built-in profiles use different default intents. > * [JDK-8272860](https://bugs.openjdk.org/browse/JDK-8272860): the old code always fetched some information from the color profile header as result we cache the headers for any profiles we used. This cache workaround the JDK-8272860 while the direct access to the profile via LCMS library could fail. The new code intentionally caches the [header](https://github.com/openjdk/jdk/pull/10459/files#diff-7448ea8346eb08c6ec1a518e3c3399d7d078a514c07956ee7e8e2b5be3d082e1R91). > > Notes: > * The old wrappers used a rendering intent for each intermediate transform, the LCMS use only one intent > * The old wrappers could throw the cmm exception if the rendering intent was not supported. The LCMS ignores unsupported intents and uses some [default](https://github.com/LuaDist/lcms/blob/master/doc/TUTORIAL.TXT#L1094) > * The old wrappers had a way to specify the input and output profiles, the LCMS library uses the first profile as input and the last profile as output. Those parameters are [removed](https://github.com/openjdk/jdk/pull/10459/files#diff-81b49f067b32296497e9e727bda25efe0b7f84fb2c05645eb6b272bfc32469f1L38) > * If at some point the new CMS library will be added it will be easy to integrate it using XXCMS plugin, instead of using some specific library logic in the shared code I've prepared a closed PR which fixes the closed test to match this change It needs to be pushed at the same time but it has yet to be reviewed. Once it is approved we can co-ordinate pushing both at the same time. ------------- PR: https://git.openjdk.org/jdk/pull/10459 From serb at openjdk.org Tue Nov 1 22:37:27 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 1 Nov 2022 22:37:27 GMT Subject: RFR: 8294488: Delete KCMS transforms wrappers In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 03:12:55 GMT, Sergey Bylokhov wrote: > This is a request to cleanup the shared code for the colors conversions. That code still uses some wrappers which can be simplified and/or deleted after KCMS removal. For example, each conversion from one color space to another creates 3 wrappers - for the first color profile, the second color profile, and one to combine the first two. But for the lcms library we only need the list of color profiles and rendering intent -> only one transform object can be used. > > The new constructor for the LCMSTransform is [added](https://github.com/openjdk/jdk/pull/10459/files#diff-7448ea8346eb08c6ec1a518e3c3399d7d078a514c07956ee7e8e2b5be3d082e1R77) and now used everywhere: > `LCMSTransform(int renderingIntent, ICC_Profile... profiles)` > It will wrap the `cmsCreateMultiprofileTransform` [function ](https://github.com/openjdk/jdk/pull/10459/files#diff-eed6ddb15e9c5bdab9fc3b3930d5d959966165d9622ddd293e8572489adea98bR202) in LCMS library: > > I tried to preserve the current behavior, and as a result, two "workarounds" are used for the next bugs. > * [JDK-8216369](https://bugs.openjdk.org/browse/JDK-8216369): after the cleanup it became obvious that we use a hardcoded value for the first rendering [intent](https://github.com/openjdk/jdk/pull/10459/files#diff-e3d6eea060882cab00827c00e1a83b0e0a5b2a31fa9a9aa2122841bbd57c4a6dR473). There is a code to fetch the intent from the color profile but I postponed use it for now because some of our built-in profiles use different default intents. > * [JDK-8272860](https://bugs.openjdk.org/browse/JDK-8272860): the old code always fetched some information from the color profile header as result we cache the headers for any profiles we used. This cache workaround the JDK-8272860 while the direct access to the profile via LCMS library could fail. The new code intentionally caches the [header](https://github.com/openjdk/jdk/pull/10459/files#diff-7448ea8346eb08c6ec1a518e3c3399d7d078a514c07956ee7e8e2b5be3d082e1R91). > > Notes: > * The old wrappers used a rendering intent for each intermediate transform, the LCMS use only one intent > * The old wrappers could throw the cmm exception if the rendering intent was not supported. The LCMS ignores unsupported intents and uses some [default](https://github.com/LuaDist/lcms/blob/master/doc/TUTORIAL.TXT#L1094) > * The old wrappers had a way to specify the input and output profiles, the LCMS library uses the first profile as input and the last profile as output. Those parameters are [removed](https://github.com/openjdk/jdk/pull/10459/files#diff-81b49f067b32296497e9e727bda25efe0b7f84fb2c05645eb6b272bfc32469f1L38) > * If at some point the new CMS library will be added it will be easy to integrate it using XXCMS plugin, instead of using some specific library logic in the shared code Thank you! I'll do a `/integrate defer` to make a [trick](https://github.com/openjdk/jdk/pull/10757#issuecomment-1290762995). ------------- PR: https://git.openjdk.org/jdk/pull/10459 From duke at openjdk.org Wed Nov 2 04:04:14 2022 From: duke at openjdk.org (ravi gupta) Date: Wed, 2 Nov 2022 04:04:14 GMT Subject: RFR: 8295774 : Write a test to verify that List Item selection events. [v2] In-Reply-To: References: Message-ID: > This testcase verify that List Item selection via mouse/keys generates ItemEvent/ActionEvent appropriately. > > a. Single click on the list generate ItemEvent and double click on item generates ActionEvent. > b. UP/DOWN keys on the list generate ItemEvent and enter key on item generates ActionEvent. > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. ravi gupta has updated the pull request incrementally with one additional commit since the last revision: 8295774 : Write a test to verify that List Item selection events. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10899/files - new: https://git.openjdk.org/jdk/pull/10899/files/c4cf5168..984ab23f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10899&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10899&range=00-01 Stats: 30 lines in 1 file changed: 3 ins; 19 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/10899.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10899/head:pull/10899 PR: https://git.openjdk.org/jdk/pull/10899 From duke at openjdk.org Wed Nov 2 04:16:35 2022 From: duke at openjdk.org (ravi gupta) Date: Wed, 2 Nov 2022 04:16:35 GMT Subject: RFR: 8295774 : Write a test to verify that List Item selection events. [v2] In-Reply-To: References: Message-ID: On Sun, 30 Oct 2022 12:57:38 GMT, Alexey Ivanov wrote: >> ravi gupta has updated the pull request incrementally with one additional commit since the last revision: >> >> 8295774 : Write a test to verify that List Item selection events. > > test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 50: > >> 48: private static final int waitDelay = 1000; >> 49: >> 50: private volatile static Frame frame; > > `frame` is used only from the EDT, thus it doesn't need to be `volatile`. Resolved . > test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 54: > >> 52: private volatile static boolean actionPerformed = false; >> 53: private volatile static boolean itemStateChanged = false; >> 54: private volatile static Robot robot; > > `robot` is used from the main thread only, therefore it doesn't need to be `volatile` either. Resolved. > test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 55: > >> 53: private volatile static boolean itemStateChanged = false; >> 54: private volatile static Robot robot; >> 55: private volatile static CountDownLatch latch; > > Should rather be `final` than `volatile`. resolved . CountDownLatch removed from code. > test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 100: > >> 98: Point listAt = list.getLocationOnScreen(); >> 99: // get bounds of button >> 100: Rectangle bounds = list.getBounds(); > > What button? Better remove the comment. > > Since you need only the size, use [`getSize()`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Component.html#getSize()) Resolved now code modified as below Dimension listDimension = list.getSize(); > test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 111: > >> 109: throw new RuntimeException( >> 110: "Fail: Timed out waiting for list to gain focus, test cannot proceed!!"); >> 111: } > > Since `list` is the only focusable component in the `frame`, it gets focus before `robot.waitForIdle()` returns. So, this along with `FocusListener` could be dropped. Resolved . FocusListener dropped. > test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 140: > >> 138: } >> 139: >> 140: robot.setAutoDelay(waitDelay); > > Why is delay increased here? This test verifies list section via mouse/keys events. For mouse events, robot.setAutoDelay(100) worked well. But for key events there were a few intermittent failures which cleared out with a higher delay via robot.setAutoDelay(1000) > test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 189: > >> 187: } >> 188: >> 189: private static void keyType(int key) throws Exception { > > Suggestion: > > private static void typeKey(int key) throws Exception { > > Method names usually start with verbs. Resolved . renamed as suggested ------------- PR: https://git.openjdk.org/jdk/pull/10899 From aturbanov at openjdk.org Wed Nov 2 07:31:37 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 2 Nov 2022 07:31:37 GMT Subject: RFR: 8289539: The color returned by CheckBox.interiorBackground is incorrect In-Reply-To: References: Message-ID: <1-S4nHbXeQWFScJq8FKmvjzrmF6LlNlf6buK4cq07oo=.0c16b209-0391-45d9-b597-3840a2bf9623@github.com> On Thu, 22 Sep 2022 06:59:59 GMT, Tejesh R wrote: > The color returned for `InteriorBackground` property is the default color used for only _WindowsClassicLookAndFeel_. For _WindowsLookAndFeel_ the `InteriorBackground` color is not been used when checkbox paint happens. In _WindowsLookAndFeel_ the CheckBox check/uncheck is drawn using `ImageCache` which is totally independent of `InteriorBackground` color in which the user expects it to be. > The proposed fix is to return null for _WindowsLookAndFeel_ (which is what happens in other LookAndFeel like Metal/Synth/Motif/Aqua ) and return default color which is the actual color used in _WindowsClassicLookAndFeel_. test/jdk/javax/swing/JCheckBox/InteriorBackgroundTest.java line 64: > 62: Color color = UIManager.getColor("CheckBox.interiorBackground"); > 63: > 64: if(laf.contains("WindowsLookAndFeel") && color != null) { Suggestion: if (laf.contains("WindowsLookAndFeel") && color != null) { test/jdk/javax/swing/JCheckBox/InteriorBackgroundTest.java line 67: > 65: throw new RuntimeException("CheckBox.interiorBackground not Null for " + > 66: laf); > 67: } else if(laf.contains("WindowsClassicLookAndFeel") && color == null) { Suggestion: } else if (laf.contains("WindowsClassicLookAndFeel") && color == null) { ------------- PR: https://git.openjdk.org/jdk/pull/10385 From duke at openjdk.org Wed Nov 2 10:58:36 2022 From: duke at openjdk.org (Abhishek Kumar) Date: Wed, 2 Nov 2022 10:58:36 GMT Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel [v2] In-Reply-To: References: <8eobdmVaHGFsFgaL6oyv193K0AKZcJ2EDmN1JPJyRyY=.490d48e5-6033-4de5-b455-dbd8affcd1b7@github.com> <3C2MgF_7g8dIAAwmHVMFT6kyzuFZRcWec0TseTNlJs0=.f5cba3e2-dfd2-4f6f-b400-da80601a259b@github.com> Message-ID: On Thu, 27 Oct 2022 09:37:07 GMT, Abhishek Kumar wrote: >I guess you can see in folders where you have only files...Testwise, maybe use File.createTempFile for creating files and see.. I tried modifying the test case for different selection mode for all LAFs. In case of FILES_AND_DIRECTORIES and DIRECTORIES_ONLY, the test passed in all LAFs. But when the selection mode is set to FILES_ONLY, the UI in GTK doesn't show the file lists and test is failing. However If I test manually for each selection mode, the behavior is same for all LAFs. 1) In case of FILES_AND_DIRECTORIES, able to select single as well as multiple directories or files. 2) In case of DIRECTORIES_ONLY, able to select single as well as multiple directories but not files. 3) In case of FILES_ONLY, able to select single as well as multiple files but not directories. ------------- PR: https://git.openjdk.org/jdk/pull/10866 From duke at openjdk.org Wed Nov 2 11:14:19 2022 From: duke at openjdk.org (Renjith Kannath Pariyangad) Date: Wed, 2 Nov 2022 11:14:19 GMT Subject: Integrated: 8252075: Documentation error in LayoutManager2 interface In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 07:00:04 GMT, Renjith Kannath Pariyangad wrote: > Updated the documentation with proper meaningful message for better understanding. This pull request has now been integrated. Changeset: 47d513ba Author: Renjith Committer: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/47d513baa2062f428465616a33d12c5bac2f22b1 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod 8252075: Documentation error in LayoutManager2 interface Reviewed-by: aivanov ------------- PR: https://git.openjdk.org/jdk/pull/10549 From aivanov at openjdk.org Wed Nov 2 11:20:19 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 2 Nov 2022 11:20:19 GMT Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel installColors and installColorsAndFont are not uninstalled In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 22:52:30 GMT, SWinxy wrote: > Many `installDefaults` methods set the font, foreground, and background on objects but their inverse methods `uninstallDefaults` do not remove them. I've added an inverse method to remove the colors and font to call for the `uninstallDefaults` methods that install defaults. > > `AquaButtonUI` can call its super since it would otherwise be repeated code. `BasicComboBoxUI` (weirdly) installs the properties again when it should be uninstalling them, so I changed. > > I noticed that, in a few subclasses, only one of calls to the super of `installDefaults` and `uninstallDefaults` are made. That is, an overridden `installDefaults` may call its super while the overridden `uninstallDefaults` does not call its super (or vise versa). These classes are: `AquaTabbedPaneUI`, `SynthMenuItemUI`, `SynthSplitPaneUI`, and `XTextAreaPeer`. > > Sorry I couldn't write a test; I wasn't sure how I should have accessed the protected variable aside from creating extending classes for each class that changed. > > See also #6603, where this issue was discovered. I've started looking at this. It looks good, yet I just skimmed through the changes without thoroughly reviewing, I haven't run the tests yet. ------------- PR: https://git.openjdk.org/jdk/pull/10565 From aivanov at openjdk.org Wed Nov 2 11:20:27 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 2 Nov 2022 11:20:27 GMT Subject: RFR: 8295774 : Write a test to verify that List Item selection events. [v2] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 04:04:14 GMT, ravi gupta wrote: >> This testcase verify that List Item selection via mouse/keys generates ItemEvent/ActionEvent appropriately. >> >> a. Single click on the list generate ItemEvent and double click on item generates ActionEvent. >> b. UP/DOWN keys on the list generate ItemEvent and enter key on item generates ActionEvent. >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8295774 : Write a test to verify that List Item selection events. Changes requested by aivanov (Reviewer). test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 80: > 78: robot = new Robot(); > 79: try { > 80: I think this blank line in unnecessary. test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 89: > 87: Point listAt = list.getLocationOnScreen(); > 88: > 89: Dimension listDimension = list.getSize(); Would `size` or `listSize` be a better name? I think the blank line between `listAt` and `listDimension` is not necessary, such as the one below before the `Robot.move` call. test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 118: > 116: EventQueue.invokeAndWait(() -> list.select(0)); > 117: > 118: if (itemStateChanged) { You may add `Robot.waitForIdle` to be 100% sure; even though the selection occurs on the EDT, by the time `invokeAndWait` returns the listeners will have been notified. So, it should be pretty safe without it. ------------- PR: https://git.openjdk.org/jdk/pull/10899 From aivanov at openjdk.org Wed Nov 2 11:20:30 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 2 Nov 2022 11:20:30 GMT Subject: RFR: 8295774 : Write a test to verify that List Item selection events. [v2] In-Reply-To: References: Message-ID: <1XNNIkZJg6E4ITeluI9A9vlrm4zu-C8H0g1DXQsfvWE=.7cb35b2e-e0c7-46df-9e6d-ff73c7ac1ccf@github.com> On Wed, 2 Nov 2022 04:12:44 GMT, ravi gupta wrote: >> test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 140: >> >>> 138: } >>> 139: >>> 140: robot.setAutoDelay(waitDelay); >> >> Why is delay increased here? > > This test verifies list section via mouse/keys events. > > For mouse events, robot.setAutoDelay(100) worked well. But for key events there were a few intermittent failures which cleared out with a higher delay via robot.setAutoDelay(1000) I see. Would it be clearer if you have two constants: private static final int MOUSE_DELAY = 100; private static final int KEYBOARD_DELAY = 1000; Then you would set the former initially and, before testing with key events, you would change to the latter. It'll make the intention much clearer and explain why it's changed. ------------- PR: https://git.openjdk.org/jdk/pull/10899 From aivanov at openjdk.org Wed Nov 2 11:51:24 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 2 Nov 2022 11:51:24 GMT Subject: RFR: 6201035: Document NPE for passing null insets to constructors and methods of several javax.swing.border.* classes [v5] In-Reply-To: <_d6PriCJT_JKqm8TXT-sy0xK5YWd35Kov9Xknx4p-kk=.5b683618-bed4-4454-93d1-d0f79ae91fc0@github.com> References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com> <_d6PriCJT_JKqm8TXT-sy0xK5YWd35Kov9Xknx4p-kk=.5b683618-bed4-4454-93d1-d0f79ae91fc0@github.com> Message-ID: On Tue, 1 Nov 2022 16:29:16 GMT, Alexey Ivanov wrote: > `TitledBorder` is to be updates as well. https://github.com/openjdk/jdk/blob/1a58cb1c023c876594e8a53d00703e564a922d36/src/java.desktop/share/classes/javax/swing/border/TitledBorder.java#L373-L378 This hasn't been addressed yet. It requires the CSR to be updated. ------------- PR: https://git.openjdk.org/jdk/pull/10740 From aivanov at openjdk.org Wed Nov 2 11:55:46 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 2 Nov 2022 11:55:46 GMT Subject: RFR: 6201035: Document NPE for passing null insets to constructors and methods of several javax.swing.border.* classes [v5] In-Reply-To: References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com> Message-ID: <8Rv7jIuURvwRUVBITdUjKhIeLk8kMkToP7s3xgl4fN0=.383709ff-4b11-4c76-b953-d9abdd95292a@github.com> On Mon, 31 Oct 2022 07:48:38 GMT, Prasanta Sadhukhan wrote: >> The behavior of MatteBorder constructors taking Insets object as a parameter is undocumented. It would throw NPE if null object is passed to it, which should be documented in the spec. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Rectify javadoc of more border classes/methods Before I can approve this PR, I would like to see the javadoc for border classes (those that are modified) updated so that all of them use *?Reinitializes?* as the first word in the description instead of *?Reinitialize?*, which aligns with [the javadoc style guide](https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html#styleguide): > **Use 3rd person (descriptive) not 2nd person (prescriptive).** > > The description is in 3rd person declarative rather than 2nd person imperative. > > Gets the label. *(preferred)* > > Get the label. (avoid) ------------- PR: https://git.openjdk.org/jdk/pull/10740 From mvs at openjdk.org Wed Nov 2 12:13:25 2022 From: mvs at openjdk.org (Manukumar V S) Date: Wed, 2 Nov 2022 12:13:25 GMT Subject: RFR: 8295707: Create a regression test for JDK-7184401 In-Reply-To: References: Message-ID: <3VNFJOC_0N1pb2AaEdWl84lpMyY0tho7gY49XbcC3QQ=.8004beac-9a80-4f13-9ccc-034ea1b3034b@github.com> On Thu, 20 Oct 2022 08:59:20 GMT, Srinivas Mandalika wrote: > 8295707: Create a regression test for JDK-7184401 > > JDK-7184401 - JDk7u6 : Missing main menu bar in Netbeans after fix for 7162144 > Above bug got introduced due to a fix for [JDK-7162144](https://bugs.openjdk.java.net/browse/JDK-7162144). > The issue was observed on the netbeans UI. > The test below recreates a standalone test to mimic the failure reported in Netbeans in [JDK-7184401](https://bugs.openjdk.java.net/browse/JDK-7184401) and verifies that it is working as expected after it got fixed via [JDK-7189350](https://bugs.openjdk.java.net/browse/JDK-7189350)) > > The Test attempts to reproduce specific behavior of NetBeans at the certain toolbar creation stage. Widgets are created on EDT; Another code posts some events to them on EDT; From another thread some code calls explicitly edt.interrupt(). > Before this got fixed, events from a second code got lost. > > This review is for migrating tests from a closed test suite to open. > Testing: > 1.Tested the code on jdk7u6 to reproduce the issue - the UI hangs when run on this build. > 2. Tested the code on jdk7u361 b01 to validate the fix - the test passed. > 3.Mach5 Testing(40 times per platform) in macos x64, linux x64 and windows x64 - the .results are clean test/jdk/java/awt/EventDispatchThread/InterruptEDTTest.java line 55: > 53: robot = new Robot(); > 54: EventQueue.invokeAndWait(() -> { > 55: edt = Thread.currentThread(); Why this adding listener code etc in EDT? ------------- PR: https://git.openjdk.org/jdk/pull/10784 From alanb at openjdk.org Wed Nov 2 12:22:31 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 2 Nov 2022 12:22:31 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v3] In-Reply-To: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com> References: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com> Message-ID: On Tue, 1 Nov 2022 16:14:20 GMT, Daniel Fuchs wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. >> >> This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. >> >> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. >> >> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. >> >> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. >> >> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Integrated review feedback > - Merge branch 'master' into deprecate-url-ctor-8294241 > - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml > - Merge branch 'master' into deprecate-url-ctor-8294241 > - Fix whitespace issues > - 8294241 Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10874 From duke at openjdk.org Wed Nov 2 14:11:38 2022 From: duke at openjdk.org (lawrence.andrews) Date: Wed, 2 Nov 2022 14:11:38 GMT Subject: RFR: 8295707: Create a regression test for JDK-7184401 In-Reply-To: References: Message-ID: On Thu, 20 Oct 2022 08:59:20 GMT, Srinivas Mandalika wrote: > 8295707: Create a regression test for JDK-7184401 > > JDK-7184401 - JDk7u6 : Missing main menu bar in Netbeans after fix for 7162144 > Above bug got introduced due to a fix for [JDK-7162144](https://bugs.openjdk.java.net/browse/JDK-7162144). > The issue was observed on the netbeans UI. > The test below recreates a standalone test to mimic the failure reported in Netbeans in [JDK-7184401](https://bugs.openjdk.java.net/browse/JDK-7184401) and verifies that it is working as expected after it got fixed via [JDK-7189350](https://bugs.openjdk.java.net/browse/JDK-7189350)) > > The Test attempts to reproduce specific behavior of NetBeans at the certain toolbar creation stage. Widgets are created on EDT; Another code posts some events to them on EDT; From another thread some code calls explicitly edt.interrupt(). > Before this got fixed, events from a second code got lost. > > This review is for migrating tests from a closed test suite to open. > Testing: > 1.Tested the code on jdk7u6 to reproduce the issue - the UI hangs when run on this build. > 2. Tested the code on jdk7u361 b01 to validate the fix - the test passed. > 3.Mach5 Testing(40 times per platform) in macos x64, linux x64 and windows x64 - the .results are clean test/jdk/java/awt/EventDispatchThread/InterruptEDTTest.java line 86: > 84: ((sun.awt.SunToolkit) (Toolkit.getDefaultToolkit())).realSync(); > 85: try { > 86: EventQueue.invokeAndWait(() -> { This is duplicate code in Line# 67 to Line# 72. test/jdk/java/awt/EventDispatchThread/InterruptEDTTest.java line 92: > 90: height = frame.getHeight(); > 91: }); > 92: robot.mouseMove(xLocation + width / 3, yLocation + height / 3); Line# 75 robot.mouseMove is called with in EDT? but where as here its not. Is there any reason for not invoking this in EDT ? ------------- PR: https://git.openjdk.org/jdk/pull/10784 From duke at openjdk.org Wed Nov 2 14:38:52 2022 From: duke at openjdk.org (ravi gupta) Date: Wed, 2 Nov 2022 14:38:52 GMT Subject: RFR: 8295774 : Write a test to verify that List Item selection events. [v3] In-Reply-To: References: Message-ID: <4N5f5eULHcJ_sv4vNkespog-aTXVciV5wiR0oDwfZ6s=.57f2de8f-3977-4b3d-a0cf-ac69cc922b99@github.com> > This testcase verify that List Item selection via mouse/keys generates ItemEvent/ActionEvent appropriately. > > a. Single click on the list generate ItemEvent and double click on item generates ActionEvent. > b. UP/DOWN keys on the list generate ItemEvent and enter key on item generates ActionEvent. > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. ravi gupta has updated the pull request incrementally with one additional commit since the last revision: 8295774: Write a test to verify that List Item selection events. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10899/files - new: https://git.openjdk.org/jdk/pull/10899/files/984ab23f..69296bb4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10899&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10899&range=01-02 Stats: 12 lines in 1 file changed: 2 ins; 3 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/10899.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10899/head:pull/10899 PR: https://git.openjdk.org/jdk/pull/10899 From aivanov at openjdk.org Wed Nov 2 14:38:53 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 2 Nov 2022 14:38:53 GMT Subject: RFR: 8295774 : Write a test to verify that List Item selection events. [v2] In-Reply-To: References: Message-ID: <2pnClu6sSVpY8aAE-A3cDXN82THZT3zqpXQ_SUvge_I=.42b67345-bc7e-418c-b3b1-30afde6dcae8@github.com> On Wed, 2 Nov 2022 04:04:14 GMT, ravi gupta wrote: >> This testcase verify that List Item selection via mouse/keys generates ItemEvent/ActionEvent appropriately. >> >> a. Single click on the list generate ItemEvent and double click on item generates ActionEvent. >> b. UP/DOWN keys on the list generate ItemEvent and enter key on item generates ActionEvent. >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8295774 : Write a test to verify that List Item selection events. @ravigupta30, I edited the JBS subject, you have to update the subject of the PR here. ------------- PR: https://git.openjdk.org/jdk/pull/10899 From duke at openjdk.org Wed Nov 2 14:38:53 2022 From: duke at openjdk.org (ravi gupta) Date: Wed, 2 Nov 2022 14:38:53 GMT Subject: RFR: 8295774 : Write a test to verify that List Item selection events. [v2] In-Reply-To: References: Message-ID: <9sUXx4wzNuNU7jKPKdrEh5AQptJ94-12T2k1YU9LBwE=.e5645579-f4c7-4806-8777-bb9ed4aa8f9e@github.com> On Wed, 2 Nov 2022 11:16:15 GMT, Alexey Ivanov wrote: >> ravi gupta has updated the pull request incrementally with one additional commit since the last revision: >> >> 8295774 : Write a test to verify that List Item selection events. > > test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 80: > >> 78: robot = new Robot(); >> 79: try { >> 80: > > I think this blank line in unnecessary. Resolved. removed blank line. > test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 89: > >> 87: Point listAt = list.getLocationOnScreen(); >> 88: >> 89: Dimension listDimension = list.getSize(); > > Would `size` or `listSize` be a better name? > > I think the blank line between `listAt` and `listDimension` is not necessary, such as the one below before the `Robot.move` call. Resolved . Renamed as listSize and blank line removed. > test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 118: > >> 116: EventQueue.invokeAndWait(() -> list.select(0)); >> 117: >> 118: if (itemStateChanged) { > > You may add `Robot.waitForIdle` to be 100% sure; even though the selection occurs on the EDT, by the time `invokeAndWait` returns the listeners will have been notified. So, it should be pretty safe without it. Resolved . added robot.waitForIdle(); ------------- PR: https://git.openjdk.org/jdk/pull/10899 From duke at openjdk.org Wed Nov 2 14:38:54 2022 From: duke at openjdk.org (ravi gupta) Date: Wed, 2 Nov 2022 14:38:54 GMT Subject: RFR: 8295774 : Write a test to verify that List Item selection events. [v3] In-Reply-To: <1XNNIkZJg6E4ITeluI9A9vlrm4zu-C8H0g1DXQsfvWE=.7cb35b2e-e0c7-46df-9e6d-ff73c7ac1ccf@github.com> References: <1XNNIkZJg6E4ITeluI9A9vlrm4zu-C8H0g1DXQsfvWE=.7cb35b2e-e0c7-46df-9e6d-ff73c7ac1ccf@github.com> Message-ID: <8clX5Vd6pdiAv5y6Ew4t_qnxdSbyV08NqdU1DGfL16I=.db685311-3768-434b-821c-5445896b8b8b@github.com> On Wed, 2 Nov 2022 11:02:34 GMT, Alexey Ivanov wrote: >> This test verifies list section via mouse/keys events. >> >> For mouse events, robot.setAutoDelay(100) worked well. But for key events there were a few intermittent failures which cleared out with a higher delay via robot.setAutoDelay(1000) > > I see. Would it be clearer if you have two constants: > > private static final int MOUSE_DELAY = 100; > private static final int KEYBOARD_DELAY = 1000; > > > Then you would set the former initially and, before testing with key events, you would change to the latter. It'll make the intention much clearer and explain why it's changed. Resolved . implemented as suggested. ------------- PR: https://git.openjdk.org/jdk/pull/10899 From aivanov at openjdk.org Wed Nov 2 14:40:47 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 2 Nov 2022 14:40:47 GMT Subject: RFR: 8295774 : Write a test to verify that List Item selection events. [v3] In-Reply-To: <4N5f5eULHcJ_sv4vNkespog-aTXVciV5wiR0oDwfZ6s=.57f2de8f-3977-4b3d-a0cf-ac69cc922b99@github.com> References: <4N5f5eULHcJ_sv4vNkespog-aTXVciV5wiR0oDwfZ6s=.57f2de8f-3977-4b3d-a0cf-ac69cc922b99@github.com> Message-ID: <9Bu4kxca-GGUfvNjb1Vsxf-FFRb1r2Z8xIONMMwj4Ag=.12f442d4-38b7-4449-a91e-23f68dab0178@github.com> On Wed, 2 Nov 2022 14:38:52 GMT, ravi gupta wrote: >> This testcase verify that List Item selection via mouse/keys generates ItemEvent/ActionEvent appropriately. >> >> a. Single click on the list generate ItemEvent and double click on item generates ActionEvent. >> b. UP/DOWN keys on the list generate ItemEvent and enter key on item generates ActionEvent. >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8295774: Write a test to verify that List Item selection events. Changes requested by aivanov (Reviewer). test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 90: > 88: > 89: robot.mouseMove(listAt.x + listSize .width / 2, > 90: listAt.y + listSize .height / 2); No space before the dot: Suggestion: robot.mouseMove(listAt.x + listSize.width / 2, listAt.y + listSize.height / 2); ------------- PR: https://git.openjdk.org/jdk/pull/10899 From alexsch at openjdk.org Wed Nov 2 14:48:32 2022 From: alexsch at openjdk.org (Alexander Scherbatiy) Date: Wed, 2 Nov 2022 14:48:32 GMT Subject: RFR: 8295737: macOS: Print content cut off when width > height with portrait orientation In-Reply-To: References: Message-ID: On Fri, 21 Oct 2022 08:42:12 GMT, Alexander Scherbatiy wrote: > A printed content is truncated on macOS if the content paper size width larger than height with portrait orientation or width is less than height with landscape orientation. > > To reproduce the issue run the [CutOffImage](https://bugs.openjdk.org/secure/attachment/101145/CutOffImage.java) sample on MacOS. > > Four rectangles are printed: > 1. size 300x100, portrait orientation > 2. size 300x100, landscape orientation > 3. size 100x300, portrait orientation > 4. size 100x300, landscape orientation > > The first and fourth rectangles are truncated: [cut off content](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf) > > The reason is that NSPrintInfo class does not allow to set paper size and orientation independently. > Setting paper size width large than height changes NSPrintInfo orientation to landscape. > Setting paper size width less than height changes NSPrintInfo orientation to portrait. > Updating NSPrintInfo orientation from landscape to portrait or from portrait to landscape swaps NSPrintInfo paper width and height. > > The Cocoa code that shows NSPrintInfo behavior: > > #import > > int main() > { > NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; > NSApp = [NSApplication sharedApplication]; > > #ifdef __MAC_10_9 // code for SDK 10.9 or newer > #define NS_PORTRAIT NSPaperOrientationPortrait > #define NS_LANDSCAPE NSPaperOrientationLandscape > #else // code for SDK 10.8 or older > #define NS_PORTRAIT NSPortraitOrientation > #define NS_LANDSCAPE NSLandscapeOrientation > #endif > > printf("NS_PORTRAIT: %d\n", NS_PORTRAIT); > printf("NS_LANDSCAPE: %d\n", NS_LANDSCAPE); > > printf("create default print info\n"); > NSPrintInfo* defaultPrintInfo = [[NSPrintInfo sharedPrintInfo] copy]; > NSSize size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > printf("call setUpPrintOperationDefaultValues\n"); > [defaultPrintInfo setUpPrintOperationDefaultValues]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > double w = 300.0; > double h = 100.0; > printf("set size: [%f, %f]\n", w, h); > [defaultPrintInfo setPaperSize:NSMakeSize(w, h)]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > printf("Set NS_PORTRAIT orientation\n"); > [defaultPrintInfo setOrientation: NS_PORTRAIT]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > [NSApp run]; > > [NSApp release]; > [pool release]; > return(EXIT_SUCCESS); > } > > > On macOS Mojave 10.14.5 it prints: > > > NS_PORTRAIT: 0 > NS_LANDSCAPE: 1 > create default print info > orientation: 0, paper size: [612.000000, 792.000000] > call setUpPrintOperationDefaultValues > orientation: 0, paper size: [612.000000, 792.000000] > set size: [300.000000, 100.000000] > orientation: 1, paper size: [300.000000, 100.000000] // orientation flip > Set NS_PORTRAIT orientation > orientation: 0, paper size: [100.000000, 300.000000] // size flip > ``` > > There are four possible cases for printing a rectangle with different size and orientation: > 1. Input: paper size: (w > h), orientation portrait > [dstPrintInfo setPaperSize: NSMakeSize(w, h)] // size: (w, h), orientation: landscape > [dstPrintInfo setOrientation: NS_PORTRAIT] // size: (h, w), orientation: portrait > Note: width and height are swapped > 2. Input: paper size: (w > h), orientation landscape > [dstPrintInfo setPaperSize: NSMakeSize(h, w)] // size: (h, w), orientation: portrait > [dstPrintInfo setOrientation: NS_LANDSCAPE] // size: (w, h), orientation: landscape > 3. Input: paper size: (w < h), orientation portrait > [dstPrintInfo setPaperSize: NSMakeSize(w, h)] // size: (w, h), orientation: portrait > [dstPrintInfo setOrientation: NS_PORTRAIT] // size: (w, h), orientation: portrait > 4. Input: paper size: (w < h), orientation landscape > [dstPrintInfo setPaperSize: NSMakeSize(h, w)] // size: (h, w), orientation: landscape > [dstPrintInfo setOrientation: NS_LANDSCAPE] // size: (h, w), orientation: landscape > Note: width and height are swapped > > Only for cases 1 and 4 the final width and height are swapped. > The proposed fix enlarges height for cases 1 and 4 to not cut the printed rectangle. > > It is not full fix which draws rectangles for cases 1 and 4 in the requested size. > Setting requested size leads that subsequent orientation flips width and height. > The fix only enlarges the truncated area in height direction. The enlarged area in width is preserved as before the fix. > > Printed rectangles before and after the fix: > 1. size 300x100, portrait orientation: [before-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101157/before-fix-1.pdf), [after-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101162/after-fix-1.pdf) > 2. size 300x100, landscape orientation: [before-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101156/before-fix-2.pdf), [after-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101161/after-fix-2.pdf) > 3. size 100x300, portrait orientation: [before-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101155/before-fix-3.pdf), [after-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101160/after-fix-3.pdf) > 4. size 100x300, landscape orientation: [before-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101154/before-fix-4.pdf), [after-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101159/after-fix-4.pdf) > > All four rectangles: [before-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf), [after-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101158/after-fix-all.pdf) Suppose there is an [image](https://bugs.openjdk.org/secure/attachment/101295/image-PORTRAIT-600x200.png) with size 600x200. It is necessary to print only region [0, 0, 300, 100] of the image using page size 300x100 and portrait orientation (case 1). The java code which prints only part of the image with the given page size and orientation could look like: PageFormat pageFormat = printerJob.getPageFormat(null); pageFormat.setOrientation(PageFormat.PORTRAIT); Paper paper = pageFormat.getPaper(); paper.setSize(300, 100); paper.setImageableArea(0, 0, 300, 100); pageFormat.setPaper(paper); First, I would check how the image can be printed with pure Cocoa code using NSImageView, NSPrintInfo, and NSPrintOperation classes and transformations. The NSImageView rotation can be implemented as: @interface SampleImageView : NSImageView @end @implementation SampleImageView - (void)drawRect:(NSRect)dirtyRect { NSAffineTransform *transform = [[NSAffineTransform alloc] init]; [transform rotateByDegrees: 90.0]; [transform concat]; [super drawRect:dirtyRect]; } @end The Cocoa pseudo code which prints the image is: NSImageView *nsImageView = // create NSImageView with the given image // apply clip and transformations to the nsImageView NSPrintInfo* printInfo = // create NSPrintInfo // set printInfo page size NSPrintOperation* loop = [NSPrintOperation printOperationWithView:nsImageView printInfo:printInfo]; The question which is not clear for me, which page size needs to be used for the code `// set printInfo page size`? Should it be the requested size 300x100? Setting page size 300x100 to NSPrintInfo implies that it is applied to landscape orientation. The result page size is rotated by 90 degree comparing to the portrait orientation. May be there are transforms which can be applied to NSPrintInfo for page size rotation? Should the default page size be used instead? So the NSImageView is translated, rotated, and clipped but it is printed to the page with default page size? ------------- PR: https://git.openjdk.org/jdk/pull/10808 From duke at openjdk.org Wed Nov 2 14:51:02 2022 From: duke at openjdk.org (ravi gupta) Date: Wed, 2 Nov 2022 14:51:02 GMT Subject: RFR: 8295774 : Write a test to verify that List Item selection events. [v4] In-Reply-To: References: Message-ID: > This testcase verify that List Item selection via mouse/keys generates ItemEvent/ActionEvent appropriately. > > a. Single click on the list generate ItemEvent and double click on item generates ActionEvent. > b. UP/DOWN keys on the list generate ItemEvent and enter key on item generates ActionEvent. > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. ravi gupta has updated the pull request incrementally with one additional commit since the last revision: 8295774: Write a test to verify that List Item selection events. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10899/files - new: https://git.openjdk.org/jdk/pull/10899/files/69296bb4..814c3397 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10899&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10899&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10899.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10899/head:pull/10899 PR: https://git.openjdk.org/jdk/pull/10899 From aivanov at openjdk.org Wed Nov 2 15:09:31 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 2 Nov 2022 15:09:31 GMT Subject: RFR: 8295774 : Write a test to verify that List Item selection events. [v4] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 14:51:02 GMT, ravi gupta wrote: >> This testcase verify that List Item selection via mouse/keys generates ItemEvent/ActionEvent appropriately. >> >> a. Single click on the list generate ItemEvent and double click on item generates ActionEvent. >> b. UP/DOWN keys on the list generate ItemEvent and enter key on item generates ActionEvent. >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8295774: Write a test to verify that List Item selection events. Marked as reviewed by aivanov (Reviewer). test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 67: > 65: }); > 66: list.addActionListener((event) -> { > 67: System.out.println("Got an ActionEvent:" + event); I prefer having a space after the colon in the string so that it's easier to read the message. ------------- PR: https://git.openjdk.org/jdk/pull/10899 From ihse at openjdk.org Wed Nov 2 15:38:16 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 2 Nov 2022 15:38:16 GMT Subject: RFR: 8295812: Skip the "half float" support in LittleCMS during the build In-Reply-To: References: Message-ID: On Sun, 23 Oct 2022 20:10:35 GMT, Sergey Bylokhov wrote: > The Java2d do not use "half" float in the image layouts, so we can disable it in the LittleCMS library during the build. It is possible to do using [this](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/liblcms/lcms2.h#L85) public option: > > > // Uncomment to get rid of the tables for "half" float support > // #define CMS_NO_HALF_SUPPORT 1 > > > This change cuts not only the unused by java2d functions but also [such](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/share/native/liblcms/cmshalf.c#L63) tables. > > The size of liblcms decreased by 20 kB on Linux(536024 vs 515152) and 15 kB on windows(246784 vs 231424). On macOS the win is only 300 bytes. Marked as reviewed by ihse (Reviewer). Nicely spotted! ------------- PR: https://git.openjdk.org/jdk/pull/10830 From honkar at openjdk.org Wed Nov 2 17:16:22 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 2 Nov 2022 17:16:22 GMT Subject: RFR: JDK-8295685: Update Libpng to 1.6.38 Message-ID: Updated libpng library to v1.6.38. Following files have been updated - - 12 source code files of libpng - LICENSE, README, CHANGES files - legal/libpng.md ------------- Commit messages: - changed to unix style line endings - libpng update - v1.6.38 Changes: https://git.openjdk.org/jdk/pull/10953/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10953&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295685 Stats: 205 lines in 16 files changed: 83 ins; 33 del; 89 mod Patch: https://git.openjdk.org/jdk/pull/10953.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10953/head:pull/10953 PR: https://git.openjdk.org/jdk/pull/10953 From honkar at openjdk.org Wed Nov 2 20:51:42 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 2 Nov 2022 20:51:42 GMT Subject: RFR: JDK-8295685: Update Libpng to 1.6.38 [v2] In-Reply-To: References: Message-ID: > Updated libpng library to v1.6.38. > > Following files have been updated - > > - 12 source code files of libpng > - LICENSE, README, CHANGES files > - legal/libpng.md Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: Updating.txt changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10953/files - new: https://git.openjdk.org/jdk/pull/10953/files/e5798056..fd4a9650 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10953&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10953&range=00-01 Stats: 18 lines in 1 file changed: 11 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/10953.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10953/head:pull/10953 PR: https://git.openjdk.org/jdk/pull/10953 From honkar at openjdk.org Wed Nov 2 21:15:02 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 2 Nov 2022 21:15:02 GMT Subject: RFR: JDK-8295685: Update Libpng to 1.6.38 [v3] In-Reply-To: References: Message-ID: > Updated libpng library to v1.6.38. > > Following files have been updated - > > - 12 source code files of libpng > - LICENSE, README, CHANGES, UPDATING text files > - legal/libpng.md Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: updated instructions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10953/files - new: https://git.openjdk.org/jdk/pull/10953/files/fd4a9650..6be50dc1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10953&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10953&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10953.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10953/head:pull/10953 PR: https://git.openjdk.org/jdk/pull/10953 From azvegint at openjdk.org Wed Nov 2 22:59:28 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 2 Nov 2022 22:59:28 GMT Subject: RFR: JDK-8295685: Update Libpng to 1.6.38 [v3] In-Reply-To: References: Message-ID: <1Ds7TiM0qPxiEdOIWjNh1K_Yj5lBMshNrQkwyN2J5PM=.3c202f3f-8277-4cc5-9fae-1434d55da63c@github.com> On Wed, 2 Nov 2022 21:15:02 GMT, Harshitha Onkar wrote: >> Updated libpng library to v1.6.38. >> >> Following files have been updated - >> >> - 12 source code files of libpng >> - LICENSE, README, CHANGES, UPDATING text files >> - legal/libpng.md > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > updated instructions src/java.desktop/share/native/libsplashscreen/libpng/UPDATING.txt line 7: > 5: and in the embedded text, and extending the copyright date. > 6: > 7: The updated info comes from the LICENSE and TRADEMARK files. and AUTHORS src/java.desktop/share/native/libsplashscreen/libpng/UPDATING.txt line 51: > 49: do > 50: sed -e 's/[ ]* $//' ${f} > ${f}.tmp; > 51: mv ${f}.tmp $f; You can use `-i` option for `sed` instead of explicit temp file. -i[SUFFIX], --in-place[=SUFFIX] edit files in place (makes backup if SUFFIX supplied) So it can be simplified to `sed -i -e 's/[ ]* $//' ${f}` BTW all 3 preparation actions can be performed in a single loop: for f in *.c *.h; do # replace tabs with spaces expand ${f} > ${f}.tmp; mv ${f}.tmp $f; # fix line endings to LF sed -i -e 's/\r$//g' ${f} # remove trailing spaces sed -i -e 's/[ ]* $//g' ${f} done src/java.desktop/share/native/libsplashscreen/libpng/pngdebug.h line 1: > 1: Not sure why this newline is needed. ------------- PR: https://git.openjdk.org/jdk/pull/10953 From honkar at openjdk.org Wed Nov 2 23:10:30 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 2 Nov 2022 23:10:30 GMT Subject: RFR: JDK-8295685: Update Libpng to 1.6.38 [v3] In-Reply-To: <1Ds7TiM0qPxiEdOIWjNh1K_Yj5lBMshNrQkwyN2J5PM=.3c202f3f-8277-4cc5-9fae-1434d55da63c@github.com> References: <1Ds7TiM0qPxiEdOIWjNh1K_Yj5lBMshNrQkwyN2J5PM=.3c202f3f-8277-4cc5-9fae-1434d55da63c@github.com> Message-ID: On Wed, 2 Nov 2022 21:18:43 GMT, Alexander Zvegintsev wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> updated instructions > > src/java.desktop/share/native/libsplashscreen/libpng/UPDATING.txt line 51: > >> 49: do >> 50: sed -e 's/[ ]* $//' ${f} > ${f}.tmp; >> 51: mv ${f}.tmp $f; > > You can use `-i` option for `sed` instead of explicit temp file. > > -i[SUFFIX], --in-place[=SUFFIX] > > edit files in place (makes backup if SUFFIX supplied) > > > So it can be simplified to `sed -i -e 's/[ ]* $//' ${f}` > > BTW all 3 preparation actions can be performed in a single loop: > > > > for f in *.c *.h; > do > # replace tabs with spaces > expand ${f} > ${f}.tmp; > mv ${f}.tmp $f; > > # fix line endings to LF > sed -i -e 's/\r$//g' ${f} > > # remove trailing spaces > sed -i -e 's/[ ]* $//g' ${f} > done Thanks for the suggestion. I'll update it. ------------- PR: https://git.openjdk.org/jdk/pull/10953 From honkar at openjdk.org Wed Nov 2 23:24:18 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 2 Nov 2022 23:24:18 GMT Subject: RFR: JDK-8295685: Update Libpng to 1.6.38 [v4] In-Reply-To: References: Message-ID: <-hRsvIa_CZeI9TQGxxPyRBU6RCiyFrwPkwKs05nQikE=.bc31b3d1-2fc7-437f-b26d-6e4ce635225c@github.com> > Updated libpng library to v1.6.38. > > Following files have been updated - > > - 12 source code files of libpng > - LICENSE, README, CHANGES, UPDATING text files > - legal/libpng.md Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: consolidated script to remove trailing whitespaces and fix line endings ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10953/files - new: https://git.openjdk.org/jdk/pull/10953/files/6be50dc1..6fb39567 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10953&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10953&range=02-03 Stats: 15 lines in 2 files changed: 0 ins; 2 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/10953.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10953/head:pull/10953 PR: https://git.openjdk.org/jdk/pull/10953 From honkar at openjdk.org Wed Nov 2 23:24:21 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 2 Nov 2022 23:24:21 GMT Subject: RFR: JDK-8295685: Update Libpng to 1.6.38 [v3] In-Reply-To: <1Ds7TiM0qPxiEdOIWjNh1K_Yj5lBMshNrQkwyN2J5PM=.3c202f3f-8277-4cc5-9fae-1434d55da63c@github.com> References: <1Ds7TiM0qPxiEdOIWjNh1K_Yj5lBMshNrQkwyN2J5PM=.3c202f3f-8277-4cc5-9fae-1434d55da63c@github.com> Message-ID: <-5LMW5PzYnMdTf7eMEdNVMim0Q9H1bqgOpY8cJngO8Q=.d3c549dd-c981-4aed-a326-a94f72a0926b@github.com> On Wed, 2 Nov 2022 22:20:03 GMT, Alexander Zvegintsev wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> updated instructions > > src/java.desktop/share/native/libsplashscreen/libpng/pngdebug.h line 1: > >> 1: > > Not sure why this newline is needed. Thanks for catching it. Updated. ------------- PR: https://git.openjdk.org/jdk/pull/10953 From azvegint at openjdk.org Thu Nov 3 00:47:49 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 3 Nov 2022 00:47:49 GMT Subject: RFR: JDK-8295685: Update Libpng to 1.6.38 [v4] In-Reply-To: <-hRsvIa_CZeI9TQGxxPyRBU6RCiyFrwPkwKs05nQikE=.bc31b3d1-2fc7-437f-b26d-6e4ce635225c@github.com> References: <-hRsvIa_CZeI9TQGxxPyRBU6RCiyFrwPkwKs05nQikE=.bc31b3d1-2fc7-437f-b26d-6e4ce635225c@github.com> Message-ID: <3P2VvXti76ZPg1XjhOHKdcae3zIg0UBc6KueTG-Cas8=.8f30dc46-3c0e-487f-bab7-981f1b7cfdea@github.com> On Wed, 2 Nov 2022 23:24:18 GMT, Harshitha Onkar wrote: >> Updated libpng library to v1.6.38. >> >> Following files have been updated - >> >> - 12 source code files of libpng >> - LICENSE, README, CHANGES, UPDATING text files >> - legal/libpng.md > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > consolidated script to remove trailing whitespaces and fix line endings src/java.desktop/share/native/libsplashscreen/libpng/UPDATING.txt line 9: > 7: The updated info comes from the LICENSE, TRADEMARK and AUTHORS files. > 8: > 9: 2) Copy LICENSE, README, and CHANGES from the new version into OpenJDK's I am not sure, but probably we might want also copy TRADEMARK and AUTHORS, since we started to pull info from them to `libpng.md` src/java.desktop/share/native/libsplashscreen/libpng/UPDATING.txt line 38: > 36: 5) Run scripts to expand tabs and remove trailing white space from source files. > 37: > 38: First cd into the libpng folder and run the following scripts. script without s? src/java.desktop/share/native/libsplashscreen/libpng/UPDATING.txt line 54: > 52: > 53: Make sure all the updated files have UNIX-STYLE (LF) line endings to avoid > 54: whitespace errors. This should be already handled by script above. ------------- PR: https://git.openjdk.org/jdk/pull/10953 From prr at openjdk.org Thu Nov 3 02:23:12 2022 From: prr at openjdk.org (Phil Race) Date: Thu, 3 Nov 2022 02:23:12 GMT Subject: RFR: JDK-8295685: Update Libpng to 1.6.38 [v4] In-Reply-To: <-hRsvIa_CZeI9TQGxxPyRBU6RCiyFrwPkwKs05nQikE=.bc31b3d1-2fc7-437f-b26d-6e4ce635225c@github.com> References: <-hRsvIa_CZeI9TQGxxPyRBU6RCiyFrwPkwKs05nQikE=.bc31b3d1-2fc7-437f-b26d-6e4ce635225c@github.com> Message-ID: <9sWxEgpt1w_8BZM6yO5zSem1rdzT1q7bur9p5zUhnv4=.30aa5f01-1674-4bc5-81ff-9e0887f97be3@github.com> On Wed, 2 Nov 2022 23:24:18 GMT, Harshitha Onkar wrote: >> Updated libpng library to v1.6.38. >> >> Following files have been updated - >> >> - 12 source code files of libpng >> - LICENSE, README, CHANGES, UPDATING text files >> - legal/libpng.md > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > consolidated script to remove trailing whitespaces and fix line endings Looks fine on the understanding that you built + tested on all platforms - running all automated tests. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.org/jdk/pull/10953 From psadhukhan at openjdk.org Thu Nov 3 03:17:34 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 3 Nov 2022 03:17:34 GMT Subject: RFR: 6257207: JTable.getDefaultEditor throws NullPointerException [v4] In-Reply-To: References: Message-ID: > If getDefaultEditor() is called before the JTable model is setup, it results in NPE. > > This is because when JTable sets its model, which ends up firing a table changed event. The testcase is listening for tableChanged events and querying the editor. But the editor isn't installed until after the model is set which results in NPE. > Fix is to ensure initializeLocalVars() which initializes default editor is setup before JTable sets its model. > > No regression is observed in jtreg/jck testsuite with this change. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Test review fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10871/files - new: https://git.openjdk.org/jdk/pull/10871/files/7ac0d1e8..a2c499fb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10871&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10871&range=02-03 Stats: 7 lines in 1 file changed: 1 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10871.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10871/head:pull/10871 PR: https://git.openjdk.org/jdk/pull/10871 From psadhukhan at openjdk.org Thu Nov 3 03:19:07 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 3 Nov 2022 03:19:07 GMT Subject: RFR: 6257207: JTable.getDefaultEditor throws NullPointerException [v3] In-Reply-To: References: <-_EIXOFFPEZ5uuvK42SJ4cNn_kA7k7rr6YOi8AY1M3M=.63eac53f-7abe-4f9d-8ecd-dcf06aadc762@github.com> Message-ID: <4_J-btAAA_SAdND_II1lT2CnSnaEFw8tPcKs61G2sVg=.e28b2d27-ffc3-485d-82aa-7ac4ae0e66b4@github.com> On Tue, 1 Nov 2022 16:45:45 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove extra line > > test/jdk/javax/swing/JTable/JTableEditorNPE.java line 62: > >> 60: }); >> 61: } finally { >> 62: Thread.sleep(1000); > > Is the `sleep` required? > > If NPE is thrown, no UI appears at all; if NPE is not thrown, the UI may be shown but not required. > > Would it be enough to add the table to the frame and call `validate()`? I added sleep to see the frame before it dispose but I agree it's not required for checking the fix..Modified as per comment... ------------- PR: https://git.openjdk.org/jdk/pull/10871 From psadhukhan at openjdk.org Thu Nov 3 03:22:44 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 3 Nov 2022 03:22:44 GMT Subject: RFR: 6201035: Document NPE for passing null insets to constructors and methods of several javax.swing.border.* classes [v6] In-Reply-To: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com> References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com> Message-ID: > The behavior of MatteBorder constructors taking Insets object as a parameter is undocumented. It would throw NPE if null object is passed to it, which should be documented in the spec. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: TitledBorder added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10740/files - new: https://git.openjdk.org/jdk/pull/10740/files/e7081b0d..40891ee7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10740&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10740&range=04-05 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10740.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10740/head:pull/10740 PR: https://git.openjdk.org/jdk/pull/10740 From psadhukhan at openjdk.org Thu Nov 3 03:27:29 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 3 Nov 2022 03:27:29 GMT Subject: RFR: 6201035: Document NPE for passing null insets to constructors and methods of several javax.swing.border.* classes [v7] In-Reply-To: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com> References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com> Message-ID: <1ppO_1ffr_WXYasbkbI13Tov3Rj92-k4-nR_RDT7W2o=.1a0f6481-3ccf-43f2-af7d-a2160d622aeb@github.com> > The behavior of MatteBorder constructors taking Insets object as a parameter is undocumented. It would throw NPE if null object is passed to it, which should be documented in the spec. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: AbstractBorder fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10740/files - new: https://git.openjdk.org/jdk/pull/10740/files/40891ee7..eaac0717 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10740&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10740&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10740.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10740/head:pull/10740 PR: https://git.openjdk.org/jdk/pull/10740 From duke at openjdk.org Thu Nov 3 05:01:35 2022 From: duke at openjdk.org (ravi gupta) Date: Thu, 3 Nov 2022 05:01:35 GMT Subject: RFR: 8295774: Write a test to verify List sends ItemEvent/ActionEvent [v5] In-Reply-To: References: Message-ID: > This testcase verify that List Item selection via mouse/keys generates ItemEvent/ActionEvent appropriately. > > a. Single click on the list generate ItemEvent and double click on item generates ActionEvent. > b. UP/DOWN keys on the list generate ItemEvent and enter key on item generates ActionEvent. > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. ravi gupta has updated the pull request incrementally with one additional commit since the last revision: 8295774: Write a test to verify List sends ItemEvent/ActionEvent ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10899/files - new: https://git.openjdk.org/jdk/pull/10899/files/814c3397..305b0122 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10899&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10899&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10899.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10899/head:pull/10899 PR: https://git.openjdk.org/jdk/pull/10899 From psadhukhan at openjdk.org Thu Nov 3 07:14:37 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 3 Nov 2022 07:14:37 GMT Subject: RFR: 6788481: CellEditorListener.editingCanceled is never called Message-ID: When editing of a table cell is canceled, the function editingCanceled of the registered listener CellEditorListener is not called as actionPerformed on ESC key press was not notifying the "cancel" listeners. Fix is to handle "Cancel" action in actionPerformed() by forwarding the Cancel message from CellEditor to the delegate so that it can call `AbstractCellEditor.fireEditingCanceled(`) which notifies all listeners of cancel event. ------------- Commit messages: - 6788481: CellEditorListener.editingCanceled is never called Changes: https://git.openjdk.org/jdk/pull/10964/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10964&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6788481 Stats: 114 lines in 2 files changed: 114 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10964.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10964/head:pull/10964 PR: https://git.openjdk.org/jdk/pull/10964 From duke at openjdk.org Thu Nov 3 07:49:28 2022 From: duke at openjdk.org (ExE Boss) Date: Thu, 3 Nov 2022 07:49:28 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v3] In-Reply-To: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com> References: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com> Message-ID: On Tue, 1 Nov 2022 16:14:20 GMT, Daniel Fuchs wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. >> >> This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. >> >> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. >> >> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. >> >> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. >> >> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Integrated review feedback > - Merge branch 'master' into deprecate-url-ctor-8294241 > - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml > - Merge branch 'master' into deprecate-url-ctor-8294241 > - Fix whitespace issues > - 8294241 Since?these are?in?the?same compilation?unit as?the?deprecated `URL`?constructors, `@SuppressWarnings("deprecation")` isn?t?needed: src/java.base/share/classes/java/net/URL.java line 885: > 883: @SuppressWarnings("deprecation") > 884: var result = new URL("jrt", host, port, file, null); > 885: return result; Suggestion: return new URL("jrt", host, port, file, null); src/java.base/share/classes/java/net/URL.java line 909: > 907: @SuppressWarnings("deprecation") > 908: var result = new URL((URL)null, uri.toString(), handler); > 909: return result; Suggestion: return new URL((URL)null, uri.toString(), handler); src/java.base/share/classes/java/net/URL.java line 1833: > 1831: try { > 1832: @SuppressWarnings("deprecation") > 1833: var _unused = replacementURL = new URL(urlString); Suggestion: replacementURL = new URL(urlString); ------------- PR: https://git.openjdk.org/jdk/pull/10874 From smandalika at openjdk.org Thu Nov 3 07:58:16 2022 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Thu, 3 Nov 2022 07:58:16 GMT Subject: RFR: 8295707: Create a regression test for JDK-7184401 In-Reply-To: <3VNFJOC_0N1pb2AaEdWl84lpMyY0tho7gY49XbcC3QQ=.8004beac-9a80-4f13-9ccc-034ea1b3034b@github.com> References: <3VNFJOC_0N1pb2AaEdWl84lpMyY0tho7gY49XbcC3QQ=.8004beac-9a80-4f13-9ccc-034ea1b3034b@github.com> Message-ID: On Wed, 2 Nov 2022 12:11:16 GMT, Manukumar V S wrote: >> 8295707: Create a regression test for JDK-7184401 >> >> JDK-7184401 - JDk7u6 : Missing main menu bar in Netbeans after fix for 7162144 >> Above bug got introduced due to a fix for [JDK-7162144](https://bugs.openjdk.java.net/browse/JDK-7162144). >> The issue was observed on the netbeans UI. >> The test below recreates a standalone test to mimic the failure reported in Netbeans in [JDK-7184401](https://bugs.openjdk.java.net/browse/JDK-7184401) and verifies that it is working as expected after it got fixed via [JDK-7189350](https://bugs.openjdk.java.net/browse/JDK-7189350)) >> >> The Test attempts to reproduce specific behavior of NetBeans at the certain toolbar creation stage. Widgets are created on EDT; Another code posts some events to them on EDT; From another thread some code calls explicitly edt.interrupt(). >> Before this got fixed, events from a second code got lost. >> >> This review is for migrating tests from a closed test suite to open. >> Testing: >> 1.Tested the code on jdk7u6 to reproduce the issue - the UI hangs when run on this build. >> 2. Tested the code on jdk7u361 b01 to validate the fix - the test passed. >> 3.Mach5 Testing(40 times per platform) in macos x64, linux x64 and windows x64 - the .results are clean > > test/jdk/java/awt/EventDispatchThread/InterruptEDTTest.java line 55: > >> 53: robot = new Robot(); >> 54: EventQueue.invokeAndWait(() -> { >> 55: edt = Thread.currentThread(); > > Why this adding listener code etc in EDT? It is just the registering of frame to the listener is on EDT and this should not impact the invocation of the listener callback method at runtime. ------------- PR: https://git.openjdk.org/jdk/pull/10784 From smandalika at openjdk.org Thu Nov 3 08:00:40 2022 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Thu, 3 Nov 2022 08:00:40 GMT Subject: RFR: 8295707: Create a regression test for JDK-7184401 In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 14:05:36 GMT, lawrence.andrews wrote: >> 8295707: Create a regression test for JDK-7184401 >> >> JDK-7184401 - JDk7u6 : Missing main menu bar in Netbeans after fix for 7162144 >> Above bug got introduced due to a fix for [JDK-7162144](https://bugs.openjdk.java.net/browse/JDK-7162144). >> The issue was observed on the netbeans UI. >> The test below recreates a standalone test to mimic the failure reported in Netbeans in [JDK-7184401](https://bugs.openjdk.java.net/browse/JDK-7184401) and verifies that it is working as expected after it got fixed via [JDK-7189350](https://bugs.openjdk.java.net/browse/JDK-7189350)) >> >> The Test attempts to reproduce specific behavior of NetBeans at the certain toolbar creation stage. Widgets are created on EDT; Another code posts some events to them on EDT; From another thread some code calls explicitly edt.interrupt(). >> Before this got fixed, events from a second code got lost. >> >> This review is for migrating tests from a closed test suite to open. >> Testing: >> 1.Tested the code on jdk7u6 to reproduce the issue - the UI hangs when run on this build. >> 2. Tested the code on jdk7u361 b01 to validate the fix - the test passed. >> 3.Mach5 Testing(40 times per platform) in macos x64, linux x64 and windows x64 - the .results are clean > > test/jdk/java/awt/EventDispatchThread/InterruptEDTTest.java line 86: > >> 84: ((sun.awt.SunToolkit) (Toolkit.getDefaultToolkit())).realSync(); >> 85: try { >> 86: EventQueue.invokeAndWait(() -> { > > This is duplicate code in Line# 67 to Line# 72. The intent was to ensure latest values are picked up, thereby ensuring the stability of the code. But I see the point that it does add value since there is not change in the frame position. Will remove it. ------------- PR: https://git.openjdk.org/jdk/pull/10784 From smandalika at openjdk.org Thu Nov 3 08:11:05 2022 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Thu, 3 Nov 2022 08:11:05 GMT Subject: RFR: 8295707: Create a regression test for JDK-7184401 In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 14:07:02 GMT, lawrence.andrews wrote: >> 8295707: Create a regression test for JDK-7184401 >> >> JDK-7184401 - JDk7u6 : Missing main menu bar in Netbeans after fix for 7162144 >> Above bug got introduced due to a fix for [JDK-7162144](https://bugs.openjdk.java.net/browse/JDK-7162144). >> The issue was observed on the netbeans UI. >> The test below recreates a standalone test to mimic the failure reported in Netbeans in [JDK-7184401](https://bugs.openjdk.java.net/browse/JDK-7184401) and verifies that it is working as expected after it got fixed via [JDK-7189350](https://bugs.openjdk.java.net/browse/JDK-7189350)) >> >> The Test attempts to reproduce specific behavior of NetBeans at the certain toolbar creation stage. Widgets are created on EDT; Another code posts some events to them on EDT; From another thread some code calls explicitly edt.interrupt(). >> Before this got fixed, events from a second code got lost. >> >> This review is for migrating tests from a closed test suite to open. >> Testing: >> 1.Tested the code on jdk7u6 to reproduce the issue - the UI hangs when run on this build. >> 2. Tested the code on jdk7u361 b01 to validate the fix - the test passed. >> 3.Mach5 Testing(40 times per platform) in macos x64, linux x64 and windows x64 - the .results are clean > > test/jdk/java/awt/EventDispatchThread/InterruptEDTTest.java line 92: > >> 90: height = frame.getHeight(); >> 91: }); >> 92: robot.mouseMove(xLocation + width / 3, yLocation + height / 3); > > Line# 75 robot.mouseMove is called with in EDT? but where as here its not. Is there any reason for not invoking this in EDT ? Yes. Lie #75 on EDT via the invokeLater call , followed by the interrupt() call on the EDT is intentional. This mimics the Netbeans actions which caused a failure 1.Widgets are created on EDT; (Frame creation) 2. another code posts some events to them on EDT(Robot actions on Line 75 on EDT via the invokeLater) From another thread some code calls explicitly edt.interrupt(). 3. Above steps causes a hang on jdk7u6 build, while the later builds it is passing. 4. Line# 92 is simply an additional validation of the code not being hanged until now and proceeding ahead in the flow. ------------- PR: https://git.openjdk.org/jdk/pull/10784 From aivanov at openjdk.org Thu Nov 3 11:18:26 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 3 Nov 2022 11:18:26 GMT Subject: RFR: 8295774: Write a test to verify List sends ItemEvent/ActionEvent [v5] In-Reply-To: References: Message-ID: <6ELXoru3I_P-1XRrpU2vFeoNIk06vRIrzyHaU8nWs90=.37608cd7-9e17-496d-9791-9fb319104297@github.com> On Thu, 3 Nov 2022 05:01:35 GMT, ravi gupta wrote: >> This testcase verify that List Item selection via mouse/keys generates ItemEvent/ActionEvent appropriately. >> >> a. Single click on the list generate ItemEvent and double click on item generates ActionEvent. >> b. UP/DOWN keys on the list generate ItemEvent and enter key on item generates ActionEvent. >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8295774: Write a test to verify List sends ItemEvent/ActionEvent Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10899 From aivanov at openjdk.org Thu Nov 3 11:18:43 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 3 Nov 2022 11:18:43 GMT Subject: RFR: 6257207: JTable.getDefaultEditor throws NullPointerException [v4] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 03:17:34 GMT, Prasanta Sadhukhan wrote: >> If getDefaultEditor() is called before the JTable model is setup, it results in NPE. >> >> This is because when JTable sets its model, which ends up firing a table changed event. The testcase is listening for tableChanged events and querying the editor. But the editor isn't installed until after the model is set which results in NPE. >> Fix is to ensure initializeLocalVars() which initializes default editor is setup before JTable sets its model. >> >> No regression is observed in jtreg/jck testsuite with this change. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test review fix Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10871 From alexsch at openjdk.org Thu Nov 3 11:20:06 2022 From: alexsch at openjdk.org (Alexander Scherbatiy) Date: Thu, 3 Nov 2022 11:20:06 GMT Subject: RFR: 8295737: macOS: Print content cut off when width > height with portrait orientation In-Reply-To: References: Message-ID: On Fri, 21 Oct 2022 08:42:12 GMT, Alexander Scherbatiy wrote: > A printed content is truncated on macOS if the content paper size width larger than height with portrait orientation or width is less than height with landscape orientation. > > To reproduce the issue run the [CutOffImage](https://bugs.openjdk.org/secure/attachment/101145/CutOffImage.java) sample on MacOS. > > Four rectangles are printed: > 1. size 300x100, portrait orientation > 2. size 300x100, landscape orientation > 3. size 100x300, portrait orientation > 4. size 100x300, landscape orientation > > The first and fourth rectangles are truncated: [cut off content](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf) > > The reason is that NSPrintInfo class does not allow to set paper size and orientation independently. > Setting paper size width large than height changes NSPrintInfo orientation to landscape. > Setting paper size width less than height changes NSPrintInfo orientation to portrait. > Updating NSPrintInfo orientation from landscape to portrait or from portrait to landscape swaps NSPrintInfo paper width and height. > > The Cocoa code that shows NSPrintInfo behavior: > > #import > > int main() > { > NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; > NSApp = [NSApplication sharedApplication]; > > #ifdef __MAC_10_9 // code for SDK 10.9 or newer > #define NS_PORTRAIT NSPaperOrientationPortrait > #define NS_LANDSCAPE NSPaperOrientationLandscape > #else // code for SDK 10.8 or older > #define NS_PORTRAIT NSPortraitOrientation > #define NS_LANDSCAPE NSLandscapeOrientation > #endif > > printf("NS_PORTRAIT: %d\n", NS_PORTRAIT); > printf("NS_LANDSCAPE: %d\n", NS_LANDSCAPE); > > printf("create default print info\n"); > NSPrintInfo* defaultPrintInfo = [[NSPrintInfo sharedPrintInfo] copy]; > NSSize size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > printf("call setUpPrintOperationDefaultValues\n"); > [defaultPrintInfo setUpPrintOperationDefaultValues]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > double w = 300.0; > double h = 100.0; > printf("set size: [%f, %f]\n", w, h); > [defaultPrintInfo setPaperSize:NSMakeSize(w, h)]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > printf("Set NS_PORTRAIT orientation\n"); > [defaultPrintInfo setOrientation: NS_PORTRAIT]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > [NSApp run]; > > [NSApp release]; > [pool release]; > return(EXIT_SUCCESS); > } > > > On macOS Mojave 10.14.5 it prints: > > > NS_PORTRAIT: 0 > NS_LANDSCAPE: 1 > create default print info > orientation: 0, paper size: [612.000000, 792.000000] > call setUpPrintOperationDefaultValues > orientation: 0, paper size: [612.000000, 792.000000] > set size: [300.000000, 100.000000] > orientation: 1, paper size: [300.000000, 100.000000] // orientation flip > Set NS_PORTRAIT orientation > orientation: 0, paper size: [100.000000, 300.000000] // size flip > ``` > > There are four possible cases for printing a rectangle with different size and orientation: > 1. Input: paper size: (w > h), orientation portrait > [dstPrintInfo setPaperSize: NSMakeSize(w, h)] // size: (w, h), orientation: landscape > [dstPrintInfo setOrientation: NS_PORTRAIT] // size: (h, w), orientation: portrait > Note: width and height are swapped > 2. Input: paper size: (w > h), orientation landscape > [dstPrintInfo setPaperSize: NSMakeSize(h, w)] // size: (h, w), orientation: portrait > [dstPrintInfo setOrientation: NS_LANDSCAPE] // size: (w, h), orientation: landscape > 3. Input: paper size: (w < h), orientation portrait > [dstPrintInfo setPaperSize: NSMakeSize(w, h)] // size: (w, h), orientation: portrait > [dstPrintInfo setOrientation: NS_PORTRAIT] // size: (w, h), orientation: portrait > 4. Input: paper size: (w < h), orientation landscape > [dstPrintInfo setPaperSize: NSMakeSize(h, w)] // size: (h, w), orientation: landscape > [dstPrintInfo setOrientation: NS_LANDSCAPE] // size: (h, w), orientation: landscape > Note: width and height are swapped > > Only for cases 1 and 4 the final width and height are swapped. > The proposed fix enlarges height for cases 1 and 4 to not cut the printed rectangle. > > It is not full fix which draws rectangles for cases 1 and 4 in the requested size. > Setting requested size leads that subsequent orientation flips width and height. > The fix only enlarges the truncated area in height direction. The enlarged area in width is preserved as before the fix. > > Printed rectangles before and after the fix: > 1. size 300x100, portrait orientation: [before-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101157/before-fix-1.pdf), [after-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101162/after-fix-1.pdf) > 2. size 300x100, landscape orientation: [before-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101156/before-fix-2.pdf), [after-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101161/after-fix-2.pdf) > 3. size 100x300, portrait orientation: [before-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101155/before-fix-3.pdf), [after-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101160/after-fix-3.pdf) > 4. size 100x300, landscape orientation: [before-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101154/before-fix-4.pdf), [after-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101159/after-fix-4.pdf) > > All four rectangles: [before-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf), [after-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101158/after-fix-all.pdf) This is the comment which I found in the NSPrintInfo.h file from MacOSX sdk: /* Set or get the values of the paper attributes. Because an NSPrintInfo's paper name, paper size, and orientation attributes must be kept consistent, invocation of any of the setting methods in this group may affect the values returned by subsequent invocations of any of the getting methods in this group. For example, paper name and paper size must always agree, and the value returned by -paperSize always takes orientation into account. */ @property (nullable, copy) NSPrinterPaperName paperName; @property NSSize paperSize; @property NSPaperOrientation orientation; macOS Mojave, version 10.14.5 file: `/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Versions/C/Headers/NSPrintInfo.h` ------------- PR: https://git.openjdk.org/jdk/pull/10808 From dfuchs at openjdk.org Thu Nov 3 11:20:03 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 3 Nov 2022 11:20:03 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v4] In-Reply-To: References: Message-ID: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com> > Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. > > The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. > > This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. > > In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. > > In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. > > Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. > > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision: - Update src/java.base/share/classes/java/net/URL.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Update src/java.base/share/classes/java/net/URL.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Update src/java.base/share/classes/java/net/URL.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10874/files - new: https://git.openjdk.org/jdk/pull/10874/files/f6b8a9f9..fc899005 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=02-03 Stats: 8 lines in 1 file changed: 0 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10874/head:pull/10874 PR: https://git.openjdk.org/jdk/pull/10874 From michaelm at openjdk.org Thu Nov 3 11:20:04 2022 From: michaelm at openjdk.org (Michael McMahon) Date: Thu, 3 Nov 2022 11:20:04 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v4] In-Reply-To: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com> References: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com> Message-ID: On Thu, 3 Nov 2022 10:56:28 GMT, Daniel Fuchs wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. >> >> This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. >> >> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. >> >> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. >> >> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. >> >> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 > > Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision: > > - Update src/java.base/share/classes/java/net/URL.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - Update src/java.base/share/classes/java/net/URL.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - Update src/java.base/share/classes/java/net/URL.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> src/java.base/share/classes/java/net/URL.java line 152: > 150: * provide any guarantee about its conformance to the URL > 151: * syntax specification. > 152: *

I wonder do we need a stronger statement about potential incompatibility here (line 149 - 151)? Something to the effect that - due to URI's stricter parsing rules not all existing URL instances can be represented as URI's and some that are may turn out to be opaque unexpectedly instead of hierarchical. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From dfuchs at openjdk.org Thu Nov 3 11:20:05 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 3 Nov 2022 11:20:05 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v4] In-Reply-To: References: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com> Message-ID: On Thu, 3 Nov 2022 10:56:28 GMT, Michael McMahon wrote: >> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision: >> >> - Update src/java.base/share/classes/java/net/URL.java >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - Update src/java.base/share/classes/java/net/URL.java >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - Update src/java.base/share/classes/java/net/URL.java >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > > src/java.base/share/classes/java/net/URL.java line 152: > >> 150: * provide any guarantee about its conformance to the URL >> 151: * syntax specification. >> 152: *

> > I wonder do we need a stronger statement about potential incompatibility here (line 149 - 151)? > > Something to the effect that - due to URI's stricter parsing rules not all existing URL instances can be represented as URI's and some that are may turn out to be opaque unexpectedly instead of hierarchical. That would better go in URL::toURI I think - but AFAICS would only apply if you constructed the URL from one of the deprecated constructors. It's not a bad idea - but given that the CSR has been approved I'd rather track that in a follow up PR. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From dfuchs at openjdk.org Thu Nov 3 11:20:08 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 3 Nov 2022 11:20:08 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v3] In-Reply-To: References: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com> Message-ID: On Thu, 3 Nov 2022 07:42:44 GMT, ExE Boss wrote: >> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Integrated review feedback >> - Merge branch 'master' into deprecate-url-ctor-8294241 >> - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml >> - Merge branch 'master' into deprecate-url-ctor-8294241 >> - Fix whitespace issues >> - 8294241 > > src/java.base/share/classes/java/net/URL.java line 885: > >> 883: @SuppressWarnings("deprecation") >> 884: var result = new URL("jrt", host, port, file, null); >> 885: return result; > > Suggestion: > > return new URL("jrt", host, port, file, null); Ah ! Good point thanks! I have accepted your suggestions. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From aivanov at openjdk.org Thu Nov 3 11:21:20 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 3 Nov 2022 11:21:20 GMT Subject: RFR: 6201035: Document NPE for passing null insets to constructors and methods of several javax.swing.border.* classes [v7] In-Reply-To: <1ppO_1ffr_WXYasbkbI13Tov3Rj92-k4-nR_RDT7W2o=.1a0f6481-3ccf-43f2-af7d-a2160d622aeb@github.com> References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com> <1ppO_1ffr_WXYasbkbI13Tov3Rj92-k4-nR_RDT7W2o=.1a0f6481-3ccf-43f2-af7d-a2160d622aeb@github.com> Message-ID: <_iqEqs-YA3-HXxGevixVJN2gY5Ja-JTUFGrWW71H07Q=.9af60ab6-041c-46b2-9384-62ac6364755d@github.com> On Thu, 3 Nov 2022 03:27:29 GMT, Prasanta Sadhukhan wrote: >> The behavior of MatteBorder constructors taking Insets object as a parameter is undocumented. It would throw NPE if null object is passed to it, which should be documented in the spec. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > AbstractBorder fix Marked as reviewed by aivanov (Reviewer). > Before I can approve this PR, I would like to see the javadoc for border classes (those that are modified) updated so that all of them use _?Reinitializes?_ as the first word in the description instead of _?Reinitialize?_, which aligns with [the javadoc style guide](https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html#styleguide): > > > **Use 3rd person (descriptive) not 2nd person (prescriptive).** > > The description is in 3rd person declarative rather than 2nd person imperative. > > Gets the label. _(preferred)_ > > Get the label. (avoid) Per the comment in JBS, addressing this is deferred to a separate issue? However, I still think it would've been more efficient to handle it here. Anyway, it's approved now. ------------- PR: https://git.openjdk.org/jdk/pull/10740 From duke at openjdk.org Thu Nov 3 12:02:41 2022 From: duke at openjdk.org (Abhishek Kumar) Date: Thu, 3 Nov 2022 12:02:41 GMT Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel [v4] In-Reply-To: References: Message-ID: > While using a JFileChooser with the file selection mode FILES_AND_DIRECTORIES and multiSelection enabled, it is impossible to select a single directory in GTK LAF. > > The condition check has been modified when multiselection is enabled and user has selected single directory. > After the fix the behavior of JFileChooser is similar to other LAFs. > > An automatic test case `test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java` is implemented and checked in CI pipeline. Link is attached in JBS. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Subtest added for file selection mode ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10866/files - new: https://git.openjdk.org/jdk/pull/10866/files/970eca4d..8e7adb1f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10866&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10866&range=02-03 Stats: 129 lines in 1 file changed: 95 ins; 1 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/10866.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10866/head:pull/10866 PR: https://git.openjdk.org/jdk/pull/10866 From duke at openjdk.org Thu Nov 3 12:04:14 2022 From: duke at openjdk.org (Abhishek Kumar) Date: Thu, 3 Nov 2022 12:04:14 GMT Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel [v2] In-Reply-To: References: <8eobdmVaHGFsFgaL6oyv193K0AKZcJ2EDmN1JPJyRyY=.490d48e5-6033-4de5-b455-dbd8affcd1b7@github.com> <3C2MgF_7g8dIAAwmHVMFT6kyzuFZRcWec0TseTNlJs0=.f5cba3e2-dfd2-4f6f-b400-da80601a259b@github.com> Message-ID: On Thu, 27 Oct 2022 09:27:00 GMT, Prasanta Sadhukhan wrote: >>> Can you also please test it works ok (or atleast not regress) for other selection mode FILES_ONLY, DIRECTORIES_ONLY in the test? >> >> Verified for file selection mode of `DIRECTORIES_ONLY`, test passed for all LAFs. >> >> In case of selection mode of `FILES_ONLY`, test is failing for all LAFs. The reason behind this is we are trying to select `Directory `when selection mode is set to `FILES_ONLY`. >> >>> Can you then please enhance the test to iterate for all installed L&Fs? >> >> Updated for all installed LAFs. > >> > Can you also please test it works ok (or atleast not regress) for other selection mode FILES_ONLY, DIRECTORIES_ONLY in the test? >> >> Verified for file selection mode of `DIRECTORIES_ONLY`, test passed for all LAFs. >> >> In case of selection mode of `FILES_ONLY`, test is failing for all LAFs. The reason behind this is we are trying to select `Directory `when selection mode is set to `FILES_ONLY`. > > I guess you can see in folders where you have only files...Testwise, maybe use File.createTempFile for creating files and see.. @prsadhuk As discussed, created the sub-test for all file selection mode. Checked with all LAFs and in CI pipeline, link is added in JBS. ------------- PR: https://git.openjdk.org/jdk/pull/10866 From duke at openjdk.org Thu Nov 3 12:23:41 2022 From: duke at openjdk.org (Renjith Kannath Pariyangad) Date: Thu, 3 Nov 2022 12:23:41 GMT Subject: RFR: 8277775: Fixup bugids in RemoveDropTargetCrashTest.java - add 4357905 Message-ID: <9K6ksfn_s82sl5wwMvngJHJBNSA19QHaBTZsMDE3DxI=.3f67d3b9-9026-4a3b-ad76-7833a128dc0c@github.com> Added reference id 4357905 into RemoveDropTargetCrashTest.java ------------- Commit messages: - JDK-8277775: Fixup bugids in RemoveDropTargetCrashTest.java - add 4357905 Changes: https://git.openjdk.org/jdk/pull/10967/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10967&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8277775 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10967.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10967/head:pull/10967 PR: https://git.openjdk.org/jdk/pull/10967 From duke at openjdk.org Thu Nov 3 12:25:04 2022 From: duke at openjdk.org (ravi gupta) Date: Thu, 3 Nov 2022 12:25:04 GMT Subject: RFR: 8295774: Write a test to verify List sends ItemEvent/ActionEvent [v5] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 05:01:35 GMT, ravi gupta wrote: >> This testcase verify that List Item selection via mouse/keys generates ItemEvent/ActionEvent appropriately. >> >> a. Single click on the list generate ItemEvent and double click on item generates ActionEvent. >> b. UP/DOWN keys on the list generate ItemEvent and enter key on item generates ActionEvent. >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8295774: Write a test to verify List sends ItemEvent/ActionEvent can someone sponsor. ------------- PR: https://git.openjdk.org/jdk/pull/10899 From aefimov at openjdk.org Thu Nov 3 13:05:33 2022 From: aefimov at openjdk.org (Aleksei Efimov) Date: Thu, 3 Nov 2022 13:05:33 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v4] In-Reply-To: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com> References: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com> Message-ID: On Thu, 3 Nov 2022 11:20:03 GMT, Daniel Fuchs wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. >> >> This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. >> >> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. >> >> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. >> >> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. >> >> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 > > Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision: > > - Update src/java.base/share/classes/java/net/URL.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - Update src/java.base/share/classes/java/net/URL.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - Update src/java.base/share/classes/java/net/URL.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> `java.naming` changes looks reasonable to me. Thanks! ------------- Marked as reviewed by aefimov (Committer). PR: https://git.openjdk.org/jdk/pull/10874 From duke at openjdk.org Thu Nov 3 13:41:45 2022 From: duke at openjdk.org (ravi gupta) Date: Thu, 3 Nov 2022 13:41:45 GMT Subject: Integrated: 8295774: Write a test to verify List sends ItemEvent/ActionEvent In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 09:01:53 GMT, ravi gupta wrote: > This testcase verify that List Item selection via mouse/keys generates ItemEvent/ActionEvent appropriately. > > a. Single click on the list generate ItemEvent and double click on item generates ActionEvent. > b. UP/DOWN keys on the list generate ItemEvent and enter key on item generates ActionEvent. > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. This pull request has now been integrated. Changeset: 2a79dfc1 Author: ravi.ra.gupta Committer: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/2a79dfc1f9c419e92aac99f92ef4e40a3471695b Stats: 175 lines in 1 file changed: 175 ins; 0 del; 0 mod 8295774: Write a test to verify List sends ItemEvent/ActionEvent Reviewed-by: serb, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/10899 From michaelm at openjdk.org Thu Nov 3 15:10:37 2022 From: michaelm at openjdk.org (Michael McMahon) Date: Thu, 3 Nov 2022 15:10:37 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v4] In-Reply-To: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com> References: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com> Message-ID: On Thu, 3 Nov 2022 11:20:03 GMT, Daniel Fuchs wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. >> >> This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. >> >> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. >> >> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. >> >> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. >> >> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 > > Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision: > > - Update src/java.base/share/classes/java/net/URL.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - Update src/java.base/share/classes/java/net/URL.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - Update src/java.base/share/classes/java/net/URL.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> Marked as reviewed by michaelm (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10874 From honkar at openjdk.org Thu Nov 3 15:35:05 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 3 Nov 2022 15:35:05 GMT Subject: RFR: JDK-8295685: Update Libpng to 1.6.38 [v5] In-Reply-To: References: Message-ID: > Updated libpng library to v1.6.38. > > Following files have been updated - > > - 12 source code files of libpng > - LICENSE, README, CHANGES, UPDATING text files > - legal/libpng.md Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: text updated ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10953/files - new: https://git.openjdk.org/jdk/pull/10953/files/6fb39567..3dc49a58 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10953&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10953&range=03-04 Stats: 7 lines in 1 file changed: 0 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10953.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10953/head:pull/10953 PR: https://git.openjdk.org/jdk/pull/10953 From dfuchs at openjdk.org Thu Nov 3 15:52:53 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 3 Nov 2022 15:52:53 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v5] In-Reply-To: References: Message-ID: > Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. > > The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. > > This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. > > In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. > > In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. > > Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. > > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Merge branch 'master' into deprecate-url-ctor-8294241 - Update src/java.base/share/classes/java/net/URL.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Update src/java.base/share/classes/java/net/URL.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Update src/java.base/share/classes/java/net/URL.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Integrated review feedback - Merge branch 'master' into deprecate-url-ctor-8294241 - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml - Merge branch 'master' into deprecate-url-ctor-8294241 - Fix whitespace issues - 8294241 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10874/files - new: https://git.openjdk.org/jdk/pull/10874/files/fc899005..b4a73f40 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=03-04 Stats: 42853 lines in 291 files changed: 10793 ins; 30812 del; 1248 mod Patch: https://git.openjdk.org/jdk/pull/10874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10874/head:pull/10874 PR: https://git.openjdk.org/jdk/pull/10874 From azvegint at openjdk.org Thu Nov 3 16:04:32 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 3 Nov 2022 16:04:32 GMT Subject: RFR: JDK-8295685: Update Libpng to 1.6.38 [v5] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 15:35:05 GMT, Harshitha Onkar wrote: >> Updated libpng library to v1.6.38. >> >> Following files have been updated - >> >> - 12 source code files of libpng >> - LICENSE, README, CHANGES, UPDATING text files >> - legal/libpng.md > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > text updated Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10953 From dfuchs at openjdk.org Thu Nov 3 17:22:28 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 3 Nov 2022 17:22:28 GMT Subject: Integrated: 8294241: Deprecate URL public constructors In-Reply-To: References: Message-ID: <4AGCrDQ4XC3UDTwYPRw8OPCbIFPueKKAGAJVb7ulbmM=.d7bc126d-3230-4d27-8519-ff06233dd8d9@github.com> On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs wrote: > Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. > > The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. > > This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. > > In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. > > In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. > > Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. > > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 This pull request has now been integrated. Changeset: 4338f527 Author: Daniel Fuchs URL: https://git.openjdk.org/jdk/commit/4338f527aa81350e3636dcfbcd2eb17ddaad3914 Stats: 853 lines in 82 files changed: 707 ins; 5 del; 141 mod 8294241: Deprecate URL public constructors Reviewed-by: joehw, prr, alanb, aefimov, michaelm ------------- PR: https://git.openjdk.org/jdk/pull/10874 From honkar at openjdk.org Thu Nov 3 18:32:36 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 3 Nov 2022 18:32:36 GMT Subject: Integrated: JDK-8295685: Update Libpng to 1.6.38 In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 16:39:22 GMT, Harshitha Onkar wrote: > Updated libpng library to v1.6.38. > > Following files have been updated - > > - 12 source code files of libpng > - LICENSE, README, CHANGES, UPDATING text files > - legal/libpng.md This pull request has now been integrated. Changeset: b685fc2d Author: Harshitha Onkar Committer: Phil Race URL: https://git.openjdk.org/jdk/commit/b685fc2de4d2847de2d1efaab2890646257ea6d3 Stats: 223 lines in 16 files changed: 91 ins; 35 del; 97 mod 8295685: Update Libpng to 1.6.38 Reviewed-by: prr, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/10953 From prr at openjdk.org Thu Nov 3 20:35:29 2022 From: prr at openjdk.org (Phil Race) Date: Thu, 3 Nov 2022 20:35:29 GMT Subject: RFR: 8294488: Delete KCMS transforms wrappers In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 03:12:55 GMT, Sergey Bylokhov wrote: > This is a request to cleanup the shared code for the colors conversions. That code still uses some wrappers which can be simplified and/or deleted after KCMS removal. For example, each conversion from one color space to another creates 3 wrappers - for the first color profile, the second color profile, and one to combine the first two. But for the lcms library we only need the list of color profiles and rendering intent -> only one transform object can be used. > > The new constructor for the LCMSTransform is [added](https://github.com/openjdk/jdk/pull/10459/files#diff-7448ea8346eb08c6ec1a518e3c3399d7d078a514c07956ee7e8e2b5be3d082e1R77) and now used everywhere: > `LCMSTransform(int renderingIntent, ICC_Profile... profiles)` > It will wrap the `cmsCreateMultiprofileTransform` [function ](https://github.com/openjdk/jdk/pull/10459/files#diff-eed6ddb15e9c5bdab9fc3b3930d5d959966165d9622ddd293e8572489adea98bR202) in LCMS library: > > I tried to preserve the current behavior, and as a result, two "workarounds" are used for the next bugs. > * [JDK-8216369](https://bugs.openjdk.org/browse/JDK-8216369): after the cleanup it became obvious that we use a hardcoded value for the first rendering [intent](https://github.com/openjdk/jdk/pull/10459/files#diff-e3d6eea060882cab00827c00e1a83b0e0a5b2a31fa9a9aa2122841bbd57c4a6dR473). There is a code to fetch the intent from the color profile but I postponed use it for now because some of our built-in profiles use different default intents. > * [JDK-8272860](https://bugs.openjdk.org/browse/JDK-8272860): the old code always fetched some information from the color profile header as result we cache the headers for any profiles we used. This cache workaround the JDK-8272860 while the direct access to the profile via LCMS library could fail. The new code intentionally caches the [header](https://github.com/openjdk/jdk/pull/10459/files#diff-7448ea8346eb08c6ec1a518e3c3399d7d078a514c07956ee7e8e2b5be3d082e1R91). > > Notes: > * The old wrappers used a rendering intent for each intermediate transform, the LCMS use only one intent > * The old wrappers could throw the cmm exception if the rendering intent was not supported. The LCMS ignores unsupported intents and uses some [default](https://github.com/LuaDist/lcms/blob/master/doc/TUTORIAL.TXT#L1094) > * The old wrappers had a way to specify the input and output profiles, the LCMS library uses the first profile as input and the last profile as output. Those parameters are [removed](https://github.com/openjdk/jdk/pull/10459/files#diff-81b49f067b32296497e9e727bda25efe0b7f84fb2c05645eb6b272bfc32469f1L38) > * If at some point the new CMS library will be added it will be easy to integrate it using XXCMS plugin, instead of using some specific library logic in the shared code Closed PR is approved. So if you do the /integrate defer trick I'll take care of the rest. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.org/jdk/pull/10459 From prr at openjdk.org Thu Nov 3 20:39:53 2022 From: prr at openjdk.org (Phil Race) Date: Thu, 3 Nov 2022 20:39:53 GMT Subject: RFR: 8295430: Use cmsDoTransformLineStride instead of cmsDoTransform in the loop In-Reply-To: <0FRqG16zkqljRkLjTq1bplcPpoJAm98eLYvjZdR6g14=.35e8b2b3-defe-4af0-a98f-1fadd358e42d@github.com> References: <0FRqG16zkqljRkLjTq1bplcPpoJAm98eLYvjZdR6g14=.35e8b2b3-defe-4af0-a98f-1fadd358e42d@github.com> Message-ID: <6oVRzVNDBT8OmKAImfE0KT80_Nkl57aPuVZvq225Zzg=.41f4c223-6408-4e55-8a5f-6da0ed99a9c9@github.com> On Wed, 19 Oct 2022 02:59:37 GMT, Sergey Bylokhov wrote: > This is the request to improve the change made by the > [8005530: [lcms] Improve performance of ColorConverOp for default destinations](http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/fd8810d50c99) > > Right now the LCMSTransform mantain the special "imageAtOnce" flags and call cmsDoTransform function in the loop per line to support the gaps betwen the lines in the images . This code can be improved by using one call to cmsDoTransformLineStride. Some discussion about this method can be found [here](https://github.com/mm2/Little-CMS/issues/314), the full [specification](https://github.com/mm2/Little-CMS/blob/master/doc/LittleCMS2.14%20API.pdf): > > > void cmsDoTransformLineStride(cmsHTRANSFORM Transform, > const void* InputBuffer, > void* OutputBuffer, > cmsUInt32Number PixelsPerLine, > cmsUInt32Number LineCount, > cmsUInt32Number BytesPerLineIn, > cmsUInt32Number BytesPerLineOut, > cmsUInt32Number BytesPerPlaneIn, > cmsUInt32Number BytesPerPlaneOut); > > This function translates bitmaps with complex organization. Each bitmap may contain > several lines, and every may have padding. The distance from one line to the next one is > BytesPerLine{In/Out}. In planar formats, each line may hold several planes, each plane may > have padding. Padding of lines and planes should be same across all bitmap. I.e. all lines > in same bitmap have to be padded in same way. This function may be more efficient that > repeated calls to cmsDoTransform(), especially when customized plug-ins are being used. > > Parameters: > > - hTransform: Handle to a color transform object. > - InputBuffer: A pointer to the input bitmap > - OutputBuffer: A pointer to the output bitmap. > - PixelsPerLine: The number of pixels for line, which is same on input and in output. > - LineCount: The number of lines, which is same on input and output > - BytesPerLine{In,Out}: The distance in bytes from one line to the next one. > - BytesPerPlaneIn{In,Out}: The distance in bytes from one plane to the next one inside a line. Only applies > in planar formats. > > > Notes: > - This function is quite efficient, and is used by some plug-ins to give a big > speedup. If you can load whole image to memory and then call this function > over it, it will be much faster than any other approach. > - BytesPerPlaneIn{In,Out} is ignored if the formats used are not planar. Please note > 1-plane planar is indistinguishable from 1-component chunky, so BytesPerPlane is > ignored as well in this case. > - If the image does not have any gaps between the pixels and lines BytesPerLine{} > are equal to the pixel's size * PixelsPerLine. > - To specify padding between pixels, use T_EXTRA() and EXTRA_SH() to specify > extra channels. This all looks good and I see that cmsDoTransform ends up in the same place as cmsDoTransformLineStride so the performance of the "simple" case should be no worse. I am just waiting for my test run to complete before approving. Hmm I wonder if this will have a merge conflict with https://github.com/openjdk/jdk/pull/10459 Probably best to integrate that one FIRST because I need to co-ordinate closed changes there. Then if this one needs a merge you can do it .. which would be tricky for me to deal with for the other one. ------------- PR: https://git.openjdk.org/jdk/pull/10754 From prr at openjdk.org Thu Nov 3 20:44:26 2022 From: prr at openjdk.org (Phil Race) Date: Thu, 3 Nov 2022 20:44:26 GMT Subject: RFR: 8277775: Fixup bugids in RemoveDropTargetCrashTest.java - add 4357905 In-Reply-To: <9K6ksfn_s82sl5wwMvngJHJBNSA19QHaBTZsMDE3DxI=.3f67d3b9-9026-4a3b-ad76-7833a128dc0c@github.com> References: <9K6ksfn_s82sl5wwMvngJHJBNSA19QHaBTZsMDE3DxI=.3f67d3b9-9026-4a3b-ad76-7833a128dc0c@github.com> Message-ID: On Thu, 3 Nov 2022 11:40:33 GMT, Renjith Kannath Pariyangad wrote: > Added reference id 4357905 into RemoveDropTargetCrashTest.java Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10967 From aivanov at openjdk.org Thu Nov 3 21:02:27 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 3 Nov 2022 21:02:27 GMT Subject: RFR: 8277775: Fixup bugids in RemoveDropTargetCrashTest.java - add 4357905 In-Reply-To: <9K6ksfn_s82sl5wwMvngJHJBNSA19QHaBTZsMDE3DxI=.3f67d3b9-9026-4a3b-ad76-7833a128dc0c@github.com> References: <9K6ksfn_s82sl5wwMvngJHJBNSA19QHaBTZsMDE3DxI=.3f67d3b9-9026-4a3b-ad76-7833a128dc0c@github.com> Message-ID: <58cJYoE8pTgdTgVRj6jY2Lv76-BwPjwHNEU4-s2vx64=.c59f471f-d2e1-4c23-bc9a-6409501e10a6@github.com> On Thu, 3 Nov 2022 11:40:33 GMT, Renjith Kannath Pariyangad wrote: > Added reference id 4357905 into RemoveDropTargetCrashTest.java Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10967 From prr at openjdk.org Thu Nov 3 21:34:53 2022 From: prr at openjdk.org (Phil Race) Date: Thu, 3 Nov 2022 21:34:53 GMT Subject: RFR: 6788481: CellEditorListener.editingCanceled is never called In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 07:05:10 GMT, Prasanta Sadhukhan wrote: > When editing of a table cell is canceled, the function editingCanceled of the registered listener CellEditorListener is not called as actionPerformed on ESC key press was not notifying the "cancel" listeners. > Fix is to handle "Cancel" action in actionPerformed() by forwarding the Cancel message from CellEditor to the delegate so that it can call `AbstractCellEditor.fireEditingCanceled(`) which notifies all listeners of cancel event. Marked as reviewed by prr (Reviewer). I assume you ran all JTable tests (at leas) not just this new test. ------------- PR: https://git.openjdk.org/jdk/pull/10964 From prr at openjdk.org Thu Nov 3 21:45:46 2022 From: prr at openjdk.org (Phil Race) Date: Thu, 3 Nov 2022 21:45:46 GMT Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and radio button with GTK LAF for bug4314194. [v2] In-Reply-To: References: Message-ID: On Wed, 19 Oct 2022 07:13:44 GMT, Abhishek Kumar wrote: >> Existing test `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` was not showing colored text for disabled checkbox and radiobutton in GTK LAF. >> >> The fix is to get the disabled state color for checkbox and radiobutton from UIManager if it exists. >> >> Test case `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` has been checked in CI pipeline. Link is attached in JBS. > > Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - ProblemList.txt file merge resolved > - 8295006 entry removed from problem lists > - Fix for disabled checkbox and radiobutton colored text "test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java has been checked" I hope you ran ALL Swing tests .. not just this single one .. ?? ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.org/jdk/pull/10755 From prr at openjdk.org Thu Nov 3 22:05:34 2022 From: prr at openjdk.org (Phil Race) Date: Thu, 3 Nov 2022 22:05:34 GMT Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel installColors and installColorsAndFont are not uninstalled In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 22:52:30 GMT, SWinxy wrote: > Many `installDefaults` methods set the font, foreground, and background on objects but their inverse methods `uninstallDefaults` do not remove them. I've added an inverse method to remove the colors and font to call for the `uninstallDefaults` methods that install defaults. > > `AquaButtonUI` can call its super since it would otherwise be repeated code. `BasicComboBoxUI` (weirdly) installs the properties again when it should be uninstalling them, so I changed. > > I noticed that, in a few subclasses, only one of calls to the super of `installDefaults` and `uninstallDefaults` are made. That is, an overridden `installDefaults` may call its super while the overridden `uninstallDefaults` does not call its super (or vise versa). These classes are: `AquaTabbedPaneUI`, `SynthMenuItemUI`, `SynthSplitPaneUI`, and `XTextAreaPeer`. > > Sorry I couldn't write a test; I wasn't sure how I should have accessed the protected variable aside from creating extending classes for each class that changed. > > See also #6603, where this issue was discovered. Same as Alexey. It looks OK. I was not sure about new public API for the convenience method but we aleady have precedent for these on LookAndFeel. Any BACKPORT would have to be different. I'd like to hear the results of Alexey's testing as the next step. ------------- PR: https://git.openjdk.org/jdk/pull/10565 From prr at openjdk.org Thu Nov 3 22:08:01 2022 From: prr at openjdk.org (Phil Race) Date: Thu, 3 Nov 2022 22:08:01 GMT Subject: RFR: JDK-4305789: BasicToolBarUI: Request conversion of private instance variable In-Reply-To: References: Message-ID: <_awTTPCMNlEawbj2ZT3c_5B3lczEzdBJKN-CYz4ebCw=.faac1fc0-95ca-412f-8b23-3e257e521eca@github.com> On Fri, 16 Sep 2022 13:47:41 GMT, aLiEnHeAd13 wrote: > Fixed Bug JDK-4305789 to support docking to any instantiated JFrame https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4305789 Not only does this require an approved CSR but no good case has been made for this, nor any tests provided. And I am sure we'd want to take a detailed look at whether we want to support this also sure this isn't how we would do it. My take is to close the bug as "will not fix". ------------- Changes requested by prr (Reviewer). PR: https://git.openjdk.org/jdk/pull/10309 From duke at openjdk.org Thu Nov 3 22:09:33 2022 From: duke at openjdk.org (SWinxy) Date: Thu, 3 Nov 2022 22:09:33 GMT Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel installColors and installColorsAndFont are not uninstalled In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 22:52:30 GMT, SWinxy wrote: > Many `installDefaults` methods set the font, foreground, and background on objects but their inverse methods `uninstallDefaults` do not remove them. I've added an inverse method to remove the colors and font to call for the `uninstallDefaults` methods that install defaults. > > `AquaButtonUI` can call its super since it would otherwise be repeated code. `BasicComboBoxUI` (weirdly) installs the properties again when it should be uninstalling them, so I changed. > > I noticed that, in a few subclasses, only one of calls to the super of `installDefaults` and `uninstallDefaults` are made. That is, an overridden `installDefaults` may call its super while the overridden `uninstallDefaults` does not call its super (or vise versa). These classes are: `AquaTabbedPaneUI`, `SynthMenuItemUI`, `SynthSplitPaneUI`, and `XTextAreaPeer`. > > Sorry I couldn't write a test; I wasn't sure how I should have accessed the protected variable aside from creating extending classes for each class that changed. > > See also #6603, where this issue was discovered. Can the CSR be skipped if the methods are made package-private? ------------- PR: https://git.openjdk.org/jdk/pull/10565 From prr at openjdk.org Thu Nov 3 22:19:32 2022 From: prr at openjdk.org (Phil Race) Date: Thu, 3 Nov 2022 22:19:32 GMT Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel installColors and installColorsAndFont are not uninstalled In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 22:07:14 GMT, SWinxy wrote: > Can the CSR be skipped if the methods are made package-private? Well, yes, except you can't do that because they are called from other packages. ------------- PR: https://git.openjdk.org/jdk/pull/10565 From duke at openjdk.org Fri Nov 4 06:20:28 2022 From: duke at openjdk.org (Abhishek Kumar) Date: Fri, 4 Nov 2022 06:20:28 GMT Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and radio button with GTK LAF for bug4314194. [v2] In-Reply-To: References: Message-ID: <1gcOSPJt-Dir3Mggqtb9e3LTdPKySj40XnR8RwNmjpU=.40f7e958-9a15-4697-b1fc-9da7dc71de33@github.com> On Thu, 3 Nov 2022 21:43:01 GMT, Phil Race wrote: > "test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java has been checked" > > I hope you ran ALL Swing tests .. not just this single one .. ?? Yeah, I ran all swing tests. ------------- PR: https://git.openjdk.org/jdk/pull/10755 From psadhukhan at openjdk.org Fri Nov 4 06:33:41 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 4 Nov 2022 06:33:41 GMT Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel [v4] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 12:02:41 GMT, Abhishek Kumar wrote: >> While using a JFileChooser with the file selection mode FILES_AND_DIRECTORIES and multiSelection enabled, it is impossible to select a single directory in GTK LAF. >> >> The condition check has been modified when multiselection is enabled and user has selected single directory. >> After the fix the behavior of JFileChooser is similar to other LAFs. >> >> An automatic test case `test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java` is implemented and checked in CI pipeline. Link is attached in JBS. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Subtest added for file selection mode test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 113: > 111: clickMouse(frameLocation, 0, frameHeight, 230); > 112: clickMouse(btnLocation, btnWidth, btnHeight, 0); > 113: checkResult(laf); I guess you can optimise by a helper method for this repeated code passing the offset value as paramter. Also, did you check [JDK-4912623](https://bugs.openjdk.org/browse/JDK-4912623) as mentioned? ------------- PR: https://git.openjdk.org/jdk/pull/10866 From psadhukhan at openjdk.org Fri Nov 4 06:33:43 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 4 Nov 2022 06:33:43 GMT Subject: RFR: 8285635: javax/swing/JRootPane/DefaultButtonTest.java failed with Default Button not pressed for L&F: com.sun.java.swing.plaf.motif.MotifLookAndFeel Message-ID: Test sometimes fail for Motif L&F only which might require some code change in Motif code but since Motif is already deprecated and obsolete, it seems prudent to skip Motif L&F in the test. Several iterations of the modified test pass in all platforms. ------------- Commit messages: - 8285635: javax/swing/JRootPane/DefaultButtonTest.java failed with Default Button not pressed for L&F: com.sun.java.swing.plaf.motif.MotifLookAndFeel Changes: https://git.openjdk.org/jdk/pull/10978/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10978&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8285635 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10978.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10978/head:pull/10978 PR: https://git.openjdk.org/jdk/pull/10978 From icehellmelissicka at gmail.com Fri Nov 4 09:31:26 2022 From: icehellmelissicka at gmail.com (Melissa Nicholson) Date: Fri, 4 Nov 2022 04:31:26 -0500 Subject: No subject Message-ID: Stop you can't kill the president. Of USA -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Nov 4 09:56:36 2022 From: duke at openjdk.org (Abhishek Kumar) Date: Fri, 4 Nov 2022 09:56:36 GMT Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel [v5] In-Reply-To: References: Message-ID: > While using a JFileChooser with the file selection mode FILES_AND_DIRECTORIES and multiSelection enabled, it is impossible to select a single directory in GTK LAF. > > The condition check has been modified when multiselection is enabled and user has selected single directory. > After the fix the behavior of JFileChooser is similar to other LAFs. > > An automatic test case `test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java` is implemented and checked in CI pipeline. Link is attached in JBS. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Review comment fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10866/files - new: https://git.openjdk.org/jdk/pull/10866/files/8e7adb1f..0b7d1a6e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10866&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10866&range=03-04 Stats: 43 lines in 1 file changed: 13 ins; 27 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10866.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10866/head:pull/10866 PR: https://git.openjdk.org/jdk/pull/10866 From duke at openjdk.org Fri Nov 4 10:04:44 2022 From: duke at openjdk.org (Abhishek Kumar) Date: Fri, 4 Nov 2022 10:04:44 GMT Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel [v4] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 06:29:31 GMT, Prasanta Sadhukhan wrote: >> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> Subtest added for file selection mode > > test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 113: > >> 111: clickMouse(frameLocation, 0, frameHeight, 230); >> 112: clickMouse(btnLocation, btnWidth, btnHeight, 0); >> 113: checkResult(laf); > > I guess you can optimise by a helper method for this repeated code passing the offset value as paramter. > > Also, did you check [JDK-4912623](https://bugs.openjdk.org/browse/JDK-4912623) as mentioned? Added a helper method for the repeated code. I tried to reproduce the [JDK-4912623](https://bugs.openjdk.org/browse/JDK-4912623) bug. SwingSet2 JFileChooser demo behaves as it is mentioned in the bug description but in Gedit I didn't find separate folder and files list. ------------- PR: https://git.openjdk.org/jdk/pull/10866 From psadhukhan at openjdk.org Fri Nov 4 10:09:40 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 4 Nov 2022 10:09:40 GMT Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel [v4] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 10:00:48 GMT, Abhishek Kumar wrote: >> test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 113: >> >>> 111: clickMouse(frameLocation, 0, frameHeight, 230); >>> 112: clickMouse(btnLocation, btnWidth, btnHeight, 0); >>> 113: checkResult(laf); >> >> I guess you can optimise by a helper method for this repeated code passing the offset value as paramter. >> >> Also, did you check [JDK-4912623](https://bugs.openjdk.org/browse/JDK-4912623) as mentioned? > > Added a helper method for the repeated code. > > I tried to reproduce the [JDK-4912623](https://bugs.openjdk.org/browse/JDK-4912623) bug. SwingSet2 JFileChooser demo behaves as it is mentioned in the bug description but in Gedit I didn't find separate folder and files list. The bug says 2) Go to FileChooser Demo. 3) Tab to Folder List 4) Press CTRL+A. It will select all the items in the list. 5) Now Tab to file list and press ctrl+A, it will not select all the items. 6) Now Open Gedit. 7) Click Open. 8) Repeat the steps 3 to 5. Behaviour for the native will be opposite to its Java counterpart. so you can create manually folder with only files and a folder with only folders and then try with Gedit to open those folders and trey the steps... ------------- PR: https://git.openjdk.org/jdk/pull/10866 From duke at openjdk.org Fri Nov 4 10:34:26 2022 From: duke at openjdk.org (Abhishek Kumar) Date: Fri, 4 Nov 2022 10:34:26 GMT Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel [v4] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 10:07:05 GMT, Prasanta Sadhukhan wrote: > The bug says 2) Go to FileChooser Demo. 3) Tab to Folder List 4) Press CTRL+A. It will select all the items in the list. 5) Now Tab to file list and press ctrl+A, it will not select all the items. 6) Now Open Gedit. 7) Click Open. 8) Repeat the steps 3 to 5. Behaviour for the native will be opposite to its Java counterpart. > > so you can create manually folder with only files and a folder with only folders and then try with Gedit to open those folders and trey the steps... I tried these steps, I am able to select all directories and all files in respective folder on press of Ctrl+A in Gedit. ------------- PR: https://git.openjdk.org/jdk/pull/10866 From psadhukhan at openjdk.org Fri Nov 4 10:41:23 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 4 Nov 2022 10:41:23 GMT Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel [v4] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 10:30:37 GMT, Abhishek Kumar wrote: >> The bug says >> 2) Go to FileChooser Demo. >> 3) Tab to Folder List >> 4) Press CTRL+A. It will select all the items in the list. >> 5) Now Tab to file list and press ctrl+A, it will not select all the items. >> 6) Now Open Gedit. >> 7) Click Open. >> 8) Repeat the steps 3 to 5. Behaviour for the native will be opposite to its Java counterpart. >> >> so you can create manually folder with only files and a folder with only folders and then try with Gedit to open those folders and trey the steps... > >> The bug says 2) Go to FileChooser Demo. 3) Tab to Folder List 4) Press CTRL+A. It will select all the items in the list. 5) Now Tab to file list and press ctrl+A, it will not select all the items. 6) Now Open Gedit. 7) Click Open. 8) Repeat the steps 3 to 5. Behaviour for the native will be opposite to its Java counterpart. >> >> so you can create manually folder with only files and a folder with only folders and then try with Gedit to open those folders and trey the steps... > > I tried these steps, I am able to select all directories and all files in respective folder on press of Ctrl+A in Gedit. Is GTK Filechooser not behaving the same as gedit? ie is GTK FileChooser not allowing to select all folders in folder list and all files in files list by CTRL+A with your fix too? ------------- PR: https://git.openjdk.org/jdk/pull/10866 From duke at openjdk.org Fri Nov 4 10:54:24 2022 From: duke at openjdk.org (Abhishek Kumar) Date: Fri, 4 Nov 2022 10:54:24 GMT Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel [v4] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 10:39:02 GMT, Prasanta Sadhukhan wrote: >>> The bug says 2) Go to FileChooser Demo. 3) Tab to Folder List 4) Press CTRL+A. It will select all the items in the list. 5) Now Tab to file list and press ctrl+A, it will not select all the items. 6) Now Open Gedit. 7) Click Open. 8) Repeat the steps 3 to 5. Behaviour for the native will be opposite to its Java counterpart. >>> >>> so you can create manually folder with only files and a folder with only folders and then try with Gedit to open those folders and trey the steps... >> >> I tried these steps, I am able to select all directories and all files in respective folder on press of Ctrl+A in Gedit. > > Is GTK Filechooser not behaving the same as gedit? > ie is GTK FileChooser not allowing to select all folders in folder list and all files in files list by CTRL+A with your fix too? With the current fix, GTK FileChooser allows to select all folders in folder list but in files list it allows only single file selection. ------------- PR: https://git.openjdk.org/jdk/pull/10866 From psadhukhan at openjdk.org Fri Nov 4 11:02:26 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 4 Nov 2022 11:02:26 GMT Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel [v4] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 10:50:28 GMT, Abhishek Kumar wrote: >> Is GTK Filechooser not behaving the same as gedit? >> ie is GTK FileChooser not allowing to select all folders in folder list and all files in files list by CTRL+A with your fix too? > > With the current fix, GTK FileChooser allows to select all folders in folder list but in files list it allows only single file selection. So, it is same without the fix too as is mentioned in that bug. Can you please see why that is so as it should be exercising the same code path as this fix? ------------- PR: https://git.openjdk.org/jdk/pull/10866 From psadhukhan at openjdk.org Fri Nov 4 11:09:30 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 4 Nov 2022 11:09:30 GMT Subject: RFR: 6788481: CellEditorListener.editingCanceled is never called In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 21:32:06 GMT, Phil Race wrote: > I assume you ran all JTable tests (at leas) not just this new test. I normally run the full clientlibs CI job which was ok. ------------- PR: https://git.openjdk.org/jdk/pull/10964 From duke at openjdk.org Fri Nov 4 11:11:24 2022 From: duke at openjdk.org (Abhishek Kumar) Date: Fri, 4 Nov 2022 11:11:24 GMT Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel [v4] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 11:00:10 GMT, Prasanta Sadhukhan wrote: > So, it is same without the fix too as is mentioned in that bug. Yeah, it behaves same without the fix also. ------------- PR: https://git.openjdk.org/jdk/pull/10866 From duke at openjdk.org Fri Nov 4 11:11:24 2022 From: duke at openjdk.org (Abhishek Kumar) Date: Fri, 4 Nov 2022 11:11:24 GMT Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel [v4] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 11:07:11 GMT, Abhishek Kumar wrote: >> So, it is same without the fix too as is mentioned in that bug. Can you please see why that is so as it should be exercising the same code path as this fix? > >> So, it is same without the fix too as is mentioned in that bug. > > Yeah, it behaves same without the fix also. > Can you please see why that is so as it should be exercising the same code path as this fix? Ok, I will check. ------------- PR: https://git.openjdk.org/jdk/pull/10866 From duke at openjdk.org Fri Nov 4 12:38:07 2022 From: duke at openjdk.org (Renjith Kannath Pariyangad) Date: Fri, 4 Nov 2022 12:38:07 GMT Subject: Integrated: 8277775: Fixup bugids in RemoveDropTargetCrashTest.java - add 4357905 In-Reply-To: <9K6ksfn_s82sl5wwMvngJHJBNSA19QHaBTZsMDE3DxI=.3f67d3b9-9026-4a3b-ad76-7833a128dc0c@github.com> References: <9K6ksfn_s82sl5wwMvngJHJBNSA19QHaBTZsMDE3DxI=.3f67d3b9-9026-4a3b-ad76-7833a128dc0c@github.com> Message-ID: On Thu, 3 Nov 2022 11:40:33 GMT, Renjith Kannath Pariyangad wrote: > Added reference id 4357905 into RemoveDropTargetCrashTest.java This pull request has now been integrated. Changeset: 22347e46 Author: Renjith Committer: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/22347e46f7e66a864ea987fa084c44792cae2e6a Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8277775: Fixup bugids in RemoveDropTargetCrashTest.java - add 4357905 Reviewed-by: prr, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/10967 From duke at openjdk.org Fri Nov 4 17:50:31 2022 From: duke at openjdk.org (duke) Date: Fri, 4 Nov 2022 17:50:31 GMT Subject: Withdrawn: 8292271 : Fix java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java test In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 17:00:25 GMT, lawrence.andrews wrote: > 1) This test was failing due to yesno > test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno > 2) PrintCheckboxManualTest.html file was missing > 3) Added os.family since test instruction says that its a linux and solair toolkit only test > 4) Removed Sysout & TestDialog class & added a better manual framework to show the instruction and test frame. > > @shurymury This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9858 From azvegint at openjdk.org Fri Nov 4 18:19:29 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 4 Nov 2022 18:19:29 GMT Subject: RFR: 6788481: CellEditorListener.editingCanceled is never called In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 07:05:10 GMT, Prasanta Sadhukhan wrote: > When editing of a table cell is canceled, the function editingCanceled of the registered listener CellEditorListener is not called as actionPerformed on ESC key press was not notifying the "cancel" listeners. > Fix is to handle "Cancel" action in actionPerformed() by forwarding the Cancel message from CellEditor to the delegate so that it can call `AbstractCellEditor.fireEditingCanceled(`) which notifies all listeners of cancel event. Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10964 From aivanov at openjdk.org Fri Nov 4 18:33:42 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 4 Nov 2022 18:33:42 GMT Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of JInternalFrame [v11] In-Reply-To: <1T21tMiVjVBLFw5lOCScck46i9MSse56klmgbWRrsks=.de04fd0d-c624-4aa9-9277-6e8be6877a45@github.com> References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com> <1T21tMiVjVBLFw5lOCScck46i9MSse56klmgbWRrsks=.de04fd0d-c624-4aa9-9277-6e8be6877a45@github.com> Message-ID: On Fri, 21 Oct 2022 22:21:09 GMT, Harshitha Onkar wrote: >> JInternalFrame background color seems to overflow into the border region. This issue is more prominently seen on Windows - Metal LAF (with fractional scaling, as shown below). The primary reason is border scaling issue as observed in - [JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614) >> >> The fix involves a similar approach as described here https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648. The test checks the midpoint and corners of borders to check if the internal frame's background color is located out of JInternalFrame. >> >> ![image](https://user-images.githubusercontent.com/95945681/190233555-a7e00f2c-9003-4c11-84fb-207957838c2f.png) > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > new x,y and translate component added to fix pixel painting issue Changes requested by aivanov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10274 From aivanov at openjdk.org Fri Nov 4 18:33:43 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 4 Nov 2022 18:33:43 GMT Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of JInternalFrame [v8] In-Reply-To: <1hPZXAFjEQ-JH2bQ_ZPAQt2ZR--EABys-P_KLP6eg7Q=.e4c4ef5d-4a84-4ca9-948a-1289cca7eb4b@github.com> References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com> <1hPZXAFjEQ-JH2bQ_ZPAQt2ZR--EABys-P_KLP6eg7Q=.e4c4ef5d-4a84-4ca9-948a-1289cca7eb4b@github.com> Message-ID: On Fri, 7 Oct 2022 17:25:32 GMT, Harshitha Onkar wrote: >> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 256: >> >>> 254: * @return the rounded value >>> 255: */ >>> 256: private static int roundHalfDown(double d) { >> >> The sun.java2d.pipe.Region#clipRound() seems have the same purpose, but it also clip the double to int. > > @mrserb Thank you for the suggestion. I guess `roundHalfDown` has been replaced with `Region.clipRound`, so it needs to be removed. ------------- PR: https://git.openjdk.org/jdk/pull/10274 From honkar at openjdk.org Fri Nov 4 18:42:14 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 4 Nov 2022 18:42:14 GMT Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of JInternalFrame [v9] In-Reply-To: References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com> Message-ID: On Wed, 12 Oct 2022 21:16:47 GMT, Sergey Bylokhov wrote: >> @mrserb Thank for the suggestion. Are you suggesting that same transformations be applied for width, height and additionally to x&y translations? >> https://github.com/openjdk/jdk/blob/ec4fb47b90c9737dfdc285ebe98367a221c90c79/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L373 > > The methods like Rigion.dimAdd/clipScale should be used everywhere the overflow is possible. > Thank you, @mrserb, for your suggestion. I didn't know about those methods. > > We already have [JDK-8294680](https://bugs.openjdk.org/browse/JDK-8294680) to refactor this code. If you don't object, I'd rather postpone updating the calculations to a later time. We should absolutely re-use the existing code if it does the same thing. @aivanov-jdk I think we decided to retain roundHalfDown and make the changes when refactoring the code. ------------- PR: https://git.openjdk.org/jdk/pull/10274 From aivanov at openjdk.org Fri Nov 4 19:04:35 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 4 Nov 2022 19:04:35 GMT Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of JInternalFrame [v9] In-Reply-To: References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com> Message-ID: On Wed, 12 Oct 2022 21:16:47 GMT, Sergey Bylokhov wrote: >> @mrserb Thank for the suggestion. Are you suggesting that same transformations be applied for width, height and additionally to x&y translations? >> https://github.com/openjdk/jdk/blob/ec4fb47b90c9737dfdc285ebe98367a221c90c79/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L373 > > The methods like Rigion.dimAdd/clipScale should be used everywhere the overflow is possible. > > Thank you, @mrserb, for your suggestion. I didn't know about those methods. > > We already have [JDK-8294680](https://bugs.openjdk.org/browse/JDK-8294680) to refactor this code. If you don't object, I'd rather postpone updating the calculations to a later time. We should absolutely re-use the existing code if it does the same thing. > > @aivanov-jdk I think we decided to retain roundHalfDown and make the changes when refactoring the code. The comment above is about `Rigion.dimAdd` and `Rigion.clipScale`. As for `roundHalfDown`, you had replaced it with `Region.clipRound`. When I was reading the code, I got the impression that you used `Region.clipRound` everywhere but one place. Eventually, I see you've reverted that change, and you're using `roundHalfDown` with no trace of `clipRound` left to be found. What I saw must have been coming from code comments rather than the real code. [The comment above](https://github.com/openjdk/jdk/pull/10274#discussion_r990278757) confirms that using `Region.clipRound` gives the same result: > > The sun.java2d.pipe.Region#clipRound() seems have the same purpose, but it also clip the double to int. > > ? It's better to re-use the existing implementation. I tested with it, it gives the same result. It went into #10681. I just missed that you had reverted it back. I guess it's not worth re-doing it once again. We'll handle it in [JDK-8294680](https://bugs.openjdk.org/browse/JDK-8294680) too. ------------- PR: https://git.openjdk.org/jdk/pull/10274 From aivanov at openjdk.org Fri Nov 4 19:13:13 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 4 Nov 2022 19:13:13 GMT Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of JInternalFrame [v11] In-Reply-To: <1T21tMiVjVBLFw5lOCScck46i9MSse56klmgbWRrsks=.de04fd0d-c624-4aa9-9277-6e8be6877a45@github.com> References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com> <1T21tMiVjVBLFw5lOCScck46i9MSse56klmgbWRrsks=.de04fd0d-c624-4aa9-9277-6e8be6877a45@github.com> Message-ID: On Fri, 21 Oct 2022 22:21:09 GMT, Harshitha Onkar wrote: >> JInternalFrame background color seems to overflow into the border region. This issue is more prominently seen on Windows - Metal LAF (with fractional scaling, as shown below). The primary reason is border scaling issue as observed in - [JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614) >> >> The fix involves a similar approach as described here https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648. The test checks the midpoint and corners of borders to check if the internal frame's background color is located out of JInternalFrame. >> >> ![image](https://user-images.githubusercontent.com/95945681/190233555-a7e00f2c-9003-4c11-84fb-207957838c2f.png) > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > new x,y and translate component added to fix pixel painting issue Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10274 From honkar at openjdk.org Fri Nov 4 19:13:15 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 4 Nov 2022 19:13:15 GMT Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of JInternalFrame [v9] In-Reply-To: References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com> Message-ID: On Fri, 4 Nov 2022 19:02:05 GMT, Alexey Ivanov wrote: >> The methods like Rigion.dimAdd/clipScale should be used everywhere the overflow is possible. > >> > Thank you, @mrserb, for your suggestion. I didn't know about those methods. >> > We already have [JDK-8294680](https://bugs.openjdk.org/browse/JDK-8294680) to refactor this code. If you don't object, I'd rather postpone updating the calculations to a later time. We should absolutely re-use the existing code if it does the same thing. >> >> @aivanov-jdk I think we decided to retain roundHalfDown and make the changes when refactoring the code. > > The comment above is about `Rigion.dimAdd` and `Rigion.clipScale`. > > As for `roundHalfDown`, you had replaced it with `Region.clipRound`. When I was reading the code, I got the impression that you used `Region.clipRound` everywhere but one place. Eventually, I see you've reverted that change, and you're using `roundHalfDown` with no trace of `clipRound` left to be found. > > What I saw must have been coming from code comments rather than the real code. > > [The comment above](https://github.com/openjdk/jdk/pull/10274#discussion_r990278757) confirms that using `Region.clipRound` gives the same result: > >> > The sun.java2d.pipe.Region#clipRound() seems have the same purpose, but it also clip the double to int. >> >> ? It's better to re-use the existing implementation. I tested with it, it gives the same result. > > It went into #10681. > > I just missed that you had reverted it back. > > I guess it's not worth re-doing it once again. We'll handle it in [JDK-8294680](https://bugs.openjdk.org/browse/JDK-8294680) too. Sounds good. I'll have it updated during [JDK-8294680](https://bugs.openjdk.org/browse/JDK-8294680) changes. ------------- PR: https://git.openjdk.org/jdk/pull/10274 From honkar at openjdk.org Fri Nov 4 19:52:27 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 4 Nov 2022 19:52:27 GMT Subject: Integrated: JDK-8015739: Background of JInternalFrame is located out of JInternalFrame In-Reply-To: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com> References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com> Message-ID: On Wed, 14 Sep 2022 18:33:47 GMT, Harshitha Onkar wrote: > JInternalFrame background color seems to overflow into the border region. This issue is more prominently seen on Windows - Metal LAF (with fractional scaling, as shown below). The primary reason is border scaling issue as observed in - [JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614) > > The fix involves a similar approach as described here https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648. The test checks the midpoint and corners of borders to check if the internal frame's background color is located out of JInternalFrame. > > ![image](https://user-images.githubusercontent.com/95945681/190233555-a7e00f2c-9003-4c11-84fb-207957838c2f.png) This pull request has now been integrated. Changeset: f857f795 Author: Harshitha Onkar Committer: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/f857f795a9fc8b116bfc6b039114051061950e28 Stats: 408 lines in 2 files changed: 360 ins; 8 del; 40 mod 8015739: Background of JInternalFrame is located out of JInternalFrame Reviewed-by: kizune, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/10274 From duke at openjdk.org Fri Nov 4 20:24:53 2022 From: duke at openjdk.org (lawrence.andrews) Date: Fri, 4 Nov 2022 20:24:53 GMT Subject: RFR: 8296335 : Fix accessibility manual test instruction Message-ID: Fixed test instruction that helps the manual tester to perform actions @shurymury ------------- Commit messages: - 8296335 : Fix accessibility manual test instruction Changes: https://git.openjdk.org/jdk/pull/10996/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10996&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296335 Stats: 8 lines in 5 files changed: 0 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10996.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10996/head:pull/10996 PR: https://git.openjdk.org/jdk/pull/10996 From prr at openjdk.org Fri Nov 4 20:38:28 2022 From: prr at openjdk.org (Phil Race) Date: Fri, 4 Nov 2022 20:38:28 GMT Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel installColors and installColorsAndFont are not uninstalled In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 22:52:30 GMT, SWinxy wrote: > Many `installDefaults` methods set the font, foreground, and background on objects but their inverse methods `uninstallDefaults` do not remove them. I've added an inverse method to remove the colors and font to call for the `uninstallDefaults` methods that install defaults. > > `AquaButtonUI` can call its super since it would otherwise be repeated code. `BasicComboBoxUI` (weirdly) installs the properties again when it should be uninstalling them, so I changed. > > I noticed that, in a few subclasses, only one of calls to the super of `installDefaults` and `uninstallDefaults` are made. That is, an overridden `installDefaults` may call its super while the overridden `uninstallDefaults` does not call its super (or vise versa). These classes are: `AquaTabbedPaneUI`, `SynthMenuItemUI`, `SynthSplitPaneUI`, and `XTextAreaPeer`. > > Sorry I couldn't write a test; I wasn't sure how I should have accessed the protected variable aside from creating extending classes for each class that changed. > > See also #6603, where this issue was discovered. You could move the methods to some internal place like SwingUtilities2.java. It would just seem very inconsistent with all the others. But that's what you'd have to do for any backport that wanted the same "fix" to those L&Fs. ------------- PR: https://git.openjdk.org/jdk/pull/10565 From prr at openjdk.org Fri Nov 4 20:43:38 2022 From: prr at openjdk.org (Phil Race) Date: Fri, 4 Nov 2022 20:43:38 GMT Subject: RFR: 8296335 : Fix accessibility manual test instruction In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 20:18:09 GMT, lawrence.andrews wrote: > Fixed test instruction that helps the manual tester to perform actions > > @shurymury Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10996 From serb at openjdk.org Fri Nov 4 21:01:09 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 4 Nov 2022 21:01:09 GMT Subject: Integrated: 8294488: Delete KCMS transforms wrappers In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 03:12:55 GMT, Sergey Bylokhov wrote: > This is a request to cleanup the shared code for the colors conversions. That code still uses some wrappers which can be simplified and/or deleted after KCMS removal. For example, each conversion from one color space to another creates 3 wrappers - for the first color profile, the second color profile, and one to combine the first two. But for the lcms library we only need the list of color profiles and rendering intent -> only one transform object can be used. > > The new constructor for the LCMSTransform is [added](https://github.com/openjdk/jdk/pull/10459/files#diff-7448ea8346eb08c6ec1a518e3c3399d7d078a514c07956ee7e8e2b5be3d082e1R77) and now used everywhere: > `LCMSTransform(int renderingIntent, ICC_Profile... profiles)` > It will wrap the `cmsCreateMultiprofileTransform` [function ](https://github.com/openjdk/jdk/pull/10459/files#diff-eed6ddb15e9c5bdab9fc3b3930d5d959966165d9622ddd293e8572489adea98bR202) in LCMS library: > > I tried to preserve the current behavior, and as a result, two "workarounds" are used for the next bugs. > * [JDK-8216369](https://bugs.openjdk.org/browse/JDK-8216369): after the cleanup it became obvious that we use a hardcoded value for the first rendering [intent](https://github.com/openjdk/jdk/pull/10459/files#diff-e3d6eea060882cab00827c00e1a83b0e0a5b2a31fa9a9aa2122841bbd57c4a6dR473). There is a code to fetch the intent from the color profile but I postponed use it for now because some of our built-in profiles use different default intents. > * [JDK-8272860](https://bugs.openjdk.org/browse/JDK-8272860): the old code always fetched some information from the color profile header as result we cache the headers for any profiles we used. This cache workaround the JDK-8272860 while the direct access to the profile via LCMS library could fail. The new code intentionally caches the [header](https://github.com/openjdk/jdk/pull/10459/files#diff-7448ea8346eb08c6ec1a518e3c3399d7d078a514c07956ee7e8e2b5be3d082e1R91). > > Notes: > * The old wrappers used a rendering intent for each intermediate transform, the LCMS use only one intent > * The old wrappers could throw the cmm exception if the rendering intent was not supported. The LCMS ignores unsupported intents and uses some [default](https://github.com/LuaDist/lcms/blob/master/doc/TUTORIAL.TXT#L1094) > * The old wrappers had a way to specify the input and output profiles, the LCMS library uses the first profile as input and the last profile as output. Those parameters are [removed](https://github.com/openjdk/jdk/pull/10459/files#diff-81b49f067b32296497e9e727bda25efe0b7f84fb2c05645eb6b272bfc32469f1L38) > * If at some point the new CMS library will be added it will be easy to integrate it using XXCMS plugin, instead of using some specific library logic in the shared code This pull request has now been integrated. Changeset: d8573b2c Author: Sergey Bylokhov Committer: Phil Race URL: https://git.openjdk.org/jdk/commit/d8573b2c5bd235a3cc6442b6bda8d1bd2da495a0 Stats: 282 lines in 9 files changed: 18 ins; 175 del; 89 mod 8294488: Delete KCMS transforms wrappers Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/10459 From prr at openjdk.org Fri Nov 4 21:02:42 2022 From: prr at openjdk.org (Phil Race) Date: Fri, 4 Nov 2022 21:02:42 GMT Subject: RFR: 8295430: Use cmsDoTransformLineStride instead of cmsDoTransform in the loop In-Reply-To: <0FRqG16zkqljRkLjTq1bplcPpoJAm98eLYvjZdR6g14=.35e8b2b3-defe-4af0-a98f-1fadd358e42d@github.com> References: <0FRqG16zkqljRkLjTq1bplcPpoJAm98eLYvjZdR6g14=.35e8b2b3-defe-4af0-a98f-1fadd358e42d@github.com> Message-ID: <1pSR37pcaYjAfv2lRT5PauM_sA_j44PKweAxAkhQRjM=.10b934ef-5c54-451d-9c17-dd56e41228fe@github.com> On Wed, 19 Oct 2022 02:59:37 GMT, Sergey Bylokhov wrote: > This is the request to improve the change made by the > [8005530: [lcms] Improve performance of ColorConverOp for default destinations](http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/fd8810d50c99) > > Right now the LCMSTransform mantain the special "imageAtOnce" flags and call cmsDoTransform function in the loop per line to support the gaps betwen the lines in the images . This code can be improved by using one call to cmsDoTransformLineStride. Some discussion about this method can be found [here](https://github.com/mm2/Little-CMS/issues/314), the full [specification](https://github.com/mm2/Little-CMS/blob/master/doc/LittleCMS2.14%20API.pdf): > > > void cmsDoTransformLineStride(cmsHTRANSFORM Transform, > const void* InputBuffer, > void* OutputBuffer, > cmsUInt32Number PixelsPerLine, > cmsUInt32Number LineCount, > cmsUInt32Number BytesPerLineIn, > cmsUInt32Number BytesPerLineOut, > cmsUInt32Number BytesPerPlaneIn, > cmsUInt32Number BytesPerPlaneOut); > > This function translates bitmaps with complex organization. Each bitmap may contain > several lines, and every may have padding. The distance from one line to the next one is > BytesPerLine{In/Out}. In planar formats, each line may hold several planes, each plane may > have padding. Padding of lines and planes should be same across all bitmap. I.e. all lines > in same bitmap have to be padded in same way. This function may be more efficient that > repeated calls to cmsDoTransform(), especially when customized plug-ins are being used. > > Parameters: > > - hTransform: Handle to a color transform object. > - InputBuffer: A pointer to the input bitmap > - OutputBuffer: A pointer to the output bitmap. > - PixelsPerLine: The number of pixels for line, which is same on input and in output. > - LineCount: The number of lines, which is same on input and output > - BytesPerLine{In,Out}: The distance in bytes from one line to the next one. > - BytesPerPlaneIn{In,Out}: The distance in bytes from one plane to the next one inside a line. Only applies > in planar formats. > > > Notes: > - This function is quite efficient, and is used by some plug-ins to give a big > speedup. If you can load whole image to memory and then call this function > over it, it will be much faster than any other approach. > - BytesPerPlaneIn{In,Out} is ignored if the formats used are not planar. Please note > 1-plane planar is indistinguishable from 1-component chunky, so BytesPerPlane is > ignored as well in this case. > - If the image does not have any gaps between the pixels and lines BytesPerLine{} > are equal to the pixel's size * PixelsPerLine. > - To specify padding between pixels, use T_EXTRA() and EXTRA_SH() to specify > extra channels. Tests all passed ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.org/jdk/pull/10754 From aivanov at openjdk.org Fri Nov 4 21:29:07 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 4 Nov 2022 21:29:07 GMT Subject: RFR: 8296335 : Fix accessibility manual test instruction In-Reply-To: References: Message-ID: <34tJEQbRFevKqt5HqZpP-HFN5vgOSNbJELSncWClMsw=.60a0eb7e-e72d-4d7e-8c98-92eb8d0fa664@github.com> On Fri, 4 Nov 2022 20:18:09 GMT, lawrence.andrews wrote: > Fixed test instruction that helps the manual tester to perform actions > > @shurymury test/jdk/javax/accessibility/manual/TableDemo.html line 81: > 79: > 80: > 81: Let us preserve the last blank line in the files. Or add if it's not there. ------------- PR: https://git.openjdk.org/jdk/pull/10996 From duke at openjdk.org Fri Nov 4 21:34:48 2022 From: duke at openjdk.org (lawrence.andrews) Date: Fri, 4 Nov 2022 21:34:48 GMT Subject: RFR: 8296335 : Fix accessibility manual test instruction [v2] In-Reply-To: References: Message-ID: > Fixed test instruction that helps the manual tester to perform actions > > @shurymury lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: Preserve last line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10996/files - new: https://git.openjdk.org/jdk/pull/10996/files/b4e040a8..224ce921 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10996&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10996&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10996.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10996/head:pull/10996 PR: https://git.openjdk.org/jdk/pull/10996 From duke at openjdk.org Fri Nov 4 21:37:47 2022 From: duke at openjdk.org (lawrence.andrews) Date: Fri, 4 Nov 2022 21:37:47 GMT Subject: RFR: 8296335 : Fix accessibility manual test instruction [v3] In-Reply-To: References: Message-ID: > Fixed test instruction that helps the manual tester to perform actions > > @shurymury lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: Add a blank line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10996/files - new: https://git.openjdk.org/jdk/pull/10996/files/224ce921..e36cecef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10996&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10996&range=01-02 Stats: 5 lines in 5 files changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10996.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10996/head:pull/10996 PR: https://git.openjdk.org/jdk/pull/10996 From aivanov at openjdk.org Fri Nov 4 22:31:19 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 4 Nov 2022 22:31:19 GMT Subject: RFR: 8296335 : Fix accessibility manual test instruction [v3] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 21:37:47 GMT, lawrence.andrews wrote: >> Fixed test instruction that helps the manual tester to perform actions >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Add a blank line Changes requested by aivanov (Reviewer). test/jdk/javax/accessibility/manual/ButtonDemo.html line 81: > 79: > 80: > 81: This is not necessary: two blank lines also cause problems. test/jdk/javax/accessibility/manual/OptionPaneDemo.html line 78: > 76: > 77: > 78: Ah, it looks the last line wasn't considered blank because it contained trailing spaces. There should be no trailing spaces, there should be only one blank line in the end of the file. In this case, the HTML file should have 77 lines. test/jdk/javax/accessibility/manual/TableDemo.html line 81: > 79: > 80: > 81: The same as above, trailing white-space caused GitHub to indicate the missing blank line at the end of the file. test/jdk/javax/accessibility/manual/TreeDemo.html line 67: > 65: > 66: > 67: There should be only one, not two. ------------- PR: https://git.openjdk.org/jdk/pull/10996 From duke at openjdk.org Fri Nov 4 23:46:36 2022 From: duke at openjdk.org (lawrence.andrews) Date: Fri, 4 Nov 2022 23:46:36 GMT Subject: RFR: 8296335 : Fix accessibility manual test instruction [v4] In-Reply-To: References: Message-ID: > Fixed test instruction that helps the manual tester to perform actions > > @shurymury lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision: - Fixed the review comments - html files with just one empty last line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10996/files - new: https://git.openjdk.org/jdk/pull/10996/files/e36cecef..cac5be99 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10996&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10996&range=02-03 Stats: 9 lines in 5 files changed: 0 ins; 9 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10996.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10996/head:pull/10996 PR: https://git.openjdk.org/jdk/pull/10996 From duke at openjdk.org Fri Nov 4 23:49:11 2022 From: duke at openjdk.org (lawrence.andrews) Date: Fri, 4 Nov 2022 23:49:11 GMT Subject: RFR: 8296335 : Fix accessibility manual test instruction [v5] In-Reply-To: References: Message-ID: > Fixed test instruction that helps the manual tester to perform actions > > @shurymury lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: Fixed the review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10996/files - new: https://git.openjdk.org/jdk/pull/10996/files/cac5be99..70642fc7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10996&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10996&range=03-04 Stats: 3 lines in 3 files changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10996.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10996/head:pull/10996 PR: https://git.openjdk.org/jdk/pull/10996 From duke at openjdk.org Fri Nov 4 23:52:01 2022 From: duke at openjdk.org (lawrence.andrews) Date: Fri, 4 Nov 2022 23:52:01 GMT Subject: RFR: 8296335 : Fix accessibility manual test instruction [v6] In-Reply-To: References: Message-ID: > Fixed test instruction that helps the manual tester to perform actions > > @shurymury lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: Fixed the review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10996/files - new: https://git.openjdk.org/jdk/pull/10996/files/70642fc7..d9926b3c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10996&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10996&range=04-05 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10996.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10996/head:pull/10996 PR: https://git.openjdk.org/jdk/pull/10996 From duke at openjdk.org Fri Nov 4 23:56:10 2022 From: duke at openjdk.org (lawrence.andrews) Date: Fri, 4 Nov 2022 23:56:10 GMT Subject: RFR: 8296335 : Fix accessibility manual test instruction [v7] In-Reply-To: References: Message-ID: > Fixed test instruction that helps the manual tester to perform actions > > @shurymury lawrence.andrews has updated the pull request incrementally with four additional commits since the last revision: - Update TreeDemo.html - Update TableDemo.html - Update ComboBoxDemo.html - Update ButtonDemo.html ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10996/files - new: https://git.openjdk.org/jdk/pull/10996/files/d9926b3c..09c7ea93 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10996&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10996&range=05-06 Stats: 4 lines in 4 files changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10996.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10996/head:pull/10996 PR: https://git.openjdk.org/jdk/pull/10996 From aivanov at openjdk.org Sat Nov 5 00:14:29 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Sat, 5 Nov 2022 00:14:29 GMT Subject: RFR: 8296335 : Fix accessibility manual test instruction [v7] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 23:56:10 GMT, lawrence.andrews wrote: >> Fixed test instruction that helps the manual tester to perform actions >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with four additional commits since the last revision: > > - Update TreeDemo.html > - Update TableDemo.html > - Update ComboBoxDemo.html > - Update ButtonDemo.html test/jdk/javax/accessibility/manual/OptionPaneDemo.html line 77: > 75: > 76: > 77: Looks like this file still contains an extra line at the end. ------------- PR: https://git.openjdk.org/jdk/pull/10996 From duke at openjdk.org Sat Nov 5 00:47:05 2022 From: duke at openjdk.org (lawrence.andrews) Date: Sat, 5 Nov 2022 00:47:05 GMT Subject: RFR: 8296335 : Fix accessibility manual test instruction [v8] In-Reply-To: References: Message-ID: > Fixed test instruction that helps the manual tester to perform actions > > @shurymury lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: Update OptionPaneDemo.html ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10996/files - new: https://git.openjdk.org/jdk/pull/10996/files/09c7ea93..f3bec8c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10996&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10996&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10996.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10996/head:pull/10996 PR: https://git.openjdk.org/jdk/pull/10996 From aivanov at openjdk.org Sat Nov 5 00:47:06 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Sat, 5 Nov 2022 00:47:06 GMT Subject: RFR: 8296335 : Fix accessibility manual test instruction [v8] In-Reply-To: References: Message-ID: On Sat, 5 Nov 2022 00:43:06 GMT, lawrence.andrews wrote: >> Fixed test instruction that helps the manual tester to perform actions >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Update OptionPaneDemo.html Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10996 From serb at openjdk.org Sat Nov 5 04:51:40 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 5 Nov 2022 04:51:40 GMT Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of JInternalFrame [v9] In-Reply-To: References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com> Message-ID: On Fri, 7 Oct 2022 21:42:40 GMT, Sergey Bylokhov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> fix for pixel color at edge, outermost border lines drawn as part of bulk of border > > src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 266: > >> 264: } >> 265: >> 266: Graphics2D g2d = (Graphics2D) g; > > It could be a DebugGraphics which is not a Graphics2D If the code will be refactored please double-check that the blind cast will not be used, "g" could DebugGraphics which is not a Graphics2D ------------- PR: https://git.openjdk.org/jdk/pull/10274 From serb at openjdk.org Sat Nov 5 04:55:37 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 5 Nov 2022 04:55:37 GMT Subject: RFR: 8295430: Use cmsDoTransformLineStride instead of cmsDoTransform in the loop [v2] In-Reply-To: <0FRqG16zkqljRkLjTq1bplcPpoJAm98eLYvjZdR6g14=.35e8b2b3-defe-4af0-a98f-1fadd358e42d@github.com> References: <0FRqG16zkqljRkLjTq1bplcPpoJAm98eLYvjZdR6g14=.35e8b2b3-defe-4af0-a98f-1fadd358e42d@github.com> Message-ID: > This is the request to improve the change made by the > [8005530: [lcms] Improve performance of ColorConverOp for default destinations](http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/fd8810d50c99) > > Right now the LCMSTransform mantain the special "imageAtOnce" flags and call cmsDoTransform function in the loop per line to support the gaps betwen the lines in the images . This code can be improved by using one call to cmsDoTransformLineStride. Some discussion about this method can be found [here](https://github.com/mm2/Little-CMS/issues/314), the full [specification](https://github.com/mm2/Little-CMS/blob/master/doc/LittleCMS2.14%20API.pdf): > > > void cmsDoTransformLineStride(cmsHTRANSFORM Transform, > const void* InputBuffer, > void* OutputBuffer, > cmsUInt32Number PixelsPerLine, > cmsUInt32Number LineCount, > cmsUInt32Number BytesPerLineIn, > cmsUInt32Number BytesPerLineOut, > cmsUInt32Number BytesPerPlaneIn, > cmsUInt32Number BytesPerPlaneOut); > > This function translates bitmaps with complex organization. Each bitmap may contain > several lines, and every may have padding. The distance from one line to the next one is > BytesPerLine{In/Out}. In planar formats, each line may hold several planes, each plane may > have padding. Padding of lines and planes should be same across all bitmap. I.e. all lines > in same bitmap have to be padded in same way. This function may be more efficient that > repeated calls to cmsDoTransform(), especially when customized plug-ins are being used. > > Parameters: > > - hTransform: Handle to a color transform object. > - InputBuffer: A pointer to the input bitmap > - OutputBuffer: A pointer to the output bitmap. > - PixelsPerLine: The number of pixels for line, which is same on input and in output. > - LineCount: The number of lines, which is same on input and output > - BytesPerLine{In,Out}: The distance in bytes from one line to the next one. > - BytesPerPlaneIn{In,Out}: The distance in bytes from one plane to the next one inside a line. Only applies > in planar formats. > > > Notes: > - This function is quite efficient, and is used by some plug-ins to give a big > speedup. If you can load whole image to memory and then call this function > over it, it will be much faster than any other approach. > - BytesPerPlaneIn{In,Out} is ignored if the formats used are not planar. Please note > 1-plane planar is indistinguishable from 1-component chunky, so BytesPerPlane is > ignored as well in this case. > - If the image does not have any gaps between the pixels and lines BytesPerLine{} > are equal to the pixel's size * PixelsPerLine. > - To specify padding between pixels, use T_EXTRA() and EXTRA_SH() to specify > extra channels. Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into JDK-8295430 - Merge remote-tracking branch 'upstream/master' into JDK-8295430 - Merge remote-tracking branch 'upstream/master' into JDK-8295430 - 8295430: Use cmsDoTransformLineStride instead of cmsDoTransform in the loop ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10754/files - new: https://git.openjdk.org/jdk/pull/10754/files/1c017aac..03c3c849 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10754&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10754&range=00-01 Stats: 196675 lines in 1649 files changed: 100914 ins; 62184 del; 33577 mod Patch: https://git.openjdk.org/jdk/pull/10754.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10754/head:pull/10754 PR: https://git.openjdk.org/jdk/pull/10754 From serb at openjdk.org Sat Nov 5 04:56:42 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 5 Nov 2022 04:56:42 GMT Subject: RFR: 8295812: Skip the "half float" support in LittleCMS during the build [v2] In-Reply-To: References: Message-ID: > The Java2d do not use "half" float in the image layouts, so we can disable it in the LittleCMS library during the build. It is possible to do using [this](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/liblcms/lcms2.h#L85) public option: > > > // Uncomment to get rid of the tables for "half" float support > // #define CMS_NO_HALF_SUPPORT 1 > > > This change cuts not only the unused by java2d functions but also [such](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/share/native/liblcms/cmshalf.c#L63) tables. > > The size of liblcms decreased by 20 kB on Linux(536024 vs 515152) and 15 kB on windows(246784 vs 231424). On macOS the win is only 300 bytes. Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into JDK-8295812 - 8295812: Skip the "half float" support in LittleCMS during the build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10830/files - new: https://git.openjdk.org/jdk/pull/10830/files/2b66abd4..cb694af2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10830&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10830&range=00-01 Stats: 180880 lines in 1463 files changed: 88306 ins; 60595 del; 31979 mod Patch: https://git.openjdk.org/jdk/pull/10830.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10830/head:pull/10830 PR: https://git.openjdk.org/jdk/pull/10830 From duke at openjdk.org Sat Nov 5 21:31:18 2022 From: duke at openjdk.org (lawrence.andrews) Date: Sat, 5 Nov 2022 21:31:18 GMT Subject: Integrated: 8296335 : Fix accessibility manual test instruction In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 20:18:09 GMT, lawrence.andrews wrote: > Fixed test instruction that helps the manual tester to perform actions > > @shurymury This pull request has now been integrated. Changeset: c2f76383 Author: lawrence.andrews <87324768+lawrence-andrew at users.noreply.github.com> Committer: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/c2f76383895e3d054988a5817de52e7795bf69c2 Stats: 12 lines in 5 files changed: 0 ins; 6 del; 6 mod 8296335: Fix accessibility manual test instruction Reviewed-by: prr, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/10996 From aturbanov at openjdk.org Sun Nov 6 16:19:35 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Sun, 6 Nov 2022 16:19:35 GMT Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel [v5] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 09:56:36 GMT, Abhishek Kumar wrote: >> While using a JFileChooser with the file selection mode FILES_AND_DIRECTORIES and multiSelection enabled, it is impossible to select a single directory in GTK LAF. >> >> The condition check has been modified when multiselection is enabled and user has selected single directory. >> After the fix the behavior of JFileChooser is similar to other LAFs. >> >> An automatic test case `test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java` is implemented and checked in CI pipeline. Link is attached in JBS. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Review comment fix test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 115: > 113: > 114: private static void checkDirectoriesOnlyTest(UIManager.LookAndFeelInfo laf) > 115: throws Exception { Suggestion: throws Exception { test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 135: > 133: > 134: private static void checkFilesAndDirectoriesTest(UIManager.LookAndFeelInfo laf) > 135: throws Exception { Suggestion: throws Exception { ------------- PR: https://git.openjdk.org/jdk/pull/10866 From smandalika at openjdk.org Mon Nov 7 07:28:02 2022 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Mon, 7 Nov 2022 07:28:02 GMT Subject: RFR: 8295707: Create a regression test for JDK-7184401 [v2] In-Reply-To: References: Message-ID: > 8295707: Create a regression test for JDK-7184401 > > JDK-7184401 - JDk7u6 : Missing main menu bar in Netbeans after fix for 7162144 > Above bug got introduced due to a fix for [JDK-7162144](https://bugs.openjdk.java.net/browse/JDK-7162144). > The issue was observed on the netbeans UI. > The test below recreates a standalone test to mimic the failure reported in Netbeans in [JDK-7184401](https://bugs.openjdk.java.net/browse/JDK-7184401) and verifies that it is working as expected after it got fixed via [JDK-7189350](https://bugs.openjdk.java.net/browse/JDK-7189350)) > > The Test attempts to reproduce specific behavior of NetBeans at the certain toolbar creation stage. Widgets are created on EDT; Another code posts some events to them on EDT; From another thread some code calls explicitly edt.interrupt(). > Before this got fixed, events from a second code got lost. > > This review is for migrating tests from a closed test suite to open. > Testing: > 1.Tested the code on jdk7u6 to reproduce the issue - the UI hangs when run on this build. > 2. Tested the code on jdk7u361 b01 to validate the fix - the test passed. > 3.Mach5 Testing(40 times per platform) in macos x64, linux x64 and windows x64 - the .results are clean Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: Fixed Review Comments: Removed redundant code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10784/files - new: https://git.openjdk.org/jdk/pull/10784/files/610841fe..ad0a6240 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10784&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10784&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10784.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10784/head:pull/10784 PR: https://git.openjdk.org/jdk/pull/10784 From smandalika at openjdk.org Mon Nov 7 07:28:05 2022 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Mon, 7 Nov 2022 07:28:05 GMT Subject: RFR: 8295707: Create a regression test for JDK-7184401 [v2] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 07:58:17 GMT, Srinivas Mandalika wrote: >> test/jdk/java/awt/EventDispatchThread/InterruptEDTTest.java line 86: >> >>> 84: ((sun.awt.SunToolkit) (Toolkit.getDefaultToolkit())).realSync(); >>> 85: try { >>> 86: EventQueue.invokeAndWait(() -> { >> >> This is duplicate code in Line# 67 to Line# 72. > > The intent was to ensure latest values are picked up, thereby ensuring the stability of the code. But I see the point that it does add value since there is not change in the frame position. Will remove it. [Fixed Review Comments: Removed redundant code](https://github.com/openjdk/jdk/pull/10784/commits/ad0a62400b5bcd95c01174e85ee8c7834be39fed) ------------- PR: https://git.openjdk.org/jdk/pull/10784 From tr at openjdk.org Mon Nov 7 09:14:29 2022 From: tr at openjdk.org (Tejesh R) Date: Mon, 7 Nov 2022 09:14:29 GMT Subject: RFR: 8285635: javax/swing/JRootPane/DefaultButtonTest.java failed with Default Button not pressed for L&F: com.sun.java.swing.plaf.motif.MotifLookAndFeel In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 06:27:19 GMT, Prasanta Sadhukhan wrote: > Test sometimes fail for Motif L&F only which might require some code change in Motif code but since Motif is already deprecated and obsolete, it seems prudent to skip Motif L&F in the test. > Several iterations of the modified test pass in all platforms. Marked as reviewed by tr (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/10978 From alexsch at openjdk.org Mon Nov 7 12:34:42 2022 From: alexsch at openjdk.org (Alexander Scherbatiy) Date: Mon, 7 Nov 2022 12:34:42 GMT Subject: RFR: 8295737: macOS: Print content cut off when width > height with portrait orientation In-Reply-To: References: Message-ID: On Fri, 21 Oct 2022 08:42:12 GMT, Alexander Scherbatiy wrote: > A printed content is truncated on macOS if the content paper size width larger than height with portrait orientation or width is less than height with landscape orientation. > > To reproduce the issue run the [CutOffImage](https://bugs.openjdk.org/secure/attachment/101145/CutOffImage.java) sample on MacOS. > > Four rectangles are printed: > 1. size 300x100, portrait orientation > 2. size 300x100, landscape orientation > 3. size 100x300, portrait orientation > 4. size 100x300, landscape orientation > > The first and fourth rectangles are truncated: [cut off content](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf) > > The reason is that NSPrintInfo class does not allow to set paper size and orientation independently. > Setting paper size width large than height changes NSPrintInfo orientation to landscape. > Setting paper size width less than height changes NSPrintInfo orientation to portrait. > Updating NSPrintInfo orientation from landscape to portrait or from portrait to landscape swaps NSPrintInfo paper width and height. > > The Cocoa code that shows NSPrintInfo behavior: > > #import > > int main() > { > NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; > NSApp = [NSApplication sharedApplication]; > > #ifdef __MAC_10_9 // code for SDK 10.9 or newer > #define NS_PORTRAIT NSPaperOrientationPortrait > #define NS_LANDSCAPE NSPaperOrientationLandscape > #else // code for SDK 10.8 or older > #define NS_PORTRAIT NSPortraitOrientation > #define NS_LANDSCAPE NSLandscapeOrientation > #endif > > printf("NS_PORTRAIT: %d\n", NS_PORTRAIT); > printf("NS_LANDSCAPE: %d\n", NS_LANDSCAPE); > > printf("create default print info\n"); > NSPrintInfo* defaultPrintInfo = [[NSPrintInfo sharedPrintInfo] copy]; > NSSize size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > printf("call setUpPrintOperationDefaultValues\n"); > [defaultPrintInfo setUpPrintOperationDefaultValues]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > double w = 300.0; > double h = 100.0; > printf("set size: [%f, %f]\n", w, h); > [defaultPrintInfo setPaperSize:NSMakeSize(w, h)]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > printf("Set NS_PORTRAIT orientation\n"); > [defaultPrintInfo setOrientation: NS_PORTRAIT]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > [NSApp run]; > > [NSApp release]; > [pool release]; > return(EXIT_SUCCESS); > } > > > On macOS Mojave 10.14.5 it prints: > > > NS_PORTRAIT: 0 > NS_LANDSCAPE: 1 > create default print info > orientation: 0, paper size: [612.000000, 792.000000] > call setUpPrintOperationDefaultValues > orientation: 0, paper size: [612.000000, 792.000000] > set size: [300.000000, 100.000000] > orientation: 1, paper size: [300.000000, 100.000000] // orientation flip > Set NS_PORTRAIT orientation > orientation: 0, paper size: [100.000000, 300.000000] // size flip > ``` > > There are four possible cases for printing a rectangle with different size and orientation: > 1. Input: paper size: (w > h), orientation portrait > [dstPrintInfo setPaperSize: NSMakeSize(w, h)] // size: (w, h), orientation: landscape > [dstPrintInfo setOrientation: NS_PORTRAIT] // size: (h, w), orientation: portrait > Note: width and height are swapped > 2. Input: paper size: (w > h), orientation landscape > [dstPrintInfo setPaperSize: NSMakeSize(h, w)] // size: (h, w), orientation: portrait > [dstPrintInfo setOrientation: NS_LANDSCAPE] // size: (w, h), orientation: landscape > 3. Input: paper size: (w < h), orientation portrait > [dstPrintInfo setPaperSize: NSMakeSize(w, h)] // size: (w, h), orientation: portrait > [dstPrintInfo setOrientation: NS_PORTRAIT] // size: (w, h), orientation: portrait > 4. Input: paper size: (w < h), orientation landscape > [dstPrintInfo setPaperSize: NSMakeSize(h, w)] // size: (h, w), orientation: landscape > [dstPrintInfo setOrientation: NS_LANDSCAPE] // size: (h, w), orientation: landscape > Note: width and height are swapped > > Only for cases 1 and 4 the final width and height are swapped. > The proposed fix enlarges height for cases 1 and 4 to not cut the printed rectangle. > > It is not full fix which draws rectangles for cases 1 and 4 in the requested size. > Setting requested size leads that subsequent orientation flips width and height. > The fix only enlarges the truncated area in height direction. The enlarged area in width is preserved as before the fix. > > Printed rectangles before and after the fix: > 1. size 300x100, portrait orientation: [before-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101157/before-fix-1.pdf), [after-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101162/after-fix-1.pdf) > 2. size 300x100, landscape orientation: [before-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101156/before-fix-2.pdf), [after-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101161/after-fix-2.pdf) > 3. size 100x300, portrait orientation: [before-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101155/before-fix-3.pdf), [after-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101160/after-fix-3.pdf) > 4. size 100x300, landscape orientation: [before-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101154/before-fix-4.pdf), [after-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101159/after-fix-4.pdf) > > All four rectangles: [before-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf), [after-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101158/after-fix-all.pdf) This is an example which is written in JavaFX and prints a rectangle on page with paper size 300x100 with portrait orientation [FxPrintImageWithHelper.java](https://bugs.openjdk.org/secure/attachment/101461/FxPrintImageWithHelper.java). Actually JavaFX has set of predefined paper sizes all of which have width less than height: [Paper.java](https://github.com/openjdk/jfx/blob/7f17447aa44fbf5b09aaa2b699266dac8b50cea1/modules/javafx.graphics/src/main/java/javafx/print/Paper.java#L127). `Paper` class does not allow to create a paper with arbitrary paper size because its constructor has default access modifier. `FxPrintImageWithHelper` sample uses [PrintHelper.java](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/print/PrintHelper.java) helper class from `com.sun.javafx.print` package with public `createPaper(...)` method. The sample properly prints a rectangle on Linux. The rectangle is truncated when it is printed on macOS. Run `FxPrintImageWithHelper` with jdk8: /bin/java FxPrintImageWithHelper Printed page on macOS: [jfx-image-300x100-portrait-jdk8.pdf](https://bugs.openjdk.org/secure/attachment/101463/jfx-image-300x100-portrait-jdk8.pdf) Run `FxPrintImageWithHelper` with jdk17: /bin/java --add-exports javafx.graphics/com.sun.javafx.print=ALL-UNNAMED FxPrintImageWithHelper Printed page on macOS: [jfx-image-300x100-portrait-jdk17.pdf](https://bugs.openjdk.org/secure/attachment/101462/jfx-image-300x100-portrait-jdk17.pdf) ------------- PR: https://git.openjdk.org/jdk/pull/10808 From honkar at openjdk.org Mon Nov 7 16:47:41 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 7 Nov 2022 16:47:41 GMT Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of JInternalFrame [v9] In-Reply-To: References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com> Message-ID: On Sat, 5 Nov 2022 04:49:25 GMT, Sergey Bylokhov wrote: >> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 266: >> >>> 264: } >>> 265: >>> 266: Graphics2D g2d = (Graphics2D) g; >> >> It could be a DebugGraphics which is not a Graphics2D > > If the code will be refactored please double-check that the blind cast will not be used, "g" could DebugGraphics which is not a Graphics2D Thank you for catching it. Made a note of it , to add it during refactoring changes - [JDK-8294680](https://bugs.openjdk.org/browse/JDK-8294680) ------------- PR: https://git.openjdk.org/jdk/pull/10274 From achung at openjdk.org Mon Nov 7 17:26:28 2022 From: achung at openjdk.org (Alisen Chung) Date: Mon, 7 Nov 2022 17:26:28 GMT Subject: RFR: 8295369: Update LCMS to 2.14 Message-ID: Updating LCMS to newest release ------------- Commit messages: - remove whitespace script - fixed whitespace error in md file - fixed whitespace error - Updated lcms to v2.14 Changes: https://git.openjdk.org/jdk/pull/11000/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11000&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295369 Stats: 2137 lines in 31 files changed: 1539 ins; 134 del; 464 mod Patch: https://git.openjdk.org/jdk/pull/11000.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11000/head:pull/11000 PR: https://git.openjdk.org/jdk/pull/11000 From honkar at openjdk.org Mon Nov 7 17:26:29 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 7 Nov 2022 17:26:29 GMT Subject: RFR: 8295369: Update LCMS to 2.14 In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 22:44:11 GMT, Alisen Chung wrote: > Updating LCMS to newest release You can eliminate whitespace issue by running the following script within native/liblcms folder. for f in *.c *.h; do # replace tabs with spaces expand ${f} > ${f}.tmp; mv ${f}.tmp $f; # fix line endings to LF sed -i -e 's/\r$//g' ${f}; # remove trailing spaces sed -i -e 's/[ ]* $//g' ${f}; done @alisenchung lcms.md file still seems to have whitespaces. You can use the above script just on the .md file to eliminate whitespaces error. ------------- Changes requested by honkar (Author). PR: https://git.openjdk.org/jdk/pull/11000 From achung at openjdk.org Mon Nov 7 18:12:25 2022 From: achung at openjdk.org (Alisen Chung) Date: Mon, 7 Nov 2022 18:12:25 GMT Subject: RFR: 8295369: Update LCMS to 2.14 In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 22:44:11 GMT, Alisen Chung wrote: > Updating LCMS to newest release All client tests were run and passed with this change ------------- PR: https://git.openjdk.org/jdk/pull/11000 From prr at openjdk.org Mon Nov 7 21:24:30 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 7 Nov 2022 21:24:30 GMT Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 12:49:34 GMT, Artem Semenov wrote: >> A11Y implementation on macOS has to directly call the 'JList.setSelectedIndex' method in order to request selection on an item (see 'CAccessibility.requestSelection'). The reason is that a11y API lacks appropriate method.There's only 'javax.accessibility.AccessibleSelection#addAccessibleSelection' which is mapped to 'javax.swing.JList#addSelectionInterval', it can not be used to set selected index. >> >> @forantar @azuev-java @mrserb please review. >> >> Please note that the new API allows you to implement a multiple selection in lists from the Java side, but I did not succeed in implementing it, because I could not determine the inclusion of the so-called "VoiceOver multiple selection mode". > > Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: > > We don't do @author tags in openjdk > Not 2022 ? I am still waiting for the following questions (from July) to be answered here (not somewhere else) > You did not acknowledge this is not a backportable fix By which I mean, if this needs to be solved in say JDK 11 too, what will you do ?? > I'd like you to explain why calling setSelectedIndex isn't good enough AND why Windows A11Y does not need this API Also leaving aside that you haven't yet shown the API is needed I note that there are javax.accessibility is NOT the place for Component specific A11Y classes. So adding javax.accessibility.AccessibleList looks like a very anomalous and perhaps incorrect design. The similar examples are nested classes of the component, eg JTree.AccessibleJTree JTable.AccessibleJTable In fact there's even already a JList.AccessibleJList ! And it seems to have things that look similar to things you say you need https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JList.AccessibleJList.html#isAccessibleChildSelected(int) and your API + boolean isSelectedIndex(int index); === and public int getAccessibleSelectionCount() Returns the number of items currently selected. If no items are selected, the return value will be 0. === and you have + /** + * Returns true if no indices are selected. + * + * @return {@code true} if no indices are selected. + */ + boolean isSelectionEmpty(); etc etc .. ------------- PR: https://git.openjdk.org/jdk/pull/8578 From kizune at openjdk.org Mon Nov 7 22:13:48 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 7 Nov 2022 22:13:48 GMT Subject: RFR: 8296496: Overzealous check in sizecalc.h prevents large memory allocation Message-ID: Removed the additional multiplication overflow detection. Instead cast all the parameters to type_t just the way they are treated in the existing size check macro. This way there is no possibility to accidentally provide parameters that will pass the size check macro while being cast to size_t there but then due to the missing cast cause the wrong size passed the actual allocation function. Since this checking macro was used in couple of different places all of them needs to be updated in the similar way. ------------- Commit messages: - Removed the additional multiplication overflow detection. Changes: https://git.openjdk.org/jdk/pull/11030/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11030&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296496 Stats: 10 lines in 1 file changed: 0 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11030.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11030/head:pull/11030 PR: https://git.openjdk.org/jdk/pull/11030 From vdyakov at openjdk.org Mon Nov 7 23:16:36 2022 From: vdyakov at openjdk.org (Victor Dyakov) Date: Mon, 7 Nov 2022 23:16:36 GMT Subject: RFR: 8296496: Overzealous check in sizecalc.h prevents large memory allocation In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 22:04:55 GMT, Alexander Zuev wrote: > Removed the additional multiplication overflow detection. > Instead cast all the parameters to type_t just the way they are treated in the existing size check macro. > This way there is no possibility to accidentally provide parameters that will pass the size check macro while being cast to size_t there but then due to the missing cast cause the wrong size passed the actual allocation function. > Since this checking macro was used in couple of different places all of them needs to be updated in the similar way. @aivanov-jdk @azvegint @prrace please review ------------- PR: https://git.openjdk.org/jdk/pull/11030 From prr at openjdk.org Mon Nov 7 23:33:34 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 7 Nov 2022 23:33:34 GMT Subject: RFR: 8295369: Update LCMS to 2.14 In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 22:44:11 GMT, Alisen Chung wrote: > Updating LCMS to newest release src/java.desktop/share/native/liblcms/UPDATING line 1: > 1: ### Updating Files ### We call this file UPDATING.txt - and that means it isn't markdown. I suggest the following for this file - and also note the manual testing - did you do this part ? Tips and tasks when updating LittleCMS sources to a newer version. ----------------------------------------------------------------- Download and unzip latest release from https://sourceforge.net/projects/lcms/files/ Replace files in src/java.desktop/share/native/liblcms with files from unzipped src and include folders Replace is important because the lcms sources here are just the subset needed by JDK. This is deliberate, so when updating be sure to import only the same files. If a file has been removed from upstream you will notice it during the copy. It should then be removed from the JDK sources. If a new file is needed then the build will fail. Manually copy that in. Some re-editing of these updated files will be needed. Use "expand" and "sed" to remove tabs and trailing white space from the imported files. Re-apply the GPL headers used by the JDK. If done correctly these should then not show up in the PR diff. Update src/java.desktop/share/legal/lcms.md per the current license/copyrights/attributions etc. Build on all platforms. If there are compiler warnings causing build failures, update the disabled warnings in make/modules/java.desktop/lib/Awt2dLibraries.gmk Run all automated client tests on all platforms. Also run J2Ddemo and pay particular attention to the "color" tab. Visually verify the color transforms against the same with the current/previous JDK ------------- PR: https://git.openjdk.org/jdk/pull/11000 From abhiscxk at openjdk.org Tue Nov 8 07:06:27 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 8 Nov 2022 07:06:27 GMT Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel [v6] In-Reply-To: References: Message-ID: > While using a JFileChooser with the file selection mode FILES_AND_DIRECTORIES and multiSelection enabled, it is impossible to select a single directory in GTK LAF. > > The condition check has been modified when multiselection is enabled and user has selected single directory. > After the fix the behavior of JFileChooser is similar to other LAFs. > > An automatic test case `test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java` is implemented and checked in CI pipeline. Link is attached in JBS. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Review comment fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10866/files - new: https://git.openjdk.org/jdk/pull/10866/files/0b7d1a6e..5c5c564c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10866&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10866&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10866.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10866/head:pull/10866 PR: https://git.openjdk.org/jdk/pull/10866 From mvs at openjdk.org Tue Nov 8 08:12:26 2022 From: mvs at openjdk.org (Manukumar V S) Date: Tue, 8 Nov 2022 08:12:26 GMT Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is unstable in MacOS machines In-Reply-To: References: Message-ID: On Tue, 11 Oct 2022 14:17:42 GMT, Manukumar V S wrote: > java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as adding some stability improvements fixes the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. This fix doesn't cover the Windows issue, so the problem listing in windows will remain same. > > Fix: > Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS. > Also updated the screen capture code, made frame undecorated, added some prints for better debugging. Any volunteers for a review?. ------------- PR: https://git.openjdk.org/jdk/pull/10655 From asemenov at openjdk.org Tue Nov 8 08:49:36 2022 From: asemenov at openjdk.org (Artem Semenov) Date: Tue, 8 Nov 2022 08:49:36 GMT Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 21:20:45 GMT, Phil Race wrote: >> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: >> >> We don't do @author tags in openjdk >> Not 2022 ? > > I am still waiting for the following questions (from July) to be answered here (not somewhere else) > >> You did not acknowledge this is not a backportable fix > > By which I mean, if this needs to be solved in say JDK 11 too, what will you do ?? > >> I'd like you to explain why calling setSelectedIndex isn't good enough AND why Windows A11Y does not need this API > > Also leaving aside that you haven't yet shown the API is needed I note that there are javax.accessibility is NOT > the place for Component specific A11Y classes. > So adding javax.accessibility.AccessibleList looks like a very anomalous and perhaps incorrect design. > > The similar examples are nested classes of the component, eg > JTree.AccessibleJTree > JTable.AccessibleJTable > > In fact there's even already a JList.AccessibleJList ! > > And it seems to have things that look similar to things you say you need > https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JList.AccessibleJList.html#isAccessibleChildSelected(int) > > and your API > > + boolean isSelectedIndex(int index); > > === > > and > public int getAccessibleSelectionCount() > Returns the number of items currently selected. If no items are selected, the return value will be 0. > > === > and you have > > + /** > + * Returns true if no indices are selected. > + * > + * @return {@code true} if no indices are selected. > + */ > + boolean isSelectionEmpty(); > > etc etc .. @prrace I acknowledge that this change is not portable. The absence of the dedicated AccessibleList interface does not allow setting selections on lists on MacOS using the accessible shortcuts and external accessibility devices. The current solution severely limits the ability of accessibility subsystem to interact with the list component thus it is not acceptable. Existing implementation uses AccessibleSelection implemented in the JList but it lacks ability to work with multiple selection intervals and side effects of setting singular selection with sequential calling of clearSelection() and addSelection() lead to the the line selection action being repeated by the VoiceOver indefinitely. We need a new accessibility interface that will implement the selection model for accessibility lists. Also it should provide additional information about the list, regardless of whether the accessibility list is inherited from JList or impolemented from scratch. New interface should be able to provide system with the additional information such as selection mode and should be flexible enough to allow implementation of both single and multiselection modes. The AccessibleSelection interface does not allow working with index intervals, which will prevent the implementation of multiple selection in the future. This interface is not yet relevant on windows because the most common readers do not have a screen navigation modes similar to VoiceOver quick navigation and the current functionality is sufficient. ------------- PR: https://git.openjdk.org/jdk/pull/8578 From abhiscxk at openjdk.org Tue Nov 8 09:40:33 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 8 Nov 2022 09:40:33 GMT Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel [v4] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 11:07:38 GMT, Abhishek Kumar wrote: >>> So, it is same without the fix too as is mentioned in that bug. >> >> Yeah, it behaves same without the fix also. > >> Can you please see why that is so as it should be exercising the same code path as this fix? > > Ok, I will check. > > Can you please see why that is so as it should be exercising the same code path as this fix? > > GTK FileChooser allows to select all folders in folder list but in files list it allows only single file selection. The reason behind this is while creating the GTKFileChooserUI, filelist selection model is set to `SINGLE_SELECTION` if **multiselection is disabled**. Code snippet is attached from `protected JScrollPane createFilesList()` method. if (getFileChooser().isMultiSelectionEnabled()) { fileList.setSelectionMode(ListSelectionModel.MULTIPLE_INTERVAL_SELECTION); } else { fileList.setSelectionMode(ListSelectionModel.SINGLE_SELECTION); } But for directory list there is no such condition is present and due to that it allows to select multiple folders in directory list with ctrl+A. ------------- PR: https://git.openjdk.org/jdk/pull/10866 From duke at openjdk.org Tue Nov 8 09:45:13 2022 From: duke at openjdk.org (Naveen Narayanan) Date: Tue, 8 Nov 2022 09:45:13 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem. Message-ID: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> Colocate JMenuItemSetAcceleratorTest to a regression test. This testcase will 1) Verify setAccelerator method of JMenuitem. 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M. Testing: Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. ------------- Commit messages: - 8296275: Write a test to verify setAccelerator method of JMenuItem. Changes: https://git.openjdk.org/jdk/pull/11035/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11035&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296275 Stats: 89 lines in 1 file changed: 89 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11035.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11035/head:pull/11035 PR: https://git.openjdk.org/jdk/pull/11035 From mvs at openjdk.org Tue Nov 8 11:05:55 2022 From: mvs at openjdk.org (Manukumar V S) Date: Tue, 8 Nov 2022 11:05:55 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem. In-Reply-To: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> Message-ID: On Tue, 8 Nov 2022 08:57:54 GMT, Naveen Narayanan wrote: > Colocate JMenuItemSetAcceleratorTest to a regression test. > > This testcase will > 1) Verify setAccelerator method of JMenuitem. > 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M. > > Testing: > Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. The JDK bug associated with an openjdk PR should not be a confidential one(I have changed it now). test/jdk/java/awt/Desktop/JMenuItemSetAcceleratorTest.java line 1: > 1: I can't see the copyright header ------------- PR: https://git.openjdk.org/jdk/pull/11035 From aturbanov at openjdk.org Tue Nov 8 13:05:36 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 8 Nov 2022 13:05:36 GMT Subject: RFR: 8296535: Unnecessary Vector usage in AquaFileSystemModel.FilesLoader Message-ID: Couple of local variables in `com.apple.laf.AquaFileSystemModel.FilesLoader#run` are used only within the method from single thread. So we can avoid usage of legacy synchronized `Vector` here and use `ArrayList` instead. ------------- Commit messages: - [PATCH] Unnecessary Vector usage in AquaFileSystemModel.FilesLoader Changes: https://git.openjdk.org/jdk/pull/10942/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10942&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296535 Stats: 17 lines in 1 file changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/10942.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10942/head:pull/10942 PR: https://git.openjdk.org/jdk/pull/10942 From duke at openjdk.org Tue Nov 8 13:05:38 2022 From: duke at openjdk.org (j3graham) Date: Tue, 8 Nov 2022 13:05:38 GMT Subject: RFR: 8296535: Unnecessary Vector usage in AquaFileSystemModel.FilesLoader In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 08:19:41 GMT, Andrey Turbanov wrote: > Couple of local variables in `com.apple.laf.AquaFileSystemModel.FilesLoader#run` are used only within the method from single thread. So we can avoid usage of legacy synchronized `Vector` here and use `ArrayList` instead. src/java.desktop/macosx/classes/com/apple/laf/AquaFileSystemModel.java line 261: > 259: } > 260: > 261: protected void sort(ArrayList v) { The custom sort implementation here could be replaced with the standard list.sort with an appropriate comparator ------------- PR: https://git.openjdk.org/jdk/pull/10942 From aturbanov at openjdk.org Tue Nov 8 13:05:38 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 8 Nov 2022 13:05:38 GMT Subject: RFR: 8296535: Unnecessary Vector usage in AquaFileSystemModel.FilesLoader In-Reply-To: References: Message-ID: On Sun, 6 Nov 2022 04:11:34 GMT, j3graham wrote: >> Couple of local variables in `com.apple.laf.AquaFileSystemModel.FilesLoader#run` are used only within the method from single thread. So we can avoid usage of legacy synchronized `Vector` here and use `ArrayList` instead. > > src/java.desktop/macosx/classes/com/apple/laf/AquaFileSystemModel.java line 261: > >> 259: } >> 260: >> 261: protected void sort(ArrayList v) { > > The custom sort implementation here could be replaced with the standard list.sort with an appropriate comparator I agree. I will create a separate issue after merging this one. ------------- PR: https://git.openjdk.org/jdk/pull/10942 From aivanov at openjdk.org Tue Nov 8 13:57:53 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 8 Nov 2022 13:57:53 GMT Subject: RFR: 8296496: Overzealous check in sizecalc.h prevents large memory allocation In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 22:04:55 GMT, Alexander Zuev wrote: > Removed the additional multiplication overflow detection. > Instead cast all the parameters to type_t just the way they are treated in the existing size check macro. > This way there is no possibility to accidentally provide parameters that will pass the size check macro while being cast to size_t there but then due to the missing cast cause the wrong size passed the actual allocation function. > Since this checking macro was used in couple of different places all of them needs to be updated in the similar way. Changes requested by aivanov (Reviewer). src/java.desktop/share/native/common/awt/utility/sizecalc.h line 95: > 93: #define SAFE_SIZE_NEW_ARRAY2(type, n, m) \ > 94: (IS_SAFE_SIZE_MUL((m), (n)) && IS_SAFE_SIZE_MUL(sizeof(type), (n) * (m)) ? \ > 95: (new type[(size_t)((n) * (m))]) : throw std::bad_alloc()) Suggestion: (new type[(size_t)(n) * (size_t)(m)]) : throw std::bad_alloc()) Each parameter must be cast as in `SAFE_SIZE_ARRAY_ALLOC`. src/java.desktop/share/native/common/awt/utility/sizecalc.h line 115: > 113: */ > 114: #define SAFE_SIZE_STRUCT_ALLOC(func, a, m, n) \ > 115: (IS_SAFE_STRUCT_SIZE((a), (m), (n)) ? ((func)((a) + (size_t)(m) * (size_t)(n))) : FAILURE_RESULT) Suggestion: (IS_SAFE_STRUCT_SIZE((a), (m), (n)) ? ((func)((size_t)(a) + (size_t)(m) * (size_t)(n))) : FAILURE_RESULT) To be safe, `a` should also be cast. And `IS_SAFE_STRUCT_SIZE` should also be updated to pass `(size_t)(m) * (size_t)(n)` to `IS_SAFE_SIZE_ADD` instead of `(m) * (n)`. ------------- PR: https://git.openjdk.org/jdk/pull/11030 From duke at openjdk.org Tue Nov 8 15:14:13 2022 From: duke at openjdk.org (lawrence.andrews) Date: Tue, 8 Nov 2022 15:14:13 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem. In-Reply-To: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> Message-ID: On Tue, 8 Nov 2022 08:57:54 GMT, Naveen Narayanan wrote: > Colocate JMenuItemSetAcceleratorTest to a regression test. > > This testcase will > 1) Verify setAccelerator method of JMenuitem. > 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M. > > Testing: > Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. test/jdk/java/awt/Desktop/JMenuItemSetAcceleratorTest.java line 58: > 56: } > 57: > 58: actionPerformLatch = new CountDownLatch(1); You can create the instance as part of the declaration. test/jdk/java/awt/Desktop/JMenuItemSetAcceleratorTest.java line 86: > 84: if (frame != null) { > 85: frame.dispose(); > 86: frame = null; This statement does not harm but you can remove it. ------------- PR: https://git.openjdk.org/jdk/pull/11035 From duke at openjdk.org Tue Nov 8 15:21:26 2022 From: duke at openjdk.org (lawrence.andrews) Date: Tue, 8 Nov 2022 15:21:26 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem. In-Reply-To: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> Message-ID: On Tue, 8 Nov 2022 08:57:54 GMT, Naveen Narayanan wrote: > Colocate JMenuItemSetAcceleratorTest to a regression test. > > This testcase will > 1) Verify setAccelerator method of JMenuitem. > 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M. > > Testing: > Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. test/jdk/java/awt/Desktop/JMenuItemSetAcceleratorTest.java line 45: > 43: > 44: frame.setJMenuBar(bar); > 45: frame.setBounds(200, 200, 200, 200); Position the frame to the middle of the screen frame.setLocationRelativeTo(null); ------------- PR: https://git.openjdk.org/jdk/pull/11035 From alexey.ivanov at oracle.com Tue Nov 8 16:15:38 2022 From: alexey.ivanov at oracle.com (Aleksei Ivanov) Date: Tue, 8 Nov 2022 16:15:38 +0000 Subject: RFR: 8296496: Overzealous check in sizecalc.h prevents large memory allocation In-Reply-To: References: Message-ID: Hi Patrick, It is the reason why it should be updated. The checks in IS_SAFE_STRUCT_SIZE are performed with the cast: (size_t)(a). If the cast is omitted here, it may yield a different result. What if ?a? is a signed integer with negative value? Regards, Alexey On 08/11/2022 15:25, Patrick Chen wrote: > But you forgot that ??(IS_SAFE_STRUCT_SIZE((a), (m), (n)) ? > ((func)((a) + (size_t)(m) * (size_t)(n))) : FAILURE_RESULT) is not the > same equivalence to ? (IS_SAFE_STRUCT_SIZE((a), (m), (n)) ? > ((func)((size_t)(a) + (size_t)(m) * (size_t)(n))) : FAILURE_RESULT) > because of the ((func)((size_t)(a) + (size_t)(m) * (size_t)(n)) > > Le?mar. 8 nov. 2022 ??14:59, Alexey Ivanov a ?crit?: > > On Mon, 7 Nov 2022 22:04:55 GMT, Alexander Zuev > wrote: > > > > To be safe, `a` should also be cast. > > And `IS_SAFE_STRUCT_SIZE` should also be updated to pass > `(size_t)(m) * (size_t)(n)` to `IS_SAFE_SIZE_ADD` instead of `(m) > * (n)`. > > ------------- > > PR: https://git.openjdk.org/jdk/pull/11030 > From omikhaltcova at openjdk.org Tue Nov 8 16:11:26 2022 From: omikhaltcova at openjdk.org (Olga Mikhaltsova) Date: Tue, 8 Nov 2022 16:11:26 GMT Subject: RFR: 8165943: LineBreakMeasurer does not measure correctly if TextAttribute.TRACKING is set. In-Reply-To: References: Message-ID: On Thu, 15 Sep 2022 16:51:27 GMT, Olga Mikhaltsova wrote: > This is a fix for LineBreakMeasurer. It takes into account the TextAttribute.TRACKING value (not eq 0) while calculating the line breaks. > > Tested on Linux x64, Windows x64, macOS x64 with the reproducer (LineBreakSample.java) attached to JDK-8165943 and the following group of tests: > `$JTREG_HOME/bin/jtreg -jdk:$BUILD_HOME ./test/jdk/java/awt/font` gentle ping; pls review this pr! ------------- PR: https://git.openjdk.org/jdk/pull/10289 From duke at openjdk.org Tue Nov 8 16:37:26 2022 From: duke at openjdk.org (j3graham) Date: Tue, 8 Nov 2022 16:37:26 GMT Subject: RFR: 8296535: Unnecessary Vector usage in AquaFileSystemModel.FilesLoader In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 08:19:41 GMT, Andrey Turbanov wrote: > Couple of local variables in `com.apple.laf.AquaFileSystemModel.FilesLoader#run` are used only within the method from single thread. So we can avoid usage of legacy synchronized `Vector` here and use `ArrayList` instead. src/java.desktop/macosx/classes/com/apple/laf/AquaFileSystemModel.java line 428: > 426: } > 427: final DoChangeContents runnable = new DoChangeContents(chunk, fid); > 428: runnables.addElement(runnable); I think the ?chunk? doesn?t need to be a vector either. ------------- PR: https://git.openjdk.org/jdk/pull/10942 From achung at openjdk.org Tue Nov 8 19:44:42 2022 From: achung at openjdk.org (Alisen Chung) Date: Tue, 8 Nov 2022 19:44:42 GMT Subject: RFR: 8295369: Update LCMS to 2.14 [v2] In-Reply-To: References: Message-ID: <3CvLzLGxp4z59wrfJtC_zx2Nr2awKQVW8sFy-5r7LwA=.3807e53b-1314-4234-a2b2-3e0f876edac4@github.com> > Updating LCMS to newest release Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: updated UPDATING.txt ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11000/files - new: https://git.openjdk.org/jdk/pull/11000/files/be78ec7b..6a1bbf36 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11000&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11000&range=00-01 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11000.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11000/head:pull/11000 PR: https://git.openjdk.org/jdk/pull/11000 From achung at openjdk.org Tue Nov 8 19:44:43 2022 From: achung at openjdk.org (Alisen Chung) Date: Tue, 8 Nov 2022 19:44:43 GMT Subject: RFR: 8295369: Update LCMS to 2.14 [v2] In-Reply-To: References: Message-ID: <8NkreC4lv-J4UQFHOm1tPbv5eVS04QhGjnX5UlDH91Q=.b46ba037-b947-43f7-9ad3-2239fdc77805@github.com> On Mon, 7 Nov 2022 23:29:31 GMT, Phil Race wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> updated UPDATING.txt > > src/java.desktop/share/native/liblcms/UPDATING line 1: > >> 1: ### Updating Files ### > > We call this file UPDATING.txt - and that means it isn't markdown. > > I suggest the following for this file - and also note the manual testing - did you do this part ? > > > Tips and tasks when updating LittleCMS sources to a newer version. > ----------------------------------------------------------------- > > Download and unzip latest release from https://sourceforge.net/projects/lcms/files/ > Replace files in src/java.desktop/share/native/liblcms with files from unzipped src and include folders > Replace is important because the lcms sources here are just the subset needed by JDK. > This is deliberate, so when updating be sure to import only the same files. > If a file has been removed from upstream you will notice it during the copy. > It should then be removed from the JDK sources. > If a new file is needed then the build will fail. Manually copy that in. > > Some re-editing of these updated files will be needed. > Use "expand" and "sed" to remove tabs and trailing white space from the imported files. > Re-apply the GPL headers used by the JDK. If done correctly these should then not > show up in the PR diff. > > Update src/java.desktop/share/legal/lcms.md per the current license/copyrights/attributions etc. > > Build on all platforms. > If there are compiler warnings causing build failures, update the disabled warnings in > make/modules/java.desktop/lib/Awt2dLibraries.gmk > Run all automated client tests on all platforms. > Also run J2Ddemo and pay particular attention to the "color" tab. > Visually verify the color transforms against the same with the current/previous JDK I ran J2Ddemo and it looks ok ------------- PR: https://git.openjdk.org/jdk/pull/11000 From kizune at openjdk.org Tue Nov 8 21:42:35 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 8 Nov 2022 21:42:35 GMT Subject: RFR: 8296496: Overzealous check in sizecalc.h prevents large memory allocation In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 13:50:25 GMT, Alexey Ivanov wrote: > Each parameter must be cast as in SAFE_SIZE_ARRAY_ALLOC. If we do that then logic might be broken since we checking for the limits against the (size_t)(m * n) but performing call with ((size_t)(m) * (size_t)(n)) which might add potential point of failure. I prefer to do the conversions in the same way we do them in checks. ------------- PR: https://git.openjdk.org/jdk/pull/11030 From achung at openjdk.org Tue Nov 8 22:03:44 2022 From: achung at openjdk.org (Alisen Chung) Date: Tue, 8 Nov 2022 22:03:44 GMT Subject: RFR: 8295369: Update LCMS to 2.14 [v3] In-Reply-To: References: Message-ID: > Updating LCMS to newest release Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: updated UPDATING.txt contents ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11000/files - new: https://git.openjdk.org/jdk/pull/11000/files/6a1bbf36..8b88afb6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11000&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11000&range=01-02 Stats: 20 lines in 1 file changed: 9 ins; 2 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/11000.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11000/head:pull/11000 PR: https://git.openjdk.org/jdk/pull/11000 From kizune at openjdk.org Tue Nov 8 22:05:24 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 8 Nov 2022 22:05:24 GMT Subject: RFR: 8296496: Overzealous check in sizecalc.h prevents large memory allocation In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 13:54:31 GMT, Alexey Ivanov wrote: > To be safe, `a` should also be cast. > >And IS_SAFE_STRUCT_SIZE should also be updated to pass (size_t)(m) * (size_t)(n) to IS_SAFE_SIZE_ADD instead of (m) * (n). Sounds reasonable. ------------- PR: https://git.openjdk.org/jdk/pull/11030 From aivanov at openjdk.org Tue Nov 8 22:39:22 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 8 Nov 2022 22:39:22 GMT Subject: RFR: 8296496: Overzealous check in sizecalc.h prevents large memory allocation In-Reply-To: References: Message-ID: <-NaB52Rgg250pB2Z40Aba9pbNi-wZKrWy70Xst3y29w=.3d66a94f-3f47-4e6a-a133-c64fffe3c649@github.com> On Tue, 8 Nov 2022 21:38:54 GMT, Alexander Zuev wrote: >> src/java.desktop/share/native/common/awt/utility/sizecalc.h line 95: >> >>> 93: #define SAFE_SIZE_NEW_ARRAY2(type, n, m) \ >>> 94: (IS_SAFE_SIZE_MUL((m), (n)) && IS_SAFE_SIZE_MUL(sizeof(type), (n) * (m)) ? \ >>> 95: (new type[(size_t)((n) * (m))]) : throw std::bad_alloc()) >> >> Suggestion: >> >> (new type[(size_t)(n) * (size_t)(m)]) : throw std::bad_alloc()) >> >> Each parameter must be cast as in `SAFE_SIZE_ARRAY_ALLOC`. > >> Each parameter must be cast as in SAFE_SIZE_ARRAY_ALLOC. > > If we do that then logic might be broken since we checking for the limits against the (size_t)(m * n) but performing call with ((size_t)(m) * (size_t)(n)) which might add potential point of failure. I prefer to do the conversions in the same way we do them in checks. It's [what you just did](https://github.com/openjdk/jdk/pull/11030/files#diff-f4ac4382758a5b83444f9483cbc756ca6572fddf4c3811f2f5d86002a91599c2L77-R74) for `SAFE_SIZE_ARRAY_ALLOC`: #define SAFE_SIZE_ARRAY_ALLOC(func, m, n) \ - (IS_SAFE_SIZE_MUL((m), (n)) ? ((func)((m) * (n))) : FAILURE_RESULT) + (IS_SAFE_SIZE_MUL((m), (n)) ? ((func)((size_t)(m) * (size_t)(n))) : FAILURE_RESULT) You cast both `m` and `n`. This code basically does the same. If you don't cast each parameter, the result may be different, since there are cases where `((size_t)(m) * (size_t)(n))` is not equal to `(size_t)((m) * (n))`. ------------- PR: https://git.openjdk.org/jdk/pull/11030 From kizune at openjdk.org Tue Nov 8 23:25:40 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 8 Nov 2022 23:25:40 GMT Subject: RFR: 8296496: Overzealous check in sizecalc.h prevents large memory allocation [v2] In-Reply-To: References: Message-ID: > Removed the additional multiplication overflow detection. > Instead cast all the parameters to type_t just the way they are treated in the existing size check macro. > This way there is no possibility to accidentally provide parameters that will pass the size check macro while being cast to size_t there but then due to the missing cast cause the wrong size passed the actual allocation function. > Since this checking macro was used in couple of different places all of them needs to be updated in the similar way. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Streamlining structure allocation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11030/files - new: https://git.openjdk.org/jdk/pull/11030/files/3a3e7769..ee223fc9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11030&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11030&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11030.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11030/head:pull/11030 PR: https://git.openjdk.org/jdk/pull/11030 From kizune at openjdk.org Tue Nov 8 23:31:04 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 8 Nov 2022 23:31:04 GMT Subject: RFR: 8296496: Overzealous check in sizecalc.h prevents large memory allocation [v2] In-Reply-To: <-NaB52Rgg250pB2Z40Aba9pbNi-wZKrWy70Xst3y29w=.3d66a94f-3f47-4e6a-a133-c64fffe3c649@github.com> References: <-NaB52Rgg250pB2Z40Aba9pbNi-wZKrWy70Xst3y29w=.3d66a94f-3f47-4e6a-a133-c64fffe3c649@github.com> Message-ID: On Tue, 8 Nov 2022 22:37:09 GMT, Alexey Ivanov wrote: >>> Each parameter must be cast as in SAFE_SIZE_ARRAY_ALLOC. >> >> If we do that then logic might be broken since we checking for the limits against the (size_t)(m * n) but performing call with ((size_t)(m) * (size_t)(n)) which might add potential point of failure. I prefer to do the conversions in the same way we do them in checks. > > It's [what you just did](https://github.com/openjdk/jdk/pull/11030/files#diff-f4ac4382758a5b83444f9483cbc756ca6572fddf4c3811f2f5d86002a91599c2L77-R74) for `SAFE_SIZE_ARRAY_ALLOC`: > > #define SAFE_SIZE_ARRAY_ALLOC(func, m, n) \ > - (IS_SAFE_SIZE_MUL((m), (n)) ? ((func)((m) * (n))) : FAILURE_RESULT) > + (IS_SAFE_SIZE_MUL((m), (n)) ? ((func)((size_t)(m) * (size_t)(n))) : FAILURE_RESULT) > > You cast both `m` and `n`. > > This code basically does the same. If you don't cast each parameter, the result may be different, since there are cases where `((size_t)(m) * (size_t)(n))` is not equal to `(size_t)((m) * (n))`. Ok, i see what you mean. Ok, that might work since we are already checking SAFE_SIZE_MUL((m), (n)) in the line above. ------------- PR: https://git.openjdk.org/jdk/pull/11030 From kizune at openjdk.org Tue Nov 8 23:43:23 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 8 Nov 2022 23:43:23 GMT Subject: RFR: 8296496: Overzealous check in sizecalc.h prevents large memory allocation [v3] In-Reply-To: References: Message-ID: <9-eaFh_LdVPjru9mFiLeSJIPn7u6D0wVBbA4TSPxrRI=.9344e582-e0df-4bd1-b24b-390451af5975@github.com> > Removed the additional multiplication overflow detection. > Instead cast all the parameters to type_t just the way they are treated in the existing size check macro. > This way there is no possibility to accidentally provide parameters that will pass the size check macro while being cast to size_t there but then due to the missing cast cause the wrong size passed the actual allocation function. > Since this checking macro was used in couple of different places all of them needs to be updated in the similar way. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Fixed casting in SAFE_SIZE_NEW_ARRAY2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11030/files - new: https://git.openjdk.org/jdk/pull/11030/files/ee223fc9..9673bac0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11030&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11030&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11030.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11030/head:pull/11030 PR: https://git.openjdk.org/jdk/pull/11030 From kizune at openjdk.org Wed Nov 9 00:54:40 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 9 Nov 2022 00:54:40 GMT Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 12:49:34 GMT, Artem Semenov wrote: >> A11Y implementation on macOS has to directly call the 'JList.setSelectedIndex' method in order to request selection on an item (see 'CAccessibility.requestSelection'). The reason is that a11y API lacks appropriate method.There's only 'javax.accessibility.AccessibleSelection#addAccessibleSelection' which is mapped to 'javax.swing.JList#addSelectionInterval', it can not be used to set selected index. >> >> @forantar @azuev-java @mrserb please review. >> >> Please note that the new API allows you to implement a multiple selection in lists from the Java side, but I did not succeed in implementing it, because I could not determine the inclusion of the so-called "VoiceOver multiple selection mode". > > Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: > > We don't do @author tags in openjdk > Not 2022 ? src/java.desktop/share/classes/javax/swing/JList.java line 52: > 50: import java.io.Serial; > 51: import java.io.Serializable; > 52: import java.util.*; We are trying not to use wildcard imports - probably automatic optimization of the IDE did it? I am always turning it off or set margin so high it is not triggered on anything with less then 200 individual package imports. test/jdk/java/awt/a11y/AccessibleListTest.java line 29: > 27: * @bug 8271846 > 28: * @summary Test implementation of AccessibleList interface > 29: * @author Artem.Semenov at jetbrains.com We are not using author tags in tests either - but that's just a nitpick. ------------- PR: https://git.openjdk.org/jdk/pull/8578 From peter.firmstone at zeus.net.au Tue Nov 1 08:07:11 2022 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 1 Nov 2022 19:07:11 +1100 Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: References: <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com> Message-ID: On 1/11/2022 5:52 pm, Alan Bateman wrote: > On Mon, 31 Oct 2022 22:00:01 GMT, Phil Race wrote: > >> You have jumped through some refactoring hoops to be able to apply the deprecation suppression to as little code as possible .. having made such changes, then why didn't you just make the recommended change instead ? >> >> Should I presume that the recommended route will have some nasty little incompatibilities we will need to be careful of first ? > Converting these use-sites to URI will require care and working through issues on a case by case basis. This is because URI is strict and will reject bad input that URL may have handled differently. It may, for example, require changing the exception handling so that exceptions such as URISyntaxException (or IAE if code is changed to URI.create) maps to what is appropriate for code using URL. So slow and careful work for future PRs I think. We found there were some common cases, we made static convenience methods to address them: Fix MS Windows file URI strings, by converting back slashes to forward slashes and inserting a forward slash before the drive letter if missing. https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L289 Convert java.io.File to Uri, ensure compatibility with URLClassLoader, when trailing directory character is dropped by java.io.File. https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L341 Escape illegal characters when string doesn't contain any existing escape sequences. https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L926 Parse and fix a string that contains escaped sequences, any illegal characters are escaped and any that should't be escaped are un-escaped. https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L939 Convert java.net.URL to Uri, automatically fixing MS Windows URI syntax. https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L324 Cheers, Peter. > > ------------- > > PR: https://git.openjdk.org/jdk/pull/10874 From chen.j.patrick at gmail.com Wed Nov 2 15:25:35 2022 From: chen.j.patrick at gmail.com (Patrick Chen) Date: Wed, 2 Nov 2022 16:25:35 +0100 Subject: RFR: 8295774 : Write a test to verify that List Item selection events. [v4] In-Reply-To: References: Message-ID: agree Le mer. 2 nov. 2022 ? 16:10, Alexey Ivanov a ?crit : > On Wed, 2 Nov 2022 14:51:02 GMT, ravi gupta wrote: > > >> This testcase verify that List Item selection via mouse/keys generates > ItemEvent/ActionEvent appropriately. > >> > >> a. Single click on the list generate ItemEvent and double click on item > generates ActionEvent. > >> b. UP/DOWN keys on the list generate ItemEvent and enter key on item > generates ActionEvent. > >> > >> Testing: > >> Tested using Mach5(20 times per platform) in macos,linux and windows > and got all pass. > > > > ravi gupta has updated the pull request incrementally with one > additional commit since the last revision: > > > > 8295774: Write a test to verify that List Item selection events. > > Marked as reviewed by aivanov (Reviewer). > > test/jdk/java/awt/event/ComponentEvent/ListItemEventsTest.java line 67: > > > 65: }); > > 66: list.addActionListener((event) -> { > > 67: System.out.println("Got an ActionEvent:" + event); > > I prefer having a space after the colon in the string so that it's easier > to read the message. > > ------------- > > PR: https://git.openjdk.org/jdk/pull/10899 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chen.j.patrick at gmail.com Tue Nov 8 15:25:42 2022 From: chen.j.patrick at gmail.com (Patrick Chen) Date: Tue, 8 Nov 2022 16:25:42 +0100 Subject: RFR: 8296496: Overzealous check in sizecalc.h prevents large memory allocation In-Reply-To: References: Message-ID: But you forgot that (IS_SAFE_STRUCT_SIZE((a), (m), (n)) ? ((func)((a) + (size_t)(m) * (size_t)(n))) : FAILURE_RESULT) is not the same equivalence to (IS_SAFE_STRUCT_SIZE((a), (m), (n)) ? ((func)((size_t)(a) + (size_t)(m) * (size_t)(n))) : FAILURE_RESULT) because of the ((func)((size_t)(a) + (size_t)(m) * (size_t)(n)) Le mar. 8 nov. 2022 ? 14:59, Alexey Ivanov a ?crit : > On Mon, 7 Nov 2022 22:04:55 GMT, Alexander Zuev > wrote: > > > Removed the additional multiplication overflow detection. > > Instead cast all the parameters to type_t just the way they are treated > in the existing size check macro. > > This way there is no possibility to accidentally provide parameters that > will pass the size check macro while being cast to size_t there but then > due to the missing cast cause the wrong size passed the actual allocation > function. > > Since this checking macro was used in couple of different places all of > them needs to be updated in the similar way. > > Changes requested by aivanov (Reviewer). > > src/java.desktop/share/native/common/awt/utility/sizecalc.h line 95: > > > 93: #define SAFE_SIZE_NEW_ARRAY2(type, n, m) \ > > 94: (IS_SAFE_SIZE_MUL((m), (n)) && IS_SAFE_SIZE_MUL(sizeof(type), > (n) * (m)) ? \ > > 95: (new type[(size_t)((n) * (m))]) : throw std::bad_alloc()) > > Suggestion: > > (new type[(size_t)(n) * (size_t)(m)]) : throw std::bad_alloc()) > > Each parameter must be cast as in `SAFE_SIZE_ARRAY_ALLOC`. > > src/java.desktop/share/native/common/awt/utility/sizecalc.h line 115: > > > 113: */ > > 114: #define SAFE_SIZE_STRUCT_ALLOC(func, a, m, n) \ > > 115: (IS_SAFE_STRUCT_SIZE((a), (m), (n)) ? ((func)((a) + (size_t)(m) > * (size_t)(n))) : FAILURE_RESULT) > > Suggestion: > > (IS_SAFE_STRUCT_SIZE((a), (m), (n)) ? ((func)((size_t)(a) + > (size_t)(m) * (size_t)(n))) : FAILURE_RESULT) > > To be safe, `a` should also be cast. > > And `IS_SAFE_STRUCT_SIZE` should also be updated to pass `(size_t)(m) * > (size_t)(n)` to `IS_SAFE_SIZE_ADD` instead of `(m) * (n)`. > > ------------- > > PR: https://git.openjdk.org/jdk/pull/11030 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prr at openjdk.org Wed Nov 9 04:32:27 2022 From: prr at openjdk.org (Phil Race) Date: Wed, 9 Nov 2022 04:32:27 GMT Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 21:20:45 GMT, Phil Race wrote: >> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: >> >> We don't do @author tags in openjdk >> Not 2022 ? > > I am still waiting for the following questions (from July) to be answered here (not somewhere else) > >> You did not acknowledge this is not a backportable fix > > By which I mean, if this needs to be solved in say JDK 11 too, what will you do ?? > >> I'd like you to explain why calling setSelectedIndex isn't good enough AND why Windows A11Y does not need this API > > Also leaving aside that you haven't yet shown the API is needed I note that there are javax.accessibility is NOT > the place for Component specific A11Y classes. > So adding javax.accessibility.AccessibleList looks like a very anomalous and perhaps incorrect design. > > The similar examples are nested classes of the component, eg > JTree.AccessibleJTree > JTable.AccessibleJTable > > In fact there's even already a JList.AccessibleJList ! > > And it seems to have things that look similar to things you say you need > https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JList.AccessibleJList.html#isAccessibleChildSelected(int) > > and your API > > + boolean isSelectedIndex(int index); > > === > > and > public int getAccessibleSelectionCount() > Returns the number of items currently selected. If no items are selected, the return value will be 0. > > === > and you have > > + /** > + * Returns true if no indices are selected. > + * > + * @return {@code true} if no indices are selected. > + */ > + boolean isSelectionEmpty(); > > etc etc .. > @prrace I acknowledge that this change is not portable. > > The absence of the dedicated AccessibleList interface does not allow setting selections on lists on MacOS using the accessible shortcuts and external accessibility devices. The current solution severely limits the ability of accessibility subsystem to interact with the list component thus it is not acceptable. Existing implementation uses AccessibleSelection implemented in the JList but it lacks ability to work with multiple selection intervals and side effects of setting singular selection with sequential calling of clearSelection() and addSelection() lead to the the line selection action being repeated by the VoiceOver indefinitely. > > We need a new accessibility interface that will implement the selection model for accessibility lists. Also it should provide additional information about the list, regardless of whether the accessibility list is inherited from JList or impolemented from scratch. New interface should be able to provide system with the additional information such as selection mode and should be flexible enough to allow implementation of both single and multiselection modes. The AccessibleSelection interface does not allow working with index intervals, which will prevent the implementation of multiple selection in the future. This interface is not yet relevant on windows because the most common readers do not have a screen navigation modes similar to VoiceOver quick navigation and the current functionality is sufficient. You didn't speak to the duplicated functionality. We should retrofit / add to the existing nested class, if new API is truly needed. "Nothing here is "inherited from JList". AccessibleJList is a nested class, not an inheritance relationship. API mistakes are hard to un-do so it is not possible for me to sign off on this without somehow finding enough time to study this API and come to my own conclusions since what I see now looks so anomalous. Perhaps if you can find someone who knows the A11Y APIs it would go faster, but that isn't me. ------------- PR: https://git.openjdk.org/jdk/pull/8578 From duke at openjdk.org Wed Nov 9 04:40:29 2022 From: duke at openjdk.org (ravi gupta) Date: Wed, 9 Nov 2022 04:40:29 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. Message-ID: This testcase Verify the content changes of a TextArea for the following assertions. a. TextListener get invoked when the content of a TextArea gets changed. b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. Testing: Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. ------------- Commit messages: - 8296632: Write a test to verify the content change of TextArea sends TextEvent. Changes: https://git.openjdk.org/jdk/pull/11052/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11052&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296632 Stats: 141 lines in 1 file changed: 141 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11052.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11052/head:pull/11052 PR: https://git.openjdk.org/jdk/pull/11052 From duke at openjdk.org Wed Nov 9 05:40:46 2022 From: duke at openjdk.org (Naveen Narayanan) Date: Wed, 9 Nov 2022 05:40:46 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem. [v2] In-Reply-To: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> Message-ID: > Colocate JMenuItemSetAcceleratorTest to a regression test. > > This testcase will > 1) Verify setAccelerator method of JMenuitem. > 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M. > > Testing: > Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: 8296275: Review comments fixed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11035/files - new: https://git.openjdk.org/jdk/pull/11035/files/22dc9ee9..19a0ba96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11035&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11035&range=00-01 Stats: 27 lines in 1 file changed: 23 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11035.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11035/head:pull/11035 PR: https://git.openjdk.org/jdk/pull/11035 From smandalika at openjdk.org Wed Nov 9 06:15:29 2022 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Wed, 9 Nov 2022 06:15:29 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem. [v2] In-Reply-To: References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> Message-ID: On Wed, 9 Nov 2022 05:40:46 GMT, Naveen Narayanan wrote: >> Colocate JMenuItemSetAcceleratorTest to a regression test. >> >> This testcase will >> 1) Verify setAccelerator method of JMenuitem. >> 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M. >> >> Testing: >> Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. > > Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: > > 8296275: Review comments fixed. test/jdk/java/awt/Desktop/JMenuItemSetAcceleratorTest.java line 77: > 75: || !Desktop.getDesktop().isSupported(Action.APP_MENU_BAR)) { > 76: System.out.println( > 77: "Test passed as Desktop or Action.APP_MENU_BAR is not supported."); More accurate to have this as: "Test skipped as Desktop or Action.APP_MENU_BAR is not supported." ------------- PR: https://git.openjdk.org/jdk/pull/11035 From smandalika at openjdk.org Wed Nov 9 06:19:30 2022 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Wed, 9 Nov 2022 06:19:30 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem. [v2] In-Reply-To: References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> Message-ID: On Wed, 9 Nov 2022 05:40:46 GMT, Naveen Narayanan wrote: >> Colocate JMenuItemSetAcceleratorTest to a regression test. >> >> This testcase will >> 1) Verify setAccelerator method of JMenuitem. >> 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M. >> >> Testing: >> Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. > > Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: > > 8296275: Review comments fixed. test/jdk/java/awt/Desktop/JMenuItemSetAcceleratorTest.java line 48: > 46: > 47: public class JMenuItemSetAcceleratorTest { > 48: private static JFrame frame = new JFrame(); Creation of frame should be done within the EDT. ------------- PR: https://git.openjdk.org/jdk/pull/11035 From mvs at openjdk.org Wed Nov 9 08:02:33 2022 From: mvs at openjdk.org (Manukumar V S) Date: Wed, 9 Nov 2022 08:02:33 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 04:29:35 GMT, ravi gupta wrote: > This testcase Verify the content changes of a TextArea for the following assertions. > > a. TextListener get invoked when the content of a TextArea gets changed. > b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. > > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. Please make sure the bug associated with a PR is a non-confidential one. ------------- PR: https://git.openjdk.org/jdk/pull/11052 From smandalika at openjdk.org Wed Nov 9 08:12:21 2022 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Wed, 9 Nov 2022 08:12:21 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 04:29:35 GMT, ravi gupta wrote: > This testcase Verify the content changes of a TextArea for the following assertions. > > a. TextListener get invoked when the content of a TextArea gets changed. > b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. > > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. test/jdk/java/awt/event/ComponentEvent/TextAreaTextEventTest.java line 2: > 1: /* > 2: * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. Is the year in which this test was initially written known? If yes, it is good to have that added here. ------------- PR: https://git.openjdk.org/jdk/pull/11052 From smandalika at openjdk.org Wed Nov 9 08:37:35 2022 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Wed, 9 Nov 2022 08:37:35 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 04:29:35 GMT, ravi gupta wrote: > This testcase Verify the content changes of a TextArea for the following assertions. > > a. TextListener get invoked when the content of a TextArea gets changed. > b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. > > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. test/jdk/java/awt/event/ComponentEvent/TextAreaTextEventTest.java line 59: > 57: robot.waitForIdle(); > 58: Point textAreaAt = textArea.getLocationOnScreen(); > 59: Dimension textAreaSize = textArea.getSize(); textArea being a swig component, these should be triggered on EDT. ------------- PR: https://git.openjdk.org/jdk/pull/11052 From asemenov at openjdk.org Wed Nov 9 09:04:19 2022 From: asemenov at openjdk.org (Artem Semenov) Date: Wed, 9 Nov 2022 09:04:19 GMT Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v2] In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 04:29:57 GMT, Phil Race wrote: >> I am still waiting for the following questions (from July) to be answered here (not somewhere else) >> >>> You did not acknowledge this is not a backportable fix >> >> By which I mean, if this needs to be solved in say JDK 11 too, what will you do ?? >> >>> I'd like you to explain why calling setSelectedIndex isn't good enough AND why Windows A11Y does not need this API >> >> Also leaving aside that you haven't yet shown the API is needed I note that there are javax.accessibility is NOT >> the place for Component specific A11Y classes. >> So adding javax.accessibility.AccessibleList looks like a very anomalous and perhaps incorrect design. >> >> The similar examples are nested classes of the component, eg >> JTree.AccessibleJTree >> JTable.AccessibleJTable >> >> In fact there's even already a JList.AccessibleJList ! >> >> And it seems to have things that look similar to things you say you need >> https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JList.AccessibleJList.html#isAccessibleChildSelected(int) >> >> and your API >> >> + boolean isSelectedIndex(int index); >> >> === >> >> and >> public int getAccessibleSelectionCount() >> Returns the number of items currently selected. If no items are selected, the return value will be 0. >> >> === >> and you have >> >> + /** >> + * Returns true if no indices are selected. >> + * >> + * @return {@code true} if no indices are selected. >> + */ >> + boolean isSelectionEmpty(); >> >> etc etc .. > >> @prrace I acknowledge that this change is not portable. >> >> The absence of the dedicated AccessibleList interface does not allow setting selections on lists on MacOS using the accessible shortcuts and external accessibility devices. The current solution severely limits the ability of accessibility subsystem to interact with the list component thus it is not acceptable. Existing implementation uses AccessibleSelection implemented in the JList but it lacks ability to work with multiple selection intervals and side effects of setting singular selection with sequential calling of clearSelection() and addSelection() lead to the the line selection action being repeated by the VoiceOver indefinitely. >> >> We need a new accessibility interface that will implement the selection model for accessibility lists. Also it should provide additional information about the list, regardless of whether the accessibility list is inherited from JList or impolemented from scratch. New interface should be able to provide system with the additional information such as selection mode and should be flexible enough to allow implementation of both single and multiselection modes. The AccessibleSelection interface does not allow working with index intervals, which will prevent the implementation of multiple selection in the future. This interface is not yet relevant on windows because the most common readers do not have a screen navigation modes similar to VoiceOver quick navigation and the current functionality is sufficient. > > You didn't speak to the duplicated functionality. > We should retrofit / add to the existing nested class, if new API is truly needed. > "Nothing here is "inherited from JList". AccessibleJList is a nested class, not an inheritance relationship. > API mistakes are hard to un-do so it is not possible for me to sign off on this without somehow finding > enough time to study this API and come to my own conclusions since what I see now looks so anomalous. > Perhaps if you can find someone who knows the A11Y APIs it would go faster, but that isn't me. @prrace in file ```src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java:569``` There is a direct inheritance dependence on JList. And that is exactly what needs to be avoided. It was pointed out to me [here](https://github.com/openjdk/jdk/pull/4412/files#r653062357 "github.com"). Without changes, a non-JList-based list will not work. ------------- PR: https://git.openjdk.org/jdk/pull/8578 From asemenov at openjdk.org Wed Nov 9 09:37:01 2022 From: asemenov at openjdk.org (Artem Semenov) Date: Wed, 9 Nov 2022 09:37:01 GMT Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v3] In-Reply-To: References: Message-ID: > A11Y implementation on macOS has to directly call the 'JList.setSelectedIndex' method in order to request selection on an item (see 'CAccessibility.requestSelection'). The reason is that a11y API lacks appropriate method.There's only 'javax.accessibility.AccessibleSelection#addAccessibleSelection' which is mapped to 'javax.swing.JList#addSelectionInterval', it can not be used to set selected index. > > @forantar @azuev-java @mrserb please review. > > Please note that the new API allows you to implement a multiple selection in lists from the Java side, but I did not succeed in implementing it, because I could not determine the inclusion of the so-called "VoiceOver multiple selection mode". Artem Semenov 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: - We are trying not to use wildcard imports - probably automatic optimization of the IDE did it? I am always turning it off or set margin so high it is not triggered on anything with less then 200 individual package imports. - We don't do @author tags in openjdk Not 2022 ? - [whitespace fix - 8271846 a11y API lacks setSelectedIndex method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8578/files - new: https://git.openjdk.org/jdk/pull/8578/files/4a9bc8e4..ff825131 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8578&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8578&range=01-02 Stats: 907222 lines in 10815 files changed: 520037 ins; 279652 del; 107533 mod Patch: https://git.openjdk.org/jdk/pull/8578.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8578/head:pull/8578 PR: https://git.openjdk.org/jdk/pull/8578 From asemenov at openjdk.org Wed Nov 9 09:42:00 2022 From: asemenov at openjdk.org (Artem Semenov) Date: Wed, 9 Nov 2022 09:42:00 GMT Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v4] In-Reply-To: References: Message-ID: > A11Y implementation on macOS has to directly call the 'JList.setSelectedIndex' method in order to request selection on an item (see 'CAccessibility.requestSelection'). The reason is that a11y API lacks appropriate method.There's only 'javax.accessibility.AccessibleSelection#addAccessibleSelection' which is mapped to 'javax.swing.JList#addSelectionInterval', it can not be used to set selected index. > > @forantar @azuev-java @mrserb please review. > > Please note that the new API allows you to implement a multiple selection in lists from the Java side, but I did not succeed in implementing it, because I could not determine the inclusion of the so-called "VoiceOver multiple selection mode". Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: We are not using author tags in tests either - but that's just a nitpick. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8578/files - new: https://git.openjdk.org/jdk/pull/8578/files/ff825131..c0342b9a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8578&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8578&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/8578.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8578/head:pull/8578 PR: https://git.openjdk.org/jdk/pull/8578 From psadhukhan at openjdk.org Wed Nov 9 10:45:08 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 9 Nov 2022 10:45:08 GMT Subject: RFR: 8296083: javax/swing/JTree/6263446/bug6263446.java fails intermittently on a VM Message-ID: Test intermittently fails in VM citing "Tree is not editing". Seems to be problem with mouse clicks not getting registered properly.. Similar test test/jdk/javax/swing/JTable/6263446/bug6263446.java is not affected, so made the test similar to it by using same safeguard using Robot.waitForIdle() and modifying clickpoint to tree cell midpoint. Several iterations of the test pass in the OCI VM and all other physical platforms (link in JBS) ------------- Commit messages: - 8296083: javax/swing/JTree/6263446/bug6263446.java fails intermittently on a VM Changes: https://git.openjdk.org/jdk/pull/11057/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11057&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296083 Stats: 27 lines in 2 files changed: 21 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11057.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11057/head:pull/11057 PR: https://git.openjdk.org/jdk/pull/11057 From aivanov at openjdk.org Wed Nov 9 11:35:27 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 9 Nov 2022 11:35:27 GMT Subject: RFR: 8296496: Overzealous check in sizecalc.h prevents large memory allocation [v3] In-Reply-To: <9-eaFh_LdVPjru9mFiLeSJIPn7u6D0wVBbA4TSPxrRI=.9344e582-e0df-4bd1-b24b-390451af5975@github.com> References: <9-eaFh_LdVPjru9mFiLeSJIPn7u6D0wVBbA4TSPxrRI=.9344e582-e0df-4bd1-b24b-390451af5975@github.com> Message-ID: On Tue, 8 Nov 2022 23:43:23 GMT, Alexander Zuev wrote: >> Removed the additional multiplication overflow detection. >> Instead cast all the parameters to type_t just the way they are treated in the existing size check macro. >> This way there is no possibility to accidentally provide parameters that will pass the size check macro while being cast to size_t there but then due to the missing cast cause the wrong size passed the actual allocation function. >> Since this checking macro was used in couple of different places all of them needs to be updated in the similar way. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Fixed casting in SAFE_SIZE_NEW_ARRAY2 Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11030 From asemenov at openjdk.org Wed Nov 9 11:43:19 2022 From: asemenov at openjdk.org (Artem Semenov) Date: Wed, 9 Nov 2022 11:43:19 GMT Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v2] In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 00:51:10 GMT, Alexander Zuev wrote: >> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: >> >> We don't do @author tags in openjdk >> Not 2022 ? > > src/java.desktop/share/classes/javax/swing/JList.java line 52: > >> 50: import java.io.Serial; >> 51: import java.io.Serializable; >> 52: import java.util.*; > > We are trying not to use wildcard imports - probably automatic optimization of the IDE did it? I am always turning it off or set margin so high it is not triggered on anything with less then 200 individual package imports. done > test/jdk/java/awt/a11y/AccessibleListTest.java line 29: > >> 27: * @bug 8271846 >> 28: * @summary Test implementation of AccessibleList interface >> 29: * @author Artem.Semenov at jetbrains.com > > We are not using author tags in tests either - but that's just a nitpick. done ------------- PR: https://git.openjdk.org/jdk/pull/8578 From duke at openjdk.org Wed Nov 9 12:00:19 2022 From: duke at openjdk.org (yosbits) Date: Wed, 9 Nov 2022 12:00:19 GMT Subject: RFR: 8295779: Xcode 14.0 fails to build jdk on m1 macos In-Reply-To: References: Message-ID: <2lJKUq4Zx6Ks1hAC7xxDEqnDaMlQQ8jZGAkEk7j1CCc=.f0d00c57-02ba-4069-b79b-d392ee1f5360@github.com> On Wed, 19 Oct 2022 15:33:31 GMT, Archie L. Cobbs wrote: > Building on MacOS 12.6 M1 with Xcode 14.0 fails due to C compiler unused parameter warnings: > > Creating support/modules_libs/java.desktop/libosx.dylib from 1 file(s) It is marked as a duplicate of the issue I reported and this issue.but it is a different issue. but I am very doubtful as to why such a decision was made. https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8296654 ------------- PR: https://git.openjdk.org/jdk/pull/10768 From kcr at openjdk.org Wed Nov 9 13:54:31 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 9 Nov 2022 13:54:31 GMT Subject: RFR: 8295779: Xcode 14.0 fails to build jdk on m1 macos In-Reply-To: <2lJKUq4Zx6Ks1hAC7xxDEqnDaMlQQ8jZGAkEk7j1CCc=.f0d00c57-02ba-4069-b79b-d392ee1f5360@github.com> References: <2lJKUq4Zx6Ks1hAC7xxDEqnDaMlQQ8jZGAkEk7j1CCc=.f0d00c57-02ba-4069-b79b-d392ee1f5360@github.com> Message-ID: <7-iFNm76RWAXP0YphCDHcPSAxEN61VkXUaqkUUA7eF8=.e6b27dd8-9ff6-4967-ac42-d57285b5a2ce@github.com> On Wed, 9 Nov 2022 11:57:51 GMT, yosbits wrote: > It is marked as a duplicate of the issue I reported and this issue.but it is a different issue. but I am very doubtful as to why such a decision was made. > > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8296654 Yes, [JDK-8296654](https://bugs.openjdk.org/browse/JDK-8296654) is a different issue. I reopened it with a comment to that effect. ------------- PR: https://git.openjdk.org/jdk/pull/10768 From duke at openjdk.org Wed Nov 9 15:05:35 2022 From: duke at openjdk.org (lawrence.andrews) Date: Wed, 9 Nov 2022 15:05:35 GMT Subject: RFR: 8296083: javax/swing/JTree/6263446/bug6263446.java fails intermittently on a VM In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 10:37:24 GMT, Prasanta Sadhukhan wrote: > Test intermittently fails in VM citing "Tree is not editing". Seems to be problem with mouse clicks not getting registered properly.. > Similar test test/jdk/javax/swing/JTable/6263446/bug6263446.java is not affected, so made the test similar to it by using same safeguard using Robot.waitForIdle() and modifying clickpoint to tree cell midpoint. > > Several iterations of the test pass in the OCI VM and all other physical platforms (link in JBS) test/jdk/javax/swing/JTree/6263446/bug6263446.java line 184: > 182: > 183: frame.getContentPane().add(tree); > 184: frame.setAlwaysOnTop(true); Java doc says its better to check whether the platform supports this method before calling it https://docs.oracle.com/javase/7/docs/api/java/awt/Window.html#setAlwaysOnTop(boolean) ------------- PR: https://git.openjdk.org/jdk/pull/11057 From psadhukhan at openjdk.org Wed Nov 9 15:27:27 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 9 Nov 2022 15:27:27 GMT Subject: RFR: 8296083: javax/swing/JTree/6263446/bug6263446.java fails intermittently on a VM In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 15:03:08 GMT, lawrence.andrews wrote: >> Test intermittently fails in VM citing "Tree is not editing". Seems to be problem with mouse clicks not getting registered properly.. >> Similar test test/jdk/javax/swing/JTable/6263446/bug6263446.java is not affected, so made the test similar to it by using same safeguard using Robot.waitForIdle() and modifying clickpoint to tree cell midpoint. >> >> Several iterations of the test pass in the OCI VM and all other physical platforms (link in JBS) > > test/jdk/javax/swing/JTree/6263446/bug6263446.java line 184: > >> 182: >> 183: frame.getContentPane().add(tree); >> 184: frame.setAlwaysOnTop(true); > > Java doc says its better to check whether the platform supports this method before calling it > https://docs.oracle.com/javase/7/docs/api/java/awt/Window.html#setAlwaysOnTop(boolean) it also says "If always-on-top mode isn't supported for this window or this window's toolkit does not support always-on-top windows, calling this method has no effect." and I dont see we check for the support in any of the swing tests, so I guess we are ok.. ------------- PR: https://git.openjdk.org/jdk/pull/11057 From duke at openjdk.org Wed Nov 9 15:42:12 2022 From: duke at openjdk.org (ScientificWare) Date: Wed, 9 Nov 2022 15:42:12 GMT Subject: RFR: JDK-8296661 : Fix typo Message-ID: I suspect a typo in the documentation comments. ------------- Commit messages: - Fix typos in CSSParser.java Changes: https://git.openjdk.org/jdk/pull/10975/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10975&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296661 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10975.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10975/head:pull/10975 PR: https://git.openjdk.org/jdk/pull/10975 From angorya at openjdk.org Wed Nov 9 15:55:22 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 9 Nov 2022 15:55:22 GMT Subject: RFR: JDK-8296661 : Fix typo In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 01:56:05 GMT, ScientificWare wrote: > I suspect a typo in the documentation comments. Marked as reviewed by angorya (no project role). ------------- PR: https://git.openjdk.org/jdk/pull/10975 From jjg at openjdk.org Thu Nov 10 01:21:09 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 10 Nov 2022 01:21:09 GMT Subject: RFR: JDK-8296547: Add @spec tags to API Message-ID: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. "Normalized" means... * Use `https:` where possible (includes pretty much all cases) * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) * Point to the root page of a multi-page spec * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. ------------- Commit messages: - JDK-8296547: Add @spec tags to API Changes: https://git.openjdk.org/jdk/pull/11073/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11073&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296547 Stats: 816 lines in 420 files changed: 816 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11073.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11073/head:pull/11073 PR: https://git.openjdk.org/jdk/pull/11073 From duke at openjdk.org Thu Nov 10 04:29:36 2022 From: duke at openjdk.org (ravi gupta) Date: Thu, 10 Nov 2022 04:29:36 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. [v2] In-Reply-To: References: Message-ID: > This testcase Verify the content changes of a TextArea for the following assertions. > > a. TextListener get invoked when the content of a TextArea gets changed. > b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. > > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. ravi gupta has updated the pull request incrementally with one additional commit since the last revision: 8296632: Review fixes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11052/files - new: https://git.openjdk.org/jdk/pull/11052/files/843cf491..898c2bf3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11052&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11052&range=00-01 Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11052.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11052/head:pull/11052 PR: https://git.openjdk.org/jdk/pull/11052 From duke at openjdk.org Thu Nov 10 05:14:36 2022 From: duke at openjdk.org (Naveen Narayanan) Date: Thu, 10 Nov 2022 05:14:36 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem. [v3] In-Reply-To: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> Message-ID: > This testcase will > 1) Verify setAccelerator method of JMenuitem. > 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M. > > Testing: > Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: 8296275: Review comments fixed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11035/files - new: https://git.openjdk.org/jdk/pull/11035/files/19a0ba96..3dc79dd4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11035&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11035&range=01-02 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11035.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11035/head:pull/11035 PR: https://git.openjdk.org/jdk/pull/11035 From jdv at openjdk.org Thu Nov 10 05:45:25 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 10 Nov 2022 05:45:25 GMT Subject: RFR: 8285635: javax/swing/JRootPane/DefaultButtonTest.java failed with Default Button not pressed for L&F: com.sun.java.swing.plaf.motif.MotifLookAndFeel In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 06:27:19 GMT, Prasanta Sadhukhan wrote: > Test sometimes fail for Motif L&F only which might require some code change in Motif code but since Motif is already deprecated and obsolete, it seems prudent to skip Motif L&F in the test. > Several iterations of the modified test pass in all platforms. Marked as reviewed by jdv (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10978 From serb at openjdk.org Thu Nov 10 05:53:40 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 10 Nov 2022 05:53:40 GMT Subject: RFR: 6788481: CellEditorListener.editingCanceled is never called In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 07:05:10 GMT, Prasanta Sadhukhan wrote: > When editing of a table cell is canceled, the function editingCanceled of the registered listener CellEditorListener is not called as actionPerformed on ESC key press was not notifying the "cancel" listeners. > Fix is to handle "Cancel" action in actionPerformed() by forwarding the Cancel message from CellEditor to the delegate so that it can call `AbstractCellEditor.fireEditingCanceled(`) which notifies all listeners of cancel event. test/jdk/javax/swing/JTable/BugCellEditorListener.java line 51: > 49: static volatile boolean cancelled; > 50: > 51: public static void main(String [] args) throws Exception { Can the test validates all installed L&F and not only default metal/aqua? ------------- PR: https://git.openjdk.org/jdk/pull/10964 From psadhukhan at openjdk.org Thu Nov 10 05:55:31 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 10 Nov 2022 05:55:31 GMT Subject: Integrated: 8285635: javax/swing/JRootPane/DefaultButtonTest.java failed with Default Button not pressed for L&F: com.sun.java.swing.plaf.motif.MotifLookAndFeel In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 06:27:19 GMT, Prasanta Sadhukhan wrote: > Test sometimes fail for Motif L&F only which might require some code change in Motif code but since Motif is already deprecated and obsolete, it seems prudent to skip Motif L&F in the test. > Several iterations of the modified test pass in all platforms. This pull request has now been integrated. Changeset: 79c00921 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/79c0092125ef01e2980f8072d7b295ce0c1a6077 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod 8285635: javax/swing/JRootPane/DefaultButtonTest.java failed with Default Button not pressed for L&F: com.sun.java.swing.plaf.motif.MotifLookAndFeel Reviewed-by: tr, jdv ------------- PR: https://git.openjdk.org/jdk/pull/10978 From mvs at openjdk.org Thu Nov 10 06:02:33 2022 From: mvs at openjdk.org (Manukumar V S) Date: Thu, 10 Nov 2022 06:02:33 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. [v2] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 04:29:36 GMT, ravi gupta wrote: >> This testcase Verify the content changes of a TextArea for the following assertions. >> >> a. TextListener get invoked when the content of a TextArea gets changed. >> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8296632: Review fixes. test/jdk/java/awt/event/ComponentEvent/TextAreaTextEventTest.java line 127: > 125: textArea = new TextArea(5, 15); > 126: textArea.addTextListener((event) -> { > 127: System.out.println("Got an Text Event: " + event); "Got a text event" ------------- PR: https://git.openjdk.org/jdk/pull/11052 From serb at openjdk.org Thu Nov 10 06:05:21 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 10 Nov 2022 06:05:21 GMT Subject: RFR: 8296083: javax/swing/JTree/6263446/bug6263446.java fails intermittently on a VM In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 10:37:24 GMT, Prasanta Sadhukhan wrote: > Test intermittently fails in VM citing "Tree is not editing". Seems to be problem with mouse clicks not getting registered properly.. > Similar test test/jdk/javax/swing/JTable/6263446/bug6263446.java is not affected, so made the test similar to it by using same safeguard using Robot.waitForIdle() and modifying clickpoint to tree cell midpoint. > > Several iterations of the test pass in the OCI VM and all other physical platforms (link in JBS) test/jdk/javax/swing/JTree/6263446/bug6263446.java line 131: > 129: robot.mousePress(InputEvent.BUTTON1_DOWN_MASK); > 130: robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK); > 131: robot.waitForIdle(); Why do we remove it here and then add it after each call of this "click" method? why not move to the end of the method? test/jdk/javax/swing/JTree/6263446/bug6263446.java line 186: > 184: frame.setAlwaysOnTop(true); > 185: frame.setLocationRelativeTo(null); > 186: frame.pack(); pack() after the setLocationRelativeTo() may move the frame out of the center of the screen, is it intentional? ------------- PR: https://git.openjdk.org/jdk/pull/11057 From tr at openjdk.org Thu Nov 10 06:07:21 2022 From: tr at openjdk.org (Tejesh R) Date: Thu, 10 Nov 2022 06:07:21 GMT Subject: RFR: 8227257: javax/swing/JFileChooser/4847375/bug4847375.java fails with AssertionError Message-ID: Observation found when _JFileChooser_ is instantiated in _WindowsLookAndFeel_ which invokes _getSystemIcon()_ from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where _resolutionVariants_ map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing _getWidth()_. Fix is tested in CI system. ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/11079/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11079&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8227257 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11079.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11079/head:pull/11079 PR: https://git.openjdk.org/jdk/pull/11079 From tr at openjdk.org Thu Nov 10 06:07:21 2022 From: tr at openjdk.org (Tejesh R) Date: Thu, 10 Nov 2022 06:07:21 GMT Subject: RFR: 8227257: javax/swing/JFileChooser/4847375/bug4847375.java fails with AssertionError In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 06:00:27 GMT, Tejesh R wrote: > Observation found when _JFileChooser_ is instantiated in _WindowsLookAndFeel_ which invokes _getSystemIcon()_ from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where _resolutionVariants_ map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing _getWidth()_. Fix is tested in CI system. @bug [JDK-8293862](https://bugs.openjdk.org/browse/JDK-8293862) ------------- PR: https://git.openjdk.org/jdk/pull/11079 From serb at openjdk.org Thu Nov 10 06:08:09 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 10 Nov 2022 06:08:09 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. [v2] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 04:29:36 GMT, ravi gupta wrote: >> This testcase Verify the content changes of a TextArea for the following assertions. >> >> a. TextListener get invoked when the content of a TextArea gets changed. >> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8296632: Review fixes. test/jdk/java/awt/event/ComponentEvent/TextAreaTextEventTest.java line 53: > 51: public static void main(String[] args) throws Exception { > 52: try { > 53: EventQueue.invokeLater(TextAreaTextEventTest::initializeGUI); Why the "invokeLater" and not "invokeAndWait"? ------------- PR: https://git.openjdk.org/jdk/pull/11052 From serb at openjdk.org Thu Nov 10 06:11:06 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 10 Nov 2022 06:11:06 GMT Subject: Integrated: 8295812: Skip the "half float" support in LittleCMS during the build In-Reply-To: References: Message-ID: On Sun, 23 Oct 2022 20:10:35 GMT, Sergey Bylokhov wrote: > The Java2d do not use "half" float in the image layouts, so we can disable it in the LittleCMS library during the build. It is possible to do using [this](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/liblcms/lcms2.h#L85) public option: > > > // Uncomment to get rid of the tables for "half" float support > // #define CMS_NO_HALF_SUPPORT 1 > > > This change cuts not only the unused by java2d functions but also [such](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/share/native/liblcms/cmshalf.c#L63) tables. > > The size of liblcms decreased by 20 kB on Linux(536024 vs 515152) and 15 kB on windows(246784 vs 231424). On macOS the win is only 300 bytes. This pull request has now been integrated. Changeset: f0a6e71e Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/f0a6e71e4d63c9820659f6ff29f94d0476d48b09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8295812: Skip the "half float" support in LittleCMS during the build Reviewed-by: erikj, prr, ihse ------------- PR: https://git.openjdk.org/jdk/pull/10830 From serb at openjdk.org Thu Nov 10 06:21:46 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 10 Nov 2022 06:21:46 GMT Subject: Integrated: 8295430: Use cmsDoTransformLineStride instead of cmsDoTransform in the loop In-Reply-To: <0FRqG16zkqljRkLjTq1bplcPpoJAm98eLYvjZdR6g14=.35e8b2b3-defe-4af0-a98f-1fadd358e42d@github.com> References: <0FRqG16zkqljRkLjTq1bplcPpoJAm98eLYvjZdR6g14=.35e8b2b3-defe-4af0-a98f-1fadd358e42d@github.com> Message-ID: On Wed, 19 Oct 2022 02:59:37 GMT, Sergey Bylokhov wrote: > This is the request to improve the change made by the > [8005530: [lcms] Improve performance of ColorConverOp for default destinations](http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/fd8810d50c99) > > Right now the LCMSTransform mantain the special "imageAtOnce" flags and call cmsDoTransform function in the loop per line to support the gaps betwen the lines in the images . This code can be improved by using one call to cmsDoTransformLineStride. Some discussion about this method can be found [here](https://github.com/mm2/Little-CMS/issues/314), the full [specification](https://github.com/mm2/Little-CMS/blob/master/doc/LittleCMS2.14%20API.pdf): > > > void cmsDoTransformLineStride(cmsHTRANSFORM Transform, > const void* InputBuffer, > void* OutputBuffer, > cmsUInt32Number PixelsPerLine, > cmsUInt32Number LineCount, > cmsUInt32Number BytesPerLineIn, > cmsUInt32Number BytesPerLineOut, > cmsUInt32Number BytesPerPlaneIn, > cmsUInt32Number BytesPerPlaneOut); > > This function translates bitmaps with complex organization. Each bitmap may contain > several lines, and every may have padding. The distance from one line to the next one is > BytesPerLine{In/Out}. In planar formats, each line may hold several planes, each plane may > have padding. Padding of lines and planes should be same across all bitmap. I.e. all lines > in same bitmap have to be padded in same way. This function may be more efficient that > repeated calls to cmsDoTransform(), especially when customized plug-ins are being used. > > Parameters: > > - hTransform: Handle to a color transform object. > - InputBuffer: A pointer to the input bitmap > - OutputBuffer: A pointer to the output bitmap. > - PixelsPerLine: The number of pixels for line, which is same on input and in output. > - LineCount: The number of lines, which is same on input and output > - BytesPerLine{In,Out}: The distance in bytes from one line to the next one. > - BytesPerPlaneIn{In,Out}: The distance in bytes from one plane to the next one inside a line. Only applies > in planar formats. > > > Notes: > - This function is quite efficient, and is used by some plug-ins to give a big > speedup. If you can load whole image to memory and then call this function > over it, it will be much faster than any other approach. > - BytesPerPlaneIn{In,Out} is ignored if the formats used are not planar. Please note > 1-plane planar is indistinguishable from 1-component chunky, so BytesPerPlane is > ignored as well in this case. > - If the image does not have any gaps between the pixels and lines BytesPerLine{} > are equal to the pixel's size * PixelsPerLine. > - To specify padding between pixels, use T_EXTRA() and EXTRA_SH() to specify > extra channels. This pull request has now been integrated. Changeset: 78a08a0f Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/78a08a0f2176d5eb4afffc06a7df2a1cea4ade4b Stats: 378 lines in 6 files changed: 340 ins; 34 del; 4 mod 8295430: Use cmsDoTransformLineStride instead of cmsDoTransform in the loop Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/10754 From mvs at openjdk.org Thu Nov 10 06:26:02 2022 From: mvs at openjdk.org (Manukumar V S) Date: Thu, 10 Nov 2022 06:26:02 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. [v2] In-Reply-To: References: Message-ID: <5QqUKyjgFWBbUDCpbeoa5PgXOiiLy99Bm_PZgCUtkEU=.262faf3e-d115-4cdc-8474-84bbf299b651@github.com> On Thu, 10 Nov 2022 04:29:36 GMT, ravi gupta wrote: >> This testcase Verify the content changes of a TextArea for the following assertions. >> >> a. TextListener get invoked when the content of a TextArea gets changed. >> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8296632: Review fixes. test/jdk/java/awt/event/ComponentEvent/TextAreaTextEventTest.java line 43: > 41: public class TextAreaTextEventTest { > 42: > 43: private static final int delay = 100; Is this delay variable really needed, I think we are using it only one place ------------- PR: https://git.openjdk.org/jdk/pull/11052 From tr at openjdk.org Thu Nov 10 06:27:35 2022 From: tr at openjdk.org (Tejesh R) Date: Thu, 10 Nov 2022 06:27:35 GMT Subject: RFR: 8227257: javax/swing/JFileChooser/4847375/bug4847375.java fails with AssertionError In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 06:00:27 GMT, Tejesh R wrote: > Observation found when _JFileChooser_ is instantiated in _WindowsLookAndFeel_ which invokes _getSystemIcon()_ from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where _resolutionVariants_ map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing _getWidth()_. Fix is tested in CI system. @azuev-java Can please share your comments on the PR. ------------- PR: https://git.openjdk.org/jdk/pull/11079 From psadhukhan at openjdk.org Thu Nov 10 06:41:07 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 10 Nov 2022 06:41:07 GMT Subject: RFR: 8296083: javax/swing/JTree/6263446/bug6263446.java fails intermittently on a VM In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 06:01:39 GMT, Sergey Bylokhov wrote: >> Test intermittently fails in VM citing "Tree is not editing". Seems to be problem with mouse clicks not getting registered properly.. >> Similar test test/jdk/javax/swing/JTable/6263446/bug6263446.java is not affected, so made the test similar to it by using same safeguard using Robot.waitForIdle() and modifying clickpoint to tree cell midpoint. >> >> Several iterations of the test pass in the OCI VM and all other physical platforms (link in JBS) > > test/jdk/javax/swing/JTree/6263446/bug6263446.java line 131: > >> 129: robot.mousePress(InputEvent.BUTTON1_DOWN_MASK); >> 130: robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK); >> 131: robot.waitForIdle(); > > Why do we remove it here and then add it after each call of this "click" method? why not move to the end of the method? I wanted to keep it same as JTable/626344 one and it worked in the OCI systems...I do not want to change it/optimise it with the access to test in these OCI systems being limited... > test/jdk/javax/swing/JTree/6263446/bug6263446.java line 186: > >> 184: frame.setAlwaysOnTop(true); >> 185: frame.setLocationRelativeTo(null); >> 186: frame.pack(); > > pack() after the setLocationRelativeTo() may move the frame out of the center of the screen, is it intentional? it doesn't and I have checked ------------- PR: https://git.openjdk.org/jdk/pull/11057 From tr at openjdk.org Thu Nov 10 07:40:46 2022 From: tr at openjdk.org (Tejesh R) Date: Thu, 10 Nov 2022 07:40:46 GMT Subject: RFR: 8296083: javax/swing/JTree/6263446/bug6263446.java fails intermittently on a VM In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 10:37:24 GMT, Prasanta Sadhukhan wrote: > Test intermittently fails in VM citing "Tree is not editing". Seems to be problem with mouse clicks not getting registered properly.. > Similar test test/jdk/javax/swing/JTable/6263446/bug6263446.java is not affected, so made the test similar to it by using same safeguard using Robot.waitForIdle() and modifying clickpoint to tree cell midpoint. > > Several iterations of the test pass in the OCI VM and all other physical platforms (link in JBS) Marked as reviewed by tr (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/11057 From abhiscxk at openjdk.org Thu Nov 10 08:09:32 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 10 Nov 2022 08:09:32 GMT Subject: RFR: 8296222: SwingEventMonitor - installListeners(Component , int ) - CELLEDITOR - bug Message-ID: It seems there was a typo inside function `installListeners(Component, int)` and `removeListeners(Component)` on case EventID.CELLEDITOR. Changed the string from "getCellEditorMethod" to "getCellEditor" in `protected void installListeners(Component c, int eventID)` and `protected void removeListeners(Component c)` methods. Didn't add any test case. ------------- Commit messages: - Typo error fix Changes: https://git.openjdk.org/jdk/pull/11082/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11082&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296222 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11082.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11082/head:pull/11082 PR: https://git.openjdk.org/jdk/pull/11082 From abhiscxk at openjdk.org Thu Nov 10 11:30:35 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 10 Nov 2022 11:30:35 GMT Subject: RFR: 8296222: SwingEventMonitor - installListeners(Component , int ) - CELLEDITOR - bug In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 08:01:38 GMT, Abhishek Kumar wrote: > It seems there was a typo inside function `installListeners(Component, int)` and `removeListeners(Component)` on case EventID.CELLEDITOR. > > Changed the string from "getCellEditorMethod" to "getCellEditor" in `protected void installListeners(Component c, int eventID)` and `protected void removeListeners(Component c)` methods. > > Didn't add any test case. @azuev-java Can you please review this PR? ------------- PR: https://git.openjdk.org/jdk/pull/11082 From dfuchs at openjdk.org Thu Nov 10 11:34:25 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 10 Nov 2022 11:34:25 GMT Subject: RFR: JDK-8296547: Add @spec tags to API In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote: > Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. > > To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. Hi Jon, When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this: http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/URL.html External Specifications [Format for Literal IPv6 Addresses in URL's](https://www.ietf.org/rfc/rfc2732.html), [Uniform Resource Identifier (URI): Generic Syntax](https://www.ietf.org/rfc/rfc3986.html), [Uniform Resource Identifiers (URI): Generic Syntax](https://www.ietf.org/rfc/rfc2396.html) You will see that two of the RFC links have the same text but link to different RFCs, which I am finding confusing. Also I do hope it's clear that if a specification is referenced it doesn't mean it's being implemented. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From alanb at openjdk.org Thu Nov 10 11:49:21 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 10 Nov 2022 11:49:21 GMT Subject: RFR: JDK-8296547: Add @spec tags to API In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com> On Thu, 10 Nov 2022 11:30:51 GMT, Daniel Fuchs wrote: > When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this: I agree and also to add that some RFCs have commas in their titles, the same separator used when there is more than one specification linked. Here's an example: http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/nio/channels/MulticastChannel.html ------------- PR: https://git.openjdk.org/jdk/pull/11073 From alanb at openjdk.org Thu Nov 10 12:04:51 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 10 Nov 2022 12:04:51 GMT Subject: RFR: JDK-8296547: Add @spec tags to API In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote: > Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. > > To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. I'm just trying to understand what "fix-ups" will be needed if the automated patch is applied. In some cases, it looks the same will spec linked from "See also" and "External Specifications", e.g. http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/StandardSocketOptions.html#TCP_NODELAY so the `@see` ref can be dropped. In other cases we will have inline refs and the same URL in the `@spec`. This may be okay for the short term but maybe there is a way to inline `@spec` to avoid the duplication? There will probably be a bit of cleanup to reflow some lines, e.g. StandardSocketOptions.java, as excessively long lines are problematic for side-by-side diffs. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From abhiscxk at openjdk.org Thu Nov 10 13:27:35 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 10 Nov 2022 13:27:35 GMT Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel [v4] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 11:00:10 GMT, Prasanta Sadhukhan wrote: >> With the current fix, GTK FileChooser allows to select all folders in folder list but in files list it allows only single file selection. > > So, it is same without the fix too as is mentioned in that bug. Can you please see why that is so as it should be exercising the same code path as this fix? @prsadhuk As discussed I have checked with the condition modified to `chooser.getFileSelectionMode() != JFileChooser.FILES_ONLY`, but this leads to failure for current test in `FILES_AND_DIRECTORIES` and `DIRECTORIES_ONLY` selection mode. And for [JDK-4912623](https://bugs.openjdk.org/browse/JDK-4912623), still not able to select all files in JFileChooser on press of ctrl+A. ------------- PR: https://git.openjdk.org/jdk/pull/10866 From psadhukhan at openjdk.org Thu Nov 10 13:38:30 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 10 Nov 2022 13:38:30 GMT Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel [v6] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 07:06:27 GMT, Abhishek Kumar wrote: >> While using a JFileChooser with the file selection mode FILES_AND_DIRECTORIES and multiSelection enabled, it is impossible to select a single directory in GTK LAF. >> >> The condition check has been modified when multiselection is enabled and user has selected single directory. >> After the fix the behavior of JFileChooser is similar to other LAFs. >> >> An automatic test case `test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java` is implemented and checked in CI pipeline. Link is attached in JBS. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Review comment fix Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10866 From psadhukhan at openjdk.org Thu Nov 10 13:38:32 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 10 Nov 2022 13:38:32 GMT Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel [v4] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 13:25:14 GMT, Abhishek Kumar wrote: >> So, it is same without the fix too as is mentioned in that bug. Can you please see why that is so as it should be exercising the same code path as this fix? > > @prsadhuk As discussed I have checked with the condition modified to `chooser.getFileSelectionMode() != JFileChooser.FILES_ONLY`, but this leads to failure for current test in `FILES_AND_DIRECTORIES` and `DIRECTORIES_ONLY` selection mode. > > And for [JDK-4912623](https://bugs.openjdk.org/browse/JDK-4912623), still not able to select all files in JFileChooser on press of ctrl+A. ok ------------- PR: https://git.openjdk.org/jdk/pull/10866 From tr at openjdk.org Thu Nov 10 13:44:27 2022 From: tr at openjdk.org (Tejesh R) Date: Thu, 10 Nov 2022 13:44:27 GMT Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel [v6] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 07:06:27 GMT, Abhishek Kumar wrote: >> While using a JFileChooser with the file selection mode FILES_AND_DIRECTORIES and multiSelection enabled, it is impossible to select a single directory in GTK LAF. >> >> The condition check has been modified when multiselection is enabled and user has selected single directory. >> After the fix the behavior of JFileChooser is similar to other LAFs. >> >> An automatic test case `test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java` is implemented and checked in CI pipeline. Link is attached in JBS. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Review comment fix Marked as reviewed by tr (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/10866 From duke at openjdk.org Thu Nov 10 14:13:08 2022 From: duke at openjdk.org (ravi gupta) Date: Thu, 10 Nov 2022 14:13:08 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. [v3] In-Reply-To: References: Message-ID: > This testcase Verify the content changes of a TextArea for the following assertions. > > a. TextListener get invoked when the content of a TextArea gets changed. > b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. > > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. ravi gupta has updated the pull request incrementally with one additional commit since the last revision: 8296632: Review fixes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11052/files - new: https://git.openjdk.org/jdk/pull/11052/files/898c2bf3..c5c93e82 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11052&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11052&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11052.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11052/head:pull/11052 PR: https://git.openjdk.org/jdk/pull/11052 From abhiscxk at openjdk.org Thu Nov 10 14:14:43 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 10 Nov 2022 14:14:43 GMT Subject: Integrated: 6972078: Can not select single directory with GTKLookAndFeel In-Reply-To: References: Message-ID: <7OzsLD5jpBoAKZV-JJQzv4LPzRw4RsWP2qrAOA_zN9g=.d61342a6-9b55-49e9-952c-a45fc92aaf20@github.com> On Wed, 26 Oct 2022 04:34:24 GMT, Abhishek Kumar wrote: > While using a JFileChooser with the file selection mode FILES_AND_DIRECTORIES and multiSelection enabled, it is impossible to select a single directory in GTK LAF. > > The condition check has been modified when multiselection is enabled and user has selected single directory. > After the fix the behavior of JFileChooser is similar to other LAFs. > > An automatic test case `test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java` is implemented and checked in CI pipeline. Link is attached in JBS. This pull request has now been integrated. Changeset: 4a68210d Author: Abhishek Kumar Committer: Tejesh R URL: https://git.openjdk.org/jdk/commit/4a68210d9f6c59ec4289b2e2412a1ae0df17fd81 Stats: 219 lines in 2 files changed: 218 ins; 0 del; 1 mod 6972078: Can not select single directory with GTKLookAndFeel Reviewed-by: psadhukhan, tr ------------- PR: https://git.openjdk.org/jdk/pull/10866 From mvs at openjdk.org Thu Nov 10 15:59:12 2022 From: mvs at openjdk.org (Manukumar V S) Date: Thu, 10 Nov 2022 15:59:12 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. [v3] In-Reply-To: References: Message-ID: <5udKZ-r9O-LAjCTHPOaZEZIx52RQaHKhKlsZZl83oPI=.b3ac509a-6c9a-4bf6-ac13-dc2e93999d38@github.com> On Thu, 10 Nov 2022 14:13:08 GMT, ravi gupta wrote: >> This testcase Verify the content changes of a TextArea for the following assertions. >> >> a. TextListener get invoked when the content of a TextArea gets changed. >> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8296632: Review fixes. use BUTTON1_DOWN_MASK everywhere test/jdk/java/awt/event/ComponentEvent/TextAreaTextEventTest.java line 94: > 92: textChanged = false; > 93: robot.mouseMove(textAreaAt.x + 4, textAreaAt.y + 10); > 94: robot.mousePress(InputEvent.BUTTON1_MASK); use BUTTON1_DOWN_MASK everywhere ------------- PR: https://git.openjdk.org/jdk/pull/11052 From mvs at openjdk.org Thu Nov 10 15:59:15 2022 From: mvs at openjdk.org (Manukumar V S) Date: Thu, 10 Nov 2022 15:59:15 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. [v2] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 04:29:36 GMT, ravi gupta wrote: >> This testcase Verify the content changes of a TextArea for the following assertions. >> >> a. TextListener get invoked when the content of a TextArea gets changed. >> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8296632: Review fixes. test/jdk/java/awt/event/ComponentEvent/TextAreaTextEventTest.java line 69: > 67: textAreaAt.y + textAreaSize.height / 2); > 68: > 69: robot.mousePress(InputEvent.BUTTON1_MASK); use BUTTON1_DOWN_MASK ------------- PR: https://git.openjdk.org/jdk/pull/11052 From weijun at openjdk.org Thu Nov 10 16:24:26 2022 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 10 Nov 2022 16:24:26 GMT Subject: RFR: JDK-8296547: Add @spec tags to API In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote: > Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. > > To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. I see https://www.ietf.org/rfc/rfc0822.html. Should be https://www.ietf.org/rfc/rfc822.html ------------- PR: https://git.openjdk.org/jdk/pull/11073 From angorya at openjdk.org Thu Nov 10 16:32:30 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 10 Nov 2022 16:32:30 GMT Subject: RFR: 8296222: SwingEventMonitor - installListeners(Component , int ) - CELLEDITOR - bug In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 08:01:38 GMT, Abhishek Kumar wrote: > It seems there was a typo inside function `installListeners(Component, int)` and `removeListeners(Component)` on case EventID.CELLEDITOR. > > Changed the string from "getCellEditorMethod" to "getCellEditor" in `protected void installListeners(Component c, int eventID)` and `protected void removeListeners(Component c)` methods. > > Didn't add any test case. Marked as reviewed by angorya (no project role). src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/SwingEventMonitor.java line 990: > 988: try { > 989: getCellEditorMethod = c.getClass().getMethod( > 990: "getCellEditor", nullClass); 1. why would they use reflection in the first place? 2. wouldn't these code paths be covered by (failing) accessibility unit tests? ------------- PR: https://git.openjdk.org/jdk/pull/11082 From duke at openjdk.org Thu Nov 10 16:35:32 2022 From: duke at openjdk.org (AJ1062910) Date: Thu, 10 Nov 2022 16:35:32 GMT Subject: RFR: JDK-8296547: Add @spec tags to API In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote: > Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. > > To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. did you changed 420 files ? ------------- PR: https://git.openjdk.org/jdk/pull/11073 From lucy at openjdk.org Thu Nov 10 16:52:39 2022 From: lucy at openjdk.org (Lutz Schmidt) Date: Thu, 10 Nov 2022 16:52:39 GMT Subject: RFR: 8295779: Xcode 14.0 fails to build jdk on m1 macos In-Reply-To: References: Message-ID: On Wed, 19 Oct 2022 15:33:31 GMT, Archie L. Cobbs wrote: > Building on MacOS 12.6 M1 with Xcode 14.0 fails due to C compiler unused parameter warnings: > > Creating support/modules_libs/java.desktop/libosx.dylib from 1 file(s) As an interim solution until LCMS 2.14 has been pulled in, you could suppress the warning like that: diff --git a/make/modules/java.desktop/lib/Awt2dLibraries.gmk b/make/modules/java.desktop/lib/Awt2dLibraries.gmk index ce14776503f..55070197ebb 100644 --- a/make/modules/java.desktop/lib/Awt2dLibraries.gmk +++ b/make/modules/java.desktop/lib/Awt2dLibraries.gmk @@ -306,7 +306,7 @@ $(eval $(call SetupJdkLibrary, BUILD_LIBLCMS, \ libawt/java2d, \ HEADERS_FROM_SRC := $(LIBLCMS_HEADERS_FROM_SRC), \ DISABLED_WARNINGS_gcc := format-nonliteral stringop-truncation, \ - DISABLED_WARNINGS_clang := format-nonliteral, \ + DISABLED_WARNINGS_clang := format-nonliteral unused-but-set-parameter, \ LDFLAGS := $(LDFLAGS_JDKLIB) \ $(call SET_SHARED_LIBRARY_ORIGIN), \ LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ There are a few other places which need a similar fix. ------------- PR: https://git.openjdk.org/jdk/pull/10768 From abhiscxk at openjdk.org Thu Nov 10 17:31:27 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 10 Nov 2022 17:31:27 GMT Subject: RFR: 8296222: SwingEventMonitor - installListeners(Component , int ) - CELLEDITOR - bug In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 16:30:12 GMT, Andy Goryachev wrote: >> It seems there was a typo inside function `installListeners(Component, int)` and `removeListeners(Component)` on case EventID.CELLEDITOR. >> >> Changed the string from "getCellEditorMethod" to "getCellEditor" in `protected void installListeners(Component c, int eventID)` and `protected void removeListeners(Component c)` methods. >> >> Didn't add any test case. > > src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/SwingEventMonitor.java line 990: > >> 988: try { >> 989: getCellEditorMethod = c.getClass().getMethod( >> 990: "getCellEditor", nullClass); > > 1. why would they use reflection in the first place? > 2. wouldn't these code paths be covered by (failing) accessibility unit tests? I am not sure about your first point. But for second point I think it is mentioned in [JDK-8296222](https://bugs.openjdk.org/browse/JDK-8296222) that "-> It looks like it was never tested " ------------- PR: https://git.openjdk.org/jdk/pull/11082 From duke at openjdk.org Thu Nov 10 17:41:32 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 10 Nov 2022 17:41:32 GMT Subject: RFR: 8295779: Xcode 14.0 fails to build jdk on m1 macos In-Reply-To: References: Message-ID: On Wed, 19 Oct 2022 15:33:31 GMT, Archie L. Cobbs wrote: > Building on MacOS 12.6 M1 with Xcode 14.0 fails due to C compiler unused parameter warnings: > > Creating support/modules_libs/java.desktop/libosx.dylib from 1 file(s) FWIW here are the patches I'm currently dragging along in order to build the `master` branch: diff --git a/make/modules/java.desktop/lib/Awt2dLibraries.gmk b/make/modules/java.desktop/lib/Awt2dLibraries.gmk index b02c0fa6c82..b279178834e 100644 --- a/make/modules/java.desktop/lib/Awt2dLibraries.gmk +++ b/make/modules/java.desktop/lib/Awt2dLibraries.gmk @@ -764,6 +764,7 @@ ifeq ($(ENABLE_HEADLESS_ONLY), false) DISABLED_WARNINGS_gcc_splashscreen_sys.c := type-limits unused-result, \ DISABLED_WARNINGS_clang_dgif_lib.c := sign-compare, \ DISABLED_WARNINGS_clang_gzwrite.c := format-nonliteral, \ + DISABLED_WARNINGS_clang_pngrutil.c := null-pointer-subtraction, \ DISABLED_WARNINGS_clang_splashscreen_impl.c := sign-compare, \ DISABLED_WARNINGS_clang_splashscreen_png.c := incompatible-pointer-types, \ DISABLED_WARNINGS_clang_splashscreen_sys.m := deprecated-declarations, \ diff --git a/src/java.desktop/share/native/liblcms/cmstypes.c b/src/java.desktop/share/native/liblcms/cmstypes.c index 006f98b084d..9a793f3efb5 100644 --- a/src/java.desktop/share/native/liblcms/cmstypes.c +++ b/src/java.desktop/share/native/liblcms/cmstypes.c @@ -3444,6 +3444,8 @@ void *Type_ProfileSequenceId_Read(struct _cms_typehandler_struct* self, cmsIOHAN cmsUInt32Number Count; cmsUInt32Number BaseOffset; + cmsUNUSED_PARAMETER(SizeOfTag); + *nItems = 0; // Get actual position as a basis for element offsets @@ -5144,6 +5146,8 @@ void *Type_Dictionary_Read(struct _cms_typehandler_struct* self, cmsIOHANDLER* i cmsMLU *DisplayNameMLU = NULL, *DisplayValueMLU=NULL; cmsBool rc; + cmsUNUSED_PARAMETER(SizeOfTag); + *nItems = 0; // Get actual position as a basis for element offsets ------------- PR: https://git.openjdk.org/jdk/pull/10768 From vkempik at openjdk.org Thu Nov 10 18:14:34 2022 From: vkempik at openjdk.org (Vladimir Kempik) Date: Thu, 10 Nov 2022 18:14:34 GMT Subject: RFR: 8295779: Xcode 14.0 fails to build jdk on m1 macos In-Reply-To: References: Message-ID: <6_AfcMqBDcwYEuFHngyfTAWLheVXHWKO3RdT3pRJlB8=.df5528da-124f-4a35-97c0-ade06918a1b4@github.com> On Wed, 19 Oct 2022 15:33:31 GMT, Archie L. Cobbs wrote: > Building on MacOS 12.6 M1 with Xcode 14.0 fails due to C compiler unused parameter warnings: > > Creating support/modules_libs/java.desktop/libosx.dylib from 1 file(s) Well, you can just use --disable-warnings-as-errors configure argument until this fixed ------------- PR: https://git.openjdk.org/jdk/pull/10768 From duke at openjdk.org Thu Nov 10 19:11:40 2022 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 10 Nov 2022 19:11:40 GMT Subject: RFR: 8295779: Xcode 14.0 fails to build jdk on m1 macos In-Reply-To: <6_AfcMqBDcwYEuFHngyfTAWLheVXHWKO3RdT3pRJlB8=.df5528da-124f-4a35-97c0-ade06918a1b4@github.com> References: <6_AfcMqBDcwYEuFHngyfTAWLheVXHWKO3RdT3pRJlB8=.df5528da-124f-4a35-97c0-ade06918a1b4@github.com> Message-ID: On Thu, 10 Nov 2022 18:09:52 GMT, Vladimir Kempik wrote: > Well, you can just use `--disable-warnings-as-errors` configure argument until this fixed Sure, but that's too blunt an instrument. It defeats the whole purpose of having warnings in the first place. If you're hacking on the code with intent to submit it back via PR, you _want_ the warnings, at least, the valid ones. ------------- PR: https://git.openjdk.org/jdk/pull/10768 From azvegint at openjdk.org Thu Nov 10 20:48:39 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 10 Nov 2022 20:48:39 GMT Subject: RFR: 8296496: Overzealous check in sizecalc.h prevents large memory allocation [v3] In-Reply-To: <9-eaFh_LdVPjru9mFiLeSJIPn7u6D0wVBbA4TSPxrRI=.9344e582-e0df-4bd1-b24b-390451af5975@github.com> References: <9-eaFh_LdVPjru9mFiLeSJIPn7u6D0wVBbA4TSPxrRI=.9344e582-e0df-4bd1-b24b-390451af5975@github.com> Message-ID: On Tue, 8 Nov 2022 23:43:23 GMT, Alexander Zuev wrote: >> Removed the additional multiplication overflow detection. >> Instead cast all the parameters to type_t just the way they are treated in the existing size check macro. >> This way there is no possibility to accidentally provide parameters that will pass the size check macro while being cast to size_t there but then due to the missing cast cause the wrong size passed the actual allocation function. >> Since this checking macro was used in couple of different places all of them needs to be updated in the similar way. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Fixed casting in SAFE_SIZE_NEW_ARRAY2 Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11030 From mullan at openjdk.org Thu Nov 10 21:34:30 2022 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 10 Nov 2022 21:34:30 GMT Subject: RFR: JDK-8296547: Add @spec tags to API In-Reply-To: <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com> Message-ID: <9dD51N9kpu4MV5_oJ1e6lxsYLxnk6mG5mQeH_SAzWqA=.71dcec22-0ad2-41f2-89e3-8c9964db61cb@github.com> On Thu, 10 Nov 2022 11:45:39 GMT, Alan Bateman wrote: > When referencing an RFC, it might be good to keep the RFC number in the text link. +1. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From jjg at openjdk.org Thu Nov 10 21:58:28 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 10 Nov 2022 21:58:28 GMT Subject: RFR: JDK-8296546: Add @spec tags to API In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Thu, 10 Nov 2022 11:30:51 GMT, Daniel Fuchs wrote: > Hi Jon, > > When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this: > > http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/URL.html > > External Specifications [Format for Literal IPv6 Addresses in URL's](https://www.ietf.org/rfc/rfc2732.html), [Uniform Resource Identifier (URI): Generic Syntax](https://www.ietf.org/rfc/rfc3986.html), [Uniform Resource Identifiers (URI): Generic Syntax](https://www.ietf.org/rfc/rfc2396.html) > > You will see that two of the RFC links have the same text but link to different RFCs, which I am finding confusing. Also I do hope it's clear that if a specification is referenced it doesn't mean it's being implemented. On keeping RFC in the title, I'll go with the team preference. I note that not all spec authorities have such a well-defined naming/numbering scheme, so it does make the summary page a bit inconsistent. Also, the entries under "R" dominate the list, which may not be what you want. On the same text but linking to different RFCs: that's tantamount to a bug somewhere. The spec for `@spec` dictates that the URLs and titles should be in 1-1 correspondence, and this is supposed to be enforced in the docket. In other words, specs should have unique titles, and any title should only be used for one spec. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From jjg at openjdk.org Thu Nov 10 22:03:32 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 10 Nov 2022 22:03:32 GMT Subject: RFR: JDK-8296546: Add @spec tags to API In-Reply-To: <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com> Message-ID: On Thu, 10 Nov 2022 11:45:39 GMT, Alan Bateman wrote: > > When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this: > > I agree and also to add that some RFCs have commas in their titles, the same separator used when there is more than one specification linked. Here's an example: > > http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/nio/channels/MulticastChannel.html I can change the doclet to use a bulleted list when any spec titles contain a comma. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From jjg at openjdk.org Thu Nov 10 22:11:30 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 10 Nov 2022 22:11:30 GMT Subject: RFR: JDK-8296546: Add @spec tags to API In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Thu, 10 Nov 2022 12:01:11 GMT, Alan Bateman wrote: > I'm trying to understand what "fix-ups" will be needed if the automated patch is applied. In some cases, it looks the same spec will be linked from "See also" and "External Specifications", e.g. http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/StandardSocketOptions.html#TCP_NODELAY so the `@see` ref can be dropped. > > In other cases we will have inline refs and the same URL in the `@spec`. This may be okay for the short term but maybe there is a way to inline `@spec` to avoid the duplication? > > There will probably be a bit of cleanup to reflow some lines, e.g. StandardSocketOptions.java, as excessively long lines are problematic for side-by-side diffs. The utility I mentioned has the (optional) ability to remove `@see` links when the text of the link exactly matches that used by the `@spec` tag. Unfortunately, the text is typically not exactly the same, and would require manual analysis to see if the `@see` tag can be removed. When inline references are used, the wording is very rarely the primary title of the spec: it is more likely to be a word or phrase that makes sense in the context of the enclosing sentence. _History: version 1 of this feature tried replacing inline links and `@see` tags with a bi-modal `@spec` tag. The results were "not good", especially in the generated external-specs page. Version 2 used a side file to provide the definitive title for each spec, but that was deemed to be too much of a maintenance issue. This is version 3, in which we've eliminated the side-file in favor of duplicating the title in each `@spec` tag._ ------------- PR: https://git.openjdk.org/jdk/pull/11073 From jjg at openjdk.org Thu Nov 10 22:19:26 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 10 Nov 2022 22:19:26 GMT Subject: RFR: 8296546: Add @spec tags to API In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Thu, 10 Nov 2022 16:33:09 GMT, AJ1062910 wrote: > did you changed 420 files ? I ran a custom utility that edited these files, yes. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From kizune at openjdk.org Thu Nov 10 22:45:41 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 10 Nov 2022 22:45:41 GMT Subject: Integrated: 8296496: Overzealous check in sizecalc.h prevents large memory allocation In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 22:04:55 GMT, Alexander Zuev wrote: > Removed the additional multiplication overflow detection. > Instead cast all the parameters to type_t just the way they are treated in the existing size check macro. > This way there is no possibility to accidentally provide parameters that will pass the size check macro while being cast to size_t there but then due to the missing cast cause the wrong size passed the actual allocation function. > Since this checking macro was used in couple of different places all of them needs to be updated in the similar way. This pull request has now been integrated. Changeset: 84e12244 Author: Alexander Zuev URL: https://git.openjdk.org/jdk/commit/84e12244a4ff82b3307a5ffe6fbe9dded7b08d86 Stats: 11 lines in 1 file changed: 0 ins; 4 del; 7 mod 8296496: Overzealous check in sizecalc.h prevents large memory allocation Reviewed-by: aivanov, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/11030 From serb at openjdk.org Thu Nov 10 23:08:32 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 10 Nov 2022 23:08:32 GMT Subject: RFR: 8295369: Update LCMS to 2.14 [v3] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 22:03:44 GMT, Alisen Chung wrote: >> Updating LCMS to newest release > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > updated UPDATING.txt contents src/java.desktop/share/native/liblcms/cmscgats.c line 2389: > 2387: > 2388: SetData(it8, i, idField, Buffer); > 2389: } Are these shifts caused by our script or that is the change in the upstream? ------------- PR: https://git.openjdk.org/jdk/pull/11000 From serb at openjdk.org Thu Nov 10 23:20:31 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 10 Nov 2022 23:20:31 GMT Subject: RFR: 8227257: javax/swing/JFileChooser/4847375/bug4847375.java fails with AssertionError In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 06:00:27 GMT, Tejesh R wrote: > Observation found when _JFileChooser_ is instantiated in _WindowsLookAndFeel_ which invokes _getSystemIcon()_ from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where _resolutionVariants_ map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing _getWidth()_. Fix is tested in CI system. I am pretty sure that the NPE reported recently in the comment in JBS is unrelated to the AssertionError reported initially. It is better to file separate issue. ------------- PR: https://git.openjdk.org/jdk/pull/11079 From prr at openjdk.org Thu Nov 10 23:30:29 2022 From: prr at openjdk.org (Phil Race) Date: Thu, 10 Nov 2022 23:30:29 GMT Subject: RFR: 8295369: Update LCMS to 2.14 [v3] In-Reply-To: References: Message-ID: <9DJxFsT8hx2Z-1cgnuIhnKhiWFMRS4tMAQCojhiBJ5s=.5917d184-c908-4874-9929-06da3a509e35@github.com> On Thu, 10 Nov 2022 22:58:54 GMT, Sergey Bylokhov wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> updated UPDATING.txt contents > > src/java.desktop/share/native/liblcms/cmscgats.c line 2389: > >> 2387: >> 2388: SetData(it8, i, idField, Buffer); >> 2389: } > > Are these shifts caused by our script or that is the change in the upstream? These look to me like tabs have not been replaced by spaces.. I saw a lot of "shifts" and I spot-checked some of them but they looked like ones where upstream had readily changed indentation. This does not look like that. ------------- PR: https://git.openjdk.org/jdk/pull/11000 From naoto at openjdk.org Thu Nov 10 23:55:34 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 10 Nov 2022 23:55:34 GMT Subject: RFR: 8296546: Add @spec tags to API In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com> On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote: > Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. > > To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. src/java.base/share/classes/java/lang/Character.java line 172: > 170: * occur. For example, in a future release, synchronization may fail. > 171: * > 172: * @spec https://www.unicode.org/reports/tr27 Unicode 3.1.0 This should probably be removed, as the original link (explaining `U+n` notation) is broken. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From honkar at openjdk.org Thu Nov 10 23:55:36 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 10 Nov 2022 23:55:36 GMT Subject: RFR: JDK-8295813: AWT_Mixing/ViewportOverlapping.java failing on Windows_11_Pro Message-ID: <8lLtmuOrcP6cmaHVBx91hxB8PDD7RO9irr5-BpyJEbk=.8edebaf4-ae38-463f-9809-d66016452198@github.com> ViewportOverlapping test was failing intermittently on Windows_11_Pro. The test has been updated to run at uiScale=1 to position the mouse clicks in the expected locations and the deprecated InputEvent.BUTTON1_MASK is replaced with BUTTON1_DOWN_MASK. ------------- Commit messages: - ViewPortOverlapping test fix Changes: https://git.openjdk.org/jdk/pull/11097/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11097&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295813 Stats: 29 lines in 1 file changed: 2 ins; 4 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/11097.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11097/head:pull/11097 PR: https://git.openjdk.org/jdk/pull/11097 From serb at openjdk.org Fri Nov 11 01:30:30 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 11 Nov 2022 01:30:30 GMT Subject: RFR: JDK-8295813: misc client tests failing on Windows_11_Pro In-Reply-To: <8lLtmuOrcP6cmaHVBx91hxB8PDD7RO9irr5-BpyJEbk=.8edebaf4-ae38-463f-9809-d66016452198@github.com> References: <8lLtmuOrcP6cmaHVBx91hxB8PDD7RO9irr5-BpyJEbk=.8edebaf4-ae38-463f-9809-d66016452198@github.com> Message-ID: On Thu, 10 Nov 2022 23:47:09 GMT, Harshitha Onkar wrote: > ViewportOverlapping test was failing intermittently on Windows_11_Pro. The test has been updated to run at uiScale=1 to position the mouse clicks at correct locations and the deprecated InputEvent.BUTTON1_MASK is replaced with BUTTON1_DOWN_MASK. What is changed in Windows 11 that the test fails on the HiDPI monitor? ------------- PR: https://git.openjdk.org/jdk/pull/11097 From serb at openjdk.org Fri Nov 11 01:53:34 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 11 Nov 2022 01:53:34 GMT Subject: RFR: 8296083: javax/swing/JTree/6263446/bug6263446.java fails intermittently on a VM In-Reply-To: References: Message-ID: <9pEe_oh21oEzVYLlhU8leo0kKtVfSD198SS7HfsSYRk=.2d875ce9-0b9b-40d0-9ae2-a07d17abb9a6@github.com> On Thu, 10 Nov 2022 06:38:19 GMT, Prasanta Sadhukhan wrote: >> test/jdk/javax/swing/JTree/6263446/bug6263446.java line 186: >> >>> 184: frame.setAlwaysOnTop(true); >>> 185: frame.setLocationRelativeTo(null); >>> 186: frame.pack(); >> >> pack() after the setLocationRelativeTo() may move the frame out of the center of the screen, is it intentional? > > it doesn't and I have checked Please recheck, setLocationRelativeTo() calculates the location based on the size of the current frame, which is wrong before the pack. I just run it and the frame is sifted to the right part of the screen. ------------- PR: https://git.openjdk.org/jdk/pull/11057 From serb at openjdk.org Fri Nov 11 02:00:37 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 11 Nov 2022 02:00:37 GMT Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and radio button with GTK LAF for bug4314194. [v2] In-Reply-To: References: Message-ID: On Wed, 19 Oct 2022 07:13:44 GMT, Abhishek Kumar wrote: >> Existing test `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` was not showing colored text for disabled checkbox and radiobutton in GTK LAF. >> >> The fix is to get the disabled state color for checkbox and radiobutton from UIManager if it exists. >> >> Test case `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` has been checked in CI pipeline. Link is attached in JBS. > > Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - ProblemList.txt file merge resolved > - 8295006 entry removed from problem lists > - Fix for disabled checkbox and radiobutton colored text Does anybody look into the regression in jdk20 reported above? The fork will be done soon, it is better to fix it early than later, if the fix is not known it is probably better to roll back some changes. Instead of fixing the product due to the test expectations, the test should be updated to use the correct properties for Nimbus and GTK. ------------- PR: https://git.openjdk.org/jdk/pull/10755 From serb at openjdk.org Fri Nov 11 02:02:15 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 11 Nov 2022 02:02:15 GMT Subject: RFR: 6201035: Document NPE for passing null insets to constructors and methods of several javax.swing.border.* classes [v7] In-Reply-To: <1ppO_1ffr_WXYasbkbI13Tov3Rj92-k4-nR_RDT7W2o=.1a0f6481-3ccf-43f2-af7d-a2160d622aeb@github.com> References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com> <1ppO_1ffr_WXYasbkbI13Tov3Rj92-k4-nR_RDT7W2o=.1a0f6481-3ccf-43f2-af7d-a2160d622aeb@github.com> Message-ID: On Thu, 3 Nov 2022 03:27:29 GMT, Prasanta Sadhukhan wrote: >> The behavior of MatteBorder constructors taking Insets object as a parameter is undocumented. It would throw NPE if null object is passed to it, which should be documented in the spec. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > AbstractBorder fix Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10740 From serb at openjdk.org Fri Nov 11 02:18:33 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 11 Nov 2022 02:18:33 GMT Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v4] In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 09:42:00 GMT, Artem Semenov wrote: >> A11Y implementation on macOS has to directly call the 'JList.setSelectedIndex' method in order to request selection on an item (see 'CAccessibility.requestSelection'). The reason is that a11y API lacks appropriate method.There's only 'javax.accessibility.AccessibleSelection#addAccessibleSelection' which is mapped to 'javax.swing.JList#addSelectionInterval', it can not be used to set selected index. >> >> @forantar @azuev-java @mrserb please review. >> >> Please note that the new API allows you to implement a multiple selection in lists from the Java side, but I did not succeed in implementing it, because I could not determine the inclusion of the so-called "VoiceOver multiple selection mode". > > Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: > > We are not using author tags in tests either - but that's just a nitpick. src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 574: > 572: return; > 573: } > 574: as.addAccessibleSelection(i); I would like to clarify one initial question. Why we cannot use `clearAccessibleSelection `to clean the current selection and then add a new one by the `addAccessibleSelection`? ------------- PR: https://git.openjdk.org/jdk/pull/8578 From psadhukhan at openjdk.org Fri Nov 11 04:03:33 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 11 Nov 2022 04:03:33 GMT Subject: RFR: 8296083: javax/swing/JTree/6263446/bug6263446.java fails intermittently on a VM In-Reply-To: <9pEe_oh21oEzVYLlhU8leo0kKtVfSD198SS7HfsSYRk=.2d875ce9-0b9b-40d0-9ae2-a07d17abb9a6@github.com> References: <9pEe_oh21oEzVYLlhU8leo0kKtVfSD198SS7HfsSYRk=.2d875ce9-0b9b-40d0-9ae2-a07d17abb9a6@github.com> Message-ID: On Fri, 11 Nov 2022 01:45:30 GMT, Sergey Bylokhov wrote: >> it doesn't and I have checked > > Please recheck, setLocationRelativeTo() calculates the location based on the size of the current frame, which is wrong before the pack. I just run it and the frame is sifted to the right part of the screen. WHich platform it is shifted? ------------- PR: https://git.openjdk.org/jdk/pull/11057 From tr at openjdk.org Fri Nov 11 04:05:47 2022 From: tr at openjdk.org (Tejesh R) Date: Fri, 11 Nov 2022 04:05:47 GMT Subject: RFR: 8227257: javax/swing/JFileChooser/4847375/bug4847375.java fails with AssertionError In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 23:18:30 GMT, Sergey Bylokhov wrote: > I am pretty sure that the NPE reported recently in the comment in JBS is unrelated to the AssertionError reported initially. It is better to file separate issue. There is a separate JBS for the NPE issue also, since the recent observations were linked to that I thought it be better as a defensive fix for this too. ------------- PR: https://git.openjdk.org/jdk/pull/11079 From psadhukhan at openjdk.org Fri Nov 11 04:08:32 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 11 Nov 2022 04:08:32 GMT Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and radio button with GTK LAF for bug4314194. [v2] In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 01:56:44 GMT, Sergey Bylokhov wrote: > Instead of fixing the product due to the test expectations, the test should be updated to use the correct properties for Nimbus and GTK. If you believe it's test issue, can you please raise a PR updating the test to what it should have using the "correct properties"? We can then roll back the product changes if need be.. ------------- PR: https://git.openjdk.org/jdk/pull/10755 From cjplummer at openjdk.org Fri Nov 11 04:18:30 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 11 Nov 2022 04:18:30 GMT Subject: RFR: 8296546: Add @spec tags to API In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote: > Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. > > To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. src/jdk.jdi/share/classes/com/sun/jdi/connect/spi/Connection.java line 105: > 103: * If the length of the packet (as indictaed by the first > 104: * 4 bytes) is less than 11 bytes, or an I/O error occurs. > 105: * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol http://cr.openjdk.java.net/~jjg/8296546/api.00/jdk.jdi/com/sun/jdi/connect/spi/Connection.html#readPacket() Within this javadoc page the jdwp-spec.html references are titled "JDWP Specification", but these `@spec` references are titled "Java Debug Wire Protocol". I suggest making them more consistent. There is one more case below and this same issue also applies to TransportService.java. Perhaps the title in jdwp-spec.html should be updated. I think "Java Debug Wire Protocol (JDWP) Specification" would be good. src/jdk.jdi/share/classes/com/sun/jdi/connect/spi/TransportService.java line 79: > 77: * target VM. > 78: * > 79: * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol See above comment for Connection.java. src/jdk.jdi/share/classes/module-info.java line 107: > 105: * > 106: * > 107: * @spec jpda/jpda.html Java Platform Debugger Architecture http://cr.openjdk.java.net/~jjg/8296546/api.00/jdk.jdi/module-summary.html `@spec` and `@see` sections end up one right after the other with the same content, except the `@see` section has the preferred hyperlink title. Suggest you remove the `@see` section and also update `@spec` hyperlink title to include "(JPDA)", or update the actual title in the jpda.html doc so it includes "(JPDA)" in it and then rerun your tool. src/jdk.jdwp.agent/share/classes/module-info.java line 30: > 28: * > 29: * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol > 30: * @spec jdwp/jdwp-transport.html Java Debug Wire Protocol Transport Interface (jdwpTransport) http://cr.openjdk.java.net/~jjg/8296546/api.00/jdk.jdwp.agent/module-summary.html The end result here is not very clean. You have the same two specs being referred to just a few lines apart, and the hyperlink titles are not even close to be the same, even though the links are the same. Maybe the "@see" section should be removed. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From abhiscxk at openjdk.org Fri Nov 11 05:25:45 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 11 Nov 2022 05:25:45 GMT Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and radio button with GTK LAF for bug4314194. [v3] In-Reply-To: References: Message-ID: > Existing test `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` was not showing colored text for disabled checkbox and radiobutton in GTK LAF. > > The fix is to get the disabled state color for checkbox and radiobutton from UIManager if it exists. > > Test case `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` has been checked in CI pipeline. Link is attached in JBS. Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge - Merge - ProblemList.txt file merge resolved - 8295006 entry removed from problem lists - Fix for disabled checkbox and radiobutton colored text ------------- Changes: https://git.openjdk.org/jdk/pull/10755/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10755&range=02 Stats: 13 lines in 2 files changed: 12 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10755.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10755/head:pull/10755 PR: https://git.openjdk.org/jdk/pull/10755 From mvs at openjdk.org Fri Nov 11 06:43:35 2022 From: mvs at openjdk.org (Manukumar V S) Date: Fri, 11 Nov 2022 06:43:35 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem. [v3] In-Reply-To: References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> Message-ID: On Thu, 10 Nov 2022 05:14:36 GMT, Naveen Narayanan wrote: >> This testcase will >> 1) Verify setAccelerator method of JMenuitem. >> 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M. >> >> Testing: >> Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. > > Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: > > 8296275: Review comments fixed. Marked as reviewed by mvs (Author). ------------- PR: https://git.openjdk.org/jdk/pull/11035 From duke at openjdk.org Fri Nov 11 08:20:55 2022 From: duke at openjdk.org (ravi gupta) Date: Fri, 11 Nov 2022 08:20:55 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. [v4] In-Reply-To: References: Message-ID: > This testcase Verify the content changes of a TextArea for the following assertions. > > a. TextListener get invoked when the content of a TextArea gets changed. > b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. > > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. ravi gupta has updated the pull request incrementally with one additional commit since the last revision: 8296632: Review fixes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11052/files - new: https://git.openjdk.org/jdk/pull/11052/files/c5c93e82..3106d5bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11052&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11052&range=02-03 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11052.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11052/head:pull/11052 PR: https://git.openjdk.org/jdk/pull/11052 From tr at openjdk.org Fri Nov 11 08:22:40 2022 From: tr at openjdk.org (Tejesh R) Date: Fri, 11 Nov 2022 08:22:40 GMT Subject: RFR: 8227257: javax/swing/JFileChooser/4847375/bug4847375.java fails with AssertionError In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 06:00:27 GMT, Tejesh R wrote: > Observation found when _JFileChooser_ is instantiated in _WindowsLookAndFeel_ which invokes _getSystemIcon()_ from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where _resolutionVariants_ map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing _getWidth()_. Fix is tested in CI system. Created separate PR which has the exact observation for a bug - [JDK-8293862] (https://bugs.openjdk.org/browse/JDK-8293862). Closing this PR. ------------- PR: https://git.openjdk.org/jdk/pull/11079 From lucy at openjdk.org Fri Nov 11 08:22:43 2022 From: lucy at openjdk.org (Lutz Schmidt) Date: Fri, 11 Nov 2022 08:22:43 GMT Subject: RFR: 8295779: Xcode 14.0 fails to build jdk on m1 macos In-Reply-To: References: Message-ID: On Wed, 19 Oct 2022 15:33:31 GMT, Archie L. Cobbs wrote: > Building on MacOS 12.6 M1 with Xcode 14.0 fails due to C compiler unused parameter warnings: > > Creating support/modules_libs/java.desktop/libosx.dylib from 1 file(s) This is a moving target, and the changes depend on the build mode as well as on the Xcode version + subversion. My company forced me on Xcode 14.1 lately. That triggered "deprecated-declarations" warnings in adlc (1x), hotspot (20x), and java.desktop (1x). These are all caused by the use of sprint(). The next Xcode subversion will for sure find other code snippets to complain about. I'm not sure which policy to follow here. Adapt the make file (will hide the warning "forever")? Change the source code (and potentially introduce new issues)? Any advice from the build gurus? ------------- PR: https://git.openjdk.org/jdk/pull/10768 From tr at openjdk.org Fri Nov 11 08:22:40 2022 From: tr at openjdk.org (Tejesh R) Date: Fri, 11 Nov 2022 08:22:40 GMT Subject: Withdrawn: 8227257: javax/swing/JFileChooser/4847375/bug4847375.java fails with AssertionError In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 06:00:27 GMT, Tejesh R wrote: > Observation found when _JFileChooser_ is instantiated in _WindowsLookAndFeel_ which invokes _getSystemIcon()_ from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where _resolutionVariants_ map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing _getWidth()_. Fix is tested in CI system. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/11079 From tr at openjdk.org Fri Nov 11 08:26:35 2022 From: tr at openjdk.org (Tejesh R) Date: Fri, 11 Nov 2022 08:26:35 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' Message-ID: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com> Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system. ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/11104/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11104&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293862 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11104.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11104/head:pull/11104 PR: https://git.openjdk.org/jdk/pull/11104 From asemenov at openjdk.org Fri Nov 11 09:14:32 2022 From: asemenov at openjdk.org (Artem Semenov) Date: Fri, 11 Nov 2022 09:14:32 GMT Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v4] In-Reply-To: References: Message-ID: <6HPa6vPeV5haQI_Ifs5IRH1xcjiqbld0T2Fk_WIABAY=.c0c2f8ff-988e-4017-8e61-a365870d5e6b@github.com> On Fri, 11 Nov 2022 02:16:15 GMT, Sergey Bylokhov wrote: >> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: >> >> We are not using author tags in tests either - but that's just a nitpick. > > src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 574: > >> 572: return; >> 573: } >> 574: as.addAccessibleSelection(i); > > I would like to clarify one initial question. Why we cannot use `clearAccessibleSelection `to clean the current selection and then add a new one by the `addAccessibleSelection`? We tried to do this, it leads to an endless repetition of the selected line until it freezes. ------------- PR: https://git.openjdk.org/jdk/pull/8578 From mvs at openjdk.org Fri Nov 11 10:13:30 2022 From: mvs at openjdk.org (Manukumar V S) Date: Fri, 11 Nov 2022 10:13:30 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. [v4] In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 08:20:55 GMT, ravi gupta wrote: >> This testcase Verify the content changes of a TextArea for the following assertions. >> >> a. TextListener get invoked when the content of a TextArea gets changed. >> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8296632: Review fixes. Marked as reviewed by mvs (Author). ------------- PR: https://git.openjdk.org/jdk/pull/11052 From dfuchs at openjdk.org Fri Nov 11 10:29:33 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 11 Nov 2022 10:29:33 GMT Subject: RFR: 8296546: Add @spec tags to API In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Thu, 10 Nov 2022 21:56:26 GMT, Jonathan Gibbons wrote: > On the same text but linking to different RFCs: that's tantamount to a bug somewhere. The spec for `@spec` dictates that the URLs and titles should be in 1-1 correspondence, and this is supposed to be enforced in the docket. In other words, specs should have unique titles, and any title should only be used for one spec. It's not uncommon for a newer version of a RFC to change its number but keep its title. I see that the links in the class level API documentation both have the RFC number in their link text. Somehow that was stripped by your tool - possibly because it tried to extract some meta information from the linked page itself? ------------- PR: https://git.openjdk.org/jdk/pull/11073 From lancea at openjdk.org Fri Nov 11 11:49:32 2022 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 11 Nov 2022 11:49:32 GMT Subject: RFR: 8296546: Add @spec tags to API In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote: > Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. > > To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. Hi Jon, I only looked at the jar specific updates but there is some duplication leftovers. It would probably be easier for the reviewers and for you if the PR could be broken out by areas into separate PRs src/java.base/share/classes/java/util/jar/Attributes.java line 58: > 56: * order that keys were inserted into the map, as with {@link LinkedHashMap}. > 57: * > 58: * @spec jar/jar.html JAR File Specification Line 52 should be removed src/java.base/share/classes/java/util/jar/Attributes.java line 450: > 448: * JAR File Specification > 449: * for more information about valid attribute names and values. > 450: * @spec jar/jar.html JAR File Specification Line 448 should be removed src/java.base/share/classes/java/util/jar/Manifest.java line 47: > 45: * Manifest format specification. > 46: * > 47: * @spec jar/jar.html JAR File Specification Line 44 should be removed src/java.base/share/classes/java/util/jar/package-info.java line 47: > 45: * > 46: * > 47: * @spec jar/jar.html JAR File Specification Line 43 should be removed src/java.base/share/classes/java/util/zip/package-info.java line 75: > 73: * > 74: * > 75: * @spec https://www.ietf.org/rfc/rfc1951.html DEFLATE Compressed Data Format Specification version 1.3 The above references should be removed as they duplicate the` @spec` tags ------------- Changes requested by lancea (Reviewer). PR: https://git.openjdk.org/jdk/pull/11073 From dfuchs at openjdk.org Fri Nov 11 12:01:42 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 11 Nov 2022 12:01:42 GMT Subject: RFR: 8296546: Add @spec tags to API In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Fri, 11 Nov 2022 11:45:43 GMT, Lance Andersen wrote: > It would probably be easier for the reviewers and for you if the PR could be broken out by areas into separate PRs Leaving out the non-public and non-exported classes would also reduce the PR size. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From duke at openjdk.org Fri Nov 11 16:52:29 2022 From: duke at openjdk.org (lawrence.andrews) Date: Fri, 11 Nov 2022 16:52:29 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. [v4] In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 08:20:55 GMT, ravi gupta wrote: >> This testcase Verify the content changes of a TextArea for the following assertions. >> >> a. TextListener get invoked when the content of a TextArea gets changed. >> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8296632: Review fixes. test/jdk/java/awt/event/ComponentEvent/TextAreaTextEventTest.java line 2: > 1: /* > 2: * Copyright (c) 2007, 2022, Oracle and/or its affiliates. All rights reserved. Since this is a new test we dn't need 2007. ------------- PR: https://git.openjdk.org/jdk/pull/11052 From serb at openjdk.org Fri Nov 11 21:36:27 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 11 Nov 2022 21:36:27 GMT Subject: RFR: 8296083: javax/swing/JTree/6263446/bug6263446.java fails intermittently on a VM In-Reply-To: References: <9pEe_oh21oEzVYLlhU8leo0kKtVfSD198SS7HfsSYRk=.2d875ce9-0b9b-40d0-9ae2-a07d17abb9a6@github.com> Message-ID: On Fri, 11 Nov 2022 04:01:17 GMT, Prasanta Sadhukhan wrote: >> Please recheck, setLocationRelativeTo() calculates the location based on the size of the current frame, which is wrong before the pack. I just run it and the frame is sifted to the right part of the screen. > > WHich platform it is shifted? I guess on any, I have tested on windows, and now on macOS. Add these lines to the end of method, and check how the frame will jump to the center: frame.setLocationRelativeTo(null); frame.pack(); frame.setVisible(true); + robot.delay(3000); + frame.dispose(); + frame.pack(); + frame.setLocationRelativeTo(null); + frame.setVisible(true); ------------- PR: https://git.openjdk.org/jdk/pull/11057 From serb at openjdk.org Fri Nov 11 21:44:37 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 11 Nov 2022 21:44:37 GMT Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v4] In-Reply-To: <6HPa6vPeV5haQI_Ifs5IRH1xcjiqbld0T2Fk_WIABAY=.c0c2f8ff-988e-4017-8e61-a365870d5e6b@github.com> References: <6HPa6vPeV5haQI_Ifs5IRH1xcjiqbld0T2Fk_WIABAY=.c0c2f8ff-988e-4017-8e61-a365870d5e6b@github.com> Message-ID: On Fri, 11 Nov 2022 09:12:21 GMT, Artem Semenov wrote: >> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 574: >> >>> 572: return; >>> 573: } >>> 574: as.addAccessibleSelection(i); >> >> I would like to clarify one initial question. Why we cannot use `clearAccessibleSelection `to clean the current selection and then add a new one by the `addAccessibleSelection`? > > We tried to do this, it leads to an endless repetition of the selected line until it freezes. Probably because of the endless notifications loop? implementation of addSelectionInterval looks similar to setSelectionInterval. In some cases the addSelectionInterval just call setSelectionInterval. ------------- PR: https://git.openjdk.org/jdk/pull/8578 From serb at openjdk.org Sat Nov 12 06:20:03 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 12 Nov 2022 06:20:03 GMT Subject: RFR: 8296905: Replace the native LCMS#getProfileID() method with the accessor Message-ID: The native method used to access the private method in the `ICC_Profile` class is replaced by the accessor. ------------- Commit messages: - 8296905: Replace the native LCMS#getProfileID() method with the accessor Changes: https://git.openjdk.org/jdk/pull/11116/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11116&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296905 Stats: 77 lines in 5 files changed: 38 ins; 36 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11116.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11116/head:pull/11116 PR: https://git.openjdk.org/jdk/pull/11116 From aturbanov at openjdk.org Sat Nov 12 09:21:13 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Sat, 12 Nov 2022 09:21:13 GMT Subject: RFR: 8296905: Replace the native LCMS#getProfileID() method with the accessor In-Reply-To: References: Message-ID: <7jMOilsUHip2idGzJGSiNEMCB4EwssM8mDmxdbAcEZw=.a71cb407-f6ab-420a-af29-6df49f8a7099@github.com> On Sat, 12 Nov 2022 04:13:52 GMT, Sergey Bylokhov wrote: > The native method used to access the private method in the `ICC_Profile` class is replaced by the accessor. src/java.desktop/share/classes/sun/awt/AWTAccessor.java line 891: > 889: */ > 890: public static ICC_ProfileAccessor getICC_ProfileAccessor() { > 891: if (iccProfileAccessor == null) { For `SharedSecrets` in java.base code was updated to use single read (to avoid concurrency problems) - see [JDK-8259021](https://bugs.openjdk.org/browse/JDK-8259021) Shouldn't we use the same patter here? ------------- PR: https://git.openjdk.org/jdk/pull/11116 From prr at openjdk.org Sat Nov 12 20:37:45 2022 From: prr at openjdk.org (Phil Race) Date: Sat, 12 Nov 2022 20:37:45 GMT Subject: RFR: 8286624: Regression Test CoordinateTruncationBug.java fails on OL8.3 Message-ID: This was a closed test - simply because it hadn't been reviewed for moving to open so I am doing it now whilst fixing a problem that was observed on the OL 8.x (and by implication an RHEL 8.x) desktop due to the screen menu bar rendering over one line of the undecorated window. That was fixed by changing the location to use setLocationRelativeTo(null) vs the previous implied (0,0) ------------- Commit messages: - 8286624 Changes: https://git.openjdk.org/jdk/pull/11120/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11120&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8286624 Stats: 271 lines in 1 file changed: 271 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11120.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11120/head:pull/11120 PR: https://git.openjdk.org/jdk/pull/11120 From xuelei at openjdk.org Sun Nov 13 06:39:00 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Sun, 13 Nov 2022 06:39:00 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 Message-ID: Hi, May I have this update reviewed? The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. Thanks, Xuelei ------------- Commit messages: - use const size_t - size correction - size correction - 8296812: sprintf is deprecated in Xcode 14 Changes: https://git.openjdk.org/jdk/pull/11115/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296812 Stats: 109 lines in 24 files changed: 15 ins; 3 del; 91 mod Patch: https://git.openjdk.org/jdk/pull/11115.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11115/head:pull/11115 PR: https://git.openjdk.org/jdk/pull/11115 From stuefe at openjdk.org Sun Nov 13 07:54:34 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 13 Nov 2022 07:54:34 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 22:41:19 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. > > Thanks, > Xuelei Hi @XueleiFan, could you use `jio_snprintf` instead (see include/jvm_io.h)? That is what we usually do for snprintf. jio_snprintf hides platform particularities wrt snprintf. Cheers, Thomas ------------- PR: https://git.openjdk.org/jdk/pull/11115 From xuelei at openjdk.org Sun Nov 13 08:28:37 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Sun, 13 Nov 2022 08:28:37 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 In-Reply-To: References: Message-ID: On Sun, 13 Nov 2022 07:50:43 GMT, Thomas Stuefe wrote: > could you use `jio_snprintf` instead (see include/jvm_io.h)? That is what we usually do for snprintf. jio_snprintf hides platform particularities wrt snprintf. > Good to know that. Thank you! While I was doing the replacement from `snprintf` to `jio_snprintf`, I noticed a lot of existing use of `snprintf` in the files touched in this PR. What do you think if we have a `snprintf` clean up in a followed PR? hotspot $ find . -type f |xargs grep snprintf |grep -v jio_snprintf |wc 262 1895 26574 ------------- PR: https://git.openjdk.org/jdk/pull/11115 From stuefe at openjdk.org Sun Nov 13 09:01:31 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 13 Nov 2022 09:01:31 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 In-Reply-To: References: Message-ID: On Sun, 13 Nov 2022 08:25:57 GMT, Xue-Lei Andrew Fan wrote: > > could you use `jio_snprintf` instead (see include/jvm_io.h)? That is what we usually do for snprintf. jio_snprintf hides platform particularities wrt snprintf. > > Good to know that. Thank you! > > While I was doing the replacement from `snprintf` to `jio_snprintf`, I noticed a lot of existing use of `snprintf` in the files touched in this PR. What do you think if we have a `snprintf` clean up in a followed PR? > > ``` > hotspot $ find . -type f |xargs grep snprintf |grep -v jio_snprintf |wc > 262 1895 26574 > ``` Hmm, possibly. We may look again at the exact reason why we use jio_snprintf. Maybe it is less important nowadays, with reduced platform number (no solaris) and Windows being more standard conform than it had been in the past. Lets hear what others think. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From kbarrett at openjdk.org Sun Nov 13 20:50:24 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 13 Nov 2022 20:50:24 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 22:41:19 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. > > Thanks, > Xuelei Please don't add uses of `jio_snprintf` or `::snprintf` to hotspot. Use `os::snprintf`. Regarding `jio_snprintf`, see https://bugs.openjdk.org/browse/JDK-8198918. Regarding `os::snprintf` and `os::vsnprintf`, see https://bugs.openjdk.org/browse/JDK-8285506. I think the only reason we haven't marked `::sprintf` and `::snprintf` forbidden (FORBID_C_FUNCTION) is there are a lot of uses, and nobody has gotten around to dealing with it. `::snprintf` in the list of candidates for https://bugs.openjdk.org/browse/JDK-8214976, some of which have already been marked. But I don't see new bugs for the as-yet unmarked ones. As a general note, as a reviewer my preference is against non-trivial and persnickety code changes that are scattered all over the code base. For something like this I'd prefer multiple more bite-sized changes that were dealing with specific uses. I doubt everyone agrees with me though. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From xuelei at openjdk.org Sun Nov 13 22:55:30 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Sun, 13 Nov 2022 22:55:30 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v2] In-Reply-To: References: Message-ID: > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with two additional commits since the last revision: - use os::snprintf for desktop update - use os::snprintf ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11115/files - new: https://git.openjdk.org/jdk/pull/11115/files/e4724c5f..a66f58bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=00-01 Stats: 41 lines in 18 files changed: 0 ins; 0 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/11115.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11115/head:pull/11115 PR: https://git.openjdk.org/jdk/pull/11115 From xuelei at openjdk.org Sun Nov 13 22:58:24 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Sun, 13 Nov 2022 22:58:24 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 In-Reply-To: References: Message-ID: <-ER02i5fNCaZX-v56giR7gCbuMkwwpdhg5LBLThVvds=.402ad601-58e3-4529-935a-151e5e76b2b3@github.com> On Sun, 13 Nov 2022 20:48:04 GMT, Kim Barrett wrote: > Please don't add uses of `jio_snprintf` or `::snprintf` to hotspot. Use `os::snprintf`. Updated to use os::snprintf, except the files under adlc where the os::snptintf definition is not included. The use of snprintf could be cleaned up with existing code in the future. > > Regarding `jio_snprintf`, see https://bugs.openjdk.org/browse/JDK-8198918. Regarding `os::snprintf` and `os::vsnprintf`, see https://bugs.openjdk.org/browse/JDK-8285506. > > I think the only reason we haven't marked `::sprintf` and `::snprintf` forbidden (FORBID_C_FUNCTION) is there are a lot of uses, and nobody has gotten around to dealing with it. `::snprintf` in the list of candidates for https://bugs.openjdk.org/browse/JDK-8214976, some of which have already been marked. But I don't see new bugs for the as-yet unmarked ones. > > As a general note, as a reviewer my preference is against non-trivial and persnickety code changes that are scattered all over the code base. For something like this I'd prefer multiple more bite-sized changes that were dealing with specific uses. I doubt everyone agrees with me though. It makes sense to me. I'd better focus on the building issue in this PR. Thank you for the review! ------------- PR: https://git.openjdk.org/jdk/pull/11115 From azvegint at openjdk.org Mon Nov 14 00:18:02 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 14 Nov 2022 00:18:02 GMT Subject: RFR: 8157173: [macosx] java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java fails Message-ID: This test currently passing as it is on all platforms, but it was problemlisted with ["Problem List some tests that leave windows open on the desktop" reason](https://github.com/openjdk/jdk/commit/fd8df3adf13f5df8f5f95482b8e0a70bc519f39f) So this test is cleaned up and stabilized. CI testing looks good. ------------- Commit messages: - initial Changes: https://git.openjdk.org/jdk/pull/11128/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11128&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8157173 Stats: 170 lines in 2 files changed: 52 ins; 45 del; 73 mod Patch: https://git.openjdk.org/jdk/pull/11128.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11128/head:pull/11128 PR: https://git.openjdk.org/jdk/pull/11128 From azvegint at openjdk.org Mon Nov 14 00:23:07 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 14 Nov 2022 00:23:07 GMT Subject: RFR: 8193547: Regression automated test '/open/test/jdk/java/awt/Toolkit/DesktopProperties/rfe4758438.java' fails Message-ID: This test has multiple issues: * Test actually does nothing and passes as it is right now, but tests nothing * `pgrep gnome-session` may return multiple PIDs -> picking up only first one * looks like jtreg does not pass GNOME_DESKTOP_SESSION_ID variable(it is deprecated, BTW), so used `XDG_CURRENT_DESKTOP` instead * removed leftovers from Solaris support * `org.gnome.settings-daemon.peripherals.mouse` is [deprecated](https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/blob/master/data/org.gnome.settings-daemon.peripherals.gschema.xml.in#L46) and does not work on latest systems
but newer `org.gnome.desktop.peripherals.mouse` works as expected
So the test modified to try new one and to check deprecated as a fallback CI testing looks good. ------------- Commit messages: - fix access rights - initial Changes: https://git.openjdk.org/jdk/pull/11127/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11127&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8193547 Stats: 125 lines in 3 files changed: 72 ins; 22 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/11127.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11127/head:pull/11127 PR: https://git.openjdk.org/jdk/pull/11127 From azvegint at openjdk.org Mon Nov 14 00:32:46 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 14 Nov 2022 00:32:46 GMT Subject: RFR: 8164464: Consistent failure of java/awt/dnd/MissingEventsOnModalDialog/MissingEventsOnModalDialogTest.java Message-ID: This is an old issue, which is no longer reproducible. The test is slightly stabilized for slow machines. CI testing looks good. ------------- Commit messages: - initial Changes: https://git.openjdk.org/jdk/pull/11129/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11129&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8164464 Stats: 24 lines in 2 files changed: 7 ins; 10 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/11129.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11129/head:pull/11129 PR: https://git.openjdk.org/jdk/pull/11129 From azvegint at openjdk.org Mon Nov 14 01:26:25 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 14 Nov 2022 01:26:25 GMT Subject: RFR: 8286624: Regression Test CoordinateTruncationBug.java fails on OL8.3 In-Reply-To: References: Message-ID: On Sat, 12 Nov 2022 20:29:39 GMT, Phil Race wrote: > This was a closed test - simply because it hadn't been reviewed for moving to open > so I am doing it now whilst fixing a problem that was observed on the OL 8.x (and > by implication an RHEL 8.x) desktop due to the screen menu bar rendering over one > line of the undecorated window. > That was fixed by changing the location to use setLocationRelativeTo(null) vs > the previous implied (0,0) Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11120 From dholmes at openjdk.org Mon Nov 14 01:57:23 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 14 Nov 2022 01:57:23 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v2] In-Reply-To: References: Message-ID: On Sun, 13 Nov 2022 22:55:30 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> May I have this update reviewed? >> >> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with two additional commits since the last revision: > > - use os::snprintf for desktop update > - use os::snprintf The hotspot changes seem okay using os::snprint. The adlc changes to use raw snprintf also seem okay for now - I'm not sure whether the platform differences for snprintf affect adlc. The desktop change is wrong - you can't use os::snprintf there. Thanks. src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp line 638: > 636: return; > 637: } > 638: os::snprintf(channelName, 16, "Ch %d", ch); You can't use this here - this is not hotspot code! ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11115 From xuelei at openjdk.org Mon Nov 14 03:27:05 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 14 Nov 2022 03:27:05 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v3] In-Reply-To: References: Message-ID: > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: revert update for desktop ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11115/files - new: https://git.openjdk.org/jdk/pull/11115/files/a66f58bf..fe6893d5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11115.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11115/head:pull/11115 PR: https://git.openjdk.org/jdk/pull/11115 From xuelei at openjdk.org Mon Nov 14 03:27:09 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 14 Nov 2022 03:27:09 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v2] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 01:51:32 GMT, David Holmes wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with two additional commits since the last revision: >> >> - use os::snprintf for desktop update >> - use os::snprintf > > src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp line 638: > >> 636: return; >> 637: } >> 638: os::snprintf(channelName, 16, "Ch %d", ch); > > You can't use this here - this is not hotspot code! You are right. Reverted to use `snprintf` for desktop update. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11115 From xuelei at openjdk.org Mon Nov 14 03:46:37 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 14 Nov 2022 03:46:37 GMT Subject: Withdrawn: 8296812: sprintf is deprecated in Xcode 14 In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 22:41:19 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. > > Thanks, > Xuelei This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From jdv at openjdk.org Mon Nov 14 04:00:28 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 14 Nov 2022 04:00:28 GMT Subject: RFR: 8164464: Consistent failure of java/awt/dnd/MissingEventsOnModalDialog/MissingEventsOnModalDialogTest.java In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 00:23:09 GMT, Alexander Zvegintsev wrote: > This is an old issue, which is no longer reproducible. > The test is slightly stabilized for slow machines. > > CI testing looks good. Marked as reviewed by jdv (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11129 From jdv at openjdk.org Mon Nov 14 04:08:21 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 14 Nov 2022 04:08:21 GMT Subject: RFR: 8157173: [macosx] java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java fails In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 00:12:00 GMT, Alexander Zvegintsev wrote: > This test currently passing as it is on all platforms, but it was problemlisted with ["Problem List some tests that leave windows open on the desktop" reason](https://github.com/openjdk/jdk/commit/fd8df3adf13f5df8f5f95482b8e0a70bc519f39f) > > So this test is cleaned up and stabilized. > > CI testing looks good. Marked as reviewed by jdv (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11128 From jdv at openjdk.org Mon Nov 14 04:53:30 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 14 Nov 2022 04:53:30 GMT Subject: RFR: 8296083: javax/swing/JTree/6263446/bug6263446.java fails intermittently on a VM In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 10:37:24 GMT, Prasanta Sadhukhan wrote: > Test intermittently fails in VM citing "Tree is not editing". Seems to be problem with mouse clicks not getting registered properly.. > Similar test test/jdk/javax/swing/JTable/6263446/bug6263446.java is not affected, so made the test similar to it by using same safeguard using Robot.waitForIdle() and modifying clickpoint to tree cell midpoint. > > Several iterations of the test pass in the OCI VM and all other physical platforms (link in JBS) test/jdk/javax/swing/JTree/6263446/bug6263446.java line 41: > 39: public class bug6263446 { > 40: > 41: private static final String FIRST = "AAAAA"; any particular reason for decreasing length of string? ------------- PR: https://git.openjdk.org/jdk/pull/11057 From abhiscxk at openjdk.org Mon Nov 14 04:53:50 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 14 Nov 2022 04:53:50 GMT Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and radio button with GTK LAF for bug4314194. [v4] In-Reply-To: References: Message-ID: > Existing test `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` was not showing colored text for disabled checkbox and radiobutton in GTK LAF. > > The fix is to get the disabled state color for checkbox and radiobutton from UIManager if it exists. > > Test case `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` has been checked in CI pipeline. Link is attached in JBS. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Used bitwise operator for condition check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10755/files - new: https://git.openjdk.org/jdk/pull/10755/files/3b5cb484..81dc7768 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10755&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10755&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10755.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10755/head:pull/10755 PR: https://git.openjdk.org/jdk/pull/10755 From abhiscxk at openjdk.org Mon Nov 14 04:53:53 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 14 Nov 2022 04:53:53 GMT Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and radio button with GTK LAF for bug4314194. [v2] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 21:43:01 GMT, Phil Race wrote: >> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - ProblemList.txt file merge resolved >> - 8295006 entry removed from problem lists >> - Fix for disabled checkbox and radiobutton colored text > > "test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java has been checked" > > I hope you ran ALL Swing tests .. not just this single one .. ?? @prrace Just a minor change in condition check. Updated to bitwise operator to check if component is disabled as it has been done for other widget. CI testing looks fine. ------------- PR: https://git.openjdk.org/jdk/pull/10755 From duke at openjdk.org Mon Nov 14 05:12:28 2022 From: duke at openjdk.org (ravi gupta) Date: Mon, 14 Nov 2022 05:12:28 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. [v4] In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 16:48:45 GMT, lawrence.andrews wrote: >> ravi gupta has updated the pull request incrementally with one additional commit since the last revision: >> >> 8296632: Review fixes. > > test/jdk/java/awt/event/ComponentEvent/TextAreaTextEventTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2007, 2022, Oracle and/or its affiliates. All rights reserved. > > Since this is a new test we dn't need 2007. I have added the original date based on the above comment that?s we get during the PR review below https://github.com/openjdk/jdk/pull/7512#issuecomment-1075171066 ------------- PR: https://git.openjdk.org/jdk/pull/11052 From xuelei at openjdk.org Mon Nov 14 05:32:20 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 14 Nov 2022 05:32:20 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v4] In-Reply-To: References: Message-ID: > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: include missing os head file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11115/files - new: https://git.openjdk.org/jdk/pull/11115/files/fe6893d5..128bc806 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11115.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11115/head:pull/11115 PR: https://git.openjdk.org/jdk/pull/11115 From psadhukhan at openjdk.org Mon Nov 14 06:56:20 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 14 Nov 2022 06:56:20 GMT Subject: RFR: 8296083: javax/swing/JTree/6263446/bug6263446.java fails intermittently on a VM [v2] In-Reply-To: References: Message-ID: > Test intermittently fails in VM citing "Tree is not editing". Seems to be problem with mouse clicks not getting registered properly.. > Similar test test/jdk/javax/swing/JTable/6263446/bug6263446.java is not affected, so made the test similar to it by using same safeguard using Robot.waitForIdle() and modifying clickpoint to tree cell midpoint. > > Several iterations of the test pass in the OCI VM and all other physical platforms (link in JBS) Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Test update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11057/files - new: https://git.openjdk.org/jdk/pull/11057/files/6a00a87c..a1ae319b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11057&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11057&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11057.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11057/head:pull/11057 PR: https://git.openjdk.org/jdk/pull/11057 From psadhukhan at openjdk.org Mon Nov 14 06:56:21 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 14 Nov 2022 06:56:21 GMT Subject: RFR: 8296083: javax/swing/JTree/6263446/bug6263446.java fails intermittently on a VM [v2] In-Reply-To: References: <9pEe_oh21oEzVYLlhU8leo0kKtVfSD198SS7HfsSYRk=.2d875ce9-0b9b-40d0-9ae2-a07d17abb9a6@github.com> Message-ID: On Fri, 11 Nov 2022 21:32:42 GMT, Sergey Bylokhov wrote: >> WHich platform it is shifted? > > I guess on any, I have tested on windows, and now on macOS. Add these lines to the end of method, and check how the frame will jump to the center: > > frame.setLocationRelativeTo(null); > frame.pack(); > frame.setVisible(true); > + robot.delay(3000); > + frame.dispose(); > + frame.pack(); > + frame.setLocationRelativeTo(null); > + frame.setVisible(true); OK. Test updated (although I dont think it would have mattered in this specific case for such a small JTree widget as can be seen from my testing CI jobs in all platforms).. ------------- PR: https://git.openjdk.org/jdk/pull/11057 From psadhukhan at openjdk.org Mon Nov 14 07:11:31 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 14 Nov 2022 07:11:31 GMT Subject: RFR: 8296083: javax/swing/JTree/6263446/bug6263446.java fails intermittently on a VM [v2] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 04:51:15 GMT, Jayathirth D V wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Test update > > test/jdk/javax/swing/JTree/6263446/bug6263446.java line 41: > >> 39: public class bug6263446 { >> 40: >> 41: private static final String FIRST = "AAAAA"; > > any particular reason for decreasing length of string? Yes, as I mentioned to make it same like JTable/6263446/bug6263446.java which has not failed in these OCI systems at all as the cause of this test failure in OCI system was not making any sense but in my local ubutu20.04 system ,it fails once in a while for not able to select the string which is done in the testcase by mouse clicks, so more characters can result in failure in selection if mouse clicks is not getting registered properly... Reducing characters does not hamper testcase which can still be used to test JDK-6263446 regression ------------- PR: https://git.openjdk.org/jdk/pull/11057 From serb at openjdk.org Mon Nov 14 08:05:48 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 14 Nov 2022 08:05:48 GMT Subject: RFR: 8296905: Replace the native LCMS#getProfileID() method with the accessor In-Reply-To: <7jMOilsUHip2idGzJGSiNEMCB4EwssM8mDmxdbAcEZw=.a71cb407-f6ab-420a-af29-6df49f8a7099@github.com> References: <7jMOilsUHip2idGzJGSiNEMCB4EwssM8mDmxdbAcEZw=.a71cb407-f6ab-420a-af29-6df49f8a7099@github.com> Message-ID: On Sat, 12 Nov 2022 09:18:57 GMT, Andrey Turbanov wrote: >> The native method used to access the private method in the `ICC_Profile` class is replaced by the accessor. > > src/java.desktop/share/classes/sun/awt/AWTAccessor.java line 891: > >> 889: */ >> 890: public static ICC_ProfileAccessor getICC_ProfileAccessor() { >> 891: if (iccProfileAccessor == null) { > > For `SharedSecrets` in java.base code was updated to use single read (to avoid concurrency problems) - see [JDK-8259021](https://bugs.openjdk.org/browse/JDK-8259021) > Shouldn't we use the same patter here? Yes, you are right, let me fix that first. ------------- PR: https://git.openjdk.org/jdk/pull/11116 From stuefe at openjdk.org Mon Nov 14 08:05:49 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 14 Nov 2022 08:05:49 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 In-Reply-To: <-ER02i5fNCaZX-v56giR7gCbuMkwwpdhg5LBLThVvds=.402ad601-58e3-4529-935a-151e5e76b2b3@github.com> References: <-ER02i5fNCaZX-v56giR7gCbuMkwwpdhg5LBLThVvds=.402ad601-58e3-4529-935a-151e5e76b2b3@github.com> Message-ID: <9fb7vy703UZemRy0XnH4NQkPINCR4FzPvjwp3MFhJqk=.56f02d33-0156-48be-862d-7972d36d19a8@github.com> On Sun, 13 Nov 2022 22:55:52 GMT, Xue-Lei Andrew Fan wrote: > Please don't add uses of `jio_snprintf` or `::snprintf` to hotspot. Use `os::snprintf`. I did not know this was our policy now. Sorry for giving the wrong advice. Maybe we should add this to the hotspot style guide since I'm probably not the only one not knowing this. > > Regarding `jio_snprintf`, see https://bugs.openjdk.org/browse/JDK-8198918. Regarding `os::snprintf` and `os::vsnprintf`, see https://bugs.openjdk.org/browse/JDK-8285506. > > I think the only reason we haven't marked `::sprintf` and `::snprintf` forbidden (FORBID_C_FUNCTION) is there are a lot of uses, and nobody has gotten around to dealing with it. `::snprintf` in the list of candidates for https://bugs.openjdk.org/browse/JDK-8214976, some of which have already been marked. But I don't see new bugs for the as-yet unmarked ones. > > As a general note, as a reviewer my preference is against non-trivial and persnickety code changes that are scattered all over the code base. For something like this I'd prefer multiple more bite-sized changes that were dealing with specific uses. I doubt everyone agrees with me though. I agree with you. Makes backporting a bit easier too. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From serb at openjdk.org Mon Nov 14 08:07:28 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 14 Nov 2022 08:07:28 GMT Subject: RFR: 8164464: Consistent failure of java/awt/dnd/MissingEventsOnModalDialog/MissingEventsOnModalDialogTest.java In-Reply-To: References: Message-ID: <7hf0MYcgcFZXxtS831v5y54TbuinrfJ0RwRoAMUf8QU=.78bf11a0-cc3a-4f71-a519-b4f574f5e3ae@github.com> On Mon, 14 Nov 2022 00:23:09 GMT, Alexander Zvegintsev wrote: > This is an old issue, which is no longer reproducible. > The test is slightly stabilized for slow machines. > > CI testing looks good. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11129 From serb at openjdk.org Mon Nov 14 08:14:26 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 14 Nov 2022 08:14:26 GMT Subject: RFR: 8157173: [macosx] java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java fails In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 00:12:00 GMT, Alexander Zvegintsev wrote: > This test currently passing as it is on all platforms, but it was problemlisted with ["Problem List some tests that leave windows open on the desktop" reason](https://github.com/openjdk/jdk/commit/fd8df3adf13f5df8f5f95482b8e0a70bc519f39f) > > So this test is cleaned up and stabilized. > > CI testing looks good. test/jdk/java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java line 159: > 157: > 158: robot.mouseMove( > 159: (int) frame.getLocationOnScreen().getX() + Looks like the frame is set on one thread and accessed on another. ------------- PR: https://git.openjdk.org/jdk/pull/11128 From smandalika at openjdk.org Mon Nov 14 08:20:28 2022 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Mon, 14 Nov 2022 08:20:28 GMT Subject: RFR: 8295707: Create a regression test for JDK-7184401 [v2] In-Reply-To: References: Message-ID: <2d94xEbgxv8AXVv-uSs_yUmbB3mWFxLOLWh_w5RZzrU=.4101da71-a35d-4010-b148-3272c6de8c5f@github.com> On Mon, 7 Nov 2022 07:28:02 GMT, Srinivas Mandalika wrote: >> 8295707: Create a regression test for JDK-7184401 >> >> JDK-7184401 - JDk7u6 : Missing main menu bar in Netbeans after fix for 7162144 >> Above bug got introduced due to a fix for [JDK-7162144](https://bugs.openjdk.java.net/browse/JDK-7162144). >> The issue was observed on the netbeans UI. >> The test below recreates a standalone test to mimic the failure reported in Netbeans in [JDK-7184401](https://bugs.openjdk.java.net/browse/JDK-7184401) and verifies that it is working as expected after it got fixed via [JDK-7189350](https://bugs.openjdk.java.net/browse/JDK-7189350)) >> >> The Test attempts to reproduce specific behavior of NetBeans at the certain toolbar creation stage. Widgets are created on EDT; Another code posts some events to them on EDT; From another thread some code calls explicitly edt.interrupt(). >> Before this got fixed, events from a second code got lost. >> >> This review is for migrating tests from a closed test suite to open. >> Testing: >> 1.Tested the code on jdk7u6 to reproduce the issue - the UI hangs when run on this build. >> 2. Tested the code on jdk7u361 b01 to validate the fix - the test passed. >> 3.Mach5 Testing(40 times per platform) in macos x64, linux x64 and windows x64 - the .results are clean > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Fixed Review Comments: Removed redundant code Any volunteers for reviewing this PR ? ------------- PR: https://git.openjdk.org/jdk/pull/10784 From aph at openjdk.org Mon Nov 14 10:06:37 2022 From: aph at openjdk.org (Andrew Haley) Date: Mon, 14 Nov 2022 10:06:37 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v4] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 05:32:20 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> May I have this update reviewed? >> >> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > include missing os head file Kim said: > As a general note, as a reviewer my preference is against non-trivial and persnickety code changes that are scattered all over the code base. For something like this I'd prefer multiple more bite-sized changes that were dealing with specific uses. I doubt everyone agrees with me though. There's a lot of wisdom in what you say. It's far too easy to mess things up when doing cleanups for compiler warnings. Also, long patches never get enough reviewing. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From stuefe at openjdk.org Mon Nov 14 10:23:28 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 14 Nov 2022 10:23:28 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v4] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 05:32:20 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> May I have this update reviewed? >> >> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > include missing os head file src/hotspot/share/adlc/output_c.cpp line 2570: > 2568: int idx = inst.operand_position_format(arg_name); > 2569: if (strcmp(arg_name, "constanttablebase") == 0) { > 2570: ib += snprintf(ib, (buflen - (ib - idxbuf)), " unsigned idx_%-5s = mach_constant_base_node_input(); \t// %s, \t%s\n", Use sizeof(buffer) instead of buflen? Also, possibly using a helper macro like this: #define remaining_buflen(buffer, position) (sizeof(buffer) - (position - buffer)) would make the code a bit easier on the eye. Or, if not a macro, an inline helper function, that could assert also array boundaries. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From asemenov at openjdk.org Mon Nov 14 11:10:35 2022 From: asemenov at openjdk.org (Artem Semenov) Date: Mon, 14 Nov 2022 11:10:35 GMT Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v4] In-Reply-To: References: <6HPa6vPeV5haQI_Ifs5IRH1xcjiqbld0T2Fk_WIABAY=.c0c2f8ff-988e-4017-8e61-a365870d5e6b@github.com> Message-ID: On Fri, 11 Nov 2022 21:40:40 GMT, Sergey Bylokhov wrote: >> We tried to do this, it leads to an endless repetition of the selected line until it freezes. > > Probably because of the endless notifications loop? implementation of addSelectionInterval looks similar to setSelectionInterval. In some cases the addSelectionInterval just call setSelectionInterval. It looks like it is. Please formulate the question differently. ------------- PR: https://git.openjdk.org/jdk/pull/8578 From azvegint at openjdk.org Mon Nov 14 14:38:38 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 14 Nov 2022 14:38:38 GMT Subject: RFR: 8157173: [macosx] java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java fails [v2] In-Reply-To: References: Message-ID: <3H6QdSOg-MtRtP1LJe3ZF0M8zTLQJ3PyQ37pp-WBZQw=.41d8b0d7-7869-400d-8b6a-3cc1ef19cf1a@github.com> > This test currently passing as it is on all platforms, but it was problemlisted with ["Problem List some tests that leave windows open on the desktop" reason](https://github.com/openjdk/jdk/commit/fd8df3adf13f5df8f5f95482b8e0a70bc519f39f) > > So this test is cleaned up and stabilized. > > CI testing looks good. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: Addressing review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11128/files - new: https://git.openjdk.org/jdk/pull/11128/files/8065bbb2..b906399e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11128&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11128&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11128.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11128/head:pull/11128 PR: https://git.openjdk.org/jdk/pull/11128 From azvegint at openjdk.org Mon Nov 14 14:47:41 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 14 Nov 2022 14:47:41 GMT Subject: RFR: 8157173: [macosx] java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java fails [v2] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 08:08:53 GMT, Sergey Bylokhov wrote: >> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressing review comments > > test/jdk/java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java line 159: > >> 157: >> 158: robot.mouseMove( >> 159: (int) frame.getLocationOnScreen().getX() + > > Looks like the frame is set on one thread and accessed on another. Updated. ------------- PR: https://git.openjdk.org/jdk/pull/11128 From azvegint at openjdk.org Mon Nov 14 14:49:35 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 14 Nov 2022 14:49:35 GMT Subject: Integrated: 8164464: Consistent failure of java/awt/dnd/MissingEventsOnModalDialog/MissingEventsOnModalDialogTest.java In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 00:23:09 GMT, Alexander Zvegintsev wrote: > This is an old issue, which is no longer reproducible. > The test is slightly stabilized for slow machines. > > CI testing looks good. This pull request has now been integrated. Changeset: b0edfc11 Author: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/b0edfc1159b160eb329a066dc2805c22937a5da8 Stats: 24 lines in 2 files changed: 7 ins; 10 del; 7 mod 8164464: Consistent failure of java/awt/dnd/MissingEventsOnModalDialog/MissingEventsOnModalDialogTest.java Reviewed-by: jdv, serb ------------- PR: https://git.openjdk.org/jdk/pull/11129 From duke at openjdk.org Mon Nov 14 15:22:26 2022 From: duke at openjdk.org (lawrence.andrews) Date: Mon, 14 Nov 2022 15:22:26 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. [v4] In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 08:20:55 GMT, ravi gupta wrote: >> This testcase Verify the content changes of a TextArea for the following assertions. >> >> a. TextListener get invoked when the content of a TextArea gets changed. >> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8296632: Review fixes. LGTM ------------- PR: https://git.openjdk.org/jdk/pull/11052 From duke at openjdk.org Mon Nov 14 16:00:37 2022 From: duke at openjdk.org (lawrence.andrews) Date: Mon, 14 Nov 2022 16:00:37 GMT Subject: RFR: 8295707: Create a regression test for JDK-7184401 [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 07:28:02 GMT, Srinivas Mandalika wrote: >> 8295707: Create a regression test for JDK-7184401 >> >> JDK-7184401 - JDk7u6 : Missing main menu bar in Netbeans after fix for 7162144 >> Above bug got introduced due to a fix for [JDK-7162144](https://bugs.openjdk.java.net/browse/JDK-7162144). >> The issue was observed on the netbeans UI. >> The test below recreates a standalone test to mimic the failure reported in Netbeans in [JDK-7184401](https://bugs.openjdk.java.net/browse/JDK-7184401) and verifies that it is working as expected after it got fixed via [JDK-7189350](https://bugs.openjdk.java.net/browse/JDK-7189350)) >> >> The Test attempts to reproduce specific behavior of NetBeans at the certain toolbar creation stage. Widgets are created on EDT; Another code posts some events to them on EDT; From another thread some code calls explicitly edt.interrupt(). >> Before this got fixed, events from a second code got lost. >> >> This review is for migrating tests from a closed test suite to open. >> Testing: >> 1.Tested the code on jdk7u6 to reproduce the issue - the UI hangs when run on this build. >> 2. Tested the code on jdk7u361 b01 to validate the fix - the test passed. >> 3.Mach5 Testing(40 times per platform) in macos x64, linux x64 and windows x64 - the .results are clean > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Fixed Review Comments: Removed redundant code LGTM ------------- PR: https://git.openjdk.org/jdk/pull/10784 From kizune at openjdk.org Mon Nov 14 18:07:34 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 14 Nov 2022 18:07:34 GMT Subject: RFR: 8296222: SwingEventMonitor - installListeners(Component , int ) - CELLEDITOR - bug In-Reply-To: References: Message-ID: <4jbqp1JkN_LwV0HDNQiki5kA0pVDVct6b1ocfSVFCYk=.4b3f5a3b-65bb-43e9-9599-5cfbf2c277de@github.com> On Thu, 10 Nov 2022 08:01:38 GMT, Abhishek Kumar wrote: > It seems there was a typo inside function `installListeners(Component, int)` and `removeListeners(Component)` on case EventID.CELLEDITOR. > > Changed the string from "getCellEditorMethod" to "getCellEditor" in `protected void installListeners(Component c, int eventID)` and `protected void removeListeners(Component c)` methods. > > Didn't add any test case. Looks good ------------- Marked as reviewed by kizune (Reviewer). PR: https://git.openjdk.org/jdk/pull/11082 From prr at openjdk.org Mon Nov 14 18:26:21 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 14 Nov 2022 18:26:21 GMT Subject: RFR: 8286624: Regression Test CoordinateTruncationBug.java fails on OL8.3 [v2] In-Reply-To: References: Message-ID: > This was a closed test - simply because it hadn't been reviewed for moving to open > so I am doing it now whilst fixing a problem that was observed on the OL 8.x (and > by implication an RHEL 8.x) desktop due to the screen menu bar rendering over one > line of the undecorated window. > That was fixed by changing the location to use setLocationRelativeTo(null) vs > the previous implied (0,0) Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8286624 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11120/files - new: https://git.openjdk.org/jdk/pull/11120/files/41753a1a..ef7287be Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11120&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11120&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11120.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11120/head:pull/11120 PR: https://git.openjdk.org/jdk/pull/11120 From prr at openjdk.org Mon Nov 14 18:43:44 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 14 Nov 2022 18:43:44 GMT Subject: RFR: 8157173: [macosx] java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java fails [v2] In-Reply-To: <3H6QdSOg-MtRtP1LJe3ZF0M8zTLQJ3PyQ37pp-WBZQw=.41d8b0d7-7869-400d-8b6a-3cc1ef19cf1a@github.com> References: <3H6QdSOg-MtRtP1LJe3ZF0M8zTLQJ3PyQ37pp-WBZQw=.41d8b0d7-7869-400d-8b6a-3cc1ef19cf1a@github.com> Message-ID: On Mon, 14 Nov 2022 14:38:38 GMT, Alexander Zvegintsev wrote: >> This test currently passing as it is on all platforms, but it was problemlisted with ["Problem List some tests that leave windows open on the desktop" reason](https://github.com/openjdk/jdk/commit/fd8df3adf13f5df8f5f95482b8e0a70bc519f39f) >> >> So this test is cleaned up and stabilized. >> >> CI testing looks good. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > Addressing review comments So - apart from the last change to use volatile - you found nothing functionally wrong with the test ? There's so much clean up I can't be sure I'm not missing some functional change you made. If there was nothing wrong with it, why was it leaving windows open ? ------------- PR: https://git.openjdk.org/jdk/pull/11128 From kizune at openjdk.org Mon Nov 14 19:27:21 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 14 Nov 2022 19:27:21 GMT Subject: RFR: 8286624: Regression Test CoordinateTruncationBug.java fails on OL8.3 [v2] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 18:26:21 GMT, Phil Race wrote: >> This was a closed test - simply because it hadn't been reviewed for moving to open >> so I am doing it now whilst fixing a problem that was observed on the OL 8.x (and >> by implication an RHEL 8.x) desktop due to the screen menu bar rendering over one >> line of the undecorated window. >> That was fixed by changing the location to use setLocationRelativeTo(null) vs >> the previous implied (0,0) > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8286624 Marked as reviewed by kizune (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11120 From achung at openjdk.org Mon Nov 14 19:30:02 2022 From: achung at openjdk.org (Alisen Chung) Date: Mon, 14 Nov 2022 19:30:02 GMT Subject: RFR: 8295369: Update LCMS to 2.14 [v4] In-Reply-To: References: Message-ID: > Updating LCMS to newest release Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: fixed indentation problem in cmscgats.c ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11000/files - new: https://git.openjdk.org/jdk/pull/11000/files/8b88afb6..5141ed55 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11000&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11000&range=02-03 Stats: 38 lines in 2 files changed: 0 ins; 29 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/11000.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11000/head:pull/11000 PR: https://git.openjdk.org/jdk/pull/11000 From achung at openjdk.org Mon Nov 14 19:30:05 2022 From: achung at openjdk.org (Alisen Chung) Date: Mon, 14 Nov 2022 19:30:05 GMT Subject: RFR: 8295369: Update LCMS to 2.14 [v3] In-Reply-To: <9DJxFsT8hx2Z-1cgnuIhnKhiWFMRS4tMAQCojhiBJ5s=.5917d184-c908-4874-9929-06da3a509e35@github.com> References: <9DJxFsT8hx2Z-1cgnuIhnKhiWFMRS4tMAQCojhiBJ5s=.5917d184-c908-4874-9929-06da3a509e35@github.com> Message-ID: On Thu, 10 Nov 2022 23:28:13 GMT, Phil Race wrote: >> src/java.desktop/share/native/liblcms/cmscgats.c line 2389: >> >>> 2387: >>> 2388: SetData(it8, i, idField, Buffer); >>> 2389: } >> >> Are these shifts caused by our script or that is the change in the upstream? > > These look to me like tabs have not been replaced by spaces.. > I saw a lot of "shifts" and I spot-checked some of them but they looked like ones where upstream had readily changed indentation. > This does not look like that. I'm not sure why the script did that, but I manually reverted these lines to what it was before the script was run. ------------- PR: https://git.openjdk.org/jdk/pull/11000 From xuelei at openjdk.org Mon Nov 14 19:30:25 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 14 Nov 2022 19:30:25 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v5] In-Reply-To: References: Message-ID: > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: use helper macro ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11115/files - new: https://git.openjdk.org/jdk/pull/11115/files/128bc806..32e18955 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=03-04 Stats: 10 lines in 3 files changed: 4 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11115.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11115/head:pull/11115 PR: https://git.openjdk.org/jdk/pull/11115 From prr at openjdk.org Mon Nov 14 19:30:25 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 14 Nov 2022 19:30:25 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v5] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 19:05:16 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> May I have this update reviewed? >> >> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > use helper macro The single client change looks fine. I didn't look at the rest. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.org/jdk/pull/11115 From xuelei at openjdk.org Mon Nov 14 19:30:29 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 14 Nov 2022 19:30:29 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v4] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 10:21:07 GMT, Thomas Stuefe wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> include missing os head file > > src/hotspot/share/adlc/output_c.cpp line 2570: > >> 2568: int idx = inst.operand_position_format(arg_name); >> 2569: if (strcmp(arg_name, "constanttablebase") == 0) { >> 2570: ib += snprintf(ib, (buflen - (ib - idxbuf)), " unsigned idx_%-5s = mach_constant_base_node_input(); \t// %s, \t%s\n", > > Use sizeof(buffer) instead of buflen? > Also, possibly using a helper macro like this: > > > #define remaining_buflen(buffer, position) (sizeof(buffer) - (position - buffer)) > > would make the code a bit easier on the eye. Or, if not a macro, an inline helper function, that could assert also array boundaries. Thanks for suggestion, which makes the code much easier to read. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From serb at openjdk.org Mon Nov 14 19:39:03 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 14 Nov 2022 19:39:03 GMT Subject: RFR: 8296496: Overzealous check in sizecalc.h prevents large memory allocation [v3] In-Reply-To: <9-eaFh_LdVPjru9mFiLeSJIPn7u6D0wVBbA4TSPxrRI=.9344e582-e0df-4bd1-b24b-390451af5975@github.com> References: <9-eaFh_LdVPjru9mFiLeSJIPn7u6D0wVBbA4TSPxrRI=.9344e582-e0df-4bd1-b24b-390451af5975@github.com> Message-ID: <9WU3TPxU8_syrXM9JF6hd92gGIKJPE5bOKGlVusNWnI=.76d7f4d0-7194-4608-9f97-6dea51fd7941@github.com> On Tue, 8 Nov 2022 23:43:23 GMT, Alexander Zuev wrote: >> Removed the additional multiplication overflow detection. >> Instead cast all the parameters to type_t just the way they are treated in the existing size check macro. >> This way there is no possibility to accidentally provide parameters that will pass the size check macro while being cast to size_t there but then due to the missing cast cause the wrong size passed the actual allocation function. >> Since this checking macro was used in couple of different places all of them needs to be updated in the similar way. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Fixed casting in SAFE_SIZE_NEW_ARRAY2 src/java.desktop/share/native/common/awt/utility/sizecalc.h line 94: > 92: > 93: #define SAFE_SIZE_NEW_ARRAY2(type, n, m) \ > 94: (IS_SAFE_SIZE_MUL((m), (n)) && IS_SAFE_SIZE_MUL(sizeof(type), (n) * (m)) ? \ Why we do not cast it here: (n) * (m)? ------------- PR: https://git.openjdk.org/jdk/pull/11030 From serb at openjdk.org Mon Nov 14 19:39:04 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 14 Nov 2022 19:39:04 GMT Subject: RFR: 8296496: Overzealous check in sizecalc.h prevents large memory allocation [v3] In-Reply-To: <9WU3TPxU8_syrXM9JF6hd92gGIKJPE5bOKGlVusNWnI=.76d7f4d0-7194-4608-9f97-6dea51fd7941@github.com> References: <9-eaFh_LdVPjru9mFiLeSJIPn7u6D0wVBbA4TSPxrRI=.9344e582-e0df-4bd1-b24b-390451af5975@github.com> <9WU3TPxU8_syrXM9JF6hd92gGIKJPE5bOKGlVusNWnI=.76d7f4d0-7194-4608-9f97-6dea51fd7941@github.com> Message-ID: <4aivSMw6ywDjt5hvWzs0Qge99o95AmA94EDQQT__eec=.ab0ada1c-ebdf-4d4f-af5e-2c4f89a897af@github.com> On Mon, 14 Nov 2022 19:20:25 GMT, Sergey Bylokhov wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed casting in SAFE_SIZE_NEW_ARRAY2 > > src/java.desktop/share/native/common/awt/utility/sizecalc.h line 94: > >> 92: >> 93: #define SAFE_SIZE_NEW_ARRAY2(type, n, m) \ >> 94: (IS_SAFE_SIZE_MUL((m), (n)) && IS_SAFE_SIZE_MUL(sizeof(type), (n) * (m)) ? \ > > Why we do not cast it here: (n) * (m)? Filed https://bugs.openjdk.org/browse/JDK-8296957 ------------- PR: https://git.openjdk.org/jdk/pull/11030 From aivanov at openjdk.org Mon Nov 14 19:39:05 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 14 Nov 2022 19:39:05 GMT Subject: RFR: 8296496: Overzealous check in sizecalc.h prevents large memory allocation [v3] In-Reply-To: <4aivSMw6ywDjt5hvWzs0Qge99o95AmA94EDQQT__eec=.ab0ada1c-ebdf-4d4f-af5e-2c4f89a897af@github.com> References: <9-eaFh_LdVPjru9mFiLeSJIPn7u6D0wVBbA4TSPxrRI=.9344e582-e0df-4bd1-b24b-390451af5975@github.com> <9WU3TPxU8_syrXM9JF6hd92gGIKJPE5bOKGlVusNWnI=.76d7f4d0-7194-4608-9f97-6dea51fd7941@github.com> <4aivSMw6ywDjt5hvWzs0Qge99o95AmA94EDQQT__eec=.ab0ada1c-ebdf-4d4f-af5e-2c4f89a897af@github.com> Message-ID: On Mon, 14 Nov 2022 19:27:44 GMT, Sergey Bylokhov wrote: >> src/java.desktop/share/native/common/awt/utility/sizecalc.h line 94: >> >>> 92: >>> 93: #define SAFE_SIZE_NEW_ARRAY2(type, n, m) \ >>> 94: (IS_SAFE_SIZE_MUL((m), (n)) && IS_SAFE_SIZE_MUL(sizeof(type), (n) * (m)) ? \ >> >> Why we do not cast it here: (n) * (m)? > > Filed https://bugs.openjdk.org/browse/JDK-8296957 You're right, it must be cast here too, I have missed it. Would you mind submitting a bug? ------------- PR: https://git.openjdk.org/jdk/pull/11030 From xuelei at openjdk.org Mon Nov 14 19:44:17 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 14 Nov 2022 19:44:17 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v6] In-Reply-To: References: Message-ID: > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: delete swp file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11115/files - new: https://git.openjdk.org/jdk/pull/11115/files/32e18955..ca4ddcc4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=04-05 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11115.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11115/head:pull/11115 PR: https://git.openjdk.org/jdk/pull/11115 From prr at openjdk.org Mon Nov 14 19:55:17 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 14 Nov 2022 19:55:17 GMT Subject: Integrated: 8286624: Regression Test CoordinateTruncationBug.java fails on OL8.3 In-Reply-To: References: Message-ID: On Sat, 12 Nov 2022 20:29:39 GMT, Phil Race wrote: > This was a closed test - simply because it hadn't been reviewed for moving to open > so I am doing it now whilst fixing a problem that was observed on the OL 8.x (and > by implication an RHEL 8.x) desktop due to the screen menu bar rendering over one > line of the undecorated window. > That was fixed by changing the location to use setLocationRelativeTo(null) vs > the previous implied (0,0) This pull request has now been integrated. Changeset: c71d87e5 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/c71d87e54ca0c0173583bed978e06c7faa0fa283 Stats: 271 lines in 1 file changed: 271 ins; 0 del; 0 mod 8286624: Regression Test CoordinateTruncationBug.java fails on OL8.3 Reviewed-by: azvegint, kizune ------------- PR: https://git.openjdk.org/jdk/pull/11120 From azvegint at openjdk.org Mon Nov 14 20:15:55 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 14 Nov 2022 20:15:55 GMT Subject: RFR: 8157173: [macosx] java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java fails [v2] In-Reply-To: References: <3H6QdSOg-MtRtP1LJe3ZF0M8zTLQJ3PyQ37pp-WBZQw=.41d8b0d7-7869-400d-8b6a-3cc1ef19cf1a@github.com> Message-ID: <7bvpOQwZbmJe8YoafePiGf2GrTtWUon22FCo21wdEf4=.de895e62-2d43-4d41-9a2b-f89cb47390a3@github.com> On Mon, 14 Nov 2022 18:39:46 GMT, Phil Race wrote: > So - apart from the last change to use volatile - you found nothing functionally wrong with the test ? There's so much clean up I can't be sure I'm not missing some functional change you made. If there was nothing wrong with it, why was it leaving windows open ? Next time I'll put clean up into different commit. Regarding the test stabilization and functional changes: * wrapped keyRelease, frame.dispose calls with finally * increased delay after frame appearance * increased AutoDelay ------------- PR: https://git.openjdk.org/jdk/pull/11128 From aivanov at openjdk.org Mon Nov 14 21:14:07 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 14 Nov 2022 21:14:07 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: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com> References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com> Message-ID: On Fri, 11 Nov 2022 08:18:19 GMT, Tejesh R wrote: > Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system. Can you verify that the MultiResolutionImage contains no variants? If it's the case, a cleaner way would be to return `null` right away. Or rather, the function that creates the `MultiResolutionIconImage` instance should be modified to return `null` rather than returning an MRI with no variants. This should never happen because if the system does not provide an icon, a default icon gets requested. By adding the null-check we don't resolve the real problem but pretend it does not exist. ------------- PR: https://git.openjdk.org/jdk/pull/11104 From prr at openjdk.org Mon Nov 14 21:18:09 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 14 Nov 2022 21:18:09 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: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com> References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com> Message-ID: On Fri, 11 Nov 2022 08:18:19 GMT, Tejesh R wrote: > Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system. I agree with Alexey. ------------- PR: https://git.openjdk.org/jdk/pull/11104 From prr at openjdk.org Mon Nov 14 21:20:05 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 14 Nov 2022 21:20:05 GMT Subject: RFR: 8296083: javax/swing/JTree/6263446/bug6263446.java fails intermittently on a VM [v2] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 06:56:20 GMT, Prasanta Sadhukhan wrote: >> Test intermittently fails in VM citing "Tree is not editing". Seems to be problem with mouse clicks not getting registered properly.. >> Similar test test/jdk/javax/swing/JTable/6263446/bug6263446.java is not affected, so made the test similar to it by using same safeguard using Robot.waitForIdle() and modifying clickpoint to tree cell midpoint. >> >> Several iterations of the test pass in the OCI VM and all other physical platforms (link in JBS) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test update So it now passes 100% of the time on the OCI systems ? ------------- PR: https://git.openjdk.org/jdk/pull/11057 From prr at openjdk.org Mon Nov 14 22:30:55 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 14 Nov 2022 22:30:55 GMT Subject: RFR: 8295369: Update LCMS to 2.14 [v3] In-Reply-To: References: <9DJxFsT8hx2Z-1cgnuIhnKhiWFMRS4tMAQCojhiBJ5s=.5917d184-c908-4874-9929-06da3a509e35@github.com> Message-ID: On Mon, 14 Nov 2022 19:09:40 GMT, Alisen Chung wrote: >> These look to me like tabs have not been replaced by spaces.. >> I saw a lot of "shifts" and I spot-checked some of them but they looked like ones where upstream had readily changed indentation. >> This does not look like that. > > I'm not sure why the script did that, but I manually reverted these lines to what it was before the script was run. Now you definitely have tabs - skara's jcheck is reporting them - for example Check failure on line 2369 in src/java.desktop/share/native/liblcms/cmscgats.c openjdk / jcheck Whitespace error Column 0: tab Column 1: tab ==== ------------- PR: https://git.openjdk.org/jdk/pull/11000 From azvegint at openjdk.org Tue Nov 15 00:27:59 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 15 Nov 2022 00:27:59 GMT Subject: RFR: 8148041: Test java/awt/Mouse/TitleBarDoubleClick/TitleBarDoubleClick fails on Ubuntu with mouseReleased event after double click on title bar Message-ID: This test was problem listed with ["some tests that leave windows open on the desktop" reason](https://github.com/openjdk/jdk/commit/fd8df3adf13f5df8f5f95482b8e0a70bc519f39f) The main issue with the test is that it may pass, but in fact the actual test was not even performed.
`jtreg` kills the test window after exiting main and ends the test before it double clicks on window's title(actual test starts from `windowActivated` event). So the test was refactored and stabilized: * robot invocation moved from EDT to main thread. * throwing test exception is performed only after frame is disposed * extra delay added after showing window. Old Ubuntu 16.04 and macOS 10.10.5 failures is no longer reproducible on modern systems. CI testing looks good. ------------- Commit messages: - refactor - clean up Changes: https://git.openjdk.org/jdk/pull/11150/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11150&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8148041 Stats: 71 lines in 2 files changed: 19 ins; 8 del; 44 mod Patch: https://git.openjdk.org/jdk/pull/11150.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11150/head:pull/11150 PR: https://git.openjdk.org/jdk/pull/11150 From tr at openjdk.org Tue Nov 15 05:12:38 2022 From: tr at openjdk.org (Tejesh R) Date: Tue, 15 Nov 2022 05:12:38 GMT Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and radio button with GTK LAF for bug4314194. [v4] In-Reply-To: References: Message-ID: <7NHSvswD-8_8Yc-h4RV8YW_KkPeyBubyhP8M-yE2UPQ=.60f8e8a5-60be-4d00-ad9c-cd205563b1ba@github.com> On Mon, 14 Nov 2022 04:53:50 GMT, Abhishek Kumar wrote: >> Existing test `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` was not showing colored text for disabled checkbox and radiobutton in GTK LAF. >> >> The fix is to get the disabled state color for checkbox and radiobutton from UIManager if it exists. >> >> Test case `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` has been checked in CI pipeline. Link is attached in JBS. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Used bitwise operator for condition check Marked as reviewed by tr (Committer). Fix is tested and working fine. ------------- PR: https://git.openjdk.org/jdk/pull/10755 From psadhukhan at openjdk.org Tue Nov 15 05:18:58 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 15 Nov 2022 05:18:58 GMT Subject: RFR: 8296083: javax/swing/JTree/6263446/bug6263446.java fails intermittently on a VM [v2] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 21:17:43 GMT, Phil Race wrote: > So it now passes 100% of the time on the OCI systems ? At least in my testing, links of those OCI jobs have been put in JBS too ------------- PR: https://git.openjdk.org/jdk/pull/11057 From tr at openjdk.org Tue Nov 15 06:32:04 2022 From: tr at openjdk.org (Tejesh R) Date: Tue, 15 Nov 2022 06:32: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: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com> References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com> Message-ID: On Fri, 11 Nov 2022 08:18:19 GMT, Tejesh R wrote: > Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system. > Yeah, the only way the retVal can become null would-be if `resolutionVariants` doesn't have an Icon. I could not reproduce the bug since it is intermittent, I came to this conclusion only by code analysis though. Should I check for `resolutionVariants` if its empty and return null without proceeding further......? I guess both the ways `null` will be returned? ------------- PR: https://git.openjdk.org/jdk/pull/11104 From kbarrett at openjdk.org Tue Nov 15 07:32:36 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 15 Nov 2022 07:32:36 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v6] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 19:44:17 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> May I have this update reviewed? >> >> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > delete swp file Mostly okay. There are some places where the result from `os::snprintf` could be used instead of a later `strlen`. Most of those are pre-existing (so could be considered for later cleanups), but in at least one case there was a new strlen call introduced, so making the code slightly worse. src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 226: > 224: char buf[512]; > 225: os::snprintf(buf, sizeof(buf), "0x%02x:0x%x:0x%03x:%d", _cpu, _variant, _model, _revision); > 226: if (_model2) os::snprintf(buf+strlen(buf), sizeof(buf) - strlen(buf), "(0x%03x)", _model2); Instead of using `strlen(buf)` (now called twice!) to get the number of characters written, use the result of the first call to `os::snprintf`. src/hotspot/os/bsd/attachListener_bsd.cpp line 251: > 249: BsdAttachOperation* BsdAttachListener::read_request(int s) { > 250: char ver_str[8]; > 251: os::snprintf(ver_str, sizeof(ver_str), "%d", ATTACH_PROTOCOL_VER); We later use `strlen(ver_str)` where we could instead use the result of `os::snprintf`. src/hotspot/os/bsd/attachListener_bsd.cpp line 294: > 292: (atoi(buf) != ATTACH_PROTOCOL_VER)) { > 293: char msg[32]; > 294: os::snprintf(msg, sizeof(msg), "%d\n", ATTACH_ERROR_BADVERSION); Rather than using `strlen(msg)` in the next line, use the result from `os::snprintf`. src/hotspot/os/bsd/attachListener_bsd.cpp line 414: > 412: // write operation result > 413: char msg[32]; > 414: os::snprintf(msg, sizeof(msg), "%d\n", result); Rather than using strlen(msg) in the next line, use the result from os::snprintf. src/hotspot/share/classfile/javaClasses.cpp line 2532: > 2530: // Print module information > 2531: if (module_name != NULL) { > 2532: buf_off = (int)strlen(buf); `buf_off` could be the result of `os::snprintf` instead of calling `strlen`. src/hotspot/share/code/dependencies.cpp line 780: > 778: } > 779: } else { > 780: char xn[12]; os::snprintf(xn, sizeof(xn), "x%d", j); Pre-existing very unusual formatting; put a line break between the statements. ------------- Changes requested by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/11115 From kizune at openjdk.org Tue Nov 15 07:39:36 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 15 Nov 2022 07:39:36 GMT Subject: RFR: 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout Message-ID: On m1 mac sometimes (in very rare instance) it takes a long time to get the sequencer so increasing timeout helps with that. Also on m1 mac sequencer got notified about the first MetaMessage twice. The reason is unclear but watching for that fixes the problem. Also on Linux sometimes process hangs indefinitely without finishing hold by the com.sun.media.sound.MediaDispatcher. Closing the sequencer at the end of the test helps with that. ------------- Commit messages: - Handle case when on m1 mac handler being called twice on the same message in the beginning of playback - 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout Changes: https://git.openjdk.org/jdk/pull/11157/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11157&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8178698 Stats: 14 lines in 2 files changed: 9 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11157.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11157/head:pull/11157 PR: https://git.openjdk.org/jdk/pull/11157 From jdv at openjdk.org Tue Nov 15 08:07:34 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 15 Nov 2022 08:07:34 GMT Subject: RFR: 8022403: sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java fails Message-ID: This test was failing because of color difference on boundaries. Updated test case to not check edges and added color tolerance. Also updated test to: 1) Use standard GraphicsConfiguration bounds for image instead of constant numbers. 2) Use waitForIdle before screen capture and added auto delay 3) Move mouse pointer away from rendering content (In my local Mac it failed every time when mouse pointer was present over test frame) 4) Remove usage of insets as it is undecorated and remove windows closing listener 5) Dispose frame when test fails With these changes test is not failing in CI with multiple runs on all platforms. ------------- Commit messages: - Bring back initial delay for slow systems - Remove from problemlist - Use waitForIdle and standardise image bounds - Initial change Changes: https://git.openjdk.org/jdk/pull/11158/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11158&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8022403 Stats: 88 lines in 2 files changed: 33 ins; 24 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/11158.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11158/head:pull/11158 PR: https://git.openjdk.org/jdk/pull/11158 From stuefe at openjdk.org Tue Nov 15 08:25:04 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 15 Nov 2022 08:25:04 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v6] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 19:44:17 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> May I have this update reviewed? >> >> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > delete swp file Hi @XueleiFan, good job, this looks like it was onerous work! One issue I noticed, in ADLC only: we sometimes use the snprintf return value to update a position pointer, e.g. in adlc output_c.cpp; should snprintf return -1, we could run backwards and overstep the beginning of the buffer. Totally up to you if you fix it, and whether as a follow-up RFE or here. If you do, the simplest way may be to add a little `stringStream`-like helper like this to ADLC: class AdlcStringStream { char* const _buf; const size_t _buflen; size_t _pos; public: AdlcStringStream(char* out, size_t outlen) : _buf(out), _buflen(outlen), _pos(0) {} void print(const char* fmt, ...) { if (_pos < _buflen) { va_list ap; va_start (ap, fmt); int written = vsnprintf(_buf + _pos, _buflen - _pos, fmt, ap); va_end(ap); if (written > 0) { _pos += written; } } } const char* buf() const { return _buf; } }; and use that instead. Way easier to read the code then. Optionally, the helper could even handle buffer allocation and destruction. All other remarks inline. Small issues remain, but nothing drastic. Cheers, Thomas src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 226: > 224: char buf[512]; > 225: os::snprintf(buf, sizeof(buf), "0x%02x:0x%x:0x%03x:%d", _cpu, _variant, _model, _revision); > 226: if (_model2) os::snprintf(buf+strlen(buf), sizeof(buf) - strlen(buf), "(0x%03x)", _model2); Here - and in several other places, where we construct a string from multiple parts - the code would be a simpler with `stringStream`: char buf[512]; stringStream ss(buf, sizeof(buf)); ss.print("0x%02x:0x%x:0x%03x:%d", _cpu, _variant, _model, _revision); if (_model2) ss.print("(0x%03x)", _model2); _features_string = os::strdup(buf); or, using `stringStream`s internal buffer: stringStream ss; ss.print("0x%02x:0x%x:0x%03x:%d", _cpu, _variant, _model, _revision); if (_model2) ss.print("(0x%03x)", _model2); _features_string = ss.base(); No manual offset counting required. I leave it up to you if you do it that way. The code here is correct as it is. src/hotspot/share/classfile/javaClasses.cpp line 2562: > 2560: CompiledMethod* nm = method->code(); > 2561: if (WizardMode && nm != NULL) { > 2562: os::snprintf(buf + buf_off, buf_size - buf_off, "(nmethod " INTPTR_FORMAT ")", (intptr_t)nm); I think you should update `buf_off` here, because now you overwrite the last text part. Weird that no test caught that. All this code here in javaClasses.cpp would benefit from using stringStream. src/hotspot/share/utilities/utf8.cpp line 521: > 519: } else { > 520: if (p + 6 >= end) break; // string is truncated > 521: os::snprintf(p, 7, "\\u%04x", c); This should be 6, or? We have 6 characters left before end, assuming end is exclusive. Also, maybe use a named constant? src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp line 638: > 636: return; > 637: } > 638: snprintf(channelName, 16, "Ch %d", ch); Can we use a constant here instead of literal 16? ------------- Changes requested by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/11115 From stuefe at openjdk.org Tue Nov 15 08:35:11 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 15 Nov 2022 08:35:11 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v6] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 07:13:49 GMT, Kim Barrett wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> delete swp file > > src/hotspot/os/bsd/attachListener_bsd.cpp line 294: > >> 292: (atoi(buf) != ATTACH_PROTOCOL_VER)) { >> 293: char msg[32]; >> 294: os::snprintf(msg, sizeof(msg), "%d\n", ATTACH_ERROR_BADVERSION); > > Rather than using `strlen(msg)` in the next line, use the result from `os::snprintf`. The problem with using the return value of os::snprintf() is that we need to handle the -1 case to prevent the position from running backward. Might be better to use stringStream instead, which should handle the -1 case transparently. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From jdv at openjdk.org Tue Nov 15 09:02:19 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 15 Nov 2022 09:02:19 GMT Subject: RFR: 8022403: sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java fails In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 07:58:24 GMT, Jayathirth D V wrote: > This test was failing because of color difference on boundaries. Updated test case to not check edges and added color tolerance. > > Also updated test to: > 1) Use standard GraphicsConfiguration bounds for image instead of constant numbers. > 2) Use waitForIdle before screen capture and added auto delay > 3) Move mouse pointer away from rendering content (In my local Mac it failed every time when mouse pointer was present over test frame) > 4) Remove usage of insets as it is undecorated and remove windows closing listener > 5) Dispose frame when test fails > > With these changes test is not failing in CI with multiple runs on all platforms. test/jdk/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java line 31: > 29: * @author Dmitri.Trembovetski at sun.com: area=Graphics > 30: * @run main/othervm OnScreenRenderingResizeTest > 31: * @run main/othervm -Dsun.java2d.d3d=false OnScreenRenderingResizeTest DirectDraw/GDI is default pipeline in Windows(https://docs.oracle.com/javase/10/troubleshoot/java-2d-pipeline-rendering-and-properties.htm#JSTGD428 ) and explicitly mentioning d3d=false should not make any difference that's why i have removed it. But i have verified updated test even with d3d=false and there are no issues. If needed i can update the test to run with d3d=false also. ------------- PR: https://git.openjdk.org/jdk/pull/11158 From aivanov at openjdk.org Tue Nov 15 15:41:55 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 15 Nov 2022 15:41:55 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: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com> Message-ID: On Tue, 15 Nov 2022 06:28:02 GMT, Tejesh R wrote: > Yeah, the only way the retVal can become null would-be if `resolutionVariants` doesn't have an Icon. I could not reproduce the bug since it is intermittent, I came to this conclusion only by code analysis though. Should I check for `resolutionVariants` if its empty and return null without proceeding further......? I guess both the ways `null` will be returned? An MRI that has no images does not make any sense, we should've returned null. There are two usages of the constructor which accepts resolution variants: https://github.com/openjdk/jdk/blob/6c8d0e617ff59eee1313589b10edbf5830774db5/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1185 https://github.com/openjdk/jdk/blob/6c8d0e617ff59eee1313589b10edbf5830774db5/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1112-L1113 There are four usages of the other constructor which accepts an image. Since it's an intermittent problem, we need to add debugging code to the code which creates the `MultiResolutionIconImage` object or handle the exceptional cases in the constructor? by adding an `assert` statement. The tests are run with asserts enabled and we may get more data. Is there a host where the test is more likely to fail? Does it fail on different hosts? Adding the null check to `getResolutionVariant` does not fix the root cause. Instead, it'll make it impossible to find the root cause because everything would look as if no problem exists. ------------- PR: https://git.openjdk.org/jdk/pull/11104 From lucy at openjdk.org Tue Nov 15 16:33:02 2022 From: lucy at openjdk.org (Lutz Schmidt) Date: Tue, 15 Nov 2022 16:33:02 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v4] In-Reply-To: References: Message-ID: <74-iTHarZs4dtXp8dqJEKYrXRw24WAQHrUorBJ4Tmvc=.e2bb3e95-c538-42cb-94a6-6d3378d5bdab@github.com> On Mon, 14 Nov 2022 05:32:20 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> May I have this update reviewed? >> >> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > include missing os head file src/hotspot/share/adlc/output_c.cpp line 536: > 534: int printed = snprintf(args, 37, "0x%x, 0x%x, %u", > 535: resources_used, resources_used_exclusively, element_count); > 536: assert(printed <= 36, "overflow"); if snprintf works correctly (we rely on that), this assert will never fire. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From lucy at openjdk.org Tue Nov 15 16:33:00 2022 From: lucy at openjdk.org (Lutz Schmidt) Date: Tue, 15 Nov 2022 16:33:00 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v6] In-Reply-To: References: Message-ID: <5CbmQLn7JMf11Q_RCVSBYvUiY-TPXV2cFihTq7BbQL0=.b3bb362e-8402-4ec7-91f0-279afaf197f3@github.com> On Mon, 14 Nov 2022 19:44:17 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> May I have this update reviewed? >> >> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > delete swp file With the comments from others honoured, changes look good to me. I found just one, now obsolete, assert which you may want to delete. ------------- Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.org/jdk/pull/11115 From tr at openjdk.org Tue Nov 15 17:06:59 2022 From: tr at openjdk.org (Tejesh R) Date: Tue, 15 Nov 2022 17:06:59 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: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com> Message-ID: <88uZDuov-zTrRsvZPNW2acygSwvozpf4lLWebonK-h0=.1d9cc10e-979c-46f8-bff2-3fce95b5fe0c@github.com> On Tue, 15 Nov 2022 15:39:24 GMT, Alexey Ivanov wrote: > > Yeah, the only way the retVal can become null would-be if `resolutionVariants` doesn't have an Icon. I could not reproduce the bug since it is intermittent, I came to this conclusion only by code analysis though. Should I check for `resolutionVariants` if its empty and return null without proceeding further......? I guess both the ways `null` will be returned? > > An MRI that has no images does not make any sense, we should've returned null. > > There are two usages of the constructor which accepts resolution variants: > > https://github.com/openjdk/jdk/blob/6c8d0e617ff59eee1313589b10edbf5830774db5/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1185 > > > https://github.com/openjdk/jdk/blob/6c8d0e617ff59eee1313589b10edbf5830774db5/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1112-L1113 > > There are four usages of the other constructor which accepts an image. > > Since it's an intermittent problem, we need to add debugging code to the code which creates the `MultiResolutionIconImage` object or handle the exceptional cases in the constructor? by adding an `assert` statement. The tests are run with asserts enabled and we may get more data. > > Is there a host where the test is more likely to fail? Does it fail on different hosts? > > Adding the null check to `getResolutionVariant` does not fix the root cause. Instead, it'll make it impossible to find the root cause because everything would look as if no problem exists. Yeah, agree to your point that it actually mask the actual problem. It fails only when windows L&F is used and `JFileChooser` is instantiated. On creating file chooser instance on windows `getSystemIcon` is called initiates the problem. ------------- PR: https://git.openjdk.org/jdk/pull/11104 From prr at openjdk.org Tue Nov 15 18:00:12 2022 From: prr at openjdk.org (Phil Race) Date: Tue, 15 Nov 2022 18:00:12 GMT Subject: RFR: 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 07:31:46 GMT, Alexander Zuev wrote: > On m1 mac sometimes (in very rare instance) it takes a long time to get the sequencer so increasing timeout helps with that. > Also on m1 mac sequencer got notified about the first MetaMessage twice. The reason is unclear but watching for that fixes the problem. Also on Linux sometimes process hangs indefinitely without finishing hold by the com.sun.media.sound.MediaDispatcher. Closing the sequencer at the end of the test helps with that. test/jdk/javax/sound/midi/Sequencer/MetaCallback.java line 43: > 41: * @summary MIDI MetaMessage callback inconsistent > 42: * @key intermittent sound > 43: * @run main/othervm/timeout=300 MetaCallback "On m1 mac sometimes (in very rare instance) it takes a long time to get the sequencer so increasing timeout helps with that." Hmm. 5 minutes is a really long time for something that should take less than 1 second (getting the sequencer). Is that because something else (perhaps another process) is holding a needed resource ? Are any other tests running ? Or were you running this test in a loop ? Perhaps it is something like what you say happened on Linux where the test wouldn't exit until the sequencer was closed ? Suppose some other process managed to exist without properly releasing some system resource .. and the next app that needed it has to wait until the O/S cleaned up? Is that possible ? Our CI test harness automatically multiplies test timeout by 2 so you've now in effect got a VERY long 10 minute timeout on this test .. way too long I think. test/jdk/javax/sound/midi/Sequencer/MetaCallback.java line 69: > 67: // On M1 Mac sometimes system notifies listener about the same message twice > 68: static List received = Collections.synchronizedList(new ArrayList<>()); > 69: Is this our bug ? test/jdk/javax/sound/midi/Sequencer/MetaCallback.java line 112: > 110: sequencer.stop(); > 111: sequencer.close(); > 112: } I can believe this was a problem. IIRC on x64 mac I had some program block until I closed the sequencer. Can you check other jtreg sound tests for similar potential problems ------------- PR: https://git.openjdk.org/jdk/pull/11157 From prr at openjdk.org Tue Nov 15 18:03:02 2022 From: prr at openjdk.org (Phil Race) Date: Tue, 15 Nov 2022 18:03:02 GMT Subject: RFR: 8022403: sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java fails In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 08:59:23 GMT, Jayathirth D V wrote: >> This test was failing because of color difference on boundaries. Updated test case to not check edges and added color tolerance. >> >> Also updated test to: >> 1) Use standard GraphicsConfiguration bounds for image instead of constant numbers. >> 2) Use waitForIdle before screen capture and added auto delay >> 3) Move mouse pointer away from rendering content (In my local Mac it failed every time when mouse pointer was present over test frame) >> 4) Remove usage of insets as it is undecorated and remove windows closing listener >> 5) Dispose frame when test fails >> >> With these changes test is not failing in CI with multiple runs on all platforms. > > test/jdk/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java line 31: > >> 29: * @author Dmitri.Trembovetski at sun.com: area=Graphics >> 30: * @run main/othervm OnScreenRenderingResizeTest >> 31: * @run main/othervm -Dsun.java2d.d3d=false OnScreenRenderingResizeTest > > DirectDraw/GDI is default pipeline in Windows(https://docs.oracle.com/javase/10/troubleshoot/java-2d-pipeline-rendering-and-properties.htm#JSTGD428 ) and explicitly mentioning d3d=false should not make any difference that's why i have removed it. > > But i have verified updated test even with d3d=false and there are no issues. If needed i can update the test to run with d3d=false also. oh boy that doc is SO out of date. D3D has been the default pipeline since shortly after that doc was written ! It was written for 6 GA and 6u10 made D3D the default. So if you want to be sure to disable it you DO need d3d=false .. ------------- PR: https://git.openjdk.org/jdk/pull/11158 From prr at openjdk.org Tue Nov 15 18:29:12 2022 From: prr at openjdk.org (Phil Race) Date: Tue, 15 Nov 2022 18:29:12 GMT Subject: RFR: 8157173: [macosx] java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java fails [v2] In-Reply-To: <3H6QdSOg-MtRtP1LJe3ZF0M8zTLQJ3PyQ37pp-WBZQw=.41d8b0d7-7869-400d-8b6a-3cc1ef19cf1a@github.com> References: <3H6QdSOg-MtRtP1LJe3ZF0M8zTLQJ3PyQ37pp-WBZQw=.41d8b0d7-7869-400d-8b6a-3cc1ef19cf1a@github.com> Message-ID: On Mon, 14 Nov 2022 14:38:38 GMT, Alexander Zvegintsev wrote: >> This test currently passing as it is on all platforms, but it was problemlisted with ["Problem List some tests that leave windows open on the desktop" reason](https://github.com/openjdk/jdk/commit/fd8df3adf13f5df8f5f95482b8e0a70bc519f39f) >> >> So this test is cleaned up and stabilized. >> >> CI testing looks good. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > Addressing review comments Regarding the test stabilization and functional changes: * wrapped keyRelease, frame.dispose calls with finally * increased delay after frame appearance * increased AutoDelay OK .. these seem worthwhile. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.org/jdk/pull/11128 From kizune at openjdk.org Tue Nov 15 19:14:14 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 15 Nov 2022 19:14:14 GMT Subject: RFR: 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 17:55:17 GMT, Phil Race wrote: > Hmm. 5 minutes is a really long time for something that should take less than 1 second (getting the sequencer). Is that because something else (perhaps another process) is holding a needed resource ? I tried to find reasons or any kind of patterns by simulating different scenarios like external applications using/holding the audio line, running other sound or midi tests in parallel, switching audio devices during the test execution - and i haven't found a way of stable reproduction or any kind of regularity in test behavior. The only thing i found out is that once test passes the normal way it never fails until system is restarted or wakes up from sleep. The only thing i can say that i had cases when a singular run of the test after the restart demonstrated this problem so it is not a resource locked by another Java instance - there are no other java processes in the system at this point. Which makes me believe that the problem is not on our side and i do not think we can do anything to circumvent the issue on our side. I will continue investigation on the OS side though. > Our CI test harness automatically multiplies test timeout by 2 so you've now in effect got a VERY long 10 minute timeout on this test .. way too long I think. Yikes! Yes, 5 minutes is already long enough for this test, multiplying it by two makes it unreasonably long in case when it is properly hangs. I will replace the limit to 120 which makes two minutes timeout on non-multiplied system and somewhat reasonable 4 minutes on CI. ------------- PR: https://git.openjdk.org/jdk/pull/11157 From kizune at openjdk.org Tue Nov 15 19:19:01 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 15 Nov 2022 19:19:01 GMT Subject: RFR: 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 17:55:40 GMT, Phil Race wrote: > Is this our bug ? Unlikely - it happens on one platform only, looks more like for some reason system restarts the midi stream after first message. But i can not be sure because i only saw it on the CI system once in more than a thousand runs, i was never able to reproduce that exact problem locally no matter how many runs i did. Analyzing the failures from the bug i see it reported twice and both times (and in my failure) it was a first message got repeated. ------------- PR: https://git.openjdk.org/jdk/pull/11157 From kizune at openjdk.org Tue Nov 15 19:30:00 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 15 Nov 2022 19:30:00 GMT Subject: RFR: 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 17:57:13 GMT, Phil Race wrote: > Can you check other jtreg sound tests for similar potential problems Sure, i will check and if i find something i will create a separate bug listing all the cases where it might be a problem. ------------- PR: https://git.openjdk.org/jdk/pull/11157 From kizune at openjdk.org Tue Nov 15 20:04:07 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 15 Nov 2022 20:04:07 GMT Subject: RFR: 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout [v2] In-Reply-To: References: Message-ID: > On m1 mac sometimes (in very rare instance) it takes a long time to get the sequencer so increasing timeout helps with that. > Also on m1 mac sequencer got notified about the first MetaMessage twice. The reason is unclear but watching for that fixes the problem. Also on Linux sometimes process hangs indefinitely without finishing hold by the com.sun.media.sound.MediaDispatcher. Closing the sequencer at the end of the test helps with that. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Lower the timeout to 120 seconds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11157/files - new: https://git.openjdk.org/jdk/pull/11157/files/96d9754f..496e1eb5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11157&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11157&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11157.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11157/head:pull/11157 PR: https://git.openjdk.org/jdk/pull/11157 From achung at openjdk.org Tue Nov 15 20:38:20 2022 From: achung at openjdk.org (Alisen Chung) Date: Tue, 15 Nov 2022 20:38:20 GMT Subject: RFR: 8295369: Update LCMS to 2.14 [v5] In-Reply-To: References: Message-ID: > Updating LCMS to newest release Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: change tab to spaces ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11000/files - new: https://git.openjdk.org/jdk/pull/11000/files/5141ed55..18c7efd3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11000&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11000&range=03-04 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/11000.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11000/head:pull/11000 PR: https://git.openjdk.org/jdk/pull/11000 From prr at openjdk.org Tue Nov 15 21:17:03 2022 From: prr at openjdk.org (Phil Race) Date: Tue, 15 Nov 2022 21:17:03 GMT Subject: RFR: 8295369: Update LCMS to 2.14 [v5] In-Reply-To: References: Message-ID: <-yBwCv86ra0nO99oCrWhK7YQCg4QyhE-OaXBYAlK9E4=.b529a419-5404-41b5-89bc-a46a4912a763@github.com> On Tue, 15 Nov 2022 20:38:20 GMT, Alisen Chung wrote: >> Updating LCMS to newest release > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > change tab to spaces Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11000 From prr at openjdk.org Tue Nov 15 21:19:10 2022 From: prr at openjdk.org (Phil Race) Date: Tue, 15 Nov 2022 21:19:10 GMT Subject: RFR: 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout [v2] In-Reply-To: References: Message-ID: <-0vmIxmxrWBvplQF8-z10KMgdsKcnsoBXyXClbycOBs=.40ad5e03-25f5-4f88-9b44-cde2b2cc5fd3@github.com> On Tue, 15 Nov 2022 20:04:07 GMT, Alexander Zuev wrote: >> On m1 mac sometimes (in very rare instance) it takes a long time to get the sequencer so increasing timeout helps with that. >> Also on m1 mac sequencer got notified about the first MetaMessage twice. The reason is unclear but watching for that fixes the problem. Also on Linux sometimes process hangs indefinitely without finishing hold by the com.sun.media.sound.MediaDispatcher. Closing the sequencer at the end of the test helps with that. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Lower the timeout to 120 seconds FWIW 120 is the default .. so that isn't a difference, but 240 seconds in CI is long enough And I suspect that Sequencer.close() is going to help. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.org/jdk/pull/11157 From honkar at openjdk.org Tue Nov 15 21:23:02 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 15 Nov 2022 21:23:02 GMT Subject: RFR: 8295369: Update LCMS to 2.14 [v5] In-Reply-To: References: Message-ID: <_GqTPx2Am0C4Arbem_xP3rIkQG7PhqcC-S0RbLCzAhM=.8f226f1e-b07f-4851-a1b2-9f6e601aa9db@github.com> On Tue, 15 Nov 2022 20:38:20 GMT, Alisen Chung wrote: >> Updating LCMS to newest release > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > change tab to spaces test/jdk/java/awt/Mouse/EnterExitEvents/DragWindowTest.java this file has been added to the PR by mistake ? ------------- PR: https://git.openjdk.org/jdk/pull/11000 From achung at openjdk.org Tue Nov 15 21:27:51 2022 From: achung at openjdk.org (Alisen Chung) Date: Tue, 15 Nov 2022 21:27:51 GMT Subject: RFR: 8295369: Update LCMS to 2.14 [v6] In-Reply-To: References: Message-ID: > Updating LCMS to newest release Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: removed accidentally added test change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11000/files - new: https://git.openjdk.org/jdk/pull/11000/files/18c7efd3..3bcd63cf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11000&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11000&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11000.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11000/head:pull/11000 PR: https://git.openjdk.org/jdk/pull/11000 From achung at openjdk.org Tue Nov 15 21:37:22 2022 From: achung at openjdk.org (Alisen Chung) Date: Tue, 15 Nov 2022 21:37:22 GMT Subject: RFR: 8295369: Update LCMS to 2.14 [v7] In-Reply-To: References: Message-ID: <8tMEK5zbbZib9Zh2lhHWL6oQCu3JJGn6eMsl6z62gTs=.527dddd3-c9d0-4877-97ee-eb4568928a36@github.com> > Updating LCMS to newest release Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: fixed license for cmscgats.c file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11000/files - new: https://git.openjdk.org/jdk/pull/11000/files/3bcd63cf..11e90452 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11000&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11000&range=05-06 Stats: 29 lines in 1 file changed: 29 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11000.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11000/head:pull/11000 PR: https://git.openjdk.org/jdk/pull/11000 From prr at openjdk.org Tue Nov 15 21:41:55 2022 From: prr at openjdk.org (Phil Race) Date: Tue, 15 Nov 2022 21:41:55 GMT Subject: RFR: 8295369: Update LCMS to 2.14 [v7] In-Reply-To: <8tMEK5zbbZib9Zh2lhHWL6oQCu3JJGn6eMsl6z62gTs=.527dddd3-c9d0-4877-97ee-eb4568928a36@github.com> References: <8tMEK5zbbZib9Zh2lhHWL6oQCu3JJGn6eMsl6z62gTs=.527dddd3-c9d0-4877-97ee-eb4568928a36@github.com> Message-ID: On Tue, 15 Nov 2022 21:37:22 GMT, Alisen Chung wrote: >> Updating LCMS to newest release > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > fixed license for cmscgats.c file Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11000 From honkar at openjdk.org Tue Nov 15 21:49:12 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 15 Nov 2022 21:49:12 GMT Subject: RFR: 8295369: Update LCMS to 2.14 [v7] In-Reply-To: <8tMEK5zbbZib9Zh2lhHWL6oQCu3JJGn6eMsl6z62gTs=.527dddd3-c9d0-4877-97ee-eb4568928a36@github.com> References: <8tMEK5zbbZib9Zh2lhHWL6oQCu3JJGn6eMsl6z62gTs=.527dddd3-c9d0-4877-97ee-eb4568928a36@github.com> Message-ID: On Tue, 15 Nov 2022 21:37:22 GMT, Alisen Chung wrote: >> Updating LCMS to newest release > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > fixed license for cmscgats.c file Marked as reviewed by honkar (Author). ------------- PR: https://git.openjdk.org/jdk/pull/11000 From achung at openjdk.org Tue Nov 15 22:17:14 2022 From: achung at openjdk.org (Alisen Chung) Date: Tue, 15 Nov 2022 22:17:14 GMT Subject: Integrated: 8295369: Update LCMS to 2.14 In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 22:44:11 GMT, Alisen Chung wrote: > Updating LCMS to newest release This pull request has now been integrated. Changeset: 6a60d318 Author: Alisen Chung URL: https://git.openjdk.org/jdk/commit/6a60d318b64d7f478d0d43dd1362cd27894a09dc Stats: 2137 lines in 31 files changed: 1546 ins; 134 del; 457 mod 8295369: Update LCMS to 2.14 Reviewed-by: honkar, prr ------------- PR: https://git.openjdk.org/jdk/pull/11000 From dholmes at openjdk.org Tue Nov 15 22:59:29 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 15 Nov 2022 22:59:29 GMT Subject: RFR: 8297089: [BACKOUT] JDK-8297088 Update LCMS to 2.14 In-Reply-To: <541DkZ8hx2zjZIGLKUpIX91smxvMvsr5RV5wW5vSmrA=.5612a697-7546-4d40-b331-263ed5417af4@github.com> References: <541DkZ8hx2zjZIGLKUpIX91smxvMvsr5RV5wW5vSmrA=.5612a697-7546-4d40-b331-263ed5417af4@github.com> Message-ID: On Tue, 15 Nov 2022 22:45:59 GMT, Daniel D. Daugherty wrote: > This reverts commit 6a60d318b64d7f478d0d43dd1362cd27894a09dc. Thanks for handling this Dan. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11176 From dcubed at openjdk.org Tue Nov 15 22:59:30 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 15 Nov 2022 22:59:30 GMT Subject: RFR: 8297089: [BACKOUT] JDK-8297088 Update LCMS to 2.14 In-Reply-To: References: <541DkZ8hx2zjZIGLKUpIX91smxvMvsr5RV5wW5vSmrA=.5612a697-7546-4d40-b331-263ed5417af4@github.com> Message-ID: On Tue, 15 Nov 2022 22:55:05 GMT, David Holmes wrote: >> This reverts commit 6a60d318b64d7f478d0d43dd1362cd27894a09dc. > > Thanks for handling this Dan. @dholmes-ora - Thanks for the fast review. I'm waiting for my Mach5 Tier1 linux builds to pass... ------------- PR: https://git.openjdk.org/jdk/pull/11176 From dcubed at openjdk.org Tue Nov 15 23:06:11 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 15 Nov 2022 23:06:11 GMT Subject: Integrated: 8297089: [BACKOUT] JDK-8297088 Update LCMS to 2.14 In-Reply-To: <541DkZ8hx2zjZIGLKUpIX91smxvMvsr5RV5wW5vSmrA=.5612a697-7546-4d40-b331-263ed5417af4@github.com> References: <541DkZ8hx2zjZIGLKUpIX91smxvMvsr5RV5wW5vSmrA=.5612a697-7546-4d40-b331-263ed5417af4@github.com> Message-ID: <-f-QPbqs4wPa451eWUkojAU23q69RThjTuFNz5uLpR4=.6fbb37d0-042d-4f9a-ba2b-05408ad1aac2@github.com> On Tue, 15 Nov 2022 22:45:59 GMT, Daniel D. Daugherty wrote: > This reverts commit 6a60d318b64d7f478d0d43dd1362cd27894a09dc. This pull request has now been integrated. Changeset: bd3acbea Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/bd3acbea8c4ac0a9d3827a59bd736f0528b1b12b Stats: 2131 lines in 31 files changed: 128 ins; 1540 del; 463 mod 8297089: [BACKOUT] JDK-8297088 Update LCMS to 2.14 Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/11176 From prr at openjdk.org Tue Nov 15 23:10:50 2022 From: prr at openjdk.org (Phil Race) Date: Tue, 15 Nov 2022 23:10:50 GMT Subject: RFR: 8297089: [BACKOUT] JDK-8297088 Update LCMS to 2.14 In-Reply-To: <541DkZ8hx2zjZIGLKUpIX91smxvMvsr5RV5wW5vSmrA=.5612a697-7546-4d40-b331-263ed5417af4@github.com> References: <541DkZ8hx2zjZIGLKUpIX91smxvMvsr5RV5wW5vSmrA=.5612a697-7546-4d40-b331-263ed5417af4@github.com> Message-ID: <8TCPlvikeMxGw6vtvKl-SJ3bRlPz_JkRje8b2jkyf3U=.a3d03430-f214-4949-9048-82b8ad376649@github.com> On Tue, 15 Nov 2022 22:45:59 GMT, Daniel D. Daugherty wrote: > This reverts commit 6a60d318b64d7f478d0d43dd1362cd27894a09dc. No don't back it out There's a one line build fix. aah too late It looks like another PR removed a disabled warning that was needed by this PR ------------- PR: https://git.openjdk.org/jdk/pull/11176 From prr at openjdk.org Tue Nov 15 23:20:17 2022 From: prr at openjdk.org (Phil Race) Date: Tue, 15 Nov 2022 23:20:17 GMT Subject: RFR: 8297089: [BACKOUT] JDK-8297088 Update LCMS to 2.14 In-Reply-To: <541DkZ8hx2zjZIGLKUpIX91smxvMvsr5RV5wW5vSmrA=.5612a697-7546-4d40-b331-263ed5417af4@github.com> References: <541DkZ8hx2zjZIGLKUpIX91smxvMvsr5RV5wW5vSmrA=.5612a697-7546-4d40-b331-263ed5417af4@github.com> Message-ID: On Tue, 15 Nov 2022 22:45:59 GMT, Daniel D. Daugherty wrote: > This reverts commit 6a60d318b64d7f478d0d43dd1362cd27894a09dc. all academic now since this was pushed ------------- PR: https://git.openjdk.org/jdk/pull/11176 From jdv at openjdk.org Wed Nov 16 03:31:50 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 16 Nov 2022 03:31:50 GMT Subject: RFR: 8022403: sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java fails [v2] In-Reply-To: References: Message-ID: > This test was failing because of color difference on boundaries. Updated test case to not check edges and added color tolerance. > > Also updated test to: > 1) Use standard GraphicsConfiguration bounds for image instead of constant numbers. > 2) Use waitForIdle before screen capture and added auto delay > 3) Move mouse pointer away from rendering content (In my local Mac it failed every time when mouse pointer was present over test frame) > 4) Remove usage of insets as it is undecorated and remove windows closing listener > 5) Dispose frame when test fails > > With these changes test is not failing in CI with multiple runs on all platforms. Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: Enable DirectDraw/GDI test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11158/files - new: https://git.openjdk.org/jdk/pull/11158/files/d268397d..ad75b5f1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11158&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11158&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11158.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11158/head:pull/11158 PR: https://git.openjdk.org/jdk/pull/11158 From jdv at openjdk.org Wed Nov 16 03:44:16 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 16 Nov 2022 03:44:16 GMT Subject: RFR: 8022403: sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java fails [v2] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 18:00:26 GMT, Phil Race wrote: >> test/jdk/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java line 31: >> >>> 29: * @author Dmitri.Trembovetski at sun.com: area=Graphics >>> 30: * @run main/othervm OnScreenRenderingResizeTest >>> 31: * @run main/othervm -Dsun.java2d.d3d=false OnScreenRenderingResizeTest >> >> DirectDraw/GDI is default pipeline in Windows(https://docs.oracle.com/javase/10/troubleshoot/java-2d-pipeline-rendering-and-properties.htm#JSTGD428 ) and explicitly mentioning d3d=false should not make any difference that's why i have removed it. >> >> But i have verified updated test even with d3d=false and there are no issues. If needed i can update the test to run with d3d=false also. > > oh boy that doc is SO out of date. > D3D has been the default pipeline since shortly after that doc was written ! > It was written for 6 GA and 6u10 made D3D the default. > So if you want to be sure to disable it you DO need d3d=false .. Hi Phil, I was also not sure about it and tested with d3d=false, thanks for the clarification. I have re-enabled DirectDraw/GDI run. Even the Java SE 19 doc says DirectDraw/GDI is default on Windows : https://docs.oracle.com/en/java/javase/19/troubleshoot/java-2d-pipeline-rendering-and-properties.html#GUID-AAB8CC86-652B-4A78-83EB-CDC3F5677A48. Thanks, Jay ------------- PR: https://git.openjdk.org/jdk/pull/11158 From prr at openjdk.org Wed Nov 16 03:56:11 2022 From: prr at openjdk.org (Phil Race) Date: Wed, 16 Nov 2022 03:56:11 GMT Subject: RFR: 8022403: sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java fails [v2] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 03:31:50 GMT, Jayathirth D V wrote: >> This test was failing because of color difference on boundaries. Updated test case to not check edges and added color tolerance. >> >> Also updated test to: >> 1) Use standard GraphicsConfiguration bounds for image instead of constant numbers. >> 2) Use waitForIdle before screen capture and added auto delay >> 3) Move mouse pointer away from rendering content (In my local Mac it failed every time when mouse pointer was present over test frame) >> 4) Remove usage of insets as it is undecorated and remove windows closing listener >> 5) Dispose frame when test fails >> >> With these changes test is not failing in CI with multiple runs on all platforms. > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Enable DirectDraw/GDI test test/jdk/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java line 79: > 77: } > 78: } > 79: frame = new Frame(); Could we perhaps do this on the AWT EDT ? ------------- PR: https://git.openjdk.org/jdk/pull/11158 From prr at openjdk.org Wed Nov 16 03:53:01 2022 From: prr at openjdk.org (Phil Race) Date: Wed, 16 Nov 2022 03:53:01 GMT Subject: RFR: 8282404: DrawStringWithInfiniteXform.java failed with "RuntimeException: drawString with InfiniteXform transform takes long time" Message-ID: This test is not problem listed and has failed only once since (SFAIK) it was last updated a year ago so this is just another small attempt to remove instability by increasing timeout, being really insistent about making sure the "done=true" is propagated and adding some extra timing logging to help analyse any failures ------------- Commit messages: - 8282404 Changes: https://git.openjdk.org/jdk/pull/11179/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11179&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8282404 Stats: 24 lines in 1 file changed: 12 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/11179.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11179/head:pull/11179 PR: https://git.openjdk.org/jdk/pull/11179 From psadhukhan at openjdk.org Wed Nov 16 04:10:55 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 16 Nov 2022 04:10:55 GMT Subject: RFR: 8022403: sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java fails [v2] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 03:31:50 GMT, Jayathirth D V wrote: >> This test was failing because of color difference on boundaries. Updated test case to not check edges and added color tolerance. >> >> Also updated test to: >> 1) Use standard GraphicsConfiguration bounds for image instead of constant numbers. >> 2) Use waitForIdle before screen capture and added auto delay >> 3) Move mouse pointer away from rendering content (In my local Mac it failed every time when mouse pointer was present over test frame) >> 4) Remove usage of insets as it is undecorated and remove windows closing listener >> 5) Dispose frame when test fails >> >> With these changes test is not failing in CI with multiple runs on all platforms. > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Enable DirectDraw/GDI test test/jdk/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java line 126: > 124: robot.mouseMove(0,0); > 125: } catch (AWTException ex) { > 126: System.err.println("Robot creation failed, continuing."); Not sure if we should continue here as createScreenCapture is being used down below which would result in NPE Also this try-block is for creation so I think setAutoDelay and mouseMove needs to be moved out of this block.. Also, better to use try-finally block to do frame.dispose() ------------- PR: https://git.openjdk.org/jdk/pull/11158 From psadhukhan at openjdk.org Wed Nov 16 04:14:56 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 16 Nov 2022 04:14:56 GMT Subject: RFR: 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout [v2] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 20:04:07 GMT, Alexander Zuev wrote: >> On m1 mac sometimes (in very rare instance) it takes a long time to get the sequencer so increasing timeout helps with that. >> Also on m1 mac sequencer got notified about the first MetaMessage twice. The reason is unclear but watching for that fixes the problem. Also on Linux sometimes process hangs indefinitely without finishing hold by the com.sun.media.sound.MediaDispatcher. Closing the sequencer at the end of the test helps with that. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Lower the timeout to 120 seconds test/jdk/javax/sound/midi/Sequencer/MetaCallback.java line 2: > 1: /* > 2: * Copyright (c) 2003, 2023, Oracle and/or its affiliates. All rights reserved. futuristic year? or you didnt have confidence that this test will be integrated this year :-) ------------- PR: https://git.openjdk.org/jdk/pull/11157 From psadhukhan at openjdk.org Wed Nov 16 04:25:57 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 16 Nov 2022 04:25:57 GMT Subject: RFR: 8282404: DrawStringWithInfiniteXform.java failed with "RuntimeException: drawString with InfiniteXform transform takes long time" In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 03:44:24 GMT, Phil Race wrote: > This test is not problem listed and has failed only once since (SFAIK) it was last updated a year ago so > this is just another small attempt to remove instability by increasing timeout, being really insistent about > making sure the "done=true" is propagated and adding some extra timing logging to help analyse any failures test/jdk/java/awt/FontClass/DrawStringWithInfiniteXform.java line 90: > 88: timer.cancel(); > 89: } > 90: System.out.println("Test passed"); It seems timer.cancel() says "Terminates this timer, discarding any currently scheduled tasks." so it might disregard the "done" check been done in ScheduleTask resulting in false positive... Should we do Thread.yield() instead? Also, this test has many coding violations like l70, l79 where no space between operators,variables... ------------- PR: https://git.openjdk.org/jdk/pull/11179 From kbarrett at openjdk.org Wed Nov 16 04:58:19 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 16 Nov 2022 04:58:19 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v6] In-Reply-To: References: Message-ID: <2Ja9uaGY95zatV-viOoTkNbakqLkWuCDn761HztySZU=.f42b4b8a-2be1-41b1-98c0-12f953e6a88b@github.com> On Tue, 15 Nov 2022 08:31:10 GMT, Thomas Stuefe wrote: >> src/hotspot/os/bsd/attachListener_bsd.cpp line 294: >> >>> 292: (atoi(buf) != ATTACH_PROTOCOL_VER)) { >>> 293: char msg[32]; >>> 294: os::snprintf(msg, sizeof(msg), "%d\n", ATTACH_ERROR_BADVERSION); >> >> Rather than using `strlen(msg)` in the next line, use the result from `os::snprintf`. > > The problem with using the return value of os::snprintf() is that we need to handle the -1 case to prevent the position from running backward. Might be better to use stringStream instead, which should handle the -1 case transparently. A result of -1 only occurs for an encoding error. An encoding error is only possible with multi-byte / wide characters. (See the definition of "encoding error" in C99 7.19.3/14.) We don't use those, so there won't be any encoding errors, so our uses of snprintf never return -1. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From psadhukhan at openjdk.org Wed Nov 16 05:05:53 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 16 Nov 2022 05:05:53 GMT Subject: RFR: 8296083: javax/swing/JTree/6263446/bug6263446.java fails intermittently on a VM [v2] In-Reply-To: References: Message-ID: <4e4V65QoBHCWpqnQgOn0lPjkvo9NiCzA4HyEmzdYHt8=.cb8da185-d421-48da-baa9-96889c294f1b@github.com> On Mon, 14 Nov 2022 06:56:20 GMT, Prasanta Sadhukhan wrote: >> Test intermittently fails in VM citing "Tree is not editing". Seems to be problem with mouse clicks not getting registered properly.. >> Similar test test/jdk/javax/swing/JTable/6263446/bug6263446.java is not affected, so made the test similar to it by using same safeguard using Robot.waitForIdle() and modifying clickpoint to tree cell midpoint. >> >> Several iterations of the test pass in the OCI VM and all other physical platforms (link in JBS) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test update Just to reiterate, I am not sure why it is failing in OCI systems as I am not able to reproduce in OCI...one time I reproduce it is bcoz of screen lock...So I added this stability checks and made it similar to JTable/6263446.java which results it in passing in OCI in several CI jobs that I gave (link in JBS)...I think we should probably give this stability fixes it a try ------------- PR: https://git.openjdk.org/jdk/pull/11057 From jdv at openjdk.org Wed Nov 16 05:16:02 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 16 Nov 2022 05:16:02 GMT Subject: RFR: 8022403: sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java fails [v3] In-Reply-To: References: Message-ID: > This test was failing because of color difference on boundaries. Updated test case to not check edges and added color tolerance. > > Also updated test to: > 1) Use standard GraphicsConfiguration bounds for image instead of constant numbers. > 2) Use waitForIdle before screen capture and added auto delay > 3) Move mouse pointer away from rendering content (In my local Mac it failed every time when mouse pointer was present over test frame) > 4) Remove usage of insets as it is undecorated and remove windows closing listener > 5) Dispose frame when test fails > > With these changes test is not failing in CI with multiple runs on all platforms. Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: Use EDT for creation of frame and dispose frame in finally block ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11158/files - new: https://git.openjdk.org/jdk/pull/11158/files/ad75b5f1..283685d7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11158&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11158&range=01-02 Stats: 124 lines in 1 file changed: 32 ins; 26 del; 66 mod Patch: https://git.openjdk.org/jdk/pull/11158.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11158/head:pull/11158 PR: https://git.openjdk.org/jdk/pull/11158 From jdv at openjdk.org Wed Nov 16 05:16:03 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 16 Nov 2022 05:16:03 GMT Subject: RFR: 8022403: sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java fails [v2] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 03:52:12 GMT, Phil Race wrote: >> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: >> >> Enable DirectDraw/GDI test > > test/jdk/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java line 79: > >> 77: } >> 78: } >> 79: frame = new Frame(); > > Could we perhaps do this on the AWT EDT ? I was under the impression that keeping setVisible() in EDT should suffice. I have moved both creation of frame and setVisible() to EDT. ------------- PR: https://git.openjdk.org/jdk/pull/11158 From jdv at openjdk.org Wed Nov 16 05:20:59 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 16 Nov 2022 05:20:59 GMT Subject: RFR: 8022403: sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java fails [v2] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 04:08:44 GMT, Prasanta Sadhukhan wrote: >> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: >> >> Enable DirectDraw/GDI test > > test/jdk/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java line 126: > >> 124: robot.mouseMove(0,0); >> 125: } catch (AWTException ex) { >> 126: System.err.println("Robot creation failed, continuing."); > > Not sure if we should continue here as createScreenCapture is being used down below which would result in NPE > Also this try-block is for creation so I think setAutoDelay and mouseMove needs to be moved out of this block.. > Also, better to use try-finally block to do frame.dispose() We will not throw NPE if robot is null. Because we have null check for robot when we want to use it. This test was originally written to check for crash after producing artifacts, thats why i think we continue to drawImage onto resizing frame even if Robot fails. So its better if we keep it that way. Also initially i used mouseMove() before we do screen capture, but this was causing considerably lag in drawing on my local mac machine. So i have kept it in initialization logic and i can see that mouse moves to (0, 0) and stays there until the test is completed. Next operation we do after this mouseMove is screenCapture. So keeping autodelay here or later should not matter. I have moved whole logic under try block and disposing frame under finally block. ------------- PR: https://git.openjdk.org/jdk/pull/11158 From prr at openjdk.org Wed Nov 16 05:29:04 2022 From: prr at openjdk.org (Phil Race) Date: Wed, 16 Nov 2022 05:29:04 GMT Subject: RFR: 8022403: sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java fails [v3] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 05:16:02 GMT, Jayathirth D V wrote: >> This test was failing because of color difference on boundaries. Updated test case to not check edges and added color tolerance. >> >> Also updated test to: >> 1) Use standard GraphicsConfiguration bounds for image instead of constant numbers. >> 2) Use waitForIdle before screen capture and added auto delay >> 3) Move mouse pointer away from rendering content (In my local Mac it failed every time when mouse pointer was present over test frame) >> 4) Remove usage of insets as it is undecorated and remove windows closing listener >> 5) Dispose frame when test fails >> >> With these changes test is not failing in CI with multiple runs on all platforms. > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Use EDT for creation of frame and dispose frame in finally block Marked as reviewed by prr (Reviewer). test/jdk/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java line 95: > 93: } > 94: }); > 95: // wait for Vista's effects to complete I wonder what this (obsolete?) comment was about - please delete, and I'm not sure what waiting there is. ------------- PR: https://git.openjdk.org/jdk/pull/11158 From kizune at openjdk.org Wed Nov 16 05:37:15 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 16 Nov 2022 05:37:15 GMT Subject: RFR: 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout [v3] In-Reply-To: References: Message-ID: <3W-OC_EeYya8hQKeGwfpAnBUylk18dq1c4CP5fSKkyw=.e86a1209-7c2a-4330-a40d-85812a829f82@github.com> > On m1 mac sometimes (in very rare instance) it takes a long time to get the sequencer so increasing timeout helps with that. > Also on m1 mac sequencer got notified about the first MetaMessage twice. The reason is unclear but watching for that fixes the problem. Also on Linux sometimes process hangs indefinitely without finishing hold by the com.sun.media.sound.MediaDispatcher. Closing the sequencer at the end of the test helps with that. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Fixed typo in copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11157/files - new: https://git.openjdk.org/jdk/pull/11157/files/496e1eb5..791065fb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11157&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11157&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11157.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11157/head:pull/11157 PR: https://git.openjdk.org/jdk/pull/11157 From jdv at openjdk.org Wed Nov 16 05:37:19 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 16 Nov 2022 05:37:19 GMT Subject: RFR: 8022403: sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java fails [v4] In-Reply-To: References: Message-ID: > This test was failing because of color difference on boundaries. Updated test case to not check edges and added color tolerance. > > Also updated test to: > 1) Use standard GraphicsConfiguration bounds for image instead of constant numbers. > 2) Use waitForIdle before screen capture and added auto delay > 3) Move mouse pointer away from rendering content (In my local Mac it failed every time when mouse pointer was present over test frame) > 4) Remove usage of insets as it is undecorated and remove windows closing listener > 5) Dispose frame when test fails > > With these changes test is not failing in CI with multiple runs on all platforms. Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: Remove comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11158/files - new: https://git.openjdk.org/jdk/pull/11158/files/283685d7..3065edba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11158&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11158&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11158.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11158/head:pull/11158 PR: https://git.openjdk.org/jdk/pull/11158 From kizune at openjdk.org Wed Nov 16 05:37:15 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 16 Nov 2022 05:37:15 GMT Subject: RFR: 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout [v2] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 04:11:21 GMT, Prasanta Sadhukhan wrote: > futuristic year? or you didnt have confidence that this test will be integrated this year :-) Is this still 2022? I guess i just wish this year is over already. Will fix that though. ------------- PR: https://git.openjdk.org/jdk/pull/11157 From psadhukhan at openjdk.org Wed Nov 16 05:37:20 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 16 Nov 2022 05:37:20 GMT Subject: RFR: 8022403: sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java fails [v2] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 05:18:28 GMT, Jayathirth D V wrote: >> test/jdk/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java line 126: >> >>> 124: robot.mouseMove(0,0); >>> 125: } catch (AWTException ex) { >>> 126: System.err.println("Robot creation failed, continuing."); >> >> Not sure if we should continue here as createScreenCapture is being used down below which would result in NPE >> Also this try-block is for creation so I think setAutoDelay and mouseMove needs to be moved out of this block.. >> Also, better to use try-finally block to do frame.dispose() > > We will not throw NPE if robot is null. Because we have null check for robot when we want to use it. > This test was originally written to check for crash after producing artifacts, thats why i think we continue to drawImage onto resizing frame even if Robot fails. So its better if we keep it that way. > > Also initially i used mouseMove() before we do screen capture, but this was causing considerably lag in drawing on my local mac machine. So i have kept it in initialization logic and i can see that mouse moves to (0, 0) and stays there until the test is completed. Next operation we do after this mouseMove is screenCapture. So keeping autodelay here or later should not matter. > > I have moved whole logic under try block and disposing frame under finally block. SInce some coordinates are changed, can you please confirm the test can be used still to confirm JDK-6664068 meaning it fails before the fix and pass with it? ------------- PR: https://git.openjdk.org/jdk/pull/11158 From jdv at openjdk.org Wed Nov 16 06:42:01 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 16 Nov 2022 06:42:01 GMT Subject: RFR: 8022403: sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java fails [v2] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 05:33:26 GMT, Prasanta Sadhukhan wrote: >> We will not throw NPE if robot is null. Because we have null check for robot when we want to use it. >> This test was originally written to check for crash after producing artifacts, thats why i think we continue to drawImage onto resizing frame even if Robot fails. So its better if we keep it that way. >> >> Also initially i used mouseMove() before we do screen capture, but this was causing considerably lag in drawing on my local mac machine. So i have kept it in initialization logic and i can see that mouse moves to (0, 0) and stays there until the test is completed. Next operation we do after this mouseMove is screenCapture. So keeping autodelay here or later should not matter. >> >> I have moved whole logic under try block and disposing frame under finally block. > > SInce some coordinates are changed, can you please confirm the test can be used still to confirm JDK-6664068 meaning it fails before the fix and pass with it? I have changed the frame/image coordinates to use bounds from screen coordinates instead of using constants (128,128) for BufferedImage and (512,512) for VolatileImage, it doesn't change the way the test works. ------------- PR: https://git.openjdk.org/jdk/pull/11158 From psadhukhan at openjdk.org Wed Nov 16 06:48:02 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 16 Nov 2022 06:48:02 GMT Subject: RFR: 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout [v3] In-Reply-To: <3W-OC_EeYya8hQKeGwfpAnBUylk18dq1c4CP5fSKkyw=.e86a1209-7c2a-4330-a40d-85812a829f82@github.com> References: <3W-OC_EeYya8hQKeGwfpAnBUylk18dq1c4CP5fSKkyw=.e86a1209-7c2a-4330-a40d-85812a829f82@github.com> Message-ID: <-38WA-JoLOxToMxxTck2FCETqVKkzmuKyFk68GEBZQM=.e231d4d0-dfc3-4d5e-9f58-32428cff6f1b@github.com> On Wed, 16 Nov 2022 05:37:15 GMT, Alexander Zuev wrote: >> On m1 mac sometimes (in very rare instance) it takes a long time to get the sequencer so increasing timeout helps with that. >> Also on m1 mac sequencer got notified about the first MetaMessage twice. The reason is unclear but watching for that fixes the problem. Also on Linux sometimes process hangs indefinitely without finishing hold by the com.sun.media.sound.MediaDispatcher. Closing the sequencer at the end of the test helps with that. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Fixed typo in copyright year test/jdk/javax/sound/midi/Sequencer/MetaCallback.java line 119: > 117: finished = true; > 118: } else if (msg.getData().length > 0 && msg.getType() == 1 && !received.contains(msg)) { > 119: received.add(msg); Do we not need to do seq.stop() before close() in l136 ------------- PR: https://git.openjdk.org/jdk/pull/11157 From psadhukhan at openjdk.org Wed Nov 16 07:02:00 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 16 Nov 2022 07:02:00 GMT Subject: RFR: 8022403: sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java fails [v4] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 05:37:19 GMT, Jayathirth D V wrote: >> This test was failing because of color difference on boundaries. Updated test case to not check edges and added color tolerance. >> >> Also updated test to: >> 1) Use standard GraphicsConfiguration bounds for image instead of constant numbers. >> 2) Use waitForIdle before screen capture and added auto delay >> 3) Move mouse pointer away from rendering content (In my local Mac it failed every time when mouse pointer was present over test frame) >> 4) Remove usage of insets as it is undecorated and remove windows closing listener >> 5) Dispose frame when test fails >> >> With these changes test is not failing in CI with multiple runs on all platforms. > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Remove comment ok ------------- Marked as reviewed by psadhukhan (Reviewer). PR: https://git.openjdk.org/jdk/pull/11158 From xuelei at openjdk.org Wed Nov 16 07:03:12 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 16 Nov 2022 07:03:12 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v7] In-Reply-To: References: Message-ID: > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11115/files - new: https://git.openjdk.org/jdk/pull/11115/files/ca4ddcc4..f2158c8b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=05-06 Stats: 24 lines in 6 files changed: 1 ins; 4 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/11115.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11115/head:pull/11115 PR: https://git.openjdk.org/jdk/pull/11115 From xuelei at openjdk.org Wed Nov 16 07:16:02 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 16 Nov 2022 07:16:02 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v6] In-Reply-To: <2Ja9uaGY95zatV-viOoTkNbakqLkWuCDn761HztySZU=.f42b4b8a-2be1-41b1-98c0-12f953e6a88b@github.com> References: <2Ja9uaGY95zatV-viOoTkNbakqLkWuCDn761HztySZU=.f42b4b8a-2be1-41b1-98c0-12f953e6a88b@github.com> Message-ID: On Wed, 16 Nov 2022 04:55:17 GMT, Kim Barrett wrote: >> The problem with using the return value of os::snprintf() is that we need to handle the -1 case to prevent the position from running backward. Might be better to use stringStream instead, which should handle the -1 case transparently. > > A result of -1 only occurs for an encoding error. An encoding error is only > possible with multi-byte / wide characters. (See the definition of "encoding > error" in C99 7.19.3/14.) We don't use those, so there won't be any encoding > errors, so our uses of snprintf never return -1. Updated to use the result from `os::snprtinf` in the new commit. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From xuelei at openjdk.org Wed Nov 16 07:16:03 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 16 Nov 2022 07:16:03 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v4] In-Reply-To: <74-iTHarZs4dtXp8dqJEKYrXRw24WAQHrUorBJ4Tmvc=.e2bb3e95-c538-42cb-94a6-6d3378d5bdab@github.com> References: <74-iTHarZs4dtXp8dqJEKYrXRw24WAQHrUorBJ4Tmvc=.e2bb3e95-c538-42cb-94a6-6d3378d5bdab@github.com> Message-ID: On Mon, 14 Nov 2022 16:53:07 GMT, Lutz Schmidt wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> include missing os head file > > src/hotspot/share/adlc/output_c.cpp line 536: > >> 534: int printed = snprintf(args, 37, "0x%x, 0x%x, %u", >> 535: resources_used, resources_used_exclusively, element_count); >> 536: assert(printed <= 36, "overflow"); > > if snprintf works correctly (we rely on that), this assert will never fire. Good point. I removed the assert in the new commit. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From xuelei at openjdk.org Wed Nov 16 07:16:00 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 16 Nov 2022 07:16:00 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v6] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 05:52:18 GMT, Thomas Stuefe wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> delete swp file > > src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 226: > >> 224: char buf[512]; >> 225: os::snprintf(buf, sizeof(buf), "0x%02x:0x%x:0x%03x:%d", _cpu, _variant, _model, _revision); >> 226: if (_model2) os::snprintf(buf+strlen(buf), sizeof(buf) - strlen(buf), "(0x%03x)", _model2); > > Here - and in several other places, where we construct a string from multiple parts - the code would be a simpler with `stringStream`: > > > char buf[512]; > stringStream ss(buf, sizeof(buf)); > ss.print("0x%02x:0x%x:0x%03x:%d", _cpu, _variant, _model, _revision); > if (_model2) ss.print("(0x%03x)", _model2); > _features_string = os::strdup(buf); > > or, using `stringStream`s internal buffer: > > > stringStream ss; > ss.print("0x%02x:0x%x:0x%03x:%d", _cpu, _variant, _model, _revision); > if (_model2) ss.print("(0x%03x)", _model2); > _features_string = ss.base(); > > > No manual offset counting required. > > I leave it up to you if you do it that way. The code here is correct as it is. Glad to know that `stringStream` could make this block safer and easier. I learned a lot from the reviewers of this PR. It looks like we can also use stringStream for other files touched in this PR. I would like to keep the update focusing on the simple replacing of `sprintf`. I may file a new PR for the improvement by using `stringStream` shortly after. > src/hotspot/share/classfile/javaClasses.cpp line 2562: > >> 2560: CompiledMethod* nm = method->code(); >> 2561: if (WizardMode && nm != NULL) { >> 2562: os::snprintf(buf + buf_off, buf_size - buf_off, "(nmethod " INTPTR_FORMAT ")", (intptr_t)nm); > > I think you should update `buf_off` here, because now you overwrite the last text part. Weird that no test caught that. > > All this code here in javaClasses.cpp would benefit from using stringStream. Oooops! Good catch. `buf_off` is updated in the new commit. I think `stringStream` could be a better solution. I will do it in a follow-up PR. > src/hotspot/share/utilities/utf8.cpp line 521: > >> 519: } else { >> 520: if (p + 6 >= end) break; // string is truncated >> 521: os::snprintf(p, 7, "\\u%04x", c); > > This should be 6, or? We have 6 characters left before end, assuming end is exclusive. > > Also, maybe use a named constant? If 6 is used, there is a output truncated warning and only 5 characters are filed actually. The terminating null/zero is counted in, I think. To make it easier to read, I added a comment. > src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp line 638: > >> 636: return; >> 637: } >> 638: snprintf(channelName, 16, "Ch %d", ch); > > Can we use a constant here instead of literal 16? To be honest, I don't know the logic of the code yet. I'm not sure how to name the literal 16 yet. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From xuelei at openjdk.org Wed Nov 16 07:16:02 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 16 Nov 2022 07:16:02 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v6] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 07:04:38 GMT, Kim Barrett wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> delete swp file > > src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 226: > >> 224: char buf[512]; >> 225: os::snprintf(buf, sizeof(buf), "0x%02x:0x%x:0x%03x:%d", _cpu, _variant, _model, _revision); >> 226: if (_model2) os::snprintf(buf+strlen(buf), sizeof(buf) - strlen(buf), "(0x%03x)", _model2); > > Instead of using `strlen(buf)` (now called twice!) to get the number of characters written, use the result of the first call to `os::snprintf`. Good point! Updated in the new commit. > src/hotspot/os/bsd/attachListener_bsd.cpp line 251: > >> 249: BsdAttachOperation* BsdAttachListener::read_request(int s) { >> 250: char ver_str[8]; >> 251: os::snprintf(ver_str, sizeof(ver_str), "%d", ATTACH_PROTOCOL_VER); > > We later use `strlen(ver_str)` where we could instead use the result of `os::snprintf`. I think it is safe to use the result of `os::snprintf` for the computation of max_len of the buf, isn't it? - const int max_len = (sizeof(ver_str) + 1) + (AttachOperation::name_length_max + 1) + + const int max_len = (ver_str_len + 1) + (AttachOperation::name_length_max + 1) + AttachOperation::arg_count_max*(AttachOperation::arg_length_max + 1); > src/hotspot/os/bsd/attachListener_bsd.cpp line 414: > >> 412: // write operation result >> 413: char msg[32]; >> 414: os::snprintf(msg, sizeof(msg), "%d\n", result); > > Rather than using strlen(msg) in the next line, use the result from os::snprintf. Updated to use the result from os::snprtinf in the new commit. > src/hotspot/share/classfile/javaClasses.cpp line 2532: > >> 2530: // Print module information >> 2531: if (module_name != NULL) { >> 2532: buf_off = (int)strlen(buf); > > `buf_off` could be the result of `os::snprintf` instead of calling `strlen`. Updated to use the result of `os::snprintf` in the new commit. > src/hotspot/share/code/dependencies.cpp line 780: > >> 778: } >> 779: } else { >> 780: char xn[12]; os::snprintf(xn, sizeof(xn), "x%d", j); > > Pre-existing very unusual formatting; put a line break between the statements. Yes. Updated in the new commit. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From jdv at openjdk.org Wed Nov 16 07:59:01 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 16 Nov 2022 07:59:01 GMT Subject: RFR: 8022403: sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java fails [v3] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 05:25:13 GMT, Phil Race wrote: >> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: >> >> Use EDT for creation of frame and dispose frame in finally block > > Marked as reviewed by prr (Reviewer). Thanks @prrace and @prsadhuk for the review. Just to be sure i have run updated test in our CI and everything looks good. ------------- PR: https://git.openjdk.org/jdk/pull/11158 From jdv at openjdk.org Wed Nov 16 08:02:36 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 16 Nov 2022 08:02:36 GMT Subject: Integrated: 8022403: sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java fails In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 07:58:24 GMT, Jayathirth D V wrote: > This test was failing because of color difference on boundaries. Updated test case to not check edges and added color tolerance. > > Also updated test to: > 1) Use standard GraphicsConfiguration bounds for image instead of constant numbers. > 2) Use waitForIdle before screen capture and added auto delay > 3) Move mouse pointer away from rendering content (In my local Mac it failed every time when mouse pointer was present over test frame) > 4) Remove usage of insets as it is undecorated and remove windows closing listener > 5) Dispose frame when test fails > > With these changes test is not failing in CI with multiple runs on all platforms. This pull request has now been integrated. Changeset: 65f7de25 Author: Jayathirth D V URL: https://git.openjdk.org/jdk/commit/65f7de252366e30ba18a22c107fc301c0fdc9378 Stats: 159 lines in 2 files changed: 49 ins; 34 del; 76 mod 8022403: sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java fails Reviewed-by: prr, psadhukhan ------------- PR: https://git.openjdk.org/jdk/pull/11158 From aturbanov at openjdk.org Wed Nov 16 08:11:56 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 16 Nov 2022 08:11:56 GMT Subject: RFR: 8148041: Test java/awt/Mouse/TitleBarDoubleClick/TitleBarDoubleClick fails on Ubuntu with mouseReleased event after double click on title bar In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 00:21:23 GMT, Alexander Zvegintsev wrote: > This test was problem listed with ["some tests that leave windows open on the desktop" reason](https://github.com/openjdk/jdk/commit/fd8df3adf13f5df8f5f95482b8e0a70bc519f39f) > > The main issue with the test is that it may pass, but in fact the actual test was not even performed.
`jtreg` kills the test window after exiting main and ends the test before it double clicks on window's title(actual test starts from `windowActivated` event). > > So the test was refactored and stabilized: > * robot invocation moved from EDT to main thread. > * throwing test exception is performed only after frame is disposed > * extra delay added after showing window. > > Old Ubuntu 16.04 and macOS 10.10.5 failures is no longer reproducible on modern systems. > > CI testing looks good. test/jdk/java/awt/Mouse/TitleBarDoubleClick/TitleBarDoubleClick.java line 117: > 115: public void mouseClicked(MouseEvent e) {fail(e);} > 116: > 117: public void windowActivated(WindowEvent e) {} nit Suggestion: public void windowActivated(WindowEvent e) {} ------------- PR: https://git.openjdk.org/jdk/pull/11150 From aturbanov at openjdk.org Wed Nov 16 08:16:45 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 16 Nov 2022 08:16:45 GMT Subject: RFR: 8157173: [macosx] java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java fails [v2] In-Reply-To: <3H6QdSOg-MtRtP1LJe3ZF0M8zTLQJ3PyQ37pp-WBZQw=.41d8b0d7-7869-400d-8b6a-3cc1ef19cf1a@github.com> References: <3H6QdSOg-MtRtP1LJe3ZF0M8zTLQJ3PyQ37pp-WBZQw=.41d8b0d7-7869-400d-8b6a-3cc1ef19cf1a@github.com> Message-ID: <_YAfy0lUtow7NKSmsKhCxr1IjBPU_RncnyZvmKamSMo=.5999f6d0-a86b-4b93-bb0f-86873b2226a7@github.com> On Mon, 14 Nov 2022 14:38:38 GMT, Alexander Zvegintsev wrote: >> This test currently passing as it is on all platforms, but it was problemlisted with ["Problem List some tests that leave windows open on the desktop" reason](https://github.com/openjdk/jdk/commit/fd8df3adf13f5df8f5f95482b8e0a70bc519f39f) >> >> So this test is cleaned up and stabilized. >> >> CI testing looks good. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > Addressing review comments test/jdk/java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java line 81: > 79: > 80: inputMasks = new int[3]; > 81: inputMasks[0] = InputEvent.SHIFT_DOWN_MASK; nit: Suggestion: inputMasks[0] = InputEvent.SHIFT_DOWN_MASK; ------------- PR: https://git.openjdk.org/jdk/pull/11128 From serb at openjdk.org Wed Nov 16 08:53:05 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 16 Nov 2022 08:53:05 GMT Subject: RFR: 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout [v3] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 19:16:52 GMT, Alexander Zuev wrote: >> test/jdk/javax/sound/midi/Sequencer/MetaCallback.java line 69: >> >>> 67: // On M1 Mac sometimes system notifies listener about the same message twice >>> 68: static List received = Collections.synchronizedList(new ArrayList<>()); >>> 69: >> >> Is this our bug ? > >> Is this our bug ? > > Unlikely - it happens on one platform only, looks more like for some reason system restarts the midi stream after first message. But i can not be sure because i only saw it on the CI system once in more than a thousand runs, i was never able to reproduce that exact problem locally no matter how many runs i did. Analyzing the failures from the bug i see it reported twice and both times (and in my failure) it was a first message got repeated. it really looks like a bug, but before workaround the bug, it probably would be better to fix threading issues in the test. One of the issues is that the flags are updated in the "meta()" on one thread and checked on another thread. ------------- PR: https://git.openjdk.org/jdk/pull/11157 From serb at openjdk.org Wed Nov 16 08:53:06 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 16 Nov 2022 08:53:06 GMT Subject: RFR: 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout [v3] In-Reply-To: <-38WA-JoLOxToMxxTck2FCETqVKkzmuKyFk68GEBZQM=.e231d4d0-dfc3-4d5e-9f58-32428cff6f1b@github.com> References: <3W-OC_EeYya8hQKeGwfpAnBUylk18dq1c4CP5fSKkyw=.e86a1209-7c2a-4330-a40d-85812a829f82@github.com> <-38WA-JoLOxToMxxTck2FCETqVKkzmuKyFk68GEBZQM=.e231d4d0-dfc3-4d5e-9f58-32428cff6f1b@github.com> Message-ID: On Wed, 16 Nov 2022 06:45:28 GMT, Prasanta Sadhukhan wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed typo in copyright year > > test/jdk/javax/sound/midi/Sequencer/MetaCallback.java line 119: > >> 117: finished = true; >> 118: } else if (msg.getData().length > 0 && msg.getType() == 1 && !received.contains(msg)) { >> 119: received.add(msg); > > Do we not need to do seq.stop() before close() in l136 If this code is needed can we check first where we create duplicate events? ------------- PR: https://git.openjdk.org/jdk/pull/11157 From achung at openjdk.org Wed Nov 16 08:56:11 2022 From: achung at openjdk.org (Alisen Chung) Date: Wed, 16 Nov 2022 08:56:11 GMT Subject: RFR: 8023562: [TEST_BUG] java/awt/Mouse/EnterExitEvents/DragWindowTest.java failed on ubuntu 13 and mac 10.11 Message-ID: Test was run on macos and linux 100x and passed. Removing from ProblemList ------------- Commit messages: - removed DragWindowTest.java from ProblemList Changes: https://git.openjdk.org/jdk/pull/11152/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11152&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8023562 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11152.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11152/head:pull/11152 PR: https://git.openjdk.org/jdk/pull/11152 From serb at openjdk.org Wed Nov 16 08:58:46 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 16 Nov 2022 08:58:46 GMT Subject: RFR: 8157173: [macosx] java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java fails [v2] In-Reply-To: <3H6QdSOg-MtRtP1LJe3ZF0M8zTLQJ3PyQ37pp-WBZQw=.41d8b0d7-7869-400d-8b6a-3cc1ef19cf1a@github.com> References: <3H6QdSOg-MtRtP1LJe3ZF0M8zTLQJ3PyQ37pp-WBZQw=.41d8b0d7-7869-400d-8b6a-3cc1ef19cf1a@github.com> Message-ID: On Mon, 14 Nov 2022 14:38:38 GMT, Alexander Zvegintsev wrote: >> This test currently passing as it is on all platforms, but it was problemlisted with ["Problem List some tests that leave windows open on the desktop" reason](https://github.com/openjdk/jdk/commit/fd8df3adf13f5df8f5f95482b8e0a70bc519f39f) >> >> So this test is cleaned up and stabilized. >> >> CI testing looks good. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > Addressing review comments Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11128 From lucy at openjdk.org Wed Nov 16 09:05:51 2022 From: lucy at openjdk.org (Lutz Schmidt) Date: Wed, 16 Nov 2022 09:05:51 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v6] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 06:43:29 GMT, Xue-Lei Andrew Fan wrote: >> src/hotspot/share/utilities/utf8.cpp line 521: >> >>> 519: } else { >>> 520: if (p + 6 >= end) break; // string is truncated >>> 521: os::snprintf(p, 7, "\\u%04x", c); >> >> This should be 6, or? We have 6 characters left before end, assuming end is exclusive. >> >> Also, maybe use a named constant? > > If 6 is used, there is a output truncated warning and only 5 characters are filed actually. The terminating null/zero is counted in, I think. To make it easier to read, I added a comment. For snprintf, all bytes written to the buffer (including the terminating \0) are counted. You have 6 bytes for character encoding ("\uxxxx") and one byte for \0. Code is correct. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From stuefe at openjdk.org Wed Nov 16 09:10:01 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 16 Nov 2022 09:10:01 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v6] In-Reply-To: References: <2Ja9uaGY95zatV-viOoTkNbakqLkWuCDn761HztySZU=.f42b4b8a-2be1-41b1-98c0-12f953e6a88b@github.com> Message-ID: On Wed, 16 Nov 2022 05:45:34 GMT, Xue-Lei Andrew Fan wrote: >> A result of -1 only occurs for an encoding error. An encoding error is only >> possible with multi-byte / wide characters. (See the definition of "encoding >> error" in C99 7.19.3/14.) We don't use those, so there won't be any encoding >> errors, so our uses of snprintf never return -1. > > Updated to use the result from `os::snprtinf` in the new commit. > A result of -1 only occurs for an encoding error. An encoding error is only possible with multi-byte / wide characters. (See the definition of "encoding error" in C99 7.19.3/14.) We don't use those, so there won't be any encoding errors, so our uses of snprintf never return -1. Hi @kimbarrett, I am not sure this was true. E.g. https://stackoverflow.com/questions/65334245/what-is-an-encoding-error-for-sprintf-that-should-return-1 cites some cases where snprintf returns -1 that have nothing to do with multibyte strings. Also, size=0 would return -1 according to SUSv2. Note glibc differs and returns the number of chars it *would* have printed. Which is also dangerous in a different way. If you use that number to update the position, the position is not limited to buffer boundaries. So, I think the result of os::snprintf should not be used to update buffer position, at least not without checking. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From duke at openjdk.org Wed Nov 16 10:44:05 2022 From: duke at openjdk.org (Patrick Chen) Date: Wed, 16 Nov 2022 10:44:05 GMT Subject: RFR: 8148041: Test java/awt/Mouse/TitleBarDoubleClick/TitleBarDoubleClick fails on Ubuntu with mouseReleased event after double click on title bar In-Reply-To: References: Message-ID: <5wm0Zj1By5O1pqE82AN_Fs9McDgIbM5b_iNAxS6BUfo=.55e45a62-03c8-4204-9671-14b3b5d4ed78@github.com> On Tue, 15 Nov 2022 00:21:23 GMT, Alexander Zvegintsev wrote: > This test was problem listed with ["some tests that leave windows open on the desktop" reason](https://github.com/openjdk/jdk/commit/fd8df3adf13f5df8f5f95482b8e0a70bc519f39f) > > The main issue with the test is that it may pass, but in fact the actual test was not even performed.
`jtreg` kills the test window after exiting main and ends the test before it double clicks on window's title(actual test starts from `windowActivated` event). > > So the test was refactored and stabilized: > * robot invocation moved from EDT to main thread. > * throwing test exception is performed only after frame is disposed > * extra delay added after showing window. > > Old Ubuntu 16.04 and macOS 10.10.5 failures is no longer reproducible on modern systems. > > CI testing looks good. Marked as reviewed by kiraka42 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.org/jdk/pull/11150 From stuefe at openjdk.org Wed Nov 16 11:11:07 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 16 Nov 2022 11:11:07 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v7] In-Reply-To: References: Message-ID: <3Z4ZjjimT7rK922Mho3uBBr59f8InHziFo3_Q10_Eyo=.d056cd57-4f64-48f4-862e-e210c0d317b1@github.com> On Wed, 16 Nov 2022 07:03:12 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> May I have this update reviewed? >> >> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > address review comments I don't think it is safe to use the return value of `os::snprintf` to update buffer positions. `os::snprintf()` calls `os::vsnprintf()` which, at least on Posix, returns the return value of `vnsprintf(3)` verbatim. If native `vsnprintf(3)` conforms to SUSv2 [1], it will return <0 if the buffer size is zero. So for cases where we calculate the buffer size based on what was written, and we are just at the edge of the buffer, we would move the next write position backward. But much worse: if the native `vsnprintf(3)` conforms to C99 (e.g. glibc, BSD libc) they return "number of characters (not including the terminating null character) which would have been written to buffer if bufsz was ignored". [2] So, if the buffer was too small and we truncated, and we use the return value to calculate the next write position, we will write outside the buffer boundaries. Regardless of what behavior we have - C99 or SUSv2 - we cannot just use the return value to update the next write position without first checking the return value. We could - and probably should - decide on C99 or SUSv2 behavior for all platforms, and modify `os::snprintf()` to provide that in an OS-independent way. But unless we decide on some mongrel of both C99 and SUSv2 behaviors, the problem remains. Cheers, Thomas [1] https://pubs.opengroup.org/onlinepubs/7908799/xsh/fprintf.html [2] https://en.cppreference.com/w/c/io/fprintf ------------- PR: https://git.openjdk.org/jdk/pull/11115 From stuefe at openjdk.org Wed Nov 16 12:59:22 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 16 Nov 2022 12:59:22 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v7] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 07:03:12 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> May I have this update reviewed? >> >> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > address review comments src/hotspot/os/bsd/attachListener_bsd.cpp line 295: > 293: char msg[32]; > 294: int msg_len = os::snprintf(msg, sizeof(msg), "%d\n", ATTACH_ERROR_BADVERSION); > 295: write_fully(s, msg, msg_len); Assuming C99 behavior: safe but only because the buffer is large enough ("%d\n" needs at most 12 bytes, buffer is 32). Were it to overflow, msg_len would be larger than sizeof(msg) and we would probably end up reading beyond the message end in write_fully. So not really better than using sprintf+strlen. src/hotspot/os/bsd/attachListener_bsd.cpp line 415: > 413: char msg[32]; > 414: int msg_len = os::snprintf(msg, sizeof(msg), "%d\n", result); > 415: int rc = BsdAttachListener::write_fully(this->socket(), msg, msg_len); same src/hotspot/share/adlc/output_c.cpp line 217: > 215: const PipeClassOperandForm *tmppipeopnd = > 216: (const PipeClassOperandForm *)pipeclass->_localUsage[paramname]; > 217: templen += snprintf(&operand_stages[templen], operand_stages_size - templen, " stage_%s%c\n", C99 Behavior: all these are probably safe but only because we never overstepped the buffer in the first place, the buffer size is pre-calculated. If it is incorrect and we have a truncation, subsequent writes will write beyond the buffer. src/hotspot/share/classfile/javaClasses.cpp line 2527: > 2525: > 2526: // Print stack trace line in buffer > 2527: size_t buf_off = os::snprintf(buf, buf_size, "\tat %s.%s(", klass_name, method_name); Here, and in subsequent uses: assuming C99 behavior of snprintf, if we truncated in snprintf, buf_off will be > buffer size, (buf + buf_off) point beyond the buffer, (buf_size - buf_off) will overflow and become very large. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From azvegint at openjdk.org Wed Nov 16 15:07:32 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 16 Nov 2022 15:07:32 GMT Subject: RFR: 8157173: [macosx] java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java fails [v3] In-Reply-To: References: Message-ID: > This test currently passing as it is on all platforms, but it was problemlisted with ["Problem List some tests that leave windows open on the desktop" reason](https://github.com/openjdk/jdk/commit/fd8df3adf13f5df8f5f95482b8e0a70bc519f39f) > > So this test is cleaned up and stabilized. > > CI testing looks good. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: indent fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11128/files - new: https://git.openjdk.org/jdk/pull/11128/files/b906399e..bf6dab4d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11128&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11128&range=01-02 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/11128.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11128/head:pull/11128 PR: https://git.openjdk.org/jdk/pull/11128 From azvegint at openjdk.org Wed Nov 16 15:08:24 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 16 Nov 2022 15:08:24 GMT Subject: RFR: 8148041: Test java/awt/Mouse/TitleBarDoubleClick/TitleBarDoubleClick fails on Ubuntu with mouseReleased event after double click on title bar [v2] In-Reply-To: References: Message-ID: > This test was problem listed with ["some tests that leave windows open on the desktop" reason](https://github.com/openjdk/jdk/commit/fd8df3adf13f5df8f5f95482b8e0a70bc519f39f) > > The main issue with the test is that it may pass, but in fact the actual test was not even performed.
`jtreg` kills the test window after exiting main and ends the test before it double clicks on window's title(actual test starts from `windowActivated` event). > > So the test was refactored and stabilized: > * robot invocation moved from EDT to main thread. > * throwing test exception is performed only after frame is disposed > * extra delay added after showing window. > > Old Ubuntu 16.04 and macOS 10.10.5 failures is no longer reproducible on modern systems. > > CI testing looks good. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: clean up ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11150/files - new: https://git.openjdk.org/jdk/pull/11150/files/59642367..17e07e37 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11150&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11150&range=00-01 Stats: 25 lines in 1 file changed: 9 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/11150.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11150/head:pull/11150 PR: https://git.openjdk.org/jdk/pull/11150 From prr at openjdk.org Wed Nov 16 17:08:01 2022 From: prr at openjdk.org (Phil Race) Date: Wed, 16 Nov 2022 17:08:01 GMT Subject: RFR: 8282404: DrawStringWithInfiniteXform.java failed with "RuntimeException: drawString with InfiniteXform transform takes long time" In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 04:23:37 GMT, Prasanta Sadhukhan wrote: > It seems timer.cancel() says "Terminates this timer, discarding any currently scheduled tasks." Yes, that's the intention. > so it might disregard the "done" check been done in ScheduleTask resulting in false positive... If we reach timer.cancel() before the timer fires off the task we don't need the task canceling it means the test can exit immediately - not wait 20 or 30 seconds. If it does fire because cancel is too slow, it will see "done==true" So perhaps I'm not following your point ? > Should we do Thread.yield() instead? No. > I'll tidy it up a bit more. ------------- PR: https://git.openjdk.org/jdk/pull/11179 From azvegint at openjdk.org Wed Nov 16 17:10:16 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 16 Nov 2022 17:10:16 GMT Subject: Integrated: 8157173: [macosx] java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java fails In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 00:12:00 GMT, Alexander Zvegintsev wrote: > This test currently passing as it is on all platforms, but it was problemlisted with ["Problem List some tests that leave windows open on the desktop" reason](https://github.com/openjdk/jdk/commit/fd8df3adf13f5df8f5f95482b8e0a70bc519f39f) > > So this test is cleaned up and stabilized. > > CI testing looks good. This pull request has now been integrated. Changeset: 39dda24d Author: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/39dda24dc67dbf06eead91cca5ce09a28fead0c9 Stats: 173 lines in 2 files changed: 52 ins; 45 del; 76 mod 8157173: [macosx] java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java fails Reviewed-by: jdv, prr, serb ------------- PR: https://git.openjdk.org/jdk/pull/11128 From prr at openjdk.org Wed Nov 16 17:16:55 2022 From: prr at openjdk.org (Phil Race) Date: Wed, 16 Nov 2022 17:16:55 GMT Subject: RFR: 8148041: Test java/awt/Mouse/TitleBarDoubleClick/TitleBarDoubleClick fails on Ubuntu with mouseReleased event after double click on title bar [v2] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 15:08:24 GMT, Alexander Zvegintsev wrote: >> This test was problem listed with ["some tests that leave windows open on the desktop" reason](https://github.com/openjdk/jdk/commit/fd8df3adf13f5df8f5f95482b8e0a70bc519f39f) >> >> The main issue with the test is that it may pass, but in fact the actual test was not even performed.
`jtreg` kills the test window after exiting main and ends the test before it double clicks on window's title(actual test starts from `windowActivated` event). >> >> So the test was refactored and stabilized: >> * robot invocation moved from EDT to main thread. >> * throwing test exception is performed only after frame is disposed >> * extra delay added after showing window. >> >> Old Ubuntu 16.04 and macOS 10.10.5 failures is no longer reproducible on modern systems. >> >> CI testing looks good. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > clean up Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11150 From prr at openjdk.org Wed Nov 16 17:19:11 2022 From: prr at openjdk.org (Phil Race) Date: Wed, 16 Nov 2022 17:19:11 GMT Subject: RFR: 8296083: javax/swing/JTree/6263446/bug6263446.java fails intermittently on a VM [v2] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 06:56:20 GMT, Prasanta Sadhukhan wrote: >> Test intermittently fails in VM citing "Tree is not editing". Seems to be problem with mouse clicks not getting registered properly.. >> Similar test test/jdk/javax/swing/JTable/6263446/bug6263446.java is not affected, so made the test similar to it by using same safeguard using Robot.waitForIdle() and modifying clickpoint to tree cell midpoint. >> >> Several iterations of the test pass in the OCI VM and all other physical platforms (link in JBS) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test update This test will need to be monitored ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.org/jdk/pull/11057 From prr at openjdk.org Wed Nov 16 17:35:25 2022 From: prr at openjdk.org (Phil Race) Date: Wed, 16 Nov 2022 17:35:25 GMT Subject: RFR: 8282404: DrawStringWithInfiniteXform.java failed with "RuntimeException: drawString with InfiniteXform transform takes long time" [v2] In-Reply-To: References: Message-ID: <23B-3108dezud6Ku_Wj_MT3S1emh8SDNA_ob5BLbfzY=.a1d35e80-f15b-402c-a7e7-906b1a0533d1@github.com> > This test is not problem listed and has failed only once since (SFAIK) it was last updated a year ago so > this is just another small attempt to remove instability by increasing timeout, being really insistent about > making sure the "done=true" is propagated and adding some extra timing logging to help analyse any failures Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8282404 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11179/files - new: https://git.openjdk.org/jdk/pull/11179/files/766dcc30..7becd787 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11179&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11179&range=00-01 Stats: 10 lines in 1 file changed: 3 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/11179.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11179/head:pull/11179 PR: https://git.openjdk.org/jdk/pull/11179 From duke at openjdk.org Wed Nov 16 17:42:08 2022 From: duke at openjdk.org (ravi gupta) Date: Wed, 16 Nov 2022 17:42:08 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. [v4] In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 08:20:55 GMT, ravi gupta wrote: >> This testcase Verify the content changes of a TextArea for the following assertions. >> >> a. TextListener get invoked when the content of a TextArea gets changed. >> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8296632: Review fixes. Any volunteers for a review? ------------- PR: https://git.openjdk.org/jdk/pull/11052 From azvegint at openjdk.org Wed Nov 16 18:33:25 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 16 Nov 2022 18:33:25 GMT Subject: RFR: 8023562: [TEST_BUG] java/awt/Mouse/EnterExitEvents/DragWindowTest.java failed on ubuntu 13 and mac 10.11 In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 01:46:06 GMT, Alisen Chung wrote: > Test was run on macos and linux 100x and passed. Removing from ProblemList Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11152 From prr at openjdk.org Wed Nov 16 19:18:07 2022 From: prr at openjdk.org (Phil Race) Date: Wed, 16 Nov 2022 19:18:07 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. [v4] In-Reply-To: References: Message-ID: <5BZCbheS5XmeDRBUQrGuFeT58G3fJvxQrjMkQOgC9EE=.0374a5cf-7ce1-4455-840e-fdd68c31a409@github.com> On Fri, 11 Nov 2022 08:20:55 GMT, ravi gupta wrote: >> This testcase Verify the content changes of a TextArea for the following assertions. >> >> a. TextListener get invoked when the content of a TextArea gets changed. >> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8296632: Review fixes. Marked as reviewed by prr (Reviewer). test/jdk/java/awt/event/ComponentEvent/TextAreaTextEventTest.java line 72: > 70: > 71: typeKey(KeyEvent.VK_T); > 72: In theory the autoWaitForIdle should ensure that events are processed. We'll see. If you find otherwise then here (and after typing the Enter key) it might be safer to do an additional robot.delay(500); You want to give every chance to process these events. ------------- PR: https://git.openjdk.org/jdk/pull/11052 From serb at openjdk.org Wed Nov 16 19:42:08 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 16 Nov 2022 19:42:08 GMT Subject: RFR: 8022403: sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java fails [v4] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 05:37:19 GMT, Jayathirth D V wrote: >> This test was failing because of color difference on boundaries. Updated test case to not check edges and added color tolerance. >> >> Also updated test to: >> 1) Use standard GraphicsConfiguration bounds for image instead of constant numbers. >> 2) Use waitForIdle before screen capture and added auto delay >> 3) Move mouse pointer away from rendering content (In my local Mac it failed every time when mouse pointer was present over test frame) >> 4) Remove usage of insets as it is undecorated and remove windows closing listener >> 5) Dispose frame when test fails >> >> With these changes test is not failing in CI with multiple runs on all platforms. > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Remove comment test/jdk/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java line 89: > 87: > 88: final Frame frame = new Frame("OnScreenRenderingResizeTest") { > 89: public void paint(Graphics g) {} Looks like these two empty methods are removed by the fix, why? ------------- PR: https://git.openjdk.org/jdk/pull/11158 From kizune at openjdk.org Wed Nov 16 19:48:13 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 16 Nov 2022 19:48:13 GMT Subject: RFR: 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout [v3] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 08:51:01 GMT, Sergey Bylokhov wrote: > One of the issues is that the flags are updated in the "meta()" on one thread and checked on another thread. I can make counter and boolean flag volatile but looking at the logic of the updates i do not think it is a problem since both counter and flag updates happens on the same thread and we do not access counter on another thread until the flag is changed. ------------- PR: https://git.openjdk.org/jdk/pull/11157 From kizune at openjdk.org Wed Nov 16 19:55:01 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 16 Nov 2022 19:55:01 GMT Subject: RFR: 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout [v3] In-Reply-To: References: <3W-OC_EeYya8hQKeGwfpAnBUylk18dq1c4CP5fSKkyw=.e86a1209-7c2a-4330-a40d-85812a829f82@github.com> <-38WA-JoLOxToMxxTck2FCETqVKkzmuKyFk68GEBZQM=.e231d4d0-dfc3-4d5e-9f58-32428cff6f1b@github.com> Message-ID: On Wed, 16 Nov 2022 08:50:57 GMT, Sergey Bylokhov wrote: >> test/jdk/javax/sound/midi/Sequencer/MetaCallback.java line 119: >> >>> 117: finished = true; >>> 118: } else if (msg.getData().length > 0 && msg.getType() == 1 && !received.contains(msg)) { >>> 119: received.add(msg); >> >> Do we not need to do seq.stop() before close() in l136 > > If this code is needed can we check first where we create duplicate events? > Do we not need to do seq.stop() before close() in l136 On that line we never call start() on the sequencer so calling stop() is redundant. ------------- PR: https://git.openjdk.org/jdk/pull/11157 From honkar at openjdk.org Wed Nov 16 20:02:07 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 16 Nov 2022 20:02:07 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. [v4] In-Reply-To: References: Message-ID: <3DeON9y6xy810glsJG7wz7g40YPSLw6VkZhOn99ZZfI=.cd37d71d-1c9c-4652-9765-241a277b085e@github.com> On Fri, 11 Nov 2022 08:20:55 GMT, ravi gupta wrote: >> This testcase Verify the content changes of a TextArea for the following assertions. >> >> a. TextListener get invoked when the content of a TextArea gets changed. >> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8296632: Review fixes. Marked as reviewed by honkar (Author). ------------- PR: https://git.openjdk.org/jdk/pull/11052 From honkar at openjdk.org Wed Nov 16 20:02:09 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 16 Nov 2022 20:02:09 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. [v4] In-Reply-To: <5BZCbheS5XmeDRBUQrGuFeT58G3fJvxQrjMkQOgC9EE=.0374a5cf-7ce1-4455-840e-fdd68c31a409@github.com> References: <5BZCbheS5XmeDRBUQrGuFeT58G3fJvxQrjMkQOgC9EE=.0374a5cf-7ce1-4455-840e-fdd68c31a409@github.com> Message-ID: <1rtG0lprHMB1oeOEcSZsfpWj3IJ8t-QdZsEZw0yFB70=.6371c5c6-f888-42e3-938b-14d923f77b25@github.com> On Wed, 16 Nov 2022 19:13:57 GMT, Phil Race wrote: >> ravi gupta has updated the pull request incrementally with one additional commit since the last revision: >> >> 8296632: Review fixes. > > test/jdk/java/awt/event/ComponentEvent/TextAreaTextEventTest.java line 72: > >> 70: >> 71: typeKey(KeyEvent.VK_T); >> 72: > > In theory the autoWaitForIdle should ensure that events are processed. We'll see. > If you find otherwise then here (and after typing the Enter key) it might be safer to do an additional robot.delay(500); > You want to give every chance to process these events. Tested it locally on Win10. Works as expected. I agree @prrace, adding additional delay would make sure that all events are processed. ------------- PR: https://git.openjdk.org/jdk/pull/11052 From psadhukhan at openjdk.org Thu Nov 17 03:20:20 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 17 Nov 2022 03:20:20 GMT Subject: RFR: 8282404: DrawStringWithInfiniteXform.java failed with "RuntimeException: drawString with InfiniteXform transform takes long time" [v2] In-Reply-To: <23B-3108dezud6Ku_Wj_MT3S1emh8SDNA_ob5BLbfzY=.a1d35e80-f15b-402c-a7e7-906b1a0533d1@github.com> References: <23B-3108dezud6Ku_Wj_MT3S1emh8SDNA_ob5BLbfzY=.a1d35e80-f15b-402c-a7e7-906b1a0533d1@github.com> Message-ID: On Wed, 16 Nov 2022 17:35:25 GMT, Phil Race wrote: >> This test is not problem listed and has failed only once since (SFAIK) it was last updated a year ago so >> this is just another small attempt to remove instability by increasing timeout, being really insistent about >> making sure the "done=true" is propagated and adding some extra timing logging to help analyse any failures > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8282404 Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11179 From psadhukhan at openjdk.org Thu Nov 17 03:20:20 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 17 Nov 2022 03:20:20 GMT Subject: RFR: 8282404: DrawStringWithInfiniteXform.java failed with "RuntimeException: drawString with InfiniteXform transform takes long time" [v2] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 17:04:08 GMT, Phil Race wrote: >> test/jdk/java/awt/FontClass/DrawStringWithInfiniteXform.java line 90: >> >>> 88: timer.cancel(); >>> 89: } >>> 90: System.out.println("Test passed"); >> >> It seems timer.cancel() says "Terminates this timer, discarding any currently scheduled tasks." so it might disregard the "done" check been done in ScheduleTask resulting in false positive... >> Should we do Thread.yield() instead? >> >> Also, this test has many coding violations like l70, l79 where no space between operators,variables... > >> It seems timer.cancel() says "Terminates this timer, discarding any currently scheduled tasks." > > Yes, that's the intention. > >> so it might disregard the "done" check been done in ScheduleTask resulting in false positive... > > If we reach timer.cancel() before the timer fires off the task we don't need the task > canceling it means the test can exit immediately - not wait 20 or 30 seconds. > > If it does fire because cancel is too slow, it will see "done==true" > > So perhaps I'm not following your point ? > > >> Should we do Thread.yield() instead? > > No. > >> I'll tidy it up a bit more. OK. So, it means ScheduleTask should ideally never be executed if drawString with infinite transform takes lesser time < 30s, which is desirable and test can exit. ------------- PR: https://git.openjdk.org/jdk/pull/11179 From psadhukhan at openjdk.org Thu Nov 17 03:23:03 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 17 Nov 2022 03:23:03 GMT Subject: RFR: 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout [v3] In-Reply-To: <3W-OC_EeYya8hQKeGwfpAnBUylk18dq1c4CP5fSKkyw=.e86a1209-7c2a-4330-a40d-85812a829f82@github.com> References: <3W-OC_EeYya8hQKeGwfpAnBUylk18dq1c4CP5fSKkyw=.e86a1209-7c2a-4330-a40d-85812a829f82@github.com> Message-ID: On Wed, 16 Nov 2022 05:37:15 GMT, Alexander Zuev wrote: >> On m1 mac sometimes (in very rare instance) it takes a long time to get the sequencer so increasing timeout helps with that. >> Also on m1 mac sequencer got notified about the first MetaMessage twice. The reason is unclear but watching for that fixes the problem. Also on Linux sometimes process hangs indefinitely without finishing hold by the com.sun.media.sound.MediaDispatcher. Closing the sequencer at the end of the test helps with that. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Fixed typo in copyright year Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11157 From psadhukhan at openjdk.org Thu Nov 17 03:23:05 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 17 Nov 2022 03:23:05 GMT Subject: RFR: 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout [v3] In-Reply-To: References: <3W-OC_EeYya8hQKeGwfpAnBUylk18dq1c4CP5fSKkyw=.e86a1209-7c2a-4330-a40d-85812a829f82@github.com> <-38WA-JoLOxToMxxTck2FCETqVKkzmuKyFk68GEBZQM=.e231d4d0-dfc3-4d5e-9f58-32428cff6f1b@github.com> Message-ID: On Wed, 16 Nov 2022 19:52:26 GMT, Alexander Zuev wrote: >> If this code is needed can we check first where we create duplicate events? > >> Do we not need to do seq.stop() before close() in l136 > > On that line we never call start() on the sequencer so calling stop() is redundant. ok, understood... ------------- PR: https://git.openjdk.org/jdk/pull/11157 From psadhukhan at openjdk.org Thu Nov 17 03:28:34 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 17 Nov 2022 03:28:34 GMT Subject: Integrated: 8296083: javax/swing/JTree/6263446/bug6263446.java fails intermittently on a VM In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 10:37:24 GMT, Prasanta Sadhukhan wrote: > Test intermittently fails in VM citing "Tree is not editing". Seems to be problem with mouse clicks not getting registered properly.. > Similar test test/jdk/javax/swing/JTable/6263446/bug6263446.java is not affected, so made the test similar to it by using same safeguard using Robot.waitForIdle() and modifying clickpoint to tree cell midpoint. > > Several iterations of the test pass in the OCI VM and all other physical platforms (link in JBS) This pull request has now been integrated. Changeset: dd9aa727 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/dd9aa7272d04b49dd5cbf3ff9f9091c7d63d68ae Stats: 26 lines in 2 files changed: 21 ins; 2 del; 3 mod 8296083: javax/swing/JTree/6263446/bug6263446.java fails intermittently on a VM Reviewed-by: tr, prr ------------- PR: https://git.openjdk.org/jdk/pull/11057 From jdv at openjdk.org Thu Nov 17 04:08:26 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 17 Nov 2022 04:08:26 GMT Subject: RFR: 8022403: sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java fails [v4] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 19:39:09 GMT, Sergey Bylokhov wrote: >> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove comment > > test/jdk/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java line 89: > >> 87: >> 88: final Frame frame = new Frame("OnScreenRenderingResizeTest") { >> 89: public void paint(Graphics g) {} > > Looks like these two empty methods are removed by the fix, why? We creating frame on EDT and running animation in main(). I didnt see any change by removing empty paint() method of frame(), thats why it is removed as cleanup. ------------- PR: https://git.openjdk.org/jdk/pull/11158 From duke at openjdk.org Thu Nov 17 05:26:27 2022 From: duke at openjdk.org (Naveen Narayanan) Date: Thu, 17 Nov 2022 05:26:27 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem. [v3] In-Reply-To: References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> Message-ID: On Thu, 10 Nov 2022 05:14:36 GMT, Naveen Narayanan wrote: >> This testcase will >> 1) Verify setAccelerator method of JMenuitem. >> 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M. >> >> Testing: >> Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. > > Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: > > 8296275: Review comments fixed. Any volunteers for a review? ------------- PR: https://git.openjdk.org/jdk/pull/11035 From kbarrett at openjdk.org Thu Nov 17 06:07:33 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 17 Nov 2022 06:07:33 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v6] In-Reply-To: References: <2Ja9uaGY95zatV-viOoTkNbakqLkWuCDn761HztySZU=.f42b4b8a-2be1-41b1-98c0-12f953e6a88b@github.com> Message-ID: On Wed, 16 Nov 2022 09:06:22 GMT, Thomas Stuefe wrote: >> Updated to use the result from `os::snprtinf` in the new commit. > >> A result of -1 only occurs for an encoding error. An encoding error is only possible with multi-byte / wide characters. (See the definition of "encoding error" in C99 7.19.3/14.) We don't use those, so there won't be any encoding errors, so our uses of snprintf never return -1. > > Hi @kimbarrett, > > I am not sure this was true. E.g. https://stackoverflow.com/questions/65334245/what-is-an-encoding-error-for-sprintf-that-should-return-1 cites some cases where snprintf returns -1 that have nothing to do with multibyte strings. Also, size=0 would return -1 according to SUSv2. > > Note glibc differs and returns the number of chars it *would* have printed. Which is also dangerous in a different way. If you use that number to update the position, the position is not limited to buffer boundaries. So, I think the result of os::snprintf should not be used to update buffer position, at least not without checking. SUSv2 is *ancient*. That got fixed in SUSv3 / POSIX.1-2001. From the Linux man page for snprintf: "Concerning the return value of snprintf(), SUSv2 and C99 contradict each other: when snprintf() is called with size=0 then SUSv2 stipulates an unspecified return value less than 1, while C99 allows str to be NULL in this case, and gives the return value (as always) as the number of characters that would have been written in case the output string has been large enough. POSIX.1-2001 and later align their specification of snprintf() with C99." For many/most places where we might use the return value, an assert of no truncation would be appropriate. (Esp. likely in places where sprintf was being used correctly.) Though there are probably places where something more is needed. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From jdv at openjdk.org Thu Nov 17 07:04:58 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 17 Nov 2022 07:04:58 GMT Subject: RFR: 8282404: DrawStringWithInfiniteXform.java failed with "RuntimeException: drawString with InfiniteXform transform takes long time" [v2] In-Reply-To: <23B-3108dezud6Ku_Wj_MT3S1emh8SDNA_ob5BLbfzY=.a1d35e80-f15b-402c-a7e7-906b1a0533d1@github.com> References: <23B-3108dezud6Ku_Wj_MT3S1emh8SDNA_ob5BLbfzY=.a1d35e80-f15b-402c-a7e7-906b1a0533d1@github.com> Message-ID: On Wed, 16 Nov 2022 17:35:25 GMT, Phil Race wrote: >> This test is not problem listed and has failed only once since (SFAIK) it was last updated a year ago so >> this is just another small attempt to remove instability by increasing timeout, being really insistent about >> making sure the "done=true" is propagated and adding some extra timing logging to help analyse any failures > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8282404 Marked as reviewed by jdv (Reviewer). test/jdk/java/awt/FontClass/DrawStringWithInfiniteXform.java line 71: > 69: System.out.flush(); > 70: float[] vals = new float[6]; > 71: for (int i=0; i<6; i++) { We can add proper indentation for operators before push, since we are updated at other places. ------------- PR: https://git.openjdk.org/jdk/pull/11179 From jdv at openjdk.org Thu Nov 17 07:17:05 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 17 Nov 2022 07:17:05 GMT Subject: RFR: 8023562: [TEST_BUG] java/awt/Mouse/EnterExitEvents/DragWindowTest.java failed on ubuntu 13 and mac 10.11 In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 18:30:02 GMT, Alexander Zvegintsev wrote: >> Test was run on macos and linux 100x and passed. Removing from ProblemList > > Marked as reviewed by azvegint (Reviewer). There is JBS comment from @azvegint about test update for this bug. Is that change still applicable or not? @alisenchung Please add CI test link in JBS for reference. ------------- PR: https://git.openjdk.org/jdk/pull/11152 From stuefe at openjdk.org Thu Nov 17 07:21:22 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 17 Nov 2022 07:21:22 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 In-Reply-To: <-ER02i5fNCaZX-v56giR7gCbuMkwwpdhg5LBLThVvds=.402ad601-58e3-4529-935a-151e5e76b2b3@github.com> References: <-ER02i5fNCaZX-v56giR7gCbuMkwwpdhg5LBLThVvds=.402ad601-58e3-4529-935a-151e5e76b2b3@github.com> Message-ID: <3fS41Mj_ubTpa_Yst_o20YWEPedypa7njvogcZf_zrk=.592f000f-bb5b-4954-af53-c2c65861f130@github.com> On Sun, 13 Nov 2022 22:55:52 GMT, Xue-Lei Andrew Fan wrote: >> Please don't add uses of `jio_snprintf` or `::snprintf` to hotspot. Use `os::snprintf`. >> >> Regarding `jio_snprintf`, see https://bugs.openjdk.org/browse/JDK-8198918. >> Regarding `os::snprintf` and `os::vsnprintf`, see https://bugs.openjdk.org/browse/JDK-8285506. >> >> I think the only reason we haven't marked `::sprintf` and `::snprintf` forbidden >> (FORBID_C_FUNCTION) is there are a lot of uses, and nobody has gotten around >> to dealing with it. `::snprintf` in the list of candidates for >> https://bugs.openjdk.org/browse/JDK-8214976, some of which have already been >> marked. But I don't see new bugs for the as-yet unmarked ones. >> >> As a general note, as a reviewer my preference is against non-trivial and >> persnickety code changes that are scattered all over the code base. For >> something like this I'd prefer multiple more bite-sized changes that were >> dealing with specific uses. I doubt everyone agrees with me though. > >> Please don't add uses of `jio_snprintf` or `::snprintf` to hotspot. Use `os::snprintf`. > > Updated to use os::snprintf, except the files under adlc where the os::snptintf definition is not included. The use of snprintf could be cleaned up with existing code in the future. > >> >> Regarding `jio_snprintf`, see https://bugs.openjdk.org/browse/JDK-8198918. Regarding `os::snprintf` and `os::vsnprintf`, see https://bugs.openjdk.org/browse/JDK-8285506. >> >> I think the only reason we haven't marked `::sprintf` and `::snprintf` forbidden (FORBID_C_FUNCTION) is there are a lot of uses, and nobody has gotten around to dealing with it. `::snprintf` in the list of candidates for https://bugs.openjdk.org/browse/JDK-8214976, some of which have already been marked. But I don't see new bugs for the as-yet unmarked ones. >> >> As a general note, as a reviewer my preference is against non-trivial and persnickety code changes that are scattered all over the code base. For something like this I'd prefer multiple more bite-sized changes that were dealing with specific uses. I doubt everyone agrees with me though. > > It makes sense to me. I'd better focus on the building issue in this PR. > > Thank you for the review! Hi @XueleiFan and @kimbarrett , I agree to the change if we, as Kim suggested, add assertions for truncation where we use the return value of snprintf. I am not fully happy with the solution though, since printing is notoriously runtime-data dependent and runtime data can change in release builds. So we could have truncation at a customer that we never see in our tests with debug builds. But seeing that this patch takes so long now and blocks the MacOS build, I don't want to block it. We can improve the code in follow up RFEs. These places would be a lot simpler with stringStream. Cheers, Thomas ------------- PR: https://git.openjdk.org/jdk/pull/11115 From abhiscxk at openjdk.org Thu Nov 17 07:21:23 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 17 Nov 2022 07:21:23 GMT Subject: Integrated: 8296222: SwingEventMonitor - installListeners(Component , int ) - CELLEDITOR - bug In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 08:01:38 GMT, Abhishek Kumar wrote: > It seems there was a typo inside function `installListeners(Component, int)` and `removeListeners(Component)` on case EventID.CELLEDITOR. > > Changed the string from "getCellEditorMethod" to "getCellEditor" in `protected void installListeners(Component c, int eventID)` and `protected void removeListeners(Component c)` methods. > > Didn't add any test case. This pull request has now been integrated. Changeset: 5795c760 Author: Abhishek Kumar Committer: Jayathirth D V URL: https://git.openjdk.org/jdk/commit/5795c760db5bbfd7ff3b56a0c6236827526df70a Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8296222: SwingEventMonitor - installListeners(Component , int ) - CELLEDITOR - bug Reviewed-by: angorya, kizune ------------- PR: https://git.openjdk.org/jdk/pull/11082 From jdv at openjdk.org Thu Nov 17 08:28:31 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 17 Nov 2022 08:28:31 GMT Subject: RFR: 8191406: [hidpi] sun/java2d/SunGraphics2D/DrawImageBilinear.java test fails Message-ID: <3mHTs6Gpmb2JPxOfF9Ii7-eBRsvLnsqykBu7gkltH-M=.a2979bc5-b386-4c5f-b621-30f2a993090d@github.com> This test was failing because of timing or color difference issues. Updated test to: 1) Use EDT for UI drawing instead of manual synchronisation 2) Use Robot.waitForIdle before screen capture 3) Increase color tolerance delta from 1 to 5 4) Use undecorated frame and explicitly set background color and move the frame to top 5) Cleanup to remove not needed flags and java options After these changes test passes on all platforms in CI except Linux. For Linux it looks like product issue so i have raised : https://bugs.openjdk.org/browse/JDK-8297175 ------------- Commit messages: - Remove image dump - ProblemList only on Linux - Add background color and tolerance - Initial change Changes: https://git.openjdk.org/jdk/pull/11201/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11201&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8191406 Stats: 129 lines in 2 files changed: 44 ins; 61 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/11201.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11201/head:pull/11201 PR: https://git.openjdk.org/jdk/pull/11201 From aivanov at openjdk.org Thu Nov 17 11:30:54 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 17 Nov 2022 11:30:54 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. [v4] In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 08:20:55 GMT, ravi gupta wrote: >> This testcase Verify the content changes of a TextArea for the following assertions. >> >> a. TextListener get invoked when the content of a TextArea gets changed. >> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8296632: Review fixes. Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11052 From aivanov at openjdk.org Thu Nov 17 11:30:57 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 17 Nov 2022 11:30:57 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. [v4] In-Reply-To: <1rtG0lprHMB1oeOEcSZsfpWj3IJ8t-QdZsEZw0yFB70=.6371c5c6-f888-42e3-938b-14d923f77b25@github.com> References: <5BZCbheS5XmeDRBUQrGuFeT58G3fJvxQrjMkQOgC9EE=.0374a5cf-7ce1-4455-840e-fdd68c31a409@github.com> <1rtG0lprHMB1oeOEcSZsfpWj3IJ8t-QdZsEZw0yFB70=.6371c5c6-f888-42e3-938b-14d923f77b25@github.com> Message-ID: <48yML77W0gevvSNMLP_oVQn9RnGdJ3s-DSdU1koHe4U=.f6368b03-eae0-4ef1-9419-3f822b5320f5@github.com> On Wed, 16 Nov 2022 19:58:27 GMT, Harshitha Onkar wrote: >> test/jdk/java/awt/event/ComponentEvent/TextAreaTextEventTest.java line 72: >> >>> 70: >>> 71: typeKey(KeyEvent.VK_T); >>> 72: >> >> In theory the autoWaitForIdle should ensure that events are processed. We'll see. >> If you find otherwise then here (and after typing the Enter key) it might be safer to do an additional robot.delay(500); >> You want to give every chance to process these events. > > Tested it locally on Win10. Works as expected. I agree with @prrace, adding additional delay would make sure that all events are processed. Without explicit `Robot.waitForIdle()` calls, the test looks as if something's missing. Adding it explicitly before checking a condition gives more confidence, the test has waited for the events to be processed. ------------- PR: https://git.openjdk.org/jdk/pull/11052 From aivanov at openjdk.org Thu Nov 17 13:09:05 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 17 Nov 2022 13:09:05 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem. [v3] In-Reply-To: References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> Message-ID: On Thu, 10 Nov 2022 05:14:36 GMT, Naveen Narayanan wrote: >> This testcase will >> 1) Verify setAccelerator method of JMenuitem. >> 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M. >> >> Testing: >> Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. > > Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: > > 8296275: Review comments fixed. test/jdk/java/awt/Desktop/JMenuItemSetAcceleratorTest.java line 51: > 49: private static JFrame frame; > 50: private volatile static CountDownLatch actionPerformLatch = > 51: new CountDownLatch(1); Suggestion: private final static CountDownLatch actionPerformLatch = new CountDownLatch(1); test/jdk/java/awt/Desktop/JMenuItemSetAcceleratorTest.java line 55: > 53: > 54: private static void createAndShow() { > 55: frame = new JFrame("Test Frame"); Suggestion: frame = new JFrame("JMenuItem.setAccelerator"); A more meaningful title is better than a very generic one, isn't it? test/jdk/java/awt/Desktop/JMenuItemSetAcceleratorTest.java line 81: > 79: try { > 80: if (!Desktop.isDesktopSupported() > 81: || !Desktop.getDesktop().isSupported(Action.APP_MENU_BAR)) { Why are you checking `APP_MENU_BAR` if you don't use it? Is the test indented for standard `JMenu` or the one that integrates with macOS menu bar? ------------- PR: https://git.openjdk.org/jdk/pull/11035 From pminborg at openjdk.org Thu Nov 17 14:34:36 2022 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 17 Nov 2022 14:34:36 GMT Subject: RFR: 8297210: Add a @sealedGraph tag to selected java.desktop classes Message-ID: <9JrgNVgMitVkUr_bsvGzpfCv56HYqvD6pRcPuMV8jts=.4f67596a-37d5-43f3-a353-bf1d276d61a5@github.com> This PR proposes to opt in for graphic rendering of the sealed hierarchy for some selected classes. Rendering capability was added via https://bugs.openjdk.org/browse/JDK-8295653 Here is how it would look like: MultipleGradientPaint_SH TextComponent_SH AppEvent_SH FilesEvent_SH InputEvent_SH Path2D_SH StyleConstants_SH ------------- Commit messages: - Remove some classes that did not render well - Add a @sealedGraph tag to java.deskop module classes Changes: https://git.openjdk.org/jdk/pull/11212/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11212&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297210 Stats: 7 lines in 7 files changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11212.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11212/head:pull/11212 PR: https://git.openjdk.org/jdk/pull/11212 From azvegint at openjdk.org Thu Nov 17 14:47:20 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 17 Nov 2022 14:47:20 GMT Subject: RFR: 8196018: java/awt/Scrollbar/ScrollbarMouseWheelTest/ScrollbarMouseWheelTest.java fails Message-ID: The issue contains evaluation that: * the test is not failing on Windows * it also fails on Linux(but provided stack trace with failure is from different test) I rechecked the test and it does not fail on all platforms. Test is stabilized: * replaced synchronization on windowActivated event with standard `robot.waitForIdle(); robot.delay(1000);` * Robot autoDelay decreased to 250 to make the test go faster. It it still a reasonable value. CI testing looks good also. ------------- Commit messages: - stabilize - clean up Changes: https://git.openjdk.org/jdk/pull/11213/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11213&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8196018 Stats: 51 lines in 2 files changed: 15 ins; 28 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/11213.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11213/head:pull/11213 PR: https://git.openjdk.org/jdk/pull/11213 From azvegint at openjdk.org Thu Nov 17 15:58:20 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 17 Nov 2022 15:58:20 GMT Subject: RFR: 8252713: jtreg time out of CtrlASCII.java seems to hang the Xserver. Message-ID: This test needs more stabilization: - The test can be easily hang by replacing
iteration on `keycharHash.elements()` with `keycharHash.forEach((k, v) -> punchCtrlKey(robot, v));` I do not see any reason why we need a synchronized `Hashtable`, so switched to `HashMap` Looks like it might be a reason of original test hanging. - `keyRelease`, `dispose` calls wrapped with finally block - Just to be safe added timeout `@run main/timeout=600` ( none of the CI test runs took too long thought) CI testing looks good on all platforms. ------------- Commit messages: - stabilize - clean up - Hashtable to HashMap Changes: https://git.openjdk.org/jdk/pull/11214/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11214&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8252713 Stats: 217 lines in 2 files changed: 58 ins; 55 del; 104 mod Patch: https://git.openjdk.org/jdk/pull/11214.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11214/head:pull/11214 PR: https://git.openjdk.org/jdk/pull/11214 From psadhukhan at openjdk.org Thu Nov 17 16:22:29 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 17 Nov 2022 16:22:29 GMT Subject: RFR: 8196018: java/awt/Scrollbar/ScrollbarMouseWheelTest/ScrollbarMouseWheelTest.java fails In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 14:38:41 GMT, Alexander Zvegintsev wrote: > The issue contains evaluation that: > * the test is not failing on Windows > * it also fails on Linux(but provided stack trace with failure is from different test) > > I rechecked the test and it does not fail on all platforms. > > Test is stabilized: > * replaced synchronization on windowActivated event with standard `robot.waitForIdle(); robot.delay(1000);` > * Robot autoDelay decreased to 250 to make the test go faster. It it still a reasonable value. > > CI testing looks good also. Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11213 From serb at openjdk.org Thu Nov 17 17:13:38 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 17 Nov 2022 17:13:38 GMT Subject: RFR: 8297195: AWTAccessor and SwingAccessor should avoid double racy reads from non-volatile fields Message-ID: The patch applied to SharedSecrets by https://github.com/openjdk/jdk/pull/1914 is applied to the AWTAccessor and SwingAccessor. It prevents null to be returned by the some of methods. See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html ------------- Commit messages: - Update AWTAccessor.java - 8297195: AWTAccessor and SwingAccessor should avoid double racy reads from non-volatile fields Changes: https://git.openjdk.org/jdk/pull/11205/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11205&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297195 Stats: 156 lines in 2 files changed: 74 ins; 6 del; 76 mod Patch: https://git.openjdk.org/jdk/pull/11205.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11205/head:pull/11205 PR: https://git.openjdk.org/jdk/pull/11205 From duke at openjdk.org Thu Nov 17 17:24:37 2022 From: duke at openjdk.org (ravi gupta) Date: Thu, 17 Nov 2022 17:24:37 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent [v5] In-Reply-To: References: Message-ID: <0M8Bj5jQPN_I6K7oNzT7IL1rwJ0z_goj4dtSdpR-dnE=.73dfa9b0-ca56-4ac3-bd5e-45d991821c52@github.com> > This testcase Verify the content changes of a TextArea for the following assertions. > > a. TextListener get invoked when the content of a TextArea gets changed. > b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. > > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. ravi gupta has updated the pull request incrementally with one additional commit since the last revision: 8296632: Review Fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11052/files - new: https://git.openjdk.org/jdk/pull/11052/files/3106d5bc..d91bdcc4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11052&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11052&range=03-04 Stats: 6 lines in 1 file changed: 1 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11052.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11052/head:pull/11052 PR: https://git.openjdk.org/jdk/pull/11052 From duke at openjdk.org Thu Nov 17 17:24:37 2022 From: duke at openjdk.org (ravi gupta) Date: Thu, 17 Nov 2022 17:24:37 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent [v4] In-Reply-To: <48yML77W0gevvSNMLP_oVQn9RnGdJ3s-DSdU1koHe4U=.f6368b03-eae0-4ef1-9419-3f822b5320f5@github.com> References: <5BZCbheS5XmeDRBUQrGuFeT58G3fJvxQrjMkQOgC9EE=.0374a5cf-7ce1-4455-840e-fdd68c31a409@github.com> <1rtG0lprHMB1oeOEcSZsfpWj3IJ8t-QdZsEZw0yFB70=.6371c5c6-f888-42e3-938b-14d923f77b25@github.com> <48yML77W0gevvSNMLP_oVQn9RnGdJ3s-DSdU1koHe4U=.f6368b03-eae0-4ef1-9419-3f822b5320f5@github.com> Message-ID: On Thu, 17 Nov 2022 11:27:07 GMT, Alexey Ivanov wrote: >> Tested it locally on Win10. Works as expected. I agree with @prrace, adding additional delay would make sure that all events are processed. > > Without explicit `Robot.waitForIdle()` calls, the test looks as if something's missing. Adding it explicitly before checking a condition gives more confidence, the test has waited for the events to be processed. Called Robot.waitForIdle() explicitly to make sure that all events are processed before checking a condition. ------------- PR: https://git.openjdk.org/jdk/pull/11052 From honkar at openjdk.org Thu Nov 17 17:32:32 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 17 Nov 2022 17:32:32 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent [v4] In-Reply-To: <48yML77W0gevvSNMLP_oVQn9RnGdJ3s-DSdU1koHe4U=.f6368b03-eae0-4ef1-9419-3f822b5320f5@github.com> References: <5BZCbheS5XmeDRBUQrGuFeT58G3fJvxQrjMkQOgC9EE=.0374a5cf-7ce1-4455-840e-fdd68c31a409@github.com> <1rtG0lprHMB1oeOEcSZsfpWj3IJ8t-QdZsEZw0yFB70=.6371c5c6-f888-42e3-938b-14d923f77b25@github.com> <48yML77W0gevvSNMLP_oVQn9RnGdJ3s-DSdU1koHe4U=.f6368b03-eae0-4ef1-9419-3f822b5320f5@github.com> Message-ID: On Thu, 17 Nov 2022 11:27:07 GMT, Alexey Ivanov wrote: >> Tested it locally on Win10. Works as expected. I agree with @prrace, adding additional delay would make sure that all events are processed. > > Without explicit `Robot.waitForIdle()` calls, the test looks as if something's missing. Adding it explicitly before checking a condition gives more confidence, the test has waited for the events to be processed. @aivanov-jdk A quick clarification - Since `robot.setAutoWaitForIdle(true);` is set to true would it be required to add `waitForIdle()` calls explicitly too? https://github.com/openjdk/jdk/blob/9c432a09dbf1824d793cc1a49b533e57f2316b62/src/java.desktop/share/classes/java/awt/Robot.java#L606 ------------- PR: https://git.openjdk.org/jdk/pull/11052 From serb at openjdk.org Thu Nov 17 17:47:16 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 17 Nov 2022 17:47:16 GMT Subject: RFR: 8191406: [hidpi] sun/java2d/SunGraphics2D/DrawImageBilinear.java test fails In-Reply-To: <3mHTs6Gpmb2JPxOfF9Ii7-eBRsvLnsqykBu7gkltH-M=.a2979bc5-b386-4c5f-b621-30f2a993090d@github.com> References: <3mHTs6Gpmb2JPxOfF9Ii7-eBRsvLnsqykBu7gkltH-M=.a2979bc5-b386-4c5f-b621-30f2a993090d@github.com> Message-ID: On Thu, 17 Nov 2022 08:20:54 GMT, Jayathirth D V wrote: >Increase color tolerance delta from 1 to 5 I see that the tolerance is added to the test, previously it was 0. Why do we need it since we use quite simple RED color? ------------- PR: https://git.openjdk.org/jdk/pull/11201 From azvegint at openjdk.org Thu Nov 17 17:51:20 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 17 Nov 2022 17:51:20 GMT Subject: RFR: 8297195: AWTAccessor and SwingAccessor should avoid double racy reads from non-volatile fields In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 10:19:31 GMT, Sergey Bylokhov wrote: > The patch applied to SharedSecrets by https://github.com/openjdk/jdk/pull/1914 is applied to the AWTAccessor and SwingAccessor. It prevents null to be returned by the some of methods. > > See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html Looks good to me. ------------- Marked as reviewed by azvegint (Reviewer). PR: https://git.openjdk.org/jdk/pull/11205 From serb at openjdk.org Thu Nov 17 17:51:22 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 17 Nov 2022 17:51:22 GMT Subject: RFR: 8191406: [hidpi] sun/java2d/SunGraphics2D/DrawImageBilinear.java test fails In-Reply-To: <3mHTs6Gpmb2JPxOfF9Ii7-eBRsvLnsqykBu7gkltH-M=.a2979bc5-b386-4c5f-b621-30f2a993090d@github.com> References: <3mHTs6Gpmb2JPxOfF9Ii7-eBRsvLnsqykBu7gkltH-M=.a2979bc5-b386-4c5f-b621-30f2a993090d@github.com> Message-ID: On Thu, 17 Nov 2022 08:20:54 GMT, Jayathirth D V wrote: > This test was failing because of timing or color difference issues. > Updated test to: > > 1) Use EDT for UI drawing instead of manual synchronisation > 2) Use Robot.waitForIdle before screen capture > 3) Increase color tolerance delta from 1 to 5 > 4) Use undecorated frame and explicitly set background color and move the frame to top > 5) Cleanup to remove not needed flags and java options > > After these changes test passes on all platforms in CI except Linux. For Linux it looks like product issue so i have raised : https://bugs.openjdk.org/browse/JDK-8297175 test/jdk/sun/java2d/SunGraphics2D/DrawImageBilinear.java line 151: > 149: frame = new Frame(); > 150: frame.add(test); > 151: frame.setBackground(Color.WHITE); How the specific background color helps the test to pass, as far as I understand it should not affect the test, no? ------------- PR: https://git.openjdk.org/jdk/pull/11201 From serb at openjdk.org Thu Nov 17 17:57:29 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 17 Nov 2022 17:57:29 GMT Subject: RFR: 8196018: java/awt/Scrollbar/ScrollbarMouseWheelTest/ScrollbarMouseWheelTest.java fails In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 14:38:41 GMT, Alexander Zvegintsev wrote: > The issue contains evaluation: > * the test is not failing on Windows > * it also fails on Linux(but provided stack trace with failure is from different test) > > I rechecked the test and it does not fail on all platforms. > > Test is stabilized: > * replaced synchronization on windowActivated event with standard `robot.waitForIdle(); robot.delay(1000);` > * Robot autoDelay decreased to 250 to make the test go faster. It it still a reasonable value. > > CI testing looks good also. test/jdk/java/awt/Scrollbar/ScrollbarMouseWheelTest/ScrollbarMouseWheelTest.java line 114: > 112: > 113: System.out.println("Test done."); > 114: if (sb1upevents == REPS && Note that all these flags are updated on one thread and used on another. ------------- PR: https://git.openjdk.org/jdk/pull/11213 From serb at openjdk.org Thu Nov 17 18:04:21 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 17 Nov 2022 18:04:21 GMT Subject: RFR: 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout [v3] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 19:46:03 GMT, Alexander Zuev wrote: > we do not access counter on another thread until the flag is changed. But we access it on a different thread w/o any synchronization, which we should add. ------------- PR: https://git.openjdk.org/jdk/pull/11157 From serb at openjdk.org Thu Nov 17 18:07:19 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 17 Nov 2022 18:07:19 GMT Subject: RFR: 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout [v3] In-Reply-To: References: <3W-OC_EeYya8hQKeGwfpAnBUylk18dq1c4CP5fSKkyw=.e86a1209-7c2a-4330-a40d-85812a829f82@github.com> <-38WA-JoLOxToMxxTck2FCETqVKkzmuKyFk68GEBZQM=.e231d4d0-dfc3-4d5e-9f58-32428cff6f1b@github.com> Message-ID: On Thu, 17 Nov 2022 03:19:31 GMT, Prasanta Sadhukhan wrote: >>> Do we not need to do seq.stop() before close() in l136 >> >> On that line we never call start() on the sequencer so calling stop() is redundant. > > ok, understood... Still have a question why we skip this duplicates and do not consider them as a bug? ------------- PR: https://git.openjdk.org/jdk/pull/11157 From serb at openjdk.org Thu Nov 17 18:10:20 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 17 Nov 2022 18:10:20 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent [v5] In-Reply-To: <0M8Bj5jQPN_I6K7oNzT7IL1rwJ0z_goj4dtSdpR-dnE=.73dfa9b0-ca56-4ac3-bd5e-45d991821c52@github.com> References: <0M8Bj5jQPN_I6K7oNzT7IL1rwJ0z_goj4dtSdpR-dnE=.73dfa9b0-ca56-4ac3-bd5e-45d991821c52@github.com> Message-ID: On Thu, 17 Nov 2022 17:24:37 GMT, ravi gupta wrote: >> This testcase Verify the content changes of a TextArea for the following assertions. >> >> a. TextListener get invoked when the content of a TextArea gets changed. >> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8296632: Review Fixes Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11052 From serb at openjdk.org Thu Nov 17 18:12:57 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 17 Nov 2022 18:12:57 GMT Subject: RFR: 6257207: JTable.getDefaultEditor throws NullPointerException [v4] In-Reply-To: References: Message-ID: <3ks1bFoj90hTCR4HII-mS2zNhcD8JSuAWxdUaqRqglg=.8c6308db-b2b9-43f5-b5bc-3101c54740be@github.com> On Thu, 3 Nov 2022 03:17:34 GMT, Prasanta Sadhukhan wrote: >> If getDefaultEditor() is called before the JTable model is setup, it results in NPE. >> >> This is because when JTable sets its model, which ends up firing a table changed event. The testcase is listening for tableChanged events and querying the editor. But the editor isn't installed until after the model is set which results in NPE. >> Fix is to ensure initializeLocalVars() which initializes default editor is setup before JTable sets its model. >> >> No regression is observed in jtreg/jck testsuite with this change. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test review fix src/java.desktop/share/classes/javax/swing/JTable.java line 706: > 704: setModel(dm); > 705: > 706: initializeLocalVars(); Did we check that the NPE now can be occurred in the initializeLocalVars since the model at that point is null? For example the initializeLocalVars->setTableHeader->firePropertyChange("tableHeader"....)->in the listener the model will be null, while it was non null before the fix. ------------- PR: https://git.openjdk.org/jdk/pull/10871 From honkar at openjdk.org Thu Nov 17 18:40:20 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 17 Nov 2022 18:40:20 GMT Subject: RFR: JDK-8295813: misc client tests failing on Windows_11_Pro In-Reply-To: References: <8lLtmuOrcP6cmaHVBx91hxB8PDD7RO9irr5-BpyJEbk=.8edebaf4-ae38-463f-9809-d66016452198@github.com> Message-ID: <-nNZT4tOFhyXQF9iM_wsPA-bdXgjurhAj8pxZbx6U14=.35bd95ab-7c2b-470a-9254-2452d36a915f@github.com> On Fri, 11 Nov 2022 01:28:24 GMT, Sergey Bylokhov wrote: > What is changed in Windows 11 that the test fails on the HiDPI monitor? @mrserb Earlier I thought the intermittent issue might be due to wrong color being picked up by Robot at the edges on HiDPI monitor. But it seems to be happening only when a batch of AWT_Mixing tests are run. There are couple of more client tests being analyzed as part this bug currently, hence converting this PR into draft until further updates. ------------- PR: https://git.openjdk.org/jdk/pull/11097 From serb at openjdk.org Thu Nov 17 18:50:35 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 17 Nov 2022 18:50:35 GMT Subject: RFR: 8022403: sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java fails [v4] In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 04:04:31 GMT, Jayathirth D V wrote: >> test/jdk/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java line 89: >> >>> 87: >>> 88: final Frame frame = new Frame("OnScreenRenderingResizeTest") { >>> 89: public void paint(Graphics g) {} >> >> Looks like these two empty methods are removed by the fix, why? > > We creating frame on EDT and running animation in main(). > I didnt see any change by removing empty paint() method of frame(), thats why it is removed as cleanup. That empty methods were there to eliminate the clearing the frame by default implementation of it in Window/Container/Component. ------------- PR: https://git.openjdk.org/jdk/pull/11158 From achung at openjdk.org Thu Nov 17 19:16:31 2022 From: achung at openjdk.org (Alisen Chung) Date: Thu, 17 Nov 2022 19:16:31 GMT Subject: RFR: 8297088: Update LCMS to 2.14 Message-ID: Redo of 8295369: Update LCMS to 2.14 Update LCMS to newest release. Updated DISABLED_WARNINGS_gcc for LCMS to include type limits to prevent a build error in linux. Automatic tests and J2D demo tests were run. ------------- Commit messages: - disabled warning for type-limits for lcms - 8295369: Update LCMS to 2.14 Changes: https://git.openjdk.org/jdk/pull/11217/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11217&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297088 Stats: 2138 lines in 32 files changed: 1546 ins; 134 del; 458 mod Patch: https://git.openjdk.org/jdk/pull/11217.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11217/head:pull/11217 PR: https://git.openjdk.org/jdk/pull/11217 From kizune at openjdk.org Thu Nov 17 19:31:30 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 17 Nov 2022 19:31:30 GMT Subject: RFR: 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout [v3] In-Reply-To: References: <3W-OC_EeYya8hQKeGwfpAnBUylk18dq1c4CP5fSKkyw=.e86a1209-7c2a-4330-a40d-85812a829f82@github.com> <-38WA-JoLOxToMxxTck2FCETqVKkzmuKyFk68GEBZQM=.e231d4d0-dfc3-4d5e-9f58-32428cff6f1b@github.com> Message-ID: On Thu, 17 Nov 2022 18:05:09 GMT, Sergey Bylokhov wrote: > Still have a question why we skip this duplicates and do not consider them as a bug? I do not have enough information to act on this issue because while not being problem listed it only occurred twice on CI system and in more than a thousand runs i was able to reproduce it once on my local system and unable to reproduce it again with all the output i've added to the code. So what i am planning to do is to leave workaround code in place but for now i will disable it and instead use it as an indicator of the problem and add a debugging output so if this issue will reappear we will have better understanding of the potential problem. ------------- PR: https://git.openjdk.org/jdk/pull/11157 From prr at openjdk.org Thu Nov 17 19:45:28 2022 From: prr at openjdk.org (Phil Race) Date: Thu, 17 Nov 2022 19:45:28 GMT Subject: RFR: 8252713: jtreg time out of CtrlASCII.java seems to hang the Xserver. In-Reply-To: References: Message-ID: <0xQkq5PsaZkF2aA9BF1l5LvdMsOIoeiHJm0s2RzEn2Q=.5cf6a802-1b8b-4900-b3b4-63fdd7ae1bb1@github.com> On Thu, 17 Nov 2022 15:51:50 GMT, Alexander Zvegintsev wrote: > This test needs more stabilization: > > - The test can be easily hang by replacing
iteration on `keycharHash.elements()` with `keycharHash.forEach((k, v) -> punchCtrlKey(robot, v));` > I do not see any reason why we need a synchronized `Hashtable`, so switched to `HashMap` > Looks like it might be a reason of original test hanging. > - `keyRelease`, `dispose` calls wrapped with finally block > - Just to be safe added timeout `@run main/timeout=600` ( none of the CI test runs took too long thought) > > CI testing looks good on all platforms. It was a deadlock on the table access, due to some internals of Hashtable this should cure it. Although I wonder if that wouldn't be a bug in the collections classes ? ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.org/jdk/pull/11214 From azvegint at openjdk.org Thu Nov 17 20:03:26 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 17 Nov 2022 20:03:26 GMT Subject: RFR: 8196018: java/awt/Scrollbar/ScrollbarMouseWheelTest/ScrollbarMouseWheelTest.java fails [v2] In-Reply-To: References: Message-ID: > The issue contains evaluation: > * the test is not failing on Windows > * it also fails on Linux(but provided stack trace with failure is from different test) > > I rechecked the test and it does not fail on all platforms. > > Test is stabilized: > * replaced synchronization on windowActivated event with standard `robot.waitForIdle(); robot.delay(1000);` > * Robot autoDelay decreased to 250 to make the test go faster. It it still a reasonable value. > > CI testing looks good also. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: addressing review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11213/files - new: https://git.openjdk.org/jdk/pull/11213/files/c2ada26e..1a75b89d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11213&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11213&range=00-01 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11213.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11213/head:pull/11213 PR: https://git.openjdk.org/jdk/pull/11213 From azvegint at openjdk.org Thu Nov 17 20:08:03 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 17 Nov 2022 20:08:03 GMT Subject: RFR: 8196018: java/awt/Scrollbar/ScrollbarMouseWheelTest/ScrollbarMouseWheelTest.java fails [v3] In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 17:53:38 GMT, Sergey Bylokhov wrote: >> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: >> >> removing extra waitForIdle(called automatically on mouseWheel because of setAutoWaitForIdle(true); > > test/jdk/java/awt/Scrollbar/ScrollbarMouseWheelTest/ScrollbarMouseWheelTest.java line 114: > >> 112: >> 113: System.out.println("Test done."); >> 114: if (sb1upevents == REPS && > > Note that all these flags are updated on one thread and used on another. Updated, also added extra delay after test. ------------- PR: https://git.openjdk.org/jdk/pull/11213 From azvegint at openjdk.org Thu Nov 17 20:08:01 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 17 Nov 2022 20:08:01 GMT Subject: RFR: 8196018: java/awt/Scrollbar/ScrollbarMouseWheelTest/ScrollbarMouseWheelTest.java fails [v3] In-Reply-To: References: Message-ID: > The issue contains evaluation: > * the test is not failing on Windows > * it also fails on Linux(but provided stack trace with failure is from different test) > > I rechecked the test and it does not fail on all platforms. > > Test is stabilized: > * replaced synchronization on windowActivated event with standard `robot.waitForIdle(); robot.delay(1000);` > * Robot autoDelay decreased to 250 to make the test go faster. It it still a reasonable value. > > CI testing looks good also. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: removing extra waitForIdle(called automatically on mouseWheel because of setAutoWaitForIdle(true); ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11213/files - new: https://git.openjdk.org/jdk/pull/11213/files/1a75b89d..80f3ee23 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11213&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11213&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11213.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11213/head:pull/11213 PR: https://git.openjdk.org/jdk/pull/11213 From aturbanov at openjdk.org Thu Nov 17 20:22:24 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 17 Nov 2022 20:22:24 GMT Subject: RFR: 8252713: jtreg time out of CtrlASCII.java seems to hang the Xserver. In-Reply-To: References: Message-ID: <7k5Itz2f40yEkRO0THulMZ9WqUtsd48Q7b1GGEISkH8=.b69b97c5-97dd-4374-a598-4ecb0ec3f393@github.com> On Thu, 17 Nov 2022 15:51:50 GMT, Alexander Zvegintsev wrote: > This test needs more stabilization: > > - The test can be easily hang by replacing
iteration on `keycharHash.elements()` with `keycharHash.forEach((k, v) -> punchCtrlKey(robot, v));` > I do not see any reason why we need a synchronized `Hashtable`, so switched to `HashMap` > Looks like it might be a reason of original test hanging. > - `keyRelease`, `dispose` calls wrapped with finally block > - Just to be safe added timeout `@run main/timeout=600` ( none of the CI test runs took too long thought) > > CI testing looks good on all platforms. test/jdk/java/awt/event/KeyEvent/KeyTyped/CtrlASCII.java line 247: > 245: printKey(evt); > 246: char keych = evt.getKeyChar(); > 247: if( !KEYCHAR_MAP.containsKey( keych ) ) { Suggestion: if (!KEYCHAR_MAP.containsKey( keych )) { ------------- PR: https://git.openjdk.org/jdk/pull/11214 From aturbanov at openjdk.org Thu Nov 17 20:24:24 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 17 Nov 2022 20:24:24 GMT Subject: RFR: 8282404: DrawStringWithInfiniteXform.java failed with "RuntimeException: drawString with InfiniteXform transform takes long time" [v2] In-Reply-To: <23B-3108dezud6Ku_Wj_MT3S1emh8SDNA_ob5BLbfzY=.a1d35e80-f15b-402c-a7e7-906b1a0533d1@github.com> References: <23B-3108dezud6Ku_Wj_MT3S1emh8SDNA_ob5BLbfzY=.a1d35e80-f15b-402c-a7e7-906b1a0533d1@github.com> Message-ID: On Wed, 16 Nov 2022 17:35:25 GMT, Phil Race wrote: >> This test is not problem listed and has failed only once since (SFAIK) it was last updated a year ago so >> this is just another small attempt to remove instability by increasing timeout, being really insistent about >> making sure the "done=true" is propagated and adding some extra timing logging to help analyse any failures > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8282404 test/jdk/java/awt/FontClass/DrawStringWithInfiniteXform.java line 46: > 44: System.out.println("Task running at " + System.currentTimeMillis()); > 45: System.out.flush(); > 46: synchronized(DrawStringWithInfiniteXform.class) { Nit Suggestion: synchronized (DrawStringWithInfiniteXform.class) { ------------- PR: https://git.openjdk.org/jdk/pull/11179 From prr at openjdk.org Thu Nov 17 20:35:01 2022 From: prr at openjdk.org (Phil Race) Date: Thu, 17 Nov 2022 20:35:01 GMT Subject: RFR: 8282404: DrawStringWithInfiniteXform.java failed with "RuntimeException: drawString with InfiniteXform transform takes long time" [v3] In-Reply-To: References: Message-ID: <2XQDUlwzVxO16V3fjJKy1k0sG2WcWC6XGOueCAHxJv8=.c380cd9b-5eea-41ff-928f-f083edfcf0dc@github.com> > This test is not problem listed and has failed only once since (SFAIK) it was last updated a year ago so > this is just another small attempt to remove instability by increasing timeout, being really insistent about > making sure the "done=true" is propagated and adding some extra timing logging to help analyse any failures Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8282404 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11179/files - new: https://git.openjdk.org/jdk/pull/11179/files/7becd787..3acdd9ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11179&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11179&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11179.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11179/head:pull/11179 PR: https://git.openjdk.org/jdk/pull/11179 From prr at openjdk.org Thu Nov 17 20:36:43 2022 From: prr at openjdk.org (Phil Race) Date: Thu, 17 Nov 2022 20:36:43 GMT Subject: Integrated: 8282404: DrawStringWithInfiniteXform.java failed with "RuntimeException: drawString with InfiniteXform transform takes long time" In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 03:44:24 GMT, Phil Race wrote: > This test is not problem listed and has failed only once since (SFAIK) it was last updated a year ago so > this is just another small attempt to remove instability by increasing timeout, being really insistent about > making sure the "done=true" is propagated and adding some extra timing logging to help analyse any failures This pull request has now been integrated. Changeset: a53be204 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/a53be204cbc8671ab998e1165f983af3a50e4ae2 Stats: 29 lines in 1 file changed: 15 ins; 0 del; 14 mod 8282404: DrawStringWithInfiniteXform.java failed with "RuntimeException: drawString with InfiniteXform transform takes long time" Reviewed-by: psadhukhan, jdv ------------- PR: https://git.openjdk.org/jdk/pull/11179 From erikj at openjdk.org Thu Nov 17 20:38:44 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 17 Nov 2022 20:38:44 GMT Subject: RFR: 8297088: Update LCMS to 2.14 In-Reply-To: References: Message-ID: <04uBn0FTAqiDocPk9RgbcjcuP5pXhJmiASyZqKb4S7o=.714e7a70-008e-4b86-97da-7015cccda764@github.com> On Thu, 17 Nov 2022 19:05:36 GMT, Alisen Chung wrote: > Redo of 8295369: Update LCMS to 2.14 > Update LCMS to newest release. > Updated DISABLED_WARNINGS_gcc for LCMS to include type limits to prevent a build error in linux. > Automatic tests and J2D demo tests were run. Build change looks good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.org/jdk/pull/11217 From aivanov at openjdk.org Thu Nov 17 20:45:37 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 17 Nov 2022 20:45:37 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent [v5] In-Reply-To: <0M8Bj5jQPN_I6K7oNzT7IL1rwJ0z_goj4dtSdpR-dnE=.73dfa9b0-ca56-4ac3-bd5e-45d991821c52@github.com> References: <0M8Bj5jQPN_I6K7oNzT7IL1rwJ0z_goj4dtSdpR-dnE=.73dfa9b0-ca56-4ac3-bd5e-45d991821c52@github.com> Message-ID: On Thu, 17 Nov 2022 17:24:37 GMT, ravi gupta wrote: >> This testcase Verify the content changes of a TextArea for the following assertions. >> >> a. TextListener get invoked when the content of a TextArea gets changed. >> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8296632: Review Fixes Marked as reviewed by aivanov (Reviewer). test/jdk/java/awt/event/ComponentEvent/TextAreaTextEventTest.java line 56: > 54: robot = new Robot(); > 55: robot.setAutoDelay(100); > 56: robot.setAutoWaitForIdle(true); If you call `waitForIdle` explicitly, this may be redundant. Yet it may make the test more stable as the robot allows processing all the events before the next event is generated. test/jdk/java/awt/event/ComponentEvent/TextAreaTextEventTest.java line 86: > 84: robot.waitForIdle(); > 85: > 86: if (!textChanged) { A nit: in other places, the blank line is above `waitForIdle`. ------------- PR: https://git.openjdk.org/jdk/pull/11052 From azvegint at openjdk.org Thu Nov 17 20:51:19 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 17 Nov 2022 20:51:19 GMT Subject: RFR: 8252713: jtreg time out of CtrlASCII.java seems to hang the Xserver. In-Reply-To: <0xQkq5PsaZkF2aA9BF1l5LvdMsOIoeiHJm0s2RzEn2Q=.5cf6a802-1b8b-4900-b3b4-63fdd7ae1bb1@github.com> References: <0xQkq5PsaZkF2aA9BF1l5LvdMsOIoeiHJm0s2RzEn2Q=.5cf6a802-1b8b-4900-b3b4-63fdd7ae1bb1@github.com> Message-ID: On Thu, 17 Nov 2022 19:43:14 GMT, Phil Race wrote: > Although I wonder if that wouldn't be a bug in the collections classes ? Don't think so, * `invokeAndWait` is called on main thread while holding lock on the hashtable * synchronized `Hastable#containsKey` method is called on EDT So EDT is blocked by hashtable, main is waiting while event posted to EDT will be processed. stacktraces are below: > "main" #1 [223509] prio=5 os_prio=0 cpu=646,16ms elapsed=70,88s tid=0x00007fe2d4029a70 nid=223509 in Object.wait() [0x00007fe2d9449000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait0(java.base at 20-ea/Native Method) - waiting on <0x0000000629436510> (a java.awt.EventQueue$1AWTInvocationLock) at java.lang.Object.wait(java.base at 20-ea/Object.java:366) at java.lang.Object.wait(java.base at 20-ea/Object.java:339) **at java.awt.EventQueue.invokeAndWait(java.desktop at 20-ea/EventQueue.java:1365)** - locked <0x0000000629436510> (a java.awt.EventQueue$1AWTInvocationLock) at java.awt.EventQueue.invokeAndWait(java.desktop at 20-ea/EventQueue.java:1346) at sun.awt.SunToolkit.realSync(java.desktop at 20-ea/SunToolkit.java:1492) at sun.awt.SunToolkit.realSync(java.desktop at 20-ea/SunToolkit.java:1438) at java.awt.Robot.waitForIdle(java.desktop at 20-ea/Robot.java:688) - locked <0x0000000629428d30> (a java.awt.Robot) at java.awt.Robot.autoWaitForIdle(java.desktop at 20-ea/Robot.java:619) at java.awt.Robot.afterEvent(java.desktop at 20-ea/Robot.java:592) at java.awt.Robot.keyRelease(java.desktop at 20-ea/Robot.java:371) - locked <0x0000000629428d30> (a java.awt.Robot) at CtrlASCII.punchCtrlKey(CtrlASCII.java:225) at CtrlASCII.lambda$start$0(CtrlASCII.java:202) at CtrlASCII$$Lambda$343/0x0000000801151088.accept(Unknown Source) **at java.util.Hashtable.forEach(java.base at 20-ea/Hashtable.java:893) - locked <0x00000006298b6b40> (a java.util.Hashtable)** at CtrlASCII.start(CtrlASCII.java:201) at CtrlASCII.main(CtrlASCII.java:162) at java.lang.invoke.LambdaForm$DMH/0x0000000801030c00.invokeStatic(java.base at 20-ea/LambdaForm$DMH) at java.lang.invoke.LambdaForm$MH/0x0000000801158000.invoke(java.base at 20-ea/LambdaForm$MH) at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 20-ea/Invokers$Holder) at jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(java.base at 20-ea/DirectMethodHandleAccessor.java:155) at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(java.base at 20-ea/DirectMethodHandleAccessor.java:104) at java.lang.reflect.Method.invoke(java.base at 20-ea/Method.java:578) at com.sun.tools.javac.launcher.Main.execute(jdk.compiler at 20-ea/Main.java:435) at com.sun.tools.javac.launcher.Main.run(jdk.compiler at 20-ea/Main.java:205) at com.sun.tools.javac.launcher.Main.main(jdk.compiler at 20-ea/Main.java:132) > "AWT-EventQueue-0" #43 [223550] prio=6 os_prio=0 cpu=26,14ms elapsed=70,34s tid=0x00007fe21c006200 nid=223550 waiting for monitor entry [0x00007fe2a02e7000] java.lang.Thread.State: BLOCKED (on object monitor) **at java.util.Hashtable.containsKey(java.base at 20-ea/Hashtable.java:352)** - **waiting to lock <0x00000006298b6b40>** (a java.util.Hashtable) at CtrlASCII.keyTyped(CtrlASCII.java:241) at java.awt.Component.processKeyEvent(java.desktop at 20-ea/Component.java:6575) at java.awt.Component.processEvent(java.desktop at 20-ea/Component.java:6397) at java.awt.TextComponent.processEvent(java.desktop at 20-ea/TextComponent.java:694) at java.awt.TextField.processEvent(java.desktop at 20-ea/TextField.java:637) at java.awt.Component.dispatchEventImpl(java.desktop at 20-ea/Component.java:4995) at java.awt.Component.dispatchEvent(java.desktop at 20-ea/Component.java:4827) at java.awt.KeyboardFocusManager.redispatchEvent(java.desktop at 20-ea/KeyboardFocusManager.java:1952) at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(java.desktop at 20-ea/DefaultKeyboardFocusManager.java:883) at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(java.desktop at 20-ea/DefaultKeyboardFocusManager.java:1146) at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(java.desktop at 20-ea/DefaultKeyboardFocusManager.java:1020) at java.awt.DefaultKeyboardFocusManager.dispatchEvent(java.desktop at 20-ea/DefaultKeyboardFocusManager.java:848) at java.awt.Component.dispatchEventImpl(java.desktop at 20-ea/Component.java:4876) at java.awt.Container.dispatchEventImpl(java.desktop at 20-ea/Container.java:2324) at java.awt.Window.dispatchEventImpl(java.desktop at 20-ea/Window.java:2780) at java.awt.Component.dispatchEvent(java.desktop at 20-ea/Component.java:4827) at java.awt.EventQueue.dispatchEventImpl(java.desktop at 20-ea/EventQueue.java:775) at java.awt.EventQueue$4.run(java.desktop at 20-ea/EventQueue.java:720) at java.awt.EventQueue$4.run(java.desktop at 20-ea/EventQueue.java:714) at java.security.AccessController.executePrivileged(java.base at 20-ea/AccessController.java:778) at java.security.AccessController.doPrivileged(java.base at 20-ea/AccessController.java:400) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 20-ea/ProtectionDomain.java:87) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 20-ea/ProtectionDomain.java:98) at java.awt.EventQueue$5.run(java.desktop at 20-ea/EventQueue.java:747) at java.awt.EventQueue$5.run(java.desktop at 20-ea/EventQueue.java:745) at java.security.AccessController.executePrivileged(java.base at 20-ea/AccessController.java:778) at java.security.AccessController.doPrivileged(java.base at 20-ea/AccessController.java:400) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 20-ea/ProtectionDomain.java:87) at java.awt.EventQueue.dispatchEvent(java.desktop at 20-ea/EventQueue.java:744) at java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 20-ea/EventDispatchThread.java:203) at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 20-ea/EventDispatchThread.java:124) at java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 20-ea/EventDispatchThread.java:113) at java.awt.EventDispatchThread.pumpEvents(java.desktop at 20-ea/EventDispatchThread.java:109) at java.awt.EventDispatchThread.pumpEvents(java.desktop at 20-ea/EventDispatchThread.java:101) at java.awt.EventDispatchThread.run(java.desktop at 20-ea/EventDispatchThread.java:90) ------------- PR: https://git.openjdk.org/jdk/pull/11214 From azvegint at openjdk.org Thu Nov 17 20:57:39 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 17 Nov 2022 20:57:39 GMT Subject: RFR: 8252713: jtreg time out of CtrlASCII.java seems to hang the Xserver. [v2] In-Reply-To: References: Message-ID: > This test needs more stabilization: > > - The test can be easily hang by replacing
iteration on `keycharHash.elements()` with `keycharHash.forEach((k, v) -> punchCtrlKey(robot, v));` > I do not see any reason why we need a synchronized `Hashtable`, so switched to `HashMap` > Looks like it might be a reason of original test hanging. > - `keyRelease`, `dispose` calls wrapped with finally block > - Just to be safe added timeout `@run main/timeout=600` ( none of the CI test runs took too long thought) > > CI testing looks good on all platforms. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: formatting clean up ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11214/files - new: https://git.openjdk.org/jdk/pull/11214/files/e53dcead..102ff6c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11214&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11214&range=00-01 Stats: 20 lines in 1 file changed: 0 ins; 2 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/11214.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11214/head:pull/11214 PR: https://git.openjdk.org/jdk/pull/11214 From prr at openjdk.org Thu Nov 17 21:12:02 2022 From: prr at openjdk.org (Phil Race) Date: Thu, 17 Nov 2022 21:12:02 GMT Subject: RFR: 8285604: closed sun/java2d/GdiRendering/ClipShapeRendering.java failed with "Incorrect color ffeeeeee instead of ff0000ff in pixel (100, 100)" Message-ID: This was a closed test. It fails very rarely due to completely incorrect colour sampling by Robot. I had this happen to me when the window came up behind some other window on my desktop. So the "fix" here is to use setAlwaysOnTop(true) But so far as I can see there's no reason for this test to be closed so I am moving it to open as well. ------------- Commit messages: - 8285604 Changes: https://git.openjdk.org/jdk/pull/11221/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11221&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8285604 Stats: 518 lines in 1 file changed: 518 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11221.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11221/head:pull/11221 PR: https://git.openjdk.org/jdk/pull/11221 From honkar at openjdk.org Thu Nov 17 22:14:31 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 17 Nov 2022 22:14:31 GMT Subject: RFR: 8023562: [TEST_BUG] java/awt/Mouse/EnterExitEvents/DragWindowTest.java failed on ubuntu 13 and mac 10.11 In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 01:46:06 GMT, Alisen Chung wrote: > Test was run on macos and linux 100x and passed. Removing from ProblemList Marked as reviewed by honkar (Author). ------------- PR: https://git.openjdk.org/jdk/pull/11152 From lbourges at openjdk.org Thu Nov 17 23:00:18 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Thu, 17 Nov 2022 23:00:18 GMT Subject: RFR: JDK-8297230: Update Marlin2D to 0.9.4.6 Message-ID: Initial PR ------------- Commit messages: - JDK-8297230: Update Marlin2D to 0.9.4.6 Changes: https://git.openjdk.org/jdk/pull/11225/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11225&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297230 Stats: 4142 lines in 37 files changed: 2668 ins; 1102 del; 372 mod Patch: https://git.openjdk.org/jdk/pull/11225.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11225/head:pull/11225 PR: https://git.openjdk.org/jdk/pull/11225 From achung at openjdk.org Thu Nov 17 23:20:21 2022 From: achung at openjdk.org (Alisen Chung) Date: Thu, 17 Nov 2022 23:20:21 GMT Subject: RFR: 8023562: [TEST_BUG] java/awt/Mouse/EnterExitEvents/DragWindowTest.java failed on ubuntu 13 and mac 10.11 In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 18:30:02 GMT, Alexander Zvegintsev wrote: >> Test was run on macos and linux 100x and passed. Removing from ProblemList > > Marked as reviewed by azvegint (Reviewer). > There is JBS comment from @azvegint about test update for this bug. Is that change still applicable or not? Looks like the comment is no longer applicable, it was fixed on the linux/mac side. > @alisenchung Please add CI test link in JBS for reference. Done! ------------- PR: https://git.openjdk.org/jdk/pull/11152 From dnguyen at openjdk.org Fri Nov 18 00:25:24 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 18 Nov 2022 00:25:24 GMT Subject: RFR: 8239801: [macos] java/awt/Focus/UnaccessibleChoice/AccessibleChoiceTest.java fails Message-ID: <1ucV0BHh8XBiFbdJncIVAPXAPXmgJEwDD8f9EWmssnQ=.48c4c221-c5a0-4211-9d15-6de0c7a7da87@github.com> This is an older test that failed intermittently but had a fix specifically for mac systems by adding key presses on mac only. This test still intermittently failed after this fix long ago and was problem listed. I ran this test 100 times on each OS after applying waitForIdle and delays between all key presses to match the delays previously present in the test. I also added a debug line and save and image of the failing window upon failure to better debug if/when the test ever fails again. The debug line is to check if the previous fix for mac is relevant in the failure. The image shows the status of the window and what is focused at the time of failure. ------------- Commit messages: - Update test with standardized delays and waitForIdle after window is visible. Add debug line and image for potential future failures. Changes: https://git.openjdk.org/jdk/pull/11227/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11227&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8239801 Stats: 26 lines in 2 files changed: 19 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11227.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11227/head:pull/11227 PR: https://git.openjdk.org/jdk/pull/11227 From jdv at openjdk.org Fri Nov 18 04:44:17 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Fri, 18 Nov 2022 04:44:17 GMT Subject: RFR: 8023562: [TEST_BUG] java/awt/Mouse/EnterExitEvents/DragWindowTest.java failed on ubuntu 13 and mac 10.11 In-Reply-To: References: Message-ID: <-nSPA8wWES8wSuP8oYkLgjNm9cjE70-lMIr0zw2Sd7U=.c4d69554-e049-4a48-8352-fbae43067edd@github.com> On Tue, 15 Nov 2022 01:46:06 GMT, Alisen Chung wrote: > Test was run on macos and linux 100x and passed. Removing from ProblemList Marked as reviewed by jdv (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11152 From jdv at openjdk.org Fri Nov 18 05:19:29 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Fri, 18 Nov 2022 05:19:29 GMT Subject: RFR: 8022403: sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java fails [v4] In-Reply-To: References: Message-ID: <1ai4RZKvGpqPt9byaTlvp8pQCO8h0Eeg2y6oIAV9k7g=.c0d4cbf9-d44d-4924-a9ad-b521b5073325@github.com> On Thu, 17 Nov 2022 18:48:27 GMT, Sergey Bylokhov wrote: >> We creating frame on EDT and running animation in main(). >> I didnt see any change by removing empty paint() method of frame(), thats why it is removed as cleanup. > > That empty methods were there to eliminate the clearing the frame by default implementation of it in Window/Container/Component. Okay. Since this is already integrated i have created https://bugs.openjdk.org/browse/JDK-8297241 to verify and update the test as per this thread. ------------- PR: https://git.openjdk.org/jdk/pull/11158 From xuelei at openjdk.org Fri Nov 18 05:48:13 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 18 Nov 2022 05:48:13 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v8] In-Reply-To: References: Message-ID: > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: assert os::snprintf return value ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11115/files - new: https://git.openjdk.org/jdk/pull/11115/files/f2158c8b..dcd7a8df Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=06-07 Stats: 271 lines in 23 files changed: 181 ins; 1 del; 89 mod Patch: https://git.openjdk.org/jdk/pull/11115.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11115/head:pull/11115 PR: https://git.openjdk.org/jdk/pull/11115 From xuelei at openjdk.org Fri Nov 18 06:42:24 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 18 Nov 2022 06:42:24 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v9] In-Reply-To: References: Message-ID: <3vPeF8_u7AOdiGQRRw5xT66iRe9rhrb1OTDTt0Fef0k=.a3ad1514-2185-4e75-9a78-01e37e4daa8d@github.com> > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: size_t cast ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11115/files - new: https://git.openjdk.org/jdk/pull/11115/files/dcd7a8df..59a87dd1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=07-08 Stats: 38 lines in 18 files changed: 0 ins; 0 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/11115.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11115/head:pull/11115 PR: https://git.openjdk.org/jdk/pull/11115 From jdv at openjdk.org Fri Nov 18 06:44:51 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Fri, 18 Nov 2022 06:44:51 GMT Subject: RFR: 8191406: [hidpi] sun/java2d/SunGraphics2D/DrawImageBilinear.java test fails In-Reply-To: References: <3mHTs6Gpmb2JPxOfF9Ii7-eBRsvLnsqykBu7gkltH-M=.a2979bc5-b386-4c5f-b621-30f2a993090d@github.com> Message-ID: <7-DK3KOUZtyhJVGGJYprGVMcLpAIHZKoHoXH-EDt8_8=.c2b932e1-2a17-45e1-9651-80ce105c494d@github.com> On Thu, 17 Nov 2022 17:49:09 GMT, Sergey Bylokhov wrote: >> This test was failing because of timing or color difference issues. >> Updated test to: >> >> 1) Use EDT for UI drawing instead of manual synchronisation >> 2) Use Robot.waitForIdle before screen capture >> 3) Increase color tolerance delta from 1 to 5 >> 4) Use undecorated frame and explicitly set background color and move the frame to top >> 5) Cleanup to remove not needed flags and java options >> >> After these changes test passes on all platforms in CI except Linux. For Linux it looks like product issue so i have raised : https://bugs.openjdk.org/browse/JDK-8297175 > > test/jdk/sun/java2d/SunGraphics2D/DrawImageBilinear.java line 151: > >> 149: frame = new Frame(); >> 150: frame.add(test); >> 151: frame.setBackground(Color.WHITE); > > How the specific background color helps the test to pass, as far as I understand it should not affect the test, no? I noticed in my local Ubuntu VM that sometimes the background was not pure white and had some delta. Thats why i explicitly added background color. But looks like it is not needed and test passes all the time in CI, so i have removed it. ------------- PR: https://git.openjdk.org/jdk/pull/11201 From jdv at openjdk.org Fri Nov 18 06:49:38 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Fri, 18 Nov 2022 06:49:38 GMT Subject: RFR: 8191406: [hidpi] sun/java2d/SunGraphics2D/DrawImageBilinear.java test fails [v2] In-Reply-To: <3mHTs6Gpmb2JPxOfF9Ii7-eBRsvLnsqykBu7gkltH-M=.a2979bc5-b386-4c5f-b621-30f2a993090d@github.com> References: <3mHTs6Gpmb2JPxOfF9Ii7-eBRsvLnsqykBu7gkltH-M=.a2979bc5-b386-4c5f-b621-30f2a993090d@github.com> Message-ID: > This test was failing because of timing or color difference issues. > Updated test to: > > 1) Use EDT for UI drawing instead of manual synchronisation > 2) Use Robot.waitForIdle before screen capture > 3) Increase color tolerance delta from 1 to 5 > 4) Use undecorated frame and explicitly set background color and move the frame to top > 5) Cleanup to remove not needed flags and java options > > After these changes test passes on all platforms in CI except Linux. For Linux it looks like product issue so i have raised : https://bugs.openjdk.org/browse/JDK-8297175 Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: Remove extra tolerance and background color ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11201/files - new: https://git.openjdk.org/jdk/pull/11201/files/60c75caa..ec464893 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11201&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11201&range=00-01 Stats: 15 lines in 1 file changed: 0 ins; 14 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11201.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11201/head:pull/11201 PR: https://git.openjdk.org/jdk/pull/11201 From jdv at openjdk.org Fri Nov 18 06:49:38 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Fri, 18 Nov 2022 06:49:38 GMT Subject: RFR: 8191406: [hidpi] sun/java2d/SunGraphics2D/DrawImageBilinear.java test fails In-Reply-To: References: <3mHTs6Gpmb2JPxOfF9Ii7-eBRsvLnsqykBu7gkltH-M=.a2979bc5-b386-4c5f-b621-30f2a993090d@github.com> Message-ID: On Thu, 17 Nov 2022 17:43:40 GMT, Sergey Bylokhov wrote: > > Increase color tolerance delta from 1 to 5 > > I see that the tolerance is added to the test, previously it was 0. Why do we need it since we use quite simple RED color? We have a tolerance of 1 for red color. We dont throw exception when red channel is 254. But i think we dont need extra tolerance and it was added because of local machine reporting differences. I have removed the extra tolerance and see that test passes in CI. ------------- PR: https://git.openjdk.org/jdk/pull/11201 From jdv at openjdk.org Fri Nov 18 06:52:52 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Fri, 18 Nov 2022 06:52:52 GMT Subject: RFR: 8191406: [hidpi] sun/java2d/SunGraphics2D/DrawImageBilinear.java test fails [v3] In-Reply-To: <3mHTs6Gpmb2JPxOfF9Ii7-eBRsvLnsqykBu7gkltH-M=.a2979bc5-b386-4c5f-b621-30f2a993090d@github.com> References: <3mHTs6Gpmb2JPxOfF9Ii7-eBRsvLnsqykBu7gkltH-M=.a2979bc5-b386-4c5f-b621-30f2a993090d@github.com> Message-ID: > This test was failing because of timing or color difference issues. > Updated test to: > > 1) Use EDT for UI drawing instead of manual synchronisation > 2) Use Robot.waitForIdle before screen capture > 3) Increase color tolerance delta from 1 to 5 > 4) Use undecorated frame and explicitly set background color and move the frame to top > 5) Cleanup to remove not needed flags and java options > > After these changes test passes on all platforms in CI except Linux. For Linux it looks like product issue so i have raised : https://bugs.openjdk.org/browse/JDK-8297175 Jayathirth D V has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains four commits: - Remove image dump - ProblemList only on Linux - Add background color and tolerance - Initial change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11201/files - new: https://git.openjdk.org/jdk/pull/11201/files/ec464893..60c75caa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11201&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11201&range=01-02 Stats: 15 lines in 1 file changed: 14 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11201.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11201/head:pull/11201 PR: https://git.openjdk.org/jdk/pull/11201 From stuefe at openjdk.org Fri Nov 18 07:12:28 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 18 Nov 2022 07:12:28 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v9] In-Reply-To: <3vPeF8_u7AOdiGQRRw5xT66iRe9rhrb1OTDTt0Fef0k=.a3ad1514-2185-4e75-9a78-01e37e4daa8d@github.com> References: <3vPeF8_u7AOdiGQRRw5xT66iRe9rhrb1OTDTt0Fef0k=.a3ad1514-2185-4e75-9a78-01e37e4daa8d@github.com> Message-ID: On Fri, 18 Nov 2022 06:42:24 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> May I have this update reviewed? >> >> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > size_t cast Hi @XueleiFan, the last version with the asserts looks fine to me. Thanks for your work! Cheers, Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/11115 From xuelei at openjdk.org Fri Nov 18 07:39:41 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 18 Nov 2022 07:39:41 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v10] In-Reply-To: References: Message-ID: > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: fix size_t cast warning on windows ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11115/files - new: https://git.openjdk.org/jdk/pull/11115/files/59a87dd1..4fa31622 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=08-09 Stats: 24 lines in 2 files changed: 0 ins; 0 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/11115.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11115/head:pull/11115 PR: https://git.openjdk.org/jdk/pull/11115 From duke at openjdk.org Fri Nov 18 08:06:48 2022 From: duke at openjdk.org (Naveen Narayanan) Date: Fri, 18 Nov 2022 08:06:48 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem. [v4] In-Reply-To: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> Message-ID: <7BjFseRCln_TmwvdPkVVsqvZXstMf-9lpnr4Z6ifMVk=.22a10022-2d6d-4a0b-9f15-54c6c0b2153b@github.com> > This testcase will > 1) Verify setAccelerator method of JMenuitem. > 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M. > > Testing: > Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: 8296275: Review comments fixed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11035/files - new: https://git.openjdk.org/jdk/pull/11035/files/3dc79dd4..77c86dc7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11035&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11035&range=02-03 Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11035.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11035/head:pull/11035 PR: https://git.openjdk.org/jdk/pull/11035 From psadhukhan at openjdk.org Fri Nov 18 08:08:02 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 18 Nov 2022 08:08:02 GMT Subject: RFR: 8285604: closed sun/java2d/GdiRendering/ClipShapeRendering.java failed with "Incorrect color ffeeeeee instead of ff0000ff in pixel (100, 100)" In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 21:05:35 GMT, Phil Race wrote: > This was a closed test. It fails very rarely due to completely incorrect colour sampling by Robot. > I had this happen to me when the window came up behind some other window on my desktop. > So the "fix" here is to use setAlwaysOnTop(true) > But so far as I can see there's no reason for this test to be closed so I am moving it to open as well. Marked as reviewed by psadhukhan (Reviewer). test/jdk/sun/java2d/GdiRendering/ClipShapeRendering.java line 504: > 502: this.clientPixels = clientPixels; > 503: int w = clientPixels.getWidth(null), > 504: h = clientPixels.getHeight(null); Nit: Please rectify this coding violation of declaring variables in same line, same in l498 before push ------------- PR: https://git.openjdk.org/jdk/pull/11221 From xuelei at openjdk.org Fri Nov 18 08:20:30 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 18 Nov 2022 08:20:30 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v11] In-Reply-To: References: Message-ID: > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: more size_t updare for windows build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11115/files - new: https://git.openjdk.org/jdk/pull/11115/files/4fa31622..c3da70cc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=09-10 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/11115.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11115/head:pull/11115 PR: https://git.openjdk.org/jdk/pull/11115 From kizune at openjdk.org Fri Nov 18 08:37:01 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Fri, 18 Nov 2022 08:37:01 GMT Subject: RFR: 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout [v4] In-Reply-To: References: Message-ID: > On m1 mac sometimes (in very rare instance) it takes a long time to get the sequencer so increasing timeout helps with that. > Also on m1 mac sequencer got notified about the first MetaMessage twice. The reason is unclear but watching for that fixes the problem. Also on Linux sometimes process hangs indefinitely without finishing hold by the com.sun.media.sound.MediaDispatcher. Closing the sequencer at the end of the test helps with that. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Making variables that accessed across different threads volatile The workaround for duplicate messages now changed to collect more data instead of making test to pass ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11157/files - new: https://git.openjdk.org/jdk/pull/11157/files/791065fb..5647db2e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11157&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11157&range=02-03 Stats: 17 lines in 1 file changed: 13 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11157.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11157/head:pull/11157 PR: https://git.openjdk.org/jdk/pull/11157 From serb at openjdk.org Fri Nov 18 08:41:31 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 18 Nov 2022 08:41:31 GMT Subject: RFR: 8196018: java/awt/Scrollbar/ScrollbarMouseWheelTest/ScrollbarMouseWheelTest.java fails [v3] In-Reply-To: References: Message-ID: <5LJgBdPkgUQ-51wT-09fC-uc2Lha-GXUxSbjF198mEE=.2a5d54d0-aba9-4580-a55b-7d1a26aeb3ec@github.com> On Thu, 17 Nov 2022 20:08:01 GMT, Alexander Zvegintsev wrote: >> The issue contains evaluation: >> * the test is not failing on Windows >> * it also fails on Linux(but provided stack trace with failure is from different test) >> >> I rechecked the test and it does not fail on all platforms. >> >> Test is stabilized: >> * replaced synchronization on windowActivated event with standard `robot.waitForIdle(); robot.delay(1000);` >> * Robot autoDelay decreased to 250 to make the test go faster. It it still a reasonable value. >> >> CI testing looks good also. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > removing extra waitForIdle(called automatically on mouseWheel because of setAutoWaitForIdle(true); Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11213 From serb at openjdk.org Fri Nov 18 08:44:24 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 18 Nov 2022 08:44:24 GMT Subject: RFR: 8297088: Update LCMS to 2.14 In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 19:05:36 GMT, Alisen Chung wrote: > Redo of 8295369: Update LCMS to 2.14 > Update LCMS to newest release. > Updated DISABLED_WARNINGS_gcc for LCMS to include type limits to prevent a build error in linux. > Automatic tests and J2D demo tests were run. make/modules/java.desktop/lib/Awt2dLibraries.gmk line 308: > 306: libawt/java2d, \ > 307: HEADERS_FROM_SRC := $(LIBLCMS_HEADERS_FROM_SRC), \ > 308: DISABLED_WARNINGS_gcc := format-nonliteral type-limits stringop-truncation, \ it would be good to report this upstream. ------------- PR: https://git.openjdk.org/jdk/pull/11217 From serb at openjdk.org Fri Nov 18 09:12:20 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 18 Nov 2022 09:12:20 GMT Subject: RFR: 8297088: Update LCMS to 2.14 In-Reply-To: References: Message-ID: <8KhAMgOEU6RSj_jo8w0HUrWfwI-sNvrfQVmkdr_OGgo=.9b1f6754-9c1f-4b81-bfdb-67d16dc8005c@github.com> On Thu, 17 Nov 2022 19:05:36 GMT, Alisen Chung wrote: > Redo of 8295369: Update LCMS to 2.14 > Update LCMS to newest release. > Updated DISABLED_WARNINGS_gcc for LCMS to include type limits to prevent a build error in linux. > Automatic tests and J2D demo tests were run. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11217 From duke at openjdk.org Fri Nov 18 09:21:51 2022 From: duke at openjdk.org (ravi gupta) Date: Fri, 18 Nov 2022 09:21:51 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent [v6] In-Reply-To: References: Message-ID: > This testcase Verify the content changes of a TextArea for the following assertions. > > a. TextListener get invoked when the content of a TextArea gets changed. > b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. > > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. ravi gupta has updated the pull request incrementally with one additional commit since the last revision: 8296632: Review Fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11052/files - new: https://git.openjdk.org/jdk/pull/11052/files/d91bdcc4..4a702aac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11052&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11052&range=04-05 Stats: 12 lines in 1 file changed: 4 ins; 8 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11052.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11052/head:pull/11052 PR: https://git.openjdk.org/jdk/pull/11052 From duke at openjdk.org Fri Nov 18 09:31:21 2022 From: duke at openjdk.org (Naveen Narayanan) Date: Fri, 18 Nov 2022 09:31:21 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem. [v3] In-Reply-To: References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> Message-ID: On Thu, 17 Nov 2022 13:05:21 GMT, Alexey Ivanov wrote: >> Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: >> >> 8296275: Review comments fixed. > > test/jdk/java/awt/Desktop/JMenuItemSetAcceleratorTest.java line 81: > >> 79: try { >> 80: if (!Desktop.isDesktopSupported() >> 81: || !Desktop.getDesktop().isSupported(Action.APP_MENU_BAR)) { > > Why are you checking `APP_MENU_BAR` if you don't use it? > > Is the test indented for standard `JMenu` or the one that integrates with macOS menu bar? Removed APP_MENU_BAR as we don't use it. ------------- PR: https://git.openjdk.org/jdk/pull/11035 From jdv at openjdk.org Fri Nov 18 12:35:28 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Fri, 18 Nov 2022 12:35:28 GMT Subject: RFR: 8297241: Update sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java Message-ID: This is follow up of https://github.com/openjdk/jdk/pull/11158#discussion_r1025574199 I have added empty paint() and update() methods back for the frame in this test. Ran the test 20 times in our CI machines on all platforms. It failed once in Linux machine and image dump showed nothing was drawn. Added robot.waitForIdle() after frame.resize() also so that system-triggered repaint can be finished after resize of the frame. With this update i don't see this test failing on all platforms in our CI even when run for 100 times. ------------- Commit messages: - Add empty paint method and waitForIdle for resize Changes: https://git.openjdk.org/jdk/pull/11237/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11237&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297241 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11237.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11237/head:pull/11237 PR: https://git.openjdk.org/jdk/pull/11237 From aivanov at openjdk.org Fri Nov 18 11:44:29 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 18 Nov 2022 11:44:29 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem. [v4] In-Reply-To: <7BjFseRCln_TmwvdPkVVsqvZXstMf-9lpnr4Z6ifMVk=.22a10022-2d6d-4a0b-9f15-54c6c0b2153b@github.com> References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> <7BjFseRCln_TmwvdPkVVsqvZXstMf-9lpnr4Z6ifMVk=.22a10022-2d6d-4a0b-9f15-54c6c0b2153b@github.com> Message-ID: On Fri, 18 Nov 2022 08:06:48 GMT, Naveen Narayanan wrote: >> This testcase will >> 1) Verify setAccelerator method of JMenuitem. >> 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M. >> >> Testing: >> Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. > > Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: > > 8296275: Review comments fixed. Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11035 From mvs at openjdk.org Fri Nov 18 13:25:21 2022 From: mvs at openjdk.org (Manukumar V S) Date: Fri, 18 Nov 2022 13:25:21 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem [v4] In-Reply-To: <7BjFseRCln_TmwvdPkVVsqvZXstMf-9lpnr4Z6ifMVk=.22a10022-2d6d-4a0b-9f15-54c6c0b2153b@github.com> References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> <7BjFseRCln_TmwvdPkVVsqvZXstMf-9lpnr4Z6ifMVk=.22a10022-2d6d-4a0b-9f15-54c6c0b2153b@github.com> Message-ID: On Fri, 18 Nov 2022 08:06:48 GMT, Naveen Narayanan wrote: >> This testcase will >> 1) Verify setAccelerator method of JMenuitem. >> 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M. >> >> Testing: >> Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. > > Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: > > 8296275: Review comments fixed. Marked as reviewed by mvs (Author). ------------- PR: https://git.openjdk.org/jdk/pull/11035 From duke at openjdk.org Fri Nov 18 13:28:40 2022 From: duke at openjdk.org (Naveen Narayanan) Date: Fri, 18 Nov 2022 13:28:40 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem [v4] In-Reply-To: References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> <7BjFseRCln_TmwvdPkVVsqvZXstMf-9lpnr4Z6ifMVk=.22a10022-2d6d-4a0b-9f15-54c6c0b2153b@github.com> Message-ID: On Fri, 18 Nov 2022 11:41:51 GMT, Alexey Ivanov wrote: >> Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: >> >> 8296275: Review comments fixed. > > Marked as reviewed by aivanov (Reviewer). @aivanov-jdk could you please sponsor. ------------- PR: https://git.openjdk.org/jdk/pull/11035 From mbaesken at openjdk.org Fri Nov 18 13:48:11 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 18 Nov 2022 13:48:11 GMT Subject: RFR: JDK-8297147: UnexpectedSourceImageSize test times out on slow machines when fastdebug is used Message-ID: <5j1gQSL_VUXqBFasAHTCF3tFdv2BY8hqD339Xwca8Qs=.6d40f959-1cc5-48da-aaa7-5f667fa76ebb@github.com> The image related test UnexpectedSourceImageSize test introduced with https://bugs.openjdk.org/browse/JDK-8264666 sometimes times out on slow machines when fastdebug is used. This happens especially in 11 and 17; in 20 it seems to be a bit faster but we better change timeouts across releases. ------------- Commit messages: - JDK-8297147 Changes: https://git.openjdk.org/jdk/pull/11240/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11240&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297147 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11240.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11240/head:pull/11240 PR: https://git.openjdk.org/jdk/pull/11240 From omikhaltcova at openjdk.org Fri Nov 18 14:03:25 2022 From: omikhaltcova at openjdk.org (Olga Mikhaltsova) Date: Fri, 18 Nov 2022 14:03:25 GMT Subject: RFR: 8165943: LineBreakMeasurer does not measure correctly if TextAttribute.TRACKING is set. In-Reply-To: References: Message-ID: On Thu, 15 Sep 2022 16:51:27 GMT, Olga Mikhaltsova wrote: > This is a fix for LineBreakMeasurer. It takes into account the TextAttribute.TRACKING value (not eq 0) while calculating the line breaks. > > Tested on Linux x64, Windows x64, macOS x64 with the reproducer (LineBreakSample.java) attached to JDK-8165943 and the following group of tests: > `$JTREG_HOME/bin/jtreg -jdk:$BUILD_HOME ./test/jdk/java/awt/font` @prrace Could you please take a look at the proposed changes! Is this fix needed or not? It fixes JDK-8165943/JDK-6598756. I opened PR on JDK-8165943 because it had more active conversation. But maybe I made a mistake and it should be opened on JDK-6598756 (created by you) because it was created earlier then JDK-8165943? ------------- PR: https://git.openjdk.org/jdk/pull/10289 From stuefe at openjdk.org Fri Nov 18 14:09:20 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 18 Nov 2022 14:09:20 GMT Subject: RFR: JDK-8297147: UnexpectedSourceImageSize test times out on slow machines when fastdebug is used In-Reply-To: <5j1gQSL_VUXqBFasAHTCF3tFdv2BY8hqD339Xwca8Qs=.6d40f959-1cc5-48da-aaa7-5f667fa76ebb@github.com> References: <5j1gQSL_VUXqBFasAHTCF3tFdv2BY8hqD339Xwca8Qs=.6d40f959-1cc5-48da-aaa7-5f667fa76ebb@github.com> Message-ID: On Fri, 18 Nov 2022 13:38:47 GMT, Matthias Baesken wrote: > The image related test UnexpectedSourceImageSize test introduced with https://bugs.openjdk.org/browse/JDK-8264666 > sometimes times out on slow machines when fastdebug is used. This happens especially in 11 and 17; in 20 it seems to be a bit faster but we better change timeouts across releases. Looks good. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/11240 From duke at openjdk.org Fri Nov 18 14:17:25 2022 From: duke at openjdk.org (Naveen Narayanan) Date: Fri, 18 Nov 2022 14:17:25 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem [v4] In-Reply-To: References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> <7BjFseRCln_TmwvdPkVVsqvZXstMf-9lpnr4Z6ifMVk=.22a10022-2d6d-4a0b-9f15-54c6c0b2153b@github.com> Message-ID: On Fri, 18 Nov 2022 11:41:51 GMT, Alexey Ivanov wrote: >> Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: >> >> 8296275: Review comments fixed. > > Marked as reviewed by aivanov (Reviewer). @aivanov-jdk could you please sponsor. ------------- PR: https://git.openjdk.org/jdk/pull/11035 From mbaesken at openjdk.org Fri Nov 18 15:07:34 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 18 Nov 2022 15:07:34 GMT Subject: RFR: JDK-8297147: UnexpectedSourceImageSize test times out on slow machines when fastdebug is used In-Reply-To: <5j1gQSL_VUXqBFasAHTCF3tFdv2BY8hqD339Xwca8Qs=.6d40f959-1cc5-48da-aaa7-5f667fa76ebb@github.com> References: <5j1gQSL_VUXqBFasAHTCF3tFdv2BY8hqD339Xwca8Qs=.6d40f959-1cc5-48da-aaa7-5f667fa76ebb@github.com> Message-ID: On Fri, 18 Nov 2022 13:38:47 GMT, Matthias Baesken wrote: > The image related test UnexpectedSourceImageSize test introduced with https://bugs.openjdk.org/browse/JDK-8264666 > sometimes times out on slow machines when fastdebug is used. This happens especially in 11 and 17; in 20 it seems to be a bit faster but we better change timeouts across releases. Hi Thomas, thanks for the review. ------------- PR: https://git.openjdk.org/jdk/pull/11240 From aivanov at openjdk.org Fri Nov 18 15:19:21 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 18 Nov 2022 15:19:21 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem [v4] In-Reply-To: <7BjFseRCln_TmwvdPkVVsqvZXstMf-9lpnr4Z6ifMVk=.22a10022-2d6d-4a0b-9f15-54c6c0b2153b@github.com> References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> <7BjFseRCln_TmwvdPkVVsqvZXstMf-9lpnr4Z6ifMVk=.22a10022-2d6d-4a0b-9f15-54c6c0b2153b@github.com> Message-ID: On Fri, 18 Nov 2022 08:06:48 GMT, Naveen Narayanan wrote: >> This testcase will >> 1) Verify setAccelerator method of JMenuitem. >> 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M. >> >> Testing: >> Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. > > Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: > > 8296275: Review comments fixed. Changes requested by aivanov (Reviewer). test/jdk/java/awt/Desktop/JMenuItemSetAcceleratorTest.java line 83: > 81: System.out.println("Test skipped as Desktop is not supported."); > 82: return; > 83: } Desktop is not used at all, is it? ------------- PR: https://git.openjdk.org/jdk/pull/11035 From aivanov at openjdk.org Fri Nov 18 15:29:21 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 18 Nov 2022 15:29:21 GMT Subject: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent [v6] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 09:21:51 GMT, ravi gupta wrote: >> This testcase Verify the content changes of a TextArea for the following assertions. >> >> a. TextListener get invoked when the content of a TextArea gets changed. >> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8296632: Review Fixes Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11052 From prr at openjdk.org Fri Nov 18 16:39:24 2022 From: prr at openjdk.org (Phil Race) Date: Fri, 18 Nov 2022 16:39:24 GMT Subject: RFR: 8297088: Update LCMS to 2.14 In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 19:05:36 GMT, Alisen Chung wrote: > Redo of 8295369: Update LCMS to 2.14 > Update LCMS to newest release. > Updated DISABLED_WARNINGS_gcc for LCMS to include type limits to prevent a build error in linux. > Automatic tests and J2D demo tests were run. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11217 From prr at openjdk.org Fri Nov 18 16:44:58 2022 From: prr at openjdk.org (Phil Race) Date: Fri, 18 Nov 2022 16:44:58 GMT Subject: RFR: 8297195: AWTAccessor and SwingAccessor should avoid double racy reads from non-volatile fields In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 10:19:31 GMT, Sergey Bylokhov wrote: > The patch applied to SharedSecrets by https://github.com/openjdk/jdk/pull/1914 is applied to the AWTAccessor and SwingAccessor. It prevents null to be returned by the some of methods. > > See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11205 From honkar at openjdk.org Fri Nov 18 18:07:50 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 18 Nov 2022 18:07:50 GMT Subject: RFR: 8297088: Update LCMS to 2.14 In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 19:05:36 GMT, Alisen Chung wrote: > Redo of 8295369: Update LCMS to 2.14 > Update LCMS to newest release. > Updated DISABLED_WARNINGS_gcc for LCMS to include type limits to prevent a build error in linux. > Automatic tests and J2D demo tests were run. Marked as reviewed by honkar (Author). File headers update, indentation & spacing looks good. ------------- PR: https://git.openjdk.org/jdk/pull/11217 From prr at openjdk.org Fri Nov 18 18:52:21 2022 From: prr at openjdk.org (Phil Race) Date: Fri, 18 Nov 2022 18:52:21 GMT Subject: RFR: JDK-8297230: Update Marlin2D to 0.9.4.6 In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 22:51:00 GMT, Laurent Bourg?s wrote: > Initial PR I am running the full battery of our automated tests on this change. ------------- PR: https://git.openjdk.org/jdk/pull/11225 From lbourges at openjdk.org Fri Nov 18 18:56:30 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Fri, 18 Nov 2022 18:56:30 GMT Subject: RFR: JDK-8297230: Update Marlin2D to 0.9.4.6 In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 22:51:00 GMT, Laurent Bourg?s wrote: > Initial PR Thanks, phil. I will write anyway a new test for java2d backport of https://github.com/bourgesl/jfx/blob/0e739a9cda59e4ebfe7676278b3d35c3043ad535/tests/system/src/test/java/test/com/sun/marlin/HugePolygonClipTest.java ------------- PR: https://git.openjdk.org/jdk/pull/11225 From duke at openjdk.org Fri Nov 18 19:21:52 2022 From: duke at openjdk.org (Naveen Narayanan) Date: Fri, 18 Nov 2022 19:21:52 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem [v5] In-Reply-To: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> Message-ID: > This testcase will > 1) Verify setAccelerator method of JMenuitem. > 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M. > > Testing: > Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: 8296275: Review comments fixed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11035/files - new: https://git.openjdk.org/jdk/pull/11035/files/77c86dc7..a7c30098 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11035&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11035&range=03-04 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11035.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11035/head:pull/11035 PR: https://git.openjdk.org/jdk/pull/11035 From duke at openjdk.org Fri Nov 18 19:21:55 2022 From: duke at openjdk.org (Naveen Narayanan) Date: Fri, 18 Nov 2022 19:21:55 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem [v4] In-Reply-To: References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> <7BjFseRCln_TmwvdPkVVsqvZXstMf-9lpnr4Z6ifMVk=.22a10022-2d6d-4a0b-9f15-54c6c0b2153b@github.com> Message-ID: On Fri, 18 Nov 2022 15:16:54 GMT, Alexey Ivanov wrote: >> Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: >> >> 8296275: Review comments fixed. > > test/jdk/java/awt/Desktop/JMenuItemSetAcceleratorTest.java line 83: > >> 81: System.out.println("Test skipped as Desktop is not supported."); >> 82: return; >> 83: } > > Desktop is not used at all, is it? Right, removed the Desktop check. ------------- PR: https://git.openjdk.org/jdk/pull/11035 From xuelei at openjdk.org Fri Nov 18 19:25:32 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 18 Nov 2022 19:25:32 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v12] In-Reply-To: References: Message-ID: > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: extra sizeof typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11115/files - new: https://git.openjdk.org/jdk/pull/11115/files/c3da70cc..4f80245f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11115.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11115/head:pull/11115 PR: https://git.openjdk.org/jdk/pull/11115 From serb at openjdk.org Fri Nov 18 19:28:34 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 18 Nov 2022 19:28:34 GMT Subject: RFR: JDK-8297147: UnexpectedSourceImageSize test times out on slow machines when fastdebug is used In-Reply-To: <5j1gQSL_VUXqBFasAHTCF3tFdv2BY8hqD339Xwca8Qs=.6d40f959-1cc5-48da-aaa7-5f667fa76ebb@github.com> References: <5j1gQSL_VUXqBFasAHTCF3tFdv2BY8hqD339Xwca8Qs=.6d40f959-1cc5-48da-aaa7-5f667fa76ebb@github.com> Message-ID: On Fri, 18 Nov 2022 13:38:47 GMT, Matthias Baesken wrote: > The image related test UnexpectedSourceImageSize test introduced with https://bugs.openjdk.org/browse/JDK-8264666 > sometimes times out on slow machines when fastdebug is used. This happens especially in 11 and 17; in 20 it seems to be a bit faster but we better change timeouts across releases. Are you sure that it is fine to bump the timeout from 2 mins to 10 minutes? It is quite big slowdown. ------------- PR: https://git.openjdk.org/jdk/pull/11240 From achung at openjdk.org Fri Nov 18 19:42:32 2022 From: achung at openjdk.org (Alisen Chung) Date: Fri, 18 Nov 2022 19:42:32 GMT Subject: Integrated: 8297088: Update LCMS to 2.14 In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 19:05:36 GMT, Alisen Chung wrote: > Redo of 8295369: Update LCMS to 2.14 > Update LCMS to newest release. > Updated DISABLED_WARNINGS_gcc for LCMS to include type limits to prevent a build error in linux. > Automatic tests and J2D demo tests were run. This pull request has now been integrated. Changeset: 2c692aa3 Author: Alisen Chung URL: https://git.openjdk.org/jdk/commit/2c692aa3567fff446b1a3263023077d8b4236945 Stats: 2138 lines in 32 files changed: 1546 ins; 134 del; 458 mod 8297088: Update LCMS to 2.14 Reviewed-by: erikj, serb, prr, honkar ------------- PR: https://git.openjdk.org/jdk/pull/11217 From achung at openjdk.org Fri Nov 18 20:20:54 2022 From: achung at openjdk.org (Alisen Chung) Date: Fri, 18 Nov 2022 20:20:54 GMT Subject: Integrated: 8023562: [TEST_BUG] java/awt/Mouse/EnterExitEvents/DragWindowTest.java failed on ubuntu 13 and mac 10.11 In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 01:46:06 GMT, Alisen Chung wrote: > Test was run on macos and linux 100x and passed. Removing from ProblemList This pull request has now been integrated. Changeset: 11fc65fa Author: Alisen Chung URL: https://git.openjdk.org/jdk/commit/11fc65fa58e39e70ff03966ba96e4ae72237b8fc Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8023562: [TEST_BUG] java/awt/Mouse/EnterExitEvents/DragWindowTest.java failed on ubuntu 13 and mac 10.11 Reviewed-by: azvegint, honkar, jdv ------------- PR: https://git.openjdk.org/jdk/pull/11152 From honkar at openjdk.org Fri Nov 18 20:33:28 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 18 Nov 2022 20:33:28 GMT Subject: RFR: 8239801: [macos] java/awt/Focus/UnaccessibleChoice/AccessibleChoiceTest.java fails In-Reply-To: <1ucV0BHh8XBiFbdJncIVAPXAPXmgJEwDD8f9EWmssnQ=.48c4c221-c5a0-4211-9d15-6de0c7a7da87@github.com> References: <1ucV0BHh8XBiFbdJncIVAPXAPXmgJEwDD8f9EWmssnQ=.48c4c221-c5a0-4211-9d15-6de0c7a7da87@github.com> Message-ID: On Fri, 18 Nov 2022 00:17:47 GMT, Damon Nguyen wrote: > This is an older test that failed intermittently but had a fix specifically for mac systems by adding key presses on mac only. This test still intermittently failed after this fix long ago and was problem listed. > > I ran this test 100 times on each OS after applying waitForIdle and delays between all key presses to match the delays previously present in the test. > > I also added a debug line and save and image of the failing window upon failure to better debug if/when the test ever fails again. The debug line is to check if the previous fix for mac is relevant in the failure. The image shows the status of the window and what is focused at the time of failure. Tested on Mac and Windows, test works well. Minor suggestions added. test/jdk/java/awt/Focus/UnaccessibleChoice/AccessibleChoiceTest.java line 99: > 97: } > 98: robot.waitForIdle(); > 99: robot.delay(2000); Is such a large delay required here since `autoDelay` and `waitForIdle` are also being called? test/jdk/java/awt/Focus/UnaccessibleChoice/AccessibleChoiceTest.java line 150: > 148: // Save image to better debug the status of test when failing > 149: Rectangle screenRect = new Rectangle(100, 200, > 150: win.getWidth(), win.getHeight() + 20); Suggestion: You can capture the frame as well as window by using the following (it captures the entire testing screen). GraphicsConfiguration ge = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration(); BufferedImage failImage = robot.createScreenCapture(ge.getBounds()); ------------- PR: https://git.openjdk.org/jdk/pull/11227 From dnguyen at openjdk.org Fri Nov 18 20:37:22 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 18 Nov 2022 20:37:22 GMT Subject: RFR: 8239801: [macos] java/awt/Focus/UnaccessibleChoice/AccessibleChoiceTest.java fails In-Reply-To: References: <1ucV0BHh8XBiFbdJncIVAPXAPXmgJEwDD8f9EWmssnQ=.48c4c221-c5a0-4211-9d15-6de0c7a7da87@github.com> Message-ID: On Fri, 18 Nov 2022 20:27:09 GMT, Harshitha Onkar wrote: >> This is an older test that failed intermittently but had a fix specifically for mac systems by adding key presses on mac only. This test still intermittently failed after this fix long ago and was problem listed. >> >> I ran this test 100 times on each OS after applying waitForIdle and delays between all key presses to match the delays previously present in the test. >> >> I also added a debug line and save and image of the failing window upon failure to better debug if/when the test ever fails again. The debug line is to check if the previous fix for mac is relevant in the failure. The image shows the status of the window and what is focused at the time of failure. > > test/jdk/java/awt/Focus/UnaccessibleChoice/AccessibleChoiceTest.java line 99: > >> 97: } >> 98: robot.waitForIdle(); >> 99: robot.delay(2000); > > Is such a large delay required here since `autoDelay` and `waitForIdle` are also being called? I believe the proper amount is a delay of 1000. I can reduce this, but I thought it might be best to leave as much unchanged as possible. It does make sense to reduce it to 1000 if possible though. ------------- PR: https://git.openjdk.org/jdk/pull/11227 From duke at openjdk.org Fri Nov 18 20:37:33 2022 From: duke at openjdk.org (ravi gupta) Date: Fri, 18 Nov 2022 20:37:33 GMT Subject: Integrated: 8296632: Write a test to verify the content change of TextArea sends TextEvent In-Reply-To: References: Message-ID: <_fXBJWqvmy1wlP_XuDq7SDxi6S72ocSMBkfGlRyUdb8=.1a0fd0f9-9758-404a-a3ef-b65021967286@github.com> On Wed, 9 Nov 2022 04:29:35 GMT, ravi gupta wrote: > This testcase Verify the content changes of a TextArea for the following assertions. > > a. TextListener get invoked when the content of a TextArea gets changed. > b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. > > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. This pull request has now been integrated. Changeset: 59a308b9 Author: ravi.ra.gupta Committer: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/59a308b9d0546471566b11f62ef9bdc169ca0b95 Stats: 141 lines in 1 file changed: 141 ins; 0 del; 0 mod 8296632: Write a test to verify the content change of TextArea sends TextEvent Reviewed-by: mvs, prr, honkar, aivanov, serb ------------- PR: https://git.openjdk.org/jdk/pull/11052 From dnguyen at openjdk.org Fri Nov 18 20:43:50 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 18 Nov 2022 20:43:50 GMT Subject: RFR: 8239801: [macos] java/awt/Focus/UnaccessibleChoice/AccessibleChoiceTest.java fails In-Reply-To: References: <1ucV0BHh8XBiFbdJncIVAPXAPXmgJEwDD8f9EWmssnQ=.48c4c221-c5a0-4211-9d15-6de0c7a7da87@github.com> Message-ID: On Fri, 18 Nov 2022 20:23:22 GMT, Harshitha Onkar wrote: >> This is an older test that failed intermittently but had a fix specifically for mac systems by adding key presses on mac only. This test still intermittently failed after this fix long ago and was problem listed. >> >> I ran this test 100 times on each OS after applying waitForIdle and delays between all key presses to match the delays previously present in the test. >> >> I also added a debug line and save and image of the failing window upon failure to better debug if/when the test ever fails again. The debug line is to check if the previous fix for mac is relevant in the failure. The image shows the status of the window and what is focused at the time of failure. > > test/jdk/java/awt/Focus/UnaccessibleChoice/AccessibleChoiceTest.java line 150: > >> 148: // Save image to better debug the status of test when failing >> 149: Rectangle screenRect = new Rectangle(100, 200, >> 150: win.getWidth(), win.getHeight() + 20); > > Suggestion: You can capture the frame as well as window by using the following (it captures the entire testing screen). > > GraphicsConfiguration ge = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration(); > BufferedImage failImage = robot.createScreenCapture(ge.getBounds()); I can update it to capture the screen instead if that's preferred. I initially had it this way, but I figured it was better to just show the window that is being tested alone. If it's better to capture the whole screen for debugging purposes, I can make this change. ------------- PR: https://git.openjdk.org/jdk/pull/11227 From dnguyen at openjdk.org Fri Nov 18 20:52:21 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 18 Nov 2022 20:52:21 GMT Subject: RFR: 8196018: java/awt/Scrollbar/ScrollbarMouseWheelTest/ScrollbarMouseWheelTest.java fails [v3] In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 20:08:01 GMT, Alexander Zvegintsev wrote: >> The issue contains evaluation: >> * the test is not failing on Windows >> * it also fails on Linux(but provided stack trace with failure is from different test) >> >> I rechecked the test and it does not fail on all platforms. >> >> Test is stabilized: >> * replaced synchronization on windowActivated event with standard `robot.waitForIdle(); robot.delay(1000);` >> * Robot autoDelay decreased to 250 to make the test go faster. It it still a reasonable value. >> >> CI testing looks good also. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > removing extra waitForIdle(called automatically on mouseWheel because of setAutoWaitForIdle(true); Tested locally on macOS and the test works normally with the test removed from the problem list. ------------- Marked as reviewed by dnguyen (Author). PR: https://git.openjdk.org/jdk/pull/11213 From aivanov at openjdk.org Fri Nov 18 21:16:23 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 18 Nov 2022 21:16:23 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem [v5] In-Reply-To: References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> Message-ID: On Fri, 18 Nov 2022 19:21:52 GMT, Naveen Narayanan wrote: >> This testcase will >> 1) Verify setAccelerator method of JMenuitem. >> 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M. >> >> Testing: >> Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. > > Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: > > 8296275: Review comments fixed. Since the test has nothing to do with `Desktop` class it should be moved to `JMenuItem` folder because it tests functionality of `JMenuItem`. test/jdk/java/awt/Desktop/JMenuItemSetAcceleratorTest.java line 24: > 22: > 23: import java.awt.Desktop; > 24: import java.awt.Desktop.Action; The unused imports are to be removed. test/jdk/java/awt/Desktop/JMenuItemSetAcceleratorTest.java line 51: > 49: private static JFrame frame; > 50: private final static CountDownLatch actionPerformLatch = > 51: new CountDownLatch(1); Suggestion: private static final CountDownLatch actionPerformLatch = new CountDownLatch(1); Please used ?blessed? modifier order. I see no reason to wrap the line, it's 84 chars long, which is acceptable to me. If you like, you can rename it to `actionLatch` so that it fits into 80 column limit. test/jdk/java/awt/Desktop/JMenuItemSetAcceleratorTest.java line 63: > 61: > 62: menuItem.setAccelerator( > 63: KeyStroke.getKeyStroke(KeyEvent.VK_M, ActionEvent.META_MASK)); Suggestion: menuItem.setAccelerator( KeyStroke.getKeyStroke(KeyEvent.VK_M, InputEvent.META_DOWN_MASK)); The modifiers come from `InputEvent`, not `ActionEvent`. test/jdk/java/awt/Desktop/JMenuItemSetAcceleratorTest.java line 78: > 76: } > 77: > 78: public static void main(String args[]) throws Exception { Suggestion: public static void main(String[] args) throws Exception { Please use Java-style array declaration. test/jdk/java/awt/Desktop/JMenuItemSetAcceleratorTest.java line 81: > 79: try { > 80: SwingUtilities > 81: .invokeAndWait(JMenuItemSetAcceleratorTest::createAndShow); I suggest not to wrap the line. No, it doesn't fit 80 column, yet wrapping creates more visual noise. If you like, you can statically import `invokeAndWait`. I'm everyone would understand where it comes from without `SwingUtilities.` prefix. However, keeping the class name makes it clear. test/jdk/java/awt/Desktop/JMenuItemSetAcceleratorTest.java line 98: > 96: } > 97: System.out > 98: .println("Test passed, received action event on menu item."); I'd rather wrap the string argument than the call. In this case, I wouldn't wrap it: the line takes 84 columns. test/jdk/java/awt/Desktop/JMenuItemSetAcceleratorTest.java line 100: > 98: .println("Test passed, received action event on menu item."); > 99: } finally { > 100: EventQueue.invokeAndWait(JMenuItemSetAcceleratorTest::disposeFrame); Why not `SwingUtilities`? ------------- Changes requested by aivanov (Reviewer). PR: https://git.openjdk.org/jdk/pull/11035 From kizune at openjdk.org Fri Nov 18 21:23:33 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Fri, 18 Nov 2022 21:23:33 GMT Subject: Integrated: 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 07:31:46 GMT, Alexander Zuev wrote: > On m1 mac sometimes (in very rare instance) it takes a long time to get the sequencer so increasing timeout helps with that. > Also on m1 mac sequencer got notified about the first MetaMessage twice. The reason is unclear but watching for that fixes the problem. Also on Linux sometimes process hangs indefinitely without finishing hold by the com.sun.media.sound.MediaDispatcher. Closing the sequencer at the end of the test helps with that. This pull request has now been integrated. Changeset: 43ce047f Author: Alexander Zuev URL: https://git.openjdk.org/jdk/commit/43ce047f9f417a1d8afa83a3d2c2429a478975db Stats: 28 lines in 2 files changed: 22 ins; 1 del; 5 mod 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout Reviewed-by: prr, psadhukhan ------------- PR: https://git.openjdk.org/jdk/pull/11157 From sebastian.luckner at st.oth-regensburg.de Fri Nov 18 21:42:51 2022 From: sebastian.luckner at st.oth-regensburg.de (Sebastian Luckner) Date: Fri, 18 Nov 2022 21:42:51 +0000 Subject: ext dna_color size on disk == 399kb & file.exists() In-Reply-To: References: <3mHTs6Gpmb2JPxOfF9Ii7-eBRsvLnsqykBu7gkltH-M=.a2979bc5-b386-4c5f-b621-30f2a993090d@github.com>, Message-ID: dieses script funktioniert mittlerweile hoffentlich ?berall gleich: public static String[] av = new String[] { "AAAA", "AAAC", "AAAT", "AAAG", "AACA", "AACC", "AACT", "AACG", "AATA", "AATC", "AATT", "AATG", "AAGA", "AAGC", "AAGT", "AAGG", "ACAA", "ACAC", "ACAT", "ACAG", "ACCA", "ACCC", "ACCT", "ACCG", "ACTA", "ACTC", "ACTT", "ACTG", "ACGA", "ACGC", "ACGT", "ACGG", "ATAA", "ATAC", "ATAT", "ATAG", "ATCA", "ATCC", "ATCT", "ATCG", "ATTA", "ATTC", "ATTT", "ATTG", "ATGA", "ATGC", "ATGT", "ATGG", "AGAA", "AGAC", "AGAT", "AGAG", "AGCA", "AGCC", "AGCT", "AGCG", "AGTA", "AGTC", "AGTT", "AGTG", "AGGA", "AGGC", "AGGT", "AGGG", "CAAA", "CAAC", "CAAT", "CAAG", "CACA", "CACC", "CACT", "CACG", "CATA", "CATC", "CATT", "CATG", "CAGA", "CAGC", "CAGT", "CAGG", "CCAA", "CCAC", "CCAT", "CCAG", "CCCA", "CCCC", "CCCT", "CCCG", "CCTA", "CCTC", "CCTT", "CCTG", "CCGA", "CCGC", "CCGT", "CCGG", "CTAA", "CTAC", "CTAT", "CTAG", "CTCA", "CTCC", "CTCT", "CTCG", "CTTA", "CTTC", "CTTT", "CTTG", "CTGA", "CTGC", "CTGT", "CTGG", "CGAA", "CGAC", "CGAT", "CGAG", "CGCA", "CGCC", "CGCT", "CGCG", "CGTA", "CGTC", "CGTT", "CGTG", "CGGA", "CGGC", "CGGT", "CGGG", "TAAA", "TAAC", "TAAT", "TAAG", "TACA", "TACC", "TACT", "TACG", "TATA", "TATC", "TATT", "TATG", "TAGA", "TAGC", "TAGT", "TAGG", "TCAA", "TCAC", "TCAT", "TCAG", "TCCA", "TCCC", "TCCT", "TCCG", "TCTA", "TCTC", "TCTT", "TCTG", "TCGA", "TCGC", "TCGT", "TCGG", "TTAA", "TTAC", "TTAT", "TTAG", "TTCA", "TTCC", "TTCT", "TTCG", "TTTA", "TTTC", "TTTT", "TTTG", "TTGA", "TTGC", "TTGT", "TTGG", "TGAA", "TGAC", "TGAT", "TGAG", "TGCA", "TGCC", "TGCT", "TGCG", "TGTA", "TGTC", "TGTT", "TGTG", "TGGA", "TGGC", "TGGT", "TGGG", "GAAA", "GAAC", "GAAT", "GAAG", "GACA", "GACC", "GACT", "GACG", "GATA", "GATC", "GATT", "GATG", "GAGA", "GAGC", "GAGT", "GAGG", "GCAA", "GCAC", "GCAT", "GCAG", "GCCA", "GCCC", "GCCT", "GCCG", "GCTA", "GCTC", "GCTT", "GCTG", "GCGA", "GCGC", "GCGT", "GCGG", "GTAA", "GTAC", "GTAT", "GTAG", "GTCA", "GTCC", "GTCT", "GTCG", "GTTA", "GTTC", "GTTT", "GTTG", "GTGA", "GTGC", "GTGT", "GTGG", "GGAA", "GGAC", "GGAT", "GGAG", "GGCA", "GGCC", "GGCT", "GGCG", "GGTA", "GGTC", "GGTT", "GGTG", "GGGA", "GGGC", "GGGT", "GGGG" }; av[2] + av[0] > av[19] + av[31] f?r gutes wirklich ?berall gleich lang ausf?hrbares script erhalte man ab sofort genau obrige kombination von den eigenen ahnen. das problem war: ein static WIDTH = 16, HEIGHT = 16 das per hand durch 16 ersetzt werden konnte. f?r tk dna: av[16] + av[916] + av[54] + av[96]; und av[3]; wer noch mit der eigenen dna programieren lernen will, hier der vergessenscode von fehlermeldungen: 243987524397085243987045398724375289987403942872349875239874239408724395870 3074259838749328749098325749432508790874325432790845327982439708 7290384574398523984057293087443527982398745032874943259870 9032874523749803749802349875453987243958704325907824390857 3290874532908742345987023497085308729438793908744538792 7298304239587403 8732905237498398704523974823 298730452394087 2739408745980239408723497084357980932874 23790842908743538794239087987320487294327398 032987452349872439870543298704987023249875 273908452743950859805980598059804 29087345290873290873452908734529087342590873425908734529087345290873425908734259087345290873452908734259087342590873425908734259087345290873452908734259087342590873425908734529087345290873425908734259087345290873452908734259087342590873452908734529087342590873290873 32907542930874529873045298730457934279083247908 23984075987345987739083 902873457298437872083945 239408752735279083940870879 was hier sein kann: 329087548790438732490287439495087 was wohl nicht mehr gut w#?re ist 0b0110101010101010101010101010101010101010101010101010101010101010101010!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!==!=! ________________________________ Von: client-libs-dev im Auftrag von Jayathirth D V Gesendet: Freitag, 18. November 2022 07:52:52 An: client-libs-dev at openjdk.org Betreff: [EXT] Re: RFR: 8191406: [hidpi] sun/java2d/SunGraphics2D/DrawImageBilinear.java test fails [v3] > This test was failing because of timing or color difference issues. > Updated test to: > > 1) Use EDT for UI drawing instead of manual synchronisation > 2) Use Robot.waitForIdle before screen capture > 3) Increase color tolerance delta from 1 to 5 > 4) Use undecorated frame and explicitly set background color and move the frame to top > 5) Cleanup to remove not needed flags and java options > > After these changes test passes on all platforms in CI except Linux. For Linux it looks like product issue so i have raised : https://bugs.openjdk.org/browse/JDK-8297175 Jayathirth D V has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains four commits: - Remove image dump - ProblemList only on Linux - Add background color and tolerance - Initial change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11201/files - new: https://git.openjdk.org/jdk/pull/11201/files/ec464893..60c75caa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11201&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11201&range=01-02 Stats: 15 lines in 1 file changed: 14 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11201.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11201/head:pull/11201 PR: https://git.openjdk.org/jdk/pull/11201 -------------- next part -------------- An HTML attachment was scrubbed... URL: From prr at openjdk.org Fri Nov 18 22:00:23 2022 From: prr at openjdk.org (Phil Race) Date: Fri, 18 Nov 2022 22:00:23 GMT Subject: RFR: 8285604: closed sun/java2d/GdiRendering/ClipShapeRendering.java failed with "Incorrect color ffeeeeee instead of ff0000ff in pixel (100, 100)" [v2] In-Reply-To: References: Message-ID: > This was a closed test. It fails very rarely due to completely incorrect colour sampling by Robot. > I had this happen to me when the window came up behind some other window on my desktop. > So the "fix" here is to use setAlwaysOnTop(true) > But so far as I can see there's no reason for this test to be closed so I am moving it to open as well. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8285604 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11221/files - new: https://git.openjdk.org/jdk/pull/11221/files/aff0b9af..8e2bfc79 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11221&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11221&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11221.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11221/head:pull/11221 PR: https://git.openjdk.org/jdk/pull/11221 From prr at openjdk.org Fri Nov 18 22:03:53 2022 From: prr at openjdk.org (Phil Race) Date: Fri, 18 Nov 2022 22:03:53 GMT Subject: Integrated: 8285604: closed sun/java2d/GdiRendering/ClipShapeRendering.java failed with "Incorrect color ffeeeeee instead of ff0000ff in pixel (100, 100)" In-Reply-To: References: Message-ID: <5dS3iH1ppWtbAKxSmZpG9VyJclrRi2kicmKKvOfAKOU=.fc745a57-2e99-43d9-87f9-105095b71ea2@github.com> On Thu, 17 Nov 2022 21:05:35 GMT, Phil Race wrote: > This was a closed test. It fails very rarely due to completely incorrect colour sampling by Robot. > I had this happen to me when the window came up behind some other window on my desktop. > So the "fix" here is to use setAlwaysOnTop(true) > But so far as I can see there's no reason for this test to be closed so I am moving it to open as well. This pull request has now been integrated. Changeset: c56c69ed Author: Phil Race URL: https://git.openjdk.org/jdk/commit/c56c69ed3e09df1b56e340498dc28ba50815d15e Stats: 518 lines in 1 file changed: 518 ins; 0 del; 0 mod 8285604: closed sun/java2d/GdiRendering/ClipShapeRendering.java failed with "Incorrect color ffeeeeee instead of ff0000ff in pixel (100, 100)" Reviewed-by: psadhukhan ------------- PR: https://git.openjdk.org/jdk/pull/11221 From serb at openjdk.org Sat Nov 19 01:11:41 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 19 Nov 2022 01:11:41 GMT Subject: RFR: 8178698: javax/sound/midi/Sequencer/MetaCallback.java failed with timeout [v3] In-Reply-To: References: <3W-OC_EeYya8hQKeGwfpAnBUylk18dq1c4CP5fSKkyw=.e86a1209-7c2a-4330-a40d-85812a829f82@github.com> <-38WA-JoLOxToMxxTck2FCETqVKkzmuKyFk68GEBZQM=.e231d4d0-dfc3-4d5e-9f58-32428cff6f1b@github.com> Message-ID: On Thu, 17 Nov 2022 19:29:22 GMT, Alexander Zuev wrote: >> Still have a question why we skip this duplicates and do not consider them as a bug? > >> Still have a question why we skip this duplicates and do not consider them as a bug? > > I do not have enough information to act on this issue because while not being problem listed it only occurred twice on CI system and in more than a thousand runs i was able to reproduce it once on my local system and unable to reproduce it again with all the output i've added to the code. So what i am planning to do is to leave workaround code in place but for now i will disable it and instead use it as an indicator of the problem and add a debugging output so if this issue will reappear we will have better understanding of the potential problem. Thank you. That looks great. ------------- PR: https://git.openjdk.org/jdk/pull/11157 From prr at openjdk.org Sat Nov 19 01:52:21 2022 From: prr at openjdk.org (Phil Race) Date: Sat, 19 Nov 2022 01:52:21 GMT Subject: RFR: JDK-8297230: Update Marlin2D to 0.9.4.6 In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 22:51:00 GMT, Laurent Bourg?s wrote: > Initial PR It passed all my testing, and I have looked over the code - lightly - this is OK by me. src/java.desktop/share/classes/sun/java2d/marlin/MarlinProperties.java line 87: > 85: public static boolean isProfileQuality() { > 86: final String key = "sun.java2d.renderer.profile"; > 87: final String profile = getString(key, "quality"); Not for this review, but some time we need to make sure there are no incompatibilities associated with these properties. What I really mean is a shortcut for speed that causes rendering that violates the SE spec needs to be disabled in JDK. I have no reason here to suppose that but we should test it some day. src/java.desktop/share/classes/sun/java2d/marlin/MergeSort.java line 188: > 186: // optimization that results in faster sorts for nearly ordered lists. > 187: if (srcX[mid - 1] <= srcX[mid]) { > 188: // 14 occurences I think the prior spelling was actually the correct one. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.org/jdk/pull/11225 From serb at openjdk.org Sat Nov 19 04:42:50 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 19 Nov 2022 04:42:50 GMT Subject: Integrated: 8297195: AWTAccessor and SwingAccessor should avoid double racy reads from non-volatile fields In-Reply-To: References: Message-ID: <_Rgj5bHjaUOyMRu52cFR7vmENWWgYeVLzq5ABlYb90k=.8dee523c-8471-4c69-94cc-80450fd3f977@github.com> On Thu, 17 Nov 2022 10:19:31 GMT, Sergey Bylokhov wrote: > The patch applied to SharedSecrets by https://github.com/openjdk/jdk/pull/1914 is applied to the AWTAccessor and SwingAccessor. It prevents null to be returned by the some of methods. > > See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html This pull request has now been integrated. Changeset: c50a9047 Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/c50a9047b4324b280b2b5d1fc70e18aac372a50c Stats: 156 lines in 2 files changed: 74 ins; 6 del; 76 mod 8297195: AWTAccessor and SwingAccessor should avoid double racy reads from non-volatile fields Reviewed-by: azvegint, prr ------------- PR: https://git.openjdk.org/jdk/pull/11205 From lbourges at openjdk.org Sat Nov 19 21:27:55 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Sat, 19 Nov 2022 21:27:55 GMT Subject: RFR: JDK-8297230: Update Marlin2D to 0.9.4.6 [v2] In-Reply-To: References: Message-ID: > Initial PR Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: fixed typos ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11225/files - new: https://git.openjdk.org/jdk/pull/11225/files/4516b8de..86364d55 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11225&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11225&range=00-01 Stats: 6 lines in 3 files changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11225.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11225/head:pull/11225 PR: https://git.openjdk.org/jdk/pull/11225 From lbourges at openjdk.org Sat Nov 19 22:03:44 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Sat, 19 Nov 2022 22:03:44 GMT Subject: RFR: JDK-8297230: Update Marlin2D to 0.9.4.6 [v3] In-Reply-To: References: Message-ID: <9pwnVKBg2HjC0elEK3cyxqMi-Bne2pCS3KXWfs1TWrw=.b1e5bd88-2e41-4042-84e7-5dd6c8acd21b@github.com> > Initial PR Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: added HugePolygonClipTest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11225/files - new: https://git.openjdk.org/jdk/pull/11225/files/86364d55..0ef50ab6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11225&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11225&range=01-02 Stats: 148 lines in 1 file changed: 148 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11225.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11225/head:pull/11225 PR: https://git.openjdk.org/jdk/pull/11225 From lbourges at openjdk.org Sat Nov 19 22:16:12 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Sat, 19 Nov 2022 22:16:12 GMT Subject: RFR: JDK-8297230: Update Marlin2D to 0.9.4.6 [v3] In-Reply-To: References: Message-ID: <4FBJhG0i_WZ-a6514hgDPJ7ddRmZgcNymzw41-epYyc=.1486b5c3-ad31-4cfa-8d79-cba0a73858e3@github.com> On Sat, 19 Nov 2022 01:43:59 GMT, Phil Race wrote: >> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: >> >> added HugePolygonClipTest > > src/java.desktop/share/classes/sun/java2d/marlin/MarlinProperties.java line 87: > >> 85: public static boolean isProfileQuality() { >> 86: final String key = "sun.java2d.renderer.profile"; >> 87: final String profile = getString(key, "quality"); > > Not for this review, but some time we need to make sure there are no incompatibilities > associated with these properties. What I really mean is a shortcut for speed that causes > rendering that violates the SE spec needs to be disabled in JDK. > I have no reason here to suppose that but we should test it some day. Good point, to be discussed later ------------- PR: https://git.openjdk.org/jdk/pull/11225 From serb at openjdk.org Sun Nov 20 03:19:58 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 20 Nov 2022 03:19:58 GMT Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v4] In-Reply-To: References: <6HPa6vPeV5haQI_Ifs5IRH1xcjiqbld0T2Fk_WIABAY=.c0c2f8ff-988e-4017-8e61-a365870d5e6b@github.com> Message-ID: On Mon, 14 Nov 2022 11:07:56 GMT, Artem Semenov wrote: >> Probably because of the endless notifications loop? implementation of addSelectionInterval looks similar to setSelectionInterval. In some cases the addSelectionInterval just call setSelectionInterval. > > It looks like it is. Please formulate the question differently. It is unclear why the `setSelectionInterval `is actually any better than `addAccessibleSelection`. Both have a similar implementation, in some cases, the addSelectionInterval just calls setSelectionInterval, and seems that posts similar notifications. So it is unclear why the setSelectionInterval works fine and addAccessibleSelection does not work. ------------- PR: https://git.openjdk.org/jdk/pull/8578 From prr at openjdk.org Sun Nov 20 03:42:22 2022 From: prr at openjdk.org (Phil Race) Date: Sun, 20 Nov 2022 03:42:22 GMT Subject: RFR: 8165943: LineBreakMeasurer does not measure correctly if TextAttribute.TRACKING is set. In-Reply-To: References: Message-ID: <2BW15v-Fz4IdXH_x_-2ZsG7ZENhltuqMmmKcR59mEHk=.1258a386-6858-4bfb-bba0-70ea6808e59b@github.com> On Thu, 15 Sep 2022 16:51:27 GMT, Olga Mikhaltsova wrote: > This is a fix for LineBreakMeasurer. It takes into account the TextAttribute.TRACKING value (not eq 0) while calculating the line breaks. > > Tested on Linux x64, Windows x64, macOS x64 with the reproducer (LineBreakSample.java) attached to JDK-8165943 and the following group of tests: > `$JTREG_HOME/bin/jtreg -jdk:$BUILD_HOME ./test/jdk/java/awt/font` I haven't had time to look at this. Maybe I can look at it some time in the 1st week of December. Ping me then. ------------- PR: https://git.openjdk.org/jdk/pull/10289 From serb at openjdk.org Sun Nov 20 06:36:42 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 20 Nov 2022 06:36:42 GMT Subject: RFR: 8296905: Replace the native LCMS#getProfileID() method with the accessor [v2] In-Reply-To: References: Message-ID: <_o1wpsDKzUA9fCH32jGlwT5L8s-SkQzpvuMqbdpGpjg=.c84893c7-2f2f-4233-a264-8db508bfcf46@github.com> > The native method used to access the private method in the `ICC_Profile` class is replaced by the accessor. Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Update AWTAccessor.java - Merge remote-tracking branch 'upstream/master' into JDK-8296905 - 8296905: Replace the native LCMS#getProfileID() method with the accessor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11116/files - new: https://git.openjdk.org/jdk/pull/11116/files/70b9c147..f7b74481 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11116&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11116&range=00-01 Stats: 27634 lines in 610 files changed: 10928 ins; 14095 del; 2611 mod Patch: https://git.openjdk.org/jdk/pull/11116.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11116/head:pull/11116 PR: https://git.openjdk.org/jdk/pull/11116 From serb at openjdk.org Sun Nov 20 07:25:25 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 20 Nov 2022 07:25:25 GMT Subject: RFR: 8296905: Replace the native LCMS#getProfileID() method with the accessor [v2] In-Reply-To: References: <7jMOilsUHip2idGzJGSiNEMCB4EwssM8mDmxdbAcEZw=.a71cb407-f6ab-420a-af29-6df49f8a7099@github.com> Message-ID: <7Tq0x05hWsqSvg2ClKSqPZVTxKS4iAHe5vM8hDRraVU=.83719c9a-907f-4d59-a520-6a67a26fd41f@github.com> On Mon, 14 Nov 2022 08:03:40 GMT, Sergey Bylokhov wrote: >> src/java.desktop/share/classes/sun/awt/AWTAccessor.java line 891: >> >>> 889: */ >>> 890: public static ICC_ProfileAccessor getICC_ProfileAccessor() { >>> 891: if (iccProfileAccessor == null) { >> >> For `SharedSecrets` in java.base code was updated to use single read (to avoid concurrency problems) - see [JDK-8259021](https://bugs.openjdk.org/browse/JDK-8259021) >> Shouldn't we use the same patter here? > > Yes, you are right, let me fix that first. The AWTAccessor and SwingAccessor files are updated by https://github.com/mrserb/jdk/commit/c50a9047b4324b280b2b5d1fc70e18aac372a50c. This patch now uses the new pattern. ------------- PR: https://git.openjdk.org/jdk/pull/11116 From serb at openjdk.org Sun Nov 20 09:50:09 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 20 Nov 2022 09:50:09 GMT Subject: RFR: 6528710: sRGB-ColorSpace to sRGB-ColorSpace Conversion Message-ID: <4Ux7VA_NY-kTKDL-AO_vDkssR4Oge70xb7fpLrkLvAU=.1f024496-68b8-4205-9b18-825e8bdeceef@github.com> The quality of the cmm library is increased since the bug was reported. This is the request to import the test from the bug description to improve the code coverage. ------------- Commit messages: - 6528710: sRGB-ColorSpace to sRGB-ColorSpace Conversion Changes: https://git.openjdk.org/jdk/pull/11250/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11250&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6528710 Stats: 51 lines in 1 file changed: 51 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11250.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11250/head:pull/11250 PR: https://git.openjdk.org/jdk/pull/11250 From serb at openjdk.org Sun Nov 20 11:19:24 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 20 Nov 2022 11:19:24 GMT Subject: RFR: JDK-8297230: Update Marlin2D to 0.9.4.6 [v3] In-Reply-To: <9pwnVKBg2HjC0elEK3cyxqMi-Bne2pCS3KXWfs1TWrw=.b1e5bd88-2e41-4042-84e7-5dd6c8acd21b@github.com> References: <9pwnVKBg2HjC0elEK3cyxqMi-Bne2pCS3KXWfs1TWrw=.b1e5bd88-2e41-4042-84e7-5dd6c8acd21b@github.com> Message-ID: On Sat, 19 Nov 2022 22:03:44 GMT, Laurent Bourg?s wrote: >> Initial PR > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > added HugePolygonClipTest src/java.desktop/share/classes/sun/java2d/marlin/ArrayCacheDouble.java line 51: > 49: * for a few type and name differences. Typically, the [BYTE]ArrayCache.java file > 50: * is edited manually and then [INT/FLOAT/DOUBLE]ArrayCache.java > 51: * files are generated with the following command lines: Looks like here and in other places this comment became outdated since the "command lines" below are removed? ------------- PR: https://git.openjdk.org/jdk/pull/11225 From lbourges at openjdk.org Sun Nov 20 11:32:16 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Sun, 20 Nov 2022 11:32:16 GMT Subject: RFR: JDK-8297230: Update Marlin2D to 0.9.4.6 [v3] In-Reply-To: References: <9pwnVKBg2HjC0elEK3cyxqMi-Bne2pCS3KXWfs1TWrw=.b1e5bd88-2e41-4042-84e7-5dd6c8acd21b@github.com> Message-ID: On Sun, 20 Nov 2022 11:15:33 GMT, Sergey Bylokhov wrote: >> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: >> >> added HugePolygonClipTest > > src/java.desktop/share/classes/sun/java2d/marlin/ArrayCacheDouble.java line 51: > >> 49: * for a few type and name differences. Typically, the [BYTE]ArrayCache.java file >> 50: * is edited manually and then [INT/FLOAT/DOUBLE]ArrayCache.java >> 51: * files are generated with the following command lines: > > Looks like here and in other places this comment became outdated since the "command lines" below are removed? You're right, I will fix that comment in all ArrayCacheXXX files. ------------- PR: https://git.openjdk.org/jdk/pull/11225 From alanb at openjdk.org Sun Nov 20 15:20:20 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 20 Nov 2022 15:20:20 GMT Subject: RFR: 8297303: ProblemList java/awt/Mouse/EnterExitEvents/DragWindowTest.java on macosx-all In-Reply-To: References: Message-ID: On Sun, 20 Nov 2022 14:59:12 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/awt/Mouse/EnterExitEvents/DragWindowTest.java on macosx-all Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11252 From azvegint at openjdk.org Sun Nov 20 15:20:21 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Sun, 20 Nov 2022 15:20:21 GMT Subject: RFR: 8297303: ProblemList java/awt/Mouse/EnterExitEvents/DragWindowTest.java on macosx-all In-Reply-To: References: Message-ID: <6UO8IMjyeUjo-KjZJOPCoBxEOA_tp52923zP3g8_TdQ=.a461215e-8ab5-4e8a-8ca8-0b380b8ac686@github.com> On Sun, 20 Nov 2022 14:59:12 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/awt/Mouse/EnterExitEvents/DragWindowTest.java on macosx-all Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11252 From dcubed at openjdk.org Sun Nov 20 15:20:21 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sun, 20 Nov 2022 15:20:21 GMT Subject: RFR: 8297303: ProblemList java/awt/Mouse/EnterExitEvents/DragWindowTest.java on macosx-all In-Reply-To: References: Message-ID: On Sun, 20 Nov 2022 15:14:40 GMT, Alan Bateman wrote: >> A trivial fix to ProblemList java/awt/Mouse/EnterExitEvents/DragWindowTest.java on macosx-all > > Marked as reviewed by alanb (Reviewer). @AlanBateman and @azvegint - Thanks for the fast reviews! ------------- PR: https://git.openjdk.org/jdk/pull/11252 From dcubed at openjdk.org Sun Nov 20 15:22:15 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sun, 20 Nov 2022 15:22:15 GMT Subject: Integrated: 8297303: ProblemList java/awt/Mouse/EnterExitEvents/DragWindowTest.java on macosx-all In-Reply-To: References: Message-ID: On Sun, 20 Nov 2022 14:59:12 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/awt/Mouse/EnterExitEvents/DragWindowTest.java on macosx-all This pull request has now been integrated. Changeset: dd553101 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/dd553101348017243893c51619999c62eb93a18e Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8297303: ProblemList java/awt/Mouse/EnterExitEvents/DragWindowTest.java on macosx-all Reviewed-by: alanb, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/11252 From duke at openjdk.org Sun Nov 20 20:03:19 2022 From: duke at openjdk.org (SWinxy) Date: Sun, 20 Nov 2022 20:03:19 GMT Subject: RFR: JDK-8296661 : Fix typo In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 01:56:05 GMT, ScientificWare wrote: > This is referenced in Java Bug Database as > - [JDK-8296661 : Fix typo](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8296661) > > This is tracked in JBS as > - [JDK-8296661 : Fix typo](https://bugs.openjdk.java.net/browse/JDK-8296661) > > I suspect a typo in the documentation comments. > > Designed from : [ScientificWare JDK-8293776 : Fix typo](https://github.com/scientificware/jdk/issues/18) Marked as reviewed by SWinxy at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.org/jdk/pull/10975 From duke at openjdk.org Mon Nov 21 00:47:49 2022 From: duke at openjdk.org (duke) Date: Mon, 21 Nov 2022 00:47:49 GMT Subject: Withdrawn: 8293478: [java.desktop/macOS] Condense SDRenderType usages in QuartzRenderer.m In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 23:41:40 GMT, SWinxy wrote: > The `SDRenderType` enum is often returned using a variable declared at the start of functions. These can be inlined in the `return` itself. Using a ternary operator condenses what may be 12 lines into one, in the most extreme cases. `doRectUsingCG` and `doPolyUsingCG` were both modified more than the rest, but are still basically the same. > > Example change: > > SDRenderType renderType = SD_Nothing; > > if (fill == YES) > { > renderType = SD_Fill; > } > else > { > renderType = SD_Stroke; > } > > // draw logic > > return renderType; > > > > // draw logic > > return fill ? SD_Fill : SD_Stroke; This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/10174 From jdv at openjdk.org Mon Nov 21 03:18:14 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 21 Nov 2022 03:18:14 GMT Subject: RFR: 8297241: Update sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 12:27:46 GMT, Jayathirth D V wrote: > This is follow up of https://github.com/openjdk/jdk/pull/11158#discussion_r1025574199 > > I have added empty paint() and update() methods back for the frame in this test. > Ran the test 20 times in our CI machines on all platforms. It failed once in Linux machine and image dump showed nothing was drawn. > > Added robot.waitForIdle() after frame.resize() also so that system-triggered repaint can be finished after resize of the frame. With this update i don't see this test failing on all platforms in our CI even when run for 100 times. @mrserb please take a look ------------- PR: https://git.openjdk.org/jdk/pull/11237 From duke at openjdk.org Mon Nov 21 05:20:29 2022 From: duke at openjdk.org (Naveen Narayanan) Date: Mon, 21 Nov 2022 05:20:29 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem [v6] In-Reply-To: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> Message-ID: > This testcase will > 1) Verify setAccelerator method of JMenuitem. > 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M. > > Testing: > Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: 8296275: Review comments fixed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11035/files - new: https://git.openjdk.org/jdk/pull/11035/files/a7c30098..a8e13a4c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11035&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11035&range=04-05 Stats: 20 lines in 1 file changed: 3 ins; 9 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/11035.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11035/head:pull/11035 PR: https://git.openjdk.org/jdk/pull/11035 From xuelei at openjdk.org Mon Nov 21 06:18:13 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 21 Nov 2022 06:18:13 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 In-Reply-To: References: Message-ID: On Sun, 13 Nov 2022 20:48:04 GMT, Kim Barrett wrote: >> Hi, >> >> May I have this update reviewed? >> >> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. >> >> Thanks, >> Xuelei > > Please don't add uses of `jio_snprintf` or `::snprintf` to hotspot. Use `os::snprintf`. > > Regarding `jio_snprintf`, see https://bugs.openjdk.org/browse/JDK-8198918. > Regarding `os::snprintf` and `os::vsnprintf`, see https://bugs.openjdk.org/browse/JDK-8285506. > > I think the only reason we haven't marked `::sprintf` and `::snprintf` forbidden > (FORBID_C_FUNCTION) is there are a lot of uses, and nobody has gotten around > to dealing with it. `::snprintf` in the list of candidates for > https://bugs.openjdk.org/browse/JDK-8214976, some of which have already been > marked. But I don't see new bugs for the as-yet unmarked ones. > > As a general note, as a reviewer my preference is against non-trivial and > persnickety code changes that are scattered all over the code base. For > something like this I'd prefer multiple more bite-sized changes that were > dealing with specific uses. I doubt everyone agrees with me though. @kimbarrett, did you have further comments? I'm going to integrate this update this week. Please let me know if you need more time. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11115 From dholmes at openjdk.org Mon Nov 21 07:35:15 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 21 Nov 2022 07:35:15 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 06:14:44 GMT, Xue-Lei Andrew Fan wrote: >> Please don't add uses of `jio_snprintf` or `::snprintf` to hotspot. Use `os::snprintf`. >> >> Regarding `jio_snprintf`, see https://bugs.openjdk.org/browse/JDK-8198918. >> Regarding `os::snprintf` and `os::vsnprintf`, see https://bugs.openjdk.org/browse/JDK-8285506. >> >> I think the only reason we haven't marked `::sprintf` and `::snprintf` forbidden >> (FORBID_C_FUNCTION) is there are a lot of uses, and nobody has gotten around >> to dealing with it. `::snprintf` in the list of candidates for >> https://bugs.openjdk.org/browse/JDK-8214976, some of which have already been >> marked. But I don't see new bugs for the as-yet unmarked ones. >> >> As a general note, as a reviewer my preference is against non-trivial and >> persnickety code changes that are scattered all over the code base. For >> something like this I'd prefer multiple more bite-sized changes that were >> dealing with specific uses. I doubt everyone agrees with me though. > > @kimbarrett, did you have further comments? I'm going to integrate this update this week. Please let me know if you need more time. Thanks! @XueleiFan AFAICS only @tstuefe has reviewed the version where you check the return value, and as such you need a second reviewer for this nominal final version of the fix. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From mbaesken at openjdk.org Mon Nov 21 08:13:18 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 21 Nov 2022 08:13:18 GMT Subject: RFR: JDK-8297147: UnexpectedSourceImageSize test times out on slow machines when fastdebug is used In-Reply-To: References: <5j1gQSL_VUXqBFasAHTCF3tFdv2BY8hqD339Xwca8Qs=.6d40f959-1cc5-48da-aaa7-5f667fa76ebb@github.com> Message-ID: On Fri, 18 Nov 2022 19:24:39 GMT, Sergey Bylokhov wrote: > Are you sure that it is fine to bump the timeout from 2 mins to 10 minutes? It is quite big slowdown. Hi Sergey, I was looking around what other slow tests of this kind of jdk tests use, and took the same timeout values that are used in the jdk/sun/java2d/cmm/ColorConvertOp test https://github.com/openjdk/jdk/blob/master/test/jdk/sun/java2d/cmm/ColorConvertOp/MTTransformValidation.java#L33 Should I try with 300 instead of 600 ? ------------- PR: https://git.openjdk.org/jdk/pull/11240 From serb at openjdk.org Mon Nov 21 09:34:02 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 21 Nov 2022 09:34:02 GMT Subject: RFR: 8296957: One more cast in SAFE_SIZE_NEW_ARRAY2 Message-ID: Implementation of SAFE_SIZE_NEW_ARRAY2 in the `sizecalc.h` missed one cast to the size_t ------------- Commit messages: - 8296957: One more cast in SAFE_SIZE_NEW_ARRAY2 Changes: https://git.openjdk.org/jdk/pull/11253/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11253&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296957 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11253.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11253/head:pull/11253 PR: https://git.openjdk.org/jdk/pull/11253 From serb at openjdk.org Mon Nov 21 09:34:11 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 21 Nov 2022 09:34:11 GMT Subject: RFR: 8297241: Update sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java In-Reply-To: References: Message-ID: <_la4iFGTfiFSIgO-Z_eu8YkzJLo7NCGMuhVVFtA796M=.20b6b18c-2d26-47a9-a5bd-b56ef071e300@github.com> On Fri, 18 Nov 2022 12:27:46 GMT, Jayathirth D V wrote: > This is follow up of https://github.com/openjdk/jdk/pull/11158#discussion_r1025574199 > > I have added empty paint() and update() methods back for the frame in this test. > Ran the test 20 times in our CI machines on all platforms. It failed once in Linux machine and image dump showed nothing was drawn. > > Added robot.waitForIdle() after frame.resize() also so that system-triggered repaint can be finished after resize of the frame. With this update i don't see this test failing on all platforms in our CI even when run for 100 times. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11237 From jdv at openjdk.org Mon Nov 21 09:53:37 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 21 Nov 2022 09:53:37 GMT Subject: Integrated: 8297241: Update sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java In-Reply-To: References: Message-ID: <3X6VaKUh1kRfy9Ksga-ufGlJUhStT3O4TQg-z42e-0I=.fcb9dff5-8a4e-4710-b446-9d8dd0705856@github.com> On Fri, 18 Nov 2022 12:27:46 GMT, Jayathirth D V wrote: > This is follow up of https://github.com/openjdk/jdk/pull/11158#discussion_r1025574199 > > I have added empty paint() and update() methods back for the frame in this test. > Ran the test 20 times in our CI machines on all platforms. It failed once in Linux machine and image dump showed nothing was drawn. > > Added robot.waitForIdle() after frame.resize() also so that system-triggered repaint can be finished after resize of the frame. With this update i don't see this test failing on all platforms in our CI even when run for 100 times. This pull request has now been integrated. Changeset: 3c094982 Author: Jayathirth D V URL: https://git.openjdk.org/jdk/commit/3c0949824e06f2b3d44f1bde9d2292a7627b0197 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod 8297241: Update sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java 8297153: sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java fails again Reviewed-by: serb ------------- PR: https://git.openjdk.org/jdk/pull/11237 From jdv at openjdk.org Mon Nov 21 10:07:23 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 21 Nov 2022 10:07:23 GMT Subject: RFR: 8191406: [hidpi] sun/java2d/SunGraphics2D/DrawImageBilinear.java test fails [v3] In-Reply-To: References: <3mHTs6Gpmb2JPxOfF9Ii7-eBRsvLnsqykBu7gkltH-M=.a2979bc5-b386-4c5f-b621-30f2a993090d@github.com> Message-ID: On Fri, 18 Nov 2022 06:52:52 GMT, Jayathirth D V wrote: >> This test was failing because of timing or color difference issues. >> Updated test to: >> >> 1) Use EDT for UI drawing instead of manual synchronisation >> 2) Use Robot.waitForIdle before screen capture >> 3) Increase color tolerance delta from 1 to 5 >> 4) Use undecorated frame and explicitly set background color and move the frame to top >> 5) Cleanup to remove not needed flags and java options >> >> After these changes test passes on all platforms in CI except Linux. For Linux it looks like product issue so i have raised : https://bugs.openjdk.org/browse/JDK-8297175 > > Jayathirth D V has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains four commits: > > - Remove image dump > - ProblemList only on Linux > - Add background color and tolerance > - Initial change I am ignoring the previous comment. Even after translating, the comment looks to be not related to current PR. @mrserb please take a look at updated PR. ------------- PR: https://git.openjdk.org/jdk/pull/11201 From lbourges at openjdk.org Mon Nov 21 10:15:01 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Mon, 21 Nov 2022 10:15:01 GMT Subject: RFR: JDK-8297230: Update Marlin2D to 0.9.4.6 [v4] In-Reply-To: References: Message-ID: > Initial PR Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: fixed class header comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11225/files - new: https://git.openjdk.org/jdk/pull/11225/files/0ef50ab6..4912b048 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11225&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11225&range=02-03 Stats: 19 lines in 4 files changed: 0 ins; 4 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/11225.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11225/head:pull/11225 PR: https://git.openjdk.org/jdk/pull/11225 From asemenov at openjdk.org Mon Nov 21 10:48:21 2022 From: asemenov at openjdk.org (Artem Semenov) Date: Mon, 21 Nov 2022 10:48:21 GMT Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v4] In-Reply-To: References: <6HPa6vPeV5haQI_Ifs5IRH1xcjiqbld0T2Fk_WIABAY=.c0c2f8ff-988e-4017-8e61-a365870d5e6b@github.com> Message-ID: On Sun, 20 Nov 2022 03:16:28 GMT, Sergey Bylokhov wrote: >> It looks like it is. Please formulate the question differently. > > It is unclear why the `setSelectionInterval `is actually any better than `addAccessibleSelection`. Both have a similar implementation, in some cases, the addSelectionInterval just calls setSelectionInterval, and seems that posts similar notifications. So it is unclear why the setSelectionInterval works fine and addAccessibleSelection does not work. I tried calling clearSelection again instead of adding an interface: if (as == null) return; if (pac.getAccessibleRole().equals(AccessibleRole.LIST)) { as.clearAccessibleSelection(); } as.addAccessibleSelection(i); After that I changed the call to ```javax.swing.JList.AccessibleJList#addAccessibleSelection``` JList.this.addSelectionInterval(i, i); on the JList.this.getSelectionModel().setSelectionInterval(i, i); Nothing changed. VoiceOVer still freezes. The problem is not that setting the selection doesn't work, but that clearing the selection before setting causes the VO to fris. ------------- PR: https://git.openjdk.org/jdk/pull/8578 From omikhaltcova at openjdk.org Mon Nov 21 10:48:28 2022 From: omikhaltcova at openjdk.org (Olga Mikhaltsova) Date: Mon, 21 Nov 2022 10:48:28 GMT Subject: RFR: 8165943: LineBreakMeasurer does not measure correctly if TextAttribute.TRACKING is set. In-Reply-To: References: Message-ID: On Thu, 15 Sep 2022 16:51:27 GMT, Olga Mikhaltsova wrote: > This is a fix for LineBreakMeasurer. It takes into account the TextAttribute.TRACKING value (not eq 0) while calculating the line breaks. > > Tested on Linux x64, Windows x64, macOS x64 with the reproducer (LineBreakSample.java) attached to JDK-8165943 and the following group of tests: > `$JTREG_HOME/bin/jtreg -jdk:$BUILD_HOME ./test/jdk/java/awt/font` Thanks! I'll ping you in 1,5 weeks. ------------- PR: https://git.openjdk.org/jdk/pull/10289 From azvegint at openjdk.org Mon Nov 21 10:51:42 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 21 Nov 2022 10:51:42 GMT Subject: Integrated: 8148041: Test java/awt/Mouse/TitleBarDoubleClick/TitleBarDoubleClick fails on Ubuntu with mouseReleased event after double click on title bar In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 00:21:23 GMT, Alexander Zvegintsev wrote: > This test was problem listed with ["some tests that leave windows open on the desktop" reason](https://github.com/openjdk/jdk/commit/fd8df3adf13f5df8f5f95482b8e0a70bc519f39f) > > The main issue with the test is that it may pass, but in fact the actual test was not even performed.
`jtreg` kills the test window after exiting main and ends the test before it double clicks on window's title(actual test starts from `windowActivated` event). > > So the test was refactored and stabilized: > * robot invocation moved from EDT to main thread. > * throwing test exception is performed only after frame is disposed > * extra delay added after showing window. > > Old Ubuntu 16.04 and macOS 10.10.5 failures is no longer reproducible on modern systems. > > CI testing looks good. This pull request has now been integrated. Changeset: 2fc340a7 Author: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/2fc340a7030e895c264c39fc8690af108a6ad921 Stats: 87 lines in 2 files changed: 28 ins; 8 del; 51 mod 8148041: Test java/awt/Mouse/TitleBarDoubleClick/TitleBarDoubleClick fails on Ubuntu with mouseReleased event after double click on title bar Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/11150 From azvegint at openjdk.org Mon Nov 21 13:43:20 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 21 Nov 2022 13:43:20 GMT Subject: Integrated: 8196018: java/awt/Scrollbar/ScrollbarMouseWheelTest/ScrollbarMouseWheelTest.java fails In-Reply-To: References: Message-ID: <9ZPBqFrjjJwLHTMIT4U8BgCDC2widfAnbf4bKdgm8eM=.183ce852-a256-44f6-8b12-dd02db61b7f7@github.com> On Thu, 17 Nov 2022 14:38:41 GMT, Alexander Zvegintsev wrote: > The issue contains evaluation: > * the test is not failing on Windows > * it also fails on Linux(but provided stack trace with failure is from different test) > > I rechecked the test and it does not fail on all platforms. > > Test is stabilized: > * replaced synchronization on windowActivated event with standard `robot.waitForIdle(); robot.delay(1000);` > * Robot autoDelay decreased to 250 to make the test go faster. It it still a reasonable value. > > CI testing looks good also. This pull request has now been integrated. Changeset: 16ab754e Author: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/16ab754e49fef50b373e9d30ef889a53c23fa530 Stats: 55 lines in 2 files changed: 17 ins; 28 del; 10 mod 8196018: java/awt/Scrollbar/ScrollbarMouseWheelTest/ScrollbarMouseWheelTest.java fails Reviewed-by: psadhukhan, serb, dnguyen ------------- PR: https://git.openjdk.org/jdk/pull/11213 From psadhukhan at openjdk.org Mon Nov 21 13:48:46 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 21 Nov 2022 13:48:46 GMT Subject: RFR: 6788481: CellEditorListener.editingCanceled is never called [v2] In-Reply-To: References: Message-ID: > When editing of a table cell is canceled, the function editingCanceled of the registered listener CellEditorListener is not called as actionPerformed on ESC key press was not notifying the "cancel" listeners. > Fix is to handle "Cancel" action in actionPerformed() by forwarding the Cancel message from CellEditor to the delegate so that it can call `AbstractCellEditor.fireEditingCanceled(`) which notifies all listeners of cancel event. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Updated test to test all installed L&F ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10964/files - new: https://git.openjdk.org/jdk/pull/10964/files/02c8fc00..3efbfa7b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10964&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10964&range=00-01 Stats: 22 lines in 1 file changed: 21 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10964.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10964/head:pull/10964 PR: https://git.openjdk.org/jdk/pull/10964 From psadhukhan at openjdk.org Mon Nov 21 13:48:49 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 21 Nov 2022 13:48:49 GMT Subject: RFR: 6788481: CellEditorListener.editingCanceled is never called [v2] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 05:51:21 GMT, Sergey Bylokhov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated test to test all installed L&F > > test/jdk/javax/swing/JTable/BugCellEditorListener.java line 51: > >> 49: static volatile boolean cancelled; >> 50: >> 51: public static void main(String [] args) throws Exception { > > Can the test validates all installed L&F and not only default metal/aqua? test updated ------------- PR: https://git.openjdk.org/jdk/pull/10964 From duke at openjdk.org Mon Nov 21 15:05:57 2022 From: duke at openjdk.org (azul-jf) Date: Mon, 21 Nov 2022 15:05:57 GMT Subject: RFR: 8165943: LineBreakMeasurer does not measure correctly if TextAttribute.TRACKING is set. In-Reply-To: <2BW15v-Fz4IdXH_x_-2ZsG7ZENhltuqMmmKcR59mEHk=.1258a386-6858-4bfb-bba0-70ea6808e59b@github.com> References: <2BW15v-Fz4IdXH_x_-2ZsG7ZENhltuqMmmKcR59mEHk=.1258a386-6858-4bfb-bba0-70ea6808e59b@github.com> Message-ID: On Sun, 20 Nov 2022 03:39:56 GMT, Phil Race wrote: >> This is a fix for LineBreakMeasurer. It takes into account the TextAttribute.TRACKING value (not eq 0) while calculating the line breaks. >> >> Tested on Linux x64, Windows x64, macOS x64 with the reproducer (LineBreakSample.java) attached to JDK-8165943 and the following group of tests: >> `$JTREG_HOME/bin/jtreg -jdk:$BUILD_HOME ./test/jdk/java/awt/font` > > I haven't had time to look at this. Maybe I can look at it some time in the 1st week of December. Ping me then. Hi @prrace, this came to our attention as a customer issue. The reproducer we used was the one from JDK-8165943. As a reminder of the issue and an illustration of the desired outcome, here are some screen captures. Existing code, TRACKING = 0.0: ![image](https://user-images.githubusercontent.com/68303684/203083698-a557b968-2e68-48b5-8313-09f7458b91c5.png) Existing code, TRACKING = 0.1: ![image](https://user-images.githubusercontent.com/68303684/203084245-f32ae45f-0d1b-4419-8d7d-274f23d14155.png) Submitted code, TRACKING = 0.1: ![image](https://user-images.githubusercontent.com/68303684/203084873-c31da8e2-7044-4737-a15d-2738f90e4929.png) ------------- PR: https://git.openjdk.org/jdk/pull/10289 From duke at openjdk.org Mon Nov 21 16:06:58 2022 From: duke at openjdk.org (Christian Heilmann) Date: Mon, 21 Nov 2022 16:06:58 GMT Subject: RFR: 8297191 fixed printing page range for e.g. page 2 to 2 on macOS Message-ID: 8297191 fixed printing page range for e.g. page 2 to 2 on macOS ------------- Commit messages: - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS Changes: https://git.openjdk.org/jdk/pull/11266/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11266&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297191 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11266.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11266/head:pull/11266 PR: https://git.openjdk.org/jdk/pull/11266 From vdyakov at openjdk.org Mon Nov 21 17:15:18 2022 From: vdyakov at openjdk.org (Victor Dyakov) Date: Mon, 21 Nov 2022 17:15:18 GMT Subject: RFR: 8296957: One more cast in SAFE_SIZE_NEW_ARRAY2 In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 01:22:49 GMT, Sergey Bylokhov wrote: > Implementation of SAFE_SIZE_NEW_ARRAY2 in the `sizecalc.h` missed one cast to the size_t @aivanov-jdk @azuev-java Please review ------------- PR: https://git.openjdk.org/jdk/pull/11253 From dnguyen at openjdk.org Mon Nov 21 17:28:58 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 21 Nov 2022 17:28:58 GMT Subject: RFR: 8239801: [macos] java/awt/Focus/UnaccessibleChoice/AccessibleChoiceTest.java fails [v2] In-Reply-To: <1ucV0BHh8XBiFbdJncIVAPXAPXmgJEwDD8f9EWmssnQ=.48c4c221-c5a0-4211-9d15-6de0c7a7da87@github.com> References: <1ucV0BHh8XBiFbdJncIVAPXAPXmgJEwDD8f9EWmssnQ=.48c4c221-c5a0-4211-9d15-6de0c7a7da87@github.com> Message-ID: > This is an older test that failed intermittently but had a fix specifically for mac systems by adding key presses on mac only. This test still intermittently failed after this fix long ago and was problem listed. > > I ran this test 100 times on each OS after applying waitForIdle and delays between all key presses to match the delays previously present in the test. > > I also added a debug line and save and image of the failing window upon failure to better debug if/when the test ever fails again. The debug line is to check if the previous fix for mac is relevant in the failure. The image shows the status of the window and what is focused at the time of failure. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Modify delays. Capture full screen instead. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11227/files - new: https://git.openjdk.org/jdk/pull/11227/files/720c651c..386edcbc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11227&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11227&range=00-01 Stats: 8 lines in 1 file changed: 3 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11227.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11227/head:pull/11227 PR: https://git.openjdk.org/jdk/pull/11227 From lbourges at openjdk.org Mon Nov 21 17:32:21 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Mon, 21 Nov 2022 17:32:21 GMT Subject: RFR: JDK-8297230: Update Marlin2D to 0.9.4.6 [v4] In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 10:15:01 GMT, Laurent Bourg?s wrote: >> Initial PR > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > fixed class header comment A phil approved early, I fixed comments and added a new test. Is it now good to integrate @mrserb ? ------------- PR: https://git.openjdk.org/jdk/pull/11225 From aivanov at openjdk.org Mon Nov 21 18:35:41 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 21 Nov 2022 18:35:41 GMT Subject: RFR: 8294807: Fix typos and clarify javadoc for SunToolKit.realsSync In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 20:21:10 GMT, Alexey Ivanov wrote: > I fixed the typo ?serie? ? "series" which was highlighted by a spellchecker. > > I also simplified the description, fixed the grammar, added `{@code}` around types, added link to `requestFocus` in the example. I need more time? ------------- PR: https://git.openjdk.org/jdk/pull/10563 From aivanov at openjdk.org Mon Nov 21 18:36:20 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 21 Nov 2022 18:36:20 GMT Subject: RFR: 8296957: One more cast in SAFE_SIZE_NEW_ARRAY2 In-Reply-To: References: Message-ID: <1rzYquEZQAItotA0EHZR7LRQkp4uFoZDaw0xJmTB01g=.6d18b832-0ffc-48fd-93a8-791e8c1ada4a@github.com> On Mon, 21 Nov 2022 01:22:49 GMT, Sergey Bylokhov wrote: > Implementation of SAFE_SIZE_NEW_ARRAY2 in the `sizecalc.h` missed one cast to the size_t Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11253 From dnguyen at openjdk.org Mon Nov 21 21:04:33 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 21 Nov 2022 21:04:33 GMT Subject: RFR: 8202931: [macos] java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java fails Message-ID: Test ran on all OS 100 times and passed. Test previously failed on macOS but no longer reproducible. Added screen capture on moment of failure to have more evidence of failures in the future (previously a runtime exception was thrown only). ------------- Commit messages: - Add screen capture of failure - Remove test from ProblemList Changes: https://git.openjdk.org/jdk/pull/11277/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11277&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8202931 Stats: 11 lines in 2 files changed: 9 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11277.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11277/head:pull/11277 PR: https://git.openjdk.org/jdk/pull/11277 From serb at openjdk.org Tue Nov 22 01:35:25 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 22 Nov 2022 01:35:25 GMT Subject: RFR: 8202931: [macos] java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java fails In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 20:56:40 GMT, Damon Nguyen wrote: > Test ran on all OS 100 times and passed. Test previously failed on macOS but no longer reproducible. Added screen capture on moment of failure to have more evidence of failures in the future (previously a runtime exception was thrown only). test/jdk/java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java line 130: > 128: .getLocalGraphicsEnvironment().getDefaultScreenDevice() > 129: .getDefaultConfiguration(); > 130: BufferedImage failImage = robot.createScreenCapture(ge.getBounds()); The test verifies all GraphicsDevice in the system, so the screenshot should be done on the screen where the popup is currently shown, ------------- PR: https://git.openjdk.org/jdk/pull/11277 From serb at openjdk.org Tue Nov 22 03:22:05 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 22 Nov 2022 03:22:05 GMT Subject: RFR: 8191406: [hidpi] sun/java2d/SunGraphics2D/DrawImageBilinear.java test fails [v2] In-Reply-To: References: <3mHTs6Gpmb2JPxOfF9Ii7-eBRsvLnsqykBu7gkltH-M=.a2979bc5-b386-4c5f-b621-30f2a993090d@github.com> Message-ID: On Fri, 18 Nov 2022 06:49:38 GMT, Jayathirth D V wrote: >> This test was failing because of timing or color difference issues. >> Updated test to: >> >> 1) Use EDT for UI drawing instead of manual synchronisation >> 2) Use Robot.waitForIdle before screen capture >> 3) Increase color tolerance delta from 1 to 5 >> 4) Use undecorated frame and explicitly set background color and move the frame to top >> 5) Cleanup to remove not needed flags and java options >> >> After these changes test passes on all platforms in CI except Linux. For Linux it looks like product issue so i have raised : https://bugs.openjdk.org/browse/JDK-8297175 > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Remove extra tolerance and background color test/jdk/sun/java2d/SunGraphics2D/DrawImageBilinear.java line 149: > 147: EventQueue.invokeAndWait(() -> createAndShowGUI()); > 148: } catch (Exception ex) { > 149: ex.printStackTrace(); It will be better to halt the test at this point if the exception was thrown during UI creation. ------------- PR: https://git.openjdk.org/jdk/pull/11201 From serb at openjdk.org Tue Nov 22 04:46:20 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 22 Nov 2022 04:46:20 GMT Subject: RFR: JDK-8297147: UnexpectedSourceImageSize test times out on slow machines when fastdebug is used In-Reply-To: <5j1gQSL_VUXqBFasAHTCF3tFdv2BY8hqD339Xwca8Qs=.6d40f959-1cc5-48da-aaa7-5f667fa76ebb@github.com> References: <5j1gQSL_VUXqBFasAHTCF3tFdv2BY8hqD339Xwca8Qs=.6d40f959-1cc5-48da-aaa7-5f667fa76ebb@github.com> Message-ID: On Fri, 18 Nov 2022 13:38:47 GMT, Matthias Baesken wrote: > The image related test UnexpectedSourceImageSize test introduced with https://bugs.openjdk.org/browse/JDK-8264666 > sometimes times out on slow machines when fastdebug is used. This happens especially in 11 and 17; in 20 it seems to be a bit faster but we better change timeouts across releases. I think it is fine then. ------------- Marked as reviewed by serb (Reviewer). PR: https://git.openjdk.org/jdk/pull/11240 From serb at openjdk.org Tue Nov 22 04:46:22 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 22 Nov 2022 04:46:22 GMT Subject: RFR: 6788481: CellEditorListener.editingCanceled is never called [v2] In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 13:48:46 GMT, Prasanta Sadhukhan wrote: >> When editing of a table cell is canceled, the function editingCanceled of the registered listener CellEditorListener is not called as actionPerformed on ESC key press was not notifying the "cancel" listeners. >> Fix is to handle "Cancel" action in actionPerformed() by forwarding the Cancel message from CellEditor to the delegate so that it can call `AbstractCellEditor.fireEditingCanceled(`) which notifies all listeners of cancel event. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Updated test to test all installed L&F Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10964 From jdv at openjdk.org Tue Nov 22 05:33:21 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 22 Nov 2022 05:33:21 GMT Subject: RFR: 8191406: [hidpi] sun/java2d/SunGraphics2D/DrawImageBilinear.java test fails [v4] In-Reply-To: <3mHTs6Gpmb2JPxOfF9Ii7-eBRsvLnsqykBu7gkltH-M=.a2979bc5-b386-4c5f-b621-30f2a993090d@github.com> References: <3mHTs6Gpmb2JPxOfF9Ii7-eBRsvLnsqykBu7gkltH-M=.a2979bc5-b386-4c5f-b621-30f2a993090d@github.com> Message-ID: > This test was failing because of timing or color difference issues. > Updated test to: > > 1) Use EDT for UI drawing instead of manual synchronisation > 2) Use Robot.waitForIdle before screen capture > 3) Increase color tolerance delta from 1 to 5 > 4) Use undecorated frame and explicitly set background color and move the frame to top > 5) Cleanup to remove not needed flags and java options > > After these changes test passes on all platforms in CI except Linux. For Linux it looks like product issue so i have raised : https://bugs.openjdk.org/browse/JDK-8297175 Jayathirth D V has updated the pull request incrementally with two additional commits since the last revision: - Exit on non creation of GUI - Remove extra tolerance and background color ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11201/files - new: https://git.openjdk.org/jdk/pull/11201/files/60c75caa..78eb2906 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11201&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11201&range=02-03 Stats: 22 lines in 1 file changed: 2 ins; 18 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11201.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11201/head:pull/11201 PR: https://git.openjdk.org/jdk/pull/11201 From jdv at openjdk.org Tue Nov 22 05:33:22 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 22 Nov 2022 05:33:22 GMT Subject: RFR: 8191406: [hidpi] sun/java2d/SunGraphics2D/DrawImageBilinear.java test fails [v2] In-Reply-To: References: <3mHTs6Gpmb2JPxOfF9Ii7-eBRsvLnsqykBu7gkltH-M=.a2979bc5-b386-4c5f-b621-30f2a993090d@github.com> Message-ID: On Tue, 22 Nov 2022 03:18:11 GMT, Sergey Bylokhov wrote: >> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove extra tolerance and background color > > test/jdk/sun/java2d/SunGraphics2D/DrawImageBilinear.java line 149: > >> 147: EventQueue.invokeAndWait(() -> createAndShowGUI()); >> 148: } catch (Exception ex) { >> 149: ex.printStackTrace(); > > It will be better to halt the test at this point if the exception was thrown during UI creation. Tested and updated. ------------- PR: https://git.openjdk.org/jdk/pull/11201 From mbaesken at openjdk.org Tue Nov 22 08:05:10 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 22 Nov 2022 08:05:10 GMT Subject: Integrated: JDK-8297147: UnexpectedSourceImageSize test times out on slow machines when fastdebug is used In-Reply-To: <5j1gQSL_VUXqBFasAHTCF3tFdv2BY8hqD339Xwca8Qs=.6d40f959-1cc5-48da-aaa7-5f667fa76ebb@github.com> References: <5j1gQSL_VUXqBFasAHTCF3tFdv2BY8hqD339Xwca8Qs=.6d40f959-1cc5-48da-aaa7-5f667fa76ebb@github.com> Message-ID: On Fri, 18 Nov 2022 13:38:47 GMT, Matthias Baesken wrote: > The image related test UnexpectedSourceImageSize test introduced with https://bugs.openjdk.org/browse/JDK-8264666 > sometimes times out on slow machines when fastdebug is used. This happens especially in 11 and 17; in 20 it seems to be a bit faster but we better change timeouts across releases. This pull request has now been integrated. Changeset: 88957a7c Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/88957a7ce8932b95e3a18e6a7d1ceb3b7f60c781 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8297147: UnexpectedSourceImageSize test times out on slow machines when fastdebug is used Reviewed-by: stuefe, serb ------------- PR: https://git.openjdk.org/jdk/pull/11240 From kbarrett at openjdk.org Tue Nov 22 08:05:27 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 22 Nov 2022 08:05:27 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v12] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 19:25:32 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> May I have this update reviewed? >> >> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > extra sizeof typo Given all the near-duplicated checking of os::snprintf results, I think there is a place for a helper function to package this up. Maybe something like // in class os // Performs snprintf and asserts the result is non-negative (so there was not // an encoding error) and that the output was not truncated. static int snprintf_checked(char* buf, size_t len, const char* fmt, ...) ATTRIBUTE_PRINTF(3, 4); // in runtime/os.cpp int os::snprintf_checked(char* buf, size_t len, const char* fmt, ...) { va_list args; va_start(args, fmt); int result = os::vsnprintf(buf, len, fmt, args); va_end(args); assert(result >= 0, "os::snprintf error"); assert(static_cast(result) < size, "os::snprintf truncated"); return result; } (I keep waffling over whether the truncation check should be an assert or a guarantee.) I've not yet gone through all the changes yet to consider which should do that checking and which should do something different, such as permitting truncation. I'm not wedded to that name; indeed, I don't like it that much, as it's kind of inconveniently long. There's a temptation to have os::snprintf forbid truncation and a different function that allows it, but that would require careful auditing of all pre-existing uses of os::snprintf too, so no. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From azvegint at openjdk.org Tue Nov 22 09:23:35 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 22 Nov 2022 09:23:35 GMT Subject: Integrated: 8252713: jtreg time out of CtrlASCII.java seems to hang the Xserver. In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 15:51:50 GMT, Alexander Zvegintsev wrote: > This test needs more stabilization: > > - The test can be easily hang by replacing
iteration on `keycharHash.elements()` with `keycharHash.forEach((k, v) -> punchCtrlKey(robot, v));` > I do not see any reason why we need a synchronized `Hashtable`, so switched to `HashMap` > Looks like it might be a reason of original test hanging. > - `keyRelease`, `dispose` calls wrapped with finally block > - Just to be safe added timeout `@run main/timeout=600` ( none of the CI test runs took too long thought) > > CI testing looks good on all platforms. This pull request has now been integrated. Changeset: 6d6046b3 Author: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/6d6046b3799217c281d077f12bce1ec590149849 Stats: 229 lines in 2 files changed: 56 ins; 55 del; 118 mod 8252713: jtreg time out of CtrlASCII.java seems to hang the Xserver. Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/11214 From smandalika at openjdk.org Tue Nov 22 10:16:23 2022 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Tue, 22 Nov 2022 10:16:23 GMT Subject: RFR: 8295707: Create a regression test for JDK-7184401 [v2] In-Reply-To: References: Message-ID: <4D8UrZaSv4ZvQ2HvBkqeeSxm222xPi9BObkV165EZMw=.510fc8e4-b646-40d0-ad9a-4882711253d8@github.com> On Mon, 7 Nov 2022 07:28:02 GMT, Srinivas Mandalika wrote: >> 8295707: Create a regression test for JDK-7184401 >> >> JDK-7184401 - JDk7u6 : Missing main menu bar in Netbeans after fix for 7162144 >> Above bug got introduced due to a fix for [JDK-7162144](https://bugs.openjdk.java.net/browse/JDK-7162144). >> The issue was observed on the netbeans UI. >> The test below recreates a standalone test to mimic the failure reported in Netbeans in [JDK-7184401](https://bugs.openjdk.java.net/browse/JDK-7184401) and verifies that it is working as expected after it got fixed via [JDK-7189350](https://bugs.openjdk.java.net/browse/JDK-7189350)) >> >> The Test attempts to reproduce specific behavior of NetBeans at the certain toolbar creation stage. Widgets are created on EDT; Another code posts some events to them on EDT; From another thread some code calls explicitly edt.interrupt(). >> Before this got fixed, events from a second code got lost. >> >> This review is for migrating tests from a closed test suite to open. >> Testing: >> 1.Tested the code on jdk7u6 to reproduce the issue - the UI hangs when run on this build. >> 2. Tested the code on jdk7u361 b01 to validate the fix - the test passed. >> 3.Mach5 Testing(40 times per platform) in macos x64, linux x64 and windows x64 - the .results are clean > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Fixed Review Comments: Removed redundant code Any volunteers for reviewing this PR ? ------------- PR: https://git.openjdk.org/jdk/pull/10784 From azvegint at openjdk.org Tue Nov 22 12:28:24 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 22 Nov 2022 12:28:24 GMT Subject: RFR: 8239801: [macos] java/awt/Focus/UnaccessibleChoice/AccessibleChoiceTest.java fails [v2] In-Reply-To: References: <1ucV0BHh8XBiFbdJncIVAPXAPXmgJEwDD8f9EWmssnQ=.48c4c221-c5a0-4211-9d15-6de0c7a7da87@github.com> Message-ID: On Mon, 21 Nov 2022 17:28:58 GMT, Damon Nguyen wrote: >> This is an older test that failed intermittently but had a fix specifically for mac systems by adding key presses on mac only. This test still intermittently failed after this fix long ago and was problem listed. >> >> I ran this test 100 times on each OS after applying waitForIdle and delays between all key presses to match the delays previously present in the test. >> >> I also added a debug line and save and image of the failing window upon failure to better debug if/when the test ever fails again. The debug line is to check if the previous fix for mac is relevant in the failure. The image shows the status of the window and what is focused at the time of failure. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Modify delays. Capture full screen instead. Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11227 From chen.j.patrick at gmail.com Tue Nov 22 13:55:01 2022 From: chen.j.patrick at gmail.com (Patrick Chen) Date: Tue, 22 Nov 2022 14:55:01 +0100 Subject: RFR: 8165943: LineBreakMeasurer does not measure correctly if TextAttribute.TRACKING is set. In-Reply-To: References: <2BW15v-Fz4IdXH_x_-2ZsG7ZENhltuqMmmKcR59mEHk=.1258a386-6858-4bfb-bba0-70ea6808e59b@github.com> Message-ID: I think it is good reviewed Le lun. 21 nov. 2022 ? 16:08, azul-jf a ?crit : > On Sun, 20 Nov 2022 03:39:56 GMT, Phil Race wrote: > > >> This is a fix for LineBreakMeasurer. It takes into account the > TextAttribute.TRACKING value (not eq 0) while calculating the line breaks. > >> > >> Tested on Linux x64, Windows x64, macOS x64 with the reproducer > (LineBreakSample.java) attached to JDK-8165943 and the following group of > tests: > >> `$JTREG_HOME/bin/jtreg -jdk:$BUILD_HOME ./test/jdk/java/awt/font` > > > > I haven't had time to look at this. Maybe I can look at it some time in > the 1st week of December. Ping me then. > > Hi @prrace, this came to our attention as a customer issue. The reproducer > we used was the one from JDK-8165943. > > As a reminder of the issue and an illustration of the desired outcome, > here are some screen captures. > > Existing code, TRACKING = 0.0: > > ![image]( > https://user-images.githubusercontent.com/68303684/203083698-a557b968-2e68-48b5-8313-09f7458b91c5.png > ) > > Existing code, TRACKING = 0.1: > > ![image]( > https://user-images.githubusercontent.com/68303684/203084245-f32ae45f-0d1b-4419-8d7d-274f23d14155.png > ) > > Submitted code, TRACKING = 0.1: > > ![image]( > https://user-images.githubusercontent.com/68303684/203084873-c31da8e2-7044-4737-a15d-2738f90e4929.png > ) > > ------------- > > PR: https://git.openjdk.org/jdk/pull/10289 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From psadhukhan at openjdk.org Tue Nov 22 14:23:57 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 22 Nov 2022 14:23:57 GMT Subject: RFR: 6257207: JTable.getDefaultEditor throws NullPointerException [v5] In-Reply-To: References: Message-ID: > If getDefaultEditor() is called before the JTable model is setup, it results in NPE. > > This is because when JTable sets its model, which ends up firing a table changed event. The testcase is listening for tableChanged events and querying the editor. But the editor isn't installed until after the model is set which results in NPE. > Fix is to ensure initializeLocalVars() which initializes default editor is setup before JTable sets its model. > > No regression is observed in jtreg/jck testsuite with this change. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Fix updated to initialize default editor,renderer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10871/files - new: https://git.openjdk.org/jdk/pull/10871/files/a2c499fb..c24d68b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10871&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10871&range=03-04 Stats: 15 lines in 1 file changed: 6 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/10871.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10871/head:pull/10871 PR: https://git.openjdk.org/jdk/pull/10871 From psadhukhan at openjdk.org Tue Nov 22 14:31:01 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 22 Nov 2022 14:31:01 GMT Subject: RFR: 6257207: JTable.getDefaultEditor throws NullPointerException [v6] In-Reply-To: References: Message-ID: > If getDefaultEditor() is called before the JTable model is setup, it results in NPE. > > This is because when JTable sets its model, which ends up firing a table changed event. The testcase is listening for tableChanged events and querying the editor. But the editor isn't installed until after the model is set which results in NPE. > Fix is to ensure initializeLocalVars() which initializes default editor is setup before JTable sets its model. > > No regression is observed in jtreg/jck testsuite with this change. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10871/files - new: https://git.openjdk.org/jdk/pull/10871/files/c24d68b7..0b917b24 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10871&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10871&range=04-05 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/10871.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10871/head:pull/10871 PR: https://git.openjdk.org/jdk/pull/10871 From psadhukhan at openjdk.org Tue Nov 22 14:31:04 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 22 Nov 2022 14:31:04 GMT Subject: RFR: 6257207: JTable.getDefaultEditor throws NullPointerException [v6] In-Reply-To: <3ks1bFoj90hTCR4HII-mS2zNhcD8JSuAWxdUaqRqglg=.8c6308db-b2b9-43f5-b5bc-3101c54740be@github.com> References: <3ks1bFoj90hTCR4HII-mS2zNhcD8JSuAWxdUaqRqglg=.8c6308db-b2b9-43f5-b5bc-3101c54740be@github.com> Message-ID: On Thu, 17 Nov 2022 18:10:38 GMT, Sergey Bylokhov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix > > src/java.desktop/share/classes/javax/swing/JTable.java line 706: > >> 704: setModel(dm); >> 705: >> 706: initializeLocalVars(); > > Did we check that the NPE now can be occurred in the initializeLocalVars since the model at that point is null? For example the initializeLocalVars->setTableHeader->firePropertyChange("tableHeader"....)->in the listener the model will be null, while it was non null before the fix. Fix is updated to initialize the required local vars which are not initialized before use. ------------- PR: https://git.openjdk.org/jdk/pull/10871 From abhiscxk at openjdk.org Tue Nov 22 16:06:24 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 22 Nov 2022 16:06:24 GMT Subject: RFR: 8078471: The BACKSPACE key doesn't work with the special options"-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel" Message-ID: The Backspace key doesn't lead to parent directory of current directory for JFileChooser in GTK LAF. Added the lazy input value in `GTKLookandFeel` and fix is working fine. Implemented a manual test to check BackSpace behavior for all installed LAF in Linux platform. The test mentioned in [JDK-8078471](https://bugs.openjdk.org/browse/JDK-8078471) `javax/swing/JFileChooser/4150029/bug4150029.html` also working fine with GTK option (-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel). ------------- Commit messages: - Whitespace error fix - Backspace changes to parent directory Changes: https://git.openjdk.org/jdk/pull/11291/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11291&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8078471 Stats: 146 lines in 2 files changed: 146 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11291.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11291/head:pull/11291 PR: https://git.openjdk.org/jdk/pull/11291 From abhiscxk at openjdk.org Tue Nov 22 16:06:25 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 22 Nov 2022 16:06:25 GMT Subject: RFR: 8078471: The BACKSPACE key doesn't work with the special options"-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel" In-Reply-To: References: Message-ID: On Tue, 22 Nov 2022 15:51:09 GMT, Abhishek Kumar wrote: > The Backspace key doesn't lead to parent directory of current directory for JFileChooser in GTK LAF. > Added the lazy input value in `GTKLookandFeel` and fix is working fine. > > Implemented a manual test to check BackSpace behavior for all installed LAF in Linux platform. > The test mentioned in [JDK-8078471](https://bugs.openjdk.org/browse/JDK-8078471) `javax/swing/JFileChooser/4150029/bug4150029.html` also working fine with GTK option (-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel). If JFileChooser current directory is set to root directory then pressing BackSpace key changes to user's home directory in GTK LAF which is incorrect. It should remain at root directory. Planning to raise a new bug for this. ------------- PR: https://git.openjdk.org/jdk/pull/11291 From serb at openjdk.org Tue Nov 22 18:11:35 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 22 Nov 2022 18:11:35 GMT Subject: Integrated: 8296957: One more cast in SAFE_SIZE_NEW_ARRAY2 In-Reply-To: References: Message-ID: <-A1nek6Ll_E5YRGznT2jXLJdQ7AGBmuJEGpKDNyUE48=.e64e039d-a1f0-4e95-824b-1c79bb96b105@github.com> On Mon, 21 Nov 2022 01:22:49 GMT, Sergey Bylokhov wrote: > Implementation of SAFE_SIZE_NEW_ARRAY2 in the `sizecalc.h` missed one cast to the size_t This pull request has now been integrated. Changeset: fb6c992f Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/fb6c992f325981c42c7f75109a6c9db7ca8715d8 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8296957: One more cast in SAFE_SIZE_NEW_ARRAY2 Reviewed-by: aivanov ------------- PR: https://git.openjdk.org/jdk/pull/11253 From honkar at openjdk.org Tue Nov 22 20:03:25 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 22 Nov 2022 20:03:25 GMT Subject: RFR: 8239801: [macos] java/awt/Focus/UnaccessibleChoice/AccessibleChoiceTest.java fails [v2] In-Reply-To: References: <1ucV0BHh8XBiFbdJncIVAPXAPXmgJEwDD8f9EWmssnQ=.48c4c221-c5a0-4211-9d15-6de0c7a7da87@github.com> Message-ID: On Mon, 21 Nov 2022 17:28:58 GMT, Damon Nguyen wrote: >> This is an older test that failed intermittently but had a fix specifically for mac systems by adding key presses on mac only. This test still intermittently failed after this fix long ago and was problem listed. >> >> I ran this test 100 times on each OS after applying waitForIdle and delays between all key presses to match the delays previously present in the test. >> >> I also added a debug line and save and image of the failing window upon failure to better debug if/when the test ever fails again. The debug line is to check if the previous fix for mac is relevant in the failure. The image shows the status of the window and what is focused at the time of failure. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Modify delays. Capture full screen instead. Marked as reviewed by honkar (Author). ------------- PR: https://git.openjdk.org/jdk/pull/11227 From dnguyen at openjdk.org Tue Nov 22 20:15:44 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 22 Nov 2022 20:15:44 GMT Subject: Integrated: 8239801: [macos] java/awt/Focus/UnaccessibleChoice/AccessibleChoiceTest.java fails In-Reply-To: <1ucV0BHh8XBiFbdJncIVAPXAPXmgJEwDD8f9EWmssnQ=.48c4c221-c5a0-4211-9d15-6de0c7a7da87@github.com> References: <1ucV0BHh8XBiFbdJncIVAPXAPXmgJEwDD8f9EWmssnQ=.48c4c221-c5a0-4211-9d15-6de0c7a7da87@github.com> Message-ID: <228okP6kHlw-3pj_sGlkkOkKmakhISRzkblIarLMsE0=.6d41b931-233d-4608-ac39-7b5462d3468e@github.com> On Fri, 18 Nov 2022 00:17:47 GMT, Damon Nguyen wrote: > This is an older test that failed intermittently but had a fix specifically for mac systems by adding key presses on mac only. This test still intermittently failed after this fix long ago and was problem listed. > > I ran this test 100 times on each OS after applying waitForIdle and delays between all key presses to match the delays previously present in the test. > > I also added a debug line and save and image of the failing window upon failure to better debug if/when the test ever fails again. The debug line is to check if the previous fix for mac is relevant in the failure. The image shows the status of the window and what is focused at the time of failure. This pull request has now been integrated. Changeset: b6dddf4c Author: Damon Nguyen Committer: Alisen Chung URL: https://git.openjdk.org/jdk/commit/b6dddf4ce6072416e17cadefbd8280f959fd93ca Stats: 29 lines in 2 files changed: 21 ins; 1 del; 7 mod 8239801: [macos] java/awt/Focus/UnaccessibleChoice/AccessibleChoiceTest.java fails Reviewed-by: honkar, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/11227 From jjg at openjdk.org Tue Nov 22 22:04:57 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 22 Nov 2022 22:04:57 GMT Subject: RFR: 8296546: Add @spec tags to API [v2] In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: > Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. > > To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Prefix RFC titles with `RFC NNNN:` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11073/files - new: https://git.openjdk.org/jdk/pull/11073/files/30ce235f..c29092d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11073&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11073&range=00-01 Stats: 325 lines in 165 files changed: 4 ins; 4 del; 317 mod Patch: https://git.openjdk.org/jdk/pull/11073.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11073/head:pull/11073 PR: https://git.openjdk.org/jdk/pull/11073 From honkar at openjdk.org Wed Nov 23 00:54:14 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 23 Nov 2022 00:54:14 GMT Subject: RFR: JDK-8297449: Update JInternalFrame Metal Border code Message-ID: Updated Metal Border code for JInternalFrame. - Added instanceof check before casting Graphics to G2D. - Replaced roundHalfDown with Region.clipRound() ------------- Commit messages: - removed unused import - JIF MetalBorder update Changes: https://git.openjdk.org/jdk/pull/11305/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11305&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297449 Stats: 112 lines in 1 file changed: 10 ins; 19 del; 83 mod Patch: https://git.openjdk.org/jdk/pull/11305.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11305/head:pull/11305 PR: https://git.openjdk.org/jdk/pull/11305 From serb at openjdk.org Wed Nov 23 02:00:24 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 23 Nov 2022 02:00:24 GMT Subject: RFR: 8191406: [hidpi] sun/java2d/SunGraphics2D/DrawImageBilinear.java test fails [v4] In-Reply-To: References: <3mHTs6Gpmb2JPxOfF9Ii7-eBRsvLnsqykBu7gkltH-M=.a2979bc5-b386-4c5f-b621-30f2a993090d@github.com> Message-ID: On Tue, 22 Nov 2022 05:33:21 GMT, Jayathirth D V wrote: >> This test was failing because of timing or color difference issues. >> Updated test to: >> >> 1) Use EDT for UI drawing instead of manual synchronisation >> 2) Use Robot.waitForIdle before screen capture >> 3) Increase color tolerance delta from 1 to 5 >> 4) Use undecorated frame and explicitly set background color and move the frame to top >> 5) Cleanup to remove not needed flags and java options >> >> After these changes test passes on all platforms in CI except Linux. For Linux it looks like product issue so i have raised : https://bugs.openjdk.org/browse/JDK-8297175 > > Jayathirth D V has updated the pull request incrementally with two additional commits since the last revision: > > - Exit on non creation of GUI > - Remove extra tolerance and background color Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11201 From serb at openjdk.org Wed Nov 23 02:00:23 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 23 Nov 2022 02:00:23 GMT Subject: RFR: JDK-8297230: Update Marlin2D to 0.9.4.6 [v4] In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 10:15:01 GMT, Laurent Bourg?s wrote: >> Initial PR > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > fixed class header comment Marked as reviewed by serb (Reviewer). test/jdk/sun/java2d/marlin/HugePolygonClipTest.java line 68: > 66: System.out.println("HugePolygonClipTest: size = " + SCENE_WIDTH + " x " + SCENE_HEIGHT); > 67: > 68: final BufferedImage image = new BufferedImage(SCENE_WIDTH, SCENE_HEIGHT, BufferedImage.TYPE_INT_ARGB); It looks fine. One additional question did we have any tests to validate how the "custom images" will work? For example the image similar to this [one](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/BufferedImage.java#L383) but using a different order of offsets, like: int[] bOffs = {1, 0, 2, 3}; For some other bug I have found that some our code does not expect "non-default" layouts. ------------- PR: https://git.openjdk.org/jdk/pull/11225 From serb at openjdk.org Wed Nov 23 02:11:31 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 23 Nov 2022 02:11:31 GMT Subject: RFR: 8295707: Create a regression test for JDK-7184401 [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 07:28:02 GMT, Srinivas Mandalika wrote: >> 8295707: Create a regression test for JDK-7184401 >> >> JDK-7184401 - JDk7u6 : Missing main menu bar in Netbeans after fix for 7162144 >> Above bug got introduced due to a fix for [JDK-7162144](https://bugs.openjdk.java.net/browse/JDK-7162144). >> The issue was observed on the netbeans UI. >> The test below recreates a standalone test to mimic the failure reported in Netbeans in [JDK-7184401](https://bugs.openjdk.java.net/browse/JDK-7184401) and verifies that it is working as expected after it got fixed via [JDK-7189350](https://bugs.openjdk.java.net/browse/JDK-7189350)) >> >> The Test attempts to reproduce specific behavior of NetBeans at the certain toolbar creation stage. Widgets are created on EDT; Another code posts some events to them on EDT; From another thread some code calls explicitly edt.interrupt(). >> Before this got fixed, events from a second code got lost. >> >> This review is for migrating tests from a closed test suite to open. >> Testing: >> 1.Tested the code on jdk7u6 to reproduce the issue - the UI hangs when run on this build. >> 2. Tested the code on jdk7u361 b01 to validate the fix - the test passed. >> 3.Mach5 Testing(40 times per platform) in macos x64, linux x64 and windows x64 - the .results are clean > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Fixed Review Comments: Removed redundant code test/jdk/java/awt/EventDispatchThread/InterruptEDTTest.java line 66: > 64: frame.setVisible(true); > 65: }); > 66: ((sun.awt.SunToolkit) (Toolkit.getDefaultToolkit())).realSync(); You can use the Robot.waitForIdle instead of realSync since jdk9. test/jdk/java/awt/EventDispatchThread/InterruptEDTTest.java line 80: > 78: }); > 79: } catch (Exception e) { > 80: e.printStackTrace(); Why do we skip an exception here and in another place below? ------------- PR: https://git.openjdk.org/jdk/pull/10784 From serb at openjdk.org Wed Nov 23 02:31:44 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 23 Nov 2022 02:31:44 GMT Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v4] In-Reply-To: References: <6HPa6vPeV5haQI_Ifs5IRH1xcjiqbld0T2Fk_WIABAY=.c0c2f8ff-988e-4017-8e61-a365870d5e6b@github.com> Message-ID: On Mon, 21 Nov 2022 10:44:43 GMT, Artem Semenov wrote: >> It is unclear why the `setSelectionInterval `is actually any better than `addAccessibleSelection`. Both have a similar implementation, in some cases, the addSelectionInterval just calls setSelectionInterval, and seems that posts similar notifications. So it is unclear why the setSelectionInterval works fine and addAccessibleSelection does not work. > > I tried calling clearSelection again instead of adding an interface: > > if (as == null) return; > if (pac.getAccessibleRole().equals(AccessibleRole.LIST)) { > as.clearAccessibleSelection(); > } > as.addAccessibleSelection(i); > > After that I changed the call to ```javax.swing.JList.AccessibleJList#addAccessibleSelection``` > > JList.this.addSelectionInterval(i, i); > > on the > > JList.this.getSelectionModel().setSelectionInterval(i, i); > > Nothing changed. VoiceOVer still freezes. > I think that the problem is not that setting the selection doesn't work, but that clearing the selection before setting causes the VO to fris. Some probably related points, the implementation of the addAccessibleSelection for the JComboBox. is the same: clearAccessibleSelection(); JComboBox.this.setSelectedIndex(i); It is possible that it also hangs? ------------- PR: https://git.openjdk.org/jdk/pull/8578 From serb at openjdk.org Wed Nov 23 02:31:44 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 23 Nov 2022 02:31:44 GMT Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v4] In-Reply-To: References: <6HPa6vPeV5haQI_Ifs5IRH1xcjiqbld0T2Fk_WIABAY=.c0c2f8ff-988e-4017-8e61-a365870d5e6b@github.com> Message-ID: On Wed, 23 Nov 2022 02:16:31 GMT, Sergey Bylokhov wrote: >> I tried calling clearSelection again instead of adding an interface: >> >> if (as == null) return; >> if (pac.getAccessibleRole().equals(AccessibleRole.LIST)) { >> as.clearAccessibleSelection(); >> } >> as.addAccessibleSelection(i); >> >> After that I changed the call to ```javax.swing.JList.AccessibleJList#addAccessibleSelection``` >> >> JList.this.addSelectionInterval(i, i); >> >> on the >> >> JList.this.getSelectionModel().setSelectionInterval(i, i); >> >> Nothing changed. VoiceOVer still freezes. >> I think that the problem is not that setting the selection doesn't work, but that clearing the selection before setting causes the VO to fris. > > Some probably related points, the implementation of the addAccessibleSelection for the JComboBox. is the same: > > clearAccessibleSelection(); > JComboBox.this.setSelectedIndex(i); > > > It is possible that it also hangs? >I think that the problem is not that setting the selection doesn't work, but that clearing the selection before setting causes the VO to fris. Are you sure that the selection should be always cleared in this method, how it will work if the jlist supports multiline selection? Or voice over does not support multyline selection? As a fix, you can delete listeners from the jlist so your request to clear the current selection will not be sent back to the voiceover. Or you can add a new method to the AccessibleSelection interface with the default implementation "clearAccessibleSelection+addAccessibleSelection". Then override it in the jlist to call setSelectedIndex(). ------------- PR: https://git.openjdk.org/jdk/pull/8578 From psadhukhan at openjdk.org Wed Nov 23 03:23:41 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 23 Nov 2022 03:23:41 GMT Subject: Integrated: 6201035: Document NPE for passing null insets to constructors and methods of several javax.swing.border.* classes In-Reply-To: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com> References: <5fBCyM1I9VREAg2ma5YHYtc_jkbTwIzDddzTdm2MPAU=.fb6b79d8-7cc0-47df-a869-b29fdfd4fa69@github.com> Message-ID: On Tue, 18 Oct 2022 06:36:49 GMT, Prasanta Sadhukhan wrote: > The behavior of MatteBorder constructors taking Insets object as a parameter is undocumented. It would throw NPE if null object is passed to it, which should be documented in the spec. This pull request has now been integrated. Changeset: 412b4365 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/412b43658a878bf004502a68948cb0c68375468e Stats: 27 lines in 10 files changed: 26 ins; 0 del; 1 mod 6201035: Document NPE for passing null insets to constructors and methods of several javax.swing.border.* classes Reviewed-by: tr, prr, aivanov, serb ------------- PR: https://git.openjdk.org/jdk/pull/10740 From jdv at openjdk.org Wed Nov 23 03:41:27 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 23 Nov 2022 03:41:27 GMT Subject: Integrated: 8191406: [hidpi] sun/java2d/SunGraphics2D/DrawImageBilinear.java test fails In-Reply-To: <3mHTs6Gpmb2JPxOfF9Ii7-eBRsvLnsqykBu7gkltH-M=.a2979bc5-b386-4c5f-b621-30f2a993090d@github.com> References: <3mHTs6Gpmb2JPxOfF9Ii7-eBRsvLnsqykBu7gkltH-M=.a2979bc5-b386-4c5f-b621-30f2a993090d@github.com> Message-ID: On Thu, 17 Nov 2022 08:20:54 GMT, Jayathirth D V wrote: > This test was failing because of timing or color difference issues. > Updated test to: > > 1) Use EDT for UI drawing instead of manual synchronisation > 2) Use Robot.waitForIdle before screen capture > 3) Increase color tolerance delta from 1 to 5 > 4) Use undecorated frame and explicitly set background color and move the frame to top > 5) Cleanup to remove not needed flags and java options > > After these changes test passes on all platforms in CI except Linux. For Linux it looks like product issue so i have raised : https://bugs.openjdk.org/browse/JDK-8297175 This pull request has now been integrated. Changeset: b4bd287f Author: Jayathirth D V URL: https://git.openjdk.org/jdk/commit/b4bd287f736b6b5dcfe1b183cae9b11eb6f22686 Stats: 107 lines in 2 files changed: 22 ins; 55 del; 30 mod 8191406: [hidpi] sun/java2d/SunGraphics2D/DrawImageBilinear.java test fails Reviewed-by: serb ------------- PR: https://git.openjdk.org/jdk/pull/11201 From smandalika at openjdk.org Wed Nov 23 06:59:33 2022 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Wed, 23 Nov 2022 06:59:33 GMT Subject: RFR: 8295707: Create a regression test for JDK-7184401 [v2] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 02:06:43 GMT, Sergey Bylokhov wrote: >> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed Review Comments: Removed redundant code > > test/jdk/java/awt/EventDispatchThread/InterruptEDTTest.java line 66: > >> 64: frame.setVisible(true); >> 65: }); >> 66: ((sun.awt.SunToolkit) (Toolkit.getDefaultToolkit())).realSync(); > > You can use the Robot.waitForIdle instead of realSync since jdk9. There was a comment in the original code before the realSync() call that was removed, which perhaps should have been left as is. // cannot substitute with robot.waitForIdle() presumably because of flushPendingEvents() there My understanding of above is that for simulating the test scenario - which is - Events (on line 75,76,77) are triggered and while these are potentially not yet complete(as they are wrapped in an invokeLater), the edt is interrupted. When run on jdk7u6 - the UI hangs and SOP of line 59 is not invoked. When run on jdk7u361 b01 the SOP on line 59 is printed and also the test passed. waitForIdle here will trigger the flushPendingEvents internally before the edt interrupt call -and that would eliminate any possibility of simulating the above scenario. > test/jdk/java/awt/EventDispatchThread/InterruptEDTTest.java line 80: > >> 78: }); >> 79: } catch (Exception e) { >> 80: e.printStackTrace(); > > Why do we skip an exception here and in another place below? As described in the comment above, the intent of the test is to validate the absence of a failure via a test hang and not via an exception. ------------- PR: https://git.openjdk.org/jdk/pull/10784 From jdv at openjdk.org Wed Nov 23 07:35:21 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 23 Nov 2022 07:35:21 GMT Subject: RFR: 6528710: sRGB-ColorSpace to sRGB-ColorSpace Conversion In-Reply-To: <4Ux7VA_NY-kTKDL-AO_vDkssR4Oge70xb7fpLrkLvAU=.1f024496-68b8-4205-9b18-825e8bdeceef@github.com> References: <4Ux7VA_NY-kTKDL-AO_vDkssR4Oge70xb7fpLrkLvAU=.1f024496-68b8-4205-9b18-825e8bdeceef@github.com> Message-ID: On Sun, 20 Nov 2022 09:10:48 GMT, Sergey Bylokhov wrote: > The quality of the cmm library is increased since the bug was reported. This is the request to import the test from the bug description to improve the code coverage. Looks good to me. Test is verified in CI and passes on all platforms. ------------- Marked as reviewed by jdv (Reviewer). PR: https://git.openjdk.org/jdk/pull/11250 From mbaesken at openjdk.org Wed Nov 23 08:26:37 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 23 Nov 2022 08:26:37 GMT Subject: RFR: JDK-8297480: GetPrimitiveArrayCritical in imageioJPEG misses result - NULL check Message-ID: Seems there is a remaining GetPrimitiveArrayCritical in imageioJPEG that misses a result - NULL check, this should be added. ------------- Commit messages: - JDK-8297480 Changes: https://git.openjdk.org/jdk/pull/11312/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11312&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297480 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11312.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11312/head:pull/11312 PR: https://git.openjdk.org/jdk/pull/11312 From jdv at openjdk.org Wed Nov 23 08:42:40 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 23 Nov 2022 08:42:40 GMT Subject: RFR: 8165943: LineBreakMeasurer does not measure correctly if TextAttribute.TRACKING is set. In-Reply-To: References: Message-ID: On Thu, 15 Sep 2022 16:51:27 GMT, Olga Mikhaltsova wrote: > This is a fix for LineBreakMeasurer. It takes into account the TextAttribute.TRACKING value (not eq 0) while calculating the line breaks. > > Tested on Linux x64, Windows x64, macOS x64 with the reproducer (LineBreakSample.java) attached to JDK-8165943 and the following group of tests: > `$JTREG_HOME/bin/jtreg -jdk:$BUILD_HOME ./test/jdk/java/awt/font` Change looks okay to me. Verified the fix locally and line break works properly with tracking now. Attached image with tracking 0.1 before and after fix. Before fix : ![BeforeFix](https://user-images.githubusercontent.com/38106814/203501840-496c9b2c-fd67-4a48-bd01-64c878b05c3f.png) After fix : ![AfterFix](https://user-images.githubusercontent.com/38106814/203501881-7ef6298a-667f-4fa1-8dab-b504ce2992c0.png) Also client test run in our CI with this fix is green. Let's wait for Phil's review also. Its better if we can add jtreg(regression) test along with fix. It can be a manual test, if we can't automate it. ------------- PR: https://git.openjdk.org/jdk/pull/10289 From duke at openjdk.org Wed Nov 23 08:52:22 2022 From: duke at openjdk.org (Patrick Chen) Date: Wed, 23 Nov 2022 08:52:22 GMT Subject: RFR: 8165943: LineBreakMeasurer does not measure correctly if TextAttribute.TRACKING is set. In-Reply-To: References: Message-ID: <_aXueuKXPQY5zpURafaHJnqhg-44l9qkyQQ5cjAVzc4=.154746fc-c3a9-456c-8a43-3cad82af9270@github.com> On Thu, 15 Sep 2022 16:51:27 GMT, Olga Mikhaltsova wrote: > This is a fix for LineBreakMeasurer. It takes into account the TextAttribute.TRACKING value (not eq 0) while calculating the line breaks. > > Tested on Linux x64, Windows x64, macOS x64 with the reproducer (LineBreakSample.java) attached to JDK-8165943 and the following group of tests: > `$JTREG_HOME/bin/jtreg -jdk:$BUILD_HOME ./test/jdk/java/awt/font` Marked as reviewed by kiraka42 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.org/jdk/pull/10289 From smandalika at openjdk.org Wed Nov 23 09:06:51 2022 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Wed, 23 Nov 2022 09:06:51 GMT Subject: RFR: 8297481: Create a regression test for JDK-4424517 Message-ID: 8297481: Create a regression test for JDK-4424517 ------------- Commit messages: - 8297481: Create a regression test for JDK-4424517 Changes: https://git.openjdk.org/jdk/pull/11313/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11313&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297481 Stats: 212 lines in 1 file changed: 212 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11313.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11313/head:pull/11313 PR: https://git.openjdk.org/jdk/pull/11313 From jdv at openjdk.org Wed Nov 23 09:31:22 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 23 Nov 2022 09:31:22 GMT Subject: RFR: JDK-8297480: GetPrimitiveArrayCritical in imageioJPEG misses result - NULL check In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 08:18:32 GMT, Matthias Baesken wrote: > Seems there is a remaining GetPrimitiveArrayCritical in imageioJPEG that misses a result - NULL check, this should be added. Did we actually hit null pointer issue in some specific condition using ImageIO or this bug got identified because of some static analysis? ------------- PR: https://git.openjdk.org/jdk/pull/11312 From smandalika at openjdk.org Wed Nov 23 09:40:24 2022 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Wed, 23 Nov 2022 09:40:24 GMT Subject: RFR: 8297481: Create a regression test for JDK-4424517 In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 08:57:23 GMT, Srinivas Mandalika wrote: > 8297481: Create a regression test for JDK-4424517 Create a regression test for JDK-4424517 Test is to verify the mapping of various KeyEvents with their KeyLocations Test triggers events or the various Keys and ensures the KeyLocation mapping to these are accurate. This review is for migrating tests from a closed test suite to open. Mach5 Test Results (60 repetitions across 3 platforms) https://mach5.us.oracle.com/mdash/jobs/jpg-closedjdk_mainline-20221123-0508-38875640 ------------- PR: https://git.openjdk.org/jdk/pull/11313 From duke at openjdk.org Wed Nov 23 11:07:19 2022 From: duke at openjdk.org (Patrick Chen) Date: Wed, 23 Nov 2022 11:07:19 GMT Subject: RFR: 8297481: Create a regression test for JDK-4424517 In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 08:57:23 GMT, Srinivas Mandalika wrote: > 8297481: Create a regression test for JDK-4424517 Marked as reviewed by kiraka42 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.org/jdk/pull/11313 From mbaesken at openjdk.org Wed Nov 23 11:20:34 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 23 Nov 2022 11:20:34 GMT Subject: RFR: JDK-8297480: GetPrimitiveArrayCritical in imageioJPEG misses result - NULL check In-Reply-To: References: Message-ID: <5HtSawu-siWzUNkmBIzoMQ-YWVD4Zg7W-Ly5syzHF2k=.e1fae864-cd81-4b14-ae9d-1f3d7301c0a7@github.com> On Wed, 23 Nov 2022 09:29:16 GMT, Jayathirth D V wrote: > Did we actually hit null pointer issue in some specific condition using ImageIO or this bug got identified because of some static analysis? I just grepped the codebase for GetPrimitiveArrayCritical usages and while doing so saw this. ------------- PR: https://git.openjdk.org/jdk/pull/11312 From jdv at openjdk.org Wed Nov 23 12:19:24 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 23 Nov 2022 12:19:24 GMT Subject: RFR: JDK-8297480: GetPrimitiveArrayCritical in imageioJPEG misses result - NULL check In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 08:18:32 GMT, Matthias Baesken wrote: > Seems there is a remaining GetPrimitiveArrayCritical in imageioJPEG that misses a result - NULL check, this should be added. Thanks for the fix. Change looks good to me. I am running ImageIO tests with fix and will approve soon. There should not be any issues. ------------- PR: https://git.openjdk.org/jdk/pull/11312 From dfuchs at openjdk.org Wed Nov 23 12:47:43 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 23 Nov 2022 12:47:43 GMT Subject: RFR: 8296546: Add @spec tags to API [v2] In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: <67cwjpPDhYIJW3yrDIi-6S1mSKwd-i9-e7Dm8X1MryM=.4cf1a49c-7798-42f6-90ab-524f4a623922@github.com> On Tue, 22 Nov 2022 22:04:57 GMT, Jonathan Gibbons wrote: >> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. >> >> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. >> >> "Normalized" means... >> * Use `https:` where possible (includes pretty much all cases) >> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) >> * Point to the root page of a multi-page spec >> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) >> >> In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. >> >> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. >> >> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. >> >> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. >> >> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ >> >> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Prefix RFC titles with `RFC NNNN:` Thanks for adding the RFC NNNN prefix to the RFC link. What is the purpose of editing non exported classes though, like those in the `sun.net` subpackages? ------------- PR: https://git.openjdk.org/jdk/pull/11073 From lbourges at openjdk.org Wed Nov 23 13:30:34 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Wed, 23 Nov 2022 13:30:34 GMT Subject: RFR: JDK-8297230: Update Marlin2D to 0.9.4.6 [v4] In-Reply-To: References: Message-ID: <8pRwivDeWKH3JAVEB1Dn1iyEOS8CpD9MDLuO90g9838=.ca64426e-1ae8-4a9c-898e-6d1badd5a534@github.com> On Wed, 23 Nov 2022 01:56:30 GMT, Sergey Bylokhov wrote: >> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed class header comment > > test/jdk/sun/java2d/marlin/HugePolygonClipTest.java line 68: > >> 66: System.out.println("HugePolygonClipTest: size = " + SCENE_WIDTH + " x " + SCENE_HEIGHT); >> 67: >> 68: final BufferedImage image = new BufferedImage(SCENE_WIDTH, SCENE_HEIGHT, BufferedImage.TYPE_INT_ARGB); > > It looks fine. One additional question did we have any tests to validate how the "custom images" will work? For example the image similar to this [one](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/BufferedImage.java#L383) but using a different order of offsets, like: int[] bOffs = {1, 0, 2, 3}; For some other bug I have found that some our code does not expect "non-default" layouts. Thanks. In this particular test I selected ARGB as a well-known format so it does not work with non-standard ARGB channels. I could have used getRed(), getGreen() values to use standard API to get each components. ------------- PR: https://git.openjdk.org/jdk/pull/11225 From lbourges at openjdk.org Wed Nov 23 13:32:16 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Wed, 23 Nov 2022 13:32:16 GMT Subject: Integrated: JDK-8297230: Update Marlin2D to 0.9.4.6 In-Reply-To: References: Message-ID: <8nuY8jjDamUazhc1ErWFgJDmCDjOXB8Jh7RECf1ujZQ=.b3a960fe-7c56-4d54-b572-df25ac58c53c@github.com> On Thu, 17 Nov 2022 22:51:00 GMT, Laurent Bourg?s wrote: > Initial PR This pull request has now been integrated. Changeset: 5b3d86f2 Author: Laurent Bourg?s URL: https://git.openjdk.org/jdk/commit/5b3d86f2296ec011f70cebe80a221b8a6f926912 Stats: 4286 lines in 38 files changed: 2812 ins; 1105 del; 369 mod 8297230: Update Marlin2D to 0.9.4.6 Reviewed-by: prr, serb ------------- PR: https://git.openjdk.org/jdk/pull/11225 From mbaesken at openjdk.org Wed Nov 23 14:21:23 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 23 Nov 2022 14:21:23 GMT Subject: RFR: JDK-8297480: GetPrimitiveArrayCritical in imageioJPEG misses result - NULL check In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 08:18:32 GMT, Matthias Baesken wrote: > Seems there is a remaining GetPrimitiveArrayCritical in imageioJPEG that misses a result - NULL check, this should be added. Hello , I did a few more grepping and source reading and while 98 or 99 percent of the GetPrimitiveArrayCritical return values are checked, there are a few more unchecked ones. See below src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m-136- jint nElements = (*env)->GetArrayLength(env, inTypes); src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m-137- NSMutableArray *formatArray = [NSMutableArray arrayWithCapacity:nElements]; src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m:138: jlong *elements = (*env)->GetPrimitiveArrayCritical(env, inTypes, NULL); src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m-139- src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m-140- for (i = 0; i < nElements; i++) { src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m-141- NSString *pbFormat = formatForIndex(elements[i]); src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m-142- if (pbFormat) src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m-143- [formatArray addObject:pbFormat]; src/java.desktop/macosx/native/libawt_lwawt/font/CCharToGlyphMapper.m-54-static inline void src/java.desktop/macosx/native/libawt_lwawt/font/CCharToGlyphMapper.m-55-GetGlyphsFromUnicodes(JNIEnv *env, AWTFont *awtFont, src/java.desktop/macosx/native/libawt_lwawt/font/CCharToGlyphMapper.m-56- jint count, UniChar *unicodes, src/java.desktop/macosx/native/libawt_lwawt/font/CCharToGlyphMapper.m-57- CGGlyph *cgGlyphs, jintArray glyphs) src/java.desktop/macosx/native/libawt_lwawt/font/CCharToGlyphMapper.m-58-{ src/java.desktop/macosx/native/libawt_lwawt/font/CCharToGlyphMapper.m:59: jint *glyphCodeInts = (*env)->GetPrimitiveArrayCritical(env, glyphs, 0); src/java.desktop/macosx/native/libawt_lwawt/font/CCharToGlyphMapper.m-60- src/java.desktop/macosx/native/libawt_lwawt/font/CCharToGlyphMapper.m-61- CTS_GetGlyphsAsIntsForCharacters(awtFont, unicodes, src/java.desktop/macosx/native/libawt_lwawt/font/CCharToGlyphMapper.m-62- cgGlyphs, glyphCodeInts, count); src/java.desktop/macosx/native/libosxui/JRSUIController.m:279: jdouble *rect = (*env)->GetPrimitiveArrayCritical(env, rectArray, NULL); src/java.desktop/macosx/native/libosxui/JRSUIController.m-280- rect[0] = partBounds.origin.x; src/java.desktop/macosx/native/libosxui/JRSUIController.m-281- rect[1] = partBounds.origin.y; src/java.desktop/unix/native/libawt_xawt/awt/swing_GTKEngine.c-333-Java_com_sun_java_swing_plaf_gtk_GTKEngine_nativeFinishPainting( src/java.desktop/unix/native/libawt_xawt/awt/swing_GTKEngine.c-334- JNIEnv *env, jobject this, jintArray dest, jint width, jint height) src/java.desktop/unix/native/libawt_xawt/awt/swing_GTKEngine.c-335-{ src/java.desktop/unix/native/libawt_xawt/awt/swing_GTKEngine.c-336- jint transparency; src/java.desktop/unix/native/libawt_xawt/awt/swing_GTKEngine.c:337: gint *buffer = (gint*) (*env)->GetPrimitiveArrayCritical(env, dest, 0); src/java.desktop/unix/native/libawt_xawt/awt/swing_GTKEngine.c-338- gtk->gdk_threads_enter(); src/java.desktop/unix/native/libawt_xawt/awt/swing_GTKEngine.c-339- transparency = gtk->copy_image(buffer, width, height); src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp-437- // Copy the resulting pixels to our Java BufferedImage. src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp:438: pDstBits = (int *)env->GetPrimitiveArrayCritical(array, 0); src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp-439- BOOL transparent = FALSE; src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp-440- transparent = IsThemeBackgroundPartiallyTransparentFunc(hTheme, part, state); src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp-441- copyDIBToBufferedImage(pDstBits, pSrcBits, transparent, w, h, stride); src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp-442- env->ReleasePrimitiveArrayCritical(array, pDstBits, 0); src/java.desktop/windows/native/libawt/windows/awt_DataTransferer.cpp-164- LOGPALETTE* pLogPalette = src/java.desktop/windows/native/libawt/windows/awt_DataTransferer.cpp:165: (LOGPALETTE*)env->GetPrimitiveArrayCritical(paletteBytes, NULL); src/java.desktop/windows/native/libawt/windows/awt_DataTransferer.cpp-166- PALETTEENTRY* pPalEntries = (PALETTEENTRY*)pLogPalette->palPalEntry; src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp:2863: colorsPtr = (jint *)env->GetPrimitiveArrayCritical(colors, 0); src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp-2864- for (int i = 0; i < (sizeof indexMap)/(sizeof *indexMap) && i < colorLen; i++) { src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp-2865- colorsPtr[i] = DesktopColor2RGB(indexMap[i]); src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp-2866- } Should I open another jbs issue for them ? ------------- PR: https://git.openjdk.org/jdk/pull/11312 From jdv at openjdk.org Wed Nov 23 14:35:20 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 23 Nov 2022 14:35:20 GMT Subject: RFR: 8297507: Update header after JDK-8297230 Message-ID: Update header to remove classpath exception ------------- Commit messages: - Update header Changes: https://git.openjdk.org/jdk/pull/11324/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11324&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297507 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11324.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11324/head:pull/11324 PR: https://git.openjdk.org/jdk/pull/11324 From mbaesken at openjdk.org Wed Nov 23 14:42:28 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 23 Nov 2022 14:42:28 GMT Subject: RFR: JDK-8297480: GetPrimitiveArrayCritical in imageioJPEG misses result - NULL check In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 08:18:32 GMT, Matthias Baesken wrote: > Seems there is a remaining GetPrimitiveArrayCritical in imageioJPEG that misses a result - NULL check, this should be added. Yes some Windows tests are failing; however it seems they miss getting the BOOT JDK or other components for example https://github.com/MBaesken/jdk/actions/runs/3530303514/jobs/5923400590 so this looks not related to me. ------------- PR: https://git.openjdk.org/jdk/pull/11312 From kcr at openjdk.org Wed Nov 23 14:43:14 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 23 Nov 2022 14:43:14 GMT Subject: RFR: 8297507: Update header after JDK-8297230 In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 14:26:34 GMT, Jayathirth D V wrote: > Update header to remove classpath exception src/java.desktop/share/classes/sun/java2d/marlin/DPQSSorterContext.java line 7: > 5: * This code is free software; you can redistribute it and/or modify it > 6: * under the terms of the GNU General Public License version 2 only, as > 7: * published by the Free Software Foundation. I don't understand this change. This file _needs_ the Classpath exception. ------------- PR: https://git.openjdk.org/jdk/pull/11324 From kcr at openjdk.org Wed Nov 23 14:43:14 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 23 Nov 2022 14:43:14 GMT Subject: RFR: 8297507: Update header after JDK-8297230 In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 14:37:06 GMT, Kevin Rushforth wrote: >> Update header to remove classpath exception > > src/java.desktop/share/classes/sun/java2d/marlin/DPQSSorterContext.java line 7: > >> 5: * This code is free software; you can redistribute it and/or modify it >> 6: * under the terms of the GNU General Public License version 2 only, as >> 7: * published by the Free Software Foundation. > > I don't understand this change. This file _needs_ the Classpath exception. The reason for the Tier1 build failure is a missing space (the official license template has two spaces after the `.` and before `Oracle designates') ------------- PR: https://git.openjdk.org/jdk/pull/11324 From jdv at openjdk.org Wed Nov 23 14:51:08 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 23 Nov 2022 14:51:08 GMT Subject: RFR: 8297507: Update header after JDK-8297230 [v2] In-Reply-To: References: Message-ID: <0CYYw2rF483dBb-8Lef81szuEQQkdzLhj3DjOMQwxJk=.ceae4759-4474-4e58-8565-1e5213bdeaa5@github.com> > Update header to add extra space Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: Update header to include extra space ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11324/files - new: https://git.openjdk.org/jdk/pull/11324/files/cd3bfae4..21a54040 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11324&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11324&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11324.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11324/head:pull/11324 PR: https://git.openjdk.org/jdk/pull/11324 From aivanov at openjdk.org Wed Nov 23 14:51:09 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 23 Nov 2022 14:51:09 GMT Subject: RFR: 8297507: Update header after JDK-8297230 [v2] In-Reply-To: <0CYYw2rF483dBb-8Lef81szuEQQkdzLhj3DjOMQwxJk=.ceae4759-4474-4e58-8565-1e5213bdeaa5@github.com> References: <0CYYw2rF483dBb-8Lef81szuEQQkdzLhj3DjOMQwxJk=.ceae4759-4474-4e58-8565-1e5213bdeaa5@github.com> Message-ID: On Wed, 23 Nov 2022 14:45:37 GMT, Jayathirth D V wrote: >> Update header to add extra space > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Update header to include extra space Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11324 From ihse at openjdk.org Wed Nov 23 14:51:09 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 23 Nov 2022 14:51:09 GMT Subject: RFR: 8297507: Update header after JDK-8297230 [v2] In-Reply-To: <0CYYw2rF483dBb-8Lef81szuEQQkdzLhj3DjOMQwxJk=.ceae4759-4474-4e58-8565-1e5213bdeaa5@github.com> References: <0CYYw2rF483dBb-8Lef81szuEQQkdzLhj3DjOMQwxJk=.ceae4759-4474-4e58-8565-1e5213bdeaa5@github.com> Message-ID: <70mP5_RMStmgbGRe4n2_5gr-Z6hMj9XHTwn_kmykH4c=.fb6def21-e754-49c4-8fb2-0863ab80263d@github.com> On Wed, 23 Nov 2022 14:45:37 GMT, Jayathirth D V wrote: >> Update header to add extra space > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Update header to include extra space Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11324 From kcr at openjdk.org Wed Nov 23 14:51:09 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 23 Nov 2022 14:51:09 GMT Subject: RFR: 8297507: Update header after JDK-8297230 [v2] In-Reply-To: <0CYYw2rF483dBb-8Lef81szuEQQkdzLhj3DjOMQwxJk=.ceae4759-4474-4e58-8565-1e5213bdeaa5@github.com> References: <0CYYw2rF483dBb-8Lef81szuEQQkdzLhj3DjOMQwxJk=.ceae4759-4474-4e58-8565-1e5213bdeaa5@github.com> Message-ID: On Wed, 23 Nov 2022 14:45:37 GMT, Jayathirth D V wrote: >> Update header to add extra space > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Update header to include extra space Presuming this passes Tier1, this looks good. ------------- Marked as reviewed by kcr (Author). PR: https://git.openjdk.org/jdk/pull/11324 From jdv at openjdk.org Wed Nov 23 14:51:12 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 23 Nov 2022 14:51:12 GMT Subject: RFR: 8297507: Update header after JDK-8297230 [v2] In-Reply-To: References: Message-ID: <6fdr9LquFdXCrqH-bGwhcLePs3XYjbbYBG4OKSmXmYk=.8c9287cb-ba9a-41a3-820d-08b642cf8c41@github.com> On Wed, 23 Nov 2022 14:39:50 GMT, Kevin Rushforth wrote: >> src/java.desktop/share/classes/sun/java2d/marlin/DPQSSorterContext.java line 7: >> >>> 5: * This code is free software; you can redistribute it and/or modify it >>> 6: * under the terms of the GNU General Public License version 2 only, as >>> 7: * published by the Free Software Foundation. >> >> I don't understand this change. This file _needs_ the Classpath exception. > > The reason for the Tier1 build failure is a missing space (the official license template has two spaces after the `.` and before `Oracle designates') Thanks Kevin. I have updated the PR. ------------- PR: https://git.openjdk.org/jdk/pull/11324 From aivanov at openjdk.org Wed Nov 23 14:51:12 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 23 Nov 2022 14:51:12 GMT Subject: RFR: 8297507: Update header after JDK-8297230 [v2] In-Reply-To: <6fdr9LquFdXCrqH-bGwhcLePs3XYjbbYBG4OKSmXmYk=.8c9287cb-ba9a-41a3-820d-08b642cf8c41@github.com> References: <6fdr9LquFdXCrqH-bGwhcLePs3XYjbbYBG4OKSmXmYk=.8c9287cb-ba9a-41a3-820d-08b642cf8c41@github.com> Message-ID: On Wed, 23 Nov 2022 14:45:17 GMT, Jayathirth D V wrote: >> The reason for the Tier1 build failure is a missing space (the official license template has two spaces after the `.` and before `Oracle designates') > > Thanks Kevin. I have updated the PR. This is not an easy thing to see. ------------- PR: https://git.openjdk.org/jdk/pull/11324 From kcr at openjdk.org Wed Nov 23 14:54:37 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 23 Nov 2022 14:54:37 GMT Subject: RFR: 8297507: Update header after JDK-8297230 [v2] In-Reply-To: <0CYYw2rF483dBb-8Lef81szuEQQkdzLhj3DjOMQwxJk=.ceae4759-4474-4e58-8565-1e5213bdeaa5@github.com> References: <0CYYw2rF483dBb-8Lef81szuEQQkdzLhj3DjOMQwxJk=.ceae4759-4474-4e58-8565-1e5213bdeaa5@github.com> Message-ID: On Wed, 23 Nov 2022 14:51:08 GMT, Jayathirth D V wrote: >> Update header to add extra space > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Update header to include extra space I think you have another missing space. I this this diff is also needed: * 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 + * 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). ------------- Changes requested by kcr (Author). PR: https://git.openjdk.org/jdk/pull/11324 From dfuchs at openjdk.org Wed Nov 23 15:01:05 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 23 Nov 2022 15:01:05 GMT Subject: RFR: 8297507: Update header after JDK-8297230 [v2] In-Reply-To: <0CYYw2rF483dBb-8Lef81szuEQQkdzLhj3DjOMQwxJk=.ceae4759-4474-4e58-8565-1e5213bdeaa5@github.com> References: <0CYYw2rF483dBb-8Lef81szuEQQkdzLhj3DjOMQwxJk=.ceae4759-4474-4e58-8565-1e5213bdeaa5@github.com> Message-ID: <9TRxiAFyF3BuinqCbCLNFXcZPDUiB8FrE8CN4PrksIA=.5523f50d-283c-4654-91fc-9d43ff31cabb@github.com> On Wed, 23 Nov 2022 14:51:08 GMT, Jayathirth D V wrote: >> Update header to add extra space > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Update header to include extra space Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11324 From aivanov at openjdk.org Wed Nov 23 15:01:05 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 23 Nov 2022 15:01:05 GMT Subject: RFR: 8297507: Update header after JDK-8297230 [v2] In-Reply-To: <0CYYw2rF483dBb-8Lef81szuEQQkdzLhj3DjOMQwxJk=.ceae4759-4474-4e58-8565-1e5213bdeaa5@github.com> References: <0CYYw2rF483dBb-8Lef81szuEQQkdzLhj3DjOMQwxJk=.ceae4759-4474-4e58-8565-1e5213bdeaa5@github.com> Message-ID: <_n8zH8iFKJGL6_lvSEu84eWyZr0QBygwg7mj5n070ec=.d1fd1587-52f9-44f2-8591-86f07f5bf5bd@github.com> On Wed, 23 Nov 2022 14:51:08 GMT, Jayathirth D V wrote: >> Update header to add extra space > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Update header to include extra space It makes sense to copy the license header from another file in the same directory to make sure nothing's missing. ------------- PR: https://git.openjdk.org/jdk/pull/11324 From jdv at openjdk.org Wed Nov 23 15:11:44 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 23 Nov 2022 15:11:44 GMT Subject: RFR: 8297507: Update header after JDK-8297230 [v3] In-Reply-To: References: Message-ID: > Update header to add extra space Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: Add additional space ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11324/files - new: https://git.openjdk.org/jdk/pull/11324/files/21a54040..d563a258 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11324&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11324&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11324.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11324/head:pull/11324 PR: https://git.openjdk.org/jdk/pull/11324 From kcr at openjdk.org Wed Nov 23 15:11:44 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 23 Nov 2022 15:11:44 GMT Subject: RFR: 8297507: Update header after JDK-8297230 [v3] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 15:08:13 GMT, Jayathirth D V wrote: >> Update header to add extra space > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Add additional space Updated fix looks good now. Marked as reviewed by kcr (Author). ------------- PR: https://git.openjdk.org/jdk/pull/11324 From dcubed at openjdk.org Wed Nov 23 15:11:44 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 23 Nov 2022 15:11:44 GMT Subject: RFR: 8297507: Update header after JDK-8297230 [v3] In-Reply-To: References: Message-ID: <2cqKsGyRHFxyKTuH6vPCl_MwtBslznw52r_R06nzBf0=.01cb42df-1429-4362-b889-bf2ec5fe9b3a@github.com> On Wed, 23 Nov 2022 15:08:13 GMT, Jayathirth D V wrote: >> Update header to add extra space > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Add additional space Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/11324 From aivanov at openjdk.org Wed Nov 23 15:11:44 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 23 Nov 2022 15:11:44 GMT Subject: RFR: 8297507: Update header after JDK-8297230 [v3] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 15:08:13 GMT, Jayathirth D V wrote: >> Update header to add extra space > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Add additional space Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11324 From dcubed at openjdk.org Wed Nov 23 15:11:47 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 23 Nov 2022 15:11:47 GMT Subject: RFR: 8297507: Update header after JDK-8297230 [v2] In-Reply-To: <0CYYw2rF483dBb-8Lef81szuEQQkdzLhj3DjOMQwxJk=.ceae4759-4474-4e58-8565-1e5213bdeaa5@github.com> References: <0CYYw2rF483dBb-8Lef81szuEQQkdzLhj3DjOMQwxJk=.ceae4759-4474-4e58-8565-1e5213bdeaa5@github.com> Message-ID: On Wed, 23 Nov 2022 14:51:08 GMT, Jayathirth D V wrote: >> Update header to add extra space > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Update header to include extra space Here's the diffs that work: $ git diff diff --git a/src/java.desktop/share/classes/sun/java2d/marlin/DPQSSorterContext.java b/src/java.desktop/share/classes/sun/java2d/marlin/DPQSSorterContext.java index e2e4fdd34bf..ee924f37805 100644 --- a/src/java.desktop/share/classes/sun/java2d/marlin/DPQSSorterContext.java +++ b/src/java.desktop/share/classes/sun/java2d/marlin/DPQSSorterContext.java @@ -4,13 +4,13 @@ * * 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. Oracle designates this + * published by the Free Software Foundation. Oracle designates this * particular file as subject to the "Classpath" exception as provided * by Oracle in the LICENSE file that accompanied this code. * * 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 + * 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). * Yes, crossed in the ether... ------------- PR: https://git.openjdk.org/jdk/pull/11324 From kcr at openjdk.org Wed Nov 23 15:11:48 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 23 Nov 2022 15:11:48 GMT Subject: RFR: 8297507: Update header after JDK-8297230 [v2] In-Reply-To: References: <0CYYw2rF483dBb-8Lef81szuEQQkdzLhj3DjOMQwxJk=.ceae4759-4474-4e58-8565-1e5213bdeaa5@github.com> Message-ID: On Wed, 23 Nov 2022 15:04:52 GMT, Daniel D. Daugherty wrote: > Here's the diffs that work: Yes, that's what Jay tested. ------------- PR: https://git.openjdk.org/jdk/pull/11324 From jdv at openjdk.org Wed Nov 23 15:11:49 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 23 Nov 2022 15:11:49 GMT Subject: RFR: 8297507: Update header after JDK-8297230 [v2] In-Reply-To: <0CYYw2rF483dBb-8Lef81szuEQQkdzLhj3DjOMQwxJk=.ceae4759-4474-4e58-8565-1e5213bdeaa5@github.com> References: <0CYYw2rF483dBb-8Lef81szuEQQkdzLhj3DjOMQwxJk=.ceae4759-4474-4e58-8565-1e5213bdeaa5@github.com> Message-ID: On Wed, 23 Nov 2022 14:51:08 GMT, Jayathirth D V wrote: >> Update header to add extra space > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Update header to include extra space With latest change i checked validate-headers locally and it passes. ------------- PR: https://git.openjdk.org/jdk/pull/11324 From kcr at openjdk.org Wed Nov 23 15:11:50 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 23 Nov 2022 15:11:50 GMT Subject: RFR: 8297507: Update header after JDK-8297230 [v2] In-Reply-To: <_n8zH8iFKJGL6_lvSEu84eWyZr0QBygwg7mj5n070ec=.d1fd1587-52f9-44f2-8591-86f07f5bf5bd@github.com> References: <0CYYw2rF483dBb-8Lef81szuEQQkdzLhj3DjOMQwxJk=.ceae4759-4474-4e58-8565-1e5213bdeaa5@github.com> <_n8zH8iFKJGL6_lvSEu84eWyZr0QBygwg7mj5n070ec=.d1fd1587-52f9-44f2-8591-86f07f5bf5bd@github.com> Message-ID: On Wed, 23 Nov 2022 14:56:58 GMT, Alexey Ivanov wrote: > It makes sense to copy the license header from another file in the same directory to make sure nothing's missing. Exactly. That's how I spotted the second problem -- by doing a diff with another file that wasn't touched by the PR in question. ------------- PR: https://git.openjdk.org/jdk/pull/11324 From jdv at openjdk.org Wed Nov 23 15:11:51 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 23 Nov 2022 15:11:51 GMT Subject: Integrated: 8297507: Update header after JDK-8297230 In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 14:26:34 GMT, Jayathirth D V wrote: > Update header to add extra space This pull request has now been integrated. Changeset: e6e57fe8 Author: Jayathirth D V URL: https://git.openjdk.org/jdk/commit/e6e57fe86da44d43a21d2d6e2753f7a7bb5352ff Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8297507: Update header after JDK-8297230 Reviewed-by: aivanov, ihse, kcr, dfuchs, dcubed ------------- PR: https://git.openjdk.org/jdk/pull/11324 From duke at openjdk.org Wed Nov 23 15:26:39 2022 From: duke at openjdk.org (ravi gupta) Date: Wed, 23 Nov 2022 15:26:39 GMT Subject: RFR: 8297489: Write a test to verify the content change of TextField sends TextEvent Message-ID: This testcase Verify the content changes of a TextField for the following assertions. a. TextListener get invoked when the content of a TextField gets changed. b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. Testing: Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. ------------- Commit messages: - 8297489: Write a test to verify the content change of TextField sends TextEvent Changes: https://git.openjdk.org/jdk/pull/11326/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11326&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297489 Stats: 140 lines in 1 file changed: 140 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11326.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11326/head:pull/11326 PR: https://git.openjdk.org/jdk/pull/11326 From duke at openjdk.org Wed Nov 23 15:29:35 2022 From: duke at openjdk.org (ravi gupta) Date: Wed, 23 Nov 2022 15:29:35 GMT Subject: RFR: 8297489: Write a test to verify the content change of TextField sends TextEvent [v2] In-Reply-To: References: Message-ID: <4gUpVv7yUeHyF_84F3HSb8J_qFfHKjvVKp-EV2hJgBc=.8bb07fb0-bfaa-4242-9e97-b06d6cb274bc@github.com> > This testcase Verify the content changes of a TextField for the following assertions. > > a. TextListener get invoked when the content of a TextField gets changed. > b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. > > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. ravi gupta has updated the pull request incrementally with one additional commit since the last revision: 8297489: bug added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11326/files - new: https://git.openjdk.org/jdk/pull/11326/files/dee8c8f9..dee88683 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11326&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11326&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11326.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11326/head:pull/11326 PR: https://git.openjdk.org/jdk/pull/11326 From jdv at openjdk.org Wed Nov 23 15:38:53 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 23 Nov 2022 15:38:53 GMT Subject: RFR: JDK-8297480: GetPrimitiveArrayCritical in imageioJPEG misses result - NULL check In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 08:18:32 GMT, Matthias Baesken wrote: > Seems there is a remaining GetPrimitiveArrayCritical in imageioJPEG that misses a result - NULL check, this should be added. Marked as reviewed by jdv (Reviewer). > Hello , I did a few more grepping and source reading and while 98 or 99 percent of the GetPrimitiveArrayCritical return values are checked, there are a few more unchecked ones. See below > > ` src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m-136- jint nElements = (*env)->GetArrayLength(env, inTypes); src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m-137- NSMutableArray *formatArray = [NSMutableArray arrayWithCapacity:nElements]; src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m:138: jlong *elements = (*env)->GetPrimitiveArrayCritical(env, inTypes, NULL); src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m-139- src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m-140- for (i = 0; i < nElements; i++) { src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m-141- NSString *pbFormat = formatForIndex(elements[i]); src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m-142- if (pbFormat) src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m-143- [formatArray addObject:pbFormat]; > > src/java.desktop/macosx/native/libawt_lwawt/font/CCharToGlyphMapper.m-54-static inline void src/java.desktop/macosx/native/libawt_lwawt/font/CCharToGlyphMapper.m-55-GetGlyphsFromUnicodes(JNIEnv *env, AWTFont *awtFont, src/java.desktop/macosx/native/libawt_lwawt/font/CCharToGlyphMapper.m-56- jint count, UniChar *unicodes, src/java.desktop/macosx/native/libawt_lwawt/font/CCharToGlyphMapper.m-57- CGGlyph *cgGlyphs, jintArray glyphs) src/java.desktop/macosx/native/libawt_lwawt/font/CCharToGlyphMapper.m-58-{ src/java.desktop/macosx/native/libawt_lwawt/font/CCharToGlyphMapper.m:59: jint *glyphCodeInts = (*env)->GetPrimitiveArrayCritical(env, glyphs, 0); src/java.desktop/macosx/native/libawt_lwawt/font/CCharToGlyphMapper.m-60- src/java.desktop/macosx/native/libawt_lwawt/font/CCharToGlyphMapper.m-61- CTS_GetGlyphsAsIntsForCharacters(awtFont, unicodes, src/java.desktop/macosx/native/libawt_lwawt/font/CCharToGlyphMapper.m-62- cgGlyphs, glyphCodeInts, count); > > src/java.desktop/macosx/native/libosxui/JRSUIController.m:279: jdouble *rect = (*env)->GetPrimitiveArrayCritical(env, rectArray, NULL); src/java.desktop/macosx/native/libosxui/JRSUIController.m-280- rect[0] = partBounds.origin.x; src/java.desktop/macosx/native/libosxui/JRSUIController.m-281- rect[1] = partBounds.origin.y; > > src/java.desktop/unix/native/libawt_xawt/awt/swing_GTKEngine.c-333-Java_com_sun_java_swing_plaf_gtk_GTKEngine_nativeFinishPainting( src/java.desktop/unix/native/libawt_xawt/awt/swing_GTKEngine.c-334- JNIEnv *env, jobject this, jintArray dest, jint width, jint height) src/java.desktop/unix/native/libawt_xawt/awt/swing_GTKEngine.c-335-{ src/java.desktop/unix/native/libawt_xawt/awt/swing_GTKEngine.c-336- jint transparency; src/java.desktop/unix/native/libawt_xawt/awt/swing_GTKEngine.c:337: gint _buffer = (gint_) (*env)->GetPrimitiveArrayCritical(env, dest, 0); src/java.desktop/unix/native/libawt_xawt/awt/swing_GTKEngine.c-338- gtk->gdk_threads_enter(); src/java.desktop/unix/native/libawt_xawt/awt/swing_GTKEngine.c-339- transparency = gtk->copy_image(buffer, width, height); > > src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp-437- // Copy the resulting pixels to our Java BufferedImage. src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp:438: pDstBits = (int *)env->GetPrimitiveArrayCritical(array, 0); src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp-439- BOOL transparent = FALSE; src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp-440- transparent = IsThemeBackgroundPartiallyTransparentFunc(hTheme, part, state); src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp-441- copyDIBToBufferedImage(pDstBits, pSrcBits, transparent, w, h, stride); src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp-442- env->ReleasePrimitiveArrayCritical(array, pDstBits, 0); > > src/java.desktop/windows/native/libawt/windows/awt_DataTransferer.cpp-164- LOGPALETTE* pLogPalette = src/java.desktop/windows/native/libawt/windows/awt_DataTransferer.cpp:165: (LOGPALETTE*)env->GetPrimitiveArrayCritical(paletteBytes, NULL); src/java.desktop/windows/native/libawt/windows/awt_DataTransferer.cpp-166- PALETTEENTRY* pPalEntries = (PALETTEENTRY*)pLogPalette->palPalEntry; > > src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp:2863: colorsPtr = (jint *)env->GetPrimitiveArrayCritical(colors, 0); src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp-2864- for (int i = 0; i < (sizeof indexMap)/(sizeof *indexMap) && i < colorLen; i++) { src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp-2865- colorsPtr[i] = DesktopColor2RGB(indexMap[i]); src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp-2866- } ` > > Should I open another jbs issue for them ? Sure please create new JBS issue for the same. ------------- PR: https://git.openjdk.org/jdk/pull/11312 From jjg at openjdk.org Wed Nov 23 16:47:22 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 23 Nov 2022 16:47:22 GMT Subject: RFR: 8296546: Add @spec tags to API [v2] In-Reply-To: <67cwjpPDhYIJW3yrDIi-6S1mSKwd-i9-e7Dm8X1MryM=.4cf1a49c-7798-42f6-90ab-524f4a623922@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> <67cwjpPDhYIJW3yrDIi-6S1mSKwd-i9-e7Dm8X1MryM=.4cf1a49c-7798-42f6-90ab-524f4a623922@github.com> Message-ID: <1chEBBDbhD7PiPdKybnhe3Bq2DyO-GTGaxTU5qtw7C4=.8191c086-d70c-4bc1-b03e-d781b1268f07@github.com> On Wed, 23 Nov 2022 12:43:16 GMT, Daniel Fuchs wrote: > Thanks for adding the RFC NNNN prefix to the RFC link. What is the purpose of editing non exported classes though, like those in the `sun.net` subpackages? That was not intentional, and is a result of the scripted edit. I will look to revert those changes and/or change the tooling to ignore those packages. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From duke at openjdk.org Wed Nov 23 17:34:14 2022 From: duke at openjdk.org (Naveen Narayanan) Date: Wed, 23 Nov 2022 17:34:14 GMT Subject: RFR: 8297095: Write a test to determine the quit request of the application Message-ID: This testcase will 1) Verify the handleQuitRequestWith() method of QuitHandler interface. 2) Check that the response is passed to the handler by means of quit notification generated by a key combination of META+Q (Mac) or ALT+F4(Windows & Linux). 3) Confirm that the active window is closed. Testing: Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. ------------- Commit messages: - 8297095: Write a test to determine the quit request of the application Changes: https://git.openjdk.org/jdk/pull/11328/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11328&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297095 Stats: 124 lines in 1 file changed: 124 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11328.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11328/head:pull/11328 PR: https://git.openjdk.org/jdk/pull/11328 From duke at openjdk.org Wed Nov 23 17:37:19 2022 From: duke at openjdk.org (ravi gupta) Date: Wed, 23 Nov 2022 17:37:19 GMT Subject: RFR: 8297489: Write a test to verify the content change of TextField sends TextEvent [v2] In-Reply-To: <4gUpVv7yUeHyF_84F3HSb8J_qFfHKjvVKp-EV2hJgBc=.8bb07fb0-bfaa-4242-9e97-b06d6cb274bc@github.com> References: <4gUpVv7yUeHyF_84F3HSb8J_qFfHKjvVKp-EV2hJgBc=.8bb07fb0-bfaa-4242-9e97-b06d6cb274bc@github.com> Message-ID: <7R-MKMx1KcRnG4q4IO1MV9RrRJrP6YFh-aiVcLIgI1Q=.813f7b37-400f-4e48-ac92-06ad965dfba7@github.com> On Wed, 23 Nov 2022 15:29:35 GMT, ravi gupta wrote: >> This testcase Verify the content changes of a TextField for the following assertions. >> >> a. TextListener get invoked when the content of a TextField gets changed. >> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8297489: bug added Any volunteers for a review? ------------- PR: https://git.openjdk.org/jdk/pull/11326 From honkar at openjdk.org Wed Nov 23 18:41:23 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 23 Nov 2022 18:41:23 GMT Subject: RFR: 8297095: Write a test to determine the quit request of the application In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 16:59:05 GMT, Naveen Narayanan wrote: > This testcase will > 1) Verify the handleQuitRequestWith() method of QuitHandler interface. > 2) Check that the response is passed to the handler by means of quit notification generated by a key combination of META+Q (Mac) or ALT+F4(Windows & Linux). > 3) Confirm that the active window is closed. > > Testing: > Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. Changes requested by honkar (Author). test/jdk/java/awt/Desktop/ActiveWindowCloseTest.java line 2: > 1: > 2: /* Copyright (c) 2016, 2022, Oracle and/or its affiliates. All rights reserved. If this is a newly created test, then the copyright should contain only the present year. test/jdk/java/awt/Desktop/ActiveWindowCloseTest.java line 23: > 21: * questions. > 22: */ > 23: import java.awt.AWTException; Minor nit: Please add a newline between copyright header and import statements. test/jdk/java/awt/Desktop/ActiveWindowCloseTest.java line 108: > 106: robot.keyRelease(KeyEvent.VK_ALT); > 107: } > 108: robot.waitForIdle(); Adding an additional delay (`robot.delay(200)`) will make sure that all the preceding events are processed. test/jdk/java/awt/Desktop/ActiveWindowCloseTest.java line 123: > 121: } > 122: } > 123: Minor nit: extra newline before closing brace can be removed. ------------- PR: https://git.openjdk.org/jdk/pull/11328 From honkar at openjdk.org Wed Nov 23 18:55:38 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 23 Nov 2022 18:55:38 GMT Subject: RFR: 8297489: Write a test to verify the content change of TextField sends TextEvent [v2] In-Reply-To: <4gUpVv7yUeHyF_84F3HSb8J_qFfHKjvVKp-EV2hJgBc=.8bb07fb0-bfaa-4242-9e97-b06d6cb274bc@github.com> References: <4gUpVv7yUeHyF_84F3HSb8J_qFfHKjvVKp-EV2hJgBc=.8bb07fb0-bfaa-4242-9e97-b06d6cb274bc@github.com> Message-ID: On Wed, 23 Nov 2022 15:29:35 GMT, ravi gupta wrote: >> This testcase Verify the content changes of a TextField for the following assertions. >> >> a. TextListener get invoked when the content of a TextField gets changed. >> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8297489: bug added Tested on Mac 12 and Win10 locally, test works as expected. CI testing looks good. Minor changes suggested. test/jdk/java/awt/event/ComponentEvent/TextFieldTextEventTest.java line 2: > 1: /* > 2: * Copyright (c) 2007, 2022, Oracle and/or its affiliates. All rights reserved. If this is a newly created test, then the copyright should contain only the present year. test/jdk/java/awt/event/ComponentEvent/TextFieldTextEventTest.java line 22: > 20: * or visit www.oracle.com if you need additional information or have any > 21: * questions. > 22: */ Minor nit: Please add a newline between copyright header and import statements. test/jdk/java/awt/event/ComponentEvent/TextFieldTextEventTest.java line 136: > 134: } > 135: > 136: private static void typeKey(int key) throws Exception { `throws Exception` clause can be removed. test/jdk/java/awt/event/ComponentEvent/TextFieldTextEventTest.java line 140: > 138: robot.keyRelease(key); > 139: } > 140: Minor nit: extra newline before closing brace can be removed. ------------- Changes requested by honkar (Author). PR: https://git.openjdk.org/jdk/pull/11326 From jjg at openjdk.org Wed Nov 23 18:57:03 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 23 Nov 2022 18:57:03 GMT Subject: RFR: 8296546: Add @spec tags to API [v3] In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: > Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. > > To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Remove updates from unexported files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11073/files - new: https://git.openjdk.org/jdk/pull/11073/files/c29092d8..3905ac83 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11073&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11073&range=01-02 Stats: 34 lines in 25 files changed: 0 ins; 34 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11073.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11073/head:pull/11073 PR: https://git.openjdk.org/jdk/pull/11073 From dfuchs at openjdk.org Wed Nov 23 19:23:53 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 23 Nov 2022 19:23:53 GMT Subject: RFR: 8296546: Add @spec tags to API [v3] In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons wrote: >> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. >> >> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. >> >> "Normalized" means... >> * Use `https:` where possible (includes pretty much all cases) >> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) >> * Point to the root page of a multi-page spec >> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) >> >> In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. >> >> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. >> >> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. >> >> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. >> >> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ >> >> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Remove updates from unexported files The java.base/net/, java.http/, java.naming/ changes look reasonable to me - though like Alan I wonder if it wouldn't be better to have an inline `{@spec }` tag - similar to `{@systemProperty }`, rather than repeating all the references outside of the context where they were cited. This probably also calls for a review of these references by maintainers of the various areas - as some of them might need some updating - e.g. linking to `rfceditor` as was previously suggested, and double checking whether all of them still make sense. Not something to be conducted within this PR though. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From dcubed at openjdk.org Wed Nov 23 20:44:30 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 23 Nov 2022 20:44:30 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: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com> References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com> Message-ID: On Fri, 11 Nov 2022 08:18:19 GMT, Tejesh R wrote: > Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system. This PR hasn't been touched in 8 days. I'm going to ProblemListing this test on windowx-x64 since we're up to 7 Tier3 failures in the jdk/jdk CI. ------------- PR: https://git.openjdk.org/jdk/pull/11104 From jjg at openjdk.org Wed Nov 23 22:09:23 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 23 Nov 2022 22:09:23 GMT Subject: RFR: 8296546: Add @spec tags to API [v3] In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Wed, 23 Nov 2022 19:20:53 GMT, Daniel Fuchs wrote: > The java.base/net/, java.http/, java.naming/ changes look reasonable to me - though like Alan I wonder if it wouldn't be better to have an inline `{@spec }` tag - similar to `{@systemProperty }`, rather than repeating all the references outside of the context where they were cited. This probably also calls for a review of these references by maintainers of the various areas - as some of them might need some updating - e.g. linking to `rfceditor` as was previously suggested, and double checking whether all of them still make sense. Not something to be conducted within this PR though. Believe me, I tried *very* hard to design and use an inline `{@spec}` tag but such a tag effectively needs a normative external file to indicate the root of a multi-page spec, and the definitive title, since inline tags either do not or are unlikely to contain such information. The general history of this work is: * version 1: bimodal tag with no external file -- the content of the summary page was effectively rubbish * version 2: bimodal tag with an external file -- in discussion with @jddarcy and CSR, we decided that was too much of a non-standard maintenance load * version 3: new tag, with no external file needed -- as you see here ------------- PR: https://git.openjdk.org/jdk/pull/11073 From aivanov at openjdk.org Wed Nov 23 22:32:43 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 23 Nov 2022 22:32:43 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: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com> References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com> Message-ID: On Fri, 11 Nov 2022 08:18:19 GMT, Tejesh R wrote: > Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system. Tejesh is testing the approach to get more details about the failure. I agree the issue is creating noise. If you problem-list the test (the two tests), he will be able to remove the test(s) from the problem list for his experiments. ------------- PR: https://git.openjdk.org/jdk/pull/11104 From aivanov at openjdk.org Wed Nov 23 22:44:11 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 23 Nov 2022 22:44:11 GMT Subject: RFR: JDK-8297449: Update JInternalFrame Metal Border code In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 00:46:57 GMT, Harshitha Onkar wrote: > Updated Metal Border code for JInternalFrame. > > - Added instanceof check before casting Graphics to G2D. > - Replaced roundHalfDown with Region.clipRound() Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 253: > 251: public void paintBorder(Component c, Graphics g, int x, int y, > 252: int w, int h) { > 253: if (g instanceof Graphics2D) { I think it's not the right approach. You should separate the parts of code into those which require `Graphics2D` (resetting transform, stroke width) and those which don't, so that the border is still painted even when `g` is not an instance of `Graphics2D`. Take a look at how @alisenchung handled it for `EtchedBorder`: https://github.com/openjdk/jdk/blob/b42c1ad1086a5c3f579e27380d23f67f8cebb437/src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java#L159-L171 The border is still rendered even if the passed in `Graphics` is not `Graphics2D`. ------------- PR: https://git.openjdk.org/jdk/pull/11305 From honkar at openjdk.org Wed Nov 23 22:49:21 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 23 Nov 2022 22:49:21 GMT Subject: RFR: JDK-8297449: Update JInternalFrame Metal Border code In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 22:40:34 GMT, Alexey Ivanov wrote: >> Updated Metal Border code for JInternalFrame. >> >> - Added instanceof check before casting Graphics to G2D. >> - Replaced roundHalfDown with Region.clipRound() > > src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 253: > >> 251: public void paintBorder(Component c, Graphics g, int x, int y, >> 252: int w, int h) { >> 253: if (g instanceof Graphics2D) { > > I think it's not the right approach. You should separate the parts of code into those which require `Graphics2D` (resetting transform, stroke width) and those which don't, so that the border is still painted even when `g` is not an instance of `Graphics2D`. > > Take a look at how @alisenchung handled it for `EtchedBorder`: > https://github.com/openjdk/jdk/blob/b42c1ad1086a5c3f579e27380d23f67f8cebb437/src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java#L159-L171 > > The border is still rendered even if the passed in `Graphics` is not `Graphics2D`. @aivanov-jdk Makes sense. Thanks for reviewing. Will check and make the necessary code changes. ------------- PR: https://git.openjdk.org/jdk/pull/11305 From joehw at openjdk.org Wed Nov 23 23:08:05 2022 From: joehw at openjdk.org (Joe Wang) Date: Wed, 23 Nov 2022 23:08:05 GMT Subject: RFR: 8296546: Add @spec tags to API [v3] In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons wrote: >> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. >> >> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. >> >> "Normalized" means... >> * Use `https:` where possible (includes pretty much all cases) >> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) >> * Point to the root page of a multi-page spec >> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) >> >> In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. >> >> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. >> >> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. >> >> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. >> >> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ >> >> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Remove updates from unexported files src/java.xml/share/classes/javax/xml/XMLConstants.java line 35: > 33: * @spec https://www.w3.org/TR/REC-xml-names Namespaces in XML 1.0 (Third Edition) > 34: * @spec https://www.w3.org/TR/xml-names11 Namespaces in XML 1.1 (Second Edition) > 35: * @spec https://www.w3.org/TR/xmlschema-1 XML Schema Part 1: Structures Second Edition Hi Jon, I would agree with what Alan said earlier that the @see ref can be dropped. This particular class (XMLConstants.java [1]) is a good example for that argument: in the resulting javadoc, 5 specs were listed in the "External Specifications" section, 6 in "See Also:", and then they were listed again for each field. That's a lot of duplicates. Adding to the confusion was that the @spec and @see were not always the same, e.g. @spec XML 1.0. points to the fifth edition while @see second. A minor comment is that the '@spec's were rendered in one line while the @see refs a list. I would see the later is easier to read. [1] http://cr.openjdk.java.net/~jjg/8296546/api.00/java.xml/javax/xml/XMLConstants.html ------------- PR: https://git.openjdk.org/jdk/pull/11073 From joehw at openjdk.org Wed Nov 23 23:43:57 2022 From: joehw at openjdk.org (Joe Wang) Date: Wed, 23 Nov 2022 23:43:57 GMT Subject: RFR: 8296546: Add @spec tags to API [v3] In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: <3O_lqMPzsBuGyrQ_snbw0Qv-XY-OaGUly6OBtoRz8hw=.041bf0b3-9dd4-4616-a003-617d28030139@github.com> On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons wrote: >> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. >> >> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. >> >> "Normalized" means... >> * Use `https:` where possible (includes pretty much all cases) >> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) >> * Point to the root page of a multi-page spec >> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) >> >> In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. >> >> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. >> >> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. >> >> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. >> >> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ >> >> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Remove updates from unexported files Specs for XSLT and XPath (many occurrences) need to point to specific version (e.g. 1.0) rather than the "cover page" (this is an issue in the original javadoc). src/java.xml/share/classes/javax/xml/transform/OutputKeys.java line 35: > 33: * > 34: * @spec https://www.w3.org/TR/xslt xslt cover page - W3C > 35: * @see The pages for XSLT and XPath at W3C are organized differently from the days when this javadoc was created. The "latest version" now points to the "cover page". Could you change the spec to the following? https://www.w3.org/TR/1999/REC-xslt-19991116 XSL Transformations (XSLT) Version 1.0 The @spec points to the general spec while @see also a specific section (similar situation as other classes in the package), if we want to keep @see ref here, it would be: https://www.w3.org/TR/1999/REC-xslt-19991116#output src/java.xml/share/classes/javax/xml/xpath/XPath.java line 104: > 102: * @author Norman Walsh > 103: * @author Jeff Suttor > 104: * @see XML Path Language (XPath) Version 1.0 Similar situation as XSLT above, the latest version now points to "cover page". For this javadoc then, it needs to be: https://www.w3.org/TR/1999/REC-xpath-19991116/ XML Path Language (XPath) Version 1.0 Unlike XSLT, the original @see ref also points to the spec generally (not a specific section), we could then drop it to keep just the @spec ref. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From dnguyen at openjdk.org Thu Nov 24 00:37:20 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 24 Nov 2022 00:37:20 GMT Subject: RFR: 6528710: sRGB-ColorSpace to sRGB-ColorSpace Conversion In-Reply-To: <4Ux7VA_NY-kTKDL-AO_vDkssR4Oge70xb7fpLrkLvAU=.1f024496-68b8-4205-9b18-825e8bdeceef@github.com> References: <4Ux7VA_NY-kTKDL-AO_vDkssR4Oge70xb7fpLrkLvAU=.1f024496-68b8-4205-9b18-825e8bdeceef@github.com> Message-ID: On Sun, 20 Nov 2022 09:10:48 GMT, Sergey Bylokhov wrote: > The quality of the cmm library is increased since the bug was reported. This is the request to import the test from the bug description to improve the code coverage. Added test locally and tested on all platforms. Looks good ------------- Marked as reviewed by dnguyen (Author). PR: https://git.openjdk.org/jdk/pull/11250 From dnguyen at openjdk.org Thu Nov 24 01:09:17 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 24 Nov 2022 01:09:17 GMT Subject: RFR: 8297095: Write a test to determine the quit request of the application In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 16:59:05 GMT, Naveen Narayanan wrote: > This testcase will > 1) Verify the handleQuitRequestWith() method of QuitHandler interface. > 2) Check that the response is passed to the handler by means of quit notification generated by a key combination of META+Q (Mac) or ALT+F4(Windows & Linux). > 3) Confirm that the active window is closed. > > Testing: > Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. test/jdk/java/awt/Desktop/ActiveWindowCloseTest.java line 93: > 91: robot.setAutoDelay(50); > 92: robot.setAutoWaitForIdle(true); > 93: robot.waitForIdle(); On top of waitForIdle, a delay of 1000 is usually added for stability after a frame is visible before events are called. ------------- PR: https://git.openjdk.org/jdk/pull/11328 From serb at openjdk.org Thu Nov 24 03:57:36 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 24 Nov 2022 03:57:36 GMT Subject: Integrated: 6528710: sRGB-ColorSpace to sRGB-ColorSpace Conversion In-Reply-To: <4Ux7VA_NY-kTKDL-AO_vDkssR4Oge70xb7fpLrkLvAU=.1f024496-68b8-4205-9b18-825e8bdeceef@github.com> References: <4Ux7VA_NY-kTKDL-AO_vDkssR4Oge70xb7fpLrkLvAU=.1f024496-68b8-4205-9b18-825e8bdeceef@github.com> Message-ID: On Sun, 20 Nov 2022 09:10:48 GMT, Sergey Bylokhov wrote: > The quality of the cmm library is increased since the bug was reported. This is the request to import the test from the bug description to improve the code coverage. This pull request has now been integrated. Changeset: abeddab9 Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/abeddab991d71f4ea54665082ffcb284267d7f44 Stats: 51 lines in 1 file changed: 51 ins; 0 del; 0 mod 6528710: sRGB-ColorSpace to sRGB-ColorSpace Conversion Reviewed-by: jdv, dnguyen ------------- PR: https://git.openjdk.org/jdk/pull/11250 From tr at openjdk.org Thu Nov 24 05:01:20 2022 From: tr at openjdk.org (Tejesh R) Date: Thu, 24 Nov 2022 05:01:20 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: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com> Message-ID: On Wed, 23 Nov 2022 20:40:33 GMT, Daniel D. Daugherty wrote: > This PR hasn't been touched in 8 days. I'm going to ProblemListing this test on windowx-x64 since we're up to 7 Tier3 failures in the jdk/jdk CI. Working on getting more info about the failure since the issue is intermittent. I am testing the diagnostic fix such that it won't affect the other test. ------------- PR: https://git.openjdk.org/jdk/pull/11104 From abhiscxk at openjdk.org Thu Nov 24 06:04:22 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 24 Nov 2022 06:04:22 GMT Subject: RFR: 8078471: The BACKSPACE key doesn't work with the special options"-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel" In-Reply-To: References: Message-ID: <1f8kkPgjHkkxs3HzrYHdJlqcRYubk2PmBVgbmTqwSoY=.4df7ef8e-6685-48e4-9e6e-ffed47f6f5a1@github.com> On Tue, 22 Nov 2022 15:53:20 GMT, Abhishek Kumar wrote: > If JFileChooser current directory is set to root directory then pressing BackSpace key changes to user's home directory in GTK LAF which is incorrect. It should remain at root directory. Planning to raise a new bug for this. @prsadhuk @jayathirthrao As discussed in the meeting, will not raise a new bug and update this PR accordingly. ------------- PR: https://git.openjdk.org/jdk/pull/11291 From duke at openjdk.org Thu Nov 24 06:10:20 2022 From: duke at openjdk.org (ravi gupta) Date: Thu, 24 Nov 2022 06:10:20 GMT Subject: RFR: 8297489: Write a test to verify the content change of TextField sends TextEvent [v3] In-Reply-To: References: Message-ID: > This testcase Verify the content changes of a TextField for the following assertions. > > a. TextListener get invoked when the content of a TextField gets changed. > b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. > > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. ravi gupta has updated the pull request incrementally with one additional commit since the last revision: 8297489: Review fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11326/files - new: https://git.openjdk.org/jdk/pull/11326/files/dee88683..a0fc7073 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11326&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11326&range=01-02 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11326.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11326/head:pull/11326 PR: https://git.openjdk.org/jdk/pull/11326 From duke at openjdk.org Thu Nov 24 06:10:20 2022 From: duke at openjdk.org (ravi gupta) Date: Thu, 24 Nov 2022 06:10:20 GMT Subject: RFR: 8297489: Write a test to verify the content change of TextField sends TextEvent [v2] In-Reply-To: References: <4gUpVv7yUeHyF_84F3HSb8J_qFfHKjvVKp-EV2hJgBc=.8bb07fb0-bfaa-4242-9e97-b06d6cb274bc@github.com> Message-ID: On Wed, 23 Nov 2022 18:46:22 GMT, Harshitha Onkar wrote: >> ravi gupta has updated the pull request incrementally with one additional commit since the last revision: >> >> 8297489: bug added > > test/jdk/java/awt/event/ComponentEvent/TextFieldTextEventTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2007, 2022, Oracle and/or its affiliates. All rights reserved. > > If this is a newly created test, then the copyright should contain only the present year. I have added the original date based on the above comment that?s we get during the PR review below https://github.com/openjdk/jdk/pull/7512#issuecomment-1075171066 ------------- PR: https://git.openjdk.org/jdk/pull/11326 From mbaesken at openjdk.org Thu Nov 24 08:06:26 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 24 Nov 2022 08:06:26 GMT Subject: RFR: JDK-8297480: GetPrimitiveArrayCritical in imageioJPEG misses result - NULL check In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 08:18:32 GMT, Matthias Baesken wrote: > Seems there is a remaining GetPrimitiveArrayCritical in imageioJPEG that misses a result - NULL check, this should be added. Thanks for the review ! ------------- PR: https://git.openjdk.org/jdk/pull/11312 From mbaesken at openjdk.org Thu Nov 24 08:06:26 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 24 Nov 2022 08:06:26 GMT Subject: Integrated: JDK-8297480: GetPrimitiveArrayCritical in imageioJPEG misses result - NULL check In-Reply-To: References: Message-ID: <5Dqa1WWQ_wWgfqb3vzeSRt7i5jJ3hgZ80ji6cNoO1_o=.9d4230f7-896a-4ddb-b56a-aa5bb8557a21@github.com> On Wed, 23 Nov 2022 08:18:32 GMT, Matthias Baesken wrote: > Seems there is a remaining GetPrimitiveArrayCritical in imageioJPEG that misses a result - NULL check, this should be added. This pull request has now been integrated. Changeset: 2f8a5c2e Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/2f8a5c2eca0dc3dad08b7b2c33394ac214907008 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8297480: GetPrimitiveArrayCritical in imageioJPEG misses result - NULL check Reviewed-by: jdv ------------- PR: https://git.openjdk.org/jdk/pull/11312 From abhiscxk at openjdk.org Thu Nov 24 08:57:45 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 24 Nov 2022 08:57:45 GMT Subject: RFR: 8078471: The BACKSPACE key doesn't work with the special options"-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel" [v2] In-Reply-To: References: Message-ID: > The Backspace key doesn't lead to parent directory of current directory for JFileChooser in GTK LAF. > Added the lazy input value in `GTKLookandFeel` and fix is working fine. > > Implemented a manual test to check BackSpace behavior for all installed LAF in Linux platform. > The test mentioned in [JDK-8078471](https://bugs.openjdk.org/browse/JDK-8078471) `javax/swing/JFileChooser/4150029/bug4150029.html` also working fine with GTK option (-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel). Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Backspace at root level handled ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11291/files - new: https://git.openjdk.org/jdk/pull/11291/files/634c507d..1fcdc76c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11291&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11291&range=00-01 Stats: 10 lines in 2 files changed: 5 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/11291.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11291/head:pull/11291 PR: https://git.openjdk.org/jdk/pull/11291 From duke at openjdk.org Thu Nov 24 09:02:34 2022 From: duke at openjdk.org (Patrick Chen) Date: Thu, 24 Nov 2022 09:02:34 GMT Subject: RFR: 6972078: Can not select single directory with GTKLookAndFeel [v6] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 07:06:27 GMT, Abhishek Kumar wrote: >> While using a JFileChooser with the file selection mode FILES_AND_DIRECTORIES and multiSelection enabled, it is impossible to select a single directory in GTK LAF. >> >> The condition check has been modified when multiselection is enabled and user has selected single directory. >> After the fix the behavior of JFileChooser is similar to other LAFs. >> >> An automatic test case `test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java` is implemented and checked in CI pipeline. Link is attached in JBS. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Review comment fix lgtm ------------- PR: https://git.openjdk.org/jdk/pull/10866 From abhiscxk at openjdk.org Thu Nov 24 09:02:48 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 24 Nov 2022 09:02:48 GMT Subject: RFR: 8078471: The BACKSPACE key doesn't work with the special options"-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel" [v2] In-Reply-To: References: Message-ID: <_5cMtdEWn6f9XydV8OMLbfeEeXytczHGQwNSkGipCsw=.cb4c5dd3-2ade-438f-9346-63ace692f1c9@github.com> On Thu, 24 Nov 2022 08:57:45 GMT, Abhishek Kumar wrote: >> The Backspace key doesn't lead to parent directory of current directory for JFileChooser in GTK LAF. >> Added the lazy input value in `GTKLookandFeel` and fix is working fine. >> >> Implemented a manual test to check BackSpace behavior for all installed LAF in Linux platform. >> The test mentioned in [JDK-8078471](https://bugs.openjdk.org/browse/JDK-8078471) `javax/swing/JFileChooser/4150029/bug4150029.html` also working fine with GTK option (-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel). > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Backspace at root level handled Updated to handle backspace key at root directory. ------------- PR: https://git.openjdk.org/jdk/pull/11291 From duke at openjdk.org Thu Nov 24 09:20:38 2022 From: duke at openjdk.org (Patrick Chen) Date: Thu, 24 Nov 2022 09:20:38 GMT Subject: RFR: JDK-8297480: GetPrimitiveArrayCritical in imageioJPEG misses result - NULL check In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 08:18:32 GMT, Matthias Baesken wrote: > Seems there is a remaining GetPrimitiveArrayCritical in imageioJPEG that misses a result - NULL check, this should be added. some tests are failing ------------- PR: https://git.openjdk.org/jdk/pull/11312 From duke at openjdk.org Thu Nov 24 10:43:19 2022 From: duke at openjdk.org (Naveen Narayanan) Date: Thu, 24 Nov 2022 10:43:19 GMT Subject: RFR: 8297095: Write a test to determine the quit request of the application In-Reply-To: References: Message-ID: <_GhdsiR6KyNJ3NU2PzgK9Dovl137G0goDwkeab5sgBk=.9e74b916-56f4-4f25-8114-12a5b186cbf9@github.com> On Wed, 23 Nov 2022 18:29:50 GMT, Harshitha Onkar wrote: >> This testcase will >> 1) Verify the handleQuitRequestWith() method of QuitHandler interface. >> 2) Check that the response is passed to the handler by means of quit notification generated by a key combination of META+Q (Mac) or ALT+F4(Windows & Linux). >> 3) Confirm that the active window is closed. >> >> Testing: >> Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. > > test/jdk/java/awt/Desktop/ActiveWindowCloseTest.java line 2: > >> 1: >> 2: /* Copyright (c) 2016, 2022, Oracle and/or its affiliates. All rights reserved. > > If this is a newly created test, then the copyright should contain only the present year. I have added the original date based on the above comment that?s we get during the PR review below https://github.com/openjdk/jdk/pull/7512#issuecomment-1075171066 ------------- PR: https://git.openjdk.org/jdk/pull/11328 From alanb at openjdk.org Thu Nov 24 10:56:23 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 24 Nov 2022 10:56:23 GMT Subject: RFR: 8296546: Add @spec tags to API [v3] In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons wrote: >> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. >> >> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. >> >> "Normalized" means... >> * Use `https:` where possible (includes pretty much all cases) >> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) >> * Point to the root page of a multi-page spec >> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) >> >> In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. >> >> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. >> >> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. >> >> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. >> >> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ >> >> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Remove updates from unexported files src/java.se/share/classes/module-info.java line 39: > 37: * > 38: * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol > 39: * @spec jni/index.html Java Native Interface Specification One thing that that bothers me a bit here is that the JNI and JDWP specs will be listed as "External Specifications" in the generated javadoc. This heading is appropriate for RFCs and other standards that we reference but seems misleading for specifications that are part of Java SE. Has this come up already? ------------- PR: https://git.openjdk.org/jdk/pull/11073 From abhiscxk at openjdk.org Thu Nov 24 12:06:26 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 24 Nov 2022 12:06:26 GMT Subject: RFR: 8078471: The BACKSPACE key doesn't work with the special options"-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel" [v2] In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 08:57:45 GMT, Abhishek Kumar wrote: >> The Backspace key doesn't lead to parent directory of current directory for JFileChooser in GTK LAF. >> Added the lazy input value in `GTKLookandFeel` and fix is working fine. >> >> Implemented a manual test to check BackSpace behavior for all installed LAF in Linux platform. >> The test mentioned in [JDK-8078471](https://bugs.openjdk.org/browse/JDK-8078471) `javax/swing/JFileChooser/4150029/bug4150029.html` also working fine with GTK option (-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel). > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Backspace at root level handled Run the CI clienlibs job with or without fix. There were few failures observed. 2 of them are common in both and 1 failure is observed in particular machine. Link is added in JBS. ------------- PR: https://git.openjdk.org/jdk/pull/11291 From psadhukhan at openjdk.org Thu Nov 24 13:03:16 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 24 Nov 2022 13:03:16 GMT Subject: RFR: 8078471: The BACKSPACE key doesn't work with the special options"-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel" [v2] In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 08:57:45 GMT, Abhishek Kumar wrote: >> The Backspace key doesn't lead to parent directory of current directory for JFileChooser in GTK LAF. >> Added the lazy input value in `GTKLookandFeel` and fix is working fine. >> >> Implemented a manual test to check BackSpace behavior for all installed LAF in Linux platform. >> The test mentioned in [JDK-8078471](https://bugs.openjdk.org/browse/JDK-8078471) `javax/swing/JFileChooser/4150029/bug4150029.html` also working fine with GTK option (-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel). > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Backspace at root level handled I wonder how it works in Nimbus as this mapping is not there in Synth/NimbusLookAndFeel and still it works and both GTK/Nimbus extends Synth. Can you please check? > If JFileChooser current directory is set to root directory then pressing BackSpace key changes to user's home directory in GTK LAF which is incorrect. It should remain at root directory. You have a similar fix for GTK https://github.com/openjdk/jdk/commit/9d0009e92b790b43153e3db353db775e6ff731cb Can it be reused in this case also? Also, is it not possible to create automated test, like calling JFileChooser.getCurrentDirectory() and fail if it's not the parent directory (or if it still remains in present directory) after BACKSPACE is pressed? ------------- PR: https://git.openjdk.org/jdk/pull/11291 From abhiscxk at openjdk.org Thu Nov 24 13:21:15 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 24 Nov 2022 13:21:15 GMT Subject: RFR: 8078471: The BACKSPACE key doesn't work with the special options"-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel" [v2] In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 13:00:52 GMT, Prasanta Sadhukhan wrote: > I wonder how it works in Nimbus as this mapping is not there in Synth/NimbusLookAndFeel and still it works and both GTK/Nimbus extends Synth. Can you please check? There is a mapping for squarebutton in skin.laf ``. Setting it true is having similar effect in Nimbus LAF also. So, I think in Nimbus LAF the squarebutton property is set through skin.laf file. > You have a similar fix for GTK https://github.com/openjdk/jdk/commit/9d0009e92b790b43153e3db353db775e6ff731cb Can it be reused in this case also? Don't think it can be reused in this case as the event is triggered from either double click or keyboard (Enter) on "../" directory present in JList. I will verify this once. > Also, is it not possible to create automated test, like calling JFileChooser.getCurrentDirectory() and fail if it's not the parent directory (or if it still remains in present directory) after BACKSPACE is pressed? I tried implementing an automated test case but in GTK LAF the cursor is focused on textfield and the backspace event is not triggered to change directory. ------------- PR: https://git.openjdk.org/jdk/pull/11291 From psadhukhan at openjdk.org Thu Nov 24 13:34:34 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 24 Nov 2022 13:34:34 GMT Subject: RFR: 8078471: The BACKSPACE key doesn't work with the special options"-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel" [v2] In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 08:57:45 GMT, Abhishek Kumar wrote: >> The Backspace key doesn't lead to parent directory of current directory for JFileChooser in GTK LAF. >> Added the lazy input value in `GTKLookandFeel` and fix is working fine. >> >> Implemented a manual test to check BackSpace behavior for all installed LAF in Linux platform. >> The test mentioned in [JDK-8078471](https://bugs.openjdk.org/browse/JDK-8078471) `javax/swing/JFileChooser/4150029/bug4150029.html` also working fine with GTK option (-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel). > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Backspace at root level handled `>` There is a mapping for squarebutton in skin.laf ``. > Setting it true is having similar effect in Nimbus LAF also. So, I think in Nimbus LAF the squarebutton property is set through skin.laf file. This mapping ""BACK_SPACE", "Go Up"," I guess has nothing to do with squarebutton property..Probably you are confusing it with your other fix? > I tried implementing an automated test case but in GTK LAF the cursor is focused on textfield and the backspace event is not triggered to change directory. You probably can do `requestFocusInWindow `to proper component...you can try to find the who has the focus by `getFocusOwner`() when you try to do manually BACKSPACE and try to set to that in automated test... ------------- PR: https://git.openjdk.org/jdk/pull/11291 From abhiscxk at openjdk.org Thu Nov 24 15:17:21 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 24 Nov 2022 15:17:21 GMT Subject: RFR: 8078471: The BACKSPACE key doesn't work with the special options"-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel" [v2] In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 13:29:12 GMT, Prasanta Sadhukhan wrote: > This mapping ""BACK_SPACE", "Go Up"," I guess has nothing to do with squarebutton property..Probably you are confusing it with your other fix? Yeah, I am sorry. I will check in Nimbus then how it's happening. > You probably can do requestFocusInWindow to proper component...you can try to find the who has the focus by getFocusOwner() when you try to do manually BACKSPACE and try to set to that in automated test... Ok. ------------- PR: https://git.openjdk.org/jdk/pull/11291 From psadhukhan at openjdk.org Thu Nov 24 15:27:08 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 24 Nov 2022 15:27:08 GMT Subject: RFR: 8296660: Swing HTML table with omitted closing tags misparsed Message-ID: <8QRoaTYNsQAZoB6Kcj1Duyk1dxtcvDiGz5HR0-7TEIA=.0dcf5cc8-5b92-40bf-ab57-670a1e020f62@github.com> This is in continuation with https://github.com/openjdk/jdk/commit/7133fc93e168f3671d048b2ae654f84ec289b98d fix done for [JDK-7172359](https://bugs.openjdk.org/browse/JDK-7172359) issue where fix was done to rectify invalid tag causing StackOverflowError but it caused alignment issue if the closing tags are optional, so the fix is modified to check for optional closing tag in which case dont return false for legalElementContext() JDK-7172359 fix and other CI regression tests are fine. ------------- Commit messages: - Fix - Fix - 8296660: Swing HTML table with omitted closing tags misparsed Changes: https://git.openjdk.org/jdk/pull/11355/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11355&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296660 Stats: 74 lines in 2 files changed: 73 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11355.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11355/head:pull/11355 PR: https://git.openjdk.org/jdk/pull/11355 From serb at openjdk.org Fri Nov 25 01:34:26 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 25 Nov 2022 01:34:26 GMT Subject: RFR: 8296905: Replace the native LCMS#getProfileID() method with the accessor [v3] In-Reply-To: References: Message-ID: > The native method used to access the private method in the `ICC_Profile` class is replaced by the accessor. Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8296905 - Update AWTAccessor.java - Merge remote-tracking branch 'upstream/master' into JDK-8296905 - 8296905: Replace the native LCMS#getProfileID() method with the accessor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11116/files - new: https://git.openjdk.org/jdk/pull/11116/files/f7b74481..9e7819fb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11116&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11116&range=01-02 Stats: 26596 lines in 411 files changed: 11421 ins; 4961 del; 10214 mod Patch: https://git.openjdk.org/jdk/pull/11116.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11116/head:pull/11116 PR: https://git.openjdk.org/jdk/pull/11116 From duke at openjdk.org Fri Nov 25 02:23:22 2022 From: duke at openjdk.org (SWinxy) Date: Fri, 25 Nov 2022 02:23:22 GMT Subject: RFR: 8296905: Replace the native LCMS#getProfileID() method with the accessor [v3] In-Reply-To: References: Message-ID: On Fri, 25 Nov 2022 01:34:26 GMT, Sergey Bylokhov wrote: >> The native method used to access the private method in the `ICC_Profile` class is replaced by the accessor. > > Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8296905 > - Update AWTAccessor.java > - Merge remote-tracking branch 'upstream/master' into JDK-8296905 > - 8296905: Replace the native LCMS#getProfileID() method with the accessor src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMS.java line 59: > 57: if (p instanceof LCMSProfile) { > 58: return (LCMSProfile)p; > 59: } Would be a good time to Suggestion: if (p instanceof LCMSProfile profile) { return profile; } ------------- PR: https://git.openjdk.org/jdk/pull/11116 From serb at openjdk.org Fri Nov 25 06:35:22 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 25 Nov 2022 06:35:22 GMT Subject: RFR: 8296905: Replace the native LCMS#getProfileID() method with the accessor [v3] In-Reply-To: References: Message-ID: On Fri, 25 Nov 2022 02:21:09 GMT, SWinxy wrote: >> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into JDK-8296905 >> - Update AWTAccessor.java >> - Merge remote-tracking branch 'upstream/master' into JDK-8296905 >> - 8296905: Replace the native LCMS#getProfileID() method with the accessor > > src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMS.java line 59: > >> 57: if (p instanceof LCMSProfile) { >> 58: return (LCMSProfile)p; >> 59: } > > Would be a good time to > Suggestion: > > if (p instanceof LCMSProfile profile) { > return profile; > } That change is possible but it will be better to do it as a separate cleanup. ------------- PR: https://git.openjdk.org/jdk/pull/11116 From serb at openjdk.org Fri Nov 25 06:38:08 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 25 Nov 2022 06:38:08 GMT Subject: RFR: 8297481: Create a regression test for JDK-4424517 In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 08:57:23 GMT, Srinivas Mandalika wrote: > 8297481: Create a regression test for JDK-4424517 Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11313 From smandalika at openjdk.org Fri Nov 25 08:34:28 2022 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Fri, 25 Nov 2022 08:34:28 GMT Subject: RFR: 8295707: Create a regression test for JDK-7184401 [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 07:28:02 GMT, Srinivas Mandalika wrote: >> 8295707: Create a regression test for JDK-7184401 >> >> JDK-7184401 - JDk7u6 : Missing main menu bar in Netbeans after fix for 7162144 >> Above bug got introduced due to a fix for [JDK-7162144](https://bugs.openjdk.java.net/browse/JDK-7162144). >> The issue was observed on the netbeans UI. >> The test below recreates a standalone test to mimic the failure reported in Netbeans in [JDK-7184401](https://bugs.openjdk.java.net/browse/JDK-7184401) and verifies that it is working as expected after it got fixed via [JDK-7189350](https://bugs.openjdk.java.net/browse/JDK-7189350)) >> >> The Test attempts to reproduce specific behavior of NetBeans at the certain toolbar creation stage. Widgets are created on EDT; Another code posts some events to them on EDT; From another thread some code calls explicitly edt.interrupt(). >> Before this got fixed, events from a second code got lost. >> >> This review is for migrating tests from a closed test suite to open. >> Testing: >> 1.Tested the code on jdk7u6 to reproduce the issue - the UI hangs when run on this build. >> 2. Tested the code on jdk7u361 b01 to validate the fix - the test passed. >> 3.Mach5 Testing(40 times per platform) in macos x64, linux x64 and windows x64 - the .results are clean > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Fixed Review Comments: Removed redundant code @mrserb Can you please share your thoughts on the reasons provided for your earlier queries and whether they are adequate? ------------- PR: https://git.openjdk.org/jdk/pull/10784 From smandalika at openjdk.org Fri Nov 25 10:22:08 2022 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Fri, 25 Nov 2022 10:22:08 GMT Subject: RFR: 8297481: Create a regression test for JDK-4424517 In-Reply-To: References: Message-ID: On Fri, 25 Nov 2022 06:35:54 GMT, Sergey Bylokhov wrote: >> 8297481: Create a regression test for JDK-4424517 > > Marked as reviewed by serb (Reviewer). @mrserb Can you please psonsor this request ? ------------- PR: https://git.openjdk.org/jdk/pull/11313 From mbaesken at openjdk.org Fri Nov 25 11:29:31 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 25 Nov 2022 11:29:31 GMT Subject: RFR: JDK-8297523 : Various GetPrimitiveArrayCritical miss result - NULL check Message-ID: <1i9xv5FZCi0_xvHCKtUwhGdYY6MGNKqpA55qWMPc9E0=.8010118f-59ba-4320-89ac-1f637ac46b54@github.com> There are still a few places where GetPrimitiveArrayCritical calls miss the result check. This should be adjusted. A similar case was recently adjusted here : https://bugs.openjdk.org/browse/JDK-8297480 ------------- Commit messages: - JDK-8297523 Changes: https://git.openjdk.org/jdk/pull/11361/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11361&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297523 Stats: 45 lines in 7 files changed: 22 ins; 5 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/11361.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11361/head:pull/11361 PR: https://git.openjdk.org/jdk/pull/11361 From stuefe at openjdk.org Fri Nov 25 13:13:01 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 25 Nov 2022 13:13:01 GMT Subject: RFR: JDK-8297523 : Various GetPrimitiveArrayCritical miss result - NULL check In-Reply-To: <1i9xv5FZCi0_xvHCKtUwhGdYY6MGNKqpA55qWMPc9E0=.8010118f-59ba-4320-89ac-1f637ac46b54@github.com> References: <1i9xv5FZCi0_xvHCKtUwhGdYY6MGNKqpA55qWMPc9E0=.8010118f-59ba-4320-89ac-1f637ac46b54@github.com> Message-ID: On Fri, 25 Nov 2022 09:15:08 GMT, Matthias Baesken wrote: > There are still a few places where GetPrimitiveArrayCritical calls miss the result check. This should be adjusted. > A similar case was recently adjusted here : https://bugs.openjdk.org/browse/JDK-8297480 Hi Matthias, But all this is just theoretical, right, since GPAC does not allocate memory in hotspot? Your patch is fine, though I would prefer OOMEs instead of silently omitting code. Cheers, Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/11361 From mbaesken at openjdk.org Fri Nov 25 13:39:06 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 25 Nov 2022 13:39:06 GMT Subject: RFR: JDK-8297523 : Various GetPrimitiveArrayCritical miss result - NULL check In-Reply-To: References: <1i9xv5FZCi0_xvHCKtUwhGdYY6MGNKqpA55qWMPc9E0=.8010118f-59ba-4320-89ac-1f637ac46b54@github.com> Message-ID: <2Y3jFvsBBcS74LUBY0qg2M1QrY4Z_D2ocETzzi-OkqQ=.c51e3069-f5f6-499c-8654-94aa0654cf2d@github.com> On Fri, 25 Nov 2022 13:09:27 GMT, Thomas Stuefe wrote: > Hi Matthias, > > But all this is just theoretical, right, since GPAC does not allocate memory in hotspot? Your patch is fine, though I would prefer OOMEs instead of silently omitting code. > > Cheers, Thomas Hi Thomas, from what I see in Hotspot (src/hotspot/share/prims/jni.cpp) , 2815 JNI_ENTRY(void*, jni_GetPrimitiveArrayCritical(JNIEnv *env, jarray array, jboolean *isCopy)) 2816 HOTSPOT_JNI_GETPRIMITIVEARRAYCRITICAL_ENTRY(env, array, (uintptr_t *) isCopy); 2817 if (isCopy != NULL) { 2818 *isCopy = JNI_FALSE; 2819 } isCopy is always set to JNI_FALSE (in case the copy-related parameter is not NULL. So I think your observation about memory allocation is correct. ------------- PR: https://git.openjdk.org/jdk/pull/11361 From duke at openjdk.org Sat Nov 26 04:15:21 2022 From: duke at openjdk.org (duke) Date: Sat, 26 Nov 2022 04:15:21 GMT Subject: Withdrawn: 4756278: RFE: Insufficient API documentation for java.awt.Polygon constructor In-Reply-To: <6ZyhGs5SlC42FDN3ToVFR1XybAsdWBTYzu3JBf_Pxsk=.1813b436-3c16-4686-bc0f-52b7039adb63@github.com> References: <6ZyhGs5SlC42FDN3ToVFR1XybAsdWBTYzu3JBf_Pxsk=.1813b436-3c16-4686-bc0f-52b7039adb63@github.com> Message-ID: On Mon, 26 Sep 2022 02:49:36 GMT, SWinxy wrote: > Appends: `, copying the array contents of {@code xpoints} and {@code ypoints}` to specify that the arrays in the constructor are explicitly copied. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/10418 From duke at openjdk.org Sat Nov 26 04:16:19 2022 From: duke at openjdk.org (duke) Date: Sat, 26 Nov 2022 04:16:19 GMT Subject: Withdrawn: 4668290: unclear spec for Polygon.bounds field In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 02:27:53 GMT, SWinxy wrote: > New documentation replaces the `This value can be null.`: > > When created, {@link #invalidate() invalidated}, or {@link #reset() reset}, > this becomes {@code null}. To get out of the null state, > {@link #getBounds()} called with {@link #npoints} being greater than > {@code 0} will transfer into a non-null {@link Rectangle}. > > > I think I've got the reason for why it can be `null` correct, but you never know. > > In javax.swing.text.html.Map, I've replaced setting the field to null with the equivalent #invalidate(). This may mean we can make the field private in the future. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/10417 From serb at openjdk.org Sat Nov 26 04:31:22 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 26 Nov 2022 04:31:22 GMT Subject: RFR: 8297676: DataBuffer.TYPE_SHORT/TYPE_FLOAT/TYPE_DOUBLE are not placeholders Message-ID: The specification for the DataBuffer.TYPE_SHORT/TYPE_FLOAT/TYPE_DOUBLE mentioned that all of them are "Placeholder for future use" which is not true. They are used and it is possible to create the ComponentColorModel for each of this transferType. Also, there is a specific data buffer for each: [DataBufferFloat](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/DataBufferFloat.java#L67), [DataBufferDouble](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/DataBufferDouble.java#L67), and [DataBufferShort](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/DataBufferShort.java#L74). ------------- Commit messages: - 8297676: DataBuffer.TYPE_SHORT/TYPE_FLOAT/TYPE_DOUBLE are not placeholders Changes: https://git.openjdk.org/jdk/pull/11374/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11374&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297676 Stats: 10 lines in 1 file changed: 2 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11374.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11374/head:pull/11374 PR: https://git.openjdk.org/jdk/pull/11374 From azvegint at openjdk.org Sun Nov 27 00:24:56 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Sun, 27 Nov 2022 00:24:56 GMT Subject: RFR: 8297676: DataBuffer.TYPE_SHORT/TYPE_FLOAT/TYPE_DOUBLE are not placeholders In-Reply-To: References: Message-ID: On Sat, 26 Nov 2022 02:58:15 GMT, Sergey Bylokhov wrote: > The specification for the DataBuffer.TYPE_SHORT/TYPE_FLOAT/TYPE_DOUBLE mentioned that all of them are "Placeholder for future use" which is not true. > > They are used and it is possible to create the ComponentColorModel for each of this transferType. Also, there is a specific data buffer for each: [DataBufferFloat](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/DataBufferFloat.java#L67), [DataBufferDouble](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/DataBufferDouble.java#L67), and [DataBufferShort](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/DataBufferShort.java#L74). Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11374 From xuelei at openjdk.org Sun Nov 27 05:27:55 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Sun, 27 Nov 2022 05:27:55 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v13] In-Reply-To: References: Message-ID: <4Wmny06cGOWkBkQ1oecPwZLp-SAke1Gun5o1-kKWLQI=.3984224b-526b-44e0-a1e3-e010a7ce7836@github.com> > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: revert use of assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11115/files - new: https://git.openjdk.org/jdk/pull/11115/files/4f80245f..ee72fb50 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=11-12 Stats: 285 lines in 24 files changed: 15 ins; 181 del; 89 mod Patch: https://git.openjdk.org/jdk/pull/11115.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11115/head:pull/11115 PR: https://git.openjdk.org/jdk/pull/11115 From stuefe at openjdk.org Sun Nov 27 08:00:08 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 27 Nov 2022 08:00:08 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v12] In-Reply-To: References: Message-ID: On Tue, 22 Nov 2022 08:02:51 GMT, Kim Barrett wrote: > Given all the near-duplicated checking of os::snprintf results, I think there is a place for a helper function to package this up. Maybe something like > > ``` > // in class os > // Performs snprintf and asserts the result is non-negative (so there was not > // an encoding error) and that the output was not truncated. > static int snprintf_checked(char* buf, size_t len, const char* fmt, ...) ATTRIBUTE_PRINTF(3, 4); > > // in runtime/os.cpp > int os::snprintf_checked(char* buf, size_t len, const char* fmt, ...) { > va_list args; > va_start(args, fmt); > int result = os::vsnprintf(buf, len, fmt, args); > va_end(args); > assert(result >= 0, "os::snprintf error"); > assert(static_cast(result) < size, "os::snprintf truncated"); > return result; > } > ``` > > (I keep waffling over whether the truncation check should be an assert or a guarantee.) > > I've not yet gone through all the changes yet to consider which should do that checking and which should do something different, such as permitting truncation. > > I'm not wedded to that name; indeed, I don't like it that much, as it's kind of inconveniently long. There's a temptation to have os::snprintf forbid truncation and a different function that allows it, but that would require careful auditing of all pre-existing uses of os::snprintf too, so no. How about renaming the existing os::snprintf to something like os::snprintf_unchecked, make os::snprintf the checked version, then, in separate RFEs, revert existing uses to the new API. When all uses of os::snprintf_unchecked are cleared up, remove it. That would make it possible to revert piecemeal while not racing with new uses of os::snprintf, since new callers will use the new checking API automatically. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From serb at openjdk.org Sun Nov 27 10:04:52 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 27 Nov 2022 10:04:52 GMT Subject: RFR: 8297681: Unnecessary color conversion during 4BYTE_ABGR_PRE to INT_ARGB_PRE blit Message-ID: <6i0_xf7jDRAnSDYgpij2L4JE2mDa4tOJ1j6okhbxEho=.2595083c-c1c6-44c2-8aef-10e317aaa2ae@github.com> I have found that drawing the BufferedImage.4BYTE_ABGR_PRE to the INT_ARGB_PRE image caused java2d to do an additional conversion from/to ARGB format. That conversion is done via a native [loop](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/share/native/libawt/java2d/loops/AlphaMath.c#L32) which tries to approximate the math, it is better to skip such conversion. An additional benefit is ~x2 performance improvements of this blit, so it will have the same performance as the opposite INT_ARGB_PRE to 4BYTE_ABGR_PRE blit. global.dest=BufImg(IntArgbPre),graphics.imaging.src=4ByteAbgrPre translucent,graphics.opts.alpharule=Src,graphics.opts.sizes=100: fix: 286439.77665 (var=3.42%) (100.0%) ***********************************************************| ***********************************************************| ********************************************************** | base: 167280.80808 (var=1.8%) (58.4%) ********************************** | ********************************** | ********************************** | global.dest=BufImg(IntArgbPre),graphics.imaging.src=4ByteAbgrPre translucent,graphics.opts.alpharule=SrcOver,graphics.opts.sizes=100: fix: 325989.80002 (var=1.58%) (100.0%) *********************************************************** | ************************************************************| ************************************************************| base: 200830.44521 (var=1.58%) (61.61%) ************************************* | ************************************* | ************************************* | To implement direct 4BYTE_ABGR_PRE to INT_ARGB_PRE blit it is necessary to "declare" and "register" blit only, all other macros are already in place. ------------- Commit messages: - Update SkipConversionIfPossible.java - Update SkipConversionIfPossible.java - make 4BYTE_ABGR_PRE to TYPE_INT_ARGB_PRE blit direct Changes: https://git.openjdk.org/jdk/pull/11376/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11376&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297681 Stats: 98 lines in 2 files changed: 97 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11376.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11376/head:pull/11376 PR: https://git.openjdk.org/jdk/pull/11376 From abhiscxk at openjdk.org Sun Nov 27 16:15:21 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Sun, 27 Nov 2022 16:15:21 GMT Subject: RFR: 8078471: The BACKSPACE key doesn't work with the special options"-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel" [v3] In-Reply-To: References: Message-ID: > The Backspace key doesn't lead to parent directory of current directory for JFileChooser in GTK LAF. > Added the lazy input value in `GTKLookandFeel` and fix is working fine. > > Implemented a manual test to check BackSpace behavior for all installed LAF in Linux platform. > The test mentioned in [JDK-8078471](https://bugs.openjdk.org/browse/JDK-8078471) `javax/swing/JFileChooser/4150029/bug4150029.html` also working fine with GTK option (-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel). Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Manual Test changed to automated ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11291/files - new: https://git.openjdk.org/jdk/pull/11291/files/1fcdc76c..dca0f8a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11291&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11291&range=01-02 Stats: 168 lines in 1 file changed: 85 ins; 54 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/11291.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11291/head:pull/11291 PR: https://git.openjdk.org/jdk/pull/11291 From abhiscxk at openjdk.org Sun Nov 27 16:25:15 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Sun, 27 Nov 2022 16:25:15 GMT Subject: RFR: 8078471: The BACKSPACE key doesn't work with the special options"-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel" [v4] In-Reply-To: References: Message-ID: > The Backspace key doesn't lead to parent directory of current directory for JFileChooser in GTK LAF. > Added the lazy input value in `GTKLookandFeel` and fix is working fine. > > Implemented a manual test to check BackSpace behavior for all installed LAF in Linux platform. > The test mentioned in [JDK-8078471](https://bugs.openjdk.org/browse/JDK-8078471) `javax/swing/JFileChooser/4150029/bug4150029.html` also working fine with GTK option (-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel). Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Whitespace error fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11291/files - new: https://git.openjdk.org/jdk/pull/11291/files/dca0f8a0..3b19e5cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11291&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11291&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11291.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11291/head:pull/11291 PR: https://git.openjdk.org/jdk/pull/11291 From abhiscxk at openjdk.org Sun Nov 27 16:25:15 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Sun, 27 Nov 2022 16:25:15 GMT Subject: RFR: 8078471: The BACKSPACE key doesn't work with the special options"-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel" [v2] In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 13:19:04 GMT, Abhishek Kumar wrote: > Also, is it not possible to create automated test, like calling JFileChooser.getCurrentDirectory() and fail if it's not the parent directory (or if it still remains in present directory) after BACKSPACE is pressed? Added Automated test case. Tested in CI pipeline, Link is attached in JBS. ------------- PR: https://git.openjdk.org/jdk/pull/11291 From mernst at openjdk.org Sun Nov 27 17:53:30 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 27 Nov 2022 17:53:30 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs? Then it can be merged, rather than wasting all the effort that went into it. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From abhiscxk at openjdk.org Mon Nov 28 04:10:58 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 28 Nov 2022 04:10:58 GMT Subject: RFR: 8078471: The BACKSPACE key doesn't work with the special options"-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel" [v2] In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 13:19:04 GMT, Abhishek Kumar wrote: > I wonder how it works in Nimbus as this mapping is not there in Synth/NimbusLookAndFeel and still it works and both GTK/Nimbus extends Synth. Can you please check? The " Go Up" action in Nimbus is mapped through FilePane class. But how Back_Space is mapped to "Go Up" is not clear. There is a mapping in SynthStyle "BACK_SPACE", "Go Up", but even after commenting the backspace works fine. ------------- PR: https://git.openjdk.org/jdk/pull/11291 From duke at openjdk.org Mon Nov 28 05:02:59 2022 From: duke at openjdk.org (Naveen Narayanan) Date: Mon, 28 Nov 2022 05:02:59 GMT Subject: Withdrawn: 8297095: Write a test to determine the quit request of the application In-Reply-To: References: Message-ID: <45293FqE5ay-PpbghoVfn1WjjMRa25IFJgWfvSwDTmA=.d38461b8-9614-4830-8deb-4c6c565587d7@github.com> On Wed, 23 Nov 2022 16:59:05 GMT, Naveen Narayanan wrote: > This testcase will > 1) Verify the handleQuitRequestWith() method of QuitHandler interface. > 2) Check that the response is passed to the handler by means of quit notification generated by a key combination of META+Q (Mac) or ALT+F4(Windows & Linux). > 3) Confirm that the active window is closed. > > Testing: > Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/11328 From xuelei at openjdk.org Mon Nov 28 07:19:27 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 28 Nov 2022 07:19:27 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v14] In-Reply-To: References: Message-ID: > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: no check on adlc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11115/files - new: https://git.openjdk.org/jdk/pull/11115/files/ee72fb50..6d91a6d7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=12-13 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11115.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11115/head:pull/11115 PR: https://git.openjdk.org/jdk/pull/11115 From xuelei at openjdk.org Mon Nov 28 07:48:23 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 28 Nov 2022 07:48:23 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v15] In-Reply-To: References: Message-ID: > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: use checked snprintf ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11115/files - new: https://git.openjdk.org/jdk/pull/11115/files/6d91a6d7..4143f51e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=13-14 Stats: 30 lines in 13 files changed: 0 ins; 0 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/11115.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11115/head:pull/11115 PR: https://git.openjdk.org/jdk/pull/11115 From xuelei at openjdk.org Mon Nov 28 07:55:02 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 28 Nov 2022 07:55:02 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v15] In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 07:48:23 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> May I have this update reviewed? >> >> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > use checked snprintf Please hold on the review. I run into weird issues while using checked snprintf in `adlc`. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From jpai at openjdk.org Mon Nov 28 09:02:13 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 28 Nov 2022 09:02:13 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Sun, 27 Nov 2022 17:49:57 GMT, Michael Ernst wrote: > Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs? Then it can be merged, rather than wasting all the effort that went into it. I've raised https://github.com/openjdk/jdk/pull/11385 for one set of changes from this current PR. I'll pick up the other ones shortly in different PRs. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From jdv at openjdk.org Mon Nov 28 09:20:56 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 28 Nov 2022 09:20:56 GMT Subject: RFR: JDK-8297523 : Various GetPrimitiveArrayCritical miss result - NULL check In-Reply-To: <1i9xv5FZCi0_xvHCKtUwhGdYY6MGNKqpA55qWMPc9E0=.8010118f-59ba-4320-89ac-1f637ac46b54@github.com> References: <1i9xv5FZCi0_xvHCKtUwhGdYY6MGNKqpA55qWMPc9E0=.8010118f-59ba-4320-89ac-1f637ac46b54@github.com> Message-ID: On Fri, 25 Nov 2022 09:15:08 GMT, Matthias Baesken wrote: > There are still a few places where GetPrimitiveArrayCritical calls miss the result check. This should be adjusted. > A similar case was recently adjusted here : https://bugs.openjdk.org/browse/JDK-8297480 LGTM. Client CI test run is also green. ------------- Marked as reviewed by jdv (Reviewer). PR: https://git.openjdk.org/jdk/pull/11361 From asemenov at openjdk.org Mon Nov 28 09:26:13 2022 From: asemenov at openjdk.org (Artem Semenov) Date: Mon, 28 Nov 2022 09:26:13 GMT Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v4] In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 09:42:00 GMT, Artem Semenov wrote: >> A11Y implementation on macOS has to directly call the 'JList.setSelectedIndex' method in order to request selection on an item (see 'CAccessibility.requestSelection'). The reason is that a11y API lacks appropriate method.There's only 'javax.accessibility.AccessibleSelection#addAccessibleSelection' which is mapped to 'javax.swing.JList#addSelectionInterval', it can not be used to set selected index. >> >> @forantar @azuev-java @mrserb please review. >> >> Please note that the new API allows you to implement a multiple selection in lists from the Java side, but I did not succeed in implementing it, because I could not determine the inclusion of the so-called "VoiceOver multiple selection mode". > > Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: > > We are not using author tags in tests either - but that's just a nitpick. @mrserb Some probably related points, the implementation of the addAccessibleSelection for the JComboBox. is the same: clearAccessibleSelection(); JComboBox.this.setSelectedIndex(i); It is possible that it also hangs? I'm not sure if this should affect comboboxes. The combo box is arranged differently. When the ComboBox is opened, the focus is moved not to the list, but to the root panel, and from it it is proxied to the list items, which are a set of buttons that are not hierarchically or in any way connected. --- Are you sure that the selection should be always cleared in this method, how it will work if the jlist supports multiline selection? Or voice over does not support multyline selection? As a fix, you can delete listeners from the jlist so your request to clear the current selection will not be sent back to the voiceover. Or you can add a new method to the AccessibleSelection interface with the default implementation "clearAccessibleSelection+addAccessibleSelection". Then override it in the jlist to call setSelectedIndex(). As stated in the pull request description. We cannot yet implement multiple selection with VO quick navigation, as this part of the A11y API is not described by Apple. Calling ClearSelection will really prevent you from implementing multiple selection in the future, so we propose a new interface that will allow you to implement multiple selection in the future. Because it gives access not only to different methods of setting the selection, but also to the selection mode. The proposed solution with removing the listener will not solve the problem of binding this piece of code to the JList that we are solving. ------------- PR: https://git.openjdk.org/jdk/pull/8578 From psadhukhan at openjdk.org Mon Nov 28 09:44:19 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 28 Nov 2022 09:44:19 GMT Subject: RFR: 8078471: The BACKSPACE key doesn't work with the special options"-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel" [v4] In-Reply-To: References: Message-ID: <2R1CzE0Tjg13--ZRoJXWkR15jV5cbw4PTbsbGjbn90s=.5cc5edb6-6d93-42e9-a267-130c1bb83fee@github.com> On Sun, 27 Nov 2022 16:25:15 GMT, Abhishek Kumar wrote: >> The Backspace key doesn't lead to parent directory of current directory for JFileChooser in GTK LAF. >> Added the lazy input value in `GTKLookandFeel` and fix is working fine. >> >> Implemented a manual test to check BackSpace behavior for all installed LAF in Linux platform. >> The test mentioned in [JDK-8078471](https://bugs.openjdk.org/browse/JDK-8078471) `javax/swing/JFileChooser/4150029/bug4150029.html` also working fine with GTK option (-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel). > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Whitespace error fix Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11291 From lbourges at openjdk.org Mon Nov 28 10:51:12 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Mon, 28 Nov 2022 10:51:12 GMT Subject: RFR: 8269806: Emoji rendering on Linux [v13] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 11:14:11 GMT, Nikita Gubarkov wrote: >> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix italic and bold styles for colored outline glyphs > > ? @YaaZ Could you merge with latest openjdk20 master to let CI build again ? ------------- PR: https://git.openjdk.org/jdk/pull/4798 From lbourges at openjdk.org Mon Nov 28 11:00:07 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Mon, 28 Nov 2022 11:00:07 GMT Subject: RFR: 8297681: Unnecessary color conversion during 4BYTE_ABGR_PRE to INT_ARGB_PRE blit In-Reply-To: <6i0_xf7jDRAnSDYgpij2L4JE2mDa4tOJ1j6okhbxEho=.2595083c-c1c6-44c2-8aef-10e317aaa2ae@github.com> References: <6i0_xf7jDRAnSDYgpij2L4JE2mDa4tOJ1j6okhbxEho=.2595083c-c1c6-44c2-8aef-10e317aaa2ae@github.com> Message-ID: <5ttFIIbb2HmtXGz1RJtzl4cYY8pK5kh-cSFd7lNAHQk=.516eb6ec-fbc1-448f-84c6-ecc4ea2dacc4@github.com> On Sun, 27 Nov 2022 06:26:48 GMT, Sergey Bylokhov wrote: > I have found that drawing the BufferedImage.4BYTE_ABGR_PRE to the INT_ARGB_PRE image caused java2d to do an additional conversion from/to ARGB format. That conversion is done via a native [loop](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/share/native/libawt/java2d/loops/AlphaMath.c#L32) which tries to approximate the math, it is better to skip such conversion. > > An additional benefit is ~x2 performance improvements of this blit, so it will have the same performance as the opposite INT_ARGB_PRE to 4BYTE_ABGR_PRE blit. > > > global.dest=BufImg(IntArgbPre),graphics.imaging.src=4ByteAbgrPre > translucent,graphics.opts.alpharule=Src,graphics.opts.sizes=100: > fix: 286439.77665 (var=3.42%) (100.0%) > ***********************************************************| > ***********************************************************| > ********************************************************** | > base: 167280.80808 (var=1.8%) (58.4%) > ********************************** | > ********************************** | > ********************************** | > > global.dest=BufImg(IntArgbPre),graphics.imaging.src=4ByteAbgrPre > translucent,graphics.opts.alpharule=SrcOver,graphics.opts.sizes=100: > fix: 325989.80002 (var=1.58%) (100.0%) > *********************************************************** | > ************************************************************| > ************************************************************| > base: 200830.44521 (var=1.58%) (61.61%) > ************************************* | > ************************************* | > ************************************* | > > > To implement direct 4BYTE_ABGR_PRE to INT_ARGB_PRE blit it is necessary to "declare" and "register" blit only, all other macros are already in place. Excellent finding ! LGTM, not an official reviewer. ------------- PR: https://git.openjdk.org/jdk/pull/11376 From honkar at openjdk.org Mon Nov 28 17:53:34 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 28 Nov 2022 17:53:34 GMT Subject: RFR: 8297489: Write a test to verify the content change of TextField sends TextEvent [v3] In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 06:10:20 GMT, ravi gupta wrote: >> This testcase Verify the content changes of a TextField for the following assertions. >> >> a. TextListener get invoked when the content of a TextField gets changed. >> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8297489: Review fixes Marked as reviewed by honkar (Author). ------------- PR: https://git.openjdk.org/jdk/pull/11326 From alexsch at openjdk.org Mon Nov 28 18:52:24 2022 From: alexsch at openjdk.org (Alexander Scherbatiy) Date: Mon, 28 Nov 2022 18:52:24 GMT Subject: RFR: 8295737: macOS: Print content cut off when width > height with portrait orientation [v2] In-Reply-To: References: Message-ID: > A printed content is truncated on macOS if the content paper size width larger than height with portrait orientation or width is less than height with landscape orientation. > > To reproduce the issue run the [CutOffImage](https://bugs.openjdk.org/secure/attachment/101145/CutOffImage.java) sample on MacOS. > > Four rectangles are printed: > 1. size 300x100, portrait orientation > 2. size 300x100, landscape orientation > 3. size 100x300, portrait orientation > 4. size 100x300, landscape orientation > > The first and fourth rectangles are truncated: [cut off content](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf) > > The reason is that NSPrintInfo class does not allow to set paper size and orientation independently. > Setting paper size width large than height changes NSPrintInfo orientation to landscape. > Setting paper size width less than height changes NSPrintInfo orientation to portrait. > Updating NSPrintInfo orientation from landscape to portrait or from portrait to landscape swaps NSPrintInfo paper width and height. > > The Cocoa code that shows NSPrintInfo behavior: > > #import > > int main() > { > NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; > NSApp = [NSApplication sharedApplication]; > > #ifdef __MAC_10_9 // code for SDK 10.9 or newer > #define NS_PORTRAIT NSPaperOrientationPortrait > #define NS_LANDSCAPE NSPaperOrientationLandscape > #else // code for SDK 10.8 or older > #define NS_PORTRAIT NSPortraitOrientation > #define NS_LANDSCAPE NSLandscapeOrientation > #endif > > printf("NS_PORTRAIT: %d\n", NS_PORTRAIT); > printf("NS_LANDSCAPE: %d\n", NS_LANDSCAPE); > > printf("create default print info\n"); > NSPrintInfo* defaultPrintInfo = [[NSPrintInfo sharedPrintInfo] copy]; > NSSize size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > printf("call setUpPrintOperationDefaultValues\n"); > [defaultPrintInfo setUpPrintOperationDefaultValues]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > double w = 300.0; > double h = 100.0; > printf("set size: [%f, %f]\n", w, h); > [defaultPrintInfo setPaperSize:NSMakeSize(w, h)]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > printf("Set NS_PORTRAIT orientation\n"); > [defaultPrintInfo setOrientation: NS_PORTRAIT]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > [NSApp run]; > > [NSApp release]; > [pool release]; > return(EXIT_SUCCESS); > } > > > On macOS Mojave 10.14.5 it prints: > > > NS_PORTRAIT: 0 > NS_LANDSCAPE: 1 > create default print info > orientation: 0, paper size: [612.000000, 792.000000] > call setUpPrintOperationDefaultValues > orientation: 0, paper size: [612.000000, 792.000000] > set size: [300.000000, 100.000000] > orientation: 1, paper size: [300.000000, 100.000000] // orientation flip > Set NS_PORTRAIT orientation > orientation: 0, paper size: [100.000000, 300.000000] // size flip > ``` > > There are four possible cases for printing a rectangle with different size and orientation: > 1. Input: paper size: (w > h), orientation portrait > [dstPrintInfo setPaperSize: NSMakeSize(w, h)] // size: (w, h), orientation: landscape > [dstPrintInfo setOrientation: NS_PORTRAIT] // size: (h, w), orientation: portrait > Note: width and height are swapped > 2. Input: paper size: (w > h), orientation landscape > [dstPrintInfo setPaperSize: NSMakeSize(h, w)] // size: (h, w), orientation: portrait > [dstPrintInfo setOrientation: NS_LANDSCAPE] // size: (w, h), orientation: landscape > 3. Input: paper size: (w < h), orientation portrait > [dstPrintInfo setPaperSize: NSMakeSize(w, h)] // size: (w, h), orientation: portrait > [dstPrintInfo setOrientation: NS_PORTRAIT] // size: (w, h), orientation: portrait > 4. Input: paper size: (w < h), orientation landscape > [dstPrintInfo setPaperSize: NSMakeSize(h, w)] // size: (h, w), orientation: landscape > [dstPrintInfo setOrientation: NS_LANDSCAPE] // size: (h, w), orientation: landscape > Note: width and height are swapped > > Only for cases 1 and 4 the final width and height are swapped. > The proposed fix enlarges height for cases 1 and 4 to not cut the printed rectangle. > > It is not full fix which draws rectangles for cases 1 and 4 in the requested size. > Setting requested size leads that subsequent orientation flips width and height. > The fix only enlarges the truncated area in height direction. The enlarged area in width is preserved as before the fix. > > Printed rectangles before and after the fix: > 1. size 300x100, portrait orientation: [before-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101157/before-fix-1.pdf), [after-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101162/after-fix-1.pdf) > 2. size 300x100, landscape orientation: [before-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101156/before-fix-2.pdf), [after-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101161/after-fix-2.pdf) > 3. size 100x300, portrait orientation: [before-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101155/before-fix-3.pdf), [after-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101160/after-fix-3.pdf) > 4. size 100x300, landscape orientation: [before-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101154/before-fix-4.pdf), [after-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101159/after-fix-4.pdf) > > All four rectangles: [before-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf), [after-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101158/after-fix-all.pdf) Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: Use FlipPageFormat class to establish relattions between PageFormat and NSPrintInfo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10808/files - new: https://git.openjdk.org/jdk/pull/10808/files/6ad5ebde..0f1109df Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10808&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10808&range=00-01 Stats: 778 lines in 4 files changed: 415 ins; 356 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/10808.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10808/head:pull/10808 PR: https://git.openjdk.org/jdk/pull/10808 From alexsch at openjdk.org Mon Nov 28 19:15:27 2022 From: alexsch at openjdk.org (Alexander Scherbatiy) Date: Mon, 28 Nov 2022 19:15:27 GMT Subject: RFR: 8295737: macOS: Print content cut off when width > height with portrait orientation [v3] In-Reply-To: References: Message-ID: > A printed content is truncated on macOS if the content paper size width larger than height with portrait orientation or width is less than height with landscape orientation. > > To reproduce the issue run the [CutOffImage](https://bugs.openjdk.org/secure/attachment/101145/CutOffImage.java) sample on MacOS. > > Four rectangles are printed: > 1. size 300x100, portrait orientation > 2. size 300x100, landscape orientation > 3. size 100x300, portrait orientation > 4. size 100x300, landscape orientation > > The first and fourth rectangles are truncated: [cut off content](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf) > > The reason is that NSPrintInfo class does not allow to set paper size and orientation independently. > Setting paper size width large than height changes NSPrintInfo orientation to landscape. > Setting paper size width less than height changes NSPrintInfo orientation to portrait. > Updating NSPrintInfo orientation from landscape to portrait or from portrait to landscape swaps NSPrintInfo paper width and height. > > The Cocoa code that shows NSPrintInfo behavior: > > #import > > int main() > { > NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; > NSApp = [NSApplication sharedApplication]; > > #ifdef __MAC_10_9 // code for SDK 10.9 or newer > #define NS_PORTRAIT NSPaperOrientationPortrait > #define NS_LANDSCAPE NSPaperOrientationLandscape > #else // code for SDK 10.8 or older > #define NS_PORTRAIT NSPortraitOrientation > #define NS_LANDSCAPE NSLandscapeOrientation > #endif > > printf("NS_PORTRAIT: %d\n", NS_PORTRAIT); > printf("NS_LANDSCAPE: %d\n", NS_LANDSCAPE); > > printf("create default print info\n"); > NSPrintInfo* defaultPrintInfo = [[NSPrintInfo sharedPrintInfo] copy]; > NSSize size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > printf("call setUpPrintOperationDefaultValues\n"); > [defaultPrintInfo setUpPrintOperationDefaultValues]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > double w = 300.0; > double h = 100.0; > printf("set size: [%f, %f]\n", w, h); > [defaultPrintInfo setPaperSize:NSMakeSize(w, h)]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > printf("Set NS_PORTRAIT orientation\n"); > [defaultPrintInfo setOrientation: NS_PORTRAIT]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > [NSApp run]; > > [NSApp release]; > [pool release]; > return(EXIT_SUCCESS); > } > > > On macOS Mojave 10.14.5 it prints: > > > NS_PORTRAIT: 0 > NS_LANDSCAPE: 1 > create default print info > orientation: 0, paper size: [612.000000, 792.000000] > call setUpPrintOperationDefaultValues > orientation: 0, paper size: [612.000000, 792.000000] > set size: [300.000000, 100.000000] > orientation: 1, paper size: [300.000000, 100.000000] // orientation flip > Set NS_PORTRAIT orientation > orientation: 0, paper size: [100.000000, 300.000000] // size flip > ``` > > There are four possible cases for printing a rectangle with different size and orientation: > 1. Input: paper size: (w > h), orientation portrait > [dstPrintInfo setPaperSize: NSMakeSize(w, h)] // size: (w, h), orientation: landscape > [dstPrintInfo setOrientation: NS_PORTRAIT] // size: (h, w), orientation: portrait > Note: width and height are swapped > 2. Input: paper size: (w > h), orientation landscape > [dstPrintInfo setPaperSize: NSMakeSize(h, w)] // size: (h, w), orientation: portrait > [dstPrintInfo setOrientation: NS_LANDSCAPE] // size: (w, h), orientation: landscape > 3. Input: paper size: (w < h), orientation portrait > [dstPrintInfo setPaperSize: NSMakeSize(w, h)] // size: (w, h), orientation: portrait > [dstPrintInfo setOrientation: NS_PORTRAIT] // size: (w, h), orientation: portrait > 4. Input: paper size: (w < h), orientation landscape > [dstPrintInfo setPaperSize: NSMakeSize(h, w)] // size: (h, w), orientation: landscape > [dstPrintInfo setOrientation: NS_LANDSCAPE] // size: (h, w), orientation: landscape > Note: width and height are swapped > > Only for cases 1 and 4 the final width and height are swapped. > The proposed fix enlarges height for cases 1 and 4 to not cut the printed rectangle. > > It is not full fix which draws rectangles for cases 1 and 4 in the requested size. > Setting requested size leads that subsequent orientation flips width and height. > The fix only enlarges the truncated area in height direction. The enlarged area in width is preserved as before the fix. > > Printed rectangles before and after the fix: > 1. size 300x100, portrait orientation: [before-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101157/before-fix-1.pdf), [after-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101162/after-fix-1.pdf) > 2. size 300x100, landscape orientation: [before-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101156/before-fix-2.pdf), [after-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101161/after-fix-2.pdf) > 3. size 100x300, portrait orientation: [before-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101155/before-fix-3.pdf), [after-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101160/after-fix-3.pdf) > 4. size 100x300, landscape orientation: [before-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101154/before-fix-4.pdf), [after-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101159/after-fix-4.pdf) > > All four rectangles: [before-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf), [after-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101158/after-fix-all.pdf) Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: Fix type with portrait orientation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10808/files - new: https://git.openjdk.org/jdk/pull/10808/files/0f1109df..e5d01404 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10808&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10808&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10808.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10808/head:pull/10808 PR: https://git.openjdk.org/jdk/pull/10808 From aivanov at openjdk.org Mon Nov 28 19:29:45 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 28 Nov 2022 19:29:45 GMT Subject: RFR: 8297489: Write a test to verify the content change of TextField sends TextEvent [v3] In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 06:10:20 GMT, ravi gupta wrote: >> This testcase Verify the content changes of a TextField for the following assertions. >> >> a. TextListener get invoked when the content of a TextField gets changed. >> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8297489: Review fixes This test is very similar to that in #11052: `TextField` vs `TextArea` ([JDK-8296632](https://bugs.openjdk.org/browse/JDK-8296632)). Is it possible to modify the test so that it runs twice for both components? ------------- Changes requested by aivanov (Reviewer). PR: https://git.openjdk.org/jdk/pull/11326 From honkar at openjdk.org Mon Nov 28 19:40:08 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 28 Nov 2022 19:40:08 GMT Subject: RFR: 8297489: Write a test to verify the content change of TextField sends TextEvent [v3] In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 19:26:52 GMT, Alexey Ivanov wrote: > This test is very similar to that in #11052: `TextField` vs `TextArea` ([JDK-8296632](https://bugs.openjdk.org/browse/JDK-8296632)). > > Is it possible to modify the test so that it runs twice for both components? I agree with @aivanov-jdk. The test can be modified to check both TextArea and TextField to avoid code repetition. ------------- PR: https://git.openjdk.org/jdk/pull/11326 From honkar at openjdk.org Mon Nov 28 20:25:19 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 28 Nov 2022 20:25:19 GMT Subject: RFR: JDK-8297449: Update JInternalFrame Metal Border code [v2] In-Reply-To: References: Message-ID: > Updated Metal Border code for JInternalFrame. > > - Added instanceof check before casting Graphics to G2D. > - Replaced roundHalfDown with Region.clipRound() Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: review changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11305/files - new: https://git.openjdk.org/jdk/pull/11305/files/0e7e7e7d..5f019dfd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11305&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11305&range=00-01 Stats: 121 lines in 1 file changed: 40 ins; 34 del; 47 mod Patch: https://git.openjdk.org/jdk/pull/11305.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11305/head:pull/11305 PR: https://git.openjdk.org/jdk/pull/11305 From serb at openjdk.org Mon Nov 28 20:25:42 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 28 Nov 2022 20:25:42 GMT Subject: RFR: 8296878: Document Filter attached to JPasswordField and setText("") is not cleared instead inserted characters replaced with unicode null characters Message-ID: The usage of DocumentFilter in the JPasswordField is excluded from the [JDK-8258373](https://bugs.openjdk.org/browse/JDK-8258373). That will be responsibility of the application to cleanup the password if DocumentFilter is set. ------------- Commit messages: - Update OldPasswordInDocumentFilter.java - 8296878: Document Filter attached to JPasswordField and setText("") is not cleared instead inserted characters replaced with unicode null characters Changes: https://git.openjdk.org/jdk/pull/11281/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11281&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296878 Stats: 94 lines in 2 files changed: 79 ins; 2 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/11281.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11281/head:pull/11281 PR: https://git.openjdk.org/jdk/pull/11281 From prr at openjdk.org Mon Nov 28 21:18:52 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 28 Nov 2022 21:18:52 GMT Subject: RFR: 8296878: Document Filter attached to JPasswordField and setText("") is not cleared instead inserted characters replaced with unicode null characters In-Reply-To: References: Message-ID: On Tue, 22 Nov 2022 03:15:55 GMT, Sergey Bylokhov wrote: > The usage of DocumentFilter in the JPasswordField is excluded from the [JDK-8258373](https://bugs.openjdk.org/browse/JDK-8258373). That will be responsibility of the application to cleanup the password if DocumentFilter is set. Marked as reviewed by prr (Reviewer). So, if you have a filter, then revert to before https://bugs.openjdk.org/browse/JDK-8258676. OK, not sure what else we could do. ------------- PR: https://git.openjdk.org/jdk/pull/11281 From prr at openjdk.org Mon Nov 28 21:21:18 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 28 Nov 2022 21:21:18 GMT Subject: RFR: 8297676: DataBuffer.TYPE_SHORT/TYPE_FLOAT/TYPE_DOUBLE are not placeholders In-Reply-To: References: Message-ID: On Sat, 26 Nov 2022 02:58:15 GMT, Sergey Bylokhov wrote: > The specification for the DataBuffer.TYPE_SHORT/TYPE_FLOAT/TYPE_DOUBLE mentioned that all of them are "Placeholder for future use" which is not true. > > They are used and it is possible to create the ComponentColorModel for each of this transferType. Also, there is a specific data buffer for each: [DataBufferFloat](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/DataBufferFloat.java#L67), [DataBufferDouble](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/DataBufferDouble.java#L67), and [DataBufferShort](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/DataBufferShort.java#L74). Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11374 From aivanov at openjdk.org Mon Nov 28 21:37:18 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 28 Nov 2022 21:37:18 GMT Subject: RFR: 8296878: Document Filter attached to JPasswordField and setText("") is not cleared instead inserted characters replaced with unicode null characters In-Reply-To: References: Message-ID: On Tue, 22 Nov 2022 03:15:55 GMT, Sergey Bylokhov wrote: > The usage of DocumentFilter in the JPasswordField is excluded from the [JDK-8258373](https://bugs.openjdk.org/browse/JDK-8258373). That will be responsibility of the application to cleanup the password if DocumentFilter is set. Marked as reviewed by aivanov (Reviewer). And `DocumentFilter` needs to be implemented carefully so that the entered password is never converted to `String`. ------------- PR: https://git.openjdk.org/jdk/pull/11281 From prr at openjdk.org Mon Nov 28 21:57:47 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 28 Nov 2022 21:57:47 GMT Subject: RFR: 8296660: Swing HTML table with omitted closing tags misparsed In-Reply-To: <8QRoaTYNsQAZoB6Kcj1Duyk1dxtcvDiGz5HR0-7TEIA=.0dcf5cc8-5b92-40bf-ab57-670a1e020f62@github.com> References: <8QRoaTYNsQAZoB6Kcj1Duyk1dxtcvDiGz5HR0-7TEIA=.0dcf5cc8-5b92-40bf-ab57-670a1e020f62@github.com> Message-ID: On Thu, 24 Nov 2022 14:59:37 GMT, Prasanta Sadhukhan wrote: > This is in continuation with https://github.com/openjdk/jdk/commit/7133fc93e168f3671d048b2ae654f84ec289b98d fix done for [JDK-7172359](https://bugs.openjdk.org/browse/JDK-7172359) issue where fix was done to rectify invalid tag causing StackOverflowError but it caused alignment issue if the closing tags are optional, so the fix is modified to check for optional closing tag in which case dont return false for legalElementContext() > > JDK-7172359 fix and other CI regression tests are fine. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11355 From prr at openjdk.org Mon Nov 28 22:14:09 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 28 Nov 2022 22:14:09 GMT Subject: RFR: 8078471: The BACKSPACE key doesn't work with the special options"-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel" [v4] In-Reply-To: References: Message-ID: <93mjzXl5w-nEPw-YZNWxufvO_Db_qloWeOe6ckSwMNw=.7457e337-34cd-4b01-b12b-2256f6b85fd5@github.com> On Sun, 27 Nov 2022 16:25:15 GMT, Abhishek Kumar wrote: >> The Backspace key doesn't lead to parent directory of current directory for JFileChooser in GTK LAF. >> Added the lazy input value in `GTKLookandFeel` and fix is working fine. >> >> Implemented a manual test to check BackSpace behavior for all installed LAF in Linux platform. >> The test mentioned in [JDK-8078471](https://bugs.openjdk.org/browse/JDK-8078471) `javax/swing/JFileChooser/4150029/bug4150029.html` also working fine with GTK option (-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel). > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Whitespace error fix Please split the long line before pushing. Also you'll probably need to update the PR to match the new bug summary. ALWAYS consider if a bug summary is well written as part of the bug evaluation test/jdk/com/sun/java/swing/plaf/gtk/TestBackSpaceAction.java line 75: > 73: subDir = new File(testDir, "subDir"); > 74: subDir.mkdir(); > 75: subDir.deleteOnExit(); To my surprise, this should be OK. The spec says "Files (or directories) are deleted in the reverse order that they are registered." ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.org/jdk/pull/11291 From duke at openjdk.org Mon Nov 28 23:09:17 2022 From: duke at openjdk.org (SWinxy) Date: Mon, 28 Nov 2022 23:09:17 GMT Subject: RFR: JDK-8297449: Update JInternalFrame Metal Border code [v2] In-Reply-To: References: Message-ID: <7Ww09yzcYB0E2d8c85iZkhjhouSxN80dC961Uxh2kak=.6a6c887d-9ab8-428a-9bac-10e9fcbd56af@github.com> On Mon, 28 Nov 2022 20:25:19 GMT, Harshitha Onkar wrote: >> Updated Metal Border code for JInternalFrame. >> >> - Added instanceof check before casting Graphics to G2D. >> - Replaced roundHalfDown with Region.clipRound() > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > review changes src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 267: > 265: } > 266: > 267: AffineTransform at = null; Because we'd no longer be causing a `ClassCastException` from casting this to be a `Graphics2D` object, later down on line 311, if the `Graphics` object isn't a G2D type, then it will throw an NPE. I fear matrices, so I have no idea what the value of `getScaleX()` would be otherwise--replace it with zero if null? ------------- PR: https://git.openjdk.org/jdk/pull/11305 From prr at openjdk.org Mon Nov 28 23:11:59 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 28 Nov 2022 23:11:59 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: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com> References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com> Message-ID: <2zfcztLetGhtzMiWWeHBKP07uGk3EMCa7qkT5VHdPb0=.0af6f4b4-185c-4fa0-9631-9287135e0519@github.com> On Fri, 11 Nov 2022 08:18:19 GMT, Tejesh R wrote: > Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system. Where are we at with making a diagnostic update to this code and the failing test(s) ? ------------- PR: https://git.openjdk.org/jdk/pull/11104 From prr at openjdk.org Mon Nov 28 23:12:00 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 28 Nov 2022 23:12:00 GMT Subject: RFR: 8296905: Replace the native LCMS#getProfileID() method with the accessor [v3] In-Reply-To: References: Message-ID: On Fri, 25 Nov 2022 01:34:26 GMT, Sergey Bylokhov wrote: >> The native method used to access the private method in the `ICC_Profile` class is replaced by the accessor. > > Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8296905 > - Update AWTAccessor.java > - Merge remote-tracking branch 'upstream/master' into JDK-8296905 > - 8296905: Replace the native LCMS#getProfileID() method with the accessor Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11116 From prr at openjdk.org Mon Nov 28 23:27:55 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 28 Nov 2022 23:27:55 GMT Subject: RFR: 8296546: Add @spec tags to API [v3] In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons wrote: >> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. >> >> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. >> >> "Normalized" means... >> * Use `https:` where possible (includes pretty much all cases) >> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) >> * Point to the root page of a multi-page spec >> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) >> >> In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. >> >> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. >> >> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. >> >> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. >> >> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ >> >> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Remove updates from unexported files src/java.desktop/share/classes/java/awt/package-info.java line 58: > 56: *
  • The AWT Modality > 57: *
  • > 58: * The Java AWT Native Interface (JAWT) Why only 1 of these 3 ? src/java.desktop/share/classes/java/awt/package-info.java line 62: > 60: * > 61: * @spec AWT_Native_Interface.html The Java AWT Native Interface Specification and Guide > 62: * @since 1.0 I wonder if links to html we include in the javadoc should be really treated in the same manner as referecnes to externally defined specifactions ? But I also wonder why only the native_interface spec was added and not the other two ? src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java line 226: > 224: * @spec https://www.ietf.org/rfc/rfc1951.html RFC 1951: DEFLATE Compressed Data Format Specification version 1.3 > 225: * @see #TAG_COMPRESSION > 226: * @see DEFLATE specification Does having @spec and @see mean we have two clickable links to the same place adjacent to each other ? ------------- PR: https://git.openjdk.org/jdk/pull/11073 From prr at openjdk.org Mon Nov 28 23:31:08 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 28 Nov 2022 23:31:08 GMT Subject: RFR: 8297210: Add a @sealedGraph tag to selected java.desktop classes In-Reply-To: <9JrgNVgMitVkUr_bsvGzpfCv56HYqvD6pRcPuMV8jts=.4f67596a-37d5-43f3-a353-bf1d276d61a5@github.com> References: <9JrgNVgMitVkUr_bsvGzpfCv56HYqvD6pRcPuMV8jts=.4f67596a-37d5-43f3-a353-bf1d276d61a5@github.com> Message-ID: On Thu, 17 Nov 2022 14:26:48 GMT, Per Minborg wrote: > This PR proposes to opt in for graphic rendering of the sealed hierarchy for some selected classes. > > Rendering capability was added via https://bugs.openjdk.org/browse/JDK-8295653 > > Here is how it would look like: > > MultipleGradientPaint_SH > > TextComponent_SH > > AppEvent_SH > > FilesEvent_SH > > InputEvent_SH > > Path2D_SH > > StyleConstants_SH Looks pretty and I can't imagine any harm .. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.org/jdk/pull/11212 From honkar at openjdk.org Tue Nov 29 00:11:09 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 29 Nov 2022 00:11:09 GMT Subject: RFR: JDK-8297449: Update JInternalFrame Metal Border code [v2] In-Reply-To: <7Ww09yzcYB0E2d8c85iZkhjhouSxN80dC961Uxh2kak=.6a6c887d-9ab8-428a-9bac-10e9fcbd56af@github.com> References: <7Ww09yzcYB0E2d8c85iZkhjhouSxN80dC961Uxh2kak=.6a6c887d-9ab8-428a-9bac-10e9fcbd56af@github.com> Message-ID: On Mon, 28 Nov 2022 23:07:12 GMT, SWinxy wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> review changes > > src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 267: > >> 265: } >> 266: >> 267: AffineTransform at = null; > > Because we'd no longer be causing a `ClassCastException` from casting this to be a `Graphics2D` object, later down on line 311, if the `Graphics` object isn't a G2D type, then it will throw an NPE. I fear matrices, so I have no idea what the value of `getScaleX()` would be otherwise--replace it with zero if null? @SWinxy Thanks for catching it. That's right, but the scale factor cannot be zero, it should probably be handled similar to `stkWidth` if **'at is null'** (at is null when g is not an instance of Graphics2D). I'll need to check the scale value to be used in this context. Something like below. `at != null ? at.getScaleX() : 1;` ------------- PR: https://git.openjdk.org/jdk/pull/11305 From dnguyen at openjdk.org Tue Nov 29 01:20:23 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 29 Nov 2022 01:20:23 GMT Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is unstable in MacOS machines In-Reply-To: References: Message-ID: On Tue, 11 Oct 2022 14:17:42 GMT, Manukumar V S wrote: > java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as adding some stability improvements fixes the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. This fix doesn't cover the Windows issue, so the problem listing in windows will remain same. > > Fix: > Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS. > Also updated the screen capture code, made frame undecorated, added some prints for better debugging. I ran the updated test in CI and locally, and it seems to be OK. My issue is that when I run locally, the test takes noticeably longer to execute and complete. I tried investigating the issue by implementing your changes incrementally, and I believe it's due to the waitForIdle after button3 presses. Maybe it's better to place a set amount of delay in ms here instead? Additionally, there are multiple spacing issues in the updated lines, and the header needs to be updated to have "2022" alongside the "2017" test date. test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 75: > 73: while (point.y < currentScreenBounds.y + currentScreenBounds.height - insets.bottom - SIZE) { > 74: while (point.x < > 75: currentScreenBounds.x + currentScreenBounds.width - insets.right - SIZE) { This might not be the most elegant way to abide by the rule to create a new line for long lines. I believe the line limit is 80 characters, which this still violates. And since it looks like you're trying to fix that here, might as well do it correctly. test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 114: > 112: private void show(MouseEvent e) { > 113: if (e.isPopupTrigger()) { > 114: System.out.println("Going to show popup "+pm+" on "+frame); There seems to be a lack of consistency with spacing throughout the test. Spacing out the "+" from the quotations and the vars makes it cleaner. test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 133: > 131: robot.mousePress(InputEvent.BUTTON3_DOWN_MASK); > 132: robot.mouseRelease(InputEvent.BUTTON3_DOWN_MASK); > 133: robot.waitForIdle(); When testing locally on my macOS machine, this waitForIdle seems to be the culprit for why this test takes much longer per iteration. Maybe worth looking into why? test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 134: > 132: robot.mouseRelease(InputEvent.BUTTON3_DOWN_MASK); > 133: robot.waitForIdle(); > 134: y = y+50; Another instance of the spacing issue. There seems to be more in this test, so it's probably best to fix them all. test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 151: > 149: try { > 150: ImageIO.write(robot.createScreenCapture(currentScreenBounds), "png", > 151: new File("screen1.png")); Is screen1.png the best name for the image? May be misleading if there are multiple screens, especially since this test iterates multiple locations. ------------- PR: https://git.openjdk.org/jdk/pull/10655 From dnguyen at openjdk.org Tue Nov 29 02:04:32 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 29 Nov 2022 02:04:32 GMT Subject: RFR: 8202931: [macos] java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java fails [v2] In-Reply-To: References: Message-ID: > Test ran on all OS 100 times and passed. Test previously failed on macOS but no longer reproducible. Added screen capture on moment of failure to have more evidence of failures in the future (previously a runtime exception was thrown only). Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Update test to capture current screen ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11277/files - new: https://git.openjdk.org/jdk/pull/11277/files/8dd89897..0e02c8ea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11277&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11277&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11277.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11277/head:pull/11277 PR: https://git.openjdk.org/jdk/pull/11277 From duke at openjdk.org Tue Nov 29 02:16:20 2022 From: duke at openjdk.org (SWinxy) Date: Tue, 29 Nov 2022 02:16:20 GMT Subject: RFR: JDK-8297449: Update JInternalFrame Metal Border code [v2] In-Reply-To: References: <7Ww09yzcYB0E2d8c85iZkhjhouSxN80dC961Uxh2kak=.6a6c887d-9ab8-428a-9bac-10e9fcbd56af@github.com> Message-ID: On Tue, 29 Nov 2022 00:05:18 GMT, Harshitha Onkar wrote: >> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 267: >> >>> 265: } >>> 266: >>> 267: AffineTransform at = null; >> >> Because we'd no longer be causing a `ClassCastException` from casting this to be a `Graphics2D` object, later down on line 311, if the `Graphics` object isn't a G2D type, then it will throw an NPE. I fear matrices, so I have no idea what the value of `getScaleX()` would be otherwise--replace it with zero if null? > > @SWinxy Thanks for catching it. That's right, but the scale factor cannot be zero, it should probably be handled similar to `stkWidth` if **'at is null'** (at is null when g is not an instance of Graphics2D). I'll need to check the scale value to be used in this context. > > Something like below. > `at != null ? at.getScaleX() : 1;` Oh I see. Otherwise the thickness would be zero. I feeeeel like doing a large if-else on checking if g is a Graphics2D would end up being cleaner. I fiddled around and this is what the else branch would look like with the affine transform value being `1`: g.translate(x, y); g.setColor(background); // Draw the bulk of the border for (int i = 0; i < 5; i++) { g.drawRect(i, i, w - (i * 2), h - (i * 2)); } if (c instanceof JInternalFrame internalFrame && internalFrame.isResizable()) { // Draw the Long highlight lines g.setColor(highlight); g.drawLine(CORNER + 1, 2, w - CORNER, 2); //top g.drawLine(2, CORNER + 1, 2, h - CORNER); //left g.drawLine(w - 2, CORNER + 1, w - 2, h - CORNER); //right g.drawLine(CORNER + 1, h - 2, w - CORNER, h - 2); //bottom // Draw the Long shadow lines g.setColor(shadow); g.drawLine(CORNER, 1, w - CORNER - 1, 1); g.drawLine(1, CORNER, 1, h - CORNER - 1); g.drawLine(w - 3, CORNER, w - 3, h - CORNER - 1); g.drawLine(CORNER, h - 3, w - CORNER - 1, h - 3); } // restore previous transform g.translate(-x, -y); ------------- PR: https://git.openjdk.org/jdk/pull/11305 From tr at openjdk.org Tue Nov 29 04:52:28 2022 From: tr at openjdk.org (Tejesh R) Date: Tue, 29 Nov 2022 04:52:28 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: <2zfcztLetGhtzMiWWeHBKP07uGk3EMCa7qkT5VHdPb0=.0af6f4b4-185c-4fa0-9631-9287135e0519@github.com> References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com> <2zfcztLetGhtzMiWWeHBKP07uGk3EMCa7qkT5VHdPb0=.0af6f4b4-185c-4fa0-9631-9287135e0519@github.com> Message-ID: On Mon, 28 Nov 2022 23:09:56 GMT, Phil Race wrote: > Where are we at with making a diagnostic update to this code and the failing test(s) ? It looks like the imageIcon were not loaded for _downloads_ folder, which might be the cause for `retVal` getting null value instead of ImageIcon. Mach5 tests link attached in JBS. ------------- PR: https://git.openjdk.org/jdk/pull/11104 From psadhukhan at openjdk.org Tue Nov 29 04:53:51 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 29 Nov 2022 04:53:51 GMT Subject: RFR: 6788481: CellEditorListener.editingCanceled is never called [v3] In-Reply-To: References: Message-ID: > When editing of a table cell is canceled, the function editingCanceled of the registered listener CellEditorListener is not called as actionPerformed on ESC key press was not notifying the "cancel" listeners. > Fix is to handle "Cancel" action in actionPerformed() by forwarding the Cancel message from CellEditor to the delegate so that it can call `AbstractCellEditor.fireEditingCanceled(`) which notifies all listeners of cancel event. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: jcheck issue fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10964/files - new: https://git.openjdk.org/jdk/pull/10964/files/3efbfa7b..b9a4bfc8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10964&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10964&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10964.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10964/head:pull/10964 PR: https://git.openjdk.org/jdk/pull/10964 From psadhukhan at openjdk.org Tue Nov 29 05:11:31 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 29 Nov 2022 05:11:31 GMT Subject: Integrated: 6788481: CellEditorListener.editingCanceled is never called In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 07:05:10 GMT, Prasanta Sadhukhan wrote: > When editing of a table cell is canceled, the function editingCanceled of the registered listener CellEditorListener is not called as actionPerformed on ESC key press was not notifying the "cancel" listeners. > Fix is to handle "Cancel" action in actionPerformed() by forwarding the Cancel message from CellEditor to the delegate so that it can call `AbstractCellEditor.fireEditingCanceled(`) which notifies all listeners of cancel event. This pull request has now been integrated. Changeset: 4e8e853b Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/4e8e853bc9b9ac3a89a9e25b9fec5381b8255806 Stats: 135 lines in 2 files changed: 135 ins; 0 del; 0 mod 6788481: CellEditorListener.editingCanceled is never called Reviewed-by: prr, azvegint, serb ------------- PR: https://git.openjdk.org/jdk/pull/10964 From jdv at openjdk.org Tue Nov 29 05:24:17 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 29 Nov 2022 05:24:17 GMT Subject: RFR: 8296660: Swing HTML table with omitted closing tags misparsed In-Reply-To: <8QRoaTYNsQAZoB6Kcj1Duyk1dxtcvDiGz5HR0-7TEIA=.0dcf5cc8-5b92-40bf-ab57-670a1e020f62@github.com> References: <8QRoaTYNsQAZoB6Kcj1Duyk1dxtcvDiGz5HR0-7TEIA=.0dcf5cc8-5b92-40bf-ab57-670a1e020f62@github.com> Message-ID: <44emdCOaOaD6gTGSIwvaEcwPjNUNVYodFTkwToHin14=.fb0a0b36-1b22-4b67-9381-daf26c4328a9@github.com> On Thu, 24 Nov 2022 14:59:37 GMT, Prasanta Sadhukhan wrote: > This is in continuation with https://github.com/openjdk/jdk/commit/7133fc93e168f3671d048b2ae654f84ec289b98d fix done for [JDK-7172359](https://bugs.openjdk.org/browse/JDK-7172359) issue where fix was done to rectify invalid tag causing StackOverflowError but it caused alignment issue if the closing tags are optional, so the fix is modified to check for optional closing tag in which case dont return false for legalElementContext() > > JDK-7172359 fix and other CI regression tests are fine. Tested and it works properly with fix. Also if we can set some size for JFrame in which HTML table is shown would be better. Without fix when i ran the test, the window was very small and i had to expand it to actually see mangled HTML content. Or we can add more detail in instruction to expand the frame to see full HTML table in case where issue i seen. ------------- Marked as reviewed by jdv (Reviewer). PR: https://git.openjdk.org/jdk/pull/11355 From serb at openjdk.org Tue Nov 29 05:28:21 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 29 Nov 2022 05:28:21 GMT Subject: RFR: 8202931: [macos] java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java fails [v2] In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 02:04:32 GMT, Damon Nguyen wrote: >> Test ran on all OS 100 times and passed. Test previously failed on macOS but no longer reproducible. Added screen capture on moment of failure to have more evidence of failures in the future (previously a runtime exception was thrown only). > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Update test to capture current screen test/jdk/java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java line 128: > 126: robot.waitForIdle(); > 127: if (choice.getSelectedIndex() == 0) { > 128: GraphicsConfiguration ge = GraphicsEnvironment `ge` is unused in the latest version of the patch? ------------- PR: https://git.openjdk.org/jdk/pull/11277 From abhiscxk at openjdk.org Tue Nov 29 06:02:44 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 29 Nov 2022 06:02:44 GMT Subject: RFR: 8078471: Backspace does not work in JFileChooser with GTK L&F [v5] In-Reply-To: References: Message-ID: > The Backspace key doesn't lead to parent directory of current directory for JFileChooser in GTK LAF. > Added the lazy input value in `GTKLookandFeel` and fix is working fine. > > Implemented a manual test to check BackSpace behavior for all installed LAF in Linux platform. > The test mentioned in [JDK-8078471](https://bugs.openjdk.org/browse/JDK-8078471) `javax/swing/JFileChooser/4150029/bug4150029.html` also working fine with GTK option (-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel). Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Formatting of long lines ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11291/files - new: https://git.openjdk.org/jdk/pull/11291/files/3b19e5cd..55540ef9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11291&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11291&range=03-04 Stats: 11 lines in 1 file changed: 2 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/11291.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11291/head:pull/11291 PR: https://git.openjdk.org/jdk/pull/11291 From abhiscxk at openjdk.org Tue Nov 29 06:06:06 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 29 Nov 2022 06:06:06 GMT Subject: RFR: 8078471: Backspace does not work in JFileChooser with GTK L&F [v4] In-Reply-To: <93mjzXl5w-nEPw-YZNWxufvO_Db_qloWeOe6ckSwMNw=.7457e337-34cd-4b01-b12b-2256f6b85fd5@github.com> References: <93mjzXl5w-nEPw-YZNWxufvO_Db_qloWeOe6ckSwMNw=.7457e337-34cd-4b01-b12b-2256f6b85fd5@github.com> Message-ID: On Mon, 28 Nov 2022 22:11:13 GMT, Phil Race wrote: > Please split the long line before pushing. Also you'll probably need to update the PR to match the new bug summary. ALWAYS consider if a bug summary is well written as part of the bug evaluation PR description changed to match the bug summary and long line split taken care. ------------- PR: https://git.openjdk.org/jdk/pull/11291 From xuelei at openjdk.org Tue Nov 29 06:44:39 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 29 Nov 2022 06:44:39 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v16] In-Reply-To: References: Message-ID: > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: use checked snprintf for adlc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11115/files - new: https://git.openjdk.org/jdk/pull/11115/files/4143f51e..d1a48254 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=14-15 Stats: 43 lines in 7 files changed: 12 ins; 1 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/11115.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11115/head:pull/11115 PR: https://git.openjdk.org/jdk/pull/11115 From duke at openjdk.org Tue Nov 29 07:33:20 2022 From: duke at openjdk.org (Naveen Narayanan) Date: Tue, 29 Nov 2022 07:33:20 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem [v5] In-Reply-To: References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> Message-ID: On Fri, 18 Nov 2022 21:13:29 GMT, Alexey Ivanov wrote: >> Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: >> >> 8296275: Review comments fixed. > > Since the test has nothing to do with `Desktop` class it should be moved to `JMenuItem` folder because it tests functionality of `JMenuItem`. @aivanov-jdk all review comments addressed. Can you please have a look. ------------- PR: https://git.openjdk.org/jdk/pull/11035 From aturbanov at openjdk.org Tue Nov 29 07:39:17 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 29 Nov 2022 07:39:17 GMT Subject: RFR: 8297750: Unnecessary Vector usage in IIORegistry Message-ID: Field `javax.imageio.spi.IIORegistry#initialCategories` is modified only in `static {}` block, which makes it effectively final. Instead of legacy synchronized `Vector` we can use non-threadsafe `ArrayList` here. ------------- Commit messages: - 8297750: Unnecessary Vector usage in IIORegistry - [PATCH] Unnecessary Vector usage in javax.imageio.spi.IIORegistry Changes: https://git.openjdk.org/jdk/pull/11379/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11379&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297750 Stats: 17 lines in 1 file changed: 1 ins; 7 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/11379.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11379/head:pull/11379 PR: https://git.openjdk.org/jdk/pull/11379 From duke at openjdk.org Tue Nov 29 07:39:17 2022 From: duke at openjdk.org (David Schlosnagle) Date: Tue, 29 Nov 2022 07:39:17 GMT Subject: RFR: 8297750: Unnecessary Vector usage in IIORegistry In-Reply-To: References: Message-ID: On Sun, 27 Nov 2022 17:51:15 GMT, Andrey Turbanov wrote: > Field `javax.imageio.spi.IIORegistry#initialCategories` is modified only in `static {}` block, which makes it effectively final. Instead of legacy synchronized `Vector` we can use non-threadsafe `ArrayList` here. src/java.desktop/share/classes/javax/imageio/spi/IIORegistry.java line 89: > 87: * categories (superinterfaces) to be used in the constructor. > 88: */ > 89: private static final ArrayList> initialCategories = new ArrayList<>(5); Should this be an immutable list and remove the static block? Suggestion: private static final List> initialCategories = List.of( ImageReaderSpi.class, ImageWriterSpi.class, ImageTranscoderSpi.class, ImageInputStreamSpi.class, ImageOutputStreamSpi.class); ------------- PR: https://git.openjdk.org/jdk/pull/11379 From serb at openjdk.org Tue Nov 29 07:39:18 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 29 Nov 2022 07:39:18 GMT Subject: RFR: 8297750: Unnecessary Vector usage in IIORegistry In-Reply-To: References: Message-ID: On Sun, 27 Nov 2022 22:22:54 GMT, David Schlosnagle wrote: >> Field `javax.imageio.spi.IIORegistry#initialCategories` is modified only in `static {}` block, which makes it effectively final. Instead of legacy synchronized `Vector` we can use non-threadsafe `ArrayList` here. > > src/java.desktop/share/classes/javax/imageio/spi/IIORegistry.java line 89: > >> 87: * categories (superinterfaces) to be used in the constructor. >> 88: */ >> 89: private static final ArrayList> initialCategories = new ArrayList<>(5); > > Should this be an immutable list and remove the static block? > > Suggestion: > > private static final List> initialCategories = List.of( > ImageReaderSpi.class, > ImageWriterSpi.class, > ImageTranscoderSpi.class, > ImageInputStreamSpi.class, > ImageOutputStreamSpi.class); I think this one could be a better approach. ------------- PR: https://git.openjdk.org/jdk/pull/11379 From aturbanov at openjdk.org Tue Nov 29 07:39:18 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 29 Nov 2022 07:39:18 GMT Subject: RFR: 8297750: Unnecessary Vector usage in IIORegistry In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 20:01:31 GMT, Sergey Bylokhov wrote: >> src/java.desktop/share/classes/javax/imageio/spi/IIORegistry.java line 89: >> >>> 87: * categories (superinterfaces) to be used in the constructor. >>> 88: */ >>> 89: private static final ArrayList> initialCategories = new ArrayList<>(5); >> >> Should this be an immutable list and remove the static block? >> >> Suggestion: >> >> private static final List> initialCategories = List.of( >> ImageReaderSpi.class, >> ImageWriterSpi.class, >> ImageTranscoderSpi.class, >> ImageInputStreamSpi.class, >> ImageOutputStreamSpi.class); > > I think this one could be a better approach. Applied ------------- PR: https://git.openjdk.org/jdk/pull/11379 From kizune at openjdk.org Tue Nov 29 07:40:23 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 29 Nov 2022 07:40:23 GMT Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication of keyboard focus Message-ID: Set the text caret to be visible but not blinking on the non-editable text area. ------------- Commit messages: - 4512626: Non-editable JTextArea provides no visual indication of keyboard focus Changes: https://git.openjdk.org/jdk/pull/11408/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11408&range=00 Issue: https://bugs.openjdk.org/browse/JDK-4512626 Stats: 13 lines in 1 file changed: 11 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11408.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11408/head:pull/11408 PR: https://git.openjdk.org/jdk/pull/11408 From xuelei at openjdk.org Tue Nov 29 07:57:36 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 29 Nov 2022 07:57:36 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v17] In-Reply-To: References: Message-ID: > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: comment for snprintf_checked ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11115/files - new: https://git.openjdk.org/jdk/pull/11115/files/d1a48254..c7dd001b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=15-16 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11115.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11115/head:pull/11115 PR: https://git.openjdk.org/jdk/pull/11115 From xuelei at openjdk.org Tue Nov 29 08:01:11 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 29 Nov 2022 08:01:11 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v12] In-Reply-To: References: Message-ID: On Sun, 27 Nov 2022 07:57:46 GMT, Thomas Stuefe wrote: > Given all the near-duplicated checking of os::snprintf results, I think there is a place for a helper function to package this up. Thank you for the suggestion. Updated to use snprintf_checked. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From xuelei at openjdk.org Tue Nov 29 08:04:55 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 29 Nov 2022 08:04:55 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v12] In-Reply-To: References: Message-ID: On Sun, 27 Nov 2022 07:57:46 GMT, Thomas Stuefe wrote: > How about renaming the existing os::snprintf to something like os::snprintf_unchecked, make os::snprintf the checked version, ... The name `snprintf` may implies the function in C. For that purpose, I may use a name different from`snprintf`, but I have no idea what it could be. ------------- PR: https://git.openjdk.org/jdk/pull/11115 From xuelei at openjdk.org Tue Nov 29 08:09:21 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 29 Nov 2022 08:09:21 GMT Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v17] In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 07:57:36 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> May I have this update reviewed? >> >> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure. The build could pass if warnings are disabled for codes that use sprintf method. For the long run, the sprintf could be replaced with snprintf. This patch is trying to check if snprintf could be used. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > comment for snprintf_checked Please review the last update, and hopefully we are close to an agreement. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11115 From psadhukhan at openjdk.org Tue Nov 29 09:07:01 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 29 Nov 2022 09:07:01 GMT Subject: RFR: 8296660: Swing HTML table with omitted closing tags misparsed [v2] In-Reply-To: <8QRoaTYNsQAZoB6Kcj1Duyk1dxtcvDiGz5HR0-7TEIA=.0dcf5cc8-5b92-40bf-ab57-670a1e020f62@github.com> References: <8QRoaTYNsQAZoB6Kcj1Duyk1dxtcvDiGz5HR0-7TEIA=.0dcf5cc8-5b92-40bf-ab57-670a1e020f62@github.com> Message-ID: > This is in continuation with https://github.com/openjdk/jdk/commit/7133fc93e168f3671d048b2ae654f84ec289b98d fix done for [JDK-7172359](https://bugs.openjdk.org/browse/JDK-7172359) issue where fix was done to rectify invalid tag causing StackOverflowError but it caused alignment issue if the closing tags are optional, so the fix is modified to check for optional closing tag in which case dont return false for legalElementContext() > > JDK-7172359 fix and other CI regression tests are fine. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Set test frame size ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11355/files - new: https://git.openjdk.org/jdk/pull/11355/files/d92e446b..d075a9ba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11355&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11355&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11355.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11355/head:pull/11355 PR: https://git.openjdk.org/jdk/pull/11355 From duke at openjdk.org Tue Nov 29 09:25:31 2022 From: duke at openjdk.org (ravi gupta) Date: Tue, 29 Nov 2022 09:25:31 GMT Subject: RFR: 8297489: Write a test to verify the content change of TextField sends TextEvent [v3] In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 06:10:20 GMT, ravi gupta wrote: >> This testcase Verify the content changes of a TextField for the following assertions. >> >> a. TextListener get invoked when the content of a TextField gets changed. >> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8297489: Review fixes i am combining the tests https://github.com/openjdk/jdk/pull/11052: TextField with TextArea ([JDK-8296632](https://bugs.openjdk.org/browse/JDK-8296632)) so that it runs twice for both components. ------------- PR: https://git.openjdk.org/jdk/pull/11326 From duke at openjdk.org Tue Nov 29 09:25:34 2022 From: duke at openjdk.org (ravi gupta) Date: Tue, 29 Nov 2022 09:25:34 GMT Subject: Withdrawn: 8297489: Write a test to verify the content change of TextField sends TextEvent In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 15:15:32 GMT, ravi gupta wrote: > This testcase Verify the content changes of a TextField for the following assertions. > > a. TextListener get invoked when the content of a TextField gets changed. > b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. > > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/11326 From alexsch at openjdk.org Tue Nov 29 10:36:32 2022 From: alexsch at openjdk.org (Alexander Scherbatiy) Date: Tue, 29 Nov 2022 10:36:32 GMT Subject: RFR: 8295737: macOS: Print content cut off when width > height with portrait orientation [v4] In-Reply-To: References: Message-ID: > A printed content is truncated on macOS if the content paper size width larger than height with portrait orientation or width is less than height with landscape orientation. > > To reproduce the issue run the [CutOffImage](https://bugs.openjdk.org/secure/attachment/101145/CutOffImage.java) sample on MacOS. > > Four rectangles are printed: > 1. size 300x100, portrait orientation > 2. size 300x100, landscape orientation > 3. size 100x300, portrait orientation > 4. size 100x300, landscape orientation > > The first and fourth rectangles are truncated: [cut off content](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf) > > The reason is that NSPrintInfo class does not allow to set paper size and orientation independently. > Setting paper size width large than height changes NSPrintInfo orientation to landscape. > Setting paper size width less than height changes NSPrintInfo orientation to portrait. > Updating NSPrintInfo orientation from landscape to portrait or from portrait to landscape swaps NSPrintInfo paper width and height. > > The Cocoa code that shows NSPrintInfo behavior: > > #import > > int main() > { > NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; > NSApp = [NSApplication sharedApplication]; > > #ifdef __MAC_10_9 // code for SDK 10.9 or newer > #define NS_PORTRAIT NSPaperOrientationPortrait > #define NS_LANDSCAPE NSPaperOrientationLandscape > #else // code for SDK 10.8 or older > #define NS_PORTRAIT NSPortraitOrientation > #define NS_LANDSCAPE NSLandscapeOrientation > #endif > > printf("NS_PORTRAIT: %d\n", NS_PORTRAIT); > printf("NS_LANDSCAPE: %d\n", NS_LANDSCAPE); > > printf("create default print info\n"); > NSPrintInfo* defaultPrintInfo = [[NSPrintInfo sharedPrintInfo] copy]; > NSSize size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > printf("call setUpPrintOperationDefaultValues\n"); > [defaultPrintInfo setUpPrintOperationDefaultValues]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > double w = 300.0; > double h = 100.0; > printf("set size: [%f, %f]\n", w, h); > [defaultPrintInfo setPaperSize:NSMakeSize(w, h)]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > printf("Set NS_PORTRAIT orientation\n"); > [defaultPrintInfo setOrientation: NS_PORTRAIT]; > size = [defaultPrintInfo paperSize]; > printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); > > [NSApp run]; > > [NSApp release]; > [pool release]; > return(EXIT_SUCCESS); > } > > > On macOS Mojave 10.14.5 it prints: > > > NS_PORTRAIT: 0 > NS_LANDSCAPE: 1 > create default print info > orientation: 0, paper size: [612.000000, 792.000000] > call setUpPrintOperationDefaultValues > orientation: 0, paper size: [612.000000, 792.000000] > set size: [300.000000, 100.000000] > orientation: 1, paper size: [300.000000, 100.000000] // orientation flip > Set NS_PORTRAIT orientation > orientation: 0, paper size: [100.000000, 300.000000] // size flip > ``` > > There are four possible cases for printing a rectangle with different size and orientation: > 1. Input: paper size: (w > h), orientation portrait > [dstPrintInfo setPaperSize: NSMakeSize(w, h)] // size: (w, h), orientation: landscape > [dstPrintInfo setOrientation: NS_PORTRAIT] // size: (h, w), orientation: portrait > Note: width and height are swapped > 2. Input: paper size: (w > h), orientation landscape > [dstPrintInfo setPaperSize: NSMakeSize(h, w)] // size: (h, w), orientation: portrait > [dstPrintInfo setOrientation: NS_LANDSCAPE] // size: (w, h), orientation: landscape > 3. Input: paper size: (w < h), orientation portrait > [dstPrintInfo setPaperSize: NSMakeSize(w, h)] // size: (w, h), orientation: portrait > [dstPrintInfo setOrientation: NS_PORTRAIT] // size: (w, h), orientation: portrait > 4. Input: paper size: (w < h), orientation landscape > [dstPrintInfo setPaperSize: NSMakeSize(h, w)] // size: (h, w), orientation: landscape > [dstPrintInfo setOrientation: NS_LANDSCAPE] // size: (h, w), orientation: landscape > Note: width and height are swapped > > Only for cases 1 and 4 the final width and height are swapped. > The proposed fix enlarges height for cases 1 and 4 to not cut the printed rectangle. > > It is not full fix which draws rectangles for cases 1 and 4 in the requested size. > Setting requested size leads that subsequent orientation flips width and height. > The fix only enlarges the truncated area in height direction. The enlarged area in width is preserved as before the fix. > > Printed rectangles before and after the fix: > 1. size 300x100, portrait orientation: [before-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101157/before-fix-1.pdf), [after-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101162/after-fix-1.pdf) > 2. size 300x100, landscape orientation: [before-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101156/before-fix-2.pdf), [after-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101161/after-fix-2.pdf) > 3. size 100x300, portrait orientation: [before-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101155/before-fix-3.pdf), [after-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101160/after-fix-3.pdf) > 4. size 100x300, landscape orientation: [before-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101154/before-fix-4.pdf), [after-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101159/after-fix-4.pdf) > > All four rectangles: [before-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf), [after-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101158/after-fix-all.pdf) Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: Fix typos in FlipPageFormat class comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10808/files - new: https://git.openjdk.org/jdk/pull/10808/files/e5d01404..261a15fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10808&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10808&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10808.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10808/head:pull/10808 PR: https://git.openjdk.org/jdk/pull/10808 From smandalika at openjdk.org Tue Nov 29 10:38:13 2022 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Tue, 29 Nov 2022 10:38:13 GMT Subject: RFR: 8297481: Create a regression test for JDK-4424517 In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 08:57:23 GMT, Srinivas Mandalika wrote: > 8297481: Create a regression test for JDK-4424517 Any volunteers for sponsoring this PR ? ------------- PR: https://git.openjdk.org/jdk/pull/11313 From smandalika at openjdk.org Tue Nov 29 10:38:42 2022 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Tue, 29 Nov 2022 10:38:42 GMT Subject: RFR: 8295707: Create a regression test for JDK-7184401 [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 07:28:02 GMT, Srinivas Mandalika wrote: >> 8295707: Create a regression test for JDK-7184401 >> >> JDK-7184401 - JDk7u6 : Missing main menu bar in Netbeans after fix for 7162144 >> Above bug got introduced due to a fix for [JDK-7162144](https://bugs.openjdk.java.net/browse/JDK-7162144). >> The issue was observed on the netbeans UI. >> The test below recreates a standalone test to mimic the failure reported in Netbeans in [JDK-7184401](https://bugs.openjdk.java.net/browse/JDK-7184401) and verifies that it is working as expected after it got fixed via [JDK-7189350](https://bugs.openjdk.java.net/browse/JDK-7189350)) >> >> The Test attempts to reproduce specific behavior of NetBeans at the certain toolbar creation stage. Widgets are created on EDT; Another code posts some events to them on EDT; From another thread some code calls explicitly edt.interrupt(). >> Before this got fixed, events from a second code got lost. >> >> This review is for migrating tests from a closed test suite to open. >> Testing: >> 1.Tested the code on jdk7u6 to reproduce the issue - the UI hangs when run on this build. >> 2. Tested the code on jdk7u361 b01 to validate the fix - the test passed. >> 3.Mach5 Testing(40 times per platform) in macos x64, linux x64 and windows x64 - the .results are clean > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Fixed Review Comments: Removed redundant code Any volunteers for reviewing this PR ? ------------- PR: https://git.openjdk.org/jdk/pull/10784 From alexsch at openjdk.org Tue Nov 29 11:19:59 2022 From: alexsch at openjdk.org (Alexander Scherbatiy) Date: Tue, 29 Nov 2022 11:19:59 GMT Subject: RFR: 8295737: macOS: Print content cut off when width > height with portrait orientation [v4] In-Reply-To: References: Message-ID: <47LQpQGxZf-QD_1umGWDEmdZhDGHGvWJuTk6fy7ePbs=.ecac3a91-f38d-4fb2-91d1-e404a97126a6@github.com> On Tue, 29 Nov 2022 10:36:32 GMT, Alexander Scherbatiy wrote: >> A printed content is truncated on macOS if the content paper size width larger than height with portrait orientation or width is less than height with landscape orientation. >> >> To reproduce the issue run the [CutOffImage](https://bugs.openjdk.org/secure/attachment/101145/CutOffImage.java) sample on MacOS. >> >> Four rectangles are printed: >> 1. size 300x100, portrait orientation >> 2. size 300x100, landscape orientation >> 3. size 100x300, portrait orientation >> 4. size 100x300, landscape orientation >> >> The first and fourth rectangles are truncated: [cut off content](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf) >> >> The reason is that NSPrintInfo class does not allow to set paper size and orientation independently. >> Setting paper size width large than height changes NSPrintInfo orientation to landscape. >> Setting paper size width less than height changes NSPrintInfo orientation to portrait. >> Updating NSPrintInfo orientation from landscape to portrait or from portrait to landscape swaps NSPrintInfo paper width and height. >> >> The Cocoa code that shows NSPrintInfo behavior: >> >> #import >> >> int main() >> { >> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; >> NSApp = [NSApplication sharedApplication]; >> >> #ifdef __MAC_10_9 // code for SDK 10.9 or newer >> #define NS_PORTRAIT NSPaperOrientationPortrait >> #define NS_LANDSCAPE NSPaperOrientationLandscape >> #else // code for SDK 10.8 or older >> #define NS_PORTRAIT NSPortraitOrientation >> #define NS_LANDSCAPE NSLandscapeOrientation >> #endif >> >> printf("NS_PORTRAIT: %d\n", NS_PORTRAIT); >> printf("NS_LANDSCAPE: %d\n", NS_LANDSCAPE); >> >> printf("create default print info\n"); >> NSPrintInfo* defaultPrintInfo = [[NSPrintInfo sharedPrintInfo] copy]; >> NSSize size = [defaultPrintInfo paperSize]; >> printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); >> >> printf("call setUpPrintOperationDefaultValues\n"); >> [defaultPrintInfo setUpPrintOperationDefaultValues]; >> size = [defaultPrintInfo paperSize]; >> printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); >> >> double w = 300.0; >> double h = 100.0; >> printf("set size: [%f, %f]\n", w, h); >> [defaultPrintInfo setPaperSize:NSMakeSize(w, h)]; >> size = [defaultPrintInfo paperSize]; >> printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); >> >> printf("Set NS_PORTRAIT orientation\n"); >> [defaultPrintInfo setOrientation: NS_PORTRAIT]; >> size = [defaultPrintInfo paperSize]; >> printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height); >> >> [NSApp run]; >> >> [NSApp release]; >> [pool release]; >> return(EXIT_SUCCESS); >> } >> >> >> On macOS Mojave 10.14.5 it prints: >> >> >> NS_PORTRAIT: 0 >> NS_LANDSCAPE: 1 >> create default print info >> orientation: 0, paper size: [612.000000, 792.000000] >> call setUpPrintOperationDefaultValues >> orientation: 0, paper size: [612.000000, 792.000000] >> set size: [300.000000, 100.000000] >> orientation: 1, paper size: [300.000000, 100.000000] // orientation flip >> Set NS_PORTRAIT orientation >> orientation: 0, paper size: [100.000000, 300.000000] // size flip >> ``` >> >> There are four possible cases for printing a rectangle with different size and orientation: >> 1. Input: paper size: (w > h), orientation portrait >> [dstPrintInfo setPaperSize: NSMakeSize(w, h)] // size: (w, h), orientation: landscape >> [dstPrintInfo setOrientation: NS_PORTRAIT] // size: (h, w), orientation: portrait >> Note: width and height are swapped >> 2. Input: paper size: (w > h), orientation landscape >> [dstPrintInfo setPaperSize: NSMakeSize(h, w)] // size: (h, w), orientation: portrait >> [dstPrintInfo setOrientation: NS_LANDSCAPE] // size: (w, h), orientation: landscape >> 3. Input: paper size: (w < h), orientation portrait >> [dstPrintInfo setPaperSize: NSMakeSize(w, h)] // size: (w, h), orientation: portrait >> [dstPrintInfo setOrientation: NS_PORTRAIT] // size: (w, h), orientation: portrait >> 4. Input: paper size: (w < h), orientation landscape >> [dstPrintInfo setPaperSize: NSMakeSize(h, w)] // size: (h, w), orientation: landscape >> [dstPrintInfo setOrientation: NS_LANDSCAPE] // size: (h, w), orientation: landscape >> Note: width and height are swapped >> >> Only for cases 1 and 4 the final width and height are swapped. >> The proposed fix enlarges height for cases 1 and 4 to not cut the printed rectangle. >> >> It is not full fix which draws rectangles for cases 1 and 4 in the requested size. >> Setting requested size leads that subsequent orientation flips width and height. >> The fix only enlarges the truncated area in height direction. The enlarged area in width is preserved as before the fix. >> >> Printed rectangles before and after the fix: >> 1. size 300x100, portrait orientation: [before-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101157/before-fix-1.pdf), [after-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101162/after-fix-1.pdf) >> 2. size 300x100, landscape orientation: [before-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101156/before-fix-2.pdf), [after-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101161/after-fix-2.pdf) >> 3. size 100x300, portrait orientation: [before-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101155/before-fix-3.pdf), [after-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101160/after-fix-3.pdf) >> 4. size 100x300, landscape orientation: [before-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101154/before-fix-4.pdf), [after-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101159/after-fix-4.pdf) >> >> All four rectangles: [before-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf), [after-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101158/after-fix-all.pdf) > > Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos in FlipPageFormat class comments Could you review the updated fix? I updated the sample which prints 4 rectangles: [PrintArrowPaperA5](https://bugs.openjdk.org/secure/attachment/101839/PrintArrowPaperA5.java). The main difference with the previous sample [CutOffImage](https://bugs.openjdk.org/secure/attachment/101145/CutOffImage.java) is that the image generation is based on the provided PageFormat class passed to the `Printable.print(Graphics graphics, PageFormat pageFormat, int index)` method: ``` private static void paintImage(Graphics2D g, PageFormat page, int pageIndex) { BufferedImage img = createImage((int) page.getWidth(), (int) page.getHeight(), page.getOrientation(), pageIndex); g.drawImage(img, 0, 0, null); } private static class TestPrintable implements Printable { @Override public int print(Graphics graphics, PageFormat pageFormat, int index) { paintImage((Graphics2D) graphics, pageFormat, index); return PAGE_EXISTS; } } ``` PrintArrowPaperA5 sample uses A5 paper size which allows to test it with real printer where A5 paper could be palced horizontally or vertically in the paper tray. PrintArrowPaperA5 sample prints four rectangles 1. size 5.8 ? 8.3 inches (width < height), portrait orientation 2. size 5.8 ? 8.3 inches (width < height), landscape orientation 3. size 8.3 ? 5.8 inches (width > height), portrait orientation 4. size 8.3 ? 5.8 inches (width > height), landscape orientation jdk 19 only correctly prints rectangles 1 and 2 (width < height) on macOS: [print-arrow-paper-a5-macos-jdk19.pdf](https://bugs.openjdk.org/secure/attachment/101840/print-arrow-paper-a5-macos-jdk19.pdf) Rectangles 3 and 4 (width > height) are truncated. MacOS NSPrintInfo class has one to one correspondence between a paper size and its orientation: a. (w < h) <-> portrait b. (w > h) <-> landscape The proposed fix adds FlipPageFormat class which is intermediate between PageFormat and NSPrintInfo and is created only if PageFormat contains a paper with width greater than height. FlipPageFormat establish the following relations: 3. PageFormat: (width > height), portrait orientation -> FlipPageFormat: (width < height), landscape orientation -> NSPrintInfo: (width > height) (landscape orientation) 4. PageFormat: (width > height), landscape orientation -> FlipPageFormat: (width < height), portrait orientation -> NSPrintInfo: (width < height) (portrait orientation) FlipPageFormat preserves the original PageFormat class to pass it to a user defined `Printable.print(Graphics, PageFormat, int)` method. `PageFormat pageFormat = pageable.getPageFormat(pageIndex);` line is changed to `PageFormat pageFormat = getPageFormat(pageIndex);` in the method `getPageformatPrintablePeekgraphics(final int pageIndex)` to uniformly get FlipPageFormat class from `private PageFormat getPageFormat(int pageIndex)` method. With the fix PrintArrowPaperA5 sample prints pages with paper width greater than height without truncation on macOS: [print-arrow-paper-a5-macos-jdk-fix.pdf](https://bugs.openjdk.org/secure/attachment/101841/print-arrow-paper-a5-macos-jdk-fix.pdf). ------------- PR: https://git.openjdk.org/jdk/pull/10808 From aivanov at openjdk.org Tue Nov 29 15:53:19 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 29 Nov 2022 15:53:19 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: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com> <2zfcztLetGhtzMiWWeHBKP07uGk3EMCa7qkT5VHdPb0=.0af6f4b4-185c-4fa0-9631-9287135e0519@github.com> Message-ID: <4jD31X3u-J_7_99mZ5wYBpBiSziJlRB_yU73z8sqCdE=.2743d998-5645-4fa7-8841-5c2096afb166@github.com> On Tue, 29 Nov 2022 04:48:28 GMT, Tejesh R wrote: > > Where are we at with making a diagnostic update to this code and the failing test(s) ? > > It looks like the imageIcon were not loaded for _downloads_ folder, which might be the cause for `retVal` getting null value instead of ImageIcon. Mach5 tests link attached in JBS. Is there a reason why getting the icon for _Downloads_ folder fails? ------------- PR: https://git.openjdk.org/jdk/pull/11104 From aivanov at openjdk.org Tue Nov 29 16:12:34 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 29 Nov 2022 16:12:34 GMT Subject: RFR: 8296275: Write a test to verify setAccelerator method of JMenuItem [v6] In-Reply-To: References: <0_veOj93RinkoRa88OGVTz0PwHqfGraC22d_a8DtHTA=.9355db38-d18e-462b-a5e5-6e19d728f2bf@github.com> Message-ID: On Mon, 21 Nov 2022 05:20:29 GMT, Naveen Narayanan wrote: >> This testcase will >> 1) Verify setAccelerator method of JMenuitem. >> 2) Check that the selection of a menu item in the menu bar will generate action by a key combination of META+M. >> >> Testing: >> Tested using Mach5(20 times per platform) in Mac OS, Linux and Windows and got all pass. > > Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: > > 8296275: Review comments fixed. I have to repeat a more serious problem: > Since the test has nothing to do with `Desktop` class it should be moved to `JMenuItem` folder because it tests functionality of `JMenuItem`. If it's supposed to test the Swing support for macOS global, then the test should do it. Could you please clarify? If it's for regular `JMenu` and `JMenuItem`, move the test; if it's for the global, then modify the test accordingly. test/jdk/java/awt/Desktop/JMenuItemSetAcceleratorTest.java line 48: > 46: private static JFrame frame; > 47: private static final CountDownLatch actionLatch = new CountDownLatch(1); > 48: private static Robot robot; My IDE issues a warning, the `robot` field can be converted to local variable. Indeed, it isn't used outside of `main`. ------------- Changes requested by aivanov (Reviewer). PR: https://git.openjdk.org/jdk/pull/11035 From tr at openjdk.org Tue Nov 29 16:59:33 2022 From: tr at openjdk.org (Tejesh R) Date: Tue, 29 Nov 2022 16:59:33 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: <4jD31X3u-J_7_99mZ5wYBpBiSziJlRB_yU73z8sqCdE=.2743d998-5645-4fa7-8841-5c2096afb166@github.com> References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com> <2zfcztLetGhtzMiWWeHBKP07uGk3EMCa7qkT5VHdPb0=.0af6f4b4-185c-4fa0-9631-9287135e0519@github.com> <4jD31X3u-J_7_99mZ5wYBpBiSziJlRB_yU73z8sqCdE=.2743d998-5645-4fa7-8841-5c2096afb166@github.com> Message-ID: <_m3nDcGpbA8Fkm8ZzY5p39cDKCG5aLIQ6IS48JNySLs=.8a772782-ade9-42db-ad8c-1a5e5b0ce43f@github.com> On Tue, 29 Nov 2022 15:51:04 GMT, Alexey Ivanov wrote: > > > Where are we at with making a diagnostic update to this code and the failing test(s) ? > > > > > > It looks like the imageIcon were not loaded for _downloads_ folder, which might be the cause for `retVal` getting null value instead of ImageIcon. Mach5 tests link attached in JBS. > > Is there a reason why getting the icon for _Downloads_ folder fails? Don't know as the failure is intermittent. ------------- PR: https://git.openjdk.org/jdk/pull/11104 From prr at openjdk.org Tue Nov 29 17:25:24 2022 From: prr at openjdk.org (Phil Race) Date: Tue, 29 Nov 2022 17:25:24 GMT Subject: RFR: 8297750: Unnecessary Vector usage in IIORegistry In-Reply-To: References: Message-ID: On Sun, 27 Nov 2022 17:51:15 GMT, Andrey Turbanov wrote: > Field `javax.imageio.spi.IIORegistry#initialCategories` is modified only in `static {}` block, which makes it effectively final. Instead of legacy synchronized `Vector` we can use non-threadsafe `ArrayList` here. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11379 From prr at openjdk.org Tue Nov 29 18:08:14 2022 From: prr at openjdk.org (Phil Race) Date: Tue, 29 Nov 2022 18:08:14 GMT Subject: RFR: 8297681: Unnecessary color conversion during 4BYTE_ABGR_PRE to INT_ARGB_PRE blit In-Reply-To: <6i0_xf7jDRAnSDYgpij2L4JE2mDa4tOJ1j6okhbxEho=.2595083c-c1c6-44c2-8aef-10e317aaa2ae@github.com> References: <6i0_xf7jDRAnSDYgpij2L4JE2mDa4tOJ1j6okhbxEho=.2595083c-c1c6-44c2-8aef-10e317aaa2ae@github.com> Message-ID: <7HwljxyHGn0-J2qzyAXWOLseMaJypixadxczYd1PZq8=.6e401f64-76fc-4699-b65e-b8fd69248bcb@github.com> On Sun, 27 Nov 2022 06:26:48 GMT, Sergey Bylokhov wrote: > I have found that drawing the BufferedImage.4BYTE_ABGR_PRE to the INT_ARGB_PRE image caused java2d to do an additional conversion from/to ARGB format. That conversion is done via a native [loop](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/share/native/libawt/java2d/loops/AlphaMath.c#L32) which tries to approximate the math, it is better to skip such conversion. > > An additional benefit is ~x2 performance improvements of this blit, so it will have the same performance as the opposite INT_ARGB_PRE to 4BYTE_ABGR_PRE blit. > > > global.dest=BufImg(IntArgbPre),graphics.imaging.src=4ByteAbgrPre > translucent,graphics.opts.alpharule=Src,graphics.opts.sizes=100: > fix: 286439.77665 (var=3.42%) (100.0%) > ***********************************************************| > ***********************************************************| > ********************************************************** | > base: 167280.80808 (var=1.8%) (58.4%) > ********************************** | > ********************************** | > ********************************** | > > global.dest=BufImg(IntArgbPre),graphics.imaging.src=4ByteAbgrPre > translucent,graphics.opts.alpharule=SrcOver,graphics.opts.sizes=100: > fix: 325989.80002 (var=1.58%) (100.0%) > *********************************************************** | > ************************************************************| > ************************************************************| > base: 200830.44521 (var=1.58%) (61.61%) > ************************************* | > ************************************* | > ************************************* | > > > To implement direct 4BYTE_ABGR_PRE to INT_ARGB_PRE blit it is necessary to "declare" and "register" blit only, all other macros are already in place. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11376 From prr at openjdk.org Tue Nov 29 18:23:23 2022 From: prr at openjdk.org (Phil Race) Date: Tue, 29 Nov 2022 18:23:23 GMT Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication of keyboard focus In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 07:30:32 GMT, Alexander Zuev wrote: > Set the text caret to be visible but not blinking on the non-editable text area. Hmm. This is a pretty broad change. It applies to any Swing component that accepts a caret as far as I can tell, and is broader than A11Y, so I worry about unexpected consequences. What is the situation today for a JTextField - and other such components ? Why was the bug report mentioning only JTextArea ? What happens for AWT heavyweights ? Does Windows display a caret even if they aren't editable ? Why is a non-editable Text Area really any different than a JLabel ?? Surely that can't get focus ? I guess I am surprised that that a non-editable component should have focus at all .. so what other components accept focus even if they aren't "active" ? ------------- PR: https://git.openjdk.org/jdk/pull/11408 From prr at openjdk.org Tue Nov 29 18:26:21 2022 From: prr at openjdk.org (Phil Race) Date: Tue, 29 Nov 2022 18:26:21 GMT Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication of keyboard focus In-Reply-To: References: Message-ID: <9F0T8I0zmxGW518FOgH0VWVk9Y9G4sBG5BeZRF985Zg=.1a6188a4-0486-4485-a3a3-6b96d6b546aa@github.com> On Tue, 29 Nov 2022 07:30:32 GMT, Alexander Zuev wrote: > Set the text caret to be visible but not blinking on the non-editable text area. src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java line 386: > 384: setBlinkRate(savedBlinkRate); > 385: savedBlinkRate = 0; > 386: } My general questions need to be addressed first, but after we get past that you need to revisit this code. It seems to overlook that an application could change the blink rate itself, and restores the saved rate over what the application has set. Also, SFAICT setBlinkRate() doesn't seem to be preventing negative values ... ------------- PR: https://git.openjdk.org/jdk/pull/11408 From aivanov at openjdk.org Tue Nov 29 18:41:34 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 29 Nov 2022 18:41:34 GMT Subject: RFR: 8297489: Write a test to verify the content change of TextField sends TextEvent [v3] In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 06:10:20 GMT, ravi gupta wrote: >> This testcase Verify the content changes of a TextField for the following assertions. >> >> a. TextListener get invoked when the content of a TextField gets changed. >> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8297489: Review fixes > i am combining the tests #11052: TextField with TextArea ([JDK-8296632](https://bugs.openjdk.org/browse/JDK-8296632)) so that it runs twice for both components. You can do this under this PR. Eventually, you're adding another test case to an existing one. ------------- PR: https://git.openjdk.org/jdk/pull/11326 From aivanov at openjdk.org Tue Nov 29 19:14:27 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 29 Nov 2022 19:14:27 GMT Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0, Integer.MAX_VALUE) fails [v10] In-Reply-To: References: Message-ID: On Mon, 31 Oct 2022 08:59:31 GMT, Prasanta Sadhukhan wrote: >> DefaultListSelectionModel.removeIndexInterva accepts `int` value which allows it to take in Integer.MAX_VALUE theoratically but it does calculation with that value which can results in IOOBE. >> Fix is to make sure the calculation stays within bounds. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Review fix Let's keep it open. CSR review has stalled. ------------- PR: https://git.openjdk.org/jdk/pull/10409 From ihse at openjdk.org Tue Nov 29 19:26:36 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 29 Nov 2022 19:26:36 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). >> >> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Remove check for .properties from jcheck" > > This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2. > - Change trailing space and tab in values to unicode encoding Yes bot, I know. I'll need to split this up into multiple steps, but please keep this open for a while more. Thank you. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From honkar at openjdk.org Tue Nov 29 20:05:49 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 29 Nov 2022 20:05:49 GMT Subject: RFR: JDK-8297449: Update JInternalFrame Metal Border code [v3] In-Reply-To: References: Message-ID: > Updated Metal Border code for JInternalFrame. > > - Added instanceof check before casting Graphics to G2D. > - Replaced roundHalfDown with Region.clipRound() Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: added scaleFactor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11305/files - new: https://git.openjdk.org/jdk/pull/11305/files/5f019dfd..a3afba44 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11305&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11305&range=01-02 Stats: 9 lines in 1 file changed: 4 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11305.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11305/head:pull/11305 PR: https://git.openjdk.org/jdk/pull/11305 From honkar at openjdk.org Tue Nov 29 20:17:01 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 29 Nov 2022 20:17:01 GMT Subject: RFR: JDK-8297449: Update JInternalFrame Metal Border code [v2] In-Reply-To: References: <7Ww09yzcYB0E2d8c85iZkhjhouSxN80dC961Uxh2kak=.6a6c887d-9ab8-428a-9bac-10e9fcbd56af@github.com> Message-ID: On Tue, 29 Nov 2022 02:12:28 GMT, SWinxy wrote: >> @SWinxy Thanks for catching it. That's right, but the scale factor cannot be zero, it should probably be handled similar to `stkWidth` if **'at is null'** (at is null when g is not an instance of Graphics2D). I'll need to check the scale value to be used in this context. >> >> Something like below. >> `at != null ? at.getScaleX() : 1;` > > Oh I see. Otherwise the thickness would be zero. I feeeeel like doing a large if-else on checking if g is a Graphics2D would end up being cleaner. I fiddled around and this is what the else branch would look like with the affine transform value being `1`: > > g.translate(x, y); > g.setColor(background); > // Draw the bulk of the border > for (int i = 0; i < 5; i++) { > g.drawRect(i, i, w - (i * 2), h - (i * 2)); > } > if (c instanceof JInternalFrame internalFrame && internalFrame.isResizable()) { > // Draw the Long highlight lines > g.setColor(highlight); > g.drawLine(CORNER + 1, 2, w - CORNER, 2); //top > g.drawLine(2, CORNER + 1, 2, h - CORNER); //left > g.drawLine(w - 2, CORNER + 1, w - 2, h - CORNER); //right > g.drawLine(CORNER + 1, h - 2, w - CORNER, h - 2); //bottom > // Draw the Long shadow lines > g.setColor(shadow); > g.drawLine(CORNER, 1, w - CORNER - 1, 1); > g.drawLine(1, CORNER, 1, h - CORNER - 1); > g.drawLine(w - 3, CORNER, w - 3, h - CORNER - 1); > g.drawLine(CORNER, h - 3, w - CORNER - 1, h - 3); > } > // restore previous transform > g.translate(-x, -y); @SWinxy @aivanov-jdk Added a new local variable `scaleFactor` to avoid NPE issues (mentioned above) if AffineTransform (at) is not set. This variable is later used to scale the thickness and corners of the border (line 313 & 330). ------------- PR: https://git.openjdk.org/jdk/pull/11305 From aivanov at openjdk.org Tue Nov 29 20:35:27 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 29 Nov 2022 20:35:27 GMT Subject: RFR: JDK-8297449: Update JInternalFrame Metal Border code [v3] In-Reply-To: References: Message-ID: <5CTWprKMA7Rt10RfXzvk1XzJxfgn7sLHtJ_RcsIpT4M=.da912d96-a10a-4077-8d54-7dc55a3b9a00@github.com> On Tue, 29 Nov 2022 20:05:49 GMT, Harshitha Onkar wrote: >> Updated Metal Border code for JInternalFrame. >> >> - Added instanceof check before casting Graphics to G2D. >> - Replaced roundHalfDown with Region.clipRound() > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > added scaleFactor src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 277: > 275: at = g2d.getTransform(); > 276: scaleFactor = at.getScaleX(); > 277: oldColor = g2d.getColor(); Color wasn't preserved before [JDK-8015739](https://bugs.openjdk.org/browse/JDK-8015739). Getting and setting the color doesn't require `Graphics2D`, so, if it's to be preserved, it should be preserved outside of `instanceof`. ------------- PR: https://git.openjdk.org/jdk/pull/11305 From honkar at openjdk.org Tue Nov 29 21:42:02 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 29 Nov 2022 21:42:02 GMT Subject: RFR: JDK-8297449: Update JInternalFrame Metal Border code [v4] In-Reply-To: References: Message-ID: > Updated Metal Border code for JInternalFrame. > > - Added instanceof check before casting Graphics to G2D. > - Replaced roundHalfDown with Region.clipRound() Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: review changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11305/files - new: https://git.openjdk.org/jdk/pull/11305/files/a3afba44..b1e3557a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11305&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11305&range=02-03 Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11305.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11305/head:pull/11305 PR: https://git.openjdk.org/jdk/pull/11305 From honkar at openjdk.org Tue Nov 29 21:42:06 2022 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 29 Nov 2022 21:42:06 GMT Subject: RFR: JDK-8297449: Update JInternalFrame Metal Border code [v3] In-Reply-To: <5CTWprKMA7Rt10RfXzvk1XzJxfgn7sLHtJ_RcsIpT4M=.da912d96-a10a-4077-8d54-7dc55a3b9a00@github.com> References: <5CTWprKMA7Rt10RfXzvk1XzJxfgn7sLHtJ_RcsIpT4M=.da912d96-a10a-4077-8d54-7dc55a3b9a00@github.com> Message-ID: On Tue, 29 Nov 2022 20:21:25 GMT, Alexey Ivanov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> added scaleFactor > > src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 277: > >> 275: at = g2d.getTransform(); >> 276: scaleFactor = at.getScaleX(); >> 277: oldColor = g2d.getColor(); > > Color wasn't preserved before [JDK-8015739](https://bugs.openjdk.org/browse/JDK-8015739). > > Getting and setting the color doesn't require `Graphics2D`, so, if it's to be preserved, it should be preserved outside of `instanceof`. @aivanov-jdk Updated the code. Removed color preservation code to match previous code (before [JDK-8015739](https://bugs.openjdk.org/browse/JDK-8015739) changes). ------------- PR: https://git.openjdk.org/jdk/pull/11305 From azvegint at openjdk.org Tue Nov 29 21:45:21 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 29 Nov 2022 21:45:21 GMT Subject: RFR: 8271519: java/awt/event/SequencedEvent/MultipleContextsFunctionalTest.java failed with "Total [200] - Expected [400]" Message-ID: <-eww7dB2tL0Mg7Q57P8Ncfm9i84sEU3wkOvGH9QlOUY=.888b31b2-441b-4077-874c-bcba2caa611b@github.com> This test was trying to add windows to `ArrayList` instance from two different threads without any synchronization. So the reported test failure happens when the `WINDOWS` list contains only one windows instead of expected two. Another possible failure is: Exception in thread "AWT-EventQueue-1" java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 0 at java.base/java.util.ArrayList.add(ArrayList.java:455) at java.base/java.util.ArrayList.add(ArrayList.java:467) at MultipleContextsFunctionalTest$1$1.run(MultipleContextsFunctionalTest.java:107) at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714) at java.base/java.security.AccessController.doPrivileged(AccessController.java:400) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) Total [200] - Expected [400] Test FAILED The test fails in about 8 out of 100 runs in a cycle for me. Changing `ArrayList` to `CopyOnWriteArrayList` solves the issue. Didn't fail once after modification and 300 runs. ------------- Commit messages: - initial Changes: https://git.openjdk.org/jdk/pull/11423/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11423&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8271519 Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11423.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11423/head:pull/11423 PR: https://git.openjdk.org/jdk/pull/11423 From abhiscxk at openjdk.org Tue Nov 29 21:53:08 2022 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 29 Nov 2022 21:53:08 GMT Subject: Integrated: 8078471: Backspace does not work in JFileChooser with GTK L&F In-Reply-To: References: Message-ID: On Tue, 22 Nov 2022 15:51:09 GMT, Abhishek Kumar wrote: > The Backspace key doesn't lead to parent directory of current directory for JFileChooser in GTK LAF. > Added the lazy input value in `GTKLookandFeel` and fix is working fine. > > Implemented a manual test to check BackSpace behavior for all installed LAF in Linux platform. > The test mentioned in [JDK-8078471](https://bugs.openjdk.org/browse/JDK-8078471) `javax/swing/JFileChooser/4150029/bug4150029.html` also working fine with GTK option (-client -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel). This pull request has now been integrated. Changeset: 20844511 Author: Abhishek Kumar Committer: Phil Race URL: https://git.openjdk.org/jdk/commit/20844511939779649e1a51970edf29eb21f137e1 Stats: 183 lines in 3 files changed: 183 ins; 0 del; 0 mod 8078471: Backspace does not work in JFileChooser with GTK L&F Reviewed-by: psadhukhan, prr ------------- PR: https://git.openjdk.org/jdk/pull/11291 From pminborg at openjdk.org Tue Nov 29 21:55:32 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 29 Nov 2022 21:55:32 GMT Subject: Integrated: 8297210: Add a @sealedGraph tag to selected java.desktop classes In-Reply-To: <9JrgNVgMitVkUr_bsvGzpfCv56HYqvD6pRcPuMV8jts=.4f67596a-37d5-43f3-a353-bf1d276d61a5@github.com> References: <9JrgNVgMitVkUr_bsvGzpfCv56HYqvD6pRcPuMV8jts=.4f67596a-37d5-43f3-a353-bf1d276d61a5@github.com> Message-ID: On Thu, 17 Nov 2022 14:26:48 GMT, Per Minborg wrote: > This PR proposes to opt in for graphic rendering of the sealed hierarchy for some selected classes. > > Rendering capability was added via https://bugs.openjdk.org/browse/JDK-8295653 > > Here is how it would look like: > > MultipleGradientPaint_SH > > TextComponent_SH > > AppEvent_SH > > FilesEvent_SH > > InputEvent_SH > > Path2D_SH > > StyleConstants_SH This pull request has now been integrated. Changeset: f4063a3c Author: Per Minborg Committer: Phil Race URL: https://git.openjdk.org/jdk/commit/f4063a3cfd11442c1db79c0d474fe91241f9d453 Stats: 7 lines in 7 files changed: 7 ins; 0 del; 0 mod 8297210: Add a @sealedGraph tag to selected java.desktop classes Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/11212 From smandalika at openjdk.org Tue Nov 29 21:57:51 2022 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Tue, 29 Nov 2022 21:57:51 GMT Subject: Integrated: 8297481: Create a regression test for JDK-4424517 In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 08:57:23 GMT, Srinivas Mandalika wrote: > 8297481: Create a regression test for JDK-4424517 This pull request has now been integrated. Changeset: e2d71c0a Author: Srinivas Mandalika Committer: Phil Race URL: https://git.openjdk.org/jdk/commit/e2d71c0a0d654841e3e591beeaa04b44c6e6b37f Stats: 212 lines in 1 file changed: 212 ins; 0 del; 0 mod 8297481: Create a regression test for JDK-4424517 Reviewed-by: serb ------------- PR: https://git.openjdk.org/jdk/pull/11313 From serb at openjdk.org Tue Nov 29 22:12:22 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 29 Nov 2022 22:12:22 GMT Subject: RFR: 8271519: java/awt/event/SequencedEvent/MultipleContextsFunctionalTest.java failed with "Total [200] - Expected [400]" In-Reply-To: <-eww7dB2tL0Mg7Q57P8Ncfm9i84sEU3wkOvGH9QlOUY=.888b31b2-441b-4077-874c-bcba2caa611b@github.com> References: <-eww7dB2tL0Mg7Q57P8Ncfm9i84sEU3wkOvGH9QlOUY=.888b31b2-441b-4077-874c-bcba2caa611b@github.com> Message-ID: On Tue, 29 Nov 2022 21:36:31 GMT, Alexander Zvegintsev wrote: > This test was trying to add windows to `ArrayList` instance from two different threads without any synchronization. > > So the reported test failure happens when the `WINDOWS` list contains only one windows instead of expected two. > > Another possible failure is: > > Exception in thread "AWT-EventQueue-1" java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 0 > at java.base/java.util.ArrayList.add(ArrayList.java:455) > at java.base/java.util.ArrayList.add(ArrayList.java:467) > at MultipleContextsFunctionalTest$1$1.run(MultipleContextsFunctionalTest.java:107) > at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318) > at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773) > at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720) > at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714) > at java.base/java.security.AccessController.doPrivileged(AccessController.java:400) > at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87) > at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742) > at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) > at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) > at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) > at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) > at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) > Total [200] - Expected [400] > Test FAILED > > > The test fails in about 8 out of 100 runs in a cycle for me. > > Changing `ArrayList` to `CopyOnWriteArrayList` solves the issue. Didn't fail once after modification and 300 runs. Please double-check that an updated test can reproduce an initial bug: JDK-8204142. It might be possible that the contention of the list may change the behavior, in that case, we can split the list per thread. ------------- PR: https://git.openjdk.org/jdk/pull/11423 From azvegint at openjdk.org Tue Nov 29 22:15:26 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 29 Nov 2022 22:15:26 GMT Subject: RFR: 8271519: java/awt/event/SequencedEvent/MultipleContextsFunctionalTest.java failed with "Total [200] - Expected [400]" In-Reply-To: References: <-eww7dB2tL0Mg7Q57P8Ncfm9i84sEU3wkOvGH9QlOUY=.888b31b2-441b-4077-874c-bcba2caa611b@github.com> Message-ID: On Tue, 29 Nov 2022 22:09:47 GMT, Sergey Bylokhov wrote: > Please double-check that an updated test can reproduce an initial bug: JDK-8204142. It might be possible that the contention of the list may change the behavior, in that case, we can split the list per thread. I did, both unmodified and modified tests are failing with jdk11.0.1. ------------- PR: https://git.openjdk.org/jdk/pull/11423 From kizune at openjdk.org Tue Nov 29 22:24:35 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 29 Nov 2022 22:24:35 GMT Subject: RFR: 4512626: Non-editable JTextArea provides no visual indication of keyboard focus In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 18:19:34 GMT, Phil Race wrote: > Hmm. This is a pretty broad change. It applies to any Swing component that accepts a caret as far as I can tell, and is broader than A11Y, so I worry about unexpected consequences. What is the situation today for a JTextField - and other such components ? They are also affected in the same way. > Why was the bug report mentioning only JTextArea ? The bug was reported during the VPAT certification of the JCK suite. They use a lot of JTextArea for the testing instructions and looks like that is what caught attention of the A11Y office. Would they notice the JTextField issue they would've report that too. > What happens for AWT heavyweights? Same. They are affected by the issue too. > Does Windows display a caret even if they aren't editable ? You mean native Windows controls? I have to check it out - and not only on Windows. However that would not affect our A11Y certification. > Why is a non-editable Text Area really any different than a JLabel ?? Surely that can't get focus ? I guess I am surprised that that a non-editable component should have focus at all .. so what other components accept focus even if they aren't "active" ? Have to check other components but JLabel can not receive focus while non-editable JTextArea and JTextField can. Moreover - the caret is active, you can move it and when editable status changes the caret will be in a new position. If you move it with shift pressed - you can select text and with corresponding shortcuts you can copy that selected text to the clipboard. > My general questions need to be addressed first, but after we get past that you need to revisit this code. It seems to overlook that an application could change the blink rate itself, and restores the saved rate over what the application has set. Ok, the only way it can be a problem is when user will try to set the blink rate of the uneditable component's caret. I think i will have to special-case that. > Also, SFAICT setBlinkRate() doesn't seem to be preventing negative values ... I wonder what will happen if i set a negative rate. Will it blink into the past before component is even created? Can it cause a time paradox? Hmm. ------------- PR: https://git.openjdk.org/jdk/pull/11408 From prr at openjdk.org Tue Nov 29 23:04:31 2022 From: prr at openjdk.org (Phil Race) Date: Tue, 29 Nov 2022 23:04:31 GMT Subject: RFR: 8165943: LineBreakMeasurer does not measure correctly if TextAttribute.TRACKING is set. In-Reply-To: References: Message-ID: On Thu, 15 Sep 2022 16:51:27 GMT, Olga Mikhaltsova wrote: > This is a fix for LineBreakMeasurer. It takes into account the TextAttribute.TRACKING value (not eq 0) while calculating the line breaks. > > Tested on Linux x64, Windows x64, macOS x64 with the reproducer (LineBreakSample.java) attached to JDK-8165943 and the following group of tests: > `$JTREG_HOME/bin/jtreg -jdk:$BUILD_HOME ./test/jdk/java/awt/font` I'm sure an automated test is possible - it should be easy enough to adjust the tracking and verify the breaks are different. The code paths here don't do complex text. Tracking doesn't really work for things like Arabic .. but it would be good to verify that Arabic measures as it lays out with tracking - ignoring it I expect, but I could be surprised if there's something I am overlooking. Hence why a test of that would be good. ------------- PR: https://git.openjdk.org/jdk/pull/10289 From prr at openjdk.org Tue Nov 29 23:14:20 2022 From: prr at openjdk.org (Phil Race) Date: Tue, 29 Nov 2022 23:14:20 GMT Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and radio button with GTK LAF for bug4314194. [v4] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 04:53:50 GMT, Abhishek Kumar wrote: >> Existing test `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` was not showing colored text for disabled checkbox and radiobutton in GTK LAF. >> >> The fix is to get the disabled state color for checkbox and radiobutton from UIManager if it exists. >> >> Test case `open/test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java` has been checked in CI pipeline. Link is attached in JBS. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Used bitwise operator for condition check Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10755 From achung at openjdk.org Tue Nov 29 23:19:33 2022 From: achung at openjdk.org (Alisen Chung) Date: Tue, 29 Nov 2022 23:19:33 GMT Subject: RFR: 8297296: java/awt/Mouse/EnterExitEvents/DragWindowTest.java fails with "No MouseReleased event on label!" Message-ID: <4zWtZ0oJqrszfA0l_MDnXQBN-8CelPwANVOGSkc-KEU=.04ceefa4-7615-4714-9fa9-1815e90f9271@github.com> Test was run on mac, windows, linux 50 times and passed after change Before fix, test fails about once every 50 runs on linux and windows platforms ------------- Commit messages: - changed robot autodelay to 250 Changes: https://git.openjdk.org/jdk/pull/11425/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11425&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297296 Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11425.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11425/head:pull/11425 PR: https://git.openjdk.org/jdk/pull/11425 From serb at openjdk.org Tue Nov 29 23:55:26 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 29 Nov 2022 23:55:26 GMT Subject: RFR: 8271519: java/awt/event/SequencedEvent/MultipleContextsFunctionalTest.java failed with "Total [200] - Expected [400]" In-Reply-To: <-eww7dB2tL0Mg7Q57P8Ncfm9i84sEU3wkOvGH9QlOUY=.888b31b2-441b-4077-874c-bcba2caa611b@github.com> References: <-eww7dB2tL0Mg7Q57P8Ncfm9i84sEU3wkOvGH9QlOUY=.888b31b2-441b-4077-874c-bcba2caa611b@github.com> Message-ID: On Tue, 29 Nov 2022 21:36:31 GMT, Alexander Zvegintsev wrote: > This test was trying to add windows to `ArrayList` instance from two different threads without any synchronization. > > So the reported test failure happens when the `WINDOWS` list contains only one windows instead of expected two. > > Another possible failure is: > > Exception in thread "AWT-EventQueue-1" java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 0 > at java.base/java.util.ArrayList.add(ArrayList.java:455) > at java.base/java.util.ArrayList.add(ArrayList.java:467) > at MultipleContextsFunctionalTest$1$1.run(MultipleContextsFunctionalTest.java:107) > at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318) > at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773) > at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720) > at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714) > at java.base/java.security.AccessController.doPrivileged(AccessController.java:400) > at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87) > at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742) > at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) > at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) > at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) > at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) > at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) > Total [200] - Expected [400] > Test FAILED > > > The test fails in about 8 out of 100 runs in a cycle for me. > > Changing `ArrayList` to `CopyOnWriteArrayList` solves the issue. Didn't fail once after modification and 300 runs. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11423 From tnakamura at openjdk.org Wed Nov 30 00:04:22 2022 From: tnakamura at openjdk.org (Toshio Nakamura) Date: Wed, 30 Nov 2022 00:04:22 GMT Subject: RFR: 8295248: JEditorPane HTML form with multi-selection broke data after resetting [v3] In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 04:27:15 GMT, Phil Race wrote: >> Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed space > > Can you try again to describe the issue ? > The bug summary is misleading I'm sure. "Drawing" as in RENDERING is NOT broken. > I think you are trying to say something about expectations for what item(s) are selected .. > Perhaps what is missing is a PROPER explanation of what you think reset and submit should do and so forth. > And this looks like one of those "tiny" changes which are "completely harmless" but you have said NOTHING about what wider testing you've done on other cases. Fix one case != make things uniformly better .. @prrace Could you kindly check the updated descriptions? ------------- PR: https://git.openjdk.org/jdk/pull/10685 From serb at openjdk.org Wed Nov 30 01:04:11 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 30 Nov 2022 01:04:11 GMT Subject: Integrated: 8296905: Replace the native LCMS#getProfileID() method with the accessor In-Reply-To: References: Message-ID: On Sat, 12 Nov 2022 04:13:52 GMT, Sergey Bylokhov wrote: > The native method used to access the private method in the `ICC_Profile` class is replaced by the accessor. This pull request has now been integrated. Changeset: defe0607 Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/defe0607e3ccd703c8c71b6fc9591d436817d306 Stats: 78 lines in 5 files changed: 40 ins; 36 del; 2 mod 8296905: Replace the native LCMS#getProfileID() method with the accessor Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/11116 From serb at openjdk.org Wed Nov 30 03:26:15 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 30 Nov 2022 03:26:15 GMT Subject: Integrated: 8296878: Document Filter attached to JPasswordField and setText("") is not cleared instead inserted characters replaced with unicode null characters In-Reply-To: References: Message-ID: On Tue, 22 Nov 2022 03:15:55 GMT, Sergey Bylokhov wrote: > The usage of DocumentFilter in the JPasswordField is excluded from the [JDK-8258373](https://bugs.openjdk.org/browse/JDK-8258373). That will be responsibility of the application to cleanup the password if DocumentFilter is set. This pull request has now been integrated. Changeset: 87f00f4a Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/87f00f4a1bfb392be0684edcdfa0254caec4ca03 Stats: 94 lines in 2 files changed: 79 ins; 2 del; 13 mod 8296878: Document Filter attached to JPasswordField and setText("") is not cleared instead inserted characters replaced with unicode null characters Reviewed-by: prr, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/11281 From serb at openjdk.org Wed Nov 30 04:20:10 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 30 Nov 2022 04:20:10 GMT Subject: Integrated: 8297676: DataBuffer.TYPE_SHORT/TYPE_FLOAT/TYPE_DOUBLE are not placeholders In-Reply-To: References: Message-ID: On Sat, 26 Nov 2022 02:58:15 GMT, Sergey Bylokhov wrote: > The specification for the DataBuffer.TYPE_SHORT/TYPE_FLOAT/TYPE_DOUBLE mentioned that all of them are "Placeholder for future use" which is not true. > > They are used and it is possible to create the ComponentColorModel for each of this transferType. Also, there is a specific data buffer for each: [DataBufferFloat](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/DataBufferFloat.java#L67), [DataBufferDouble](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/DataBufferDouble.java#L67), and [DataBufferShort](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/DataBufferShort.java#L74). This pull request has now been integrated. Changeset: 37f613ba Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/37f613bad3b01b40d518de34630e1e6d63737a4c Stats: 10 lines in 1 file changed: 2 ins; 2 del; 6 mod 8297676: DataBuffer.TYPE_SHORT/TYPE_FLOAT/TYPE_DOUBLE are not placeholders Reviewed-by: azvegint, prr ------------- PR: https://git.openjdk.org/jdk/pull/11374 From serb at openjdk.org Wed Nov 30 07:29:22 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 30 Nov 2022 07:29:22 GMT Subject: RFR: 8297750: Unnecessary Vector usage in IIORegistry In-Reply-To: References: Message-ID: <7xzmV5AW00c4tWJkS4KxGIcx6G4-6RNAsBDRtdvDtL8=.81342362-d28d-4fa6-8689-ed851c3af634@github.com> On Sun, 27 Nov 2022 17:51:15 GMT, Andrey Turbanov wrote: > Field `javax.imageio.spi.IIORegistry#initialCategories` is modified only in `static {}` block, which makes it effectively final. Instead of legacy synchronized `Vector` we can use non-threadsafe `ArrayList` here. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11379 From serb at openjdk.org Wed Nov 30 07:32:33 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 30 Nov 2022 07:32:33 GMT Subject: Integrated: 8297681: Unnecessary color conversion during 4BYTE_ABGR_PRE to INT_ARGB_PRE blit In-Reply-To: <6i0_xf7jDRAnSDYgpij2L4JE2mDa4tOJ1j6okhbxEho=.2595083c-c1c6-44c2-8aef-10e317aaa2ae@github.com> References: <6i0_xf7jDRAnSDYgpij2L4JE2mDa4tOJ1j6okhbxEho=.2595083c-c1c6-44c2-8aef-10e317aaa2ae@github.com> Message-ID: On Sun, 27 Nov 2022 06:26:48 GMT, Sergey Bylokhov wrote: > I have found that drawing the BufferedImage.4BYTE_ABGR_PRE to the INT_ARGB_PRE image caused java2d to do an additional conversion from/to ARGB format. That conversion is done via a native [loop](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/share/native/libawt/java2d/loops/AlphaMath.c#L32) which tries to approximate the math, it is better to skip such conversion. > > An additional benefit is ~x2 performance improvements of this blit, so it will have the same performance as the opposite INT_ARGB_PRE to 4BYTE_ABGR_PRE blit. > > > global.dest=BufImg(IntArgbPre),graphics.imaging.src=4ByteAbgrPre > translucent,graphics.opts.alpharule=Src,graphics.opts.sizes=100: > fix: 286439.77665 (var=3.42%) (100.0%) > ***********************************************************| > ***********************************************************| > ********************************************************** | > base: 167280.80808 (var=1.8%) (58.4%) > ********************************** | > ********************************** | > ********************************** | > > global.dest=BufImg(IntArgbPre),graphics.imaging.src=4ByteAbgrPre > translucent,graphics.opts.alpharule=SrcOver,graphics.opts.sizes=100: > fix: 325989.80002 (var=1.58%) (100.0%) > *********************************************************** | > ************************************************************| > ************************************************************| > base: 200830.44521 (var=1.58%) (61.61%) > ************************************* | > ************************************* | > ************************************* | > > > To implement direct 4BYTE_ABGR_PRE to INT_ARGB_PRE blit it is necessary to "declare" and "register" blit only, all other macros are already in place. This pull request has now been integrated. Changeset: 8ffed34e Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/8ffed34e1da0ad2b9b6503f13831843dadfed319 Stats: 98 lines in 2 files changed: 97 ins; 0 del; 1 mod 8297681: Unnecessary color conversion during 4BYTE_ABGR_PRE to INT_ARGB_PRE blit Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/11376 From serb at openjdk.org Wed Nov 30 07:47:18 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 30 Nov 2022 07:47:18 GMT Subject: RFR: 8295006: Colored text is not shown on disabled checkbox and radio button with GTK LAF for bug4314194. [v2] In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 04:04:52 GMT, Prasanta Sadhukhan wrote: > If you believe it's test issue, can you please raise a PR updating the test to what it should have using the "correct properties"? > We can then roll back the product changes if need be or you also can rollback in the same PR the changes you think are incorrect I will update the test case and also will file a bug to fix the usage of the Synth properties. ------------- PR: https://git.openjdk.org/jdk/pull/10755 From psadhukhan at openjdk.org Wed Nov 30 08:01:08 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 30 Nov 2022 08:01:08 GMT Subject: RFR: 8297296: java/awt/Mouse/EnterExitEvents/DragWindowTest.java fails with "No MouseReleased event on label!" In-Reply-To: <4zWtZ0oJqrszfA0l_MDnXQBN-8CelPwANVOGSkc-KEU=.04ceefa4-7615-4714-9fa9-1815e90f9271@github.com> References: <4zWtZ0oJqrszfA0l_MDnXQBN-8CelPwANVOGSkc-KEU=.04ceefa4-7615-4714-9fa9-1815e90f9271@github.com> Message-ID: On Tue, 29 Nov 2022 23:10:56 GMT, Alisen Chung wrote: > Test was run on mac, windows, linux 50 times and passed after change > Before fix, test fails about once every 50 runs on linux and windows platforms test/jdk/java/awt/Mouse/EnterExitEvents/DragWindowTest.java line 58: > 56: > 57: Robot robot = new Robot(); > 58: robot.setAutoDelay(250); We normally do not need so much delay for test to work, 100ms being the norm which has sufficed for other tests. Maybe you need to wait robot.delay after creating and showing the GUI which is not done here. Also, this test has heavyweight and lightweight mix, for ex. MyDragWindow class uses JPanel but not in EDT which can result in some timing issue you are seeing, either it needs to be in EDT or can it be changed to AWT Panel as done elsewhere in the test? ALso, please change the wildcards imports while you are at it.. ------------- PR: https://git.openjdk.org/jdk/pull/11425 From jdv at openjdk.org Wed Nov 30 08:41:18 2022 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 30 Nov 2022 08:41:18 GMT Subject: RFR: 8297296: java/awt/Mouse/EnterExitEvents/DragWindowTest.java fails with "No MouseReleased event on label!" In-Reply-To: <4zWtZ0oJqrszfA0l_MDnXQBN-8CelPwANVOGSkc-KEU=.04ceefa4-7615-4714-9fa9-1815e90f9271@github.com> References: <4zWtZ0oJqrszfA0l_MDnXQBN-8CelPwANVOGSkc-KEU=.04ceefa4-7615-4714-9fa9-1815e90f9271@github.com> Message-ID: <2qvnXiBbC1hX-Cvvfi60BGCFg_nJitelXVKE484gJRM=.c6a70927-8869-4e4a-8ab0-bf421823480c@github.com> On Tue, 29 Nov 2022 23:10:56 GMT, Alisen Chung wrote: > Test was run on mac, windows, linux 50 times and passed after change > Before fix, test fails about once every 50 runs on linux and windows platforms This test was de-problemlisted recently under https://bugs.openjdk.org/browse/JDK-8023562 after running test 100 times in CI. And now with increased auto delay we are trying de-problemlist it again. With increased auto delay test is passing in our CI on all platforms when ran for 100 times, but we need to refine this test as mentioned by @prsadhuk to add needed delay at appropriate places and remove mixture of lightweight & heavyweight parts. test/jdk/java/awt/Mouse/EnterExitEvents/DragWindowTest.java line 84: > 82: > 83: if (dragWindowMouseEnteredCount != 1) { > 84: // System.out.println("dragWindowMouseEnteredCount " + dragWindowMouseEnteredCount); We should remove this line or uncomment it(if needed as debug info for future failures) ------------- PR: https://git.openjdk.org/jdk/pull/11425 From tr at openjdk.org Wed Nov 30 09:04:28 2022 From: tr at openjdk.org (Tejesh R) Date: Wed, 30 Nov 2022 09:04:28 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: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com> Message-ID: On Wed, 23 Nov 2022 20:40:33 GMT, Daniel D. Daugherty wrote: >> Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system. > > This PR hasn't been touched in 8 days. I'm going to ProblemListing this test > on windowx-x64 since we're up to 7 Tier3 failures in the jdk/jdk CI. @dcubed-ojdk I'm able to reproduce the bug in mach5 test runs more often. More of failures are observed within test runs also and the issue is with `downloads` ImageIcon not loading up, to find out the exact root cause I might need some more time. Problem listing the test would be better now. ------------- PR: https://git.openjdk.org/jdk/pull/11104 From psadhukhan at openjdk.org Wed Nov 30 09:22:29 2022 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 30 Nov 2022 09:22:29 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: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com> References: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com> Message-ID: On Fri, 11 Nov 2022 08:18:19 GMT, Tejesh R wrote: > Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system. Do we need to wait a bit longer after creating JFileChooser as the test immediately ends after instantiating it? Also, doesn't JFileChooser needs headful keyword as it needs to show a file dialog? Does it work more reliably if its to run in headful CI systems? ------------- PR: https://git.openjdk.org/jdk/pull/11104 From duke at openjdk.org Wed Nov 30 10:03:30 2022 From: duke at openjdk.org (duke) Date: Wed, 30 Nov 2022 10:03:30 GMT Subject: Withdrawn: 8289539: The color returned by CheckBox.interiorBackground is incorrect In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 06:59:59 GMT, Tejesh R wrote: > The color returned for `InteriorBackground` property is the default color used for only _WindowsClassicLookAndFeel_. For _WindowsLookAndFeel_ the `InteriorBackground` color is not been used when checkbox paint happens. In _WindowsLookAndFeel_ the CheckBox check/uncheck is drawn using `ImageCache` which is totally independent of `InteriorBackground` color in which the user expects it to be. > The proposed fix is to return null for _WindowsLookAndFeel_ (which is what happens in other LookAndFeel like Metal/Synth/Motif/Aqua ) and return default color which is the actual color used in _WindowsClassicLookAndFeel_. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/10385 From tr at openjdk.org Wed Nov 30 10:19:19 2022 From: tr at openjdk.org (Tejesh R) Date: Wed, 30 Nov 2022 10:19:19 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: <_ex7fdQejjDj_c0LWYUxpkA2rbquqZt2zuQ-VNLYZ1g=.7a9faaa1-7846-484f-ba3d-98e7c5d3e927@github.com> Message-ID: On Wed, 30 Nov 2022 09:20:17 GMT, Prasanta Sadhukhan wrote: > Do we need to wait a bit longer after creating JFileChooser as the test immediately ends after instantiating it? Also, doesn't JFileChooser needs headful keyword as it needs to show a file dialog? Does it work more reliably if its to run in headful CI systems? Should the test be headful even if we instantiate JFileChooser without showing the dialog.? I can check with a delay after its instantiated, but no sure if that might be causing the issue. Because the same issue is observed in another bug also which instantiates JFileChooser and does some tasks after that. ------------- PR: https://git.openjdk.org/jdk/pull/11104 From mbaesken at openjdk.org Wed Nov 30 12:53:12 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 30 Nov 2022 12:53:12 GMT Subject: Integrated: JDK-8297523 : Various GetPrimitiveArrayCritical miss result - NULL check In-Reply-To: <1i9xv5FZCi0_xvHCKtUwhGdYY6MGNKqpA55qWMPc9E0=.8010118f-59ba-4320-89ac-1f637ac46b54@github.com> References: <1i9xv5FZCi0_xvHCKtUwhGdYY6MGNKqpA55qWMPc9E0=.8010118f-59ba-4320-89ac-1f637ac46b54@github.com> Message-ID: <6qZIzBXnI-OmgkoiE5orqNkXrmamJS1s6oqKGyeiQ54=.f39a048a-1580-4c50-8c39-0593f77dcacb@github.com> On Fri, 25 Nov 2022 09:15:08 GMT, Matthias Baesken wrote: > There are still a few places where GetPrimitiveArrayCritical calls miss the result check. This should be adjusted. > A similar case was recently adjusted here : https://bugs.openjdk.org/browse/JDK-8297480 This pull request has now been integrated. Changeset: 27b339d1 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/27b339d1893e60fc894ace9ae3c0e052ae858627 Stats: 45 lines in 7 files changed: 22 ins; 5 del; 18 mod 8297523: Various GetPrimitiveArrayCritical miss result - NULL check Reviewed-by: stuefe, jdv ------------- PR: https://git.openjdk.org/jdk/pull/11361 From duke at openjdk.org Wed Nov 30 13:07:36 2022 From: duke at openjdk.org (ravi gupta) Date: Wed, 30 Nov 2022 13:07:36 GMT Subject: RFR: 8297489: Write a test to verify the content change of TextField sends TextEvent [v4] In-Reply-To: References: Message-ID: > This testcase Verify the content changes of a TextField for the following assertions. > > a. TextListener get invoked when the content of a TextField gets changed. > b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. > > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. ravi gupta has updated the pull request incrementally with one additional commit since the last revision: Deleted the file from the git repository ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11326/files - new: https://git.openjdk.org/jdk/pull/11326/files/a0fc7073..b5623ba5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11326&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11326&range=02-03 Stats: 141 lines in 1 file changed: 0 ins; 141 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11326.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11326/head:pull/11326 PR: https://git.openjdk.org/jdk/pull/11326 From duke at openjdk.org Wed Nov 30 14:34:01 2022 From: duke at openjdk.org (Nikita Gubarkov) Date: Wed, 30 Nov 2022 14:34:01 GMT Subject: RFR: 8269806: Emoji rendering on Linux [v15] In-Reply-To: References: Message-ID: > It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR > It includes: > - Bitmap glyph loading via Freetype > - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint > - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs > - Small fixes in related code like null-checks which could cause NPE & comment typos Nikita Gubarkov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Merge branch 'master' into JDK-8269806 - Merge branch 'master' into JDK-8269806 - Fix italic and bold styles for colored outline glyphs - Fix rotated text metrics - Disable colored outlines on Linux to be able to build with old system Freetype - Merge master - Optimize bitmap creation in GlyphRenderData Get rid of unneeded abstract methods Use SSIM for OutlineTextRendererEmoji test - Fix pointer to long conversion - Fix other CRLF - Fix GlyphRenderData CRLF - ... and 8 more: https://git.openjdk.org/jdk/compare/be4245e8...8c5b2850 ------------- Changes: https://git.openjdk.org/jdk/pull/4798/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=14 Stats: 2522 lines in 54 files changed: 2084 ins; 140 del; 298 mod Patch: https://git.openjdk.org/jdk/pull/4798.diff Fetch: git fetch https://git.openjdk.org/jdk pull/4798/head:pull/4798 PR: https://git.openjdk.org/jdk/pull/4798 From duke at openjdk.org Wed Nov 30 16:38:48 2022 From: duke at openjdk.org (ravi gupta) Date: Wed, 30 Nov 2022 16:38:48 GMT Subject: RFR: 8297489: Modify TextAreaTextEventTest.java as to verify the content change of TextComponent sends TextEvent [v5] In-Reply-To: References: Message-ID: > Modify TextAreaTextEventTest.java as to verify the content changes of a both TextComponent(TextField,TextArea) for the following assertions. > > a. TextListener get invoked when the content of a TextField gets changed. > b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. > > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. ravi gupta has updated the pull request incrementally with one additional commit since the last revision: Modified TextAreaTextEventTest.java as to verify the content change of TextComponent sends TextEvent ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11326/files - new: https://git.openjdk.org/jdk/pull/11326/files/b5623ba5..10d2e42b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11326&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11326&range=03-04 Stats: 308 lines in 2 files changed: 167 ins; 141 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11326.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11326/head:pull/11326 PR: https://git.openjdk.org/jdk/pull/11326 From aivanov at openjdk.org Wed Nov 30 17:30:42 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 30 Nov 2022 17:30:42 GMT Subject: RFR: 8297489: Modify TextAreaTextEventTest.java as to verify the content change of TextComponent sends TextEvent [v5] In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 16:38:48 GMT, ravi gupta wrote: >> Modify TextAreaTextEventTest.java as to verify the content changes of a both TextComponent(TextField,TextArea) for the following assertions. >> >> a. TextListener get invoked when the content of a TextField gets changed. >> b. TextListener not get invoked during text selection or when Special keys such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > ravi gupta has updated the pull request incrementally with one additional commit since the last revision: > > Modified TextAreaTextEventTest.java as to verify the content change of TextComponent sends TextEvent Changes requested by aivanov (Reviewer). test/jdk/java/awt/event/ComponentEvent/TextComponentTextEventTest.java line 63: > 61: TextArea textArea = new TextArea(5, 15); > 62: textArea.addTextListener((event) -> { > 63: System.out.println("TextArea Got a text event: " + event); Nit for being consistent: Suggestion: System.out.println("TextArea got a text event: " + event); test/jdk/java/awt/event/ComponentEvent/TextComponentTextEventTest.java line 88: > 86: EventQueue.invokeAndWait(() -> { > 87: textFieldAt = textComp.getLocationOnScreen(); > 88: textFieldSize = textComp.getSize(); Suggestion: textCompAt = textComp.getLocationOnScreen(); textCompSize = textComp.getSize(); This makes it clearer that the location and size are of a generic component which could be either `textField` or `textArea`. test/jdk/java/awt/event/ComponentEvent/TextComponentTextEventTest.java line 116: > 114: throw new RuntimeException( > 115: "FAIL: TextEvent triggered when Enter pressed on in " > 116: + textComp); Suggestion: "FAIL: TextEvent triggered when Enter pressed on " + textComp); ------------- PR: https://git.openjdk.org/jdk/pull/11326 From dnguyen at openjdk.org Wed Nov 30 17:53:08 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 30 Nov 2022 17:53:08 GMT Subject: RFR: 8202931: [macos] java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java fails [v3] In-Reply-To: References: Message-ID: > Test ran on all OS 100 times and passed. Test previously failed on macOS but no longer reproducible. Added screen capture on moment of failure to have more evidence of failures in the future (previously a runtime exception was thrown only). Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Remove extra line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11277/files - new: https://git.openjdk.org/jdk/pull/11277/files/0e02c8ea..9e93ac8e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11277&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11277&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11277.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11277/head:pull/11277 PR: https://git.openjdk.org/jdk/pull/11277 From dnguyen at openjdk.org Wed Nov 30 17:53:14 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 30 Nov 2022 17:53:14 GMT Subject: RFR: 8202931: [macos] java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java fails [v2] In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 05:26:11 GMT, Sergey Bylokhov wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Update test to capture current screen > > test/jdk/java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java line 128: > >> 126: robot.waitForIdle(); >> 127: if (choice.getSelectedIndex() == 0) { >> 128: GraphicsConfiguration ge = GraphicsEnvironment > > `ge` is unused in the latest version of the patch? My mistake. This was a remnant from when I was double-checking that the image would still produce correctly. But yes, I'm just using the existing instance of `ge` since that is determining the screen where the popup is shown. ------------- PR: https://git.openjdk.org/jdk/pull/11277 From duke at openjdk.org Wed Nov 30 18:16:39 2022 From: duke at openjdk.org (ScientificWare) Date: Wed, 30 Nov 2022 18:16:39 GMT Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4 [v23] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 17:13:42 GMT, ScientificWare wrote: >> This is referenced in Java Bug Database as >> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276) >> >> This is tracked in JBS as >> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.openjdk.java.net/browse/JDK-8292276) >> >> Adds missing color names, defined by CSS Level 4, in CSS.java : >> CSS Color Module Level 4 >> W3C Candidate Recommendation Snapshot, 5 July 2022 >> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color) >> >> Designed from : [ScientificWare JDK-8292276 : Add named colors from CSS Color Module Level 4](https://github.com/scientificware/jdk/issues/12) > > ScientificWare has updated the pull request incrementally with one additional commit since the last revision: > > Moves jtreg tags to the class declaration > > Comment with tags isn't collapsed when viewed in an IDE if it's placed before the class declaration. The updated javadoc depends on https://bugs.openjdk.org/browse/JDK-8292276 implementation. This work is in progress. ------------- PR: https://git.openjdk.org/jdk/pull/9825 From kizune at openjdk.org Wed Nov 30 19:49:08 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 30 Nov 2022 19:49:08 GMT Subject: RFR: JDK-8297449: Update JInternalFrame Metal Border code [v4] In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 21:42:02 GMT, Harshitha Onkar wrote: >> Updated Metal Border code for JInternalFrame. >> >> - Added instanceof check before casting Graphics to G2D. >> - Replaced roundHalfDown with Region.clipRound() > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > review changes Marked as reviewed by kizune (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11305