From duke at openjdk.java.net  Tue Mar  1 01:26:26 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Tue, 1 Mar 2022 01:26:26 GMT
Subject: RFR: 8015854: [macosx] JButton's HTML ImageView adding unwanted
 padding [v6]
In-Reply-To: <17xp212dQCFG9Yc7ML9pjPURjwxuFMOIZ75eGX3A-58=.71b5c61c-9fee-493a-a0a6-2345112cd8e7@github.com>
References: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
 <jaZO4QMQ6dvG0L-aO77zmgW5X1PPYbFwl85RZt5D4S0=.88946d69-85f9-4db6-b5d6-2d8340f496e0@github.com>
 <17xp212dQCFG9Yc7ML9pjPURjwxuFMOIZ75eGX3A-58=.71b5c61c-9fee-493a-a0a6-2345112cd8e7@github.com>
Message-ID: <WXCQQpgFVfAIPlVEs3gIl2ZtUnzqFDZ6ny7ttTknvs0=.f8a7c4c6-a470-410d-a230-11d371491c4e@github.com>

On Mon, 28 Feb 2022 21:56:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> DamonGuy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated exception propagation. Added button location to EDT. Updated testImageCentering for variable arguments. Moved object instantiation to the same line.
>
> test/jdk/javax/swing/JButton/HtmlButtonImageTest/HtmlButtonImageTest.java line 92:
> 
>> 90:             BufferedImage failImg = robot.createScreenCapture(new Rectangle(point.x - BUTTON_WIDTH / 2, point.y - BUTTON_HEIGHT / 2, BUTTON_WIDTH, BUTTON_HEIGHT));
>> 91:             ImageIO.write(failImg, "png", new File(testDir + "/fail_square.png"));
>> 92:             throw new RuntimeException("Failed image generation: " + e);
> 
> This doesn't make sense. I mean `IOException` can be thrown from try-block only from `generateImage` method. In this case, there's nothing to display on screen and therefore nothing to capture. You should not catch `IOException` at all.
> 
> You should create the screenshot if the conditions you verify aren't met. The screenshot should be taken inside `if (!checkRedness(c))` block before you throw the `RuntimeException` to indicate failure.

I believe I fixed the additional changes requested in the next commit. I understand what you meant with main handling exceptions now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7310


From duke at openjdk.java.net  Tue Mar  1 02:19:07 2022
From: duke at openjdk.java.net (duke)
Date: Tue, 1 Mar 2022 02:19:07 GMT
Subject: Withdrawn: JDK-8276809:
 java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on
 Windows
In-Reply-To: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
References: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
Message-ID: <VhG7Gpwc8FFIl2EVhilXYPQw0b2xOEdZsO0bCfUcAkA=.02600538-f747-4d55-b622-90c13fabbc63@github.com>

On Tue, 9 Nov 2021 07:57:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni to an awt related test, and shows on Windows server 2019 the following JNI warning , so the test  JNICheck/FreeTypeScalerJNICheck.java fails on this Windows version.
> 
> :stdErr:
> Thu Oct 28 01:27:10 CEST 2021
> stdout: [WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV
>                at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop at 18.0.0.1-internal/Native Method)
>                at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop at 18.0.0.1-internal/Win32GraphicsEnvironment.java:95)
>                at sun.awt.Win32GraphicsEnvironment.<clinit>(java.desktop at 18.0.0.1-internal/Win32GraphicsEnvironment.java:63)
>                at sun.awt.PlatformGraphicsInfo.createGE(java.desktop at 18.0.0.1-internal/PlatformGraphicsInfo.java:34)
>                at java.awt.GraphicsEnvironment$LocalGE.createGE(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:93)
>                at java.awt.GraphicsEnvironment$LocalGE.<clinit>(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:84)
>                at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(java.desktop at 18.0.0.1-internal/GraphicsEnvironment.java:106)
>                at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53)
>                at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)
> 
> We can get rid of the warning by adjusting a JNU_CallStaticMethodByName call in awt_Win32GraphicsEnv.cpp .

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6306


From psadhukhan at openjdk.java.net  Tue Mar  1 08:38:35 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 1 Mar 2022 08:38:35 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic available
 not used by GUI elements even though available without Korean
 Language Pack
Message-ID: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>

Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts

-------------

Commit messages:
 - 8190907: Windows 10 default Korean Font Malgun Gothic available not used by GUI elements even though available without Korean Language Pack

Changes: https://git.openjdk.java.net/jdk/pull/7643/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7643&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8190907
  Stats: 14 lines in 1 file changed: 2 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7643.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7643/head:pull/7643

PR: https://git.openjdk.java.net/jdk/pull/7643


From psadhukhan at openjdk.java.net  Tue Mar  1 10:22:29 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 1 Mar 2022 10:22:29 GMT
Subject: RFR: 8282473: Refactor swing classes javadoc to use @throws instead of
 @exception
Message-ID: <ZEDkB2AsCYNkyACgfH8htOz5VfAZobfGP6KviOHLZhU=.3c93f6f1-2058-4481-a1fb-ed752a2e3746@github.com>

Prevailing JDK coding practices use "@throws" rather than "@exception".
Refactor existing swing classes javadoc to use @throws

-------------

Commit messages:
 - Fix
 - Fix
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/7644/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7644&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282473
  Stats: 533 lines in 114 files changed: 0 ins; 0 del; 533 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7644.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7644/head:pull/7644

PR: https://git.openjdk.java.net/jdk/pull/7644


From aivanov at openjdk.java.net  Tue Mar  1 11:44:12 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 1 Mar 2022 11:44:12 GMT
Subject: RFR: 8015854: [macosx] JButton's HTML ImageView adding unwanted
 padding [v7]
In-Reply-To: <DfRa-3kb-xIl4-kTyTDYqtaxsOoNDAnRfWA3KSdmjy4=.6575b0cc-a7ef-42b7-80f7-1844eb66fdea@github.com>
References: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
 <DfRa-3kb-xIl4-kTyTDYqtaxsOoNDAnRfWA3KSdmjy4=.6575b0cc-a7ef-42b7-80f7-1844eb66fdea@github.com>
Message-ID: <-K6rtQyT-7qLsORwESekvXuVNRhPii3sMGAlrS6IwAY=.f46b22a7-8c6a-467f-bd58-54e798500bef@github.com>

On Mon, 28 Feb 2022 23:27:50 GMT, DamonGuy <duke at openjdk.java.net> wrote:

>> Html does not fit in JButton at certain sizes because default Insets cause html to be displayed off-center. 
>> 
>> Changes made to SwingUtilities.java layoutCompoundLabelImpl method to enable clipping if html does not fit, similar to regular text. AquaButtonUI.java now detects when html does not fit, and an implementation for alternate insets that are recursively tested for regular text inside layoutAndGetText() are now also being used for html content.
>> 
>> Created test (Bug8015854.java) with the same format as the test described on the issue. The button is of size 37x37 with an image of a red square sized 19x19. The test checks for red pixels on the edges of where the square image should be from the center of the button. The test fails with the non-changed jdk, but passes with the changes.
>
> DamonGuy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated code organization. Removed unnecessary catch blocks and comments. Added null check for frame disposal.

test/jdk/javax/swing/JButton/HtmlButtonImageTest/HtmlButtonImageTest.java line 53:

> 51: public final class HtmlButtonImageTest {
> 52:     private static JFrame frame;
> 53:     private static Point point;

`point` must be volatile as it's accessed from two threads.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7310


From aivanov at openjdk.java.net  Tue Mar  1 12:06:15 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 1 Mar 2022 12:06:15 GMT
Subject: RFR: 8015854: [macosx] JButton's HTML ImageView adding unwanted
 padding [v2]
In-Reply-To: <HBa5hf4oLNpdQvVFl2xe9Ag7LktcAZSV4V941uNy0ws=.e5da9d7d-8228-4d52-a5c7-16bd0a7144cb@github.com>
References: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
 <pn-wczysGBNV4XJ8_rDFXnEKKJ_6_f6R67qppgx28Mg=.6bf696b2-9a19-41ca-ba5b-d23312248231@github.com>
 <HBa5hf4oLNpdQvVFl2xe9Ag7LktcAZSV4V941uNy0ws=.e5da9d7d-8228-4d52-a5c7-16bd0a7144cb@github.com>
Message-ID: <Gmckdelne7neGqhWETPY47J2lW_oqDCmGzcVj21VLAw=.69bdfbbc-c495-423c-b83e-c2cf899e1040@github.com>

On Sat, 5 Feb 2022 18:16:34 GMT, Phil Race <prr at openjdk.org> wrote:

>> DamonGuy has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add cycling of all installed LAFs. Add image generation to avoid saving an image to repo.
>>  - Changed frame to dispose regardless of passing or failing.
>
> src/java.desktop/share/classes/javax/swing/SwingUtilities.java line 1129:
> 
>> 1127:             v = (c != null) ? (View) c.getClientProperty("html") : null;
>> 1128:             if (v != null) {
>> 1129:                 if(availTextWidth < (int) v.getPreferredSpan(View.X_AXIS)){
> 
> Can you attach "before" and "after" images into the bug report as part of the evaluation ?
> Do this for Aqua and Metal too.
> 
> I presume this code only gets entered for labels with images ?
> If this is all L&Fs then please manually test on mac. Windows and GTK L&Fs using SwingSet2 looking for problems as well as running all automated client tests using mach5.
> 
> We do not use syntax like "if(" and "else{".
> It should always be "if (" and "else {"
> Also no space after (int) for the cast. lines 1129 and 1134 .. 
> And make sure lines are <=80 characters long which that one 1134 doesn't look to be.

> @prrace Also no space after (int) for the cast. lines 1129 and 1134 ..

I'd like to clarify what style is followed by the client code.

[Code Conventions for the Java](https://www.oracle.com/java/technologies/javase/codeconventions-contents.html) published in 1999 in its section for white-space [state](https://www.oracle.com/java/technologies/javase/codeconventions-whitespace.html#498):

_?Casts should be followed by a blank space.?_

A more recent [draft for Java Style](http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html) that is commonly referred to during code reviews also says about using the space after the cast in its [Horizontal Whitespace section](http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-whitespace):

_?A single space should be used?  
After the closing parenthesis of a cast.?_

As far as I can see, neither style ? *no space* after the cast vs *a space* after the cast ? is followed consistently. Let's agree on one option and follow it then.

Shall I bring it up for a discussion on the client-libs mailing list?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7310


From aivanov at openjdk.java.net  Tue Mar  1 12:25:09 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 1 Mar 2022 12:25:09 GMT
Subject: RFR: 8015854: [macosx] JButton's HTML ImageView adding unwanted
 padding [v4]
In-Reply-To: <E2stwUY_Og_fby3Y0MPoba9Gr7eoryDrPvuclqccbf0=.63b8f227-c5fd-463d-9e56-103515fc7bb9@github.com>
References: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
 <lyxDxKiU6PokQIEDykTL_s4MvMleY06DwnSbdhRt4UY=.4db8d06d-50d3-4637-8240-f2c1ef79dc8d@github.com>
 <wxzLTWLNh7kpgWMZw1ew8Ohqrs9euMyvu_u2UMDYsEo=.ab3f621e-a41f-4baa-87a5-6e60a6a95357@github.com>
 <E2stwUY_Og_fby3Y0MPoba9Gr7eoryDrPvuclqccbf0=.63b8f227-c5fd-463d-9e56-103515fc7bb9@github.com>
Message-ID: <9Odpq0YTy18AQHa6Nt3n1KoyW19iYs7l2GgqiEdQZd0=.9caae1b3-5818-4038-9416-3a87859705a0@github.com>

On Thu, 24 Feb 2022 16:07:41 GMT, DamonGuy <duke at openjdk.java.net> wrote:

>> src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 313:
>> 
>>> 311:             // use zero insets for view since layout only handles text calculations
>>> 312:             text = layoutAndGetText(g, b, aquaBorder, new
>>> 313:                     Insets(0,0,0,0), viewRect, iconRect, textRect);
>> 
>> If there is only html text instead of image in JButton, will it not be a problem using 0 insets or is there a problem with text too being shifted like image?
>
> The text was also unexpectedly shifted, so this zero inset fixes that issue as well. Setting the insets to zero for all HTML fixes the unwanted padding.

Should we create a separate test for HTML text? Probably manual only but still. If it is a known issue and it's also resolved by this fix, I find such a test useful.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7310


From aivanov at openjdk.java.net  Tue Mar  1 12:25:10 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 1 Mar 2022 12:25:10 GMT
Subject: RFR: 8015854: [macosx] JButton's HTML ImageView adding unwanted
 padding [v4]
In-Reply-To: <wxzLTWLNh7kpgWMZw1ew8Ohqrs9euMyvu_u2UMDYsEo=.ab3f621e-a41f-4baa-87a5-6e60a6a95357@github.com>
References: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
 <lyxDxKiU6PokQIEDykTL_s4MvMleY06DwnSbdhRt4UY=.4db8d06d-50d3-4637-8240-f2c1ef79dc8d@github.com>
 <wxzLTWLNh7kpgWMZw1ew8Ohqrs9euMyvu_u2UMDYsEo=.ab3f621e-a41f-4baa-87a5-6e60a6a95357@github.com>
Message-ID: <1VyZwzdKS6ZiYdakmm7j7Elb1ECbIH72466KjoAD4IE=.388b8d7e-554f-4e3a-be5f-00502672565e@github.com>

On Thu, 24 Feb 2022 09:26:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> DamonGuy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed incomplete comment.
>
> test/jdk/javax/swing/JButton/HtmlButtonImageTest/HtmlButtonImageTest.java line 85:
> 
>> 83:         robot.mouseMove(frame.getLocationOnScreen().x, frame.getLocationOnScreen().y);
>> 84:         robot.mouseMove(button.getLocationOnScreen().x, button.getLocationOnScreen().y);
>> 85: 
> 
> I guess there is no need of this staggard mouseMove. One can move straight to "point" as done below, right?

There's no need for `mouseMove` at all. However, it helps to analyse the image visually whether the red square is centered in the button or not.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7310


From aivanov at openjdk.java.net  Tue Mar  1 12:35:06 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 1 Mar 2022 12:35:06 GMT
Subject: RFR: 8015854: [macosx] JButton's HTML ImageView adding unwanted
 padding [v2]
In-Reply-To: <jklVZZSwHTIARC5_ePds3ACoUU3lRKJd3Np6rMQxW3M=.66d079f3-97b6-4ec9-8741-b7af05672c0a@github.com>
References: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
 <pn-wczysGBNV4XJ8_rDFXnEKKJ_6_f6R67qppgx28Mg=.6bf696b2-9a19-41ca-ba5b-d23312248231@github.com>
 <jklVZZSwHTIARC5_ePds3ACoUU3lRKJd3Np6rMQxW3M=.66d079f3-97b6-4ec9-8741-b7af05672c0a@github.com>
Message-ID: <_xis0t6zeLWPEutXb6ffOJD_w0cBAgOvfoQYifD4g2Y=.1790d64d-0c1e-44a4-b4c8-bd2261d758b9@github.com>

On Fri, 4 Feb 2022 02:55:02 GMT, DamonGuy <duke at openjdk.java.net> wrote:

>> DamonGuy has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add cycling of all installed LAFs. Add image generation to avoid saving an image to repo.
>>  - Changed frame to dispose regardless of passing or failing.
>
> I noticed I mistakenly left the thrown exception for failures commented out for the most recent push while testing the new changes. The new test with the run-time generated image and cycled LAFs seems to fail for Nimbus LAF, so I will fix this and push to the branch again.

A general comment: You, @DamonGuy, have quite a few comments in the test. Most of these comments are redundant because they repeat what the code does. The code should be self-documenting by using meaningful method and variable names, and I think you follow this rule.

The problem with comments is that they may be left unmodified when the code changes. Thus, the comments become misleading, confusing and therefore don't help a reader understand the code but make the reader guess whether they should believe the comment or the code.

A couple of points from [Programming Practices](http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-commenting-code) section from the Java Style Guide:

? _?First and foremost, try to make the code simple enough that it?s self explanatory. While comments explaining the code are good, not having to explain the code is better.?_

? _?Avoid comments that run the risk of getting out of sync as the code evolves. (If a comment runs the risk of getting out of sync, it?s often a sign that it comments how the code works rather than what the code achieves.)?_

-------------

PR: https://git.openjdk.java.net/jdk/pull/7310


From aivanov at openjdk.java.net  Tue Mar  1 14:07:07 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 1 Mar 2022 14:07:07 GMT
Subject: RFR: 8015854: [macosx] JButton's HTML ImageView adding unwanted
 padding [v7]
In-Reply-To: <DfRa-3kb-xIl4-kTyTDYqtaxsOoNDAnRfWA3KSdmjy4=.6575b0cc-a7ef-42b7-80f7-1844eb66fdea@github.com>
References: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
 <DfRa-3kb-xIl4-kTyTDYqtaxsOoNDAnRfWA3KSdmjy4=.6575b0cc-a7ef-42b7-80f7-1844eb66fdea@github.com>
Message-ID: <aSOXKBXo-g2Mmi9v4kyeH3UV53KntCPTxB19J-EzpKs=.f2da8d0b-f6aa-4f98-8bbd-ec1bdeefecaf@github.com>

On Mon, 28 Feb 2022 23:27:50 GMT, DamonGuy <duke at openjdk.java.net> wrote:

>> Html does not fit in JButton at certain sizes because default Insets cause html to be displayed off-center. 
>> 
>> Changes made to SwingUtilities.java layoutCompoundLabelImpl method to enable clipping if html does not fit, similar to regular text. AquaButtonUI.java now detects when html does not fit, and an implementation for alternate insets that are recursively tested for regular text inside layoutAndGetText() are now also being used for html content.
>> 
>> Created test (Bug8015854.java) with the same format as the test described on the issue. The button is of size 37x37 with an image of a red square sized 19x19. The test checks for red pixels on the edges of where the square image should be from the center of the button. The test fails with the non-changed jdk, but passes with the changes.
>
> DamonGuy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated code organization. Removed unnecessary catch blocks and comments. Added null check for frame disposal.

Hi Jeremy,

> _Mailing list message from [Jeremy Wood](mailto:mickleness at gmail.com) on [client-libs-dev](mailto:client-libs-dev at mail.openjdk.java.net):_
> 
> Damon:
> 
> Sorry for joining this chat late. Is the core problem here that Swing is positioning graphic elements incorrectly -- and those bad positions are platform-independent?

Yes, it looks that this issue is platform-independent and can be reproduced with other Look-and-Feels on other platforms.

> 
> If so: this might be a good candidate for me to try to rewrite a test to avoid the Robot class. I have a Graphics2D implementation <https://github.com/mickleness/pumpernickel/blob/master/src/main/java/com/pump/graphics/vector/VectorGraphics2D.java> that catalogs rendering operations. If just the act of reviewing those catalogued instructions can detect the underlying problem: this might be a simpler/faster alternative. (I?m assuming tests written using the Robot class are more expensive to run and more brittle.)
> 
> Does this sound like something that might benefit this test case? (I can have a look at it in a few days.)
> 
> Regards, - Jeremy

The code you reference cannot be used in OpenJDK until _the author of the code_ contributes it to OpenJDK.

You're right headful tests are more expensive to run.

@prsadhuk mentioned that `Robot.getPixelColor` may produce an incorrect result which @honkar-jdk came across. In fact, @DamonGuy sees the artefacts too: on a High DPI display (and built-in Retina display of MacBook is a High DPI display), one pixel in user's space is represented with several physical pixels. In such a case, `getPixelColor` still returns only one pixel.

In [Harshitha's](https://github.com/honkar-jdk) #7219, the table header border had 1px width. The robot correctly captured the specified part of the screen but the line was drawn on the second row of the physical pixels.

Damon needs to account for antialiasing. The image needs to be scaled up for Retina display, its borders aren't sharp anymore.

Painting the `JButton` to `BufferedImage` could resolve these problems, the test could check for the red color without adding a tolerance. If there's no frame and button is painted to `BufferedImage`, the test could be made _headless_.

Perhaps, we should advise this approach when the test doesn't need to process any input.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7310


From aivanov at openjdk.java.net  Tue Mar  1 14:30:06 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 1 Mar 2022 14:30:06 GMT
Subject: RFR: 8015854: [macosx] JButton's HTML ImageView adding unwanted
 padding
In-Reply-To: <hnyblIWtUeSFqxlNy3BPgpUVsEfBObIpC3glr31ZDYY=.8db9528a-1404-4b4b-8a50-8cc7ada31d5d@github.com>
References: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
 <dy67jGFEinetq6QaDmr3jyWpr_LM2FW5iE7lQ854ips=.72431a52-3630-4594-bc17-f55de0da377f@github.com>
 <hnyblIWtUeSFqxlNy3BPgpUVsEfBObIpC3glr31ZDYY=.8db9528a-1404-4b4b-8a50-8cc7ada31d5d@github.com>
Message-ID: <dmqFqm60xISBNehiYxcY78D60DXW4Bw_RjQ_z_cRpZk=.eb0bed09-22e0-4987-bec0-655d210a109b@github.com>

On Thu, 3 Feb 2022 01:43:07 GMT, DamonGuy <duke at openjdk.java.net> wrote:

> > The JBS says "This is reproducible with the Mac default (Aqua) look and feel; using another LAF (Metal for instance) seems to position the ImageView correctly." so it seems to be a mac issue not generic, so fixing in shared code will have other repurcussions..You probably need to fix in Aqua specific class..
> 
> @prsadhuk Sorry, I forgot to mention in the JBS issue that while testing if the issue was reproducible locally, I discovered that the issue exists for Aqua LAF as described, but also other LAFs (such as Metal and Basic).
> 
> This discovery shifted my attention away from AquaButtonUI alone, and AquaButtonUI's layoutAndGetText method using alternative insets turned out to be where the issue was coming from. This method relies on "SwingUtilities.layoutCompoundLabel" to generate alternative insets, so that's where I made my changes. Is this logic valid or should I contain my changes in AquaButtonUI?

Since this fix addresses `AquaButtonUI` only and we know for sure that other Look-and-Feels are also affected (Metal at least according to the comments in JBS and here), has anyone submitted a new bug for other LaFs?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7310


From aivanov at openjdk.java.net  Tue Mar  1 16:15:08 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 1 Mar 2022 16:15:08 GMT
Subject: RFR: 8281569: Create tests for Frame.setMinimumSize() method [v6]
In-Reply-To: <E7dfs1cDOyA__dqPhuRtSirB3Iv3cIlZ02fG39lH98I=.b1f661ca-b2b1-4bec-b548-35cc1f4ae80e@github.com>
References: <nSHmEKVtW-ErNDdAP0Xh0QSaRbBg4yA9ZvSoqi7XtMg=.7690f96d-3d0d-4fda-bb58-0ce641d465d9@github.com>
 <E7dfs1cDOyA__dqPhuRtSirB3Iv3cIlZ02fG39lH98I=.b1f661ca-b2b1-4bec-b548-35cc1f4ae80e@github.com>
Message-ID: <JUKnONH6hwXskpQERwF3xaF4Vag74wZKzFgErug6Wsc=.75defc8e-fa40-4d4c-89b7-e98175438e72@github.com>

On Mon, 28 Feb 2022 11:45:32 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create tests for setMinimumSize functionality
>> Create a test which verifies that on increasing the Frame's minimumSize, it gets reflected in the subsequent getSize call
>> Create a test which verifies that on frame resizes back to minimumSize on calling pack.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed, removed redundant waitForIdle

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/Frame/SetMinimumSizeTest/SetMinimumSizeTest1.java line 40:

> 38: 
> 39:     private static Frame frame;
> 40:     private static volatile Dimension dimension, actualDimension;

In Java, each field should be declared on its own line.

test/jdk/java/awt/Frame/SetMinimumSizeTest/SetMinimumSizeTest1.java line 42:

> 40:     private static volatile Dimension dimension, actualDimension;
> 41: 
> 42:     public static void createGUI(Frame _frame) {

The `_frame` parameter is never used, please remove it.

test/jdk/java/awt/Frame/SetMinimumSizeTest/SetMinimumSizeTest1.java line 61:

> 59:                 dimension = frame.getSize();
> 60:                 dimension.width = dimension.width + 20;
> 61:                 dimension.height = dimension.height + 20;

Suggestion:

                dimension.width += 20;
                dimension.height += 20;

test/jdk/java/awt/Frame/SetMinimumSizeTest/SetMinimumSizeTest1.java line 73:

> 71:             });
> 72: 
> 73:             robot.waitForIdle();

At line 73, `waitForIdle` doesn't affect anything, it should be removed.

test/jdk/java/awt/Frame/SetMinimumSizeTest/SetMinimumSizeTest1.java line 81:

> 79:             }
> 80:         }
> 81:         finally {

Suggestion:

        } finally {


The finally-block as well as catch- and else-blocks should be at the same line as the closing brace from the previous block.

test/jdk/java/awt/Frame/SetMinimumSizeTest/SetMinimumSizeTest2.java line 42:

> 40:     private static volatile Dimension dimension, actualDimension;
> 41: 
> 42:     public static void createGUI(Frame _frame) {

The same as for test1: field declarations are on its own lines, `_frame` parameter removed.

test/jdk/java/awt/Frame/SetMinimumSizeTest/SetMinimumSizeTest2.java line 63:

> 61: 
> 62:             EventQueue.invokeAndWait(() -> {
> 63:                 frame.setSize(new Dimension(dimension.width + 20, dimension.height + 20));

You can call `setSize(int, int)` method without creating a new `Dimension` object. This way is also fine.

test/jdk/java/awt/Frame/SetMinimumSizeTest/SetMinimumSizeTest2.java line 82:

> 80:             });
> 81: 
> 82:             robot.waitForIdle();

At line 82, `waitForIdle` is not needed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7444


From aivanov at openjdk.java.net  Tue Mar  1 16:44:11 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 1 Mar 2022 16:44:11 GMT
Subject: RFR: 6911375: mouseWheel has no effect without vertical scrollbar
 [v2]
In-Reply-To: <y4QjxoUtP5jpcD2_MLfQCooZJEAxjD4EoW9TJi6b5sA=.43f01906-e154-4478-a25c-eb3d015f7143@github.com>
References: <LRiJrIRXEEKyRk3kJGxpiYdjaM3e0clEM8686zpgLDI=.9a4d9f5f-bf67-471a-9c0d-b90289dc123a@github.com>
 <y4QjxoUtP5jpcD2_MLfQCooZJEAxjD4EoW9TJi6b5sA=.43f01906-e154-4478-a25c-eb3d015f7143@github.com>
Message-ID: <SqClhYuGmWjZ5xsjoVsh0ICc4MzoMfR7tAsuwOqGxJQ=.95db6589-fc61-48ef-bbb2-6057d26abf6b@github.com>

On Mon, 28 Feb 2022 07:59:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It is observed that mouseWheel doesn't scroll through a list if there is no scrollbar even though pressing PageUp/Down using keyboard moves up/down the list.
>> Issue stems from the fact that BasicScrollPaneUI.Handler.mouseWheelMoved() skips the mouse wheel events when the scrollbar is not visible. 
>> Fixed to handle mouseWheelEvent even though scrollbar is not visible with the assumption that if both vertical and horizontal scrollbar is not visible, then assume default orientation to be vertical.
>> 
>> Existing jtreg, jck tests are ok. All L&F works well with the fix and testcase works in all platforms except on mac which will be handled separately.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test comments

test/jdk/javax/swing/JScrollPane/TestMouseWheelScroll.java line 48:

> 46:     static Point p;
> 47:     static int width;
> 48:     static int height;

These three should also be volatile, shouldn't they?

test/jdk/javax/swing/JScrollPane/TestMouseWheelScroll.java line 101:

> 99:                 robot.delay(1000);
> 100:                 robot.mouseWheel(1);
> 101:                 robot.delay(500);

You don't call `waitForIdle` or `delay` after the mouse click because it just selects an item but doesn't change the position, right?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7585


From aivanov at openjdk.java.net  Tue Mar  1 16:44:12 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 1 Mar 2022 16:44:12 GMT
Subject: RFR: 6911375: mouseWheel has no effect without vertical scrollbar
 [v2]
In-Reply-To: <trMKZD9k98XfzCU5GioF7G8H-qzMaKnlkSUQdE00mEk=.3214a35c-3f04-43aa-a34d-434df6f47197@github.com>
References: <LRiJrIRXEEKyRk3kJGxpiYdjaM3e0clEM8686zpgLDI=.9a4d9f5f-bf67-471a-9c0d-b90289dc123a@github.com>
 <XZ4FTlIUoTnUpPrDoKPQPIRuNM7iH9_tiABo47DnPAo=.2ec18c09-8729-444f-87fc-b36ebb560180@github.com>
 <trMKZD9k98XfzCU5GioF7G8H-qzMaKnlkSUQdE00mEk=.3214a35c-3f04-43aa-a34d-434df6f47197@github.com>
Message-ID: <I0YDV_5sU9Mv2lYXJKwp9qDF3W6KhFM0qR6ZaB988dU=.7623b370-0d4d-486b-af46-6e0d8af8bdd1@github.com>

On Mon, 28 Feb 2022 08:02:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/javax/swing/JScrollPane/TestMouseWheelScroll.java line 80:
>> 
>>> 78:                     scrollPane.setVerticalScrollBarPolicy(JScrollPane.VERTICAL_SCROLLBAR_NEVER);
>>> 79:                     frame.add(scrollPane);
>>> 80:                     frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>> 
>> Suggestion:
>> 
>>                     frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
>> 
>> It's safer for tests.
>
> This testcase was failing on macos which needs to be debugged, so it is excluded in mac for now. But as I told in description, the fix is not affecting other regression test in macos.
> It's working on other platforms and I have some issue in my local mac system so I will take this debugging of macos once I sort my system.
> 
> Regarding your other question, the orientation will be horizontal. Tested against javax/swing/JScrollPane/HorizontalMouseWheelOnShiftPressed/HorizontalMouseWheelOnShiftPressed.java

I see, thank you for explanation. Does it make sense to put the test in ProblemList.txt for macOS, so that it's not forgotten the test is to be run on macOS too?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7585


From aivanov at openjdk.java.net  Tue Mar  1 16:54:02 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 1 Mar 2022 16:54:02 GMT
Subject: RFR: 6218162: DefaultTableColumnModel.getColumn() method should
 mention ArrayIndexOutOfBoundsException [v3]
In-Reply-To: <XtDXW8eh84GfpMHO0zvqPYCjUFPnnlQ-Ka6ZMv1HNMw=.909a4ca3-12d1-43c6-b6f5-26854535be6a@github.com>
References: <KYDs0LbJF3OqE_Wncy3XvCymxYe5dHfrN9PQXkXCEYE=.2e310ed0-910f-433c-93a3-e1f691f2131b@github.com>
 <XtDXW8eh84GfpMHO0zvqPYCjUFPnnlQ-Ka6ZMv1HNMw=.909a4ca3-12d1-43c6-b6f5-26854535be6a@github.com>
Message-ID: <g7grbJge5VqgyMW3u6xC4FEhZjdlTHhiVmBkpRoPjkk=.f22671ca-de4a-4cdf-8bf7-9d20dcd98486@github.com>

On Mon, 28 Feb 2022 07:24:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> If invalid ie 0 or > getColumnCount() index is passed to DefaultTableColumnModel.getColumn() then it returns AIOBE in current implementation which should be documented in the spec. Fixed the spec to mention the exception.
>
> Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - javadoc fix
>  - javadoc fix
>  - javadoc fix

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7587


From aivanov at openjdk.java.net  Tue Mar  1 16:54:03 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 1 Mar 2022 16:54:03 GMT
Subject: RFR: 6218162: DefaultTableColumnModel.getColumn() method should
 mention ArrayIndexOutOfBoundsException [v2]
In-Reply-To: <J9zvdd_9NNvisnC5pr-c2xrYr6bm2RV0wfJ8zoyRYCk=.038a35f2-3ae1-4279-bcb0-dd3067c27d08@github.com>
References: <KYDs0LbJF3OqE_Wncy3XvCymxYe5dHfrN9PQXkXCEYE=.2e310ed0-910f-433c-93a3-e1f691f2131b@github.com>
 <PEMaXtVsNOMHw2WFAalGTEQzDL5B5uDVkEURblnS7wg=.e989d8fb-cd92-4cb0-b9ee-027ff9ff8252@github.com>
 <4iVrHkUpcWdueUHLYWWF39Do-DXVv8w6C9_78rpC69Y=.4e74c3ec-a8e0-46d1-ac0e-ced56d2e1a37@github.com>
 <J9zvdd_9NNvisnC5pr-c2xrYr6bm2RV0wfJ8zoyRYCk=.038a35f2-3ae1-4279-bcb0-dd3067c27d08@github.com>
Message-ID: <nFB3oYS-qH8r5F3WtTGtpgtcXAYMlZfofYnJzW06fgA=.b5214dae-8dcf-4420-b88d-e1d3cd28c281@github.com>

On Mon, 28 Feb 2022 07:16:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/table/DefaultTableColumnModel.java line 294:
>> 
>>> 292:      *                          at <code>columnIndex</code>
>>> 293:      * @exception  ArrayIndexOutOfBoundsException if <code>columnIndex</code>
>>> 294:      *             is out of range:
>> 
>> As Joe Darcy pointed out, we use @throws these days.
>
> I was aware of that but this file uses @exception throughout, so to be consistent, I used that..But if it is recommended to use @throws even at the cost of being inconsistent within the file, I would use that.

It is the reason why I didn't ask to use `@throws` which is the preferred way.

Anyway, #7644 with [JDK-8282473](https://bugs.openjdk.java.net/browse/JDK-8282473) will bring consistency and all `@exception` tags will be replaced with `@throws`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7587


From aivanov at openjdk.java.net  Tue Mar  1 16:59:12 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 1 Mar 2022 16:59:12 GMT
Subject: RFR: 8281738: Create a regression test for checking the 'Space'
 key activation of focused Button [v7]
In-Reply-To: <n-yxsjWEloyeNIh5BPrDGy5QJ7O_MvKgy6YEEpV-RlI=.5d31f735-ef68-4ac6-9e4a-a193dc9891a9@github.com>
References: <tvjgbTQ13Sbz1D37rufjVdYnW9T7_mqEHg2n4H5CIcg=.da6bf10e-0b6b-40e6-bbb7-19296933559f@github.com>
 <IHNpuuRXpXkJ9KtxdM4Yzx5Q3-vCRkAuvsBzeq6LU9A=.bb33e852-d8f9-4391-b2b1-6ee9c1f25b8e@github.com>
 <n-yxsjWEloyeNIh5BPrDGy5QJ7O_MvKgy6YEEpV-RlI=.5d31f735-ef68-4ac6-9e4a-a193dc9891a9@github.com>
Message-ID: <YpShI9g2CYZEadvVXOO82ysEG8opyhNCsLb13g-5uiQ=.e6bfe45d-6180-4471-89fc-2c4885156fe7@github.com>

On Wed, 23 Feb 2022 21:15:02 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Does anyone have any comments or objections?

Having heard no comments, I'm integrating.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7460


From mvs at openjdk.java.net  Tue Mar  1 16:59:14 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 1 Mar 2022 16:59:14 GMT
Subject: Integrated: 8281738: Create a regression test for checking the 'Space'
 key activation of focused Button
In-Reply-To: <tvjgbTQ13Sbz1D37rufjVdYnW9T7_mqEHg2n4H5CIcg=.da6bf10e-0b6b-40e6-bbb7-19296933559f@github.com>
References: <tvjgbTQ13Sbz1D37rufjVdYnW9T7_mqEHg2n4H5CIcg=.da6bf10e-0b6b-40e6-bbb7-19296933559f@github.com>
Message-ID: <D07C1vGwpmH7bCQClQAnP7Is8cnlONJTR7SGA5Fahsw=.ed761cee-da42-4207-8393-f0ebf23c2924@github.com>

On Mon, 14 Feb 2022 14:04:33 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> This test verifies in all platforms and in all 'Look and Feels' that pressing the 'Space' key generates ActionEvent on focused Button or not.

This pull request has now been integrated.

Changeset: 941e97c4
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/941e97c4eb186bc63386d17f458ba69f4bddd828
Stats:     152 lines in 1 file changed: 152 ins; 0 del; 0 mod

8281738: Create a regression test for checking the 'Space' key activation of focused Button

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/7460


From aivanov at openjdk.java.net  Tue Mar  1 17:01:10 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 1 Mar 2022 17:01:10 GMT
Subject: RFR: 8276849: Refresh the window icon on graphics configuration
 changes [v5]
In-Reply-To: <8ubPWqU0vTLZW-eX7r2v9GAvrlp_4-mRKwuz8jwPHlM=.ee58d4d6-1ad0-409a-98cb-2d839e8187d6@github.com>
References: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
 <8ubPWqU0vTLZW-eX7r2v9GAvrlp_4-mRKwuz8jwPHlM=.ee58d4d6-1ad0-409a-98cb-2d839e8187d6@github.com>
Message-ID: <f2P0JKXzcL6Pvny3vOJNCF5dWk0CgcTuKv6sk4Fv0xU=.a5df4903-8e5f-4355-aee2-51675ce510a5@github.com>

On Fri, 25 Feb 2022 12:39:50 GMT, Emmanuel Bourg <duke at openjdk.java.net> wrote:

>> When a list of icons is set on a window, the most appropiate icon is selected depending on the graphics configuration. But if the graphics configuration changes (because the window is moved to a different screen, or because the DPI settings of the screen is changed), the frame icon isn't updated.
>> 
>> Here is an example illustrating the issue:
>> 
>>     public static void main(String[] args) throws Exception {
>>         SwingUtilities.invokeLater(() -> {
>>             JFrame frame = new JFrame("Window Icon Test");
>>             frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
>>             frame.setSize(400, 300);
>>             frame.setVisible(true);
>> 
>>             List<Image> images = new ArrayList<>();
>>             for (int size = 16; size <= 32; size++) {
>>                 // create an image displaying the size used
>>                 BufferedImage image = new BufferedImage(size, size, BufferedImage.TYPE_INT_ARGB);
>>                 Graphics2D g = image.createGraphics();
>>                 g.setFont(new Font("dialog", Font.BOLD, 12));
>>                 g.setColor(Color.BLACK);
>>                 g.drawString(String.valueOf(size), 0, size - (size - g.getFont().getSize()) / 2);
>>                 images.add(image);
>>             }
>> 
>>             frame.setIconImages(images);
>>         });
>>     }
>> 
>> On Windows if the screen scaling is set to 100% the 16x16 icon is picked from the list. If the scaling of the screen is set to 150% while the application is running, the 16x16 icon is upscaled and looks blurry.
>> 
>> A way to work around this issue is to listen for graphics configuration changes with:
>> 
>>     frame.addPropertyChangeListener("graphicsConfiguration", event -> frame.setIconImages(frame.getIconImages()));
>> 
>> 
>> Ideally this should be done automatically by the JDK. Maybe the `WindowPeer` could call `updateIconImages()` when `updateGraphicsData()` or `displayChanged()` is invoked?
>
> Emmanuel Bourg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't refresh the frame icon on graphics configuration changes on macOS (not applicable)

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6180


From aivanov at openjdk.java.net  Tue Mar  1 17:05:06 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 1 Mar 2022 17:05:06 GMT
Subject: Integrated: 8282150: Drop redundant <br> elements from tables in
 java.desktop HTML files
In-Reply-To: <iQdYgK6zPLmGwsY6TyBbUJAkV9jbtx4ZA3Z7tzNwD0g=.1eb374c5-ab11-4057-88c5-ee1d19444489@github.com>
References: <iQdYgK6zPLmGwsY6TyBbUJAkV9jbtx4ZA3Z7tzNwD0g=.1eb374c5-ab11-4057-88c5-ee1d19444489@github.com>
Message-ID: <XOTR0SZNSf-HqJmCH8m2LXHW2scFj3MpBgvj3mqYn3c=.9ca5b08e-ce1f-4622-8897-757ea1396f37@github.com>

On Sun, 20 Feb 2022 18:07:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Drops the redundant `<br>` elements from tables and lists in java.desktop HTML files.

This pull request has now been integrated.

Changeset: b86a8c00
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b86a8c004f4e67e7b6bf45ce7cf96bcd8520a881
Stats:     168 lines in 2 files changed: 0 ins; 0 del; 168 mod

8282150: Drop redundant <br> elements from tables in java.desktop HTML files

Reviewed-by: jdv, dmarkov

-------------

PR: https://git.openjdk.java.net/jdk/pull/7547


From naoto at openjdk.java.net  Tue Mar  1 18:34:00 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 1 Mar 2022 18:34:00 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack
In-Reply-To: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
Message-ID: <XMQgyyPsQBicfb85ajWNSslcyOaTl_O8csvGEE9ICwU=.3c67351b-37a7-4edb-8509-1a4fc568ee8b@github.com>

On Tue, 1 Mar 2022 08:31:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts

Is it OK to replace all of them? According to this document:
https://docs.microsoft.com/en-us/typography/fonts/windows_10_font_list
There still are Korean supplementary fonts available (Batang/Gulim/etc) if `Feature On Demand` is installed. Should they be honored?

Also, for bold type, should we use `malgunbd.ttf`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From aivanov at openjdk.java.net  Tue Mar  1 22:01:59 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 1 Mar 2022 22:01:59 GMT
Subject: RFR: 8282473: Refactor swing classes javadoc to use @throws
 instead of @exception
In-Reply-To: <ZEDkB2AsCYNkyACgfH8htOz5VfAZobfGP6KviOHLZhU=.3c93f6f1-2058-4481-a1fb-ed752a2e3746@github.com>
References: <ZEDkB2AsCYNkyACgfH8htOz5VfAZobfGP6KviOHLZhU=.3c93f6f1-2058-4481-a1fb-ed752a2e3746@github.com>
Message-ID: <yzHtJShyGIKnYIKBMQXcxI2XstNl86vO_9g2uJpNxmY=.f441065e-1bb7-440f-b591-db86576bad56@github.com>

On Tue, 1 Mar 2022 10:16:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Prevailing JDK coding practices use "@throws" rather than "@exception".
> Refactor existing swing classes javadoc to use @throws

Marked as reviewed by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/JApplet.java line 139:

> 137:      *
> 138:      * @throws HeadlessException if GraphicsEnvironment.isHeadless()
> 139:      * returns true.

Suggestion:

     * returns true

In other cases, there's no ending punctuation for `@throws`.

src/java.desktop/share/classes/javax/swing/JColorChooser.java line 154:

> 152:      * @return the selected color or <code>null</code> if the user opted out
> 153:      * @throws HeadlessException if GraphicsEnvironment.isHeadless()
> 154:      * returns true.

It looks `HeadlessException` has the period everywhere where it's documented. In this case, I suggest addressing this under another issue.

src/java.desktop/share/classes/javax/swing/JLabel.java line 625:

> 623:      * @return the key value if {@code key} is a legal value for the
> 624:      *         verticalAlignment or verticalTextPosition properties
> 625:      * @throws IllegalArgumentException if key isn't TOP, CENTER, or BOTTOM.

Another case with ending punctuation.

src/java.desktop/share/classes/javax/swing/JRootPane.java line 582:

> 580:      * @param content the <code>Container</code> to use for component-contents
> 581:      * @throws java.awt.IllegalComponentStateException (a runtime
> 582:      *            exception) if the content pane parameter is <code>null</code>

Shall we remove _?(a runtime exception)?_ note?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7644


From duke at openjdk.java.net  Tue Mar  1 23:25:04 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Tue, 1 Mar 2022 23:25:04 GMT
Subject: RFR: 8015854: [macosx] JButton's HTML ImageView adding unwanted
 padding [v4]
In-Reply-To: <9Odpq0YTy18AQHa6Nt3n1KoyW19iYs7l2GgqiEdQZd0=.9caae1b3-5818-4038-9416-3a87859705a0@github.com>
References: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
 <lyxDxKiU6PokQIEDykTL_s4MvMleY06DwnSbdhRt4UY=.4db8d06d-50d3-4637-8240-f2c1ef79dc8d@github.com>
 <wxzLTWLNh7kpgWMZw1ew8Ohqrs9euMyvu_u2UMDYsEo=.ab3f621e-a41f-4baa-87a5-6e60a6a95357@github.com>
 <E2stwUY_Og_fby3Y0MPoba9Gr7eoryDrPvuclqccbf0=.63b8f227-c5fd-463d-9e56-103515fc7bb9@github.com>
 <9Odpq0YTy18AQHa6Nt3n1KoyW19iYs7l2GgqiEdQZd0=.9caae1b3-5818-4038-9416-3a87859705a0@github.com>
Message-ID: <qsszeftB496XoKcgOCNx2EhjMwuM3B3tHsouTpSdiNs=.09af3f28-f202-4971-9716-8d7a06b656a6@github.com>

On Tue, 1 Mar 2022 12:20:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The text was also unexpectedly shifted, so this zero inset fixes that issue as well. Setting the insets to zero for all HTML fixes the unwanted padding.
>
> Should we create a separate test for HTML text? Probably manual only but still. If it is a known issue and it's also resolved by this fix, I find such a test useful.

I can definitely try to do so. The newest version of the test is now headless using BufferedImage. By manual, do you mean making a headful test where the tester clicks pass or fail according to the position of HTML text on the button?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7310


From duke at openjdk.java.net  Tue Mar  1 23:27:57 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Tue, 1 Mar 2022 23:27:57 GMT
Subject: RFR: 8015854: [macosx] JButton's HTML ImageView adding unwanted
 padding [v8]
In-Reply-To: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
References: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
Message-ID: <DgeMCQtzhqMoDpyf3LSagIZNmGafVtMtAi3d1rpE4xk=.afbd74d4-c78e-426e-b112-d87d25a05755@github.com>

> Html does not fit in JButton at certain sizes because default Insets cause html to be displayed off-center. 
> 
> Changes made to SwingUtilities.java layoutCompoundLabelImpl method to enable clipping if html does not fit, similar to regular text. AquaButtonUI.java now detects when html does not fit, and an implementation for alternate insets that are recursively tested for regular text inside layoutAndGetText() are now also being used for html content.
> 
> Created test (Bug8015854.java) with the same format as the test described on the issue. The button is of size 37x37 with an image of a red square sized 19x19. The test checks for red pixels on the edges of where the square image should be from the center of the button. The test fails with the non-changed jdk, but passes with the changes.

DamonGuy has updated the pull request incrementally with one additional commit since the last revision:

  Updated test to be headless using BufferedImage.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7310/files
  - new: https://git.openjdk.java.net/jdk/pull/7310/files/d9db4c2b..dd8599ce

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7310&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7310&range=06-07

  Stats: 113 lines in 1 file changed: 13 ins; 57 del; 43 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7310.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7310/head:pull/7310

PR: https://git.openjdk.java.net/jdk/pull/7310


From duke at openjdk.java.net  Tue Mar  1 23:37:12 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Tue, 1 Mar 2022 23:37:12 GMT
Subject: RFR: 8015854: [macosx] JButton's HTML ImageView adding unwanted
 padding [v8]
In-Reply-To: <DgeMCQtzhqMoDpyf3LSagIZNmGafVtMtAi3d1rpE4xk=.afbd74d4-c78e-426e-b112-d87d25a05755@github.com>
References: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
 <DgeMCQtzhqMoDpyf3LSagIZNmGafVtMtAi3d1rpE4xk=.afbd74d4-c78e-426e-b112-d87d25a05755@github.com>
Message-ID: <EOgvUaDKBLE38BJL982WuJraTzwl37Emb9pecU1Aq3k=.56904ac9-b77f-43d6-9f22-b43e0697f261@github.com>

On Tue, 1 Mar 2022 23:27:57 GMT, DamonGuy <duke at openjdk.java.net> wrote:

>> Html does not fit in JButton at certain sizes because default Insets cause html to be displayed off-center. 
>> 
>> Changes made to SwingUtilities.java layoutCompoundLabelImpl method to enable clipping if html does not fit, similar to regular text. AquaButtonUI.java now detects when html does not fit, and an implementation for alternate insets that are recursively tested for regular text inside layoutAndGetText() are now also being used for html content.
>> 
>> Created test (Bug8015854.java) with the same format as the test described on the issue. The button is of size 37x37 with an image of a red square sized 19x19. The test checks for red pixels on the edges of where the square image should be from the center of the button. The test fails with the non-changed jdk, but passes with the changes.
>
> DamonGuy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated test to be headless using BufferedImage.

I have updated the test to be headless by using BufferedImage. 

There is no new bug submitted yet for other LAFs that I know of. I tested other LAFs and the issue does persist, so I can submit the bug for them if necessary. The other LAFs I tested were Metal, Nimbus, and Motif.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7310


From smandalika at openjdk.java.net  Wed Mar  2 06:10:42 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 2 Mar 2022 06:10:42 GMT
Subject: RFR: 8281569: Create tests for Frame.setMinimumSize() method [v7]
In-Reply-To: <nSHmEKVtW-ErNDdAP0Xh0QSaRbBg4yA9ZvSoqi7XtMg=.7690f96d-3d0d-4fda-bb58-0ce641d465d9@github.com>
References: <nSHmEKVtW-ErNDdAP0Xh0QSaRbBg4yA9ZvSoqi7XtMg=.7690f96d-3d0d-4fda-bb58-0ce641d465d9@github.com>
Message-ID: <xUdMr1Z546K3EqnGd2Ut99nH26o7EVH-_aQ0DkrX0jg=.e04635a3-7cf9-4d14-94d0-692caf706ee4@github.com>

> Create tests for setMinimumSize functionality
> Create a test which verifies that on increasing the Frame's minimumSize, it gets reflected in the subsequent getSize call
> Create a test which verifies that on frame resizes back to minimumSize on calling pack.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed: field declared on different line, finally block on same line, changed to +=,..

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7444/files
  - new: https://git.openjdk.java.net/jdk/pull/7444/files/8d9141fb..e244dd3a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7444&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7444&range=05-06

  Stats: 19 lines in 2 files changed: 2 ins; 6 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7444.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7444/head:pull/7444

PR: https://git.openjdk.java.net/jdk/pull/7444


From myano at openjdk.java.net  Wed Mar  2 06:24:05 2022
From: myano at openjdk.java.net (Masanori Yano)
Date: Wed, 2 Mar 2022 06:24:05 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <1xgNYge02zcX-kfQ343p2YT4v2MIbym5SHL_fDnqMPI=.ab03d946-c8ec-4a2f-871a-8d58e6a30f43@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
 <1xgNYge02zcX-kfQ343p2YT4v2MIbym5SHL_fDnqMPI=.ab03d946-c8ec-4a2f-871a-8d58e6a30f43@github.com>
Message-ID: <gTIPP0tHTsyPXjtsNrSHwLZMeEK5Y_GbDH-bA1Fit0I=.813d9ad7-a0d9-448b-9c35-06f249c168db@github.com>

On Mon, 14 Feb 2022 20:12:39 GMT, Phil Race <prr at openjdk.org> wrote:

>> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8275715: D3D pipeline processes multiple PaintEvent at initial drawing
>
> Ok. Please confirm you have run all automated headful jtreg tests on a system with D3D enabled
> and that you have also done manual testing (using SwingSet2 and J2Ddemo) and no problems are observed ?

@prrace How long will it take for you to reply to the comment?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6064


From psadhukhan at openjdk.java.net  Wed Mar  2 09:23:02 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 2 Mar 2022 09:23:02 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack
In-Reply-To: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
Message-ID: <bEjR5W5SbUgFkO87iG0ZJl14X_2yhnqw350_-XadWrs=.52e3fadf-648f-49c0-af39-7921a47d78d5@github.com>

On Tue, 1 Mar 2022 08:31:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts

Malgun Gothic is supposed to be the default korean font replacing Gulim as per the wiki mentioned in the description, so I have only replaced Gulim,not all.. Others like Batang are not replaced.
Also, as I pointed out by screenshot in JBS in my Windows10 I dont have malgunbd.ttf so I was doubting it may not be available in all distribution by default, so I have used only malgun.ttf

OTOH, if Gulim is available as supplementary fonts, we probably can close this issue as "Wont fix" mentioning the same.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From psadhukhan at openjdk.java.net  Wed Mar  2 09:29:01 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 2 Mar 2022 09:29:01 GMT
Subject: RFR: 8282473: Refactor swing classes javadoc to use @throws
 instead of @exception
In-Reply-To: <ZEDkB2AsCYNkyACgfH8htOz5VfAZobfGP6KviOHLZhU=.3c93f6f1-2058-4481-a1fb-ed752a2e3746@github.com>
References: <ZEDkB2AsCYNkyACgfH8htOz5VfAZobfGP6KviOHLZhU=.3c93f6f1-2058-4481-a1fb-ed752a2e3746@github.com>
Message-ID: <qBkzwaDhQEXT-nSBjGiirU-q8UeMLTTqLdT6lhS_G5g=.26339fc9-3058-44d9-b943-87816530aa63@github.com>

On Tue, 1 Mar 2022 10:16:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Prevailing JDK coding practices use "@throws" rather than "@exception".
> Refactor existing swing classes javadoc to use @throws

I would rather keep this PR simple just to replace @exception with @throws. Other anomalies/idiosyncracies can be tackled in separate issue, if you dont mind.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7644


From aivanov at openjdk.java.net  Wed Mar  2 09:38:03 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 2 Mar 2022 09:38:03 GMT
Subject: RFR: 8282473: Refactor swing classes javadoc to use @throws
 instead of @exception
In-Reply-To: <qBkzwaDhQEXT-nSBjGiirU-q8UeMLTTqLdT6lhS_G5g=.26339fc9-3058-44d9-b943-87816530aa63@github.com>
References: <ZEDkB2AsCYNkyACgfH8htOz5VfAZobfGP6KviOHLZhU=.3c93f6f1-2058-4481-a1fb-ed752a2e3746@github.com>
 <qBkzwaDhQEXT-nSBjGiirU-q8UeMLTTqLdT6lhS_G5g=.26339fc9-3058-44d9-b943-87816530aa63@github.com>
Message-ID: <1m78aouqMVQM_wYuTVgGkMxqp_T9aYV_r2Mwm5LtukU=.0d622828-b834-4dd9-8626-b91dba4a7a6d@github.com>

On Wed, 2 Mar 2022 09:25:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I would rather keep this PR simple just to replace @exception with @throws. Other anomalies/idiosyncracies can be tackled in separate issue, if you dont mind.

I didn't make myself clear: I absolutely agree with your approach. If it were only one case to address, but there are too many to include under this issue. Simple changes that address one issue at a time are easier to review.

In fact, I found quite a few inaccuracies in javadoc while reviewing this change.

Have you submitted a bug to address the inconsistency with usage of periods? If not, I'll submit one.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7644


From psadhukhan at openjdk.java.net  Wed Mar  2 09:44:02 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 2 Mar 2022 09:44:02 GMT
Subject: RFR: 8282473: Refactor swing classes javadoc to use @throws
 instead of @exception
In-Reply-To: <ZEDkB2AsCYNkyACgfH8htOz5VfAZobfGP6KviOHLZhU=.3c93f6f1-2058-4481-a1fb-ed752a2e3746@github.com>
References: <ZEDkB2AsCYNkyACgfH8htOz5VfAZobfGP6KviOHLZhU=.3c93f6f1-2058-4481-a1fb-ed752a2e3746@github.com>
Message-ID: <R3sRaJ4GdTrRvqgpQdN18ZhWyuR7Y9ijnR9-CPCPoFA=.4ae5cd14-28d5-41fb-acf3-39b239b33850@github.com>

On Tue, 1 Mar 2022 10:16:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Prevailing JDK coding practices use "@throws" rather than "@exception".
> Refactor existing swing classes javadoc to use @throws

No, you can submit..

-------------

PR: https://git.openjdk.java.net/jdk/pull/7644


From aivanov at openjdk.java.net  Wed Mar  2 09:56:06 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 2 Mar 2022 09:56:06 GMT
Subject: RFR: 8281569: Create tests for Frame.setMinimumSize() method [v7]
In-Reply-To: <xUdMr1Z546K3EqnGd2Ut99nH26o7EVH-_aQ0DkrX0jg=.e04635a3-7cf9-4d14-94d0-692caf706ee4@github.com>
References: <nSHmEKVtW-ErNDdAP0Xh0QSaRbBg4yA9ZvSoqi7XtMg=.7690f96d-3d0d-4fda-bb58-0ce641d465d9@github.com>
 <xUdMr1Z546K3EqnGd2Ut99nH26o7EVH-_aQ0DkrX0jg=.e04635a3-7cf9-4d14-94d0-692caf706ee4@github.com>
Message-ID: <4sbdmYr4Zf2u1bWeNJkT8nsvedKeirT-2PnrTEJ_rmI=.f3d4376e-7ce4-4d33-a67d-faa1d599036c@github.com>

On Wed, 2 Mar 2022 06:10:42 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create tests for setMinimumSize functionality
>> Create a test which verifies that on increasing the Frame's minimumSize, it gets reflected in the subsequent getSize call
>> Create a test which verifies that on frame resizes back to minimumSize on calling pack.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: field declared on different line, finally block on same line, changed to +=,..

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7444


From dmarkov at openjdk.java.net  Wed Mar  2 12:22:09 2022
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Wed, 2 Mar 2022 12:22:09 GMT
Subject: RFR: 8282473: Refactor swing classes javadoc to use @throws
 instead of @exception
In-Reply-To: <ZEDkB2AsCYNkyACgfH8htOz5VfAZobfGP6KviOHLZhU=.3c93f6f1-2058-4481-a1fb-ed752a2e3746@github.com>
References: <ZEDkB2AsCYNkyACgfH8htOz5VfAZobfGP6KviOHLZhU=.3c93f6f1-2058-4481-a1fb-ed752a2e3746@github.com>
Message-ID: <RtqbG-sk6sMtUC9IcphyvO4m-9TEZWEh_iz8bO1kAg8=.241ca4b3-055a-4150-9475-750d99340946@github.com>

On Tue, 1 Mar 2022 10:16:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Prevailing JDK coding practices use "@throws" rather than "@exception".
> Refactor existing swing classes javadoc to use @throws

Marked as reviewed by dmarkov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7644


From smandalika at openjdk.java.net  Wed Mar  2 13:12:04 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 2 Mar 2022 13:12:04 GMT
Subject: RFR: 8281569: Create tests for Frame.setMinimumSize() method [v7]
In-Reply-To: <4sbdmYr4Zf2u1bWeNJkT8nsvedKeirT-2PnrTEJ_rmI=.f3d4376e-7ce4-4d33-a67d-faa1d599036c@github.com>
References: <nSHmEKVtW-ErNDdAP0Xh0QSaRbBg4yA9ZvSoqi7XtMg=.7690f96d-3d0d-4fda-bb58-0ce641d465d9@github.com>
 <xUdMr1Z546K3EqnGd2Ut99nH26o7EVH-_aQ0DkrX0jg=.e04635a3-7cf9-4d14-94d0-692caf706ee4@github.com>
 <4sbdmYr4Zf2u1bWeNJkT8nsvedKeirT-2PnrTEJ_rmI=.f3d4376e-7ce4-4d33-a67d-faa1d599036c@github.com>
Message-ID: <fntoxBW9_hOmA_Lr_jQt_KwJkNcveE29QYy_n-9xAyc=.6ccd325f-24e8-4105-bc8d-f2e74efd506f@github.com>

On Wed, 2 Mar 2022 09:52:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments fixed: field declared on different line, finally block on same line, changed to +=,..
>
> Marked as reviewed by aivanov (Reviewer).

@aivanov-jdk Can you please sponsor my changes?.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7444


From psadhukhan at openjdk.java.net  Wed Mar  2 13:21:54 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 2 Mar 2022 13:21:54 GMT
Subject: RFR: 6911375: mouseWheel has no effect without vertical scrollbar
 [v3]
In-Reply-To: <LRiJrIRXEEKyRk3kJGxpiYdjaM3e0clEM8686zpgLDI=.9a4d9f5f-bf67-471a-9c0d-b90289dc123a@github.com>
References: <LRiJrIRXEEKyRk3kJGxpiYdjaM3e0clEM8686zpgLDI=.9a4d9f5f-bf67-471a-9c0d-b90289dc123a@github.com>
Message-ID: <K3lEqbdn4pwlUoFGFFjjVtzJhDaIKP8324mQYy5xJ1k=.8efff190-b223-42e9-960e-930ef623683c@github.com>

> It is observed that mouseWheel doesn't scroll through a list if there is no scrollbar even though pressing PageUp/Down using keyboard moves up/down the list.
> Issue stems from the fact that BasicScrollPaneUI.Handler.mouseWheelMoved() skips the mouse wheel events when the scrollbar is not visible. 
> Fixed to handle mouseWheelEvent even though scrollbar is not visible with the assumption that if both vertical and horizontal scrollbar is not visible, then assume default orientation to be vertical.
> 
> Existing jtreg, jck tests are ok. All L&F works well with the fix and testcase works in all platforms except on mac which will be handled separately.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Add volatile keyword in test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7585/files
  - new: https://git.openjdk.java.net/jdk/pull/7585/files/700a98e6..3514278e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7585&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7585&range=01-02

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7585.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7585/head:pull/7585

PR: https://git.openjdk.java.net/jdk/pull/7585


From aivanov at openjdk.java.net  Wed Mar  2 13:21:54 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 2 Mar 2022 13:21:54 GMT
Subject: RFR: 6911375: mouseWheel has no effect without vertical scrollbar
 [v3]
In-Reply-To: <K3lEqbdn4pwlUoFGFFjjVtzJhDaIKP8324mQYy5xJ1k=.8efff190-b223-42e9-960e-930ef623683c@github.com>
References: <LRiJrIRXEEKyRk3kJGxpiYdjaM3e0clEM8686zpgLDI=.9a4d9f5f-bf67-471a-9c0d-b90289dc123a@github.com>
 <K3lEqbdn4pwlUoFGFFjjVtzJhDaIKP8324mQYy5xJ1k=.8efff190-b223-42e9-960e-930ef623683c@github.com>
Message-ID: <gPs452r3ULeHKqrJOh8397NDdSXXGouh0ZJBvUcRRQU=.13bb9144-57f1-4b5e-a6f8-748f1aa5a3a4@github.com>

On Wed, 2 Mar 2022 13:17:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It is observed that mouseWheel doesn't scroll through a list if there is no scrollbar even though pressing PageUp/Down using keyboard moves up/down the list.
>> Issue stems from the fact that BasicScrollPaneUI.Handler.mouseWheelMoved() skips the mouse wheel events when the scrollbar is not visible. 
>> Fixed to handle mouseWheelEvent even though scrollbar is not visible with the assumption that if both vertical and horizontal scrollbar is not visible, then assume default orientation to be vertical.
>> 
>> Existing jtreg, jck tests are ok. All L&F works well with the fix and testcase works in all platforms except on mac which will be handled separately.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add volatile keyword in test

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7585


From psadhukhan at openjdk.java.net  Wed Mar  2 13:21:55 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 2 Mar 2022 13:21:55 GMT
Subject: RFR: 6911375: mouseWheel has no effect without vertical scrollbar
 [v2]
In-Reply-To: <SqClhYuGmWjZ5xsjoVsh0ICc4MzoMfR7tAsuwOqGxJQ=.95db6589-fc61-48ef-bbb2-6057d26abf6b@github.com>
References: <LRiJrIRXEEKyRk3kJGxpiYdjaM3e0clEM8686zpgLDI=.9a4d9f5f-bf67-471a-9c0d-b90289dc123a@github.com>
 <y4QjxoUtP5jpcD2_MLfQCooZJEAxjD4EoW9TJi6b5sA=.43f01906-e154-4478-a25c-eb3d015f7143@github.com>
 <SqClhYuGmWjZ5xsjoVsh0ICc4MzoMfR7tAsuwOqGxJQ=.95db6589-fc61-48ef-bbb2-6057d26abf6b@github.com>
Message-ID: <GFYPwC-IWeAlv9QfzojwY-3WrtWEojFiij9qoaOjzW8=.3c848261-b0c1-4871-b052-10a1e231ca85@github.com>

On Tue, 1 Mar 2022 16:38:30 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix test comments
>
> test/jdk/javax/swing/JScrollPane/TestMouseWheelScroll.java line 48:
> 
>> 46:     static Point p;
>> 47:     static int width;
>> 48:     static int height;
> 
> These three should also be volatile, shouldn't they?

yes

> test/jdk/javax/swing/JScrollPane/TestMouseWheelScroll.java line 101:
> 
>> 99:                 robot.delay(1000);
>> 100:                 robot.mouseWheel(1);
>> 101:                 robot.delay(500);
> 
> You don't call `waitForIdle` or `delay` after the mouse click because it just selects an item but doesn't change the position, right?

added

-------------

PR: https://git.openjdk.java.net/jdk/pull/7585


From psadhukhan at openjdk.java.net  Wed Mar  2 13:21:55 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 2 Mar 2022 13:21:55 GMT
Subject: RFR: 6911375: mouseWheel has no effect without vertical scrollbar
 [v3]
In-Reply-To: <I0YDV_5sU9Mv2lYXJKwp9qDF3W6KhFM0qR6ZaB988dU=.7623b370-0d4d-486b-af46-6e0d8af8bdd1@github.com>
References: <LRiJrIRXEEKyRk3kJGxpiYdjaM3e0clEM8686zpgLDI=.9a4d9f5f-bf67-471a-9c0d-b90289dc123a@github.com>
 <XZ4FTlIUoTnUpPrDoKPQPIRuNM7iH9_tiABo47DnPAo=.2ec18c09-8729-444f-87fc-b36ebb560180@github.com>
 <trMKZD9k98XfzCU5GioF7G8H-qzMaKnlkSUQdE00mEk=.3214a35c-3f04-43aa-a34d-434df6f47197@github.com>
 <I0YDV_5sU9Mv2lYXJKwp9qDF3W6KhFM0qR6ZaB988dU=.7623b370-0d4d-486b-af46-6e0d8af8bdd1@github.com>
Message-ID: <cDIkGBVp-vXf0Wtvt7EX-W0TRdx3z2S0cVOHullXkxc=.6a6811fd-914e-45c6-a164-da25b9e85376@github.com>

On Tue, 1 Mar 2022 16:41:18 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This testcase was failing on macos which needs to be debugged, so it is excluded in mac for now. But as I told in description, the fix is not affecting other regression test in macos.
>> It's working on other platforms and I have some issue in my local mac system so I will take this debugging of macos once I sort my system.
>> 
>> Regarding your other question, the orientation will be horizontal. Tested against javax/swing/JScrollPane/HorizontalMouseWheelOnShiftPressed/HorizontalMouseWheelOnShiftPressed.java
>
> I see, thank you for explanation. Does it make sense to put the test in ProblemList.txt for macOS, so that it's not forgotten the test is to be run on macOS too?

We problemlist a test if it fails in a particular platform whereas in this case it is taken care of by @requires so it will not fail.
But no worries, it's in my radar to take it up. I will raise a JBS as soon as this is committed as I need to mention about this test in JBS description.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7585


From aivanov at openjdk.java.net  Wed Mar  2 13:21:55 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 2 Mar 2022 13:21:55 GMT
Subject: RFR: 6911375: mouseWheel has no effect without vertical scrollbar
 [v3]
In-Reply-To: <cDIkGBVp-vXf0Wtvt7EX-W0TRdx3z2S0cVOHullXkxc=.6a6811fd-914e-45c6-a164-da25b9e85376@github.com>
References: <LRiJrIRXEEKyRk3kJGxpiYdjaM3e0clEM8686zpgLDI=.9a4d9f5f-bf67-471a-9c0d-b90289dc123a@github.com>
 <XZ4FTlIUoTnUpPrDoKPQPIRuNM7iH9_tiABo47DnPAo=.2ec18c09-8729-444f-87fc-b36ebb560180@github.com>
 <trMKZD9k98XfzCU5GioF7G8H-qzMaKnlkSUQdE00mEk=.3214a35c-3f04-43aa-a34d-434df6f47197@github.com>
 <I0YDV_5sU9Mv2lYXJKwp9qDF3W6KhFM0qR6ZaB988dU=.7623b370-0d4d-486b-af46-6e0d8af8bdd1@github.com>
 <cDIkGBVp-vXf0Wtvt7EX-W0TRdx3z2S0cVOHullXkxc=.6a6811fd-914e-45c6-a164-da25b9e85376@github.com>
Message-ID: <yx0_kfkFpdcSi-Zv-KE7RdGJhPgWN47B56UCitfzNbY=.2f2c11d5-432e-43bd-b4c0-5899b12329aa@github.com>

On Wed, 2 Mar 2022 13:14:08 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> I see, thank you for explanation. Does it make sense to put the test in ProblemList.txt for macOS, so that it's not forgotten the test is to be run on macOS too?
>
> We problemlist a test if it fails in a particular platform whereas in this case it is taken care of by @requires so it will not fail.
> But no worries, it's in my radar to take it up. I will raise a JBS as soon as this is committed as I need to mention about this test in JBS description.

Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7585


From aivanov at openjdk.java.net  Wed Mar  2 14:54:55 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 2 Mar 2022 14:54:55 GMT
Subject: RFR: 8282473: Refactor swing classes javadoc to use @throws
 instead of @exception
In-Reply-To: <ZEDkB2AsCYNkyACgfH8htOz5VfAZobfGP6KviOHLZhU=.3c93f6f1-2058-4481-a1fb-ed752a2e3746@github.com>
References: <ZEDkB2AsCYNkyACgfH8htOz5VfAZobfGP6KviOHLZhU=.3c93f6f1-2058-4481-a1fb-ed752a2e3746@github.com>
Message-ID: <VF6DnpwXZ_z6HzsJ_I4jvQtZphgekPmen39x0hhgMwY=.28b7d1e8-fbee-4867-9bd6-24d34e50c49d@github.com>

On Tue, 1 Mar 2022 10:16:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Prevailing JDK coding practices use "@throws" rather than "@exception".
> Refactor existing swing classes javadoc to use @throws

Submitted:

- [JDK-8282539](https://bugs.openjdk.java.net/browse/JDK-8282539): Remove ending punctuation from @throws HeadlessException
- [JDK-8282546](https://bugs.openjdk.java.net/browse/JDK-8282546): Remove ending punctuation from @throws in java.desktop

I decided to separate these two cases.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7644


From aivanov at openjdk.java.net  Wed Mar  2 16:22:01 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 2 Mar 2022 16:22:01 GMT
Subject: RFR: 8282473: Refactor swing classes javadoc to use @throws
 instead of @exception
In-Reply-To: <yzHtJShyGIKnYIKBMQXcxI2XstNl86vO_9g2uJpNxmY=.f441065e-1bb7-440f-b591-db86576bad56@github.com>
References: <ZEDkB2AsCYNkyACgfH8htOz5VfAZobfGP6KviOHLZhU=.3c93f6f1-2058-4481-a1fb-ed752a2e3746@github.com>
 <yzHtJShyGIKnYIKBMQXcxI2XstNl86vO_9g2uJpNxmY=.f441065e-1bb7-440f-b591-db86576bad56@github.com>
Message-ID: <9zvPmVRaNuXTPvDdAKFQoc0UrUrbFsw7608FUjNLmGU=.1937c3e9-1faa-463c-81e5-c80972f61ba1@github.com>

On Tue, 1 Mar 2022 20:13:30 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prevailing JDK coding practices use "@throws" rather than "@exception".
>> Refactor existing swing classes javadoc to use @throws
>
> src/java.desktop/share/classes/javax/swing/JRootPane.java line 582:
> 
>> 580:      * @param content the <code>Container</code> to use for component-contents
>> 581:      * @throws java.awt.IllegalComponentStateException (a runtime
>> 582:      *            exception) if the content pane parameter is <code>null</code>
> 
> Shall we remove _?(a runtime exception)?_ note?

Submitted [JDK-8282562](https://bugs.openjdk.java.net/browse/JDK-8282562): Remove "(a runtime exception)" from javadoc for unchecked exceptions in java.desktop

-------------

PR: https://git.openjdk.java.net/jdk/pull/7644


From achung at openjdk.java.net  Wed Mar  2 18:13:07 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 2 Mar 2022 18:13:07 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor
In-Reply-To: <rr-q8_MKsGzwfkGOsQLt-Rabzaok9pyAMecmLvUcRU8=.6f352cee-e260-4eb4-a203-f896137aa59f@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <N1n7OHD60zGkgScnV4kHt9Y9uauOP_kbiI46uatTGIY=.054b811f-b6e0-4e6c-b0d1-4cc1580a57e6@github.com>
 <PdunT5nhqtOL3qGYnYXinV8D9stzrmXmCaQmUo6WxxU=.d96e56d3-3d5f-4315-8cae-add5e9322806@github.com>
 <rr-q8_MKsGzwfkGOsQLt-Rabzaok9pyAMecmLvUcRU8=.6f352cee-e260-4eb4-a203-f896137aa59f@github.com>
Message-ID: <032ug3NHtrq71T-LPnGGJVT-OIqPe2V8QjOJXPfyOdY=.3ec1e9ee-e0ed-4437-b918-87b5ece945b1@github.com>

On Mon, 14 Feb 2022 23:26:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I think there's a rounding error when doing x.5 scalings causing the drawing area to be one pixel too small on the left side
>
> Can you please check how it will work for the undecorated frame, if it will be fine then the problem is somehow related to the size of the insets.

@mrserb I've been trying to manually adjust the insets/variables to see what could be causing the issue, but only decreasing borderX by 1 seems to fix the issue. Could you clarify what you can gather from the undecorated frame working?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From naoto at openjdk.java.net  Wed Mar  2 18:29:03 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 2 Mar 2022 18:29:03 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack
In-Reply-To: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
Message-ID: <SdZr_k9rt37lidSPlDn2H0zB2_9b5zOK3SR_Htc4q0U=.4ce26cdc-0b22-40ea-a150-71190757269d@github.com>

On Tue, 1 Mar 2022 08:31:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts

I thought there is some mechanism to chain physical fonts, such as if `glim.ttc` is not available for `korean` then use `malgun.ttf` instead, but I may be wrong here. @prrace, can you comment on it?

If there is no such fallback mechanism, `Batang` should also be replaced with `Malgun Gothic`, otherwise it would show blobs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From cushon at openjdk.java.net  Wed Mar  2 18:47:09 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 2 Mar 2022 18:47:09 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v10]
In-Reply-To: <8bgd8AjF-ev0GEN5E0CUBZIU61-bFTqqyn26dsTrFBU=.d6a81200-5160-46b0-ae4c-e28a67649a9d@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <W2s9WCAQ0PrTJ6_74UYEZKrNcArdyqeqFjPDL60ugsU=.ddb42dc6-f07c-48cb-bf69-0625ac3e5ea4@github.com>
 <8bgd8AjF-ev0GEN5E0CUBZIU61-bFTqqyn26dsTrFBU=.d6a81200-5160-46b0-ae4c-e28a67649a9d@github.com>
Message-ID: <m_K9Bw82CHY1vgyTkfSMGQhNuL7fW2WzeSYPL5oBgyA=.15bf3ba1-a81c-452e-b007-f241559941cc@github.com>

On Tue, 1 Feb 2022 16:55:16 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Hi, is there any feedback on this change, or the alternate fix in #7100 that updates the binary files, or the related cleanup in #7099?

Friendly ping.

My opinion is that https://github.com/openjdk/jdk/pull/7099 is a clear improvement to the current test setup, because it preserves the existing behaviour without relying on patching the JDK to disable constructor validation in `DragGestureEvent` and `DragGestureRecognizer` to generate the serialized objects.

Additionally, I think it's worth considering the fix in https://github.com/openjdk/jdk/pull/7100. It includes a minimal fix to the `uninstallDefaults` behaviour of `BasicPanelUI`, which is the only broken uninstall behaviour exercised by the current test, and allows moving the test off the allowlist.

However if the decision is that those approaches aren't worth pursuing, and it would be better to wait to set up comprehensive test coverage for the uninstall bugs in this package ([JDK-8278620](https://bugs.openjdk.java.net/browse/JDK-8278620)), I'm happy to drop these PRs.

Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6603


From duke at openjdk.java.net  Wed Mar  2 20:33:53 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Wed, 2 Mar 2022 20:33:53 GMT
Subject: RFR: 8281284 : Write JSlider accessibility test [v3]
In-Reply-To: <VB8Ldq_d1uZBKpyvvDlu7t9lUtAd_WhLl4meSv46ixo=.b8b023ee-6946-407d-8e05-223fb2d95062@github.com>
References: <VB8Ldq_d1uZBKpyvvDlu7t9lUtAd_WhLl4meSv46ixo=.b8b023ee-6946-407d-8e05-223fb2d95062@github.com>
Message-ID: <hmyE7Cl15-xC5nEWEXiEJNDsreygA6vDFD55mhSw08w=.02b3fa70-52ae-41f7-a26f-cae0a134d34b@github.com>

> This testcase covers both old and new api ( api added in jdk17  getAccessibleAction(), getAccessibleActionCount() , getAccessibleActionDescription )
> 
> @shurymury 
> @savoptik

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  Add JSlider accessibility test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7355/files
  - new: https://git.openjdk.java.net/jdk/pull/7355/files/0e1f269f..cc0f6e41

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7355&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7355&range=01-02

  Stats: 344 lines in 2 files changed: 96 ins; 248 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7355.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7355/head:pull/7355

PR: https://git.openjdk.java.net/jdk/pull/7355


From duke at openjdk.java.net  Wed Mar  2 20:33:54 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Wed, 2 Mar 2022 20:33:54 GMT
Subject: RFR: 8281284 : Write JSlider accessibility test [v2]
In-Reply-To: <7VvKxnFl7P5VP0YzN9JRMhwNZTPShZHU8TKYQgxkW_k=.1a1d6447-19a3-4480-8ea6-1acd9632f8fc@github.com>
References: <VB8Ldq_d1uZBKpyvvDlu7t9lUtAd_WhLl4meSv46ixo=.b8b023ee-6946-407d-8e05-223fb2d95062@github.com>
 <WSyyvbDw4QhAeZBtTt4Njk0kn9gEjEnpyT62Gp3DDVs=.f72bd463-7ec0-498d-b3fb-b5ba392c42e3@github.com>
 <7VvKxnFl7P5VP0YzN9JRMhwNZTPShZHU8TKYQgxkW_k=.1a1d6447-19a3-4480-8ea6-1acd9632f8fc@github.com>
Message-ID: <VS8_CKH4iwzNGB4Jv15re93OLw0VX3FM0pGZZGmJQZ4=.bea996af-96f9-4ec3-98e0-b9ce0e39ef45@github.com>

On Sun, 6 Feb 2022 08:22:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added @key headful
>
> test/jdk/javax/accessibility/JSlider/JSliderAccessibilityTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2019, 2022 Oracle and/or its affiliates. All rights reserved.
> 
> Is it a new test or it is based on some old code?

fixed

> test/jdk/javax/accessibility/JSlider/JSliderAccessibilityTest.java line 125:
> 
>> 123:                 throw new RuntimeException("AccessibleStateSet shouldn't contain both HORIZONTAL and VERTICAL");
>> 124:             }
>> 125:             if (jSlider.getOrientation() != jSlider.HORIZONTAL) {
> 
> Shouldn't the test creates a sliders using different orientations?

converted the testcase to manual as suggested by savoptik

-------------

PR: https://git.openjdk.java.net/jdk/pull/7355


From duke at openjdk.java.net  Wed Mar  2 20:33:55 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Wed, 2 Mar 2022 20:33:55 GMT
Subject: RFR: 8281284 : Write JSlider accessibility test [v2]
In-Reply-To: <fZTkuYh4mgXB8VeCC67IyXEMZDzuuNrZizMH7h4z4So=.a0ddda63-d2cd-462a-bc35-6deef9e5d315@github.com>
References: <VB8Ldq_d1uZBKpyvvDlu7t9lUtAd_WhLl4meSv46ixo=.b8b023ee-6946-407d-8e05-223fb2d95062@github.com>
 <WSyyvbDw4QhAeZBtTt4Njk0kn9gEjEnpyT62Gp3DDVs=.f72bd463-7ec0-498d-b3fb-b5ba392c42e3@github.com>
 <4jjNGD2edw9UK5P1W1WMgthuJxr1y1bP1hkswXlt3Uo=.c477cd79-81ed-4af7-a1d8-2e3451b8284f@github.com>
 <fZTkuYh4mgXB8VeCC67IyXEMZDzuuNrZizMH7h4z4So=.a0ddda63-d2cd-462a-bc35-6deef9e5d315@github.com>
Message-ID: <Goi_9-1a0nCF3eAF65_hiRgkfVIy5iQ8ogXO9GymB84=.568e0a08-d062-43ad-8d9b-92da8e6ddea3@github.com>

On Wed, 23 Feb 2022 02:03:24 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> test/jdk/javax/accessibility/JSlider/JSliderAccessibilityTest.java line 68:
>> 
>>> 66:         frame.setLocationRelativeTo(null);
>>> 67:         frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
>>> 68:         frame.setVisible(true);
>> 
>> Please add instructions to the test on how to take it on all intended platforms. And also when to consider that the test is passed correctly.
>
> @savoptik this is automated test. Are you suggesting me to change the test to manual ?

converted the test to manual

-------------

PR: https://git.openjdk.java.net/jdk/pull/7355


From duke at openjdk.java.net  Wed Mar  2 20:41:59 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Wed, 2 Mar 2022 20:41:59 GMT
Subject: RFR: 8281284 : Write JSlider accessibility test [v4]
In-Reply-To: <VB8Ldq_d1uZBKpyvvDlu7t9lUtAd_WhLl4meSv46ixo=.b8b023ee-6946-407d-8e05-223fb2d95062@github.com>
References: <VB8Ldq_d1uZBKpyvvDlu7t9lUtAd_WhLl4meSv46ixo=.b8b023ee-6946-407d-8e05-223fb2d95062@github.com>
Message-ID: <Oiv65B9ZpLWGXaBpmeWVoPGXEGOghZdozSx5-_zXhG8=.520f99d1-24ee-4967-b4d1-06e60f6ee8ff@github.com>

> This testcase covers both old and new api ( api added in jdk17  getAccessibleAction(), getAccessibleActionCount() , getAccessibleActionDescription )
> 
> @shurymury 
> @savoptik

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  Fixed the white character

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7355/files
  - new: https://git.openjdk.java.net/jdk/pull/7355/files/cc0f6e41..563e41e9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7355&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7355&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7355.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7355/head:pull/7355

PR: https://git.openjdk.java.net/jdk/pull/7355


From prr at openjdk.java.net  Wed Mar  2 20:59:45 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 2 Mar 2022 20:59:45 GMT
Subject: RFR: 8282577: ICC_Profile.setTagData() invalidates the profile
Message-ID: <ecPAoejPCnfczdYoQmH89792PmRZxg4Rc5LaEHlsnXo=.3ad1b170-e862-4322-9164-df0501b298a0@github.com>

As per the bug eval, we are returning a pointer to a native raw LittleCMS profile and it should be a cooked one.
The simple test fails before the fix with
~/jdk17/Contents/Home/bin/java SetTagDataValidation                               
Exception in thread "main" java.awt.color.CMMException: LCMS error 13: Couldn't link the profiles
	at java.desktop/sun.java2d.cmm.lcms.LCMS.createNativeTransform(Native Method)
	at java.desktop/sun.java2d.cmm.lcms.LCMS.createTransform(LCMS.java:104)
	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.doTransform(LCMSTransform.java:143)
	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.colorConvert(LCMSTransform.java:633)
	at java.desktop/java.awt.color.ICC_ColorSpace.toRGB(ICC_ColorSpace.java:224)
	at SetTagDataValidation.main(SetTagDataValidation.java:61)

and with the fix  just prints 
java SetTagDataValidation
0.4
0.5000076
0.6

-------------

Commit messages:
 - 8282577: ICC_Profile.setTagData() invalidates the profile

Changes: https://git.openjdk.java.net/jdk/pull/7668/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7668&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282577
  Stats: 79 lines in 2 files changed: 77 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7668.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7668/head:pull/7668

PR: https://git.openjdk.java.net/jdk/pull/7668


From prr at openjdk.java.net  Wed Mar  2 23:17:05 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 2 Mar 2022 23:17:05 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack
In-Reply-To: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
Message-ID: <XKieA-webWAuC43kHFQbwVUcGlHbluLooOWeSoq3NCA=.ba301c32-83d6-4228-b3c6-5e483cf6831c@github.com>

On Tue, 1 Mar 2022 08:31:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts

There's no chaining mechanism in the way you describe it .. it would have to be in our fallback list.

Batang and Gulim are the fonts that have been available since .. well at least XP.

https://docs.microsoft.com/en-us/typography/font-list/batang

https://docs.microsoft.com/en-us/typography/font-list/gulim

Malun Gothic only came in with Windows 7 :-
https://docs.microsoft.com/en-us/typography/font-list/malgun-gothic

I think it reasonable to put malun.ttf in the "allfonts" as a fallback  if it really is pre-installed on ALL systems.

But actual Korean users really should be installing the Korean font pack regardless and then
we should pick the best available font. Maybe its the new ones now.

Replacing them would not have been possible in the past but now Vista isn't supported

Note that Gulim is a Sans Serif font, Batang a Serif font.
Malun Gothic is described as suitable for on screen display - it sounds like a replacement for Gulim
but not for Batang so it is correct you aren't replacing that.
But is there a new Serif font available too ?
Please investigate / check.

And it seems (ah I see Naoto spotted this too) there is a Bold version of
Malgun Gothic in its own ttf file : Malgunbd.ttf So we should start using that.
To your point about it not being in the pre-installed fonts it doesn't matter for the reason I gave.

One other thing you are going to have to check is the rendering of other scripts when running in a Korean locale.

Batang lists support for Arabic .. Malun does not .. but then neither does Gulim .. so it may be no worse.

But sequence.fallback doesn't have any obvious Arabic support.
We used to be able to count on Lucida Sans for that .. but may be there's another gap there.
Mainly make sure you don't increase that gap.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From smandalika at openjdk.java.net  Thu Mar  3 03:30:10 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Thu, 3 Mar 2022 03:30:10 GMT
Subject: Integrated: 8281569: Create tests for Frame.setMinimumSize() method
In-Reply-To: <nSHmEKVtW-ErNDdAP0Xh0QSaRbBg4yA9ZvSoqi7XtMg=.7690f96d-3d0d-4fda-bb58-0ce641d465d9@github.com>
References: <nSHmEKVtW-ErNDdAP0Xh0QSaRbBg4yA9ZvSoqi7XtMg=.7690f96d-3d0d-4fda-bb58-0ce641d465d9@github.com>
Message-ID: <2dhv8XQthaOzrB8Oqz7BAMTDDEwuMBSvLf7NM3yBD1g=.7ee7952e-032e-47fb-8cf1-d7637ecf9d06@github.com>

On Fri, 11 Feb 2022 17:28:09 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Create tests for setMinimumSize functionality
> Create a test which verifies that on increasing the Frame's minimumSize, it gets reflected in the subsequent getSize call
> Create a test which verifies that on frame resizes back to minimumSize on calling pack.

This pull request has now been integrated.

Changeset: d0eb6fa2
Author:    Srinivas Mandalika <smandalika at openjdk.org>
Committer: Abdul Kolarkunnu <akolarkunnu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d0eb6fa2204c4112ef57ffa7579e209ebee62551
Stats:     185 lines in 2 files changed: 185 ins; 0 del; 0 mod

8281569: Create tests for Frame.setMinimumSize() method

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/7444


From mvs at openjdk.java.net  Thu Mar  3 06:19:36 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Thu, 3 Mar 2022 06:19:36 GMT
Subject: RFR: 8282402: Create a regression test for JDK-4666101 [v2]
In-Reply-To: <EQKuFYhNKfKTbojYCvsUi5xv2ID2b2Jv70h2BEe56jg=.59196b83-8851-4004-9211-807f239e5045@github.com>
References: <EQKuFYhNKfKTbojYCvsUi5xv2ID2b2Jv70h2BEe56jg=.59196b83-8851-4004-9211-807f239e5045@github.com>
Message-ID: <ys1Yg3FVOXzKVNUI4eqPtiaGg9t0_1yNzQwzGwJ65WM=.a1131650-a609-437a-bccb-a02ee64d04cd@github.com>

> Create a regression test for [JDK-4666101](https://bugs.openjdk.java.net/browse/JDK-4666101).
> 
> DESCRIPTION OF THE ACTUAL PROBLEM :
> In a JEditorPane, the down arrow has no effect after you add text on a line preceding a blank line.
> 
> Testing:
> As the original issue was reported in JDK 1.4.0 and it was fixed in JDK 1.4.2, I have verified the working of this test in those Java versions and the results are as follows:
> 
> Java 1.4.0 -> Test Failed.
> $ ./j2sdk1.4.0/bin/java JEditorBugWin
> Caret Updated : 3
> Test Failed, Down Arrow Key Not Functional, expected caret position is 5, but actual is 4
> 
> 
> Java 1.4.2 -> Test Passed.
> $ ./j2sdk1.4.2/bin/java JEditorBugWin
> Caret Updated : 5
> Test Passed, Down Arrow Key Functional

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Take a screenshot when the test fails, helpful for debugging failures

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7623/files
  - new: https://git.openjdk.java.net/jdk/pull/7623/files/95148f72..5dec2a8a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7623&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7623&range=00-01

  Stats: 18 lines in 1 file changed: 18 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7623.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7623/head:pull/7623

PR: https://git.openjdk.java.net/jdk/pull/7623


From psadhukhan at openjdk.java.net  Thu Mar  3 07:45:46 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 3 Mar 2022 07:45:46 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v2]
In-Reply-To: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
Message-ID: <3F6rwtKnmNxHmNk_JwNo-ovGQCtROCOTqq9JYEkxCnU=.715f8bd7-4df9-47dc-85f3-a598d01e8e78@github.com>

> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Add bold version

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7643/files
  - new: https://git.openjdk.java.net/jdk/pull/7643/files/0066bfd5..9c098f99

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7643&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7643&range=00-01

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7643.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7643/head:pull/7643

PR: https://git.openjdk.java.net/jdk/pull/7643


From psadhukhan at openjdk.java.net  Thu Mar  3 07:50:05 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 3 Mar 2022 07:50:05 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack
In-Reply-To: <XKieA-webWAuC43kHFQbwVUcGlHbluLooOWeSoq3NCA=.ba301c32-83d6-4228-b3c6-5e483cf6831c@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <XKieA-webWAuC43kHFQbwVUcGlHbluLooOWeSoq3NCA=.ba301c32-83d6-4228-b3c6-5e483cf6831c@github.com>
Message-ID: <Ie0Hc_efRCpzXXumHYnU4Z6GPUiDmSbgIU6aMnp3rxM=.4d04cf07-641d-471b-81a2-90b5ba6578b0@github.com>

On Wed, 2 Mar 2022 23:13:48 GMT, Phil Race <prr at openjdk.org> wrote:

> But is there a new Serif font available too ?

I could not find any replacement for Batang serif font so have kept it same.

> Bold version of Malgun Gothic in its own ttf file : Malgunbd.ttf So we should start using that

Added

> Arabic support.

Tested with java/awt/font/NumericShaper/EasternArabicTest and MTTest..Rendered same before and after this fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From mvs at openjdk.java.net  Thu Mar  3 09:06:05 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Thu, 3 Mar 2022 09:06:05 GMT
Subject: RFR: 8282343: Create a regression test for JDK-4518432
In-Reply-To: <rygpvWtk3UgIsffXwTUC6aTOGfOjfZRZexJaQmMLIGE=.d7ae758a-01bb-49dd-810f-1cd2b64cc326@github.com>
References: <rygpvWtk3UgIsffXwTUC6aTOGfOjfZRZexJaQmMLIGE=.d7ae758a-01bb-49dd-810f-1cd2b64cc326@github.com>
Message-ID: <bv3BIukTmOvyWk7zp8HkDs_8nQ4uSyk5JrTSvn_4dKc=.27f9aa79-90c9-423d-8417-d125297cf258@github.com>

On Thu, 24 Feb 2022 11:46:58 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Create a regression test for [JDK-4518432](https://bugs.openjdk.java.net/browse/JDK-4518432).
> 
> Issue: Copying from JTree and then changing the data in the component that was copied from, can cause pastes to use 
>            the new edited data.
> 
> This test verifies that copying from JTree node and then changing the data in the component that was copied from,
>  is not causing the pastes to use the new edited data instead of the original copied data.
> 
> Testing:
> Java 1.4.0 -> Test Failed.
> $ ./j2sdk1.4.0/bin/java JTreeWin
> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
> Test Failed in javax.swing.plaf.metal.MetalLookAndFeel, Expected : "colorsblue", but actual : "ctextolorsblue"
> Testing L&F: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> Test Failed in com.sun.java.swing.plaf.windows.WindowsLookAndFeel, Expected : "colorsblue", but actual : "ctextolorsblue"
> 
> Java 1.4.1 -> Test Passed.
> $ ./j2sdk1.4.1/bin/java JTreeWin
> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
> Test Passed in javax.swing.plaf.metal.MetalLookAndFeel
> Testing L&F: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> Test Passed in com.sun.java.swing.plaf.windows.WindowsLookAndFeel

@aivanov-jdk Can you please review this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7605


From mvs at openjdk.java.net  Thu Mar  3 09:06:06 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Thu, 3 Mar 2022 09:06:06 GMT
Subject: RFR: 8282402: Create a regression test for JDK-4666101 [v2]
In-Reply-To: <ys1Yg3FVOXzKVNUI4eqPtiaGg9t0_1yNzQwzGwJ65WM=.a1131650-a609-437a-bccb-a02ee64d04cd@github.com>
References: <EQKuFYhNKfKTbojYCvsUi5xv2ID2b2Jv70h2BEe56jg=.59196b83-8851-4004-9211-807f239e5045@github.com>
 <ys1Yg3FVOXzKVNUI4eqPtiaGg9t0_1yNzQwzGwJ65WM=.a1131650-a609-437a-bccb-a02ee64d04cd@github.com>
Message-ID: <1rNUgM39ccKhEH1T_7Y8kHqEX4y85NyJS2PoMr3djHE=.a21d4f7a-e011-4fdd-bc5e-f5617838eeb6@github.com>

On Thu, 3 Mar 2022 06:19:36 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Create a regression test for [JDK-4666101](https://bugs.openjdk.java.net/browse/JDK-4666101).
>> 
>> DESCRIPTION OF THE ACTUAL PROBLEM :
>> In a JEditorPane, the down arrow has no effect after you add text on a line preceding a blank line.
>> 
>> Testing:
>> As the original issue was reported in JDK 1.4.0 and it was fixed in JDK 1.4.2, I have verified the working of this test in those Java versions and the results are as follows:
>> 
>> Java 1.4.0 -> Test Failed.
>> $ ./j2sdk1.4.0/bin/java JEditorBugWin
>> Caret Updated : 3
>> Test Failed, Down Arrow Key Not Functional, expected caret position is 5, but actual is 4
>> 
>> 
>> Java 1.4.2 -> Test Passed.
>> $ ./j2sdk1.4.2/bin/java JEditorBugWin
>> Caret Updated : 5
>> Test Passed, Down Arrow Key Functional
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Take a screenshot when the test fails, helpful for debugging failures

@aivanov-jdk Can you please review this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7623


From psadhukhan at openjdk.java.net  Thu Mar  3 09:54:13 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 3 Mar 2022 09:54:13 GMT
Subject: Integrated: 8037965: NullPointerException in
 TextLayout.getBaselineFromGraphic() for JTextComponents
In-Reply-To: <l_eWkMXRIx0Jndkm2T21CVF0StbfoVcqXmNZBSSIPeM=.ba82ab91-de31-4d72-9019-b573e4b45923@github.com>
References: <l_eWkMXRIx0Jndkm2T21CVF0StbfoVcqXmNZBSSIPeM=.ba82ab91-de31-4d72-9019-b573e4b45923@github.com>
Message-ID: <9q7yeKpWiKVcnO4mRDBldtuVpwftDCKD0_-oXMtqbmI=.0cc408cf-4923-4fc3-b05a-211eb8bc53b3@github.com>

On Wed, 16 Feb 2022 07:44:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> When invalid unicode codepoints 0xFFFF and 0x10000 are added to an empty javax.swing.JTextComponent (JTextArea or JTextField), the view cannot be updated due to a NullPointerException in TextLayout.getBaselineFromGraphic() 
> owing to the fact GraphicAttribute is null for these invalid codepoints. 
> 
> TextLayout.getBaselineFromGraphic() is called from [TextLayout.standardInit](https://github.com/openjdk/jdk/blame/master/src/java.desktop/share/classes/java/awt/font/TextLayout.java#L647) and [TextMeasurer.initAll](https://github.com/openjdk/jdk/blame/master/src/java.desktop/share/classes/java/awt/font/TextMeasurer.java#L249) where it relies on CHAR_REPLACEMENT TextAttribute 
> and its spec says "The default value is null, indicating that the standard glyphs provided by the font should be used. " so if invalid codepoints is used, the default value is not changed so we need to be ready for null value too.
> 
> Since TextAttribute_CHAR_REPLACEMENT says "It is required for correct positioning of 'inline' components within a line when bidirectional reordering is performed. Each character (Unicode code point) will be rendered using the provided GraphicAttribute." so 
> Fixed by checking if GraphicAttribute is null, then keep the baseline to default value (which is 0) by returning default baseline (which is ROMAN_BASELINE)
> 
> Existing jtreg,jck tests are green.

This pull request has now been integrated.

Changeset: 0402a288
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0402a288f309d589d1dc8860e95e4ed42a1ef9f4
Stats:     41 lines in 2 files changed: 41 ins; 0 del; 0 mod

8037965: NullPointerException in TextLayout.getBaselineFromGraphic() for JTextComponents

Reviewed-by: prr, aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/7490


From psadhukhan at openjdk.java.net  Thu Mar  3 09:57:10 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 3 Mar 2022 09:57:10 GMT
Subject: Integrated: 6911375: mouseWheel has no effect without vertical
 scrollbar
In-Reply-To: <LRiJrIRXEEKyRk3kJGxpiYdjaM3e0clEM8686zpgLDI=.9a4d9f5f-bf67-471a-9c0d-b90289dc123a@github.com>
References: <LRiJrIRXEEKyRk3kJGxpiYdjaM3e0clEM8686zpgLDI=.9a4d9f5f-bf67-471a-9c0d-b90289dc123a@github.com>
Message-ID: <EuFgP4gctNIwsN2I8GFVY-0Z7m--XRbQw5U1G8ICuJc=.5e99b3ca-7094-4502-82c2-7a355692b5c4@github.com>

On Wed, 23 Feb 2022 04:24:41 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It is observed that mouseWheel doesn't scroll through a list if there is no scrollbar even though pressing PageUp/Down using keyboard moves up/down the list.
> Issue stems from the fact that BasicScrollPaneUI.Handler.mouseWheelMoved() skips the mouse wheel events when the scrollbar is not visible. 
> Fixed to handle mouseWheelEvent even though scrollbar is not visible with the assumption that if both vertical and horizontal scrollbar is not visible, then assume default orientation to be vertical.
> 
> Existing jtreg, jck tests are ok. All L&F works well with the fix and testcase works in all platforms except on mac which will be handled separately.

This pull request has now been integrated.

Changeset: 832729b4
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/832729b41e690d6f05da71997bbe2a74b2d6dada
Stats:     138 lines in 2 files changed: 135 ins; 1 del; 2 mod

6911375: mouseWheel has no effect without vertical scrollbar

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/7585


From psadhukhan at openjdk.java.net  Thu Mar  3 12:33:23 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 3 Mar 2022 12:33:23 GMT
Subject: RFR: 8282602: Refactor java/awt classes javadoc to use @throws instead
 of @exception
Message-ID: <FVJL0ITAodybntUy2Ro7w5FmBxCQXDhgEZSckEcpW8o=.f25b6a6a-78b4-4c07-90d6-cb506cd73d87@github.com>

Prevailing JDK coding practices use "@throws" rather than "@exception".
Refactor existing java/awt classes javadoc to use @throws

-------------

Commit messages:
 - Fix
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/7675/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7675&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282602
  Stats: 350 lines in 73 files changed: 0 ins; 0 del; 350 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7675.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7675/head:pull/7675

PR: https://git.openjdk.java.net/jdk/pull/7675


From aivanov at openjdk.java.net  Thu Mar  3 15:39:06 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 3 Mar 2022 15:39:06 GMT
Subject: RFR: 8282402: Create a regression test for JDK-4666101 [v2]
In-Reply-To: <ys1Yg3FVOXzKVNUI4eqPtiaGg9t0_1yNzQwzGwJ65WM=.a1131650-a609-437a-bccb-a02ee64d04cd@github.com>
References: <EQKuFYhNKfKTbojYCvsUi5xv2ID2b2Jv70h2BEe56jg=.59196b83-8851-4004-9211-807f239e5045@github.com>
 <ys1Yg3FVOXzKVNUI4eqPtiaGg9t0_1yNzQwzGwJ65WM=.a1131650-a609-437a-bccb-a02ee64d04cd@github.com>
Message-ID: <31bO4g20K1sGmCiJoO3yJoDGLxunJ0C7lgiahDHU518=.e3b0566d-413a-43ce-b066-3e8744cb8b39@github.com>

On Thu, 3 Mar 2022 06:19:36 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Create a regression test for [JDK-4666101](https://bugs.openjdk.java.net/browse/JDK-4666101).
>> 
>> DESCRIPTION OF THE ACTUAL PROBLEM :
>> In a JEditorPane, the down arrow has no effect after you add text on a line preceding a blank line.
>> 
>> Testing:
>> As the original issue was reported in JDK 1.4.0 and it was fixed in JDK 1.4.2, I have verified the working of this test in those Java versions and the results are as follows:
>> 
>> Java 1.4.0 -> Test Failed.
>> $ ./j2sdk1.4.0/bin/java JEditorBugWin
>> Caret Updated : 3
>> Test Failed, Down Arrow Key Not Functional, expected caret position is 5, but actual is 4
>> 
>> 
>> Java 1.4.2 -> Test Passed.
>> $ ./j2sdk1.4.2/bin/java JEditorBugWin
>> Caret Updated : 5
>> Test Passed, Down Arrow Key Functional
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Take a screenshot when the test fails, helpful for debugging failures

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7623


From prr at openjdk.java.net  Thu Mar  3 16:10:08 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 3 Mar 2022 16:10:08 GMT
Subject: RFR: 8236907: JTable added to nested panels does not paint last
 visible row [v6]
In-Reply-To: <jah2oFNSLMeHahABUYh03HJQ35JI0aN0M_76t8rDI7Q=.9f27f09b-a826-4f29-a292-29d1fdfaa634@github.com>
References: <Xwc58NmkbNIShAkXmFRyiZrdhN-4EHh-r-FwswcULWw=.666e1d7b-b978-4dfb-8dc1-3dcf85f72cf8@github.com>
 <jah2oFNSLMeHahABUYh03HJQ35JI0aN0M_76t8rDI7Q=.9f27f09b-a826-4f29-a292-29d1fdfaa634@github.com>
Message-ID: <elPdPCi72AIc6f1Ai_M-KTuRtoSGKBB7A5ktaxU7ltY=.baad13d6-300d-4782-969c-903664ea7517@github.com>

On Tue, 22 Feb 2022 04:38:21 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> Issue in painting last row of JTable due to decrement in `MaxRow `during computation. Differences in `MaxRow `computation between `TablePrintable` and `BasicTableUI `class. The Bug is fixed in both the classes. Test Case added to validate the same.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8236907: JTable added to nested panels does not paint last

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7422


From mvs at openjdk.java.net  Thu Mar  3 16:16:50 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Thu, 3 Mar 2022 16:16:50 GMT
Subject: RFR: 8282402: Create a regression test for JDK-4666101 [v3]
In-Reply-To: <EQKuFYhNKfKTbojYCvsUi5xv2ID2b2Jv70h2BEe56jg=.59196b83-8851-4004-9211-807f239e5045@github.com>
References: <EQKuFYhNKfKTbojYCvsUi5xv2ID2b2Jv70h2BEe56jg=.59196b83-8851-4004-9211-807f239e5045@github.com>
Message-ID: <eyLJO4c2gSYAb17y5pBx-yipSSqKOOe7jXd2wGPZbOs=.7a2f68a7-cbf4-4337-bd64-9799a2309ebd@github.com>

> Create a regression test for [JDK-4666101](https://bugs.openjdk.java.net/browse/JDK-4666101).
> 
> DESCRIPTION OF THE ACTUAL PROBLEM :
> In a JEditorPane, the down arrow has no effect after you add text on a line preceding a blank line.
> 
> Testing:
> As the original issue was reported in JDK 1.4.0 and it was fixed in JDK 1.4.2, I have verified the working of this test in those Java versions and the results are as follows:
> 
> Java 1.4.0 -> Test Failed.
> $ ./j2sdk1.4.0/bin/java JEditorBugWin
> Caret Updated : 3
> Test Failed, Down Arrow Key Not Functional, expected caret position is 5, but actual is 4
> 
> 
> Java 1.4.2 -> Test Passed.
> $ ./j2sdk1.4.2/bin/java JEditorBugWin
> Caret Updated : 5
> Test Passed, Down Arrow Key Functional

Manukumar V S has updated the pull request incrementally with two additional commits since the last revision:

 - Removed one extra blank line before import static
 - Review comments fixed: Formatting changes, removed extra blank lines, removed casting for jEditorLoc.x

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7623/files
  - new: https://git.openjdk.java.net/jdk/pull/7623/files/5dec2a8a..dc26ec28

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7623&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7623&range=01-02

  Stats: 12 lines in 1 file changed: 1 ins; 8 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7623.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7623/head:pull/7623

PR: https://git.openjdk.java.net/jdk/pull/7623


From naoto at openjdk.java.net  Thu Mar  3 17:09:01 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 3 Mar 2022 17:09:01 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v2]
In-Reply-To: <3F6rwtKnmNxHmNk_JwNo-ovGQCtROCOTqq9JYEkxCnU=.715f8bd7-4df9-47dc-85f3-a598d01e8e78@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <3F6rwtKnmNxHmNk_JwNo-ovGQCtROCOTqq9JYEkxCnU=.715f8bd7-4df9-47dc-85f3-a598d01e8e78@github.com>
Message-ID: <xXdQHvNMku2qsBap1OkjuissD1y0v73EmiikAF61yrA=.3557992d-2209-42b5-97d6-4f5cbe3943d8@github.com>

On Thu, 3 Mar 2022 07:45:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add bold version

OK, so there is no way to chain the physical fonts.
One other thing I noticed was that `GulimChe` is a `monospaced` font, so I would also leave it for `monospaced` properties, as `Malgun Gothic` is a proportional font.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From duke at openjdk.java.net  Thu Mar  3 17:11:39 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 3 Mar 2022 17:11:39 GMT
Subject: RFR: 8281284 : Write JSlider accessibility test [v5]
In-Reply-To: <VB8Ldq_d1uZBKpyvvDlu7t9lUtAd_WhLl4meSv46ixo=.b8b023ee-6946-407d-8e05-223fb2d95062@github.com>
References: <VB8Ldq_d1uZBKpyvvDlu7t9lUtAd_WhLl4meSv46ixo=.b8b023ee-6946-407d-8e05-223fb2d95062@github.com>
Message-ID: <WvwD8UFahxh4RyMHJIMuXrRQvc225Lo9QKKXY5qbRK0=.36eaafd9-7f1d-4686-bada-b81b91dbbf8e@github.com>

> This testcase covers both old and new api ( api added in jdk17  getAccessibleAction(), getAccessibleActionCount() , getAccessibleActionDescription )
> 
> @shurymury 
> @savoptik

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  run the on windows and mac

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7355/files
  - new: https://git.openjdk.java.net/jdk/pull/7355/files/563e41e9..b815681d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7355&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7355&range=03-04

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7355.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7355/head:pull/7355

PR: https://git.openjdk.java.net/jdk/pull/7355


From prr at openjdk.java.net  Thu Mar  3 18:11:05 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 3 Mar 2022 18:11:05 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v2]
In-Reply-To: <xXdQHvNMku2qsBap1OkjuissD1y0v73EmiikAF61yrA=.3557992d-2209-42b5-97d6-4f5cbe3943d8@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <3F6rwtKnmNxHmNk_JwNo-ovGQCtROCOTqq9JYEkxCnU=.715f8bd7-4df9-47dc-85f3-a598d01e8e78@github.com>
 <xXdQHvNMku2qsBap1OkjuissD1y0v73EmiikAF61yrA=.3557992d-2209-42b5-97d6-4f5cbe3943d8@github.com>
Message-ID: <s_HQHE4CN84wdv0RqslSkfEvAkOdCbeuetUYOpy5_I0=.974288fa-24d5-49c0-b941-e58c40608d01@github.com>

On Thu, 3 Mar 2022 17:05:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> OK, so there is no way to chain the physical fonts.
> One other thing I noticed was that `GulimChe` is a `monospaced` font, so I would also leave it for `monospaced` properties, as `Malgun Gothic` is a proportional font.

Good point.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From prr at openjdk.java.net  Thu Mar  3 18:11:05 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 3 Mar 2022 18:11:05 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v2]
In-Reply-To: <3F6rwtKnmNxHmNk_JwNo-ovGQCtROCOTqq9JYEkxCnU=.715f8bd7-4df9-47dc-85f3-a598d01e8e78@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <3F6rwtKnmNxHmNk_JwNo-ovGQCtROCOTqq9JYEkxCnU=.715f8bd7-4df9-47dc-85f3-a598d01e8e78@github.com>
Message-ID: <cMKcpdy-o1jKXIv336E7035DANl6X-xs6h6ER4TaaYA=.b80a5175-81bd-4516-92ef-2e1ccc075643@github.com>

On Thu, 3 Mar 2022 07:45:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add bold version

make/data/fontconfig/windows.fontconfig.properties line 169:

> 167: dialog.bolditalic.hebrew=David Bold
> 168: dialog.bolditalic.japanese=MS Gothic
> 169: dialog.bolditalic.korean=Malgun Gothic

You should use the Bold version of the font here too - ie for bold italic - not just for bold - since it is clearly closer ..

make/data/fontconfig/windows.fontconfig.properties line 184:

> 182: dialoginput.bold.japanese=MS Gothic
> 183: dialoginput.bold.korean=Malgun Gothic Bold
> 184: 

Since dialoginput is usually the same as monospaced, per Naoto's comment, this should be reverted.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From aivanov at openjdk.java.net  Thu Mar  3 18:12:02 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 3 Mar 2022 18:12:02 GMT
Subject: RFR: 8282343: Create a regression test for JDK-4518432
In-Reply-To: <rygpvWtk3UgIsffXwTUC6aTOGfOjfZRZexJaQmMLIGE=.d7ae758a-01bb-49dd-810f-1cd2b64cc326@github.com>
References: <rygpvWtk3UgIsffXwTUC6aTOGfOjfZRZexJaQmMLIGE=.d7ae758a-01bb-49dd-810f-1cd2b64cc326@github.com>
Message-ID: <n8Oa5TP5i3XJQHWsmz414VJeUBi-d50QNjmhnRhIg7M=.d09f152a-16eb-4f97-9c45-3aee7a677954@github.com>

On Thu, 24 Feb 2022 11:46:58 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Create a regression test for [JDK-4518432](https://bugs.openjdk.java.net/browse/JDK-4518432).
> 
> Issue: Copying from JTree and then changing the data in the component that was copied from, can cause pastes to use 
>            the new edited data.
> 
> This test verifies that copying from JTree node and then changing the data in the component that was copied from,
>  is not causing the pastes to use the new edited data instead of the original copied data.
> 
> Testing:
> Java 1.4.0 -> Test Failed.
> $ ./j2sdk1.4.0/bin/java JTreeWin
> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
> Test Failed in javax.swing.plaf.metal.MetalLookAndFeel, Expected : "colorsblue", but actual : "ctextolorsblue"
> Testing L&F: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> Test Failed in com.sun.java.swing.plaf.windows.WindowsLookAndFeel, Expected : "colorsblue", but actual : "ctextolorsblue"
> 
> Java 1.4.1 -> Test Passed.
> $ ./j2sdk1.4.1/bin/java JTreeWin
> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
> Test Passed in javax.swing.plaf.metal.MetalLookAndFeel
> Testing L&F: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> Test Passed in com.sun.java.swing.plaf.windows.WindowsLookAndFeel

Marked as reviewed by aivanov (Reviewer).

test/jdk/javax/swing/JTree/4518432/JTreeNodeCopyPasteTest.java line 100:

> 98:                     throw new RuntimeException("Test Failed, waited too long, " +
> 99:                             "but the JTree can't gain focus for L&F: " + laf);
> 100:                 }

The tree is the only component on the frame. By default, it will get focus. The call to `waitForIdle` guarantees all the events are processed. Even if tree doesn't get focus, the next thing you do is click a node in the tree, which brings the focus.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7605


From aivanov at openjdk.java.net  Thu Mar  3 19:07:59 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 3 Mar 2022 19:07:59 GMT
Subject: RFR: 8282402: Create a regression test for JDK-4666101 [v3]
In-Reply-To: <eyLJO4c2gSYAb17y5pBx-yipSSqKOOe7jXd2wGPZbOs=.7a2f68a7-cbf4-4337-bd64-9799a2309ebd@github.com>
References: <EQKuFYhNKfKTbojYCvsUi5xv2ID2b2Jv70h2BEe56jg=.59196b83-8851-4004-9211-807f239e5045@github.com>
 <eyLJO4c2gSYAb17y5pBx-yipSSqKOOe7jXd2wGPZbOs=.7a2f68a7-cbf4-4337-bd64-9799a2309ebd@github.com>
Message-ID: <g1tLvk1NcqzgYfLpauvD4v0lYaMc9jT1l89liODvrrg=.7b2e3048-6a59-4e75-b668-cdf093ec592e@github.com>

On Thu, 3 Mar 2022 16:16:50 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Create a regression test for [JDK-4666101](https://bugs.openjdk.java.net/browse/JDK-4666101).
>> 
>> DESCRIPTION OF THE ACTUAL PROBLEM :
>> In a JEditorPane, the down arrow has no effect after you add text on a line preceding a blank line.
>> 
>> Testing:
>> As the original issue was reported in JDK 1.4.0 and it was fixed in JDK 1.4.2, I have verified the working of this test in those Java versions and the results are as follows:
>> 
>> Java 1.4.0 -> Test Failed.
>> $ ./j2sdk1.4.0/bin/java JEditorBugWin
>> Caret Updated : 3
>> Test Failed, Down Arrow Key Not Functional, expected caret position is 5, but actual is 4
>> 
>> 
>> Java 1.4.2 -> Test Passed.
>> $ ./j2sdk1.4.2/bin/java JEditorBugWin
>> Caret Updated : 5
>> Test Passed, Down Arrow Key Functional
>
> Manukumar V S has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Removed one extra blank line before import static
>  - Review comments fixed: Formatting changes, removed extra blank lines, removed casting for jEditorLoc.x

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7623


From mvs at openjdk.java.net  Thu Mar  3 19:33:07 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Thu, 3 Mar 2022 19:33:07 GMT
Subject: Integrated: 8282402: Create a regression test for JDK-4666101
In-Reply-To: <EQKuFYhNKfKTbojYCvsUi5xv2ID2b2Jv70h2BEe56jg=.59196b83-8851-4004-9211-807f239e5045@github.com>
References: <EQKuFYhNKfKTbojYCvsUi5xv2ID2b2Jv70h2BEe56jg=.59196b83-8851-4004-9211-807f239e5045@github.com>
Message-ID: <bvbrSocEzCUpz-1eejBd9eQkB1TZzB9B0VtpbKTI4P4=.d5c1890d-aad0-4b44-a87d-64ae9420bf19@github.com>

On Fri, 25 Feb 2022 15:37:10 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Create a regression test for [JDK-4666101](https://bugs.openjdk.java.net/browse/JDK-4666101).
> 
> DESCRIPTION OF THE ACTUAL PROBLEM :
> In a JEditorPane, the down arrow has no effect after you add text on a line preceding a blank line.
> 
> Testing:
> As the original issue was reported in JDK 1.4.0 and it was fixed in JDK 1.4.2, I have verified the working of this test in those Java versions and the results are as follows:
> 
> Java 1.4.0 -> Test Failed.
> $ ./j2sdk1.4.0/bin/java JEditorBugWin
> Caret Updated : 3
> Test Failed, Down Arrow Key Not Functional, expected caret position is 5, but actual is 4
> 
> 
> Java 1.4.2 -> Test Passed.
> $ ./j2sdk1.4.2/bin/java JEditorBugWin
> Caret Updated : 5
> Test Passed, Down Arrow Key Functional

This pull request has now been integrated.

Changeset: 1581e3fa
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1581e3faa06358f192799b3a89718028c7f6a24b
Stats:     197 lines in 1 file changed: 197 ins; 0 del; 0 mod

8282402: Create a regression test for JDK-4666101

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/7623


From aivanov at openjdk.java.net  Thu Mar  3 20:49:05 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 3 Mar 2022 20:49:05 GMT
Subject: RFR: 8015854: [macosx] JButton's HTML ImageView adding unwanted
 padding [v8]
In-Reply-To: <DgeMCQtzhqMoDpyf3LSagIZNmGafVtMtAi3d1rpE4xk=.afbd74d4-c78e-426e-b112-d87d25a05755@github.com>
References: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
 <DgeMCQtzhqMoDpyf3LSagIZNmGafVtMtAi3d1rpE4xk=.afbd74d4-c78e-426e-b112-d87d25a05755@github.com>
Message-ID: <Fy5r-0QeGQ5ziIJS066IdaMXfGwwXejMaGGP32-g8xo=.8e4388a6-ac4b-44b8-b5bc-2291e628133b@github.com>

On Tue, 1 Mar 2022 23:27:57 GMT, DamonGuy <duke at openjdk.java.net> wrote:

>> Html does not fit in JButton at certain sizes because default Insets cause html to be displayed off-center. 
>> 
>> Changes made to SwingUtilities.java layoutCompoundLabelImpl method to enable clipping if html does not fit, similar to regular text. AquaButtonUI.java now detects when html does not fit, and an implementation for alternate insets that are recursively tested for regular text inside layoutAndGetText() are now also being used for html content.
>> 
>> Created test (Bug8015854.java) with the same format as the test described on the issue. The button is of size 37x37 with an image of a red square sized 19x19. The test checks for red pixels on the edges of where the square image should be from the center of the button. The test fails with the non-changed jdk, but passes with the changes.
>
> DamonGuy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated test to be headless using BufferedImage.

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JButton/HtmlButtonImageTest/HtmlButtonImageTest.java line 42:

> 40: import java.io.IOException;
> 41: import java.io.File;
> 42: import javax.imageio.ImageIO;

Could you sort the imports, please? *Optimize Imports*  or a similar command in your IDE should do the magic.

test/jdk/javax/swing/JButton/HtmlButtonImageTest/HtmlButtonImageTest.java line 68:

> 66: 
> 67:         SwingUtilities.invokeAndWait(HtmlButtonImageTest::createButton);
> 68:         SwingUtilities.invokeAndWait(HtmlButtonImageTest::createImage);

`paintButton` would be clearer.

test/jdk/javax/swing/JButton/HtmlButtonImageTest/HtmlButtonImageTest.java line 100:

> 98:     }
> 99: 
> 100:     private static boolean checkRedness(int rgb) {

`checkRed` or `checkRedColor`?

test/jdk/javax/swing/JButton/HtmlButtonImageTest/HtmlButtonImageTest.java line 114:

> 112:         System.out.println("Passed");
> 113:     }
> 114: }

It's usually recommended to end the file with a new line.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7310


From prr at openjdk.java.net  Thu Mar  3 20:59:45 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 3 Mar 2022 20:59:45 GMT
Subject: RFR: 8282577: ICC_Profile.setTagData() invalidates the profile
 [v2]
In-Reply-To: <ecPAoejPCnfczdYoQmH89792PmRZxg4Rc5LaEHlsnXo=.3ad1b170-e862-4322-9164-df0501b298a0@github.com>
References: <ecPAoejPCnfczdYoQmH89792PmRZxg4Rc5LaEHlsnXo=.3ad1b170-e862-4322-9164-df0501b298a0@github.com>
Message-ID: <GGRZZUEdvlvAmpMvXIpjjqtcmwXQhMmvXtG-DCyPpxU=.82d001fb-dc00-437e-afa9-1b93f3d9e091@github.com>

> As per the bug eval, we are returning a pointer to a native raw LittleCMS profile and it should be a cooked one.
> The simple test fails before the fix with
> ~/jdk17/Contents/Home/bin/java SetTagDataValidation                               
> Exception in thread "main" java.awt.color.CMMException: LCMS error 13: Couldn't link the profiles
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createNativeTransform(Native Method)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createTransform(LCMS.java:104)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.doTransform(LCMSTransform.java:143)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.colorConvert(LCMSTransform.java:633)
> 	at java.desktop/java.awt.color.ICC_ColorSpace.toRGB(ICC_ColorSpace.java:224)
> 	at SetTagDataValidation.main(SetTagDataValidation.java:61)
> 
> and with the fix  just prints 
> java SetTagDataValidation
> 0.4
> 0.5000076
> 0.6

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8282577: ICC_Profile.setTagData() invalidates the profile

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7668/files
  - new: https://git.openjdk.java.net/jdk/pull/7668/files/e46c65c1..2ecf8211

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7668&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7668&range=00-01

  Stats: 7 lines in 2 files changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7668.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7668/head:pull/7668

PR: https://git.openjdk.java.net/jdk/pull/7668


From prr at openjdk.java.net  Thu Mar  3 21:27:36 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 3 Mar 2022 21:27:36 GMT
Subject: RFR: 8282577: ICC_Profile.setData(int,
 byte[]) invalidates the profile [v3]
In-Reply-To: <ecPAoejPCnfczdYoQmH89792PmRZxg4Rc5LaEHlsnXo=.3ad1b170-e862-4322-9164-df0501b298a0@github.com>
References: <ecPAoejPCnfczdYoQmH89792PmRZxg4Rc5LaEHlsnXo=.3ad1b170-e862-4322-9164-df0501b298a0@github.com>
Message-ID: <XTG2b5zZA9u3_Km2pJCA3xCsJzJl_tjOfnXGNunixgY=.c92ea820-38bc-4668-b8cc-350915a6fc7a@github.com>

> As per the bug eval, we are returning a pointer to a native raw LittleCMS profile and it should be a cooked one.
> The simple test fails before the fix with
> ~/jdk17/Contents/Home/bin/java SetTagDataValidation                               
> Exception in thread "main" java.awt.color.CMMException: LCMS error 13: Couldn't link the profiles
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createNativeTransform(Native Method)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createTransform(LCMS.java:104)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.doTransform(LCMSTransform.java:143)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.colorConvert(LCMSTransform.java:633)
> 	at java.desktop/java.awt.color.ICC_ColorSpace.toRGB(ICC_ColorSpace.java:224)
> 	at SetTagDataValidation.main(SetTagDataValidation.java:61)
> 
> and with the fix  just prints 
> java SetTagDataValidation
> 0.4
> 0.5000076
> 0.6

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8282577: ICC_Profile.setData(int, byte[]) invalidates the profile

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7668/files
  - new: https://git.openjdk.java.net/jdk/pull/7668/files/2ecf8211..5bf31b11

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7668&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7668&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7668.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7668/head:pull/7668

PR: https://git.openjdk.java.net/jdk/pull/7668


From duke at openjdk.java.net  Thu Mar  3 21:27:45 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Thu, 3 Mar 2022 21:27:45 GMT
Subject: RFR: 8015854: [macosx] JButton's HTML ImageView adding unwanted
 padding [v9]
In-Reply-To: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
References: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
Message-ID: <OwPC-VaHbRkOx7x_AY5rKgx1vUO_NK8M19y2mh6_hM0=.52fe5c95-71b5-4ba5-a6b0-25af7200cd9c@github.com>

> Html does not fit in JButton at certain sizes because default Insets cause html to be displayed off-center. 
> 
> Changes made to SwingUtilities.java layoutCompoundLabelImpl method to enable clipping if html does not fit, similar to regular text. AquaButtonUI.java now detects when html does not fit, and an implementation for alternate insets that are recursively tested for regular text inside layoutAndGetText() are now also being used for html content.
> 
> Created test (Bug8015854.java) with the same format as the test described on the issue. The button is of size 37x37 with an image of a red square sized 19x19. The test checks for red pixels on the edges of where the square image should be from the center of the button. The test fails with the non-changed jdk, but passes with the changes.

DamonGuy has updated the pull request incrementally with one additional commit since the last revision:

  Organized imports. Renamed functions for clarity. Added newline at end.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7310/files
  - new: https://git.openjdk.java.net/jdk/pull/7310/files/dd8599ce..1a885b7b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7310&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7310&range=07-08

  Stats: 16 lines in 1 file changed: 5 ins; 5 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7310.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7310/head:pull/7310

PR: https://git.openjdk.java.net/jdk/pull/7310


From prr at openjdk.java.net  Thu Mar  3 21:44:00 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 3 Mar 2022 21:44:00 GMT
Subject: RFR: 8282577: ICC_Profile.setData(int,
 byte[]) invalidates the profile [v3]
In-Reply-To: <XTG2b5zZA9u3_Km2pJCA3xCsJzJl_tjOfnXGNunixgY=.c92ea820-38bc-4668-b8cc-350915a6fc7a@github.com>
References: <ecPAoejPCnfczdYoQmH89792PmRZxg4Rc5LaEHlsnXo=.3ad1b170-e862-4322-9164-df0501b298a0@github.com>
 <XTG2b5zZA9u3_Km2pJCA3xCsJzJl_tjOfnXGNunixgY=.c92ea820-38bc-4668-b8cc-350915a6fc7a@github.com>
Message-ID: <Ne67azqOcQz4M7Aqu8R2pmbfdY6F1YjRH5XBQRFN3AE=.318ae18f-6f55-4764-8c3c-9a9f528afe00@github.com>

On Thu, 3 Mar 2022 21:27:36 GMT, Phil Race <prr at openjdk.org> wrote:

>> As per the bug eval, we are returning a pointer to a native raw LittleCMS profile and it should be a cooked one.
>> The simple test fails before the fix with
>> ~/jdk17/Contents/Home/bin/java SetTagDataValidation                               
>> Exception in thread "main" java.awt.color.CMMException: LCMS error 13: Couldn't link the profiles
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createNativeTransform(Native Method)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createTransform(LCMS.java:104)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.doTransform(LCMSTransform.java:143)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.colorConvert(LCMSTransform.java:633)
>> 	at java.desktop/java.awt.color.ICC_ColorSpace.toRGB(ICC_ColorSpace.java:224)
>> 	at SetTagDataValidation.main(SetTagDataValidation.java:61)
>> 
>> and with the fix  just prints 
>> java SetTagDataValidation
>> 0.4
>> 0.5000076
>> 0.6
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282577: ICC_Profile.setData(int, byte[]) invalidates the profile

I have added the problem listing of a test sun/java2d/cmm/ReadWriteProfileTest.java
https://bugs.openjdk.java.net/browse/JDK-8282635

The test would not have been passing if the profile were actually validated and it looks like there's various issues to be solved - if possible.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7668


From aivanov at openjdk.java.net  Thu Mar  3 21:57:08 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 3 Mar 2022 21:57:08 GMT
Subject: RFR: 8015854: [macosx] JButton's HTML ImageView adding unwanted
 padding [v9]
In-Reply-To: <OwPC-VaHbRkOx7x_AY5rKgx1vUO_NK8M19y2mh6_hM0=.52fe5c95-71b5-4ba5-a6b0-25af7200cd9c@github.com>
References: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
 <OwPC-VaHbRkOx7x_AY5rKgx1vUO_NK8M19y2mh6_hM0=.52fe5c95-71b5-4ba5-a6b0-25af7200cd9c@github.com>
Message-ID: <wcpnqTLbSokVemp2VokOYi2I_fagf1cJk9JLclJSBvw=.1dceec86-4302-4420-9899-e9d1dc70af89@github.com>

On Thu, 3 Mar 2022 21:27:45 GMT, DamonGuy <duke at openjdk.java.net> wrote:

>> Html does not fit in JButton at certain sizes because default Insets cause html to be displayed off-center. 
>> 
>> Changes made to SwingUtilities.java layoutCompoundLabelImpl method to enable clipping if html does not fit, similar to regular text. AquaButtonUI.java now detects when html does not fit, and an implementation for alternate insets that are recursively tested for regular text inside layoutAndGetText() are now also being used for html content.
>> 
>> Created test (Bug8015854.java) with the same format as the test described on the issue. The button is of size 37x37 with an image of a red square sized 19x19. The test checks for red pixels on the edges of where the square image should be from the center of the button. The test fails with the non-changed jdk, but passes with the changes.
>
> DamonGuy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Organized imports. Renamed functions for clarity. Added newline at end.

Looks good other than reversed method names to create a button and then paint the button into an image.

-------------

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7310


From aivanov at openjdk.java.net  Thu Mar  3 21:57:09 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 3 Mar 2022 21:57:09 GMT
Subject: RFR: 8015854: [macosx] JButton's HTML ImageView adding unwanted
 padding [v8]
In-Reply-To: <Fy5r-0QeGQ5ziIJS066IdaMXfGwwXejMaGGP32-g8xo=.8e4388a6-ac4b-44b8-b5bc-2291e628133b@github.com>
References: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
 <DgeMCQtzhqMoDpyf3LSagIZNmGafVtMtAi3d1rpE4xk=.afbd74d4-c78e-426e-b112-d87d25a05755@github.com>
 <Fy5r-0QeGQ5ziIJS066IdaMXfGwwXejMaGGP32-g8xo=.8e4388a6-ac4b-44b8-b5bc-2291e628133b@github.com>
Message-ID: <0gk2h41UhnL9rn15_XOGq7vtLxkjYN0Hy7IzqoYk7hc=.7d902cf9-600f-415a-94ed-5c90e5d76c2e@github.com>

On Thu, 3 Mar 2022 20:42:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> DamonGuy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated test to be headless using BufferedImage.
>
> test/jdk/javax/swing/JButton/HtmlButtonImageTest/HtmlButtonImageTest.java line 68:
> 
>> 66: 
>> 67:         SwingUtilities.invokeAndWait(HtmlButtonImageTest::createButton);
>> 68:         SwingUtilities.invokeAndWait(HtmlButtonImageTest::createImage);
> 
> `paintButton` would be clearer.

No, `createButton` then `paintButton` :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7310


From duke at openjdk.java.net  Thu Mar  3 22:51:48 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Thu, 3 Mar 2022 22:51:48 GMT
Subject: RFR: 8015854: [macosx] JButton's HTML ImageView adding unwanted
 padding [v10]
In-Reply-To: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
References: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
Message-ID: <UCmQpKAK-Au3tEpSM9j7nePxcxWLAzoTTl2rBVAyBks=.4e46d6b8-521b-48bf-b7bf-a8c3a458f3da@github.com>

> Html does not fit in JButton at certain sizes because default Insets cause html to be displayed off-center. 
> 
> Changes made to SwingUtilities.java layoutCompoundLabelImpl method to enable clipping if html does not fit, similar to regular text. AquaButtonUI.java now detects when html does not fit, and an implementation for alternate insets that are recursively tested for regular text inside layoutAndGetText() are now also being used for html content.
> 
> Created test (Bug8015854.java) with the same format as the test described on the issue. The button is of size 37x37 with an image of a red square sized 19x19. The test checks for red pixels on the edges of where the square image should be from the center of the button. The test fails with the non-changed jdk, but passes with the changes.

DamonGuy has updated the pull request incrementally with two additional commits since the last revision:

 - Changed method name.
 - Reorganized imports. Added space in conditional.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7310/files
  - new: https://git.openjdk.java.net/jdk/pull/7310/files/1a885b7b..93f19ca2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7310&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7310&range=08-09

  Stats: 14 lines in 1 file changed: 6 ins; 5 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7310.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7310/head:pull/7310

PR: https://git.openjdk.java.net/jdk/pull/7310


From achung at openjdk.java.net  Fri Mar  4 00:49:39 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Fri, 4 Mar 2022 00:49:39 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v2]
In-Reply-To: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
Message-ID: <FekRgDLssGtJkXCN1Z-po6L4liDWivTfMM0SE2IOdSY=.6c5792c4-3d8f-49f4-a32f-99466c97ae6c@github.com>

> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping

Alisen Chung has updated the pull request incrementally with three additional commits since the last revision:

 - adjusted pixels to check for border
 - typo
 - reverted old change, swapped order of painting to prevent overdrawing

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7449/files
  - new: https://git.openjdk.java.net/jdk/pull/7449/files/c0b31892..6056faf8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=00-01

  Stats: 64 lines in 3 files changed: 48 ins; 1 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7449.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7449/head:pull/7449

PR: https://git.openjdk.java.net/jdk/pull/7449


From achung at openjdk.java.net  Fri Mar  4 00:49:40 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Fri, 4 Mar 2022 00:49:40 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor
In-Reply-To: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
Message-ID: <CCVY97gly1EUj0aXYQfIo0SKL-C3k-DHws5h28Rvt0U=.733eccae-7fe8-489d-8b58-3c99138ffbeb@github.com>

On Fri, 11 Feb 2022 23:44:22 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping

I've updated the fix to stop overdrawing, please review @mrserb @prrace @prsadhuk

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From mvs at openjdk.java.net  Fri Mar  4 01:55:45 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Fri, 4 Mar 2022 01:55:45 GMT
Subject: RFR: 8282343: Create a regression test for JDK-4518432 [v2]
In-Reply-To: <rygpvWtk3UgIsffXwTUC6aTOGfOjfZRZexJaQmMLIGE=.d7ae758a-01bb-49dd-810f-1cd2b64cc326@github.com>
References: <rygpvWtk3UgIsffXwTUC6aTOGfOjfZRZexJaQmMLIGE=.d7ae758a-01bb-49dd-810f-1cd2b64cc326@github.com>
Message-ID: <txwcmfxBEpPTfmHiPM_ElQm2TKFBL6jYHU_shn5JulU=.c8c0fb77-5c98-4395-9d6a-6e36e6a1fecd@github.com>

> Create a regression test for [JDK-4518432](https://bugs.openjdk.java.net/browse/JDK-4518432).
> 
> Issue: Copying from JTree and then changing the data in the component that was copied from, can cause pastes to use 
>            the new edited data.
> 
> This test verifies that copying from JTree node and then changing the data in the component that was copied from,
>  is not causing the pastes to use the new edited data instead of the original copied data.
> 
> Testing:
> Java 1.4.0 -> Test Failed.
> $ ./j2sdk1.4.0/bin/java JTreeWin
> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
> Test Failed in javax.swing.plaf.metal.MetalLookAndFeel, Expected : "colorsblue", but actual : "ctextolorsblue"
> Testing L&F: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> Test Failed in com.sun.java.swing.plaf.windows.WindowsLookAndFeel, Expected : "colorsblue", but actual : "ctextolorsblue"
> 
> Java 1.4.1 -> Test Passed.
> $ ./j2sdk1.4.1/bin/java JTreeWin
> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
> Test Passed in javax.swing.plaf.metal.MetalLookAndFeel
> Testing L&F: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> Test Passed in com.sun.java.swing.plaf.windows.WindowsLookAndFeel

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed: Formatting changes, removed extra blank lines, removed redundant tree focus listening code

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7605/files
  - new: https://git.openjdk.java.net/jdk/pull/7605/files/00f02705..de0712a5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7605&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7605&range=00-01

  Stats: 20 lines in 1 file changed: 0 ins; 20 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7605.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7605/head:pull/7605

PR: https://git.openjdk.java.net/jdk/pull/7605


From mvs at openjdk.java.net  Fri Mar  4 02:05:48 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Fri, 4 Mar 2022 02:05:48 GMT
Subject: RFR: 8282234: Create a regression test for JDK-4532513 [v3]
In-Reply-To: <h3ZoydrpxAklsdt3qahYdowBNEwAh4lZo96oGx2EEVc=.e076785d-c06f-43af-a3b9-d76390ea1f33@github.com>
References: <h3ZoydrpxAklsdt3qahYdowBNEwAh4lZo96oGx2EEVc=.e076785d-c06f-43af-a3b9-d76390ea1f33@github.com>
Message-ID: <4yaJRW-hhl_zQtTvYmkYk2DFmJ5dtzF8f2P47iWxrQU=.3a367d66-de8d-4447-b1c1-daa896de7090@github.com>

> Create a regression test for [JDK-4532513](https://bugs.openjdk.java.net/browse/JDK-4532513).
> This test verifies that the DefaultCaret doesn't requests focus in mouseClick and mousePressed causing the associated input verifier to fire twice.
> As per [JDK-4532513](https://bugs.openjdk.java.net/browse/JDK-4532513), the DefaultCaret requests focus in mouseClick and mousePressed causing the associated input verifier to fire twice.
> This issue was raised in JDK 1.4.0 and fixed in 1.4.1, so the test need to be failed in 1.4.0 and must pass in 1.4.1.
> 
> Testing:
> 
> In JDK 1.4.0:
> $ ./j2sdk1.4.0/bin/java DefaultCaretWin
> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
> shouldYieldFocus called 1
> shouldYieldFocus called 2
> shouldYieldFocus called 3
> java.lang.RuntimeException: Test failed for javax.swing.plaf.metal.MetalLookAndFeel as InputVerifier.shouldYieldFocus() getting called 3 times on jTextField2, but it is expected to call only once.
>         at DefaultCaretWin.runTest(DefaultCaretWin.java:114)
>         at DefaultCaretWin.main(DefaultCaretWin.java:58)
> 
> In JDK 1.4.1:
> $ ./j2sdk1.4.1/bin/java DefaultCaretWin
> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
> shouldYieldFocus called 1
> Test passed for laf: javax.swing.plaf.metal.MetalLookAndFeel
> Testing L&F: com.sun.java.swing.plaf.motif.MotifLookAndFeel
> shouldYieldFocus called 1
> Test passed for laf: com.sun.java.swing.plaf.motif.MotifLookAndFeel
> Testing L&F: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> shouldYieldFocus called 1
> Test passed for laf: com.sun.java.swing.plaf.windows.WindowsLookAndFeel

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Formatting changes, removed extra blank lines, rearranged methods order

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7577/files
  - new: https://git.openjdk.java.net/jdk/pull/7577/files/6d8a8c89..96942f37

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7577&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7577&range=01-02

  Stats: 11 lines in 1 file changed: 1 ins; 6 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7577.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7577/head:pull/7577

PR: https://git.openjdk.java.net/jdk/pull/7577


From mvs at openjdk.java.net  Fri Mar  4 02:05:48 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Fri, 4 Mar 2022 02:05:48 GMT
Subject: RFR: 8282234: Create a regression test for JDK-4532513 [v2]
In-Reply-To: <JIAEbD0RXItwhjq-N56wGZ0j02U1gZaw9dNUzbMnYwE=.fb17fb34-723b-4eb4-971a-ff03793499ab@github.com>
References: <h3ZoydrpxAklsdt3qahYdowBNEwAh4lZo96oGx2EEVc=.e076785d-c06f-43af-a3b9-d76390ea1f33@github.com>
 <JIAEbD0RXItwhjq-N56wGZ0j02U1gZaw9dNUzbMnYwE=.fb17fb34-723b-4eb4-971a-ff03793499ab@github.com>
Message-ID: <MbtLDQ01YMLnf7U6Y-7ss0VktP-2HlbRdHze6Gvz3ZA=.3b135264-4cd3-48b2-abab-84aa04958cbb@github.com>

On Wed, 23 Feb 2022 07:13:25 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Create a regression test for [JDK-4532513](https://bugs.openjdk.java.net/browse/JDK-4532513).
>> This test verifies that the DefaultCaret doesn't requests focus in mouseClick and mousePressed causing the associated input verifier to fire twice.
>> As per [JDK-4532513](https://bugs.openjdk.java.net/browse/JDK-4532513), the DefaultCaret requests focus in mouseClick and mousePressed causing the associated input verifier to fire twice.
>> This issue was raised in JDK 1.4.0 and fixed in 1.4.1, so the test need to be failed in 1.4.0 and must pass in 1.4.1.
>> 
>> Testing:
>> 
>> In JDK 1.4.0:
>> $ ./j2sdk1.4.0/bin/java DefaultCaretWin
>> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
>> shouldYieldFocus called 1
>> shouldYieldFocus called 2
>> shouldYieldFocus called 3
>> java.lang.RuntimeException: Test failed for javax.swing.plaf.metal.MetalLookAndFeel as InputVerifier.shouldYieldFocus() getting called 3 times on jTextField2, but it is expected to call only once.
>>         at DefaultCaretWin.runTest(DefaultCaretWin.java:114)
>>         at DefaultCaretWin.main(DefaultCaretWin.java:58)
>> 
>> In JDK 1.4.1:
>> $ ./j2sdk1.4.1/bin/java DefaultCaretWin
>> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
>> shouldYieldFocus called 1
>> Test passed for laf: javax.swing.plaf.metal.MetalLookAndFeel
>> Testing L&F: com.sun.java.swing.plaf.motif.MotifLookAndFeel
>> shouldYieldFocus called 1
>> Test passed for laf: com.sun.java.swing.plaf.motif.MotifLookAndFeel
>> Testing L&F: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>> shouldYieldFocus called 1
>> Test passed for laf: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set the default number of columns in JTextField constructor, otherwise in linux platforms the column width is coming default as 0 and in turns fails the test

@aivanov-jdk Can you please review this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7577


From psadhukhan at openjdk.java.net  Fri Mar  4 05:07:44 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 4 Mar 2022 05:07:44 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v3]
In-Reply-To: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
Message-ID: <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>

> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Revert dialogInput. Add Bolditalic

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7643/files
  - new: https://git.openjdk.java.net/jdk/pull/7643/files/9c098f99..0f74bf39

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7643&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7643&range=01-02

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7643.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7643/head:pull/7643

PR: https://git.openjdk.java.net/jdk/pull/7643


From smandalika at openjdk.java.net  Fri Mar  4 06:03:28 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Fri, 4 Mar 2022 06:03:28 GMT
Subject: RFR: 8282640: Create a test for JDK-4740761
Message-ID: <Rr2xSJSr1_1WFxavIZtwz_rlxf15Yvd5dCxZ_1dcggs=.7415074d-6beb-434e-b463-04388e50b0c8@github.com>

Create a test for [JDK-4740761](https://bugs.openjdk.java.net/browse/JDK-4740761)

The issue observed is in a JFrame with a JTextField and a JScrollPane which contains focused component. When the JScrollPane was
is removed from its parent, focus stays with the the scroller
of the removed JScrollPane, instead of moving to the TextField.

The test verifies the same - i.e. it verifies that the removal of the scrollpane moves the focus to the JTextField present in the JFrame.

-------------

Commit messages:
 - 8282640: Create a test for JDK-4740761
 - 8282640: Create a test for JDK-4740761
 - 8282640: Create a test for JDK-4740761

Changes: https://git.openjdk.java.net/jdk/pull/7686/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7686&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282640
  Stats: 118 lines in 1 file changed: 118 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7686.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7686/head:pull/7686

PR: https://git.openjdk.java.net/jdk/pull/7686


From asemenov at openjdk.java.net  Fri Mar  4 09:13:00 2022
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Fri, 4 Mar 2022 09:13:00 GMT
Subject: RFR: 8281284 : Write JSlider accessibility test [v5]
In-Reply-To: <WvwD8UFahxh4RyMHJIMuXrRQvc225Lo9QKKXY5qbRK0=.36eaafd9-7f1d-4686-bada-b81b91dbbf8e@github.com>
References: <VB8Ldq_d1uZBKpyvvDlu7t9lUtAd_WhLl4meSv46ixo=.b8b023ee-6946-407d-8e05-223fb2d95062@github.com>
 <WvwD8UFahxh4RyMHJIMuXrRQvc225Lo9QKKXY5qbRK0=.36eaafd9-7f1d-4686-bada-b81b91dbbf8e@github.com>
Message-ID: <M3FzDhITrDji-cvik9ecX3i0yxm1BUsuq6jD6E4cMC0=.aba4eb90-f3d5-43a1-b1bd-a558593008c3@github.com>

On Thu, 3 Mar 2022 17:11:39 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> This testcase covers both old and new api ( api added in jdk17  getAccessibleAction(), getAccessibleActionCount() , getAccessibleActionDescription )
>> 
>> @shurymury 
>> @savoptik
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   run the on windows and mac

Looks good to me. I agree

-------------

PR: https://git.openjdk.java.net/jdk/pull/7355


From dbatrak at openjdk.java.net  Fri Mar  4 09:24:59 2022
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Fri, 4 Mar 2022 09:24:59 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v3]
In-Reply-To: <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
Message-ID: <3ghRGxNVhvU1lK6xujw3BlBepie3GvPONnIF3cAwIlo=.51b5b48d-62fa-4573-b99d-1fba84482087@github.com>

On Fri, 4 Mar 2022 05:07:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert dialogInput. Add Bolditalic

If I may comment, in the past we received a noticeable amount of complaints about Korean text not rendered in our IDEs on Windows. This was solved by installing Korean font pack, but relying on users always doing that by themselves doesn't seem to provide the best user experience. So, two years ago, in JetBrains Runtime we ended up replacing Gulim/GulimChe/Batang with Malgun Gothic. This works well for us so far. I understand that this approach can give worse results for users that do install Korean font pack. But, I believe, the 'chaining' proposed by Naoto can actually be implemented, if desired - we just need to introduce a new 'category' to the properties file, say `korean_supplementary`. By putting it before `korean` in sequence definitions, we'll make e.g. Batang used if it's installed, and fall back to Malgun Gothic otherwise.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From aivanov at openjdk.java.net  Fri Mar  4 09:39:09 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 4 Mar 2022 09:39:09 GMT
Subject: RFR: 8015854: [macosx] JButton's HTML ImageView adding unwanted
 padding [v10]
In-Reply-To: <UCmQpKAK-Au3tEpSM9j7nePxcxWLAzoTTl2rBVAyBks=.4e46d6b8-521b-48bf-b7bf-a8c3a458f3da@github.com>
References: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
 <UCmQpKAK-Au3tEpSM9j7nePxcxWLAzoTTl2rBVAyBks=.4e46d6b8-521b-48bf-b7bf-a8c3a458f3da@github.com>
Message-ID: <nmw4M2cmBN_zGVtXGkwL1z5Syb3OpdD9Y6fYlcQ11Rk=.748ab61d-7bf0-4f77-bf05-f483b51ce1af@github.com>

On Thu, 3 Mar 2022 22:51:48 GMT, DamonGuy <duke at openjdk.java.net> wrote:

>> Html does not fit in JButton at certain sizes because default Insets cause html to be displayed off-center. 
>> 
>> Changes made to SwingUtilities.java layoutCompoundLabelImpl method to enable clipping if html does not fit, similar to regular text. AquaButtonUI.java now detects when html does not fit, and an implementation for alternate insets that are recursively tested for regular text inside layoutAndGetText() are now also being used for html content.
>> 
>> Created test (Bug8015854.java) with the same format as the test described on the issue. The button is of size 37x37 with an image of a red square sized 19x19. The test checks for red pixels on the edges of where the square image should be from the center of the button. The test fails with the non-changed jdk, but passes with the changes.
>
> DamonGuy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Changed method name.
>  - Reorganized imports. Added space in conditional.

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7310


From psadhukhan at openjdk.java.net  Fri Mar  4 09:56:04 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 4 Mar 2022 09:56:04 GMT
Subject: RFR: 8015854: [macosx] JButton's HTML ImageView adding unwanted
 padding [v10]
In-Reply-To: <UCmQpKAK-Au3tEpSM9j7nePxcxWLAzoTTl2rBVAyBks=.4e46d6b8-521b-48bf-b7bf-a8c3a458f3da@github.com>
References: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
 <UCmQpKAK-Au3tEpSM9j7nePxcxWLAzoTTl2rBVAyBks=.4e46d6b8-521b-48bf-b7bf-a8c3a458f3da@github.com>
Message-ID: <NN4OUQA41LIiqFNVks1kS8_cVtTEOfr0JMm551QV_8E=.33553a93-6366-4917-9267-c9b05bc9e310@github.com>

On Thu, 3 Mar 2022 22:51:48 GMT, DamonGuy <duke at openjdk.java.net> wrote:

>> Html does not fit in JButton at certain sizes because default Insets cause html to be displayed off-center. 
>> 
>> Changes made to SwingUtilities.java layoutCompoundLabelImpl method to enable clipping if html does not fit, similar to regular text. AquaButtonUI.java now detects when html does not fit, and an implementation for alternate insets that are recursively tested for regular text inside layoutAndGetText() are now also being used for html content.
>> 
>> Created test (Bug8015854.java) with the same format as the test described on the issue. The button is of size 37x37 with an image of a red square sized 19x19. The test checks for red pixels on the edges of where the square image should be from the center of the button. The test fails with the non-changed jdk, but passes with the changes.
>
> DamonGuy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Changed method name.
>  - Reorganized imports. Added space in conditional.

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7310


From aivanov at openjdk.java.net  Fri Mar  4 10:53:02 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 4 Mar 2022 10:53:02 GMT
Subject: RFR: 8282343: Create a regression test for JDK-4518432 [v2]
In-Reply-To: <txwcmfxBEpPTfmHiPM_ElQm2TKFBL6jYHU_shn5JulU=.c8c0fb77-5c98-4395-9d6a-6e36e6a1fecd@github.com>
References: <rygpvWtk3UgIsffXwTUC6aTOGfOjfZRZexJaQmMLIGE=.d7ae758a-01bb-49dd-810f-1cd2b64cc326@github.com>
 <txwcmfxBEpPTfmHiPM_ElQm2TKFBL6jYHU_shn5JulU=.c8c0fb77-5c98-4395-9d6a-6e36e6a1fecd@github.com>
Message-ID: <sQFbCCt1-trD4ra5cIWqUu891-PKjhJnX6Zsn-KMdV4=.0161762a-6913-44a8-b54f-de55b207fc18@github.com>

On Fri, 4 Mar 2022 01:55:45 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Create a regression test for [JDK-4518432](https://bugs.openjdk.java.net/browse/JDK-4518432).
>> 
>> Issue: Copying from JTree and then changing the data in the component that was copied from, can cause pastes to use 
>>            the new edited data.
>> 
>> This test verifies that copying from JTree node and then changing the data in the component that was copied from,
>>  is not causing the pastes to use the new edited data instead of the original copied data.
>> 
>> Testing:
>> Java 1.4.0 -> Test Failed.
>> $ ./j2sdk1.4.0/bin/java JTreeWin
>> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
>> Test Failed in javax.swing.plaf.metal.MetalLookAndFeel, Expected : "colorsblue", but actual : "ctextolorsblue"
>> Testing L&F: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>> Test Failed in com.sun.java.swing.plaf.windows.WindowsLookAndFeel, Expected : "colorsblue", but actual : "ctextolorsblue"
>> 
>> Java 1.4.1 -> Test Passed.
>> $ ./j2sdk1.4.1/bin/java JTreeWin
>> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
>> Test Passed in javax.swing.plaf.metal.MetalLookAndFeel
>> Testing L&F: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>> Test Passed in com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: Formatting changes, removed extra blank lines, removed redundant tree focus listening code

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7605


From mvs at openjdk.java.net  Fri Mar  4 10:59:05 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Fri, 4 Mar 2022 10:59:05 GMT
Subject: Integrated: 8282343: Create a regression test for JDK-4518432
In-Reply-To: <rygpvWtk3UgIsffXwTUC6aTOGfOjfZRZexJaQmMLIGE=.d7ae758a-01bb-49dd-810f-1cd2b64cc326@github.com>
References: <rygpvWtk3UgIsffXwTUC6aTOGfOjfZRZexJaQmMLIGE=.d7ae758a-01bb-49dd-810f-1cd2b64cc326@github.com>
Message-ID: <G5OQCxnfCyeJ71fUV8_C-bgXe8Qs9TtL8umb8YnCJaI=.fee87721-cd8a-4b2c-ac4a-46dff05cf2b7@github.com>

On Thu, 24 Feb 2022 11:46:58 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Create a regression test for [JDK-4518432](https://bugs.openjdk.java.net/browse/JDK-4518432).
> 
> Issue: Copying from JTree and then changing the data in the component that was copied from, can cause pastes to use 
>            the new edited data.
> 
> This test verifies that copying from JTree node and then changing the data in the component that was copied from,
>  is not causing the pastes to use the new edited data instead of the original copied data.
> 
> Testing:
> Java 1.4.0 -> Test Failed.
> $ ./j2sdk1.4.0/bin/java JTreeWin
> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
> Test Failed in javax.swing.plaf.metal.MetalLookAndFeel, Expected : "colorsblue", but actual : "ctextolorsblue"
> Testing L&F: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> Test Failed in com.sun.java.swing.plaf.windows.WindowsLookAndFeel, Expected : "colorsblue", but actual : "ctextolorsblue"
> 
> Java 1.4.1 -> Test Passed.
> $ ./j2sdk1.4.1/bin/java JTreeWin
> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
> Test Passed in javax.swing.plaf.metal.MetalLookAndFeel
> Testing L&F: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> Test Passed in com.sun.java.swing.plaf.windows.WindowsLookAndFeel

This pull request has now been integrated.

Changeset: b3837808
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b3837808bf13de2aa3d8c6c21cf61baac9baf2b2
Stats:     217 lines in 1 file changed: 217 ins; 0 del; 0 mod

8282343: Create a regression test for JDK-4518432

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/7605


From zgu at openjdk.java.net  Fri Mar  4 13:32:31 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 4 Mar 2022 13:32:31 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig()
Message-ID: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>

Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs`

Test:

- [x] jdk_desktop on Linux x86_64

-------------

Commit messages:
 - 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig()

Changes: https://git.openjdk.java.net/jdk/pull/7691/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7691&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282628
  Stats: 21 lines in 2 files changed: 18 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7691.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7691/head:pull/7691

PR: https://git.openjdk.java.net/jdk/pull/7691


From stuefe at openjdk.java.net  Fri Mar  4 16:51:05 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 4 Mar 2022 16:51:05 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig()
In-Reply-To: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
Message-ID: <ms4DIbFqPVTD3tLd3qeDA_-GBgrjQuh92XkE_v6OYog=.0a62ec93-87ba-42ee-ad3b-8c2a1ebe28ba@github.com>

On Fri, 4 Mar 2022 13:25:12 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs`
> 
> Test:
> 
> - [x] jdk_desktop on Linux x86_64

Looks good.

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7691


From duke at openjdk.java.net  Fri Mar  4 16:56:25 2022
From: duke at openjdk.java.net (Matteo Baccan)
Date: Fri, 4 Mar 2022 16:56:25 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <MN1ZlPsviXs5KpzVm8f3tQCJGp4XUZisKCT0Zc5WMVE=.9ef74900-2544-463f-9109-9a59d0e2ea1e@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Hi

I have pushed this PR about 1 month ago. Only 3 days ago OCA was accepted.
Now: what is the next step?

This is a cleanup PR that removes some double semicolons at the end of some lines inside the JDK code.

ciao
matteo

-------------

PR: https://git.openjdk.java.net/jdk/pull/7268


From duke at openjdk.java.net  Fri Mar  4 16:56:25 2022
From: duke at openjdk.java.net (Matteo Baccan)
Date: Fri, 4 Mar 2022 16:56:25 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of
 lines
Message-ID: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>

Hi

I have reviewed the code for removing double semicolons at the end of lines

all the best
matteo

-------------

Commit messages:
 - Removed double semicolon at the end of lines

Changes: https://git.openjdk.java.net/jdk/pull/7268/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7268&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282657
  Stats: 93 lines in 82 files changed: 0 ins; 0 del; 93 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7268.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7268/head:pull/7268

PR: https://git.openjdk.java.net/jdk/pull/7268


From jwaters at openjdk.java.net  Fri Mar  4 16:56:26 2022
From: jwaters at openjdk.java.net (Julian Waters)
Date: Fri, 4 Mar 2022 16:56:26 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <MN1ZlPsviXs5KpzVm8f3tQCJGp4XUZisKCT0Zc5WMVE=.9ef74900-2544-463f-9109-9a59d0e2ea1e@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <MN1ZlPsviXs5KpzVm8f3tQCJGp4XUZisKCT0Zc5WMVE=.9ef74900-2544-463f-9109-9a59d0e2ea1e@github.com>
Message-ID: <lG5726a2a2WsQQRwKZ-SUq00bw3xlHNvLwgcYapsIY4=.d0ad6d98-14f6-4f55-b06c-fe24dc042505@github.com>

On Fri, 25 Feb 2022 15:40:09 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

>> Hi
>> 
>> I have reviewed the code for removing double semicolons at the end of lines
>> 
>> all the best
>> matteo
>
> Hi
> 
> I have pushed this PR about 1 month ago. Only 3 days ago OCA was accepted.
> Now: what is the next step?
> 
> This is a cleanup PR that removes some double semicolons at the end of some lines inside the JDK code.
> 
> ciao
> matteo

Hi @matteobaccan

The next step would be to create a relevant issue on the tracker and set it to track this PR. Since you don't have the ability to create new issues on the JBS yet I'll help you create one, please rename your PR title to 8282657 and the system should take care of the rest and automatically mark your PR as ready for review after setting it to track the corresponding JBS entry.

Cheers,
Julian

-------------

PR: https://git.openjdk.java.net/jdk/pull/7268


From lancea at openjdk.java.net  Fri Mar  4 17:07:59 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 4 Mar 2022 17:07:59 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <e7XmpMjRNztZjXRaLS_7w4v_zyHgRMOWuaP-uvgHc8U=.1fabaeab-3387-4056-8b46-6851ef81c0d3@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

The changes look OK.  The copyright year probably should be updated as part of this PR

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7268


From duke at openjdk.java.net  Fri Mar  4 17:14:05 2022
From: duke at openjdk.java.net (Matteo Baccan)
Date: Fri, 4 Mar 2022 17:14:05 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <Z5IUTXYy0jJDvo942sQbkENuPE1poTsr0KXGmlNjK-8=.4b7a9484-d07e-4582-8f09-532018f06875@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Hi Lance

I can make a second commit updating the copyright year

Tell me if this is necessary

ciao
matteo

-------------

PR: https://git.openjdk.java.net/jdk/pull/7268


From rriggs at openjdk.java.net  Fri Mar  4 17:20:05 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 4 Mar 2022 17:20:05 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <UZMe07GwGmxtV0yNEmp8lmvGErijX5P0Gi8vCTMM1eY=.c117f6e6-cd47-4e44-b70f-3e00254e658f@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

We usually request that these be be broken up by area to attract the appropriate reviewers and avoid eye-strain.  The client modules are usually separated out, as are hotspot.
And corresponding tests.
This kind of change is pretty low value for the code base and requires the involvement of quite a few reviewers.
If you had ask ahead of time, I would have suggested finding something with more value.

-------------

Changes requested by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7268


From naoto at openjdk.java.net  Fri Mar  4 17:29:01 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 4 Mar 2022 17:29:01 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v2]
In-Reply-To: <cMKcpdy-o1jKXIv336E7035DANl6X-xs6h6ER4TaaYA=.b80a5175-81bd-4516-92ef-2e1ccc075643@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <3F6rwtKnmNxHmNk_JwNo-ovGQCtROCOTqq9JYEkxCnU=.715f8bd7-4df9-47dc-85f3-a598d01e8e78@github.com>
 <cMKcpdy-o1jKXIv336E7035DANl6X-xs6h6ER4TaaYA=.b80a5175-81bd-4516-92ef-2e1ccc075643@github.com>
Message-ID: <38BaTaUcyQ6-Xdt3q-mJlHgJQ4JHR2u8Pfp52jiq5E4=.a79d91c1-6f58-4088-b0d1-4a1d43921b51@github.com>

On Thu, 3 Mar 2022 18:07:25 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add bold version
>
> make/data/fontconfig/windows.fontconfig.properties line 184:
> 
>> 182: dialoginput.bold.japanese=MS Gothic
>> 183: dialoginput.bold.korean=Malgun Gothic Bold
>> 184: 
> 
> Since dialoginput is usually the same as monospaced, per Naoto's comment, this should be reverted.

Not only reverting, but I think `GulimChe` here is the right choice, as it is `monospaced`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From naoto at openjdk.java.net  Fri Mar  4 17:36:06 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 4 Mar 2022 17:36:06 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v3]
In-Reply-To: <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
Message-ID: <ElGAdcsVhAVE2v7UJzByEC9dv20yemq6ibeIY7--mwQ=.46427313-1602-41d5-a893-d3cd557e0cb0@github.com>

On Fri, 4 Mar 2022 05:07:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert dialogInput. Add Bolditalic

Initially I thought it was surprising this problem has not been reported quite some time since `Malgun Gothic` was introduced. Then I guessed that Korean customers possibly would all install Korean language pack because without it, they would not be able to input Korean chars (no Korean input method included by default). I think in IntelliJ's case, possibly the typical users are all developers installing English Windows, thus there have been bug reports. So, I would rather think replacing those fonts with `Malgun Gothic` could be problematic to the former Korean customers.
Having said that, I would want the `chaining` functionality which could effectively satisfy both users. Other than the option you provided, there could be an extension of the fontconfig, such as,

serif.plain.korean=Batang, Malgun Gothic

so that if `Batang` file is not ther, we can fall back to `Malgun Gothic`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From ihse at openjdk.java.net  Fri Mar  4 17:50:03 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Mar 2022 17:50:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <UZMe07GwGmxtV0yNEmp8lmvGErijX5P0Gi8vCTMM1eY=.c117f6e6-cd47-4e44-b70f-3e00254e658f@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <UZMe07GwGmxtV0yNEmp8lmvGErijX5P0Gi8vCTMM1eY=.c117f6e6-cd47-4e44-b70f-3e00254e658f@github.com>
Message-ID: <uclpoZxrJsB8HaLQGJ4mOFL-PlE1VkzzSiFYVX9Xu74=.cf93ab56-6689-4c02-aaed-db24b78811b5@github.com>

On Fri, 4 Mar 2022 17:17:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Hi
>> 
>> I have reviewed the code for removing double semicolons at the end of lines
>> 
>> all the best
>> matteo
>
> We usually request that these be be broken up by area to attract the appropriate reviewers and avoid eye-strain.  The client modules are usually separated out, as are hotspot.
> And corresponding tests.
> This kind of change is pretty low value for the code base and requires the involvement of quite a few reviewers.
> If you had ask ahead of time, I would have suggested finding something with more value.

@RogerRiggs Otoh, this change is really trivial. I have verified that all changes are replacing trailing ";;" in Java code. These are all clearly typos. I think it's nice that we try to strive for a high quality, and while you are correct this is maybe not the most pressing issue, I think it's nice to get a cleanup like this done. 

I'd argue that this is a trivial change. If you are worried, let's get a couple of more reviewers. I can't see the need to split this up per area.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7268


From prr at openjdk.java.net  Fri Mar  4 18:20:05 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 4 Mar 2022 18:20:05 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v3]
In-Reply-To: <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
Message-ID: <eLpNVkpn7dXZ1qqUsgjHrw8g-gPQEgO-ZHSnQK5l4TQ=.e8fd41f7-41a0-4bc7-8499-36b111bd6f76@github.com>

On Fri, 4 Mar 2022 05:07:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert dialogInput. Add Bolditalic

But serif.plain.korean isn't used unless it is a Korean locale .. so what's the point ?

And this one line already added 
allfonts.korean=Malgun Gothic
will provide it as a fall back so I don't see the need.
If I am an English language user running in a US / UK locale I'll get my Korean glyphs from there with the only difference being it isn't in the same place in the precedence order.
This also ensures that any "new" code points added in that font not present in the older ones will always be available.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From naoto at openjdk.java.net  Fri Mar  4 18:27:06 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 4 Mar 2022 18:27:06 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v3]
In-Reply-To: <eLpNVkpn7dXZ1qqUsgjHrw8g-gPQEgO-ZHSnQK5l4TQ=.e8fd41f7-41a0-4bc7-8499-36b111bd6f76@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
 <eLpNVkpn7dXZ1qqUsgjHrw8g-gPQEgO-ZHSnQK5l4TQ=.e8fd41f7-41a0-4bc7-8499-36b111bd6f76@github.com>
Message-ID: <cYNSehHTdI0s3FRSnkMv7_E0Ldk4NHD5rHLDavLR8yU=.314f4d66-9e67-46e1-8c08-85a14b1a336d@github.com>

On Fri, 4 Mar 2022 18:16:22 GMT, Phil Race <prr at openjdk.org> wrote:

> allfonts.korean=Malgun Gothic will provide it as a fall back so I don't see the need.

OK, that's what I needed. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From prr at openjdk.java.net  Fri Mar  4 18:57:02 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 4 Mar 2022 18:57:02 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v3]
In-Reply-To: <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
Message-ID: <JfEtMIcXatutCEl4kvrgl5x9z_-epRAAzfhmoaws4lk=.a69337b9-64d2-4666-a9bf-ceab80166e65@github.com>

On Fri, 4 Mar 2022 05:07:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert dialogInput. Add Bolditalic

BTW does anyone know if this is a problem for Chinese or Japanese too ?
I think Indic might have needs a font pack too .. maybe not in this bug but should we be looking wider than Korean ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From prr at openjdk.java.net  Fri Mar  4 19:10:06 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 4 Mar 2022 19:10:06 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <flAiYSlXjGXC4cguwLIZyH5aNm_n_wHhhiUVZLnQHOw=.55037371-dfc6-481a-965a-703b845542ad@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Marked as reviewed by prr (Reviewer).

Looks like  there's only one client source code file touched
Most of the client changes are only in jtreg tests - and this is very trivial, so I'm OK with them being included here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7268


From prr at openjdk.java.net  Fri Mar  4 19:14:01 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 4 Mar 2022 19:14:01 GMT
Subject: RFR: 8282473: Refactor swing classes javadoc to use @throws
 instead of @exception
In-Reply-To: <ZEDkB2AsCYNkyACgfH8htOz5VfAZobfGP6KviOHLZhU=.3c93f6f1-2058-4481-a1fb-ed752a2e3746@github.com>
References: <ZEDkB2AsCYNkyACgfH8htOz5VfAZobfGP6KviOHLZhU=.3c93f6f1-2058-4481-a1fb-ed752a2e3746@github.com>
Message-ID: <Z2kkRDP-AB5NPUBiKmLIhPrhDI2Vr4hWoslQbcHv1P8=.28f3d878-3249-452a-9b77-1e4e302c5f46@github.com>

On Tue, 1 Mar 2022 10:16:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Prevailing JDK coding practices use "@throws" rather than "@exception".
> Refactor existing swing classes javadoc to use @throws

This is touching a lot of files but I can't see it interfering with clean backports as we are very unlikely to touch lines in javadoc of SE API in backports !
And of course by implication, this fix is not one that would/should be backported.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7644


From naoto at openjdk.java.net  Fri Mar  4 19:20:06 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 4 Mar 2022 19:20:06 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v3]
In-Reply-To: <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
Message-ID: <jUTSUQdzYuqHIoz6PeiPF72degxYRqFmOLCwAEz-TXQ=.12ac6065-ea05-48e4-a4b3-e3f9a9ad871b@github.com>

On Fri, 4 Mar 2022 05:07:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert dialogInput. Add Bolditalic

Not that I know of. Simple testing with Japanese text worked OK, but extensive testing for CJK would be needed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From aivanov at openjdk.java.net  Fri Mar  4 19:27:04 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 4 Mar 2022 19:27:04 GMT
Subject: RFR: 8282602: Refactor awt classes javadoc to use @throws instead
 of @exception
In-Reply-To: <FVJL0ITAodybntUy2Ro7w5FmBxCQXDhgEZSckEcpW8o=.f25b6a6a-78b4-4c07-90d6-cb506cd73d87@github.com>
References: <FVJL0ITAodybntUy2Ro7w5FmBxCQXDhgEZSckEcpW8o=.f25b6a6a-78b4-4c07-90d6-cb506cd73d87@github.com>
Message-ID: <hZVxVpmJH81EA46zQ2Rtdf1P5YqvqRMpc1bCjXMZAaI=.3034c523-f94d-42f0-8a80-6e2c6015698a@github.com>

On Thu, 3 Mar 2022 12:26:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Prevailing JDK coding practices use "@throws" rather than "@exception".
> Refactor existing java/awt classes javadoc to use @throws

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7675


From duke at openjdk.java.net  Fri Mar  4 19:30:13 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Fri, 4 Mar 2022 19:30:13 GMT
Subject: Integrated: 8015854: [macosx] JButton's HTML ImageView adding unwanted
 padding
In-Reply-To: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
References: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
Message-ID: <PHJNEdUOVGXi1G3hwTY66oyI5NtAF-WcRC04grWIQ7I=.99352df6-c6b9-4cdd-927e-85b851dc6d9a@github.com>

On Tue, 1 Feb 2022 16:11:52 GMT, DamonGuy <duke at openjdk.java.net> wrote:

> Html does not fit in JButton at certain sizes because default Insets cause html to be displayed off-center. 
> 
> Changes made to SwingUtilities.java layoutCompoundLabelImpl method to enable clipping if html does not fit, similar to regular text. AquaButtonUI.java now detects when html does not fit, and an implementation for alternate insets that are recursively tested for regular text inside layoutAndGetText() are now also being used for html content.
> 
> Created test (Bug8015854.java) with the same format as the test described on the issue. The button is of size 37x37 with an image of a red square sized 19x19. The test checks for red pixels on the edges of where the square image should be from the center of the button. The test fails with the non-changed jdk, but passes with the changes.

This pull request has now been integrated.

Changeset: 9c817d38
Author:    Damon Nguyen <damon.nguyen at oracle.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9c817d38806708f84139e3180ac86a3805dcce5f
Stats:     125 lines in 2 files changed: 123 ins; 1 del; 1 mod

8015854: [macosx] JButton's HTML ImageView adding unwanted padding

Reviewed-by: psadhukhan, aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/7310


From rriggs at openjdk.java.net  Fri Mar  4 19:33:06 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 4 Mar 2022 19:33:06 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <w6EtpBynowVBiw_b5nP_UIAIXBanT3tU4iu5g8_e4gM=.24ccf09a-048f-4308-ac77-a8412eb61b71@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7268


From prr at openjdk.java.net  Fri Mar  4 19:42:08 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 4 Mar 2022 19:42:08 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig()
In-Reply-To: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
Message-ID: <I7J82hR9gpCK97Tht5oiuaNZEcQjk-fb9ikmc2OKEgc=.d4535ef8-9856-4ee5-9356-91009ea2850c@github.com>

On Fri, 4 Mar 2022 13:25:12 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs`
> 
> Test:
> 
> - [x] jdk_desktop on Linux x86_64

I've increased the number of reviewers because as well as the current reviewer it should have
(1) a reviewer from the client team
(2) a reviewer from whoever owns jni_util.h

If there were no change to that file it would have been simpler.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7691


From iris at openjdk.java.net  Fri Mar  4 19:43:03 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 4 Mar 2022 19:43:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <MATEadXGlyHBObaz0cYBJT19VmXa5Sk_VcaOKC_AtE8=.c1394e50-8bc7-44ab-bcec-8f3701295187@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Nice tidy of the code.

Is there anything that can be done to prevent re-introduction of this trivial problem?  Perhaps a new Skara bot jcheck option similar to what is already in place for trailing whitespace?

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7268


From wetmore at openjdk.java.net  Fri Mar  4 19:56:03 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Fri, 4 Mar 2022 19:56:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <1X39o4ON1uvbSXAp_r66zAmSy6sWZFKaP7-M54vAqX0=.d6abe0d5-9dd2-409b-91df-255d838196cb@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

LGTM also.  

Similar suggestion for updating copyrights.

-------------

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7268


From aivanov at openjdk.java.net  Fri Mar  4 20:02:11 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 4 Mar 2022 20:02:11 GMT
Subject: RFR: 8015854: [macosx] JButton's HTML ImageView adding unwanted
 padding [v8]
In-Reply-To: <EOgvUaDKBLE38BJL982WuJraTzwl37Emb9pecU1Aq3k=.56904ac9-b77f-43d6-9f22-b43e0697f261@github.com>
References: <TMaFwxP7hppckwsyFYDqFaQiuHfoeEHLKLeCgjXuKV0=.66a4da31-044a-4c67-b1e2-2f5cca30d845@github.com>
 <DgeMCQtzhqMoDpyf3LSagIZNmGafVtMtAi3d1rpE4xk=.afbd74d4-c78e-426e-b112-d87d25a05755@github.com>
 <EOgvUaDKBLE38BJL982WuJraTzwl37Emb9pecU1Aq3k=.56904ac9-b77f-43d6-9f22-b43e0697f261@github.com>
Message-ID: <KKFBf13YUHA8662QXuDdPzi7QscpG_7oT-lDpyQ4H7g=.63c0e619-bed0-495e-a0a4-d0cc23a4a9d7@github.com>

On Tue, 1 Mar 2022 23:33:40 GMT, DamonGuy <duke at openjdk.java.net> wrote:

> There is no new bug submitted yet for other LAFs that I know of. I tested other LAFs and the issue does persist, so I can submit the bug for them if necessary. The other LAFs I tested were Metal, Nimbus, and Motif.

Please, submit a new bug so that we don't forget about this issue in other LAFs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7310


From prr at openjdk.java.net  Fri Mar  4 20:19:00 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 4 Mar 2022 20:19:00 GMT
Subject: RFR: 8282602: Refactor awt classes javadoc to use @throws instead
 of @exception
In-Reply-To: <FVJL0ITAodybntUy2Ro7w5FmBxCQXDhgEZSckEcpW8o=.f25b6a6a-78b4-4c07-90d6-cb506cd73d87@github.com>
References: <FVJL0ITAodybntUy2Ro7w5FmBxCQXDhgEZSckEcpW8o=.f25b6a6a-78b4-4c07-90d6-cb506cd73d87@github.com>
Message-ID: <2YKBIloBXEg_Jwc1l_fMElQLJOsyLbBEn_4OMuLkJi8=.8ba591c3-1c95-4e93-aa97-3a38911fd9c8@github.com>

On Thu, 3 Mar 2022 12:26:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Prevailing JDK coding practices use "@throws" rather than "@exception".
> Refactor existing java/awt classes javadoc to use @throws

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7675


From prr at openjdk.java.net  Fri Mar  4 20:20:09 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 4 Mar 2022 20:20:09 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v3]
In-Reply-To: <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
Message-ID: <VuFA2MF3j6ZKek1b6H-UrTyQx6GFVHA7lQPevbptTyU=.62842243-f608-4192-b505-ce3cba03ee17@github.com>

On Fri, 4 Mar 2022 05:07:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert dialogInput. Add Bolditalic

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From prr at openjdk.java.net  Fri Mar  4 20:44:06 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 4 Mar 2022 20:44:06 GMT
Subject: RFR: 8282422: JTable.print() failed with
 UnsupportedCharsetException on AIX ko_KR locale
In-Reply-To: <WoFYqSGq8S5uRqiDH_FJ3ebGeinGkEI1c5_6H7omPnM=.db3d9c13-c0a7-454b-8872-034fec9daedc@github.com>
References: <WoFYqSGq8S5uRqiDH_FJ3ebGeinGkEI1c5_6H7omPnM=.db3d9c13-c0a7-454b-8872-034fec9daedc@github.com>
Message-ID: <Es5sO5apD-GNYUCC9L-oiykynWyJe9qbGUYrliUo6Mw=.0ddda000-4911-4e61-9271-bcd6db72d256@github.com>

On Sat, 26 Feb 2022 16:24:07 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> On AIX ko_KR locale, I could see following exception after JTable.print() was called
> 
> java.nio.charset.UnsupportedCharsetException: sun.font.X11KSC5601
>         at java.base/java.nio.charset.Charset.forName(Charset.java:527)
>         at java.desktop/sun.awt.FontConfiguration.getFontCharsetEncoder(FontConfiguration.java:964)
> ......
> 
> According to my investigation, sun.font.X11KSC5601 moved from sun.awt.motif.X11KSC5601.

Should be safe enough since I think AIX may be the only platform left that needs this.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7630


From prr at openjdk.java.net  Fri Mar  4 21:13:07 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 4 Mar 2022 21:13:07 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v2]
In-Reply-To: <6sowygRcdclz1LCYIHZSWMKV2LhuPo0D_EaYC_JIq0c=.b25c1f95-2510-4372-a8e4-99178d1762ce@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <6sowygRcdclz1LCYIHZSWMKV2LhuPo0D_EaYC_JIq0c=.b25c1f95-2510-4372-a8e4-99178d1762ce@github.com>
Message-ID: <9TbYruwfo7JM4xbW6Mwj_WAAXdbrZR3O62Cc6xgt2TI=.74af7b62-adef-4b98-b195-4f9d47d5098d@github.com>

On Mon, 28 Feb 2022 14:54:19 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> The two tests `ScreenCaptureGtkTest.java` and `HiDPIRobotScreenCaptureTest.java` under `java/awt/Robot/HiDPIScreenCapture` started to intermittently fail under Windows and Linux after the [recent changes](https://github.com/openjdk/jdk/commit/cc7cf81256ed4d74493472017b1c4df20fa2208a) made exclusively for the Linux `Robot` implementation.
>> 
>> `HiDPIRobotScreenCaptureTest.java`
>> Since the Windows failures cannot possibly have their origin in the fix made - the latter being Linux-only - the test apparently either exposes an existing bug in the Windows `Robot` or is bumping against a peculiarity of that platform. The test is reverted back to its original form that didn't fail.
>> 
>> `ScreenCaptureGtkTest.java`
>> The coordinates in the log `(83, 78)` of a failure are higher up than the test suggests `(83, 97)`. I've seen similar failures on Ubuntu 20.04 when the coordinates were set to `(0, 0)`. The color then picked matched the color of the bar drawn at the top of the screen. I believe it's best to place the test pixels towards the center of the window to avoid desktop elements interference.
>> 
>> The other possible reason for intermittent failures are window coordinates. Suppose that the test is executing with `sun.java2d.uiScale` set to 2. This effectively means that it can only pick colors of pixels at even coordinates (in the absolute desktop space). So if the window is placed at, say, `(201, 201)`, `Robot` can only pick the color at either `(200, 200)` or `(202, 202)`. Since the test only makes sense if it is pixel-accurate, I removed all `@run`s with `sun.java2d.uiScale` other than 1. This way window placement will not cause a failure.
>> 
>> This was tested on Ubuntu 20.04 and 18.04 with desktop scaling set to 100%, 200%, and 300%.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed HiDPIRobotScreenCaptureTest to save image on failure

test/jdk/java/awt/Robot/HiDPIScreenCapture/ScreenCaptureGtkTest.java line 44:

> 42:  * @run main/othervm -Djdk.gtk.version=2 -Dsun.java2d.uiScale=1 ScreenCaptureGtkTest
> 43:  * @run main/othervm -Djdk.gtk.version=3 -Dsun.java2d.uiScale=1 ScreenCaptureGtkTest
> 44:  */

So having removed all of these, it isn't testing hi-dpi any more, is it ? Even if running on a hi-dpi screen.
Would it be better to let it just use whatever it wants for default ? Meaning if it happens to run on a hi-dpi
screen we want to know if that works don't we ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From prr at openjdk.java.net  Fri Mar  4 21:15:03 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 4 Mar 2022 21:15:03 GMT
Subject: RFR: 6218162: DefaultTableColumnModel.getColumn() method should
 mention ArrayIndexOutOfBoundsException [v3]
In-Reply-To: <XtDXW8eh84GfpMHO0zvqPYCjUFPnnlQ-Ka6ZMv1HNMw=.909a4ca3-12d1-43c6-b6f5-26854535be6a@github.com>
References: <KYDs0LbJF3OqE_Wncy3XvCymxYe5dHfrN9PQXkXCEYE=.2e310ed0-910f-433c-93a3-e1f691f2131b@github.com>
 <XtDXW8eh84GfpMHO0zvqPYCjUFPnnlQ-Ka6ZMv1HNMw=.909a4ca3-12d1-43c6-b6f5-26854535be6a@github.com>
Message-ID: <7U-SomFGRaFJPIZu_PxlYB92SMh4x0vMz5OxNLHFbLU=.2faa415f-e1f4-4bb5-a1bd-a84954c60e52@github.com>

On Mon, 28 Feb 2022 07:24:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> If invalid ie 0 or > getColumnCount() index is passed to DefaultTableColumnModel.getColumn() then it returns AIOBE in current implementation which should be documented in the spec. Fixed the spec to mention the exception.
>
> Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - javadoc fix
>  - javadoc fix
>  - javadoc fix

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7587


From prr at openjdk.java.net  Fri Mar  4 21:22:05 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 4 Mar 2022 21:22:05 GMT
Subject: RFR: 7017094: ParsedSynthStyle: parameter name "direction" should
 be changed to "tabIndex"
In-Reply-To: <VwlUM4QDKOnh4_pNaV2cwYvW8zqI0HyAc8nYqaBYgyY=.bc90ec24-8575-4e02-810f-2cd14914caa3@github.com>
References: <VwlUM4QDKOnh4_pNaV2cwYvW8zqI0HyAc8nYqaBYgyY=.bc90ec24-8575-4e02-810f-2cd14914caa3@github.com>
Message-ID: <PR5bG7t1d0RyPRInxQB1smlLdV94K_v_te5ampK07AU=.a7fe2868-85d7-4e9e-8c15-bde697b5b44a@github.com>

On Mon, 21 Feb 2022 04:59:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> [SynthPainter](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthPainter.java#L1759)
> and 
> [SynthPainterImpl](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/nimbus/SynthPainterImpl.java#L2074)
> expects a "tabIndex" although the parameter is not used currently.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7551


From darcy at openjdk.java.net  Fri Mar  4 21:33:07 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 4 Mar 2022 21:33:07 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <Fk4CQf_wtrFu81GCs38UEX3qnk9nz3DUkP7EZT37icU=.78ef4ece-fe43-4b9a-b4c4-393e7bf741cb@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7268


From dholmes at openjdk.java.net  Fri Mar  4 21:34:07 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 4 Mar 2022 21:34:07 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig()
In-Reply-To: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
Message-ID: <pdaQf3gGHrA4wvATmdOdtxUulmGYsbnjcP6dDP-M2ZM=.c6dd4579-ffe8-455b-9f38-c4373c55a3ab@github.com>

On Fri, 4 Mar 2022 13:25:12 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs`
> 
> Test:
> 
> - [x] jdk_desktop on Linux x86_64

I would have just inlined JNU_CHECK_EXCEPTION and added the cleanup code directly. The additional macro wasn't really necessary and would not really be usable for any kind of general cleanup actions beyond a one-liner.

But it is okay.

Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7691


From prr at openjdk.java.net  Fri Mar  4 21:35:17 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 4 Mar 2022 21:35:17 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v2]
In-Reply-To: <FekRgDLssGtJkXCN1Z-po6L4liDWivTfMM0SE2IOdSY=.6c5792c4-3d8f-49f4-a32f-99466c97ae6c@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <FekRgDLssGtJkXCN1Z-po6L4liDWivTfMM0SE2IOdSY=.6c5792c4-3d8f-49f4-a32f-99466c97ae6c@github.com>
Message-ID: <dAi-3yVWhSzLp-xxgY_4kJcgR-sjI0Gawzs_Oy5R3pQ=.bb14e735-3133-4581-9741-8ea5c2b0aca8@github.com>

On Fri, 4 Mar 2022 00:49:39 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - adjusted pixels to check for border
>  - typo
>  - reverted old change, swapped order of painting to prevent overdrawing

Can you explain (walk through) why the old code was wrong and the new code is correct ?
There's a lot of things that aren't obvious to me.
The old code would use the same coords and just toggle which parts were in highlight/shadow
Now you've spilit is so that lowered does things in a different order and so forth and I find it
impossible without an explanation of your reasoning to say if that reasoning is correct ...

Also the bug report deserves an evaluation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From zgu at openjdk.java.net  Fri Mar  4 21:57:58 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 4 Mar 2022 21:57:58 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig()
In-Reply-To: <pdaQf3gGHrA4wvATmdOdtxUulmGYsbnjcP6dDP-M2ZM=.c6dd4579-ffe8-455b-9f38-c4373c55a3ab@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
 <pdaQf3gGHrA4wvATmdOdtxUulmGYsbnjcP6dDP-M2ZM=.c6dd4579-ffe8-455b-9f38-c4373c55a3ab@github.com>
Message-ID: <IX-VSuXxNiYd6gzw8e2_l4hwb6-JjlCgP3qmW7x2Eno=.84218e33-f86e-4a3d-9fd5-ccd64a0d4631@github.com>

On Fri, 4 Mar 2022 21:30:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I would have just inlined JNU_CHECK_EXCEPTION and added the cleanup code directly. The additional macro wasn't really necessary and would not really be usable for any kind of general cleanup actions beyond a one-liner.
> 
> But it is okay.
> 
> Thanks.

Thanks for the review, @dholmes-ora .

The macros are used to hide the different syntax of c and c++ to avoid polluting code here, it seems to be a common pattern in client code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7691


From duke at openjdk.java.net  Fri Mar  4 22:42:04 2022
From: duke at openjdk.java.net (Jeremy)
Date: Fri, 4 Mar 2022 22:42:04 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v12]
In-Reply-To: <pkujGIpXv0UwX2gxeX6kOzKXHiqoImRI9BuglmWbHbE=.a4801fee-2fc4-4a78-97b6-4ea27396492a@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <pkujGIpXv0UwX2gxeX6kOzKXHiqoImRI9BuglmWbHbE=.a4801fee-2fc4-4a78-97b6-4ea27396492a@github.com>
Message-ID: <V_dusBmHOneHnSxQxMHeTd_Dk3zljmHwI2XSlDPOeok=.c9faa61f-d98a-40fd-b79c-0328ed985006@github.com>

On Thu, 16 Dec 2021 18:33:37 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>   
>   This is a second follow-up response to prrace's code review feedback about method modifiers.
>   
>   This commit more carefully preserves the getBounds2D() method modifiers for all 3 classes: the Path2D.Double, the Path2D.Float, and the Path2D itself.
>   
>   It is possible (if unlikely) that someone previously extended the Path2D class and overrode getBounds2D(), because the Path2D#getBounds2D() method was *not* final. So with this commit: any such existing code will not break. Meanwhile the subclasses (Double and Float) preserve their previous modifiers (final, synchronized).
>   
>   This is in response to prrace's code review:
>   
>   >    You are changing the signature of public API
>   >    src/java.desktop/share/classes/java/awt/geom/Path2D.java
>   >    public final synchronized Rectangle2D getBounds2D() => public Rectangle2D getBounds2D() {
>   >
>   > So no longer final, and no longer synchronized.
>   > This means a CSR is required and we need to think about it ..
>   > the intention was that the subclass not over-ride.
>   > And why remove synchronized ? I am fairly sure it was there to
>   > make sure no one was mutating the Path whilst
>   > bounds are being calculated.
>   > And you are using getPathIterator(AffineTransform) and the docs
>   > for that say it isn't thread safe.
>   > So I think this implementation needs to be thought about very carefully.

I don't suppose any new client-lib members would be willing to set up a CSR for this PR?

No worries if not. I just wanted to double-check before this PR gets auto-closed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6227


From duke at openjdk.java.net  Fri Mar  4 22:54:16 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Fri, 4 Mar 2022 22:54:16 GMT
Subject: Integrated: 8236907: JTable added to nested panels does not paint last
 visible row
In-Reply-To: <Xwc58NmkbNIShAkXmFRyiZrdhN-4EHh-r-FwswcULWw=.666e1d7b-b978-4dfb-8dc1-3dcf85f72cf8@github.com>
References: <Xwc58NmkbNIShAkXmFRyiZrdhN-4EHh-r-FwswcULWw=.666e1d7b-b978-4dfb-8dc1-3dcf85f72cf8@github.com>
Message-ID: <HeOxGG5D8bBAE7uEBRqokF4hqG9l7bPjXr6-oP1hUXY=.d2d98036-cf12-43e6-95d5-38df7469a221@github.com>

On Thu, 10 Feb 2022 09:49:41 GMT, Tejesh R <duke at openjdk.java.net> wrote:

> Issue in painting last row of JTable due to decrement in `MaxRow `during computation. Differences in `MaxRow `computation between `TablePrintable` and `BasicTableUI `class. The Bug is fixed in both the classes. Test Case added to validate the same.

This pull request has now been integrated.

Changeset: bae0d5e7
Author:    TejeshR13 <tejesh.r at oracle.com>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bae0d5e7174fed8ffa8a30408c3cffa6e4dd3ddc
Stats:     245 lines in 3 files changed: 224 ins; 17 del; 4 mod

8236907: JTable added to nested panels does not paint last visible row

Reviewed-by: psadhukhan, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/7422


From prr at openjdk.java.net  Fri Mar  4 23:14:16 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 4 Mar 2022 23:14:16 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
Message-ID: <Skw1v2cIWlvB1zWvZfi_DiGvq_gP_fAsH9aYuiFdRaw=.8b30e8b7-46af-4119-a947-74e460fcbb1e@github.com>

On Thu, 28 Oct 2021 08:27:44 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the 8275715 bug fixes?
>> 
>> I think D3DScreenUpdateManager posts unnecessary PaintEvent during processing PaintEvent. When the validate method is called from createGraphics, repaintPeerTarget should not be called.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8275715: D3D pipeline processes multiple PaintEvent at initial drawing

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6064


From achung at openjdk.java.net  Sat Mar  5 01:59:04 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Sat, 5 Mar 2022 01:59:04 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v2]
In-Reply-To: <dAi-3yVWhSzLp-xxgY_4kJcgR-sjI0Gawzs_Oy5R3pQ=.bb14e735-3133-4581-9741-8ea5c2b0aca8@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <FekRgDLssGtJkXCN1Z-po6L4liDWivTfMM0SE2IOdSY=.6c5792c4-3d8f-49f4-a32f-99466c97ae6c@github.com>
 <dAi-3yVWhSzLp-xxgY_4kJcgR-sjI0Gawzs_Oy5R3pQ=.bb14e735-3133-4581-9741-8ea5c2b0aca8@github.com>
Message-ID: <X20yOeSYQ3aDABuDUvVWyy7sjXKFbphtUpA7V1vfwrI=.1f366364-dc10-4110-a719-f6f7f40a7722@github.com>

On Fri, 4 Mar 2022 21:31:55 GMT, Phil Race <prr at openjdk.org> wrote:

> Can you explain (walk through) why the old code was wrong and the new code is correct ? There's a lot of things that aren't obvious to me. The old code would use the same coords and just toggle which parts were in highlight/shadow Now you've spilit is so that lowered does things in a different order and so forth and I find it impossible without an explanation of your reasoning to say if that reasoning is correct ...
> 
> Also the bug report deserves an evaluation.

I think currently the problem is the lighter color is overdrawing the darker color, so I swapped the drawing order so that the darker color is always drawn second. I think the reason the rect and lines are drawn at the same x value probably has to do with the affine transform in the graphics object, but I'm not sure why it happens.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From duke at openjdk.java.net  Sat Mar  5 04:03:06 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Sat, 5 Mar 2022 04:03:06 GMT
Subject: RFR: 8281284 : Write JSlider accessibility test [v5]
In-Reply-To: <M3FzDhITrDji-cvik9ecX3i0yxm1BUsuq6jD6E4cMC0=.aba4eb90-f3d5-43a1-b1bd-a558593008c3@github.com>
References: <VB8Ldq_d1uZBKpyvvDlu7t9lUtAd_WhLl4meSv46ixo=.b8b023ee-6946-407d-8e05-223fb2d95062@github.com>
 <WvwD8UFahxh4RyMHJIMuXrRQvc225Lo9QKKXY5qbRK0=.36eaafd9-7f1d-4686-bada-b81b91dbbf8e@github.com>
 <M3FzDhITrDji-cvik9ecX3i0yxm1BUsuq6jD6E4cMC0=.aba4eb90-f3d5-43a1-b1bd-a558593008c3@github.com>
Message-ID: <T113JRdg-jgMhjfNwKHGNmqx3xT_pDubc4XVZsz57Xs=.e988cf53-0733-4e47-81c7-32ee1ff37f6b@github.com>

On Fri, 4 Mar 2022 09:10:02 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   run the on windows and mac
>
> Looks good to me. I agree

@savoptik , can you approve this PR so that this PR is eligible for merge.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7355


From dholmes at openjdk.java.net  Sat Mar  5 05:32:05 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 5 Mar 2022 05:32:05 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig()
In-Reply-To: <IX-VSuXxNiYd6gzw8e2_l4hwb6-JjlCgP3qmW7x2Eno=.84218e33-f86e-4a3d-9fd5-ccd64a0d4631@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
 <pdaQf3gGHrA4wvATmdOdtxUulmGYsbnjcP6dDP-M2ZM=.c6dd4579-ffe8-455b-9f38-c4373c55a3ab@github.com>
 <IX-VSuXxNiYd6gzw8e2_l4hwb6-JjlCgP3qmW7x2Eno=.84218e33-f86e-4a3d-9fd5-ccd64a0d4631@github.com>
Message-ID: <wruqVOEWBWdR3YKrvcctN2NhoUwdS7osp0z6j3m2QYs=.5e93b491-2a7e-4f01-a462-ad77a876e6ce@github.com>

On Fri, 4 Mar 2022 21:54:57 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> The macros are used to hide the different syntax of c and c++ to avoid polluting code here, it seems to be a common pattern in client code.

That's to allow for general use by C or C++ source files. But you are only needing this in a C source file so you would only need the C variant of the calling syntax.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7691


From dholmes at openjdk.java.net  Sat Mar  5 05:52:04 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 5 Mar 2022 05:52:04 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <2NJw-71OOOvNs9519H__uYdXQnJm23L-Ez4jKoAuKrk=.c277d644-fd63-442e-99a1-6d3d66cb3405@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

I eyeballed the diff file and all seems okay.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7268


From jwaters at openjdk.java.net  Sat Mar  5 06:52:13 2022
From: jwaters at openjdk.java.net (Julian Waters)
Date: Sat, 5 Mar 2022 06:52:13 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <BYP-9VZJoznj9GWtwXRA99BqEtITgNUVrbDggKRdads=.8664f68e-92af-4dad-99c3-a7b0bb0e1e68@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Nice, good work matteo

Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7268


From duke at openjdk.java.net  Sat Mar  5 07:22:03 2022
From: duke at openjdk.java.net (Jan =?UTF-8?B?U2NobMO2w59pbg==?=)
Date: Sat, 5 Mar 2022 07:22:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <apFWxhCWJTH2dzbDsF-uJEef-Y6uhfH0gNI48VGHYwU=.8dfe6837-793d-466f-bb16-9f7fd53798d8@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

This PR changes a comment in javax/swing/RepaintManager.java. This commented out code should be removed altogether in another PR? Because its an System.out.println and because its commented out code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7268


From asemenov at openjdk.java.net  Sat Mar  5 08:08:58 2022
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Sat, 5 Mar 2022 08:08:58 GMT
Subject: RFR: 8281284 : Write JSlider accessibility test [v5]
In-Reply-To: <T113JRdg-jgMhjfNwKHGNmqx3xT_pDubc4XVZsz57Xs=.e988cf53-0733-4e47-81c7-32ee1ff37f6b@github.com>
References: <VB8Ldq_d1uZBKpyvvDlu7t9lUtAd_WhLl4meSv46ixo=.b8b023ee-6946-407d-8e05-223fb2d95062@github.com>
 <WvwD8UFahxh4RyMHJIMuXrRQvc225Lo9QKKXY5qbRK0=.36eaafd9-7f1d-4686-bada-b81b91dbbf8e@github.com>
 <M3FzDhITrDji-cvik9ecX3i0yxm1BUsuq6jD6E4cMC0=.aba4eb90-f3d5-43a1-b1bd-a558593008c3@github.com>
 <T113JRdg-jgMhjfNwKHGNmqx3xT_pDubc4XVZsz57Xs=.e988cf53-0733-4e47-81c7-32ee1ff37f6b@github.com>
Message-ID: <QywBHOloRQyDVYdYq_eSn16WZU4sebZSvmifeAUl7EE=.b96e672a-6556-4253-a792-4f8412e53cf6@github.com>

On Sat, 5 Mar 2022 03:59:21 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> Looks good to me. I agree
>
> @savoptik , can you approve this PR so that this PR is eligible for merge.

@lawrence-andrew I am not reviewer. Contact @mrserb or @azuev-java

-------------

PR: https://git.openjdk.java.net/jdk/pull/7355


From duke at openjdk.java.net  Sat Mar  5 08:30:05 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Sat, 5 Mar 2022 08:30:05 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v2]
In-Reply-To: <9TbYruwfo7JM4xbW6Mwj_WAAXdbrZR3O62Cc6xgt2TI=.74af7b62-adef-4b98-b195-4f9d47d5098d@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <6sowygRcdclz1LCYIHZSWMKV2LhuPo0D_EaYC_JIq0c=.b25c1f95-2510-4372-a8e4-99178d1762ce@github.com>
 <9TbYruwfo7JM4xbW6Mwj_WAAXdbrZR3O62Cc6xgt2TI=.74af7b62-adef-4b98-b195-4f9d47d5098d@github.com>
Message-ID: <e2kuv7ZIhCBFVsdOaBTQLsvEah30BhTsk721cke6nsc=.a16cdabb-7566-418d-b89e-de43b9573290@github.com>

On Fri, 4 Mar 2022 21:10:03 GMT, Phil Race <prr at openjdk.org> wrote:

> So having removed all of these, it isn't testing hi-dpi any more, is it ?

True. But there still is `ScreenCaptureTest.java` that will continue testing hi-dpi. 

Keeping `ScreenCaptureGtkTest.java` still makes sense because it verifies that `getPixelColor()` works precisely when neighboring pixels are of a different color; also, it shuffles the GTK versions.

Unfortunately, I see no way to fully and reliably test the changes for 8280861 with scaling above 1. I am forced to choose between two evils: 
1. either I set the scale above 1 and pick color inside a large area to be sure that I don't pick neighboring pixels because of an unfortunate window placement
1. or I set the scale to 1 and test colors of pixels sitting next to one another.

(1) was tested by the existing tests, (2) is tested by `ScreenCaptureGtkTest.java`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From dbatrak at openjdk.java.net  Sat Mar  5 10:38:00 2022
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Sat, 5 Mar 2022 10:38:00 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v3]
In-Reply-To: <eLpNVkpn7dXZ1qqUsgjHrw8g-gPQEgO-ZHSnQK5l4TQ=.e8fd41f7-41a0-4bc7-8499-36b111bd6f76@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
 <eLpNVkpn7dXZ1qqUsgjHrw8g-gPQEgO-ZHSnQK5l4TQ=.e8fd41f7-41a0-4bc7-8499-36b111bd6f76@github.com>
Message-ID: <7FJIWE5xd3Fh0W0iu6nmtcuZoWq2cuPDUidpy5l8jjs=.47bc0c69-86c1-43ef-b7da-29d9b6f34af5@github.com>

On Fri, 4 Mar 2022 18:16:22 GMT, Phil Race <prr at openjdk.org> wrote:

> But serif.plain.korean isn't used unless it is a Korean locale

That's not the case, and is easily verifiable for English locale - whatever font is specified there will become a component of Serif composite. 'korean' here is a script id, which is referenced from `sequence.fallback`, used for all locales.

> And this one line already added
allfonts.korean=Malgun Gothic
will provide it as a fall back so I don't see the need.

That's also not the case. With the patch applied, Serif font still doesn't have Malgun Gothic as a component.
That line in the current patch has no effect at all - `allfonts.<script>` lines only have an effect for scripts, which don't have assigned fonts in `<composite>.<style>.<script>` properties. 

> BTW does anyone know if this is a problem for Chinese or Japanese too ?
I think Indic might have needs a font pack too .. maybe not in this bug but should we be looking wider than Korean ?

Didn't hear about related problems for Chinese or Japanese, but the same problem exists for Thai script - DokChampa font isn't available by default on Windows 10, and we use Tahoma as a replacement currently.

BTW, maybe it's worth to create a test case for this problem? As Korean support is explicitly coded in `windows.fontconfig.properties`, it might be good to check that all 20 logical fonts can display Korean on Windows. If a newer Windows version will change the bundled font again, the problem will become apparent at once.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From lbourges at openjdk.java.net  Sat Mar  5 12:56:03 2022
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sat, 5 Mar 2022 12:56:03 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v12]
In-Reply-To: <i8wNF6CsEhC-9p88qf8vH9nSdhDDwcFjY7Z2QMpvz4Y=.81f1d2ff-d730-4e43-8782-329736fe78e2@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <pkujGIpXv0UwX2gxeX6kOzKXHiqoImRI9BuglmWbHbE=.a4801fee-2fc4-4a78-97b6-4ea27396492a@github.com>
 <i8wNF6CsEhC-9p88qf8vH9nSdhDDwcFjY7Z2QMpvz4Y=.81f1d2ff-d730-4e43-8782-329736fe78e2@github.com>
Message-ID: <I4vVwoc93Pg-d8V0zqHKBK50pDXiDJr54tohlEG1fPI=.d280763c-8e64-4c61-808f-7387a89c3819@github.com>

On Wed, 5 Jan 2022 22:48:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>>   
>>   This is a second follow-up response to prrace's code review feedback about method modifiers.
>>   
>>   This commit more carefully preserves the getBounds2D() method modifiers for all 3 classes: the Path2D.Double, the Path2D.Float, and the Path2D itself.
>>   
>>   It is possible (if unlikely) that someone previously extended the Path2D class and overrode getBounds2D(), because the Path2D#getBounds2D() method was *not* final. So with this commit: any such existing code will not break. Meanwhile the subclasses (Double and Float) preserve their previous modifiers (final, synchronized).
>>   
>>   This is in response to prrace's code review:
>>   
>>   >    You are changing the signature of public API
>>   >    src/java.desktop/share/classes/java/awt/geom/Path2D.java
>>   >    public final synchronized Rectangle2D getBounds2D() => public Rectangle2D getBounds2D() {
>>   >
>>   > So no longer final, and no longer synchronized.
>>   > This means a CSR is required and we need to think about it ..
>>   > the intention was that the subclass not over-ride.
>>   > And why remove synchronized ? I am fairly sure it was there to
>>   > make sure no one was mutating the Path whilst
>>   > bounds are being calculated.
>>   > And you are using getPathIterator(AffineTransform) and the docs
>>   > for that say it isn't thread safe.
>>   > So I think this implementation needs to be thought about very carefully.
>
> I still recommend a CSR since
> 1) Although "compatible", this visibly moves the specs for getBounds2D() from copies on the Float and Double nested sub-classes to the enclosing parent class
> 2) Although in the spirit of what getBounds2D() is supposed to do  .. it actually hasn't for over 20 years. We like to document such behavioural changes via a CSR.
> 
> Actually regarding (1) there's also a real change there too since now The Float subclass will return a Rectangle2D.Double .. I am not sure that we should actually do that.

This work is great for jdk19, 25 years after java 1.2 providing the java2d API, to get more precise curve bounding boxes (closer to extrema), let's write the CSR altogether, @prrace

-------------

PR: https://git.openjdk.java.net/jdk/pull/6227


From myano at openjdk.java.net  Sun Mar  6 23:58:06 2022
From: myano at openjdk.java.net (Masanori Yano)
Date: Sun, 6 Mar 2022 23:58:06 GMT
Subject: Integrated: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing
In-Reply-To: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
Message-ID: <YXEKwRwzwT3gyoyv0JE6-NyWsq56oNxAXOuYrNmecxc=.7be8e3ae-6ba6-45b1-b09e-50ab1b015d08@github.com>

On Thu, 21 Oct 2021 12:19:43 GMT, Masanori Yano <myano at openjdk.org> wrote:

> Could you please review the 8275715 bug fixes?
> 
> I think D3DScreenUpdateManager posts unnecessary PaintEvent during processing PaintEvent. When the validate method is called from createGraphics, repaintPeerTarget should not be called.

This pull request has now been integrated.

Changeset: 415bf441
Author:    Masanori Yano <myano at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/415bf44191632cd8dbcc158c0ff0992c0b61c3ba
Stats:     92 lines in 2 files changed: 88 ins; 0 del; 4 mod

8275715: D3D pipeline processes multiple PaintEvent at initial drawing

Reviewed-by: prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/6064


From dholmes at openjdk.java.net  Mon Mar  7 00:16:06 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 7 Mar 2022 00:16:06 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <gTIPP0tHTsyPXjtsNrSHwLZMeEK5Y_GbDH-bA1Fit0I=.813d9ad7-a0d9-448b-9c35-06f249c168db@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
 <1xgNYge02zcX-kfQ343p2YT4v2MIbym5SHL_fDnqMPI=.ab03d946-c8ec-4a2f-871a-8d58e6a30f43@github.com>
 <gTIPP0tHTsyPXjtsNrSHwLZMeEK5Y_GbDH-bA1Fit0I=.813d9ad7-a0d9-448b-9c35-06f249c168db@github.com>
Message-ID: <Vs_8fuUEuC3aFZdlryNPK6zLtaVKN6taXfoSGqFgQ-Q=.228bac9e-eef2-4dbb-9c29-a25f06fafad8@github.com>

On Wed, 2 Mar 2022 06:21:15 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Ok. Please confirm you have run all automated headful jtreg tests on a system with D3D enabled
>> and that you have also done manual testing (using SwingSet2 and J2Ddemo) and no problems are observed ?
>
> @prrace How long will it take for you to reply to the comment?

@masyano the new test has an invalid copyright notice: missing comma after 2021, which is causing a tier 1 build failure in our CI.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6064


From myano at openjdk.java.net  Mon Mar  7 00:21:04 2022
From: myano at openjdk.java.net (Masanori Yano)
Date: Mon, 7 Mar 2022 00:21:04 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <Vs_8fuUEuC3aFZdlryNPK6zLtaVKN6taXfoSGqFgQ-Q=.228bac9e-eef2-4dbb-9c29-a25f06fafad8@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
 <1xgNYge02zcX-kfQ343p2YT4v2MIbym5SHL_fDnqMPI=.ab03d946-c8ec-4a2f-871a-8d58e6a30f43@github.com>
 <gTIPP0tHTsyPXjtsNrSHwLZMeEK5Y_GbDH-bA1Fit0I=.813d9ad7-a0d9-448b-9c35-06f249c168db@github.com>
 <Vs_8fuUEuC3aFZdlryNPK6zLtaVKN6taXfoSGqFgQ-Q=.228bac9e-eef2-4dbb-9c29-a25f06fafad8@github.com>
Message-ID: <F24MmF4YPHRKmznTFEK4W9dyPjl3dU9AfR9JATICWBQ=.aef2bf67-2fca-4ef7-ac43-cd06ab737c06@github.com>

On Mon, 7 Mar 2022 00:12:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> @prrace How long will it take for you to reply to the comment?
>
> @masyano the new test has an invalid copyright notice: missing comma after 2021, which is causing a tier 1 build failure in our CI.

@dholmes-ora Thank you for notice. Should I create a new pull request to correct the copyright?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6064


From dholmes at openjdk.java.net  Mon Mar  7 00:21:05 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 7 Mar 2022 00:21:05 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
Message-ID: <sMcB342Xx6Sk9q69nQjyRiN5I1aT13Rn74gkX4CZCHE=.27a905f5-fbc7-4b2a-bc2b-d335a96e1f02@github.com>

On Thu, 28 Oct 2021 08:27:44 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the 8275715 bug fixes?
>> 
>> I think D3DScreenUpdateManager posts unnecessary PaintEvent during processing PaintEvent. When the validate method is called from createGraphics, repaintPeerTarget should not be called.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8275715: D3D pipeline processes multiple PaintEvent at initial drawing

New bug filed: JDK-8282713 - which will need a new PR. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6064


From myano at openjdk.java.net  Mon Mar  7 00:52:11 2022
From: myano at openjdk.java.net (Masanori Yano)
Date: Mon, 7 Mar 2022 00:52:11 GMT
Subject: RFR: 8282713: Invalid copyright notice in new test added by
 JDK-8275715
Message-ID: <nvfCgEiH_P828NNdt4k2_flGKjlZP66OqkD0fCBZ4HY=.ce5fe4e2-fb01-4eb3-a942-8027289f2981@github.com>

I would like to fix the missing comma in the copyright of the test added in JDK-8275715.
Could you please review the fix?

-------------

Commit messages:
 - 8282713: Invalid copyright notice in new test added by JDK-8275715

Changes: https://git.openjdk.java.net/jdk/pull/7716/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7716&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282713
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7716.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7716/head:pull/7716

PR: https://git.openjdk.java.net/jdk/pull/7716


From myano at openjdk.java.net  Mon Mar  7 00:59:03 2022
From: myano at openjdk.java.net (Masanori Yano)
Date: Mon, 7 Mar 2022 00:59:03 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
Message-ID: <ctGVHMZ9cVLlF1MP8957PLPadfAQwKO0XA_Sto3_6zA=.2a2448d3-ac23-44c2-913f-5b3cf8db4661@github.com>

On Thu, 28 Oct 2021 08:27:44 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the 8275715 bug fixes?
>> 
>> I think D3DScreenUpdateManager posts unnecessary PaintEvent during processing PaintEvent. When the validate method is called from createGraphics, repaintPeerTarget should not be called.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8275715: D3D pipeline processes multiple PaintEvent at initial drawing

I opened new PR at https://github.com/openjdk/jdk/pull/7716.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6064


From dholmes at openjdk.java.net  Mon Mar  7 01:06:59 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 7 Mar 2022 01:06:59 GMT
Subject: RFR: 8282713: Invalid copyright notice in new test added by
 JDK-8275715
In-Reply-To: <nvfCgEiH_P828NNdt4k2_flGKjlZP66OqkD0fCBZ4HY=.ce5fe4e2-fb01-4eb3-a942-8027289f2981@github.com>
References: <nvfCgEiH_P828NNdt4k2_flGKjlZP66OqkD0fCBZ4HY=.ce5fe4e2-fb01-4eb3-a942-8027289f2981@github.com>
Message-ID: <yc_RjQ1KtPGwzZK9u3eznHheDNq-xJIQzqaYpPGjStc=.e94eaa18-defd-4c48-af27-62584cf8f03e@github.com>

On Mon, 7 Mar 2022 00:46:12 GMT, Masanori Yano <myano at openjdk.org> wrote:

> I would like to fix the missing comma in the copyright of the test added in JDK-8275715.
> Could you please review the fix?

Looks good and trivial. Did you verify it fixes the problem with the `validate-source` target?

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7716


From dholmes at openjdk.java.net  Mon Mar  7 01:13:00 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 7 Mar 2022 01:13:00 GMT
Subject: RFR: 8282713: Invalid copyright notice in new test added by
 JDK-8275715
In-Reply-To: <nvfCgEiH_P828NNdt4k2_flGKjlZP66OqkD0fCBZ4HY=.ce5fe4e2-fb01-4eb3-a942-8027289f2981@github.com>
References: <nvfCgEiH_P828NNdt4k2_flGKjlZP66OqkD0fCBZ4HY=.ce5fe4e2-fb01-4eb3-a942-8027289f2981@github.com>
Message-ID: <AaQhdosBhI8FyFNwu76SNW9lAA8bYLs8glL-ZRqcwzs=.1de6cac6-5dd4-4371-989e-7d8bc4c42d67@github.com>

On Mon, 7 Mar 2022 00:46:12 GMT, Masanori Yano <myano at openjdk.org> wrote:

> I would like to fix the missing comma in the copyright of the test added in JDK-8275715.
> Could you please review the fix?

Just realized you can't run `validate-source`, so I will confirm fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7716


From myano at openjdk.java.net  Mon Mar  7 01:23:02 2022
From: myano at openjdk.java.net (Masanori Yano)
Date: Mon, 7 Mar 2022 01:23:02 GMT
Subject: RFR: 8282713: Invalid copyright notice in new test added by
 JDK-8275715
In-Reply-To: <nvfCgEiH_P828NNdt4k2_flGKjlZP66OqkD0fCBZ4HY=.ce5fe4e2-fb01-4eb3-a942-8027289f2981@github.com>
References: <nvfCgEiH_P828NNdt4k2_flGKjlZP66OqkD0fCBZ4HY=.ce5fe4e2-fb01-4eb3-a942-8027289f2981@github.com>
Message-ID: <kCiDxRrTZvTxM7ny3I-hpDS4gzG21UVBy0HeOMSboCc=.d81acac2-c992-4352-8e2f-b0d66e3e1e7a@github.com>

On Mon, 7 Mar 2022 00:46:12 GMT, Masanori Yano <myano at openjdk.org> wrote:

> I would like to fix the missing comma in the copyright of the test added in JDK-8275715.
> Could you please review the fix?

I was in trouble because it turned out to be "No rule to make target". Please confirm.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7716


From dholmes at openjdk.java.net  Mon Mar  7 01:33:00 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 7 Mar 2022 01:33:00 GMT
Subject: RFR: 8282713: Invalid copyright notice in new test added by
 JDK-8275715
In-Reply-To: <nvfCgEiH_P828NNdt4k2_flGKjlZP66OqkD0fCBZ4HY=.ce5fe4e2-fb01-4eb3-a942-8027289f2981@github.com>
References: <nvfCgEiH_P828NNdt4k2_flGKjlZP66OqkD0fCBZ4HY=.ce5fe4e2-fb01-4eb3-a942-8027289f2981@github.com>
Message-ID: <Uks77lBQjvmOfNEBexEUACsjdbe5KCbIuTo9tPEIF1E=.f6ad3f53-f12c-442a-b0fd-2be0a58f81be@github.com>

On Mon, 7 Mar 2022 00:46:12 GMT, Masanori Yano <myano at openjdk.org> wrote:

> I would like to fix the missing comma in the copyright of the test added in JDK-8275715.
> Could you please review the fix?

The actual build target is `validate-headers` but I have confirmed the fix. Please integrate asap. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7716


From myano at openjdk.java.net  Mon Mar  7 01:36:59 2022
From: myano at openjdk.java.net (Masanori Yano)
Date: Mon, 7 Mar 2022 01:36:59 GMT
Subject: Integrated: 8282713: Invalid copyright notice in new test added by
 JDK-8275715
In-Reply-To: <nvfCgEiH_P828NNdt4k2_flGKjlZP66OqkD0fCBZ4HY=.ce5fe4e2-fb01-4eb3-a942-8027289f2981@github.com>
References: <nvfCgEiH_P828NNdt4k2_flGKjlZP66OqkD0fCBZ4HY=.ce5fe4e2-fb01-4eb3-a942-8027289f2981@github.com>
Message-ID: <SXpxBVd8t-aPqeHrLD63C-sQK13V1vxqL24z1DYfzc8=.511c07c8-1e8a-4bc5-ab91-e1a59d47e8cf@github.com>

On Mon, 7 Mar 2022 00:46:12 GMT, Masanori Yano <myano at openjdk.org> wrote:

> I would like to fix the missing comma in the copyright of the test added in JDK-8275715.
> Could you please review the fix?

This pull request has now been integrated.

Changeset: 894ffb09
Author:    Masanori Yano <myano at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/894ffb098c80bfeb4209038c017d01dbf53fac0f
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8282713: Invalid copyright notice in new test added by JDK-8275715

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/7716


From prr at openjdk.java.net  Mon Mar  7 02:30:09 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 7 Mar 2022 02:30:09 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
Message-ID: <zvYqTWZxzC101Dn-B_tyt5mFbKDU-DkDro_y6_xbZrY=.f1e1a902-459b-4c35-ba7d-3f03339c7092@github.com>

On Thu, 28 Oct 2021 08:27:44 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the 8275715 bug fixes?
>> 
>> I think D3DScreenUpdateManager posts unnecessary PaintEvent during processing PaintEvent. When the validate method is called from createGraphics, repaintPeerTarget should not be called.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8275715: D3D pipeline processes multiple PaintEvent at initial drawing

FWIW this should not have been pushed without a 2nd reviewer (meaning two approvals). 
Please review the code review policies section here  https://openjdk.java.net/groups/client-libs/
where it says 
The standard requirement in Java SE is for one (or more) reviewer prior to code freeze and two (or more) reviewers thereafter. The Java Client Library Group has standardized on two reviewers with few exceptions.

You pushed with only one approval. Bear that in mind !

-------------

PR: https://git.openjdk.java.net/jdk/pull/6064


From serb at openjdk.java.net  Mon Mar  7 05:28:01 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 7 Mar 2022 05:28:01 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v3]
In-Reply-To: <ZMRyILWuQQGX4uTsGvmjSdpbkGVpTL_WGZSYtAbKJRg=.3f1853c7-d19a-4018-a116-e7a329c85d01@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <QhVV8XEk1m7hFhnnzwp4A1WnF-Yv1nqT8nMyrI1zS4M=.50a380db-f2b7-4965-a367-75e5eeb31515@github.com>
 <5gKSW29Ah7FkFKAqlcJxZekf1LYkHIVfY-C4rqfkmx4=.d0563bfc-de95-4726-a160-7cbdd22ceb66@github.com>
 <ZMRyILWuQQGX4uTsGvmjSdpbkGVpTL_WGZSYtAbKJRg=.3f1853c7-d19a-4018-a116-e7a329c85d01@github.com>
Message-ID: <-w_PHnFRbDuIBUvbgaSOYb7w9wl5sqgFasRIBQgyN4E=.3b002eac-d87c-4f42-a9c5-5d2df2e9012b@github.com>

On Wed, 17 Nov 2021 13:29:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> I don't see a reason to discard the various stability improvements.
>> The discussion is long so I may not be summarising correctly but 
>> - A product fix may resolve most of the issues and yet
>> - Stability fixes are still valuable
>> - The one test with a colour tolerance update may be better platform problem listed 
>> - The offset of -10,-10 for the cursor maybe better if it was parameterised and a bit bigger.
>
> @prrace Do you have any comments? If not, can you please approve?

@prsadhuk @prrace Did we report this to Apple? I have found that some of the tck tests could be unstable due to this, and "CGDisplayHideCursor/CGDisplayShowCursor" may cure it, but probably Apple suggests something else?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From mvs at openjdk.java.net  Mon Mar  7 06:49:37 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Mon, 7 Mar 2022 06:49:37 GMT
Subject: RFR: 8282234: Create a regression test for JDK-4532513 [v4]
In-Reply-To: <h3ZoydrpxAklsdt3qahYdowBNEwAh4lZo96oGx2EEVc=.e076785d-c06f-43af-a3b9-d76390ea1f33@github.com>
References: <h3ZoydrpxAklsdt3qahYdowBNEwAh4lZo96oGx2EEVc=.e076785d-c06f-43af-a3b9-d76390ea1f33@github.com>
Message-ID: <z_5sc9-2z3hqsz9i5v9__shRI8BovzuxfJtJOs0zx_A=.00142713-957e-4238-8849-24882b054f77@github.com>

> Create a regression test for [JDK-4532513](https://bugs.openjdk.java.net/browse/JDK-4532513).
> This test verifies that the DefaultCaret doesn't requests focus in mouseClick and mousePressed causing the associated input verifier to fire twice.
> As per [JDK-4532513](https://bugs.openjdk.java.net/browse/JDK-4532513), the DefaultCaret requests focus in mouseClick and mousePressed causing the associated input verifier to fire twice.
> This issue was raised in JDK 1.4.0 and fixed in 1.4.1, so the test need to be failed in 1.4.0 and must pass in 1.4.1.
> 
> Testing:
> 
> In JDK 1.4.0:
> $ ./j2sdk1.4.0/bin/java DefaultCaretWin
> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
> shouldYieldFocus called 1
> shouldYieldFocus called 2
> shouldYieldFocus called 3
> java.lang.RuntimeException: Test failed for javax.swing.plaf.metal.MetalLookAndFeel as InputVerifier.shouldYieldFocus() getting called 3 times on jTextField2, but it is expected to call only once.
>         at DefaultCaretWin.runTest(DefaultCaretWin.java:114)
>         at DefaultCaretWin.main(DefaultCaretWin.java:58)
> 
> In JDK 1.4.1:
> $ ./j2sdk1.4.1/bin/java DefaultCaretWin
> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
> shouldYieldFocus called 1
> Test passed for laf: javax.swing.plaf.metal.MetalLookAndFeel
> Testing L&F: com.sun.java.swing.plaf.motif.MotifLookAndFeel
> shouldYieldFocus called 1
> Test passed for laf: com.sun.java.swing.plaf.motif.MotifLookAndFeel
> Testing L&F: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> shouldYieldFocus called 1
> Test passed for laf: com.sun.java.swing.plaf.windows.WindowsLookAndFeel

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Moved the test from JTextArea to JTextField which is more appropriate

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7577/files
  - new: https://git.openjdk.java.net/jdk/pull/7577/files/96942f37..184f0824

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7577&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7577&range=02-03

  Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7577.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7577/head:pull/7577

PR: https://git.openjdk.java.net/jdk/pull/7577


From mvs at openjdk.java.net  Mon Mar  7 10:25:59 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Mon, 7 Mar 2022 10:25:59 GMT
Subject: RFR: 8282234: Create a regression test for JDK-4532513 [v5]
In-Reply-To: <h3ZoydrpxAklsdt3qahYdowBNEwAh4lZo96oGx2EEVc=.e076785d-c06f-43af-a3b9-d76390ea1f33@github.com>
References: <h3ZoydrpxAklsdt3qahYdowBNEwAh4lZo96oGx2EEVc=.e076785d-c06f-43af-a3b9-d76390ea1f33@github.com>
Message-ID: <utKt_vnJ4QneycG8N-qIy4ymXvpNloCgujknrDBawiU=.ea89d3e7-0c8c-4802-8fda-076ffe9720a5@github.com>

> Create a regression test for [JDK-4532513](https://bugs.openjdk.java.net/browse/JDK-4532513).
> This test verifies that the DefaultCaret doesn't requests focus in mouseClick and mousePressed causing the associated input verifier to fire twice.
> As per [JDK-4532513](https://bugs.openjdk.java.net/browse/JDK-4532513), the DefaultCaret requests focus in mouseClick and mousePressed causing the associated input verifier to fire twice.
> This issue was raised in JDK 1.4.0 and fixed in 1.4.1, so the test need to be failed in 1.4.0 and must pass in 1.4.1.
> 
> Testing:
> 
> In JDK 1.4.0:
> $ ./j2sdk1.4.0/bin/java DefaultCaretWin
> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
> shouldYieldFocus called 1
> shouldYieldFocus called 2
> shouldYieldFocus called 3
> java.lang.RuntimeException: Test failed for javax.swing.plaf.metal.MetalLookAndFeel as InputVerifier.shouldYieldFocus() getting called 3 times on jTextField2, but it is expected to call only once.
>         at DefaultCaretWin.runTest(DefaultCaretWin.java:114)
>         at DefaultCaretWin.main(DefaultCaretWin.java:58)
> 
> In JDK 1.4.1:
> $ ./j2sdk1.4.1/bin/java DefaultCaretWin
> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
> shouldYieldFocus called 1
> Test passed for laf: javax.swing.plaf.metal.MetalLookAndFeel
> Testing L&F: com.sun.java.swing.plaf.motif.MotifLookAndFeel
> shouldYieldFocus called 1
> Test passed for laf: com.sun.java.swing.plaf.motif.MotifLookAndFeel
> Testing L&F: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> shouldYieldFocus called 1
> Test passed for laf: com.sun.java.swing.plaf.windows.WindowsLookAndFeel

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed: Removed unwanted blank lines, removed ENTER key press

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7577/files
  - new: https://git.openjdk.java.net/jdk/pull/7577/files/184f0824..095e918a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7577&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7577&range=03-04

  Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7577.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7577/head:pull/7577

PR: https://git.openjdk.java.net/jdk/pull/7577


From erikj at openjdk.java.net  Mon Mar  7 13:44:05 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 7 Mar 2022 13:44:05 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <BYP-9VZJoznj9GWtwXRA99BqEtITgNUVrbDggKRdads=.8664f68e-92af-4dad-99c3-a7b0bb0e1e68@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <BYP-9VZJoznj9GWtwXRA99BqEtITgNUVrbDggKRdads=.8664f68e-92af-4dad-99c3-a7b0bb0e1e68@github.com>
Message-ID: <Axd1QHFh-k8zh76bMceeni5kEH2N5sU7O5JxGIt6bN8=.2186d5f3-deec-4540-8db4-b8548fe6286b@github.com>

On Sat, 5 Mar 2022 06:49:16 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change?

They need to match. You can either do it manually, or change the title to just the bug number and the bot will change it for you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7268


From jwaters at openjdk.java.net  Mon Mar  7 16:24:00 2022
From: jwaters at openjdk.java.net (Julian Waters)
Date: Mon, 7 Mar 2022 16:24:00 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <Axd1QHFh-k8zh76bMceeni5kEH2N5sU7O5JxGIt6bN8=.2186d5f3-deec-4540-8db4-b8548fe6286b@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <BYP-9VZJoznj9GWtwXRA99BqEtITgNUVrbDggKRdads=.8664f68e-92af-4dad-99c3-a7b0bb0e1e68@github.com>
 <Axd1QHFh-k8zh76bMceeni5kEH2N5sU7O5JxGIt6bN8=.2186d5f3-deec-4540-8db4-b8548fe6286b@github.com>
Message-ID: <WUgibFurfKq3h0sqZ2YDVuSbxl-gxhmgJPnoUPWpeX4=.7af5c5e5-a326-4708-9eb9-d64f41c9af7c@github.com>

On Mon, 7 Mar 2022 13:40:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change?
> 
> They need to match. You can either do it manually, or change the title to just the bug number and the bot will change it for you.

Alright, I can't change the title of the PR, I guess it'll be easier for me to change the issue instead

-------------

PR: https://git.openjdk.java.net/jdk/pull/7268


From lancea at openjdk.java.net  Mon Mar  7 16:43:08 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 7 Mar 2022 16:43:08 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

What problem are you having editing the PR header?   You should be able to do so as the author of the PR

-------------

PR: https://git.openjdk.java.net/jdk/pull/7268


From kcr at openjdk.java.net  Mon Mar  7 16:52:07 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 7 Mar 2022 16:52:07 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>
Message-ID: <OlXgsLnUYvaXKuqKPGlg36JcuDUmXp8jC-8P6Y2o35k=.e68e429a-72b7-4828-9ea6-2be0165d2cdf@github.com>

On Mon, 7 Mar 2022 16:40:15 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> What problem are you having editing the PR header? You should be able to do so as the author of the PR

Exactly. You should see an "Edit" button near the right edge of the PR title. See the attached image:

![PR-title](https://user-images.githubusercontent.com/34689748/157079404-eadbe8be-ae94-41e0-b17b-0d1a8026b9da.png)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7268


From kcr at openjdk.java.net  Mon Mar  7 16:56:06 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 7 Mar 2022 16:56:06 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <ya35_llZyJFaqTkVaOv3ybkki4iCaQUTO_PPCw8XaPg=.eb0e2be9-5ed0-4be8-8a14-47f573b6dbfb@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

But as the JBS title and PR title now match, this is a moot point.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7268


From ihse at openjdk.java.net  Mon Mar  7 17:18:03 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 7 Mar 2022 17:18:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>
Message-ID: <dBlj9TBpXi1bkSF7MrLzM2Sr_v5Hr4UUzLBYf3J63FY=.e99bba44-af79-4c57-b448-5e5a38633760@github.com>

On Mon, 7 Mar 2022 16:40:15 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi
>> 
>> I have reviewed the code for removing double semicolons at the end of lines
>> 
>> all the best
>> matteo
>
> What problem are you having editing the PR header?   You should be able to do so as the author of the PR

@LanceAndersen @kevinrushforth TheShermanTanker is not the author of this PR, he's just assisting the author by creating the JBS issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7268


From kcr at openjdk.java.net  Mon Mar  7 17:18:03 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 7 Mar 2022 17:18:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <dBlj9TBpXi1bkSF7MrLzM2Sr_v5Hr4UUzLBYf3J63FY=.e99bba44-af79-4c57-b448-5e5a38633760@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>
 <dBlj9TBpXi1bkSF7MrLzM2Sr_v5Hr4UUzLBYf3J63FY=.e99bba44-af79-4c57-b448-5e5a38633760@github.com>
Message-ID: <gU_j20iocr_5kNAxvBLGmM3fgGRXQdnmguOWyMdIe4E=.d980a805-e168-4a7d-b9d9-a1a09df4b870@github.com>

On Mon, 7 Mar 2022 17:12:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> TheShermanTanker is not the author of this PR, he's just assisting the author by creating the JBS issue.

Ah, that explains it then.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7268


From prr at openjdk.java.net  Mon Mar  7 18:05:10 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 7 Mar 2022 18:05:10 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v3]
In-Reply-To: <QhVV8XEk1m7hFhnnzwp4A1WnF-Yv1nqT8nMyrI1zS4M=.50a380db-f2b7-4965-a367-75e5eeb31515@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <QhVV8XEk1m7hFhnnzwp4A1WnF-Yv1nqT8nMyrI1zS4M=.50a380db-f2b7-4965-a367-75e5eeb31515@github.com>
Message-ID: <YX8ODU4QIcmDlXt4-5nZuxFnc7qS44NkUk_-xnYu6Vo=.3205ac38-c42c-4a85-968c-4bbc16ad092e@github.com>

On Fri, 29 Oct 2021 06:43:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
>> It was seen from the logs that we have color mismatch in these tests.
>> 
>> For example, in PressedIcon test, we had following log
>> 
>> ----------System.out:(1/75)----------
>> color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
>> ----------System.err:(13/842)----------
>> java.lang.RuntimeException: Colors is different for scale=1!
>> 	at PressedIconTest.main(PressedIconTest.java:97)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> and JInternalFrame test, we had 
>> ----------System.err:(15/939)----------
>> FRAME_COLOR Red: 255; Green: 200; Blue: 0
>> Pixel color Red: 55; Green: 55; Blue: 55
>> java.lang.RuntimeException: Internal frame is not correctly dragged!
>> 	at bug8069348.main(bug8069348.java:96)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
>> Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
>> Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.
>> 
>> The awt tests that are failing seems to have different root cause and will be handled separately.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review fix
>  - Fix

I can't see that we did but I have now.
One thing that occurred to me is that 
 Settings->Accessibility->Display->Shake mouse pointer to locate
is enabled by default and if our tests "warping" the pointer trigger this then maybe it could be why we see the pointer - I can imagine that the mode for large pointer isn't immediately turned off.
So disabling that setting maybe is worth adding to all our systems

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From aivanov at openjdk.java.net  Mon Mar  7 21:24:00 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 7 Mar 2022 21:24:00 GMT
Subject: RFR: 8282234: Create a regression test for JDK-4532513 [v5]
In-Reply-To: <utKt_vnJ4QneycG8N-qIy4ymXvpNloCgujknrDBawiU=.ea89d3e7-0c8c-4802-8fda-076ffe9720a5@github.com>
References: <h3ZoydrpxAklsdt3qahYdowBNEwAh4lZo96oGx2EEVc=.e076785d-c06f-43af-a3b9-d76390ea1f33@github.com>
 <utKt_vnJ4QneycG8N-qIy4ymXvpNloCgujknrDBawiU=.ea89d3e7-0c8c-4802-8fda-076ffe9720a5@github.com>
Message-ID: <trB9LwlYaZtBZkv9yh-o7AkE2-HmBX1hlsudUFzKyx0=.4d452b71-9f93-43dc-a630-bd067a40b695@github.com>

On Mon, 7 Mar 2022 10:25:59 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Create a regression test for [JDK-4532513](https://bugs.openjdk.java.net/browse/JDK-4532513).
>> This test verifies that the DefaultCaret doesn't requests focus in mouseClick and mousePressed causing the associated input verifier to fire twice.
>> As per [JDK-4532513](https://bugs.openjdk.java.net/browse/JDK-4532513), the DefaultCaret requests focus in mouseClick and mousePressed causing the associated input verifier to fire twice.
>> This issue was raised in JDK 1.4.0 and fixed in 1.4.1, so the test need to be failed in 1.4.0 and must pass in 1.4.1.
>> 
>> Testing:
>> 
>> In JDK 1.4.0:
>> $ ./j2sdk1.4.0/bin/java DefaultCaretWin
>> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
>> shouldYieldFocus called 1
>> shouldYieldFocus called 2
>> shouldYieldFocus called 3
>> java.lang.RuntimeException: Test failed for javax.swing.plaf.metal.MetalLookAndFeel as InputVerifier.shouldYieldFocus() getting called 3 times on jTextField2, but it is expected to call only once.
>>         at DefaultCaretWin.runTest(DefaultCaretWin.java:114)
>>         at DefaultCaretWin.main(DefaultCaretWin.java:58)
>> 
>> In JDK 1.4.1:
>> $ ./j2sdk1.4.1/bin/java DefaultCaretWin
>> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
>> shouldYieldFocus called 1
>> Test passed for laf: javax.swing.plaf.metal.MetalLookAndFeel
>> Testing L&F: com.sun.java.swing.plaf.motif.MotifLookAndFeel
>> shouldYieldFocus called 1
>> Test passed for laf: com.sun.java.swing.plaf.motif.MotifLookAndFeel
>> Testing L&F: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>> shouldYieldFocus called 1
>> Test passed for laf: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: Removed unwanted blank lines, removed ENTER key press

Marked as reviewed by aivanov (Reviewer).

test/jdk/javax/swing/JTextField/4532513/DefaultCaretRequestsFocusTest.java line 119:

> 117:                     throw new RuntimeException("Test failed for " + laf
> 118:                             + " as InputVerifier.shouldYieldFocus() getting called " + shouldYieldFocusCount
> 119:                             + " times on jTextField2, but it is expected to call only once.");

Suggestion:

                            + " as InputVerifier.shouldYieldFocus() was called " + shouldYieldFocusCount
                            + " times on jTextField2, but it is expected to be called only once.");

-------------

PR: https://git.openjdk.java.net/jdk/pull/7577


From duke at openjdk.java.net  Mon Mar  7 21:37:05 2022
From: duke at openjdk.java.net (Matteo Baccan)
Date: Mon, 7 Mar 2022 21:37:05 GMT
Subject: Integrated: 8282657: Code cleanup: removing double semicolons at the
 end of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <IOsP6dA-9UbtLKUQwfdQE9Z6Lc6qO2iUIy_8Ywsk4Z0=.cbc4836e-3973-4cb3-bdb6-c413368ce9f5@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

This pull request has now been integrated.

Changeset: ccad3923
Author:    Matteo Baccan <matteo.baccan at gmail.com>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ccad39237ab860c5c5579537f740177e3f1adcc9
Stats:     93 lines in 82 files changed: 0 ins; 0 del; 93 mod

8282657: Code cleanup: removing double semicolons at the end of lines

Reviewed-by: lancea, rriggs, ihse, prr, iris, wetmore, darcy, dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/7268


From duke at openjdk.java.net  Mon Mar  7 23:42:24 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Mon, 7 Mar 2022 23:42:24 GMT
Subject: RFR: 8282771 : Create test case for JDK-8262981
Message-ID: <pbRcgoRd0mYiHu3ASOMDqfVCJuyKZsKKSZd3JlguYaM=.0770dc62-36be-42e8-b88e-6425263fd6dd@github.com>

Following methods are covered in this testcase
getAccessibleAction()
getAccessibleActionCount()
getAccessibleActionDescription()
doAccessibleAction(int direction) 

@shurymury

-------------

Commit messages:
 - Fixed white issue
 - 8282771 : Create test case for JDK-8262981

Changes: https://git.openjdk.java.net/jdk/pull/7734/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7734&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282771
  Stats: 312 lines in 1 file changed: 312 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7734.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7734/head:pull/7734

PR: https://git.openjdk.java.net/jdk/pull/7734


From duke at openjdk.java.net  Mon Mar  7 23:56:23 2022
From: duke at openjdk.java.net (Rajat Mahajan)
Date: Mon, 7 Mar 2022 23:56:23 GMT
Subject: RFR: 8249592 : Robot.mouseMove moves cursor to incorrect location when
 display scale varies and Java runs in DPI Unaware mode
Message-ID: <7SyMjVox8LbT2ZqI1n0fj8nwb3YsCXfrap6VuGtNVbc=.e8c0bd94-c477-4a69-839f-25e7b3d31f7d@github.com>

8249592 : Robot.mouseMove moves cursor to incorrect location when display scale varies and Java runs in DPI Unaware mode

-------------

Commit messages:
 - 8249592: Robot.mouseMove moves cursor to incorrect location when display scale varies and Java runs in DPI Unaware mode
 - 8249592: Robot.mouseMove moves cursor to incorrect location when display scale varies and Java runs in DPI Unaware mode

Changes: https://git.openjdk.java.net/jdk/pull/7736/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7736&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8249592
  Stats: 22 lines in 1 file changed: 14 ins; 4 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7736.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7736/head:pull/7736

PR: https://git.openjdk.java.net/jdk/pull/7736


From duke at openjdk.java.net  Tue Mar  8 03:04:40 2022
From: duke at openjdk.java.net (Rajat Mahajan)
Date: Tue, 8 Mar 2022 03:04:40 GMT
Subject: RFR: 8249592 : Robot.mouseMove moves cursor to incorrect location
 when display scale varies and Java runs in DPI Unaware mode [v2]
In-Reply-To: <7SyMjVox8LbT2ZqI1n0fj8nwb3YsCXfrap6VuGtNVbc=.e8c0bd94-c477-4a69-839f-25e7b3d31f7d@github.com>
References: <7SyMjVox8LbT2ZqI1n0fj8nwb3YsCXfrap6VuGtNVbc=.e8c0bd94-c477-4a69-839f-25e7b3d31f7d@github.com>
Message-ID: <3coBtonKSRsFrz2LQekjlGWXtP9RG18NZMzwbUirB9o=.17df2580-16bd-49bf-93c1-472c20d173a8@github.com>

> 8249592 : Robot.mouseMove moves cursor to incorrect location when display scale varies and Java runs in DPI Unaware mode

Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:

  removed stdlib.h, not needed

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7736/files
  - new: https://git.openjdk.java.net/jdk/pull/7736/files/ea9e748c..52700714

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7736&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7736&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7736.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7736/head:pull/7736

PR: https://git.openjdk.java.net/jdk/pull/7736


From serb at openjdk.java.net  Tue Mar  8 03:55:06 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 8 Mar 2022 03:55:06 GMT
Subject: RFR: 8249592 : Robot.mouseMove moves cursor to incorrect location
 when display scale varies and Java runs in DPI Unaware mode [v2]
In-Reply-To: <3coBtonKSRsFrz2LQekjlGWXtP9RG18NZMzwbUirB9o=.17df2580-16bd-49bf-93c1-472c20d173a8@github.com>
References: <7SyMjVox8LbT2ZqI1n0fj8nwb3YsCXfrap6VuGtNVbc=.e8c0bd94-c477-4a69-839f-25e7b3d31f7d@github.com>
 <3coBtonKSRsFrz2LQekjlGWXtP9RG18NZMzwbUirB9o=.17df2580-16bd-49bf-93c1-472c20d173a8@github.com>
Message-ID: <BG1Al6mxI40fhN5LWWVoCrP1MkYzPOx6dohEIooBN8E=.0da9d2e1-c20f-40e2-9048-e63e00d46929@github.com>

On Tue, 8 Mar 2022 03:04:40 GMT, Rajat Mahajan <duke at openjdk.java.net> wrote:

>> 8249592 : Robot.mouseMove moves cursor to incorrect location when display scale varies and Java runs in DPI Unaware mode
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed stdlib.h, not needed

src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp line 53:

> 51: 
> 52:     ::SendInput(1, &mouseInput, sizeof(mouseInput));
> 53: 

This change looks fine, the only suggestion I have is to split the long lines and use the 80 chars per line.

Please also confirm that mach5 is green.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7736


From serb at openjdk.java.net  Tue Mar  8 04:15:05 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 8 Mar 2022 04:15:05 GMT
Subject: RFR: 8282577: ICC_Profile.setData(int,
 byte[]) invalidates the profile [v3]
In-Reply-To: <XTG2b5zZA9u3_Km2pJCA3xCsJzJl_tjOfnXGNunixgY=.c92ea820-38bc-4668-b8cc-350915a6fc7a@github.com>
References: <ecPAoejPCnfczdYoQmH89792PmRZxg4Rc5LaEHlsnXo=.3ad1b170-e862-4322-9164-df0501b298a0@github.com>
 <XTG2b5zZA9u3_Km2pJCA3xCsJzJl_tjOfnXGNunixgY=.c92ea820-38bc-4668-b8cc-350915a6fc7a@github.com>
Message-ID: <OtKvQNBuh1av_6S-qU2Nufz_hr4bD_-V8gSHyJBNgAw=.1bbdad9c-efb8-4f2d-ad51-5dea50df43ab@github.com>

On Thu, 3 Mar 2022 21:27:36 GMT, Phil Race <prr at openjdk.org> wrote:

>> As per the bug eval, we are returning a pointer to a native raw LittleCMS profile and it should be a cooked one.
>> The simple test fails before the fix with
>> ~/jdk17/Contents/Home/bin/java SetTagDataValidation                               
>> Exception in thread "main" java.awt.color.CMMException: LCMS error 13: Couldn't link the profiles
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createNativeTransform(Native Method)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createTransform(LCMS.java:104)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.doTransform(LCMSTransform.java:143)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.colorConvert(LCMSTransform.java:633)
>> 	at java.desktop/java.awt.color.ICC_ColorSpace.toRGB(ICC_ColorSpace.java:224)
>> 	at SetTagDataValidation.main(SetTagDataValidation.java:61)
>> 
>> and with the fix  just prints 
>> java SetTagDataValidation
>> 0.4
>> 0.5000076
>> 0.6
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282577: ICC_Profile.setData(int, byte[]) invalidates the profile

The current bug looks similar to this one https://bugs.openjdk.java.net/browse/JDK-8272865 I tried to fix it the same way but I was not sure if it is safe to ignore the ReadWriteProfileTest.java or not, since it has five related bugids.

test/jdk/java/awt/color/ICC_Profile/MTGetData.java line 106:

> 104:                     icc.setData(tag, data2);
> 105:                 }
> 106:             } catch (CMMException cmmEx) {

Don't we need to throw the IllegalArgumentException instead of CMMException?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7668


From serb at openjdk.java.net  Tue Mar  8 04:35:57 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 8 Mar 2022 04:35:57 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux
In-Reply-To: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
Message-ID: <uJtU1TV7PpGwucAAZvR8OjZsr9LBdjm_wniaJt2vFsc=.c4042f93-8285-4b27-ba85-f1b41a4423da@github.com>

On Fri, 21 Jan 2022 17:02:38 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

> These crashes were not reproducible, so the fix is based on a hypothesis that there are two possible reasons for them:
> 1. `makeDefaultConfig()` returning `NULL`.
> 2. A race condition when the number of screens changes.
> The race scenario: `X11GraphisDevice.makeDefaultConfiguration()` is called on EDT so the call can race with `X11GraphisDevice.invalidate()` that re-sets the screen number of the device; the latter is invoked on the `AWT-XAWT` thread from `X11GraphicsEnvironment.rebuildDevices()`. So by the time `makeDefaultConfiguration()` makes a native call with the device's current screen number, the `x11Screens` array maintained by the native code could have become shorter. And the native methods like `Java_sun_awt_X11GraphicsDevice_getConfigColormap()` assume that the number passed to them is always current and valid. The AWT lock only protects against the changes during the native methods invocation and does not protect against them being called with an outdated screen number. With a larger screen number, those methods read past the end of the `x11Screens` array.
> 
> The fix for (1) is to die gracefully instead of crashing in an attempt to de-reference a `NULL` pointer, which might happen upon returning from `makeDefaultConfig()` in `getAllConfigs()`.
> 
> The fix for (2) is to eliminate the race by protecting `X11GraphisDevice.screen` with the AWT lock such that it doesn't change when the native methods working with it are active.
> 
> We've been shipping JetBrains Runtime with this fix for a few months now and there were no crash reports with those specific patterns against the versions with the fix.

Sorry for the delay, I have started to look at it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7182


From serb at openjdk.java.net  Tue Mar  8 04:38:08 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 8 Mar 2022 04:38:08 GMT
Subject: RFR: 8281284 : Write JSlider accessibility test [v5]
In-Reply-To: <WvwD8UFahxh4RyMHJIMuXrRQvc225Lo9QKKXY5qbRK0=.36eaafd9-7f1d-4686-bada-b81b91dbbf8e@github.com>
References: <VB8Ldq_d1uZBKpyvvDlu7t9lUtAd_WhLl4meSv46ixo=.b8b023ee-6946-407d-8e05-223fb2d95062@github.com>
 <WvwD8UFahxh4RyMHJIMuXrRQvc225Lo9QKKXY5qbRK0=.36eaafd9-7f1d-4686-bada-b81b91dbbf8e@github.com>
Message-ID: <nMUEJwP-36E6lQ9XRJt1tgJ-8D-Q3Md2g3sntjDwPWU=.ef3f9769-c471-49f0-9450-14861d39bb74@github.com>

On Thu, 3 Mar 2022 17:11:39 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> This testcase covers both old and new api ( api added in jdk17  getAccessibleAction(), getAccessibleActionCount() , getAccessibleActionDescription )
>> 
>> @shurymury 
>> @savoptik
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   run the on windows and mac

test/jdk/java/awt/a11y/AccessibleJSliderTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2022 Oracle and/or its affiliates. All rights reserved.

A comma after the date?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7355


From serb at openjdk.java.net  Tue Mar  8 04:54:01 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 8 Mar 2022 04:54:01 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v2]
In-Reply-To: <e2kuv7ZIhCBFVsdOaBTQLsvEah30BhTsk721cke6nsc=.a16cdabb-7566-418d-b89e-de43b9573290@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <6sowygRcdclz1LCYIHZSWMKV2LhuPo0D_EaYC_JIq0c=.b25c1f95-2510-4372-a8e4-99178d1762ce@github.com>
 <9TbYruwfo7JM4xbW6Mwj_WAAXdbrZR3O62Cc6xgt2TI=.74af7b62-adef-4b98-b195-4f9d47d5098d@github.com>
 <e2kuv7ZIhCBFVsdOaBTQLsvEah30BhTsk721cke6nsc=.a16cdabb-7566-418d-b89e-de43b9573290@github.com>
Message-ID: <oTP9s3hH1t5pNZz3PA-VvGs07r7KcBory6QosyVesRA=.cf4b7478-116d-4a28-88da-5dd7c91e0bbe@github.com>

On Sat, 5 Mar 2022 08:27:10 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> test/jdk/java/awt/Robot/HiDPIScreenCapture/ScreenCaptureGtkTest.java line 44:
>> 
>>> 42:  * @run main/othervm -Djdk.gtk.version=2 -Dsun.java2d.uiScale=1 ScreenCaptureGtkTest
>>> 43:  * @run main/othervm -Djdk.gtk.version=3 -Dsun.java2d.uiScale=1 ScreenCaptureGtkTest
>>> 44:  */
>> 
>> So having removed all of these, it isn't testing hi-dpi any more, is it ? Even if running on a hi-dpi screen.
>> Would it be better to let it just use whatever it wants for default ? Meaning if it happens to run on a hi-dpi
>> screen we want to know if that works don't we ?
>
>> So having removed all of these, it isn't testing hi-dpi any more, is it ?
> 
> True. But there still is `ScreenCaptureTest.java` that will continue testing hi-dpi. 
> 
> Keeping `ScreenCaptureGtkTest.java` still makes sense because it verifies that `getPixelColor()` works precisely when neighboring pixels are of a different color; also, it shuffles the GTK versions.
> 
> Unfortunately, I see no way to fully and reliably test the changes for 8280861 with scaling above 1. I am forced to choose between two evils: 
> 1. either I set the scale above 1 and pick color inside a large area to be sure that I don't pick neighboring pixels because of an unfortunate window placement
> 1. or I set the scale to 1 and test colors of pixels sitting next to one another.
> 
> (1) was tested by the existing tests, (2) is tested by `ScreenCaptureGtkTest.java`.

you can check both cases, if the scale=1 then use high precision.
if the scale > 1 then you can use low precision -> if the scale is equal to 2 then shift by two/four pixels or something like that?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From serb at openjdk.java.net  Tue Mar  8 05:08:05 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 8 Mar 2022 05:08:05 GMT
Subject: RFR: 8282577: ICC_Profile.setData(int,
 byte[]) invalidates the profile [v3]
In-Reply-To: <XTG2b5zZA9u3_Km2pJCA3xCsJzJl_tjOfnXGNunixgY=.c92ea820-38bc-4668-b8cc-350915a6fc7a@github.com>
References: <ecPAoejPCnfczdYoQmH89792PmRZxg4Rc5LaEHlsnXo=.3ad1b170-e862-4322-9164-df0501b298a0@github.com>
 <XTG2b5zZA9u3_Km2pJCA3xCsJzJl_tjOfnXGNunixgY=.c92ea820-38bc-4668-b8cc-350915a6fc7a@github.com>
Message-ID: <Aqa2p8-xDo4e2vwxbFTpOHOcGQLP0CKnq8CUsVoNhZY=.726195f5-cddb-456d-81d4-fc3b137faff4@github.com>

On Thu, 3 Mar 2022 21:27:36 GMT, Phil Race <prr at openjdk.org> wrote:

>> As per the bug eval, we are returning a pointer to a native raw LittleCMS profile and it should be a cooked one.
>> The simple test fails before the fix with
>> ~/jdk17/Contents/Home/bin/java SetTagDataValidation                               
>> Exception in thread "main" java.awt.color.CMMException: LCMS error 13: Couldn't link the profiles
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createNativeTransform(Native Method)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createTransform(LCMS.java:104)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.doTransform(LCMSTransform.java:143)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.colorConvert(LCMSTransform.java:633)
>> 	at java.desktop/java.awt.color.ICC_ColorSpace.toRGB(ICC_ColorSpace.java:224)
>> 	at SetTagDataValidation.main(SetTagDataValidation.java:61)
>> 
>> and with the fix  just prints 
>> java SetTagDataValidation
>> 0.4
>> 0.5000076
>> 0.6
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282577: ICC_Profile.setData(int, byte[]) invalidates the profile

src/java.desktop/share/native/liblcms/LCMS.c line 765:

> 763:         // The profile we used for sanity checking needs to be returned
> 764:         // since the one we updated is raw - not cooked.
> 765:         cmsCloseProfile(p);

Looks like now we close this profile in all branches, so can we do that just above the "if (pfSanity == NULL)"?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7668


From duke at openjdk.java.net  Tue Mar  8 05:10:51 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Tue, 8 Mar 2022 05:10:51 GMT
Subject: RFR: 8282771 : Create test case for JDK-8262981 [v2]
In-Reply-To: <pbRcgoRd0mYiHu3ASOMDqfVCJuyKZsKKSZd3JlguYaM=.0770dc62-36be-42e8-b88e-6425263fd6dd@github.com>
References: <pbRcgoRd0mYiHu3ASOMDqfVCJuyKZsKKSZd3JlguYaM=.0770dc62-36be-42e8-b88e-6425263fd6dd@github.com>
Message-ID: <usATVM-CnG-KZiEBBuQyS-D8Muz1H_u6iZvuv3NY-PA=.2a6b01bb-a8e7-4048-851d-4ba6bd129a82@github.com>

> Following methods are covered in this testcase
> getAccessibleAction()
> getAccessibleActionCount()
> getAccessibleActionDescription()
> doAccessibleAction(int direction) 
> 
> @shurymury

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  Added command after the date

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7734/files
  - new: https://git.openjdk.java.net/jdk/pull/7734/files/51439f7f..5caf9a3b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7734&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7734&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7734.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7734/head:pull/7734

PR: https://git.openjdk.java.net/jdk/pull/7734


From duke at openjdk.java.net  Tue Mar  8 05:13:44 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Tue, 8 Mar 2022 05:13:44 GMT
Subject: RFR: 8281284 : Write JSlider accessibility test [v6]
In-Reply-To: <VB8Ldq_d1uZBKpyvvDlu7t9lUtAd_WhLl4meSv46ixo=.b8b023ee-6946-407d-8e05-223fb2d95062@github.com>
References: <VB8Ldq_d1uZBKpyvvDlu7t9lUtAd_WhLl4meSv46ixo=.b8b023ee-6946-407d-8e05-223fb2d95062@github.com>
Message-ID: <fDOHV-OlzUk7WMu8mwl33ZjJLUJWqN9JPUfxe_WL9JA=.95cad332-bdca-4af4-9eaa-3a7a83be0606@github.com>

> This testcase covers both old and new api ( api added in jdk17  getAccessibleAction(), getAccessibleActionCount() , getAccessibleActionDescription )
> 
> @shurymury 
> @savoptik

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  Added comma after the date

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7355/files
  - new: https://git.openjdk.java.net/jdk/pull/7355/files/b815681d..fcc32f70

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7355&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7355&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7355.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7355/head:pull/7355

PR: https://git.openjdk.java.net/jdk/pull/7355


From duke at openjdk.java.net  Tue Mar  8 05:13:46 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Tue, 8 Mar 2022 05:13:46 GMT
Subject: RFR: 8281284 : Write JSlider accessibility test [v5]
In-Reply-To: <nMUEJwP-36E6lQ9XRJt1tgJ-8D-Q3Md2g3sntjDwPWU=.ef3f9769-c471-49f0-9450-14861d39bb74@github.com>
References: <VB8Ldq_d1uZBKpyvvDlu7t9lUtAd_WhLl4meSv46ixo=.b8b023ee-6946-407d-8e05-223fb2d95062@github.com>
 <WvwD8UFahxh4RyMHJIMuXrRQvc225Lo9QKKXY5qbRK0=.36eaafd9-7f1d-4686-bada-b81b91dbbf8e@github.com>
 <nMUEJwP-36E6lQ9XRJt1tgJ-8D-Q3Md2g3sntjDwPWU=.ef3f9769-c471-49f0-9450-14861d39bb74@github.com>
Message-ID: <enTvL-EzrNEBf8v4Ct7H8T2FosNS3gDSE90vwFwvgIw=.b6e911c7-24fa-4b92-8d85-6822b10c8542@github.com>

On Tue, 8 Mar 2022 04:34:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   run the on windows and mac
>
> test/jdk/java/awt/a11y/AccessibleJSliderTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2022 Oracle and/or its affiliates. All rights reserved.
> 
> A comma after the date?

Added comma after the date.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7355


From mvs at openjdk.java.net  Tue Mar  8 05:25:56 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 8 Mar 2022 05:25:56 GMT
Subject: RFR: 8282234: Create a regression test for JDK-4532513 [v6]
In-Reply-To: <h3ZoydrpxAklsdt3qahYdowBNEwAh4lZo96oGx2EEVc=.e076785d-c06f-43af-a3b9-d76390ea1f33@github.com>
References: <h3ZoydrpxAklsdt3qahYdowBNEwAh4lZo96oGx2EEVc=.e076785d-c06f-43af-a3b9-d76390ea1f33@github.com>
Message-ID: <xReAg4lbK0JkwSHVvjpZvyxt_yKOP-VJN778Y5VLnJQ=.cc685092-fe02-496d-bac5-95e6f25b4fbf@github.com>

> Create a regression test for [JDK-4532513](https://bugs.openjdk.java.net/browse/JDK-4532513).
> This test verifies that the DefaultCaret doesn't requests focus in mouseClick and mousePressed causing the associated input verifier to fire twice.
> As per [JDK-4532513](https://bugs.openjdk.java.net/browse/JDK-4532513), the DefaultCaret requests focus in mouseClick and mousePressed causing the associated input verifier to fire twice.
> This issue was raised in JDK 1.4.0 and fixed in 1.4.1, so the test need to be failed in 1.4.0 and must pass in 1.4.1.
> 
> Testing:
> 
> In JDK 1.4.0:
> $ ./j2sdk1.4.0/bin/java DefaultCaretWin
> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
> shouldYieldFocus called 1
> shouldYieldFocus called 2
> shouldYieldFocus called 3
> java.lang.RuntimeException: Test failed for javax.swing.plaf.metal.MetalLookAndFeel as InputVerifier.shouldYieldFocus() getting called 3 times on jTextField2, but it is expected to call only once.
>         at DefaultCaretWin.runTest(DefaultCaretWin.java:114)
>         at DefaultCaretWin.main(DefaultCaretWin.java:58)
> 
> In JDK 1.4.1:
> $ ./j2sdk1.4.1/bin/java DefaultCaretWin
> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
> shouldYieldFocus called 1
> Test passed for laf: javax.swing.plaf.metal.MetalLookAndFeel
> Testing L&F: com.sun.java.swing.plaf.motif.MotifLookAndFeel
> shouldYieldFocus called 1
> Test passed for laf: com.sun.java.swing.plaf.motif.MotifLookAndFeel
> Testing L&F: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> shouldYieldFocus called 1
> Test passed for laf: com.sun.java.swing.plaf.windows.WindowsLookAndFeel

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Review comment fixed: Updated error message

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7577/files
  - new: https://git.openjdk.java.net/jdk/pull/7577/files/095e918a..8f228a72

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7577&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7577&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7577.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7577/head:pull/7577

PR: https://git.openjdk.java.net/jdk/pull/7577


From smandalika at openjdk.java.net  Tue Mar  8 08:23:40 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Tue, 8 Mar 2022 08:23:40 GMT
Subject: RFR: JDK-8282777: Create a Regression test for JDK-4515031
Message-ID: <D8K1EcGCjhQQzplHsgYncKPvGmSPhrAs7RNDIl_pQlo=.e8d60f67-9cf4-4ac7-957b-ddbecffc85de@github.com>

Create a Regression test for [JDK-4515031](https://bugs.openjdk.java.net/browse/JDK-4515031)

The issue indicates the need for a a getAccessibleDescription being implemented for the JFileChooser.
The test added verifies the same.

-------------

Commit messages:
 - 8282777:Create a Regression test for JDK-4515031

Changes: https://git.openjdk.java.net/jdk/pull/7738/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7738&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282777
  Stats: 98 lines in 1 file changed: 98 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7738.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7738/head:pull/7738

PR: https://git.openjdk.java.net/jdk/pull/7738


From smandalika at openjdk.java.net  Tue Mar  8 08:33:27 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Tue, 8 Mar 2022 08:33:27 GMT
Subject: RFR: JDK-8282778: Create a regression test for JDK-4699544
Message-ID: <IDgBuK7aFq5DBF_2mWS-l27LMVG9XSZe-2Zl_bITg3M=.527d9ca4-e081-4ce2-b123-1f2580f5e017@github.com>

Create a regression test for JDK-4699544

The subclass of javax.swing.JRootPane (AccessibleJRootPane) that implements the accessibility interface javax.accessibility.AccessibleComponent is derived from java.awt.AccessibleAWTComponent, which returns null for getAccessibleAt() because a component does not necessarily have childs.

The root pane always has a content pane child, so getAccessibleAt() should be overwritten by AccessibleJRootPane appropriately.
The test added verifies the same.

-------------

Commit messages:
 - 8282778: Create a regression test for JDK-4699544

Changes: https://git.openjdk.java.net/jdk/pull/7739/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7739&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282778
  Stats: 57 lines in 1 file changed: 57 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7739.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7739/head:pull/7739

PR: https://git.openjdk.java.net/jdk/pull/7739


From serb at openjdk.java.net  Tue Mar  8 09:24:08 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 8 Mar 2022 09:24:08 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig()
In-Reply-To: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
Message-ID: <vlXvB8DZMIq-ReuFB7SgtYI1OvADATcJ8tZdNu3pbTo=.6843b81b-de36-4970-80ae-43a761e865fe@github.com>

On Fri, 4 Mar 2022 13:25:12 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs`
> 
> Test:
> 
> - [x] jdk_desktop on Linux x86_64

src/java.desktop/unix/native/common/awt/fontpath.c line 938:

> 936:             while ((cnt < max) && (cacheDir = (*FcStrListNext)(cacheDirs))) {
> 937:                 jstr = (*env)->NewStringUTF(env, (const char*)cacheDir);
> 938:                 JNU_CHECK_EXCEPTION_AND_CLEANUP(env, (*FcStrListDone)(cacheDirs));

I think you do not need to create an additional macro here, just inline it and call "(*FcStrListDone)(cacheDirs);" directly. Something like:

if (IS_NULL(jstr) {
    (*FcStrListDone)(cacheDirs);
    return;
}

Note that the "IS_NULL" is used in this file after NewStringUTF. Any objections?

src/java.desktop/unix/native/common/awt/fontpath.c line 940:

> 938:                 JNU_CHECK_EXCEPTION_AND_CLEANUP(env, (*FcStrListDone)(cacheDirs));
> 939: 
> 940:                 (*env)->SetObjectArrayElement(env, cacheDirArray, cnt++, jstr);

Probably we should add the check+cleanup after the SetObjectArrayElement? Otherwise, we may call NewStringUTF while an exception is raised by the SetObjectArrayElement.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7691


From mvs at openjdk.java.net  Tue Mar  8 10:13:25 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 8 Mar 2022 10:13:25 GMT
Subject: RFR: 8282548: Create a regression test for JDK-4330998
Message-ID: <7HqoT6jmH4HyYQUli2v_MDFwkk8BV-e-0uAEFyxBmkI=.735e0071-2c02-423a-9647-9f33a0fedfa4@github.com>

Create a regression test for [JDK-4330998](https://bugs.openjdk.java.net/browse/JDK-4330998)

Issue tested:
When calling JEditorPane.setText(null), the following exception is thrown:

java.lang.NullPointerException:
        at java.io.StringReader.<init>(StringReader.java:38)

Testing:
Java 1.4.0 -> Test Failed.
$ ./j2sdk1.4.0/bin/java bug4330998Win
java.lang.RuntimeException: Test failed, caught Exception java.lang.NullPointerException when calling text.setText(null)
        at bug4330998Win.runTest(bug4330998Win.java:45)
        at bug4330998Win.main(bug4330998Win.java:51)
Exception in thread "main"

Java 1.4.1 -> Test Passed.
$ ./j2sdk1.4.1/bin/java bug4330998Win
Test passed

-------------

Commit messages:
 - 8282548: Create a regression test for JDK-4330998

Changes: https://git.openjdk.java.net/jdk/pull/7740/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7740&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282548
  Stats: 55 lines in 1 file changed: 55 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7740.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7740/head:pull/7740

PR: https://git.openjdk.java.net/jdk/pull/7740


From mvs at openjdk.java.net  Tue Mar  8 10:57:06 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 8 Mar 2022 10:57:06 GMT
Subject: RFR: 8282548: Create a regression test for JDK-4330998
In-Reply-To: <7HqoT6jmH4HyYQUli2v_MDFwkk8BV-e-0uAEFyxBmkI=.735e0071-2c02-423a-9647-9f33a0fedfa4@github.com>
References: <7HqoT6jmH4HyYQUli2v_MDFwkk8BV-e-0uAEFyxBmkI=.735e0071-2c02-423a-9647-9f33a0fedfa4@github.com>
Message-ID: <mX0mvtjp9BluziBd1BU3yfOxD2CtbUl5csoGipPHxbA=.de5b1858-9bd1-4e26-8071-b71ae44d7506@github.com>

On Tue, 8 Mar 2022 10:06:23 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Create a regression test for [JDK-4330998](https://bugs.openjdk.java.net/browse/JDK-4330998)
> Context: Migrating tests from a closed tonga based test suite to open regression based one.
> 
> Issue tested:
> When calling JEditorPane.setText(null), the following exception is thrown:
> 
> java.lang.NullPointerException:
>         at java.io.StringReader.<init>(StringReader.java:38)
> 
> Testing:
> Java 1.4.0 -> Test Failed.
> $ ./j2sdk1.4.0/bin/java bug4330998Win
> java.lang.RuntimeException: Test failed, caught Exception java.lang.NullPointerException when calling text.setText(null)
>         at bug4330998Win.runTest(bug4330998Win.java:45)
>         at bug4330998Win.main(bug4330998Win.java:51)
> Exception in thread "main"
> 
> Java 1.4.1 -> Test Passed.
> $ ./j2sdk1.4.1/bin/java bug4330998Win
> Test passed

@aivanov-jdk Can you please review this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7740


From mvs at openjdk.java.net  Tue Mar  8 10:59:24 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 8 Mar 2022 10:59:24 GMT
Subject: RFR: 8282789: Create a regression test for the JTree usecase of
 JDK-4618767
Message-ID: <8OsXQ_pAltihbq8L16yTW3IsYGF3nahH-Xa7fy7G3vI=.35818df7-7c9c-4acc-9b1c-63a03942914c@github.com>

Create a regression test for the JTree usecase of [JDK-4618767](https://bugs.openjdk.java.net/browse/JDK-4618767)
Context: Migrating tests from a closed tonga based test suite to open regression based one.

Issue identified in [JDK-4618767](https://bugs.openjdk.java.net/browse/JDK-4618767):
Typing a letter while a JTree has focus now makes the selection jump to the first/next node/item whose text starts with that letter even though that letter is accompanied by modifier keys such as ALT or CTRL.

Fix:
Only enable JTree letter navigation when the user doesn't press any modifier keys such as ALT or CTRL.

Testing:
Java 1.4.0 -> Test Failed.
$ ./j2sdk1.4.0/bin/java JTreeOld
LookAndFeel: javax.swing.plaf.metal.MetalLookAndFeel
OS = windows nt (unknown)
java.lang.RuntimeException: Test Failed, expected colors, but got food
        at JTreeOld.doTest(JTreeOld.java:166)
        at JTreeOld.main(JTreeOld.java:32)
Exception in thread "main"

Java 1.4.1 -> Test Passed.
$ ./j2sdk1.4.1/bin/java JTreeOld
LookAndFeel: javax.swing.plaf.metal.MetalLookAndFeel
OS = windows nt (unknown)
Test passed javax.swing.plaf.metal.MetalLookAndFeel
LookAndFeel: com.sun.java.swing.plaf.motif.MotifLookAndFeel
OS = windows nt (unknown)
Test passed com.sun.java.swing.plaf.motif.MotifLookAndFeel
LookAndFeel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
OS = windows nt (unknown)
Test passed com.sun.java.swing.plaf.windows.WindowsLookAndFeel

-------------

Commit messages:
 - 8282789: Create a regression test for the JTree usecase of JDK-4618767

Changes: https://git.openjdk.java.net/jdk/pull/7742/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7742&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282789
  Stats: 226 lines in 1 file changed: 226 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7742.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7742/head:pull/7742

PR: https://git.openjdk.java.net/jdk/pull/7742


From mvs at openjdk.java.net  Tue Mar  8 10:59:25 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 8 Mar 2022 10:59:25 GMT
Subject: RFR: 8282789: Create a regression test for the JTree usecase of
 JDK-4618767
In-Reply-To: <8OsXQ_pAltihbq8L16yTW3IsYGF3nahH-Xa7fy7G3vI=.35818df7-7c9c-4acc-9b1c-63a03942914c@github.com>
References: <8OsXQ_pAltihbq8L16yTW3IsYGF3nahH-Xa7fy7G3vI=.35818df7-7c9c-4acc-9b1c-63a03942914c@github.com>
Message-ID: <XEvOPma9DMaX9Oh2wTjLndiZqeT-zdmcVIum50w-REs=.c0a9bba7-67c3-4b50-9435-c562ced53819@github.com>

On Tue, 8 Mar 2022 10:52:44 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Create a regression test for the JTree usecase of [JDK-4618767](https://bugs.openjdk.java.net/browse/JDK-4618767)
> Context: Migrating tests from a closed tonga based test suite to open regression based one.
> 
> Issue identified in [JDK-4618767](https://bugs.openjdk.java.net/browse/JDK-4618767):
> Typing a letter while a JTree has focus now makes the selection jump to the first/next node/item whose text starts with that letter even though that letter is accompanied by modifier keys such as ALT or CTRL.
> 
> Fix:
> Only enable JTree letter navigation when the user doesn't press any modifier keys such as ALT or CTRL.
> 
> Testing:
> Java 1.4.0 -> Test Failed.
> $ ./j2sdk1.4.0/bin/java JTreeOld
> LookAndFeel: javax.swing.plaf.metal.MetalLookAndFeel
> OS = windows nt (unknown)
> java.lang.RuntimeException: Test Failed, expected colors, but got food
>         at JTreeOld.doTest(JTreeOld.java:166)
>         at JTreeOld.main(JTreeOld.java:32)
> Exception in thread "main"
> 
> Java 1.4.1 -> Test Passed.
> $ ./j2sdk1.4.1/bin/java JTreeOld
> LookAndFeel: javax.swing.plaf.metal.MetalLookAndFeel
> OS = windows nt (unknown)
> Test passed javax.swing.plaf.metal.MetalLookAndFeel
> LookAndFeel: com.sun.java.swing.plaf.motif.MotifLookAndFeel
> OS = windows nt (unknown)
> Test passed com.sun.java.swing.plaf.motif.MotifLookAndFeel
> LookAndFeel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> OS = windows nt (unknown)
> Test passed com.sun.java.swing.plaf.windows.WindowsLookAndFeel

@aivanov-jdk Can you please review this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7742


From dholmes at openjdk.java.net  Tue Mar  8 12:23:57 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Mar 2022 12:23:57 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig()
In-Reply-To: <vlXvB8DZMIq-ReuFB7SgtYI1OvADATcJ8tZdNu3pbTo=.6843b81b-de36-4970-80ae-43a761e865fe@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
 <vlXvB8DZMIq-ReuFB7SgtYI1OvADATcJ8tZdNu3pbTo=.6843b81b-de36-4970-80ae-43a761e865fe@github.com>
Message-ID: <VN40ZcD4H6uJr-mBKa98Dh5T6xG3giYR_5k8vgxYlUo=.e7735192-049f-4c74-b9f3-56bb5358de87@github.com>

On Tue, 8 Mar 2022 09:20:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs`
>> 
>> Test:
>> 
>> - [x] jdk_desktop on Linux x86_64
>
> src/java.desktop/unix/native/common/awt/fontpath.c line 940:
> 
>> 938:                 JNU_CHECK_EXCEPTION_AND_CLEANUP(env, (*FcStrListDone)(cacheDirs));
>> 939: 
>> 940:                 (*env)->SetObjectArrayElement(env, cacheDirArray, cnt++, jstr);
> 
> Probably we should add the check+cleanup after the SetObjectArrayElement? Otherwise, we may call NewStringUTF while an exception is raised by the SetObjectArrayElement.

??? You want to check and cleanup if NewStringUTF fails. You only want to call SetObjectElementArray if NewStringUTF succeeds.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7691


From dholmes at openjdk.java.net  Tue Mar  8 12:34:06 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Mar 2022 12:34:06 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig()
In-Reply-To: <vlXvB8DZMIq-ReuFB7SgtYI1OvADATcJ8tZdNu3pbTo=.6843b81b-de36-4970-80ae-43a761e865fe@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
 <vlXvB8DZMIq-ReuFB7SgtYI1OvADATcJ8tZdNu3pbTo=.6843b81b-de36-4970-80ae-43a761e865fe@github.com>
Message-ID: <GRmuWHFuzJ-AntpdyiUElqOPGPZnjK1CrUJ7ZTZ_Npg=.1c8e5a5f-0d57-486e-8444-be9094fb8be5@github.com>

On Tue, 8 Mar 2022 09:18:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs`
>> 
>> Test:
>> 
>> - [x] jdk_desktop on Linux x86_64
>
> src/java.desktop/unix/native/common/awt/fontpath.c line 938:
> 
>> 936:             while ((cnt < max) && (cacheDir = (*FcStrListNext)(cacheDirs))) {
>> 937:                 jstr = (*env)->NewStringUTF(env, (const char*)cacheDir);
>> 938:                 JNU_CHECK_EXCEPTION_AND_CLEANUP(env, (*FcStrListDone)(cacheDirs));
> 
> I think you do not need to create an additional macro here, just inline it and call "(*FcStrListDone)(cacheDirs);" directly. Something like:
> 
> if (IS_NULL(jstr) {
>     (*FcStrListDone)(cacheDirs);
>     return;
> }
> 
> Note that the "IS_NULL" is used in this file after NewStringUTF. Any objections?

Good catch! Elsewhere in this file IS_NULL is always used to check NewStringUTF, so the existing code was inconsistent in checking for a pending exception.

Checking for NULL and checking for a pending exception are logically equivalent as long as the passed in pointer is not NULL.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7691


From aivanov at openjdk.java.net  Tue Mar  8 13:40:57 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 8 Mar 2022 13:40:57 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig()
In-Reply-To: <VN40ZcD4H6uJr-mBKa98Dh5T6xG3giYR_5k8vgxYlUo=.e7735192-049f-4c74-b9f3-56bb5358de87@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
 <vlXvB8DZMIq-ReuFB7SgtYI1OvADATcJ8tZdNu3pbTo=.6843b81b-de36-4970-80ae-43a761e865fe@github.com>
 <VN40ZcD4H6uJr-mBKa98Dh5T6xG3giYR_5k8vgxYlUo=.e7735192-049f-4c74-b9f3-56bb5358de87@github.com>
Message-ID: <ovvJcgWIwvjUabakDYGicQy3hnAyivs_XVkdm1aWU2c=.26f59cd5-8ffe-4994-b98a-24868b2c7e74@github.com>

On Tue, 8 Mar 2022 12:20:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/java.desktop/unix/native/common/awt/fontpath.c line 940:
>> 
>>> 938:                 JNU_CHECK_EXCEPTION_AND_CLEANUP(env, (*FcStrListDone)(cacheDirs));
>>> 939: 
>>> 940:                 (*env)->SetObjectArrayElement(env, cacheDirArray, cnt++, jstr);
>> 
>> Probably we should add the check+cleanup after the SetObjectArrayElement? Otherwise, we may call NewStringUTF while an exception is raised by the SetObjectArrayElement.
>
> ??? You want to check and cleanup if NewStringUTF fails. You only want to call SetObjectElementArray if NewStringUTF succeeds.

Can `SetObjectElementArray` raise an exception?  
The index is within the array length and we store a string. I assume `cacheDirArray` is a string array.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7691


From duke at openjdk.java.net  Tue Mar  8 14:13:03 2022
From: duke at openjdk.java.net (duke)
Date: Tue, 8 Mar 2022 14:13:03 GMT
Subject: Withdrawn: 8278348: [macos12]
 javax/swing/JTree/4908142/bug4908142.java fails in macos12
In-Reply-To: <NIiUwv0S9Luwx-Cr3f59GSllTUVRsa96rRxonSLk0Sk=.6e3cd774-13fd-47ff-badf-0655a4d1ad99@github.com>
References: <NIiUwv0S9Luwx-Cr3f59GSllTUVRsa96rRxonSLk0Sk=.6e3cd774-13fd-47ff-badf-0655a4d1ad99@github.com>
Message-ID: <4VYiPKmYJ8HVgoUQZOe87fZD6tgW2GwMbUnA6uCZqNY=.7f411a1d-08de-4a17-8033-4fd027f199fc@github.com>

On Tue, 14 Dec 2021 05:44:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test seem to be failing in macos12.0.1 (although it does not seem to affect 12.1) due to keypresses of "a", "a", "d" is not selecting "aad" but "ade" which seems to point to the fact that 2 exclusive "a" keypress are considered as 1 "a" keypress.
> Although I am not able to reroduce this issue if test is ran standalone or in JTree group, but it fails when ran as toplevel "jdk_desktop" testgroup or even whole swing test group.
> 
> Looking at text navigational algorithm probably done in JDK-4908142 (although I am not sure if this is done for that bug or subsequently revised) 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3804
> 
> it seems if a subsequent key press comes after a predefined timefactor after the previous keypress, it is considered as a fresh/new keypress and not part of ongoing string search ie, if 2nd "a" comes after the predefined timefactor from 1st "a', then seacrh algorithm will search for "ad" and not "aad" as can be seen here
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3815
> 
> I am not sure why macos12 will take so long  for 2nd "a" keypress  but the logs corraborates that it does take more than "timefactor" time what is set now, which is 1000.
> 1st "a" keypress, we have time 1639400688049 lastTime 0 typedString a
> 2nd "a" keypress, we have time 1639400691150 lastTime 1639400688049 typedString a [which is diff of 3101]
> 
> So, proposed fix is to configure "Tree.timeFactor" to 5000 to workaround this macos12 issue. It pass when full desktop tests is run in macos12 and also test passes in all platforms.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6826


From zgu at openjdk.java.net  Tue Mar  8 15:38:06 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 8 Mar 2022 15:38:06 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig()
In-Reply-To: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
Message-ID: <aC-KiS1qmDtxCLuNiVKYldlMeV3EPlbyAg6ogiL5W88=.94a078f7-8ca1-4665-99c8-4a35469c0ec6@github.com>

On Fri, 4 Mar 2022 13:25:12 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs`
> 
> Test:
> 
> - [x] jdk_desktop on Linux x86_64

> 



> > The macros are used to hide the different syntax of c and c++ to avoid polluting code here, it seems to be a common pattern in client code.
> 
> That's to allow for general use by C or C++ source files. But you are only needing this in a C source file so you would only need the C variant of the calling syntax.



> > The macros are used to hide the different syntax of c and c++ to avoid polluting code here, it seems to be a common pattern in client code.
> 
> That's to allow for general use by C or C++ source files. But you are only needing this in a C source file so you would only need the C variant of the calling syntax.

I don't like the macros. I can argument all `JNU_CHECK_EXCEPTION(_RETURN)` macros are particular bad, because these patterns can easily result premature returns without proper cleanup. This bug is an evidence. But they exist for a long time, and I just follow the convention :-( I would prefer to eliminate them all, as inline code is not big at all.

I did a quick grep, there are a few suspicious spots, e.g. [https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L2711](url), I have yet take a close look.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7691


From zgu at openjdk.java.net  Tue Mar  8 15:54:45 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 8 Mar 2022 15:54:45 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig() [v2]
In-Reply-To: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
Message-ID: <ZRNakjIguZ98WIzHKjOaIZs6I-oM_u5atLQm8Q1EQc8=.126d61df-ef31-4be0-86ff-6e2d0b4ce201@github.com>

> Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs`
> 
> Test:
> 
> - [x] jdk_desktop on Linux x86_64

Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:

  mrserb and aivanov-jdk's comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7691/files
  - new: https://git.openjdk.java.net/jdk/pull/7691/files/0ff07ddd..c4a3ec87

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7691&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7691&range=00-01

  Stats: 23 lines in 2 files changed: 2 ins; 18 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7691.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7691/head:pull/7691

PR: https://git.openjdk.java.net/jdk/pull/7691


From aivanov at openjdk.java.net  Tue Mar  8 16:02:03 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 8 Mar 2022 16:02:03 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig() [v2]
In-Reply-To: <ZRNakjIguZ98WIzHKjOaIZs6I-oM_u5atLQm8Q1EQc8=.126d61df-ef31-4be0-86ff-6e2d0b4ce201@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
 <ZRNakjIguZ98WIzHKjOaIZs6I-oM_u5atLQm8Q1EQc8=.126d61df-ef31-4be0-86ff-6e2d0b4ce201@github.com>
Message-ID: <ruIi34MsCsfm9hz6exsKQuWyYUfSDk-xBxtiN9pcJdQ=.521ad6f4-c12f-414e-b778-f348c0450203@github.com>

On Tue, 8 Mar 2022 15:54:45 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs`
>> 
>> Test:
>> 
>> - [x] jdk_desktop on Linux x86_64
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mrserb and aivanov-jdk's comments

> I did a quick grep, there are a few suspicious spots, e.g. [https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L2711](url), I have yet take a close look.

It doesn't leak the icon handle here, it's assigned to the member of the object (probably `NULL`). Yet it's inconsistent: if an exception is expected from `CreateIconFromRaster` on the line above, why isn't it checked after `CreateIconFromRaster` is called on the following line?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7691


From aivanov at openjdk.java.net  Tue Mar  8 16:13:07 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 8 Mar 2022 16:13:07 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861
In-Reply-To: <Ng7zkIIZ2e0jXX0zOM8R8wneueIfSiJA8UJsP-KC3ho=.bc5efc47-cc81-4fb1-a60e-4e9b2f012690@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <B2CHu-TrteeGoFk5ciTK_-Pvdwop-Vfwp3vmWh-kQUU=.d1a2d5b3-6150-4a95-8da6-0a5aa58c3e69@github.com>
 <OU17BKK48iYH-RHO3JKDGNtevs1v0eV0nElDAqNTh4Y=.685cd66b-965d-4a57-9129-a2ec5364f15e@github.com>
 <Ng7zkIIZ2e0jXX0zOM8R8wneueIfSiJA8UJsP-KC3ho=.bc5efc47-cc81-4fb1-a60e-4e9b2f012690@github.com>
Message-ID: <AyI2GAFstNxlfVoXNkHoWEPbc1lVQbkvlX97OzUIQlA=.efc49c30-641a-4556-b0a2-d37806ff847e@github.com>

On Thu, 24 Feb 2022 22:04:19 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> I submitted a job for testing the changes.
>> 
>> Thanks a lot!
>
>> > I submitted a job for testing the changes.
>> 
>> Thanks a lot!
> 
> I got 1 failure out of 15 on Linux for `java/awt/Robot/HiDPIScreenCapture/HiDPIRobotScreenCaptureTest.java`. The screenshot of the entire screen has no open windows: just plain desktop background. It was probably captured after the test was shutdown.
> 
> The test doesn't save the captured image on failure, does it?
> 
> It's crucial to save the captured images, otherwise we're blind and left to guess what Robot captured and why it didn't match.

> @aivanov-jdk Could you please re-run the test? Thanks once more!

Sorry for my delayed reply.

One failure reported:

command: main -Dsun.java2d.win.uiScaleX=3 -Dsun.java2d.win.uiScaleY=2 HiDPIRobotScreenCaptureTest
...
----------System.out:(3/218)----------
Creating screen capture of java.awt.Rectangle[x=83,y=97,width=400,height=300]
Checking (100, 75) to have color java.awt.Color[r=0,g=255,b=0]
... Mismatch: found java.awt.Color[r=135,g=8,b=69] instead. Check image.png.
----------System.err:(12/723)----------
java.lang.RuntimeException: Wrong image color!
	at HiDPIRobotScreenCaptureTest.checkRectColor(HiDPIRobotScreenCaptureTest.java:125)
	at HiDPIRobotScreenCaptureTest.main(HiDPIRobotScreenCaptureTest.java:108)
...

![The captured image.png](https://user-images.githubusercontent.com/70774172/157277072-febab0d6-bef3-43df-a98f-8b6b6eea60ff.png)

The checked point (x, y) = (100, 75) is 10 pixels into the green square but it's 55 pixels above the square.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From mvs at openjdk.java.net  Tue Mar  8 17:04:07 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 8 Mar 2022 17:04:07 GMT
Subject: Integrated: 8282234: Create a regression test for JDK-4532513
In-Reply-To: <h3ZoydrpxAklsdt3qahYdowBNEwAh4lZo96oGx2EEVc=.e076785d-c06f-43af-a3b9-d76390ea1f33@github.com>
References: <h3ZoydrpxAklsdt3qahYdowBNEwAh4lZo96oGx2EEVc=.e076785d-c06f-43af-a3b9-d76390ea1f33@github.com>
Message-ID: <J-zPn3AA-jdCq7_-QAX4xLx5ACez9aTAOc5Jwvs73zg=.abd20e07-15a8-4f6a-98b5-428ca758168e@github.com>

On Tue, 22 Feb 2022 15:47:20 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Create a regression test for [JDK-4532513](https://bugs.openjdk.java.net/browse/JDK-4532513).
> This test verifies that the DefaultCaret doesn't requests focus in mouseClick and mousePressed causing the associated input verifier to fire twice.
> As per [JDK-4532513](https://bugs.openjdk.java.net/browse/JDK-4532513), the DefaultCaret requests focus in mouseClick and mousePressed causing the associated input verifier to fire twice.
> This issue was raised in JDK 1.4.0 and fixed in 1.4.1, so the test need to be failed in 1.4.0 and must pass in 1.4.1.
> 
> Testing:
> 
> In JDK 1.4.0:
> $ ./j2sdk1.4.0/bin/java DefaultCaretWin
> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
> shouldYieldFocus called 1
> shouldYieldFocus called 2
> shouldYieldFocus called 3
> java.lang.RuntimeException: Test failed for javax.swing.plaf.metal.MetalLookAndFeel as InputVerifier.shouldYieldFocus() getting called 3 times on jTextField2, but it is expected to call only once.
>         at DefaultCaretWin.runTest(DefaultCaretWin.java:114)
>         at DefaultCaretWin.main(DefaultCaretWin.java:58)
> 
> In JDK 1.4.1:
> $ ./j2sdk1.4.1/bin/java DefaultCaretWin
> Testing L&F: javax.swing.plaf.metal.MetalLookAndFeel
> shouldYieldFocus called 1
> Test passed for laf: javax.swing.plaf.metal.MetalLookAndFeel
> Testing L&F: com.sun.java.swing.plaf.motif.MotifLookAndFeel
> shouldYieldFocus called 1
> Test passed for laf: com.sun.java.swing.plaf.motif.MotifLookAndFeel
> Testing L&F: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> shouldYieldFocus called 1
> Test passed for laf: com.sun.java.swing.plaf.windows.WindowsLookAndFeel

This pull request has now been integrated.

Changeset: 6b34884b
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6b34884b34c4d84a1b5cfa3556a188415a42b1de
Stats:     193 lines in 1 file changed: 193 ins; 0 del; 0 mod

8282234: Create a regression test for JDK-4532513

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/7577


From aivanov at openjdk.java.net  Tue Mar  8 17:27:06 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 8 Mar 2022 17:27:06 GMT
Subject: RFR: 8277922: Unable to click JCheckBox in JTable through Java
 Access Bridge [v2]
In-Reply-To: <eKlfsWF1ulDc1qhcbD5xf2_6sOmc3RIb6FPfeZ89A5E=.0669d318-101a-428d-b824-198dc7da7c6e@github.com>
References: <68JPxsadS5K_WkQgEkMdD_qCt1DWBpBVHV23b0oQKGU=.0b4e520a-205d-4cf1-b506-dd48616ebece@github.com>
 <wjeNqAqGo2_dqjjH4nzP7TwmM40y8wLvTXpJNWcO4fc=.27160ded-58f9-4486-9613-67af7869a2c0@github.com>
 <eKlfsWF1ulDc1qhcbD5xf2_6sOmc3RIb6FPfeZ89A5E=.0669d318-101a-428d-b824-198dc7da7c6e@github.com>
Message-ID: <jMSLsRdtlovITvX8or9Pk_aNIqv4CupYeYa40iH9OnM=.54347b3c-0f6e-4e6a-932c-8320b7a6e7e2@github.com>

On Sat, 12 Feb 2022 00:52:26 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JTable.java line 5493:
>> 
>>> 5491:         }
>>> 5492: 
>>> 5493:         protected class AccessibleBooleanRenderer
>> 
>> I guess the doAccessibleAction(i); should work in a similar way as something like "table,getCellJComponent()".click(). Is it actually possible to click on the cell w/o using robot and w/o a11y API just via Swing API and w/o adding code for each type of the renderer?
>
> I do not see the method "getCellJComponent" in JTable or anything like this, but what I see in the code is, yes, call to the method "doAccessibleAction(0)" of accessible action of accessible context of "JCheckBox" just calls "doClick()" method of "JCheckBox". Yes, sure, "doClick()" is the public method of any "javax.swing.AbstractButton" and can be called from anywhere having a reference to the instance of "javax.swing.AbstractButton".
> 
> In the fix I added code to this particular renderer "JTable.BooleanRenderer" in order to be able to intercept every invocation of "boolean doAccessibleAction(int i)" method of its default "AccessibleAction" implementation which is "JCheckBox.AccessibleJCheckBox" and to be able to change a boolean value of a cell in "JTable".
> 
> I am not going to add any similar code to other types of default table cell renderers, because first of all there are not many of them: "DefaultTableCellRenderer.UIResource", "NumberRenderer", "DoubleRenderer", "DateRenderer", "IconRenderer", "BooleanRenderer", they are used in the method "JTable.createDefaultRenderers()", and all of these renderers except for "BooleanRenderer" are derivatives of "JLabel" component which reports 0 supported accessible actions, so any default renderer except of "BooleanRenderer" does not support any accessible action. And the problem is that "BooleanRenderer" is derivative of "JCheckBox" and therefore it reports to the user through Java Access Bridge API, through Java Accessibility API that it supports 1 action called "click".

> Is it actually possible to click on the cell w/o using robot and w/o a11y API just via Swing API and w/o adding code for each type of the renderer?

No, it's not possible because there's no real component in each cell. The table draws the checkbox using `TableCellRenderer`, by default it's `BooleanRenderer` which extends `JCheckBox`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7416


From aivanov at openjdk.java.net  Tue Mar  8 17:27:07 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 8 Mar 2022 17:27:07 GMT
Subject: RFR: 8277922: Unable to click JCheckBox in JTable through Java
 Access Bridge [v2]
In-Reply-To: <8R69aU6gXH3ibU7vnlvoMipS8kMceB29ZCJqrKDhwHs=.c8729782-eaf7-4290-9d30-e8cbce8913e9@github.com>
References: <68JPxsadS5K_WkQgEkMdD_qCt1DWBpBVHV23b0oQKGU=.0b4e520a-205d-4cf1-b506-dd48616ebece@github.com>
 <wjeNqAqGo2_dqjjH4nzP7TwmM40y8wLvTXpJNWcO4fc=.27160ded-58f9-4486-9613-67af7869a2c0@github.com>
 <eKlfsWF1ulDc1qhcbD5xf2_6sOmc3RIb6FPfeZ89A5E=.0669d318-101a-428d-b824-198dc7da7c6e@github.com>
 <6RUw9T57vpFeVswFzk736HUDXblDL4wvZdh3ssYnoR4=.3c486241-e422-4e38-9baf-ba7abfaedf2b@github.com>
 <8R69aU6gXH3ibU7vnlvoMipS8kMceB29ZCJqrKDhwHs=.c8729782-eaf7-4290-9d30-e8cbce8913e9@github.com>
Message-ID: <cVXvV5WY5C8GiHJno-iSCTEtZDRHK0P1oPCA83Rmb5g=.0774fe8c-a2e2-4780-9651-15e3af186a9f@github.com>

On Thu, 24 Feb 2022 12:02:00 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

>>> The reason of the issue is the fact that when the assistive technology software tries to do "AccessibleAction" on "AccessibleContext" associated with a cell with boolean data type in "JTable" component through Java Access Bridge (JAB), the JDK executes this "AccessibleAction" on "AccessibleContext" of a renderer, which is an instance of the class "javax.swing.JTable.BooleanRenderer" which is a derivative of "JCheckBox" class, and the instance of this renderer is single and common for all cells of boolean data type. Therefore execution of "click" "AccessibleAction" on this renderer component which is not permanently bound to any particular cell in the table does not lead to update of the table cell value.
>> 
>> But how do the real mouse clicks trigger selection/deselection of the checkbox state, I guess that the "table.setValueAt()" should be called somewhere, can we do something similar from the "doAccessibleAction()"?
>
> Hi Sergey. When real mouse click happens "MOUSE_PRESSED", "MOUSE_RELEASED" AWT events are generated and properly handled by code in "JTable" and in other related to "JTable" classes, for example "javax.swing.plaf.basic.BasicTableUI". In the process of handling "JTable" switches to the editing mode and starts considering that at this moment the mouse events are related to not "BooleanRenderer" but to the editor component "BooleanEditor". All these focus/selection/deselection happens during processing of the "MOUSE_PRESSED" event in the methods:
> - "javax.swing.plaf.basic.BasicTableUI.Handler.mousePressed(MouseEvent e)"
> - "javax.swing.plaf.basic.BasicTableUI.Handler.adjustSelection(MouseEvent e)"
> - "javax.swing.JTable.editCellAt(int row, int column, EventObject e)"
> - "javax.swing.JTable.changeSelection(int rowIndex, int columnIndex, boolean toggle, boolean extend)"
> 
> So real mouse click is not a simple call of some one generic click method, which does everything.
> 
> My position is that "selection/deselection" should not happen as a result of "doAccessibleAction(int)" on "AccessibleAction" of "BooleanRenderer". "selection/deselection" must also include setting of focus to the edited cell. Regarding focus I repeat what I said in my prior comment above:
> 
>> I checked the behavior of "doAccessibleAction" on JCheckBox, JButton located outside JTable and I confirm that it does not lead to setting of focus to these components, hence there is no need to set focus to this "JCheckBox" "BooleanRenderer" when it is in table cell and no need to change selection in JTable.
> 
> I do not see the need in imitating calls to the methods of "BasicTableUI.Handler", "JTable", which are listed upper and involved in real mouse clicks, in handling of "doAccessibleAction". To my mind execution of accessible action "click" in any "JToggleButton" including "JCheckBox" IS NOT EQUAL to real mouse click on them and therefore there is no need to aim to make "doAccessibleAction" on "BooleanRenderer" to be equal to real mouse click on it.

I agree we shouldn't try to repeat the same actions that are caused by mouse click. It aligns with the behaviour of a stand-alone checkbox.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7416


From zgu at openjdk.java.net  Tue Mar  8 17:52:04 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 8 Mar 2022 17:52:04 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig() [v2]
In-Reply-To: <ruIi34MsCsfm9hz6exsKQuWyYUfSDk-xBxtiN9pcJdQ=.521ad6f4-c12f-414e-b778-f348c0450203@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
 <ZRNakjIguZ98WIzHKjOaIZs6I-oM_u5atLQm8Q1EQc8=.126d61df-ef31-4be0-86ff-6e2d0b4ce201@github.com>
 <ruIi34MsCsfm9hz6exsKQuWyYUfSDk-xBxtiN9pcJdQ=.521ad6f4-c12f-414e-b778-f348c0450203@github.com>
Message-ID: <P8QXBx6GNVLiMaELiYVVp-rxHFWs7RGoz-J7jRVEzz4=.3c900a4a-c4e5-4fe0-9dfe-6a9de4091eda@github.com>

On Tue, 8 Mar 2022 15:58:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > I did a quick grep, there are a few suspicious spots, e.g. [https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L2711](url), I have yet take a close look.
> 
> It doesn't leak the icon handle here, it's assigned to the member of the object (probably `NULL`). Yet it's inconsistent: if an exception is expected from `CreateIconFromRaster` on the line above, why isn't it checked after `CreateIconFromRaster` is called on the following line?

I am not familiar with this code. What I see is that, it assigns `m_hIcon` and `m_hIconSm` to local variables, then reset them to `NULL`, once exception returns, are references to icon and small icon handles lost? and it will destroy icons as L2727 - 2732 do. But I may miss something.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7691


From duke at openjdk.java.net  Tue Mar  8 18:26:59 2022
From: duke at openjdk.java.net (Rajat Mahajan)
Date: Tue, 8 Mar 2022 18:26:59 GMT
Subject: RFR: 8249592 : Robot.mouseMove moves cursor to incorrect location
 when display scale varies and Java runs in DPI Unaware mode [v3]
In-Reply-To: <7SyMjVox8LbT2ZqI1n0fj8nwb3YsCXfrap6VuGtNVbc=.e8c0bd94-c477-4a69-839f-25e7b3d31f7d@github.com>
References: <7SyMjVox8LbT2ZqI1n0fj8nwb3YsCXfrap6VuGtNVbc=.e8c0bd94-c477-4a69-839f-25e7b3d31f7d@github.com>
Message-ID: <UfxwyMHWRsrNOZUoU_l8Bv9SMm8GtyfI5i7Dk4JZCuo=.000fc764-7d45-4ca2-80a4-1ea3b014040b@github.com>

> 8249592 : Robot.mouseMove moves cursor to incorrect location when display scale varies and Java runs in DPI Unaware mode

Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:

  limit code to 80 characters per line

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7736/files
  - new: https://git.openjdk.java.net/jdk/pull/7736/files/52700714..0c6c5217

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7736&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7736&range=01-02

  Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7736.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7736/head:pull/7736

PR: https://git.openjdk.java.net/jdk/pull/7736


From duke at openjdk.java.net  Tue Mar  8 18:32:00 2022
From: duke at openjdk.java.net (Rajat Mahajan)
Date: Tue, 8 Mar 2022 18:32:00 GMT
Subject: RFR: 8249592 : Robot.mouseMove moves cursor to incorrect location
 when display scale varies and Java runs in DPI Unaware mode [v2]
In-Reply-To: <BG1Al6mxI40fhN5LWWVoCrP1MkYzPOx6dohEIooBN8E=.0da9d2e1-c20f-40e2-9048-e63e00d46929@github.com>
References: <7SyMjVox8LbT2ZqI1n0fj8nwb3YsCXfrap6VuGtNVbc=.e8c0bd94-c477-4a69-839f-25e7b3d31f7d@github.com>
 <3coBtonKSRsFrz2LQekjlGWXtP9RG18NZMzwbUirB9o=.17df2580-16bd-49bf-93c1-472c20d173a8@github.com>
 <BG1Al6mxI40fhN5LWWVoCrP1MkYzPOx6dohEIooBN8E=.0da9d2e1-c20f-40e2-9048-e63e00d46929@github.com>
Message-ID: <O-VKiQiNlUj3DthS_IHtDO3oojk5HZYtNSJhg9uBabQ=.e55ca33e-7ddb-4f0d-bea0-2f0ae4e51c71@github.com>

On Tue, 8 Mar 2022 03:51:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed stdlib.h, not needed
>
> src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp line 53:
> 
>> 51: 
>> 52:     ::SendInput(1, &mouseInput, sizeof(mouseInput));
>> 53: 
> 
> This change looks fine, the only suggestion I have is to split the long lines and use the 80 chars per line.
> 
> Please also confirm that mach5 is green.

Mach5 passed all testing with the change. Fixed limit to 80 chars/ line.
thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/7736


From serb at openjdk.java.net  Tue Mar  8 20:16:04 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 8 Mar 2022 20:16:04 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig() [v2]
In-Reply-To: <ovvJcgWIwvjUabakDYGicQy3hnAyivs_XVkdm1aWU2c=.26f59cd5-8ffe-4994-b98a-24868b2c7e74@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
 <vlXvB8DZMIq-ReuFB7SgtYI1OvADATcJ8tZdNu3pbTo=.6843b81b-de36-4970-80ae-43a761e865fe@github.com>
 <VN40ZcD4H6uJr-mBKa98Dh5T6xG3giYR_5k8vgxYlUo=.e7735192-049f-4c74-b9f3-56bb5358de87@github.com>
 <ovvJcgWIwvjUabakDYGicQy3hnAyivs_XVkdm1aWU2c=.26f59cd5-8ffe-4994-b98a-24868b2c7e74@github.com>
Message-ID: <P1vFX2im3GdZBVfjvk2W2A340nu1DAayEQsAkk8YEMI=.edd6c37a-4571-4ec3-8904-ddff55ff2347@github.com>

On Tue, 8 Mar 2022 13:37:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> ??? You want to check and cleanup if NewStringUTF fails. You only want to call SetObjectElementArray if NewStringUTF succeeds.
>
> Can `SetObjectElementArray` raise an exception?  
> The index is within the array length and we store a string. I assume `cacheDirArray` is a string array.

> ??? You want to check and cleanup if NewStringUTF fails. You only want to call SetObjectElementArray if NewStringUTF succeeds.

If the SetObjectArrayElement will throw an exception we will call the NewStringUTF while the exception is raised which is a kind of "jni" issue. If such an exception is possible we should check and cleanup.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7691


From aivanov at openjdk.java.net  Tue Mar  8 20:51:07 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 8 Mar 2022 20:51:07 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig() [v2]
In-Reply-To: <ZRNakjIguZ98WIzHKjOaIZs6I-oM_u5atLQm8Q1EQc8=.126d61df-ef31-4be0-86ff-6e2d0b4ce201@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
 <ZRNakjIguZ98WIzHKjOaIZs6I-oM_u5atLQm8Q1EQc8=.126d61df-ef31-4be0-86ff-6e2d0b4ce201@github.com>
Message-ID: <C7zON_MwM69D6PxMGQAvVJwwczdn_RgzwNDM58sS8bY=.258b933b-abf6-4600-9ca5-b5eefaef9b22@github.com>

On Tue, 8 Mar 2022 15:54:45 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs`
>> 
>> Test:
>> 
>> - [x] jdk_desktop on Linux x86_64
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mrserb and aivanov-jdk's comments

> > > I did a quick grep, there are a few suspicious spots, e.g. https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L2711, I have yet take a close look.
> > 
> > 
> > It doesn't leak the icon handle here, it's assigned to the member of the object (probably `NULL`). Yet it's inconsistent: if an exception is expected from `CreateIconFromRaster` on the line above, why isn't it checked after `CreateIconFromRaster` is called on the following line?
> 
> I am not familiar with this code. What I see is that, it assigns `m_hIcon` and `m_hIconSm` to local variables, then reset them to `NULL`, once exception returns, are references to icon and small icon handles lost? and it will destroy icons as L2727 - 2732 do. But I may miss something.

You're right. The old icon handles in `hOldIcon` and `hOldIconSm` will be leaked here if `CreateIconFromRaster` throws an exception.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7691


From aivanov at openjdk.java.net  Tue Mar  8 21:01:10 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 8 Mar 2022 21:01:10 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig() [v2]
In-Reply-To: <P1vFX2im3GdZBVfjvk2W2A340nu1DAayEQsAkk8YEMI=.edd6c37a-4571-4ec3-8904-ddff55ff2347@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
 <vlXvB8DZMIq-ReuFB7SgtYI1OvADATcJ8tZdNu3pbTo=.6843b81b-de36-4970-80ae-43a761e865fe@github.com>
 <VN40ZcD4H6uJr-mBKa98Dh5T6xG3giYR_5k8vgxYlUo=.e7735192-049f-4c74-b9f3-56bb5358de87@github.com>
 <ovvJcgWIwvjUabakDYGicQy3hnAyivs_XVkdm1aWU2c=.26f59cd5-8ffe-4994-b98a-24868b2c7e74@github.com>
 <P1vFX2im3GdZBVfjvk2W2A340nu1DAayEQsAkk8YEMI=.edd6c37a-4571-4ec3-8904-ddff55ff2347@github.com>
Message-ID: <MwRLN7fDsNNMeLRGr7h7oSAX2vN-eSESJiiI_vwwxpY=.d6dde22d-2d98-4ca0-abc8-dd02c6da7ebd@github.com>

On Tue, 8 Mar 2022 20:12:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Can `SetObjectElementArray` raise an exception?  
>> The index is within the array length and we store a string. I assume `cacheDirArray` is a string array.
>
>> ??? You want to check and cleanup if NewStringUTF fails. You only want to call SetObjectElementArray if NewStringUTF succeeds.
> 
> If the SetObjectArrayElement will throw an exception we will call the NewStringUTF while the exception is raised which is a kind of "jni" issue. If such an exception is possible we should check and cleanup.

A quick search for `SetObjectArrayElement` in `java.desktop` module shows the call to `SetObjectArrayElement` is rarely followed by exception check.

What kind of exception can `SetObjectArrayElement` raise if the index is within the range and the stored element is of correct type?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7691


From zgu at openjdk.java.net  Tue Mar  8 21:05:09 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 8 Mar 2022 21:05:09 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig() [v2]
In-Reply-To: <MwRLN7fDsNNMeLRGr7h7oSAX2vN-eSESJiiI_vwwxpY=.d6dde22d-2d98-4ca0-abc8-dd02c6da7ebd@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
 <vlXvB8DZMIq-ReuFB7SgtYI1OvADATcJ8tZdNu3pbTo=.6843b81b-de36-4970-80ae-43a761e865fe@github.com>
 <VN40ZcD4H6uJr-mBKa98Dh5T6xG3giYR_5k8vgxYlUo=.e7735192-049f-4c74-b9f3-56bb5358de87@github.com>
 <ovvJcgWIwvjUabakDYGicQy3hnAyivs_XVkdm1aWU2c=.26f59cd5-8ffe-4994-b98a-24868b2c7e74@github.com>
 <P1vFX2im3GdZBVfjvk2W2A340nu1DAayEQsAkk8YEMI=.edd6c37a-4571-4ec3-8904-ddff55ff2347@github.com>
 <MwRLN7fDsNNMeLRGr7h7oSAX2vN-eSESJiiI_vwwxpY=.d6dde22d-2d98-4ca0-abc8-dd02c6da7ebd@github.com>
Message-ID: <lLWAmaDMBQyaSzyHCeIr2CLXwG1QywzU_BEv0MKeEGY=.517f5679-8525-4180-9852-8f9d3efb94d4@github.com>

On Tue, 8 Mar 2022 20:57:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> ??? You want to check and cleanup if NewStringUTF fails. You only want to call SetObjectElementArray if NewStringUTF succeeds.
>> 
>> If the SetObjectArrayElement will throw an exception we will call the NewStringUTF while the exception is raised which is a kind of "jni" issue. If such an exception is possible we should check and cleanup.
>
> A quick search for `SetObjectArrayElement` in `java.desktop` module shows the call to `SetObjectArrayElement` is rarely followed by exception check.
> 
> What kind of exception can `SetObjectArrayElement` raise if the index is within the range and the stored element is of correct type?

I think `NewStringUTF()` can throw OOM and also return `NULL`, just which one you pick.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7691


From aivanov at openjdk.java.net  Tue Mar  8 21:08:06 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 8 Mar 2022 21:08:06 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig() [v2]
In-Reply-To: <lLWAmaDMBQyaSzyHCeIr2CLXwG1QywzU_BEv0MKeEGY=.517f5679-8525-4180-9852-8f9d3efb94d4@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
 <vlXvB8DZMIq-ReuFB7SgtYI1OvADATcJ8tZdNu3pbTo=.6843b81b-de36-4970-80ae-43a761e865fe@github.com>
 <VN40ZcD4H6uJr-mBKa98Dh5T6xG3giYR_5k8vgxYlUo=.e7735192-049f-4c74-b9f3-56bb5358de87@github.com>
 <ovvJcgWIwvjUabakDYGicQy3hnAyivs_XVkdm1aWU2c=.26f59cd5-8ffe-4994-b98a-24868b2c7e74@github.com>
 <P1vFX2im3GdZBVfjvk2W2A340nu1DAayEQsAkk8YEMI=.edd6c37a-4571-4ec3-8904-ddff55ff2347@github.com>
 <MwRLN7fDsNNMeLRGr7h7oSAX2vN-eSESJiiI_vwwxpY=.d6dde22d-2d98-4ca0-abc8-dd02c6da7ebd@github.com>
 <lLWAmaDMBQyaSzyHCeIr2CLXwG1QywzU_BEv0MKeEGY=.517f5679-8525-4180-9852-8f9d3efb94d4@github.com>
Message-ID: <K_sM2PDY8Y5pdwJbobnUoks3yNWWxVD73AmegpHQSgk=.73c202b2-a38c-4be1-8f29-b94aa1dc1a23@github.com>

On Tue, 8 Mar 2022 21:02:04 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> I think `NewStringUTF()` can throw OOM and also return `NULL`, just which one you pick.

Yes.

But we're discussing whether a check for exception is necessary after `(*env)->SetObjectArrayElement`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7691


From zgu at openjdk.java.net  Tue Mar  8 21:18:07 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 8 Mar 2022 21:18:07 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig() [v2]
In-Reply-To: <K_sM2PDY8Y5pdwJbobnUoks3yNWWxVD73AmegpHQSgk=.73c202b2-a38c-4be1-8f29-b94aa1dc1a23@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
 <vlXvB8DZMIq-ReuFB7SgtYI1OvADATcJ8tZdNu3pbTo=.6843b81b-de36-4970-80ae-43a761e865fe@github.com>
 <VN40ZcD4H6uJr-mBKa98Dh5T6xG3giYR_5k8vgxYlUo=.e7735192-049f-4c74-b9f3-56bb5358de87@github.com>
 <ovvJcgWIwvjUabakDYGicQy3hnAyivs_XVkdm1aWU2c=.26f59cd5-8ffe-4994-b98a-24868b2c7e74@github.com>
 <P1vFX2im3GdZBVfjvk2W2A340nu1DAayEQsAkk8YEMI=.edd6c37a-4571-4ec3-8904-ddff55ff2347@github.com>
 <MwRLN7fDsNNMeLRGr7h7oSAX2vN-eSESJiiI_vwwxpY=.d6dde22d-2d98-4ca0-abc8-dd02c6da7ebd@github.com>
 <lLWAmaDMBQyaSzyHCeIr2CLXwG1QywzU_BEv0MKeEGY=.517f5679-8525-4180-9852-8f9d3efb94d4@github.com>
 <K_sM2PDY8Y5pdwJbobnUoks3yNWWxVD73AmegpHQSgk=.73c202b2-a38c-4be1-8f29-b94aa1dc1a23@github.com>
Message-ID: <LYOdTV_DUsdIXHaqxBsh-sq8EkO2fUtxGkAxK27zWf4=.8eec652d-7d35-4563-b0d8-862bc1ec4373@github.com>

On Tue, 8 Mar 2022 21:05:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I think `NewStringUTF()` can throw OOM and also return `NULL`, just which one you pick.
>
>> I think `NewStringUTF()` can throw OOM and also return `NULL`, just which one you pick.
> 
> Yes.
> 
> But we're discussing whether a check for exception is necessary after `(*env)->SetObjectArrayElement`.

`SetObjectArrayElement()` may throw `ArrayIndexOutOfBoundsException` and `ArrayStoreException`, but I don't see it is possible here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7691


From aivanov at openjdk.java.net  Tue Mar  8 21:18:07 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 8 Mar 2022 21:18:07 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig() [v2]
In-Reply-To: <LYOdTV_DUsdIXHaqxBsh-sq8EkO2fUtxGkAxK27zWf4=.8eec652d-7d35-4563-b0d8-862bc1ec4373@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
 <vlXvB8DZMIq-ReuFB7SgtYI1OvADATcJ8tZdNu3pbTo=.6843b81b-de36-4970-80ae-43a761e865fe@github.com>
 <VN40ZcD4H6uJr-mBKa98Dh5T6xG3giYR_5k8vgxYlUo=.e7735192-049f-4c74-b9f3-56bb5358de87@github.com>
 <ovvJcgWIwvjUabakDYGicQy3hnAyivs_XVkdm1aWU2c=.26f59cd5-8ffe-4994-b98a-24868b2c7e74@github.com>
 <P1vFX2im3GdZBVfjvk2W2A340nu1DAayEQsAkk8YEMI=.edd6c37a-4571-4ec3-8904-ddff55ff2347@github.com>
 <MwRLN7fDsNNMeLRGr7h7oSAX2vN-eSESJiiI_vwwxpY=.d6dde22d-2d98-4ca0-abc8-dd02c6da7ebd@github.com>
 <lLWAmaDMBQyaSzyHCeIr2CLXwG1QywzU_BEv0MKeEGY=.517f5679-8525-4180-9852-8f9d3efb94d4@github.com>
 <K_sM2PDY8Y5pdwJbobnUoks3yNWWxVD73AmegpHQSgk=.73c202b2-a38c-4be1-8f29-b94aa1dc1a23@github.com>
 <LYOdTV_DUsdIXHaqxBsh-sq8EkO2fUtxGkAxK27zWf4=.8eec652d-7d35-4563-b0d8-862bc1ec4373@github.com>
Message-ID: <FI1b86b9IZi-syedyizirGyjbGERz7Ov1xBuWUdxrmo=.aab0798b-3905-478d-908e-9e22d710061d@github.com>

On Tue, 8 Mar 2022 21:12:33 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>>> I think `NewStringUTF()` can throw OOM and also return `NULL`, just which one you pick.
>> 
>> Yes.
>> 
>> But we're discussing whether a check for exception is necessary after `(*env)->SetObjectArrayElement`.
>
> `SetObjectArrayElement()` may throw `ArrayIndexOutOfBoundsException` and `ArrayStoreException`, but I don't see it is possible here.

That's exactly my point. Therefore the check for exception after `SetObjectArrayElement` is unnecessary.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7691


From serb at openjdk.java.net  Wed Mar  9 01:57:06 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 9 Mar 2022 01:57:06 GMT
Subject: RFR: 8249592 : Robot.mouseMove moves cursor to incorrect location
 when display scale varies and Java runs in DPI Unaware mode [v3]
In-Reply-To: <UfxwyMHWRsrNOZUoU_l8Bv9SMm8GtyfI5i7Dk4JZCuo=.000fc764-7d45-4ca2-80a4-1ea3b014040b@github.com>
References: <7SyMjVox8LbT2ZqI1n0fj8nwb3YsCXfrap6VuGtNVbc=.e8c0bd94-c477-4a69-839f-25e7b3d31f7d@github.com>
 <UfxwyMHWRsrNOZUoU_l8Bv9SMm8GtyfI5i7Dk4JZCuo=.000fc764-7d45-4ca2-80a4-1ea3b014040b@github.com>
Message-ID: <75SiHnV4Y5Gxt5Eo5kKnTt8qfqrEjz-q5Z9og-zViG0=.ad2ab67a-b23f-4fcc-a115-39da01776ec8@github.com>

On Tue, 8 Mar 2022 18:26:59 GMT, Rajat Mahajan <duke at openjdk.java.net> wrote:

>> 8249592 : Robot.mouseMove moves cursor to incorrect location when display scale varies and Java runs in DPI Unaware mode
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   limit code to 80 characters per line

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7736


From stuefe at openjdk.java.net  Wed Mar  9 06:57:01 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 9 Mar 2022 06:57:01 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig() [v2]
In-Reply-To: <ZRNakjIguZ98WIzHKjOaIZs6I-oM_u5atLQm8Q1EQc8=.126d61df-ef31-4be0-86ff-6e2d0b4ce201@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
 <ZRNakjIguZ98WIzHKjOaIZs6I-oM_u5atLQm8Q1EQc8=.126d61df-ef31-4be0-86ff-6e2d0b4ce201@github.com>
Message-ID: <-S80LKyRxiTf3Cpc22n2rjAz9wJFGlM795arBKTmlcw=.d22e7b11-6b30-4f35-8b6b-03bd190946df@github.com>

On Tue, 8 Mar 2022 15:54:45 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs`
>> 
>> Test:
>> 
>> - [x] jdk_desktop on Linux x86_64
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mrserb and aivanov-jdk's comments

Still looks good to me.

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7691


From duke at openjdk.java.net  Wed Mar  9 07:04:59 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Wed, 9 Mar 2022 07:04:59 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v2]
In-Reply-To: <oTP9s3hH1t5pNZz3PA-VvGs07r7KcBory6QosyVesRA=.cf4b7478-116d-4a28-88da-5dd7c91e0bbe@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <6sowygRcdclz1LCYIHZSWMKV2LhuPo0D_EaYC_JIq0c=.b25c1f95-2510-4372-a8e4-99178d1762ce@github.com>
 <9TbYruwfo7JM4xbW6Mwj_WAAXdbrZR3O62Cc6xgt2TI=.74af7b62-adef-4b98-b195-4f9d47d5098d@github.com>
 <e2kuv7ZIhCBFVsdOaBTQLsvEah30BhTsk721cke6nsc=.a16cdabb-7566-418d-b89e-de43b9573290@github.com>
 <oTP9s3hH1t5pNZz3PA-VvGs07r7KcBory6QosyVesRA=.cf4b7478-116d-4a28-88da-5dd7c91e0bbe@github.com>
Message-ID: <r1RvzuRuDC0e_agpDZsdu6obb8f5i-Hs5Du5_ghXYJA=.4e59556e-e8e7-4b6e-a569-b636f0f676f7@github.com>

On Tue, 8 Mar 2022 04:50:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> if the scale > 1 then you can use low precision -> if the scale is equal to 2 then shift by two/four pixels or something like that?

@mrserb I suppose I could do that, but then it wouldn't be much different from the existing tests that verify color inside a sufficiently large area. I can make this area smaller, but this still won't help to find a rounding error in `gtk3_get_drawable_data()`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From smandalika at openjdk.java.net  Wed Mar  9 08:21:23 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 9 Mar 2022 08:21:23 GMT
Subject: RFR: 8282857: Create a regression test for JDK-4702690
Message-ID: <jklfp2oMIJWjzE4tz62KCLHfBqlaV0GlyZqk-wUiFHI=.7a721efc-e549-4058-819e-2785e64d9e8d@github.com>

Create a regression test for [JDK-4702690](https://bugs.openjdk.java.net/browse/JDK-4702690)

In many cases in Swing it is possible to easily programatically determine that a JScrollBar (or two) is scrolling some JPanel (the cannonical case is a JScrollPane).
In these cases, when accessibility support is instantiated (e.g. the AccessibleJScrollBar is created), a Controller_For and Controled_By relation should be instantiated between the AccessibleJScrollBar and the AccessibleJPanel that the JScrollBar and JPanel are associated with.

This allows various assistive technologies, especially voice-recognition technologies, to better interact with scrolling items.

The test put up validates that the target object for these properties(CONTROLLED_BY, CONTROLLED_FOR) are set appropriately for JScrollPane and JScrollBar.

-------------

Commit messages:
 - 8282857: Create a regression test for JDK-4702690

Changes: https://git.openjdk.java.net/jdk/pull/7753/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7753&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282857
  Stats: 106 lines in 1 file changed: 106 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7753.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7753/head:pull/7753

PR: https://git.openjdk.java.net/jdk/pull/7753


From aivanov at openjdk.java.net  Wed Mar  9 09:14:08 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 9 Mar 2022 09:14:08 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig() [v2]
In-Reply-To: <ZRNakjIguZ98WIzHKjOaIZs6I-oM_u5atLQm8Q1EQc8=.126d61df-ef31-4be0-86ff-6e2d0b4ce201@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
 <ZRNakjIguZ98WIzHKjOaIZs6I-oM_u5atLQm8Q1EQc8=.126d61df-ef31-4be0-86ff-6e2d0b4ce201@github.com>
Message-ID: <fvC-3RC0G4d0EVAiIMS-uCICYlxvt4TexQKBXGWkrBA=.04680060-50db-42f7-b493-c42178085ac5@github.com>

On Tue, 8 Mar 2022 15:54:45 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs`
>> 
>> Test:
>> 
>> - [x] jdk_desktop on Linux x86_64
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mrserb and aivanov-jdk's comments

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7691


From aivanov at openjdk.java.net  Wed Mar  9 09:42:00 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 9 Mar 2022 09:42:00 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig() [v2]
In-Reply-To: <C7zON_MwM69D6PxMGQAvVJwwczdn_RgzwNDM58sS8bY=.258b933b-abf6-4600-9ca5-b5eefaef9b22@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
 <ZRNakjIguZ98WIzHKjOaIZs6I-oM_u5atLQm8Q1EQc8=.126d61df-ef31-4be0-86ff-6e2d0b4ce201@github.com>
 <C7zON_MwM69D6PxMGQAvVJwwczdn_RgzwNDM58sS8bY=.258b933b-abf6-4600-9ca5-b5eefaef9b22@github.com>
Message-ID: <xD8nVklzvh_Wr5LUI45-zHoP8GG2Yf5dl2-7rKyeUe8=.5fefd2cd-b8c0-4b58-bd04-5718af0c3283@github.com>

On Tue, 8 Mar 2022 20:47:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> You're right. The old icon handles in `hOldIcon` and `hOldIconSm` will be leaked here if `CreateIconFromRaster` throws an exception.

I've submitted [JDK-8282862](https://bugs.openjdk.java.net/browse/JDK-8282862): AwtWindow::SetIconData leaks old icon handles if an exception is detected

-------------

PR: https://git.openjdk.java.net/jdk/pull/7691


From duke at openjdk.java.net  Wed Mar  9 09:49:03 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Wed, 9 Mar 2022 09:49:03 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861
In-Reply-To: <AyI2GAFstNxlfVoXNkHoWEPbc1lVQbkvlX97OzUIQlA=.efc49c30-641a-4556-b0a2-d37806ff847e@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <B2CHu-TrteeGoFk5ciTK_-Pvdwop-Vfwp3vmWh-kQUU=.d1a2d5b3-6150-4a95-8da6-0a5aa58c3e69@github.com>
 <OU17BKK48iYH-RHO3JKDGNtevs1v0eV0nElDAqNTh4Y=.685cd66b-965d-4a57-9129-a2ec5364f15e@github.com>
 <Ng7zkIIZ2e0jXX0zOM8R8wneueIfSiJA8UJsP-KC3ho=.bc5efc47-cc81-4fb1-a60e-4e9b2f012690@github.com>
 <AyI2GAFstNxlfVoXNkHoWEPbc1lVQbkvlX97OzUIQlA=.efc49c30-641a-4556-b0a2-d37806ff847e@github.com>
Message-ID: <TzdA8vDn1JHsq91XY1rsi7C-KT2slkKIijXRiVjBzFM=.6d67cdb1-1524-4164-89bb-fb00b613ec58@github.com>

On Tue, 8 Mar 2022 16:10:02 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> > I submitted a job for testing the changes.
>>> 
>>> Thanks a lot!
>> 
>> I got 1 failure out of 15 on Linux for `java/awt/Robot/HiDPIScreenCapture/HiDPIRobotScreenCaptureTest.java`. The screenshot of the entire screen has no open windows: just plain desktop background. It was probably captured after the test was shutdown.
>> 
>> The test doesn't save the captured image on failure, does it?
>> 
>> It's crucial to save the captured images, otherwise we're blind and left to guess what Robot captured and why it didn't match.
>
>> @aivanov-jdk Could you please re-run the test? Thanks once more!
> 
> Sorry for my delayed reply.
> 
> One failure reported:
> 
> command: main -Dsun.java2d.win.uiScaleX=3 -Dsun.java2d.win.uiScaleY=2 HiDPIRobotScreenCaptureTest
> ...
> ----------System.out:(3/218)----------
> Creating screen capture of java.awt.Rectangle[x=83,y=97,width=400,height=300]
> Checking (100, 75) to have color java.awt.Color[r=0,g=255,b=0]
> ... Mismatch: found java.awt.Color[r=135,g=8,b=69] instead. Check image.png.
> ----------System.err:(12/723)----------
> java.lang.RuntimeException: Wrong image color!
> 	at HiDPIRobotScreenCaptureTest.checkRectColor(HiDPIRobotScreenCaptureTest.java:125)
> 	at HiDPIRobotScreenCaptureTest.main(HiDPIRobotScreenCaptureTest.java:108)
> ...
> 
> ![The captured image.png](https://user-images.githubusercontent.com/70774172/157277072-febab0d6-bef3-43df-a98f-8b6b6eea60ff.png)
> 
> The checked point (x, y) = (100, 75) is 10 pixels into the green square but it's 55 pixels above the square.

@aivanov-jdk Thanks for re-running the test. Where does this failure come from - Linux or Windows? The saved image's size is correct (400x300 px), but I can't explain the location of the painted area inside it and why it is so small...

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From dbatrak at openjdk.java.net  Wed Mar  9 09:51:06 2022
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Wed, 9 Mar 2022 09:51:06 GMT
Subject: RFR: 8185261: Font fallback sometimes doesn't work in Swing text
 components [v2]
In-Reply-To: <4SfhJKrUWWmdo2ZioTjqiU5b3a4cZBwWhMX89auZBRg=.5bf8b903-dbb2-4e7c-adaf-59c5e8212e72@github.com>
References: <5qQoyooaZzlKSp4iMudwLZ16MotrGrPB7GhQ3aAVYjo=.8e97ba6f-4aab-40d7-944f-4f68dc2b7b1c@github.com>
 <4SfhJKrUWWmdo2ZioTjqiU5b3a4cZBwWhMX89auZBRg=.5bf8b903-dbb2-4e7c-adaf-59c5e8212e72@github.com>
Message-ID: <moKITpfuhzdTGuFFjkAtTNVvQpAEfBP-DY-PfIQp3_s=.626c94af-9b1c-4837-b79f-02d072a6e9d7@github.com>

On Tue, 1 Feb 2022 21:40:53 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

>> The proposed fix makes fonts with and without fallback components distinguishable (in terms of `equals` method), so that
>> font metrics cache (and other similar code) can handle them separately. This is achieved by adding a new boolean field
>> to `Font` class, specifically denoting fonts with fallback components. The latter ones don't need to pretend to be
>> 'created' fonts anymore, to preserve their `Font2D` handle.
>> It's not possible to use the existing `createdFont` field in `equals` implementation, as JCK requires a 'real' created
>> font (the one obtained using `Font.createFont` method) to be equal to the same font after serialization and
>> deserialization.
>
> Dmitry Batrak has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove 'headful' requirement from test case

Still needs a review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7313


From aivanov at openjdk.java.net  Wed Mar  9 10:35:55 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 9 Mar 2022 10:35:55 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861
In-Reply-To: <AyI2GAFstNxlfVoXNkHoWEPbc1lVQbkvlX97OzUIQlA=.efc49c30-641a-4556-b0a2-d37806ff847e@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <B2CHu-TrteeGoFk5ciTK_-Pvdwop-Vfwp3vmWh-kQUU=.d1a2d5b3-6150-4a95-8da6-0a5aa58c3e69@github.com>
 <OU17BKK48iYH-RHO3JKDGNtevs1v0eV0nElDAqNTh4Y=.685cd66b-965d-4a57-9129-a2ec5364f15e@github.com>
 <Ng7zkIIZ2e0jXX0zOM8R8wneueIfSiJA8UJsP-KC3ho=.bc5efc47-cc81-4fb1-a60e-4e9b2f012690@github.com>
 <AyI2GAFstNxlfVoXNkHoWEPbc1lVQbkvlX97OzUIQlA=.efc49c30-641a-4556-b0a2-d37806ff847e@github.com>
Message-ID: <2HbOJApbFTU13CcwJaiU1d__ivYxshUWXgIjX20f8yQ=.79d8f7ef-bdc2-4575-b126-5d6a5dcb7a61@github.com>

On Tue, 8 Mar 2022 16:10:02 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> > I submitted a job for testing the changes.
>>> 
>>> Thanks a lot!
>> 
>> I got 1 failure out of 15 on Linux for `java/awt/Robot/HiDPIScreenCapture/HiDPIRobotScreenCaptureTest.java`. The screenshot of the entire screen has no open windows: just plain desktop background. It was probably captured after the test was shutdown.
>> 
>> The test doesn't save the captured image on failure, does it?
>> 
>> It's crucial to save the captured images, otherwise we're blind and left to guess what Robot captured and why it didn't match.
>
>> @aivanov-jdk Could you please re-run the test? Thanks once more!
> 
> Sorry for my delayed reply.
> 
> One failure reported:
> 
> command: main -Dsun.java2d.win.uiScaleX=3 -Dsun.java2d.win.uiScaleY=2 HiDPIRobotScreenCaptureTest
> ...
> ----------System.out:(3/218)----------
> Creating screen capture of java.awt.Rectangle[x=83,y=97,width=400,height=300]
> Checking (100, 75) to have color java.awt.Color[r=0,g=255,b=0]
> ... Mismatch: found java.awt.Color[r=135,g=8,b=69] instead. Check image.png.
> ----------System.err:(12/723)----------
> java.lang.RuntimeException: Wrong image color!
> 	at HiDPIRobotScreenCaptureTest.checkRectColor(HiDPIRobotScreenCaptureTest.java:125)
> 	at HiDPIRobotScreenCaptureTest.main(HiDPIRobotScreenCaptureTest.java:108)
> ...
> 
> ![The captured image.png](https://user-images.githubusercontent.com/70774172/157277072-febab0d6-bef3-43df-a98f-8b6b6eea60ff.png)
> 
> The checked point (x, y) = (100, 75) is 10 pixels into the green square but it's 55 pixels above the square.

> @aivanov-jdk Thanks for re-running the test. Where does this failure come from - Linux or Windows? The saved image's size is correct (400x300 px), but I can't explain the location of the painted area inside it and why it is so small...

It's Linux, Ubuntu 20.10. Neither can I.

I checked the history and the test failed on different hosts, so it could be an intermittent bug in JDK itself.

~~Shouldn't the image be larger than 400?300? The size of the frame is 400?300 in user's space, the test is running with uiScaleX=3 and uiScaleY=2, therefore the size of the frame should be 1200?600. In some cases, such a size may not fit on the screen.~~ I see these `sun.java2d.win.uiScale{X,Y}` affect Windows only. On Ubuntu, the test runs according to the system settings.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From aivanov at openjdk.java.net  Wed Mar  9 11:05:05 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 9 Mar 2022 11:05:05 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861
In-Reply-To: <2HbOJApbFTU13CcwJaiU1d__ivYxshUWXgIjX20f8yQ=.79d8f7ef-bdc2-4575-b126-5d6a5dcb7a61@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <B2CHu-TrteeGoFk5ciTK_-Pvdwop-Vfwp3vmWh-kQUU=.d1a2d5b3-6150-4a95-8da6-0a5aa58c3e69@github.com>
 <OU17BKK48iYH-RHO3JKDGNtevs1v0eV0nElDAqNTh4Y=.685cd66b-965d-4a57-9129-a2ec5364f15e@github.com>
 <Ng7zkIIZ2e0jXX0zOM8R8wneueIfSiJA8UJsP-KC3ho=.bc5efc47-cc81-4fb1-a60e-4e9b2f012690@github.com>
 <AyI2GAFstNxlfVoXNkHoWEPbc1lVQbkvlX97OzUIQlA=.efc49c30-641a-4556-b0a2-d37806ff847e@github.com>
 <2HbOJApbFTU13CcwJaiU1d__ivYxshUWXgIjX20f8yQ=.79d8f7ef-bdc2-4575-b126-5d6a5dcb7a61@github.com>
Message-ID: <ZYtIoW0UbJ59TCkPHgUyZ9dNz9PmJuNUBygEUZgKWTg=.6509cf6c-e985-4c8b-b9ad-3e9af583d235@github.com>

On Wed, 9 Mar 2022 10:32:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Shouldn't the image be larger than 400?300? The size of the frame is 400?300 in user's space, the test is running with uiScaleX=3 and uiScaleY=2, therefore the size of the frame should be 1200?600. In some cases, such a size may not fit on the screen.

This is what happened on Windows:
![Captured image on Windows](https://user-images.githubusercontent.com/70774172/157427018-4b7acdb9-145a-426c-888d-8d4be33b0fc0.png)

The frame didn't fit on the screen. According to the screenshot of the entire screen, the resolution on the host was 1024?768. It can't fit the frame which is larger than screen 1200?600, especially when it is positioned at 83*3=248, 97*2=194.

This failure has nothing to do with [JDK-8280861](https://bugs.openjdk.java.net/browse/JDK-8280861), it's just a coincidence.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From dholmes at openjdk.java.net  Wed Mar  9 11:13:01 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Mar 2022 11:13:01 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig() [v2]
In-Reply-To: <ZRNakjIguZ98WIzHKjOaIZs6I-oM_u5atLQm8Q1EQc8=.126d61df-ef31-4be0-86ff-6e2d0b4ce201@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
 <ZRNakjIguZ98WIzHKjOaIZs6I-oM_u5atLQm8Q1EQc8=.126d61df-ef31-4be0-86ff-6e2d0b4ce201@github.com>
Message-ID: <hlbe6_FR-8HfUs0apGlvWdG_0sJO2u6hlVx1MTMWYrM=.fdb81fc9-65b6-4175-b23c-bb50d661fac3@github.com>

On Tue, 8 Mar 2022 15:54:45 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs`
>> 
>> Test:
>> 
>> - [x] jdk_desktop on Linux x86_64
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mrserb and aivanov-jdk's comments

Current version seems fine.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7691


From zgu at openjdk.java.net  Wed Mar  9 13:31:05 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 9 Mar 2022 13:31:05 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig() [v2]
In-Reply-To: <-S80LKyRxiTf3Cpc22n2rjAz9wJFGlM795arBKTmlcw=.d22e7b11-6b30-4f35-8b6b-03bd190946df@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
 <ZRNakjIguZ98WIzHKjOaIZs6I-oM_u5atLQm8Q1EQc8=.126d61df-ef31-4be0-86ff-6e2d0b4ce201@github.com>
 <-S80LKyRxiTf3Cpc22n2rjAz9wJFGlM795arBKTmlcw=.d22e7b11-6b30-4f35-8b6b-03bd190946df@github.com>
Message-ID: <wLrkTb10vSZ11a5xVJOhChWg5i82OORzbvXgrQBnar0=.9833f447-604a-49e7-8651-3aee0f1180a5@github.com>

On Wed, 9 Mar 2022 06:53:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   mrserb and aivanov-jdk's comments
>
> Still looks good to me.

Thanks for the review and suggestions,  @tstuefe, @dholmes-ora , @mrserb, @aivanov-jdk

-------------

PR: https://git.openjdk.java.net/jdk/pull/7691


From zgu at openjdk.java.net  Wed Mar  9 13:31:06 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 9 Mar 2022 13:31:06 GMT
Subject: Integrated: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig()
In-Reply-To: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
Message-ID: <mZQoTfwS2pOOxjvvmh008U_9qy6xeIJkYVo_8Iw4kL8=.5a4d0e7f-3f64-4f9e-877c-3111c8acff15@github.com>

On Fri, 4 Mar 2022 13:25:12 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs`
> 
> Test:
> 
> - [x] jdk_desktop on Linux x86_64

This pull request has now been integrated.

Changeset: 5df2a057
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5df2a057707eb65148f96710bd57d8dd8d85d1ed
Stats:     5 lines in 1 file changed: 2 ins; 0 del; 3 mod

8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig()

Reviewed-by: stuefe, dholmes, aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/7691


From duke at openjdk.java.net  Wed Mar  9 13:35:46 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Wed, 9 Mar 2022 13:35:46 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861
In-Reply-To: <ZYtIoW0UbJ59TCkPHgUyZ9dNz9PmJuNUBygEUZgKWTg=.6509cf6c-e985-4c8b-b9ad-3e9af583d235@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <B2CHu-TrteeGoFk5ciTK_-Pvdwop-Vfwp3vmWh-kQUU=.d1a2d5b3-6150-4a95-8da6-0a5aa58c3e69@github.com>
 <OU17BKK48iYH-RHO3JKDGNtevs1v0eV0nElDAqNTh4Y=.685cd66b-965d-4a57-9129-a2ec5364f15e@github.com>
 <Ng7zkIIZ2e0jXX0zOM8R8wneueIfSiJA8UJsP-KC3ho=.bc5efc47-cc81-4fb1-a60e-4e9b2f012690@github.com>
 <AyI2GAFstNxlfVoXNkHoWEPbc1lVQbkvlX97OzUIQlA=.efc49c30-641a-4556-b0a2-d37806ff847e@github.com>
 <2HbOJApbFTU13CcwJaiU1d__ivYxshUWXgIjX20f8yQ=.79d8f7ef-bdc2-4575-b126-5d6a5dcb7a61@github.com>
 <ZYtIoW0UbJ59TCkPHgUyZ9dNz9PmJuNUBygEUZgKWTg=.6509cf6c-e985-4c8b-b9ad-3e9af583d235@github.com>
Message-ID: <kDfUBaJ2cpKl64zYSjUQwfIVotIpsi9rd5qHOibcAXo=.80119282-0abc-4b28-8cde-0c1fe0df0e14@github.com>

On Wed, 9 Mar 2022 11:02:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> @aivanov-jdk Thanks for re-running the test. Where does this failure come from - Linux or Windows? The saved image's size is correct (400x300 px), but I can't explain the location of the painted area inside it and why it is so small...
>> 
>> It's Linux, Ubuntu 20.10. Neither can I.
>> 
>> I checked the history and the test failed on different hosts, so it could be an intermittent bug in JDK itself.
>> 
>> ~~Shouldn't the image be larger than 400?300? The size of the frame is 400?300 in user's space, the test is running with uiScaleX=3 and uiScaleY=2, therefore the size of the frame should be 1200?600. In some cases, such a size may not fit on the screen.~~ I see these `sun.java2d.win.uiScale{X,Y}` affect Windows only. On Ubuntu, the test runs according to the system settings.
>
>> Shouldn't the image be larger than 400?300? The size of the frame is 400?300 in user's space, the test is running with uiScaleX=3 and uiScaleY=2, therefore the size of the frame should be 1200?600. In some cases, such a size may not fit on the screen.
> 
> This is what happened on Windows:
> ![Captured image on Windows](https://user-images.githubusercontent.com/70774172/157427018-4b7acdb9-145a-426c-888d-8d4be33b0fc0.png)
> 
> The frame didn't fit on the screen. According to the screenshot of the entire screen, the resolution on the host was 1024?768. It can't fit the frame which is larger than screen 1200?600, especially when it is positioned at 83*3=248, 97*2=194.
> 
> This failure has nothing to do with [JDK-8280861](https://bugs.openjdk.java.net/browse/JDK-8280861), it's just a coincidence.

@aivanov-jdk I added image-saving code to the Linux test `ScreenCaptureGtkTest.java`. Could you please re-run it?
As before, it passes my test runs on Ubuntu 20.04.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From duke at openjdk.java.net  Wed Mar  9 13:35:44 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Wed, 9 Mar 2022 13:35:44 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v3]
In-Reply-To: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
Message-ID: <6pGT5DmJQoDUOkO7uGHHh3DgPrtciQWTerAigWPh4-4=.85547921-1017-438c-9af4-7e3b90c06bb2@github.com>

> The two tests `ScreenCaptureGtkTest.java` and `HiDPIRobotScreenCaptureTest.java` under `java/awt/Robot/HiDPIScreenCapture` started to intermittently fail under Windows and Linux after the [recent changes](https://github.com/openjdk/jdk/commit/cc7cf81256ed4d74493472017b1c4df20fa2208a) made exclusively for the Linux `Robot` implementation.
> 
> `HiDPIRobotScreenCaptureTest.java`
> Since the Windows failures cannot possibly have their origin in the fix made - the latter being Linux-only - the test apparently either exposes an existing bug in the Windows `Robot` or is bumping against a peculiarity of that platform. The test is reverted back to its original form that didn't fail.
> 
> `ScreenCaptureGtkTest.java`
> The coordinates in the log `(83, 78)` of a failure are higher up than the test suggests `(83, 97)`. I've seen similar failures on Ubuntu 20.04 when the coordinates were set to `(0, 0)`. The color then picked matched the color of the bar drawn at the top of the screen. I believe it's best to place the test pixels towards the center of the window to avoid desktop elements interference.
> 
> The other possible reason for intermittent failures are window coordinates. Suppose that the test is executing with `sun.java2d.uiScale` set to 2. This effectively means that it can only pick colors of pixels at even coordinates (in the absolute desktop space). So if the window is placed at, say, `(201, 201)`, `Robot` can only pick the color at either `(200, 200)` or `(202, 202)`. Since the test only makes sense if it is pixel-accurate, I removed all `@run`s with `sun.java2d.uiScale` other than 1. This way window placement will not cause a failure.
> 
> This was tested on Ubuntu 20.04 and 18.04 with desktop scaling set to 100%, 200%, and 300%.

Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:

  HiDPIRobotScreenCaptureTest.java: smaller frame size such that it fits on a 1200x600 screen.
  
  ScreenCaptureGtkTest.java: smaller frame size; added code to save
  the image on failure.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7613/files
  - new: https://git.openjdk.java.net/jdk/pull/7613/files/36be6acc..351626cf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7613&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7613&range=01-02

  Stats: 42 lines in 2 files changed: 33 ins; 2 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7613.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7613/head:pull/7613

PR: https://git.openjdk.java.net/jdk/pull/7613


From zgu at openjdk.java.net  Wed Mar  9 13:49:04 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 9 Mar 2022 13:49:04 GMT
Subject: RFR: 8282628: Potential memory leak in
 sun.font.FontConfigManager.getFontConfig() [v2]
In-Reply-To: <xD8nVklzvh_Wr5LUI45-zHoP8GG2Yf5dl2-7rKyeUe8=.5fefd2cd-b8c0-4b58-bd04-5718af0c3283@github.com>
References: <RdNfTAJHL49x7SvhNFsZCpGGDZ3vZAwh6NyL6ii1I_Y=.fd80b6d2-38f5-4053-b247-f416b5a60cc8@github.com>
 <ZRNakjIguZ98WIzHKjOaIZs6I-oM_u5atLQm8Q1EQc8=.126d61df-ef31-4be0-86ff-6e2d0b4ce201@github.com>
 <C7zON_MwM69D6PxMGQAvVJwwczdn_RgzwNDM58sS8bY=.258b933b-abf6-4600-9ca5-b5eefaef9b22@github.com>
 <xD8nVklzvh_Wr5LUI45-zHoP8GG2Yf5dl2-7rKyeUe8=.5fefd2cd-b8c0-4b58-bd04-5718af0c3283@github.com>
Message-ID: <MI8RnXGQBIRX88k_OHvN7E1AnYAUh2X7-tAaGdvBP1o=.a4561fd8-6467-4192-9fe9-53025a8333a1@github.com>

On Wed, 9 Mar 2022 09:38:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > You're right. The old icon handles in `hOldIcon` and `hOldIconSm` will be leaked here if `CreateIconFromRaster` throws an exception.
> 
> I've submitted [JDK-8282862](https://bugs.openjdk.java.net/browse/JDK-8282862): AwtWindow::SetIconData leaks old icon handles if an exception is detected

Thanks for the confirmation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7691


From smandalika at openjdk.java.net  Wed Mar  9 13:56:01 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 9 Mar 2022 13:56:01 GMT
Subject: RFR: JDK-8282046: Create a regression test for CCC8000326 [v2]
In-Reply-To: <-VGyuJF_FNWbGP0twM4iFd8-XQSMXwUtojpZ-ahuSG0=.8bf0a780-7586-46c8-9bc2-dc6e06e5ee0f@github.com>
References: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
 <-VGyuJF_FNWbGP0twM4iFd8-XQSMXwUtojpZ-ahuSG0=.8bf0a780-7586-46c8-9bc2-dc6e06e5ee0f@github.com>
Message-ID: <h_GF-SnUDxtWkHSqDBqzcWcS2bOwA-ObGGxXlYwK3fc=.43f6eb7b-49d9-4372-8602-7fd13c9d91b0@github.com>

On Mon, 21 Feb 2022 21:03:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments fixed: file name changed, volatile dimension, static call to doTest
>
> Changes requested by aivanov (Reviewer).

@aivanov-jdk  Can you please review this PR?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7512


From aivanov at openjdk.java.net  Wed Mar  9 14:19:01 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 9 Mar 2022 14:19:01 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861
In-Reply-To: <ZYtIoW0UbJ59TCkPHgUyZ9dNz9PmJuNUBygEUZgKWTg=.6509cf6c-e985-4c8b-b9ad-3e9af583d235@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <B2CHu-TrteeGoFk5ciTK_-Pvdwop-Vfwp3vmWh-kQUU=.d1a2d5b3-6150-4a95-8da6-0a5aa58c3e69@github.com>
 <OU17BKK48iYH-RHO3JKDGNtevs1v0eV0nElDAqNTh4Y=.685cd66b-965d-4a57-9129-a2ec5364f15e@github.com>
 <Ng7zkIIZ2e0jXX0zOM8R8wneueIfSiJA8UJsP-KC3ho=.bc5efc47-cc81-4fb1-a60e-4e9b2f012690@github.com>
 <AyI2GAFstNxlfVoXNkHoWEPbc1lVQbkvlX97OzUIQlA=.efc49c30-641a-4556-b0a2-d37806ff847e@github.com>
 <2HbOJApbFTU13CcwJaiU1d__ivYxshUWXgIjX20f8yQ=.79d8f7ef-bdc2-4575-b126-5d6a5dcb7a61@github.com>
 <ZYtIoW0UbJ59TCkPHgUyZ9dNz9PmJuNUBygEUZgKWTg=.6509cf6c-e985-4c8b-b9ad-3e9af583d235@github.com>
Message-ID: <xJHbeLvhFaKHCTfvpasDQz_4VpxPDpJlAXqLdTPchkc=.6dd35247-ede9-4e5b-99fa-3b1b8fa02778@github.com>

On Wed, 9 Mar 2022 11:02:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> @aivanov-jdk Thanks for re-running the test. Where does this failure come from - Linux or Windows? The saved image's size is correct (400x300 px), but I can't explain the location of the painted area inside it and why it is so small...
>> 
>> It's Linux, Ubuntu 20.10. Neither can I.
>> 
>> I checked the history and the test failed on different hosts, so it could be an intermittent bug in JDK itself.
>> 
>> ~~Shouldn't the image be larger than 400?300? The size of the frame is 400?300 in user's space, the test is running with uiScaleX=3 and uiScaleY=2, therefore the size of the frame should be 1200?600. In some cases, such a size may not fit on the screen.~~ I see these `sun.java2d.win.uiScale{X,Y}` affect Windows only. On Ubuntu, the test runs according to the system settings.
>
>> Shouldn't the image be larger than 400?300? The size of the frame is 400?300 in user's space, the test is running with uiScaleX=3 and uiScaleY=2, therefore the size of the frame should be 1200?600. In some cases, such a size may not fit on the screen.
> 
> This is what happened on Windows:
> ![Captured image on Windows](https://user-images.githubusercontent.com/70774172/157427018-4b7acdb9-145a-426c-888d-8d4be33b0fc0.png)
> 
> The frame didn't fit on the screen. According to the screenshot of the entire screen, the resolution on the host was 1024?768. It can't fit the frame which is larger than screen 1200?600, especially when it is positioned at 83*3=248, 97*2=194.
> 
> This failure has nothing to do with [JDK-8280861](https://bugs.openjdk.java.net/browse/JDK-8280861), it's just a coincidence.

> @aivanov-jdk I added image-saving code to the Linux test `ScreenCaptureGtkTest.java`. Could you please re-run it? As before, it passes my test runs on Ubuntu 20.04.

I added [the code myself](https://github.com/aivanov-jdk/jdk/commits/8282270-screenCapture) and it's scheduled to run on the host where the test failed. I started my branched from [JDK-8280861](https://bugs.openjdk.java.net/browse/JDK-8280861). Let's see what went wrong.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From aivanov at openjdk.java.net  Wed Mar  9 14:26:03 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 9 Mar 2022 14:26:03 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v3]
In-Reply-To: <6pGT5DmJQoDUOkO7uGHHh3DgPrtciQWTerAigWPh4-4=.85547921-1017-438c-9af4-7e3b90c06bb2@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <6pGT5DmJQoDUOkO7uGHHh3DgPrtciQWTerAigWPh4-4=.85547921-1017-438c-9af4-7e3b90c06bb2@github.com>
Message-ID: <ydXqoU6eOcbICNMi2XpmrL6YSZJHqc25IOEzWmt8KCk=.58e0eafe-f236-4766-8bc6-d9030d2e38d6@github.com>

On Wed, 9 Mar 2022 13:35:44 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> The two tests `ScreenCaptureGtkTest.java` and `HiDPIRobotScreenCaptureTest.java` under `java/awt/Robot/HiDPIScreenCapture` started to intermittently fail under Windows and Linux after the [recent changes](https://github.com/openjdk/jdk/commit/cc7cf81256ed4d74493472017b1c4df20fa2208a) made exclusively for the Linux `Robot` implementation.
>> 
>> `HiDPIRobotScreenCaptureTest.java`
>> Since the Windows failures cannot possibly have their origin in the fix made - the latter being Linux-only - the test apparently either exposes an existing bug in the Windows `Robot` or is bumping against a peculiarity of that platform. The test is reverted back to its original form that didn't fail.
>> 
>> `ScreenCaptureGtkTest.java`
>> The coordinates in the log `(83, 78)` of a failure are higher up than the test suggests `(83, 97)`. I've seen similar failures on Ubuntu 20.04 when the coordinates were set to `(0, 0)`. The color then picked matched the color of the bar drawn at the top of the screen. I believe it's best to place the test pixels towards the center of the window to avoid desktop elements interference.
>> 
>> The other possible reason for intermittent failures are window coordinates. Suppose that the test is executing with `sun.java2d.uiScale` set to 2. This effectively means that it can only pick colors of pixels at even coordinates (in the absolute desktop space). So if the window is placed at, say, `(201, 201)`, `Robot` can only pick the color at either `(200, 200)` or `(202, 202)`. Since the test only makes sense if it is pixel-accurate, I removed all `@run`s with `sun.java2d.uiScale` other than 1. This way window placement will not cause a failure.
>> 
>> This was tested on Ubuntu 20.04 and 18.04 with desktop scaling set to 100%, 200%, and 300%.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   HiDPIRobotScreenCaptureTest.java: smaller frame size such that it fits on a 1200x600 screen.
>   
>   ScreenCaptureGtkTest.java: smaller frame size; added code to save
>   the image on failure.

Does it make sense to run all the checks before throwing the exception?

I mean run all the checks that the test performs and accumulate failures if any. If the list of failures isn't empty, throw an exception to fail the entire test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From aivanov at openjdk.java.net  Wed Mar  9 14:37:01 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 9 Mar 2022 14:37:01 GMT
Subject: RFR: 8249592 : Robot.mouseMove moves cursor to incorrect location
 when display scale varies and Java runs in DPI Unaware mode [v3]
In-Reply-To: <UfxwyMHWRsrNOZUoU_l8Bv9SMm8GtyfI5i7Dk4JZCuo=.000fc764-7d45-4ca2-80a4-1ea3b014040b@github.com>
References: <7SyMjVox8LbT2ZqI1n0fj8nwb3YsCXfrap6VuGtNVbc=.e8c0bd94-c477-4a69-839f-25e7b3d31f7d@github.com>
 <UfxwyMHWRsrNOZUoU_l8Bv9SMm8GtyfI5i7Dk4JZCuo=.000fc764-7d45-4ca2-80a4-1ea3b014040b@github.com>
Message-ID: <LtNrJb_MnczpFLPJ1us-NaWbKzmkKSpPsYYuNmPQA3Y=.369d496d-8c88-4db7-9d76-fcd93604ddeb@github.com>

On Tue, 8 Mar 2022 18:26:59 GMT, Rajat Mahajan <duke at openjdk.java.net> wrote:

>> 8249592 : Robot.mouseMove moves cursor to incorrect location when display scale varies and Java runs in DPI Unaware mode
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   limit code to 80 characters per line

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7736


From duke at openjdk.java.net  Wed Mar  9 15:06:58 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Wed, 9 Mar 2022 15:06:58 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v3]
In-Reply-To: <ydXqoU6eOcbICNMi2XpmrL6YSZJHqc25IOEzWmt8KCk=.58e0eafe-f236-4766-8bc6-d9030d2e38d6@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <6pGT5DmJQoDUOkO7uGHHh3DgPrtciQWTerAigWPh4-4=.85547921-1017-438c-9af4-7e3b90c06bb2@github.com>
 <ydXqoU6eOcbICNMi2XpmrL6YSZJHqc25IOEzWmt8KCk=.58e0eafe-f236-4766-8bc6-d9030d2e38d6@github.com>
Message-ID: <de8SseltKYp0wACfzOkrvVbqq0YzXqju1fPDWpPlBVo=.8ca42205-8b1b-4ede-959e-47f28847b030@github.com>

On Wed, 9 Mar 2022 14:22:30 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Does it make sense to run all the checks before throwing the exception?
> 
> I mean run all the checks that the test performs and accumulate failures if any. If the list of failures isn't empty, throw an exception to fail the entire test.

That might turn out to be useful for debugging a failure, I think.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From alitvinov at openjdk.java.net  Wed Mar  9 16:11:02 2022
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Wed, 9 Mar 2022 16:11:02 GMT
Subject: RFR: 8277922: Unable to click JCheckBox in JTable through Java
 Access Bridge [v3]
In-Reply-To: <68JPxsadS5K_WkQgEkMdD_qCt1DWBpBVHV23b0oQKGU=.0b4e520a-205d-4cf1-b506-dd48616ebece@github.com>
References: <68JPxsadS5K_WkQgEkMdD_qCt1DWBpBVHV23b0oQKGU=.0b4e520a-205d-4cf1-b506-dd48616ebece@github.com>
Message-ID: <Vz4HgwEIrd3001wrGJ2-Vt55yX-YU8pfKgkw3qrb3Rc=.06e4fa2a-e91b-489d-af57-50499468371a@github.com>

> Hello,
> 
> Could you please review the following fix for the bug. The bug consists in the fact that When an assistive technology software by means of Java Access Bridge API executes "AccessibleAction" "click" on "AccessibleContext" which corresponds to "javax.swing.JTable" cell containing "javax.swing.JCheckBox", then the cell's value and cell's view represented by "JCheckBox" stay unchanged. The issue is a bug in JDK and should be fixed in JDK, because JDK informs the assistive technology software through Java Access Bridge API in particular through the function
> 
> "BOOL getAccessibleActions(long vmID, AccessibleContext accessibleContext, AccessibleActions *actions)"
> 
> that "AccessibleContext" of the table cell with "JCheckBox" supports one action "click", while real execution of this action on this accessible context does not lead to any result.
> 
> THE ROOT CAUSE OF THE BUG:
> 
> The reason of the issue is the fact that when the assistive technology software tries to do "AccessibleAction" on "AccessibleContext" associated with a cell with boolean data type in "JTable" component through Java Access Bridge (JAB), the JDK executes this "AccessibleAction" on "AccessibleContext" of a renderer, which is an instance of the class "javax.swing.JTable.BooleanRenderer" which is a derivative of "JCheckBox" class, and the instance of this renderer is single and common for all cells of boolean data type. Therefore execution of "click" "AccessibleAction" on this renderer component which is not permanently bound to any particular cell in the table does not lead to update of the table cell value.
> 
> THE FIX:
> 
> The fix implements an approach which guarantees setting of new values to the table's cells with boolean data type on each execution of "AccessibleAction" of "javax.swing.JTable.BooleanRenderer" instance, when execution of this action changes the "selected" state of this "BooleanRenderer" JCheckBox component.
> 
> Please take into account that the created automatic regression test simulates the issue only with Java Accessibility API what is not fully equal to the original test scenario which requires the assistive technology software and usage of Java Access Bridge API and which can be tested using the manual test case attached to the issue in JBS. However the regression test still allows to reproduce the issue and verify that the fix resolves it.
> 
> Thank you,
> Anton

Anton Litvinov has updated the pull request incrementally with one additional commit since the last revision:

  The third version of the fix for JDK-8277922

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7416/files
  - new: https://git.openjdk.java.net/jdk/pull/7416/files/aa1c2491..58cec72e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7416&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7416&range=01-02

  Stats: 420 lines in 3 files changed: 192 ins; 226 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7416.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7416/head:pull/7416

PR: https://git.openjdk.java.net/jdk/pull/7416


From alitvinov at openjdk.java.net  Wed Mar  9 17:31:00 2022
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Wed, 9 Mar 2022 17:31:00 GMT
Subject: RFR: 8277922: Unable to click JCheckBox in JTable through Java
 Access Bridge [v3]
In-Reply-To: <Vz4HgwEIrd3001wrGJ2-Vt55yX-YU8pfKgkw3qrb3Rc=.06e4fa2a-e91b-489d-af57-50499468371a@github.com>
References: <68JPxsadS5K_WkQgEkMdD_qCt1DWBpBVHV23b0oQKGU=.0b4e520a-205d-4cf1-b506-dd48616ebece@github.com>
 <Vz4HgwEIrd3001wrGJ2-Vt55yX-YU8pfKgkw3qrb3Rc=.06e4fa2a-e91b-489d-af57-50499468371a@github.com>
Message-ID: <C13OLGSlwmN6JOrKpnqsNSOhVy2-D-WT7phIxMWE4ys=.f2616b7f-4e60-4efd-a9e0-97803fc108cb@github.com>

On Wed, 9 Mar 2022 16:11:02 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

>> Hello,
>> 
>> Could you please review the following fix for the bug. The bug consists in the fact that When an assistive technology software by means of Java Access Bridge API executes "AccessibleAction" "click" on "AccessibleContext" which corresponds to "javax.swing.JTable" cell containing "javax.swing.JCheckBox", then the cell's value and cell's view represented by "JCheckBox" stay unchanged. The issue is a bug in JDK and should be fixed in JDK, because JDK informs the assistive technology software through Java Access Bridge API in particular through the function
>> 
>> "BOOL getAccessibleActions(long vmID, AccessibleContext accessibleContext, AccessibleActions *actions)"
>> 
>> that "AccessibleContext" of the table cell with "JCheckBox" supports one action "click", while real execution of this action on this accessible context does not lead to any result.
>> 
>> THE ROOT CAUSE OF THE BUG:
>> 
>> The reason of the issue is the fact that when the assistive technology software tries to do "AccessibleAction" on "AccessibleContext" associated with a cell with boolean data type in "JTable" component through Java Access Bridge (JAB), the JDK executes this "AccessibleAction" on "AccessibleContext" of a renderer, which is an instance of the class "javax.swing.JTable.BooleanRenderer" which is a derivative of "JCheckBox" class, and the instance of this renderer is single and common for all cells of boolean data type. Therefore execution of "click" "AccessibleAction" on this renderer component which is not permanently bound to any particular cell in the table does not lead to update of the table cell value.
>> 
>> THE FIX:
>> 
>> The fix implements an approach which guarantees setting of new values to the table's cells with boolean data type on each execution of "AccessibleAction" of "javax.swing.JTable.BooleanRenderer" instance, when execution of this action changes the "selected" state of this "BooleanRenderer" JCheckBox component.
>> 
>> Please take into account that the created automatic regression test simulates the issue only with Java Accessibility API what is not fully equal to the original test scenario which requires the assistive technology software and usage of Java Access Bridge API and which can be tested using the manual test case attached to the issue in JBS. However the regression test still allows to reproduce the issue and verify that the fix resolves it.
>> 
>> Thank you,
>> Anton
>
> Anton Litvinov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The third version of the fix for JDK-8277922

Hello Alexey @aivanov-jdk  and Sergey @mrserb,

The new third version of the fix is created and pushed to the branch of this pull request. The third version of the fix is completely alternative and guaranteed way of resolution of this bug, because of this I would recommend to look at its Full Webrev to simplify understanding of the fix before looking at the exact third commit in GitHub interface. Could you please review the third version of the fix?

In the third fix version I refused from the whole idea to implement the functionality accomplishing click action in BooleanRenderer component, and instead of this decided just to prohibit users to execute any accessible actions on AccessibleContext of BooleanRenderer and to put a point in this controversial bug. Among 6 default table cell renderers in JDK:
- "javax.swing.table.DefaultTableCellRenderer.UIResource"
- "javax.swing.JTable.NumberRenderer"
- "javax.swing.JTable.DoubleRenderer"
- "javax.swing.JTable.DateRenderer"
- "javax.swing.JTable.IconRenderer"
- "javax.swing.JTable.BooleanRenderer"

BooleanRenderer was the only component, whose AccessibleContext had non-null AccessibleAction, however as we see in all research in this bug and this review request, execution of this AccessibleAction of BoleanRenderer did not have any opportunity to change internal states and visual states of the corresponding table cell, so it just never worked. Also Java Access Bridge API for assistive technology software in C++/C, provides only functions to read states and data from accessible table object and does not provide functions for modification of accessible table, therefore implementation of AccessibleAction for BooleanRenderer would create unwanted contradiction in both Java Access Bridge API and Java Accessibility API.

Also recent offline feedback from the bug filer proved that the original approach in 1st and 2nd fix versions was not reliable and proper way of resolution of the bug. Because the main conceptual problem standing behind this bug is not resolvable reliably in current design of Java Access Bridge, which is the fact that 1 or more table cells with Boolean data in them are all associated with a single instance of BooleanRenderer by design of Java Access Bridge, and during execution of "doAccessibleAction(int)" of AccessibleAction of BooleanRenderer the BooleanRenderer HAS NO ANY MEANS to reliably know for which exact cell the user intended to execute the AccessibleAction. Currently each JTable cell has own AccessibleContext object which is instance of "JTable.AccessibleJTable.AccessibleJTableCell" and which internally calls API of AccessibleContext of renderer, but at the same time there is always an opportunity for the end user to get AccessibleContext of the renderer directly bypassing
  API of AccessibleJTable and AccessibleJTableCell, it can be as simple as this
`
TableCellRenderer cellRenderer = table.getCellRenderer(row, column);
if (cellRenderer instanceof Accessible) {
    AccessibleContext cellRendererAc = ((Accessible) cellRenderer).getAccessibleContext();
}
`
, so as soon as the user gets AccessibleContext of BooleanRenderer by any of existing way in Java Access Bridge API or Java Accessibility API, the user has right to call "doAccessibleAction" on it and to expect that it will be worked.

Therefore I am convinced that the only solid way to resolve this bug is to stop reporting to the end users that "AccessibleContext" of "BolleanRenderer" supports "AccessibleAction", what has never been supported in reality.

Thank you,
Anton

-------------

PR: https://git.openjdk.java.net/jdk/pull/7416


From alitvinov at openjdk.java.net  Wed Mar  9 17:44:25 2022
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Wed, 9 Mar 2022 17:44:25 GMT
Subject: RFR: 8277922: Unable to click JCheckBox in JTable through Java
 Access Bridge [v3]
In-Reply-To: <Vz4HgwEIrd3001wrGJ2-Vt55yX-YU8pfKgkw3qrb3Rc=.06e4fa2a-e91b-489d-af57-50499468371a@github.com>
References: <68JPxsadS5K_WkQgEkMdD_qCt1DWBpBVHV23b0oQKGU=.0b4e520a-205d-4cf1-b506-dd48616ebece@github.com>
 <Vz4HgwEIrd3001wrGJ2-Vt55yX-YU8pfKgkw3qrb3Rc=.06e4fa2a-e91b-489d-af57-50499468371a@github.com>
Message-ID: <DRsVmwW1sLibjkLPQzGiUs1kR_UDYAypF2nDShZIUJQ=.b126e1bd-018c-4958-8c77-cc42d032de8c@github.com>

On Wed, 9 Mar 2022 16:11:02 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

>> Hello,
>> 
>> Could you please review the following fix for the bug. The bug consists in the fact that When an assistive technology software by means of Java Access Bridge API executes "AccessibleAction" "click" on "AccessibleContext" which corresponds to "javax.swing.JTable" cell containing "javax.swing.JCheckBox", then the cell's value and cell's view represented by "JCheckBox" stay unchanged. The issue is a bug in JDK and should be fixed in JDK, because JDK informs the assistive technology software through Java Access Bridge API in particular through the function
>> 
>> "BOOL getAccessibleActions(long vmID, AccessibleContext accessibleContext, AccessibleActions *actions)"
>> 
>> that "AccessibleContext" of the table cell with "JCheckBox" supports one action "click", while real execution of this action on this accessible context does not lead to any result.
>> 
>> THE ROOT CAUSE OF THE BUG:
>> 
>> The reason of the issue is the fact that when the assistive technology software tries to do "AccessibleAction" on "AccessibleContext" associated with a cell with boolean data type in "JTable" component through Java Access Bridge (JAB), the JDK executes this "AccessibleAction" on "AccessibleContext" of a renderer, which is an instance of the class "javax.swing.JTable.BooleanRenderer" which is a derivative of "JCheckBox" class, and the instance of this renderer is single and common for all cells of boolean data type. Therefore execution of "click" "AccessibleAction" on this renderer component which is not permanently bound to any particular cell in the table does not lead to update of the table cell value.
>> 
>> THE FIX:
>> 
>> The fix implements an approach which guarantees setting of new values to the table's cells with boolean data type on each execution of "AccessibleAction" of "javax.swing.JTable.BooleanRenderer" instance, when execution of this action changes the "selected" state of this "BooleanRenderer" JCheckBox component.
>> 
>> Please take into account that the created automatic regression test simulates the issue only with Java Accessibility API what is not fully equal to the original test scenario which requires the assistive technology software and usage of Java Access Bridge API and which can be tested using the manual test case attached to the issue in JBS. However the regression test still allows to reproduce the issue and verify that the fix resolves it.
>> 
>> Thank you,
>> Anton
>
> Anton Litvinov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The third version of the fix for JDK-8277922

In addition to my previous comment. The regression test in the third fix version is completely rewritten and now tests scenarios corresponding to the fix and which are different from scenarios in the regression test of the first and the second fix versions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7416


From shurailine at openjdk.java.net  Wed Mar  9 20:40:44 2022
From: shurailine at openjdk.java.net (Alexandre Iline)
Date: Wed, 9 Mar 2022 20:40:44 GMT
Subject: RFR: 8282771 : Create test case for JDK-8262981 [v2]
In-Reply-To: <usATVM-CnG-KZiEBBuQyS-D8Muz1H_u6iZvuv3NY-PA=.2a6b01bb-a8e7-4048-851d-4ba6bd129a82@github.com>
References: <pbRcgoRd0mYiHu3ASOMDqfVCJuyKZsKKSZd3JlguYaM=.0770dc62-36be-42e8-b88e-6425263fd6dd@github.com>
 <usATVM-CnG-KZiEBBuQyS-D8Muz1H_u6iZvuv3NY-PA=.2a6b01bb-a8e7-4048-851d-4ba6bd129a82@github.com>
Message-ID: <WfPSMypUugSpI_d-zktrhRf4uLzO6yrTsgTgZ3CU-eg=.76e4a52a-2453-4a44-916b-de7c8b60eea2@github.com>

On Tue, 8 Mar 2022 05:10:51 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> Following methods are covered in this testcase
>> getAccessibleAction()
>> getAccessibleActionCount()
>> getAccessibleActionDescription()
>> doAccessibleAction(int direction) 
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added command after the date

@azuev-java what do you think be a better location for this test? javax/swing/JSlider/8262981 or somewhere in javax/accessibility?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7734


From shurailine at openjdk.java.net  Wed Mar  9 20:45:43 2022
From: shurailine at openjdk.java.net (Alexandre Iline)
Date: Wed, 9 Mar 2022 20:45:43 GMT
Subject: RFR: 8281284 : Write JSlider accessibility test [v6]
In-Reply-To: <fDOHV-OlzUk7WMu8mwl33ZjJLUJWqN9JPUfxe_WL9JA=.95cad332-bdca-4af4-9eaa-3a7a83be0606@github.com>
References: <VB8Ldq_d1uZBKpyvvDlu7t9lUtAd_WhLl4meSv46ixo=.b8b023ee-6946-407d-8e05-223fb2d95062@github.com>
 <fDOHV-OlzUk7WMu8mwl33ZjJLUJWqN9JPUfxe_WL9JA=.95cad332-bdca-4af4-9eaa-3a7a83be0606@github.com>
Message-ID: <rnRnhuvbmL6JHRwZkfpZ6K2kj8ixOEelt_EhARJwaV4=.e2acace3-646f-46c4-91eb-4f4a4b5fded4@github.com>

On Tue, 8 Mar 2022 05:13:44 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> This testcase covers both old and new api ( api added in jdk17  getAccessibleAction(), getAccessibleActionCount() , getAccessibleActionDescription )
>> 
>> @shurymury 
>> @savoptik
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comma after the date

There is some support for the manual accessibility tests recently added in javax/accessibility/manual test hierarchy. This test should go there and use the support. The tests which are currently there are using SwingSet app. It is very easy to extend the concept to support any other UI.

@azuev-java FYI

-------------

PR: https://git.openjdk.java.net/jdk/pull/7355


From kizune at openjdk.java.net  Wed Mar  9 20:46:56 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 9 Mar 2022 20:46:56 GMT
Subject: RFR: 8282771 : Create test case for JDK-8262981 [v2]
In-Reply-To: <WfPSMypUugSpI_d-zktrhRf4uLzO6yrTsgTgZ3CU-eg=.76e4a52a-2453-4a44-916b-de7c8b60eea2@github.com>
References: <pbRcgoRd0mYiHu3ASOMDqfVCJuyKZsKKSZd3JlguYaM=.0770dc62-36be-42e8-b88e-6425263fd6dd@github.com>
 <usATVM-CnG-KZiEBBuQyS-D8Muz1H_u6iZvuv3NY-PA=.2a6b01bb-a8e7-4048-851d-4ba6bd129a82@github.com>
 <WfPSMypUugSpI_d-zktrhRf4uLzO6yrTsgTgZ3CU-eg=.76e4a52a-2453-4a44-916b-de7c8b60eea2@github.com>
Message-ID: <ObP0bKCfSixV1mZgA0CPULBUuEzDLh8eSOV6QAlPKp0=.a65c6642-0ce7-48d9-828f-fce425531d04@github.com>

On Wed, 9 Mar 2022 20:37:50 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> @azuev-java what do you think be a better location for this test? javax/swing/JSlider/8262981 or somewhere in javax/accessibility?

I'd say let's group them up somewhere in accessibility folder so they can be ran easier as a bundle instead of selecting them from individual component test folders.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7734


From achung at openjdk.java.net  Wed Mar  9 21:16:48 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 9 Mar 2022 21:16:48 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10
Message-ID: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>

msg drop for jdk19, Mar 9, 2022

-------------

Commit messages:
 - open jdk19 l10n msg drop

Changes: https://git.openjdk.java.net/jdk/pull/7765/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280400
  Stats: 13775 lines in 142 files changed: 12170 ins; 1249 del; 356 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7765.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765

PR: https://git.openjdk.java.net/jdk/pull/7765


From shurailine at openjdk.java.net  Wed Mar  9 21:39:44 2022
From: shurailine at openjdk.java.net (Alexandre Iline)
Date: Wed, 9 Mar 2022 21:39:44 GMT
Subject: RFR: 8282771 : Create test case for JDK-8262981 [v2]
In-Reply-To: <usATVM-CnG-KZiEBBuQyS-D8Muz1H_u6iZvuv3NY-PA=.2a6b01bb-a8e7-4048-851d-4ba6bd129a82@github.com>
References: <pbRcgoRd0mYiHu3ASOMDqfVCJuyKZsKKSZd3JlguYaM=.0770dc62-36be-42e8-b88e-6425263fd6dd@github.com>
 <usATVM-CnG-KZiEBBuQyS-D8Muz1H_u6iZvuv3NY-PA=.2a6b01bb-a8e7-4048-851d-4ba6bd129a82@github.com>
Message-ID: <7EWmVHyewgaJ_TubMRdybp-GmJEtgtaC8jb7ULaJyyU=.6dc08b11-fe05-4c80-b031-a693ed65dbde@github.com>

On Tue, 8 Mar 2022 05:10:51 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> Following methods are covered in this testcase
>> getAccessibleAction()
>> getAccessibleActionCount()
>> getAccessibleActionDescription()
>> doAccessibleAction(int direction) 
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added command after the date

test/jdk/javax/swing/JSlider/8262981/JSliderAccessibleAction.java line 179:

> 177:         for (String laf : instLookAndFeels) {
> 178:             try {
> 179:                 invalidDecrementCountDownLatch = new CountDownLatch(1);

these fields are accessed both from EDT and the main test thread

-------------

PR: https://git.openjdk.java.net/jdk/pull/7734


From shurailine at openjdk.java.net  Wed Mar  9 21:46:43 2022
From: shurailine at openjdk.java.net (Alexandre Iline)
Date: Wed, 9 Mar 2022 21:46:43 GMT
Subject: RFR: 8282771 : Create test case for JDK-8262981 [v2]
In-Reply-To: <usATVM-CnG-KZiEBBuQyS-D8Muz1H_u6iZvuv3NY-PA=.2a6b01bb-a8e7-4048-851d-4ba6bd129a82@github.com>
References: <pbRcgoRd0mYiHu3ASOMDqfVCJuyKZsKKSZd3JlguYaM=.0770dc62-36be-42e8-b88e-6425263fd6dd@github.com>
 <usATVM-CnG-KZiEBBuQyS-D8Muz1H_u6iZvuv3NY-PA=.2a6b01bb-a8e7-4048-851d-4ba6bd129a82@github.com>
Message-ID: <50-l67zvGGkIYVVkvoyJQUT6QgaaUVL7IpVrFeShrGQ=.078f3025-81ac-4b49-9101-228cec94f50d@github.com>

On Tue, 8 Mar 2022 05:10:51 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> Following methods are covered in this testcase
>> getAccessibleAction()
>> getAccessibleActionCount()
>> getAccessibleActionDescription()
>> doAccessibleAction(int direction) 
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added command after the date

test/jdk/javax/swing/JSlider/8262981/JSliderAccessibleAction.java line 264:

> 262:                             "Increment button");
> 263:                 }
> 264:                 if (jSliderInitialValue.get() != currentJSliderValue.get()) {

This is  fundamentally unstable. 

You are clicking on the decrease button. The actual decrease which happened in the slider after the click may be more than you expect. Or less. 

The only reliable condition perhaps is that the value has decreased and even that may have a delayed effect, so it needs to be waited for. 

For example see  sanity/client/SwingSet/src/SliderDemoTest.java.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7734


From prr at openjdk.java.net  Wed Mar  9 22:23:41 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 9 Mar 2022 22:23:41 GMT
Subject: RFR: 8282577: ICC_Profile.setData(int,
 byte[]) invalidates the profile [v3]
In-Reply-To: <OtKvQNBuh1av_6S-qU2Nufz_hr4bD_-V8gSHyJBNgAw=.1bbdad9c-efb8-4f2d-ad51-5dea50df43ab@github.com>
References: <ecPAoejPCnfczdYoQmH89792PmRZxg4Rc5LaEHlsnXo=.3ad1b170-e862-4322-9164-df0501b298a0@github.com>
 <XTG2b5zZA9u3_Km2pJCA3xCsJzJl_tjOfnXGNunixgY=.c92ea820-38bc-4668-b8cc-350915a6fc7a@github.com>
 <OtKvQNBuh1av_6S-qU2Nufz_hr4bD_-V8gSHyJBNgAw=.1bbdad9c-efb8-4f2d-ad51-5dea50df43ab@github.com>
Message-ID: <FOujn0TqrgJzNCS6-rn9N7VJ1uRmdt8L8hK-mcgx5QQ=.2385d80a-d8f6-4adf-abb1-b977a2efaa08@github.com>

On Tue, 8 Mar 2022 04:09:23 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The current bug looks similar to this one https://bugs.openjdk.java.net/browse/JDK-8272865 I tried to fix it the same way but I was not sure if it is safe to ignore the ReadWriteProfileTest.java or not, since it has five related bugids.


I missed that bug. There's overlap but this bug is mainly about an unusable profile being returned.
The "nicety" that getData() returns what setData() set is much less important.

However I have been pondering that test.
If by the 5 related bug IDs you mean those in the @bug tag
 * @bug 6476665 6523403 6733501 7042594 7043064

only the last of them says anything clearly related where the eval from 2013 says
--

The only exception is ReadWriteProfileTest. This test relies on an assumption, 
that we read a data for a tag in the exactly same form as it was written. 
However, this assumption is not correct in case of lcms, because this 
library may perform some sort of modifications on the tag data. 
For example, plain text tags can be promoted to multilinguage tags, 
color points can be normalized and etc. To get this test working, we ether 
have to upgrade the tag comparison routines in the test, or force 
"as is" tag injection in lcms. The second option seems to be a bit dangerous 
to me because it potentially open doors for an injection of malformed tags 
into a profile. 
---

Actually it is not clear to me that modifications to that effect were made to the test by that bug fix.
I only see it skipping Kodak tags : http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a07c907a82b5

But it means even back then there was acknowledgement that getData() may not return what setData() set
even if the data were accepted. And plain (ascii) text tags being promoted to multi-lingual tags is an example of
what I saw. I've not dug into locating all versions of the ICC spec but an old copy makes no mention of the
multi-lingual support so I can imagine that LittleCMS is "bringing up to date" a tag that was encoded into
a profile before that support was present.

Source comments in LittleCMS on cmsReadRawTag seemed to suggest it would always cook the tag
so as to make sure it returned consistent results. But I checked with the LCMS maintainer and he
said that was out-dated and updated the source comments. So it is definite that we can't rely on
these being consistent.

So I have been wondering if the test is even valid and worth saving.

The spec doesn't say anything one way or another
https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/color/ICC_Profile.html#getData()
so I am sure a case could be made either way as to what it intended. 

One way to "save" the test is that after doing the validation which calls cmsReadTag() and get an "OK"
we discard this profile and create ANOTHER copy which we return to the app. Since nothing will have
cooked that new profile data it will get back what it set. Unless something else cooks it or LittleCMS behaviour changes.

I'm up for doing that here and then the test will pass again without changes.

> The current bug looks similar to this one https://bugs.openjdk.java.net/browse/JDK-8272865 I tried to fix it the same way but I was not sure if it is safe to ignore the ReadWriteProfileTest.java or not, since it has five related bugids.


I missed that bug. There's overlap but this bug is mainly about an unusable profile being returned.
The "nicety" that getData() returns what setData() set is much less important.

However I have been pondering that test.
If by the 5 related bug IDs you mean those in the @bug tag
 * @bug 6476665 6523403 6733501 7042594 7043064

only the last of them says anything clearly related where the eval from 2013 says
--

The only exception is ReadWriteProfileTest. This test relies on an assumption, 
that we read a data for a tag in the exactly same form as it was written. 
However, this assumption is not correct in case of lcms, because this 
library may perform some sort of modifications on the tag data. 
For example, plain text tags can be promoted to multilinguage tags, 
color points can be normalized and etc. To get this test working, we ether 
have to upgrade the tag comparison routines in the test, or force 
"as is" tag injection in lcms. The second option seems to be a bit dangerous 
to me because it potentially open doors for an injection of malformed tags 
into a profile. 
---

Actually it is not clear to me that modifications to that effect were made to the test by that bug fix.
I only see it skipping Kodak tags : http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a07c907a82b5

But it means even back then there was acknowledgement that getData() may not return what setData() set
even if the data were accepted. And plain (ascii) text tags being promoted to multi-lingual tags is an example of
what I saw. I've not dug into locating all versions of the ICC spec but an old copy makes no mention of the
multi-lingual support so I can imagine that LittleCMS is "bringing up to date" a tag that was encoded into
a profile before that support was present.

Source comments in LittleCMS on cmsReadRawTag seemed to suggest it would always cook the tag
so as to make sure it returned consistent results. But I checked with the LCMS maintainer and he
said that was out-dated and updated the source comments. So it is definite that we can't rely on
these being consistent.

So I have been wondering if the test is even valid and worth saving.

The spec doesn't say anything one way or another
https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/color/ICC_Profile.html#getData()
so I am sure a case could be made either way as to what it intended. 

One way to "save" the test is that after doing the validation which calls cmsReadTag() and get an "OK"
we discard this profile and create ANOTHER copy which we return to the app. Since nothing will have
cooked that new profile data it will get back what it set. Unless something else cooks it or LittleCMS behaviour changes.

I'm up for doing that here and then the test will pass again without changes.

> src/java.desktop/share/native/liblcms/LCMS.c line 765:
> 
>> 763:         // The profile we used for sanity checking needs to be returned
>> 764:         // since the one we updated is raw - not cooked.
>> 765:         cmsCloseProfile(p);
> 
> Looks like now we close this profile in all branches, so can we do that just above the "if (pfSanity == NULL)"?

Ok

-------------

PR: https://git.openjdk.java.net/jdk/pull/7668


From prr at openjdk.java.net  Wed Mar  9 22:23:42 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 9 Mar 2022 22:23:42 GMT
Subject: RFR: 8282577: ICC_Profile.setData(int,
 byte[]) invalidates the profile [v3]
In-Reply-To: <FOujn0TqrgJzNCS6-rn9N7VJ1uRmdt8L8hK-mcgx5QQ=.2385d80a-d8f6-4adf-abb1-b977a2efaa08@github.com>
References: <ecPAoejPCnfczdYoQmH89792PmRZxg4Rc5LaEHlsnXo=.3ad1b170-e862-4322-9164-df0501b298a0@github.com>
 <XTG2b5zZA9u3_Km2pJCA3xCsJzJl_tjOfnXGNunixgY=.c92ea820-38bc-4668-b8cc-350915a6fc7a@github.com>
 <OtKvQNBuh1av_6S-qU2Nufz_hr4bD_-V8gSHyJBNgAw=.1bbdad9c-efb8-4f2d-ad51-5dea50df43ab@github.com>
 <FOujn0TqrgJzNCS6-rn9N7VJ1uRmdt8L8hK-mcgx5QQ=.2385d80a-d8f6-4adf-abb1-b977a2efaa08@github.com>
Message-ID: <C74UYKEMkqPMHBgbhIC8Bd8JhGwVBG8ENRw0lRjVhXo=.99fa9656-12ef-43ea-9b5a-3056bf21c1af@github.com>

On Wed, 9 Mar 2022 22:20:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/native/liblcms/LCMS.c line 765:
>> 
>>> 763:         // The profile we used for sanity checking needs to be returned
>>> 764:         // since the one we updated is raw - not cooked.
>>> 765:         cmsCloseProfile(p);
>> 
>> Looks like now we close this profile in all branches, so can we do that just above the "if (pfSanity == NULL)"?
>
> Ok

Ok

-------------

PR: https://git.openjdk.java.net/jdk/pull/7668


From naoto at openjdk.java.net  Wed Mar  9 22:29:44 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 9 Mar 2022 22:29:44 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <PBk3nk8e8eclzDy8yKIrJOgKLqveAK3NoSqrAzra6fg=.3dbfe55e-2394-4ee6-bd3b-43b558c02ef7@github.com>

On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung <achung at openjdk.org> wrote:

> msg drop for jdk19, Mar 9, 2022

`src/java.base/share/classes/sun/util/resources/CurrencyNames_de.properties`
`src/java.base/share/classes/sun/util/resources/CurrencyNames_ja.properties`
`src/java.base/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties`

These are part of `jdk.localedata` module. Should be excluded from `java.base` module and apply the diffs to `src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_xx.properties` manually. (Note that the first half of it is not necessary when merging).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7765


From serb at openjdk.java.net  Wed Mar  9 22:41:44 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 9 Mar 2022 22:41:44 GMT
Subject: RFR: 8282577: ICC_Profile.setData(int,
 byte[]) invalidates the profile [v3]
In-Reply-To: <FOujn0TqrgJzNCS6-rn9N7VJ1uRmdt8L8hK-mcgx5QQ=.2385d80a-d8f6-4adf-abb1-b977a2efaa08@github.com>
References: <ecPAoejPCnfczdYoQmH89792PmRZxg4Rc5LaEHlsnXo=.3ad1b170-e862-4322-9164-df0501b298a0@github.com>
 <XTG2b5zZA9u3_Km2pJCA3xCsJzJl_tjOfnXGNunixgY=.c92ea820-38bc-4668-b8cc-350915a6fc7a@github.com>
 <OtKvQNBuh1av_6S-qU2Nufz_hr4bD_-V8gSHyJBNgAw=.1bbdad9c-efb8-4f2d-ad51-5dea50df43ab@github.com>
 <FOujn0TqrgJzNCS6-rn9N7VJ1uRmdt8L8hK-mcgx5QQ=.2385d80a-d8f6-4adf-abb1-b977a2efaa08@github.com>
Message-ID: <9h1diCMn_P6rhpXE2spMDP82cwk_QcvlakdmrpIvuBE=.3b8e4d62-904f-4568-bdef-4501f4ac981b@github.com>

On Wed, 9 Mar 2022 22:19:53 GMT, Phil Race <prr at openjdk.org> wrote:

> One way to "save" the test is that after doing the validation which calls cmsReadTag() and get an "OK" we discard this profile and create ANOTHER copy which we return to the app. Since nothing will have cooked that new profile data it will get back what it set. Unless something else cooks it or LittleCMS behaviour changes.
> 
> I'm up for doing that here and then the test will pass again without changes.

Based on the link below, I guess it is not possible to do:
https://github.com/mm2/Little-CMS/issues/275#issuecomment-907041554
> so writting a tag as raw and then reading it as cooked without serializing does result into an error.

If we will create a new profile it will not be possible to use it by the ColorTransform, because the LCMS will call cmsReadTag under the hood. But even if it will work the content of the tag will be changed.

But we can try for sure.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7668


From aivanov at openjdk.java.net  Wed Mar  9 23:11:46 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 9 Mar 2022 23:11:46 GMT
Subject: RFR: 8277922: Unable to click JCheckBox in JTable through Java
 Access Bridge [v3]
In-Reply-To: <Vz4HgwEIrd3001wrGJ2-Vt55yX-YU8pfKgkw3qrb3Rc=.06e4fa2a-e91b-489d-af57-50499468371a@github.com>
References: <68JPxsadS5K_WkQgEkMdD_qCt1DWBpBVHV23b0oQKGU=.0b4e520a-205d-4cf1-b506-dd48616ebece@github.com>
 <Vz4HgwEIrd3001wrGJ2-Vt55yX-YU8pfKgkw3qrb3Rc=.06e4fa2a-e91b-489d-af57-50499468371a@github.com>
Message-ID: <LnYrdRZZrxNBaQqNon8wZU4NlG4l63XPVtkDGFN1ftk=.7f878212-5d70-45fb-b50d-beb28a9566bd@github.com>

On Wed, 9 Mar 2022 16:11:02 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

>> Hello,
>> 
>> Could you please review the following fix for the bug. The bug consists in the fact that When an assistive technology software by means of Java Access Bridge API executes "AccessibleAction" "click" on "AccessibleContext" which corresponds to "javax.swing.JTable" cell containing "javax.swing.JCheckBox", then the cell's value and cell's view represented by "JCheckBox" stay unchanged. The issue is a bug in JDK and should be fixed in JDK, because JDK informs the assistive technology software through Java Access Bridge API in particular through the function
>> 
>> "BOOL getAccessibleActions(long vmID, AccessibleContext accessibleContext, AccessibleActions *actions)"
>> 
>> that "AccessibleContext" of the table cell with "JCheckBox" supports one action "click", while real execution of this action on this accessible context does not lead to any result.
>> 
>> THE ROOT CAUSE OF THE BUG:
>> 
>> The reason of the issue is the fact that when the assistive technology software tries to do "AccessibleAction" on "AccessibleContext" associated with a cell with boolean data type in "JTable" component through Java Access Bridge (JAB), the JDK executes this "AccessibleAction" on "AccessibleContext" of a renderer, which is an instance of the class "javax.swing.JTable.BooleanRenderer" which is a derivative of "JCheckBox" class, and the instance of this renderer is single and common for all cells of boolean data type. Therefore execution of "click" "AccessibleAction" on this renderer component which is not permanently bound to any particular cell in the table does not lead to update of the table cell value.
>> 
>> THE FIX:
>> 
>> The fix implements an approach which guarantees setting of new values to the table's cells with boolean data type on each execution of "AccessibleAction" of "javax.swing.JTable.BooleanRenderer" instance, when execution of this action changes the "selected" state of this "BooleanRenderer" JCheckBox component.
>> 
>> Please take into account that the created automatic regression test simulates the issue only with Java Accessibility API what is not fully equal to the original test scenario which requires the assistive technology software and usage of Java Access Bridge API and which can be tested using the manual test case attached to the issue in JBS. However the regression test still allows to reproduce the issue and verify that the fix resolves it.
>> 
>> Thank you,
>> Anton
>
> Anton Litvinov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The third version of the fix for JDK-8277922

The new approach by returning no accessible action looks cleaner. It resolves the ambiguity where the user of the API could get the accessible context of the cell renderer directly, in which case the accessible action cannot be performed because there's no way for the renderer to determine to which cell the action applies.

src/java.desktop/share/classes/javax/swing/JTable.java line 8417:

> 8415:                 if (ac != null) {
> 8416:                     return ac.getAccessibleAction();
> 8417:                 }

This is the fix for possible NPE, right?

test/jdk/javax/accessibility/JTable/BooleanRendererHasAccessibleActionTest.java line 48:

> 46: import javax.swing.table.TableCellRenderer;
> 47: 
> 48: public class BooleanRendererHasAccessibleActionTest {

Would `BooleanRendererHasNoAccessibleActionTest` be a better name? After all, you test for *no* accessible action.

test/jdk/javax/accessibility/JTable/BooleanRendererHasAccessibleActionTest.java line 50:

> 48: public class BooleanRendererHasAccessibleActionTest {
> 49:     private volatile JFrame frame;
> 50:     private volatile JTable table;

Neither `frame` nor `table` are accessed from any other thread but EDT, I believe `volatile` isn't necessary in this case.

test/jdk/javax/accessibility/JTable/BooleanRendererHasAccessibleActionTest.java line 142:

> 140: 
> 141:     private void testAccessibleActionInCellRenderer(int row, int column,
> 142:             boolean shouldBeNull) {

Since `shouldBeNull` is always `true`, I propose to drop it.

test/jdk/javax/accessibility/JTable/BooleanRendererHasAccessibleActionTest.java line 143:

> 141:     private void testAccessibleActionInCellRenderer(int row, int column,
> 142:             boolean shouldBeNull) {
> 143:         System.out.println(String.format(

I suggest using `System.out.printf`, just add `"\n"` to the end of format string.

test/jdk/javax/accessibility/JTable/BooleanRendererHasAccessibleActionTest.java line 161:

> 159:         AccessibleAction cellRendererAa = cellRendererAc.getAccessibleAction();
> 160:         if ((shouldBeNull && (cellRendererAa != null)) ||
> 161:             (!shouldBeNull && (cellRendererAa == null))) {

If `shouldBeNull` is dropped from parameters, this condition can be simplified to
Suggestion:

        if (cellRendererAa != null)) {


And the error message below should say _'cellRendererAa' is not null_.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7416


From aivanov at openjdk.java.net  Wed Mar  9 23:15:44 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 9 Mar 2022 23:15:44 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v3]
In-Reply-To: <6pGT5DmJQoDUOkO7uGHHh3DgPrtciQWTerAigWPh4-4=.85547921-1017-438c-9af4-7e3b90c06bb2@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <6pGT5DmJQoDUOkO7uGHHh3DgPrtciQWTerAigWPh4-4=.85547921-1017-438c-9af4-7e3b90c06bb2@github.com>
Message-ID: <84CRVdUD0owliNUkY7i0JQBU6HqhtKvGdqrbdG0FOSM=.3e5b983c-0965-40c6-bd80-95d17c013f65@github.com>

On Wed, 9 Mar 2022 13:35:44 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> The two tests `ScreenCaptureGtkTest.java` and `HiDPIRobotScreenCaptureTest.java` under `java/awt/Robot/HiDPIScreenCapture` started to intermittently fail under Windows and Linux after the [recent changes](https://github.com/openjdk/jdk/commit/cc7cf81256ed4d74493472017b1c4df20fa2208a) made exclusively for the Linux `Robot` implementation.
>> 
>> `HiDPIRobotScreenCaptureTest.java`
>> Since the Windows failures cannot possibly have their origin in the fix made - the latter being Linux-only - the test apparently either exposes an existing bug in the Windows `Robot` or is bumping against a peculiarity of that platform. The test is reverted back to its original form that didn't fail.
>> 
>> `ScreenCaptureGtkTest.java`
>> The coordinates in the log `(83, 78)` of a failure are higher up than the test suggests `(83, 97)`. I've seen similar failures on Ubuntu 20.04 when the coordinates were set to `(0, 0)`. The color then picked matched the color of the bar drawn at the top of the screen. I believe it's best to place the test pixels towards the center of the window to avoid desktop elements interference.
>> 
>> The other possible reason for intermittent failures are window coordinates. Suppose that the test is executing with `sun.java2d.uiScale` set to 2. This effectively means that it can only pick colors of pixels at even coordinates (in the absolute desktop space). So if the window is placed at, say, `(201, 201)`, `Robot` can only pick the color at either `(200, 200)` or `(202, 202)`. Since the test only makes sense if it is pixel-accurate, I removed all `@run`s with `sun.java2d.uiScale` other than 1. This way window placement will not cause a failure.
>> 
>> This was tested on Ubuntu 20.04 and 18.04 with desktop scaling set to 100%, 200%, and 300%.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   HiDPIRobotScreenCaptureTest.java: smaller frame size such that it fits on a 1200x600 screen.
>   
>   ScreenCaptureGtkTest.java: smaller frame size; added code to save
>   the image on failure.

ScreenCaptureGtkTest failed when it was run with `-Djdk.gtk.version=2 -Dsun.java2d.uiScale=3` options:


----------messages:(5/317)----------
command: main -Djdk.gtk.version=2 -Dsun.java2d.uiScale=3 ScreenCaptureGtkTest
...
----------System.out:(1/128)----------
Checking color at 83, 78 to be equal to java.awt.Color[r=0,g=255,b=0]...
Mismatch: found java.awt.Color[r=54,g=52,b=58] instead
----------System.err:(13/786)----------
Gtk-Message: 20:23:41.357: Failed to load module "canberra-gtk-module"
java.lang.RuntimeException: Wrong screen pixel color
	at ScreenCaptureGtkTest.checkPixelColors(ScreenCaptureGtkTest.java:127)
	at ScreenCaptureGtkTest.main(ScreenCaptureGtkTest.java:101)


The regular screenshot shows nothing: the image is filled with green with three pixel dots.

However, multi-resolution screenshot reveals something (the image is zoomed):
![MRI screenshot zoomed](https://user-images.githubusercontent.com/70774172/157537522-2d61eda5-d499-4a23-8a28-083c19bf4079.png)

The first pixel line above is part of the background image. The robot seems to pick it up it instead of the correct pixel.

The host where the test fails is Ubuntu 18.04.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From joehw at openjdk.java.net  Thu Mar 10 00:46:44 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 10 Mar 2022 00:46:44 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <8oYKi_L4IgNDFUfJ9uXlSl47KULO4j1HudfJg3kVeCU=.90fa019e-8b6f-4a69-870b-cd53c8802490@github.com>

On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung <achung at openjdk.org> wrote:

> msg drop for jdk19, Mar 9, 2022

For the bundles in java.xml:

For files with Oracle copyright, update the year to 2022 and @LastModified Mar 2022. Take XPATHErrorResources_ja.java as an example, the copyright year was updated to 2021 and @LastModified: Nov 2021. That's probably the date it was last modified, but as we updating them now along with a number of other files, it would be good to be consistent and change all of them to the current date.

For files with the reserved comment block such as SerializerMessages_de.java, do the same as did in XPATHErrorResources_de.java, add the copyright header and LastModified tag with the current date. 

For files with the Oracle GPL license such as message_zh_CN.properties, do not delete the license header. Instead, update the copyright year to 2022 if there are changes. I don't see any changes were made for many of these files, for example from msg/XMLSchemaMessages_ja.properties to regex/message_zh_CN.properties, the only change was the removal of the header.

In the webrev view, some files have the word "undefined" right under the license header, hopefully once the license header is fixed, that would go away as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7765


From prr at openjdk.java.net  Thu Mar 10 01:46:37 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 10 Mar 2022 01:46:37 GMT
Subject: RFR: 8282577: ICC_Profile.setData(int,
 byte[]) invalidates the profile [v3]
In-Reply-To: <XTG2b5zZA9u3_Km2pJCA3xCsJzJl_tjOfnXGNunixgY=.c92ea820-38bc-4668-b8cc-350915a6fc7a@github.com>
References: <ecPAoejPCnfczdYoQmH89792PmRZxg4Rc5LaEHlsnXo=.3ad1b170-e862-4322-9164-df0501b298a0@github.com>
 <XTG2b5zZA9u3_Km2pJCA3xCsJzJl_tjOfnXGNunixgY=.c92ea820-38bc-4668-b8cc-350915a6fc7a@github.com>
Message-ID: <Z-61yWMCmOPBC8Xi_KRwzlpo_cu-bsJGm6jz82Dc-54=.ebb8fbbc-ae73-4184-bc7b-04c1675ea33c@github.com>

On Thu, 3 Mar 2022 21:27:36 GMT, Phil Race <prr at openjdk.org> wrote:

>> As per the bug eval, we are returning a pointer to a native raw LittleCMS profile and it should be a cooked one.
>> The simple test fails before the fix with
>> ~/jdk17/Contents/Home/bin/java SetTagDataValidation                               
>> Exception in thread "main" java.awt.color.CMMException: LCMS error 13: Couldn't link the profiles
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createNativeTransform(Native Method)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createTransform(LCMS.java:104)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.doTransform(LCMSTransform.java:143)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.colorConvert(LCMSTransform.java:633)
>> 	at java.desktop/java.awt.color.ICC_ColorSpace.toRGB(ICC_ColorSpace.java:224)
>> 	at SetTagDataValidation.main(SetTagDataValidation.java:61)
>> 
>> and with the fix  just prints 
>> java SetTagDataValidation
>> 0.4
>> 0.5000076
>> 0.6
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282577: ICC_Profile.setData(int, byte[]) invalidates the profile

I'm not sure if everything in that github issue is 100% accurate or understood by me but Marti's point is

So you use RAW functions in copyProfile() and then access them using cmsReadTag in test().
This is the case described in the manual.

> If we will create a new profile it will not be possible to use it by the ColorTransform,
> because the LCMS will call cmsReadTag under the hood.

Well this seems to have been the long-standing bug I am trying to fix - because we
copied a profile and what we *returned* is not the result of
"you will need to dump the profile to memory or disk and then reopen it."

The new code does that and so it works.

> But even if it will work the content of the tag will be changed.

Yes, any tags that are read by the implementation (or by the client) *may* be changed.

I am saying that if our "pfSanity" test profile did not call cmsReadTag() and returned
pfSanity directly - or directly called cmsReadRawTag() - it will get back the same
data it set. We don't want to "skip" that sanity since it is what tells use we want
to throw IAE. So just "recreate" the profile. Then ReadWriteProfileTest will be happy
*so long* as it does its comparisons BEFORE trying a ColorConvertOp.

There is nothing I can do to fix that short of us maintaining a Java level cache
of all the raw tags and never asking the CMM for any data that may have been cooked
and serialised. That might work too but I am not sure it is important enough to try.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7668


From duke at openjdk.java.net  Thu Mar 10 02:49:14 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Thu, 10 Mar 2022 02:49:14 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell.
Message-ID: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>

Previously while tabbing through the JTable cell, the cell highlighter/focus ring was not visible against the selection background. 

Changes were made to Aqua LAF to derive a brighter focus ring color by changing hue, saturation and brightness of selection background color so that it is visible while tabbing through JTable cells. 

A test case is added to compare the RGB difference between the original focus ring color & selection background and the brighter focus ring color & selection background.

-------------

Commit messages:
 - Cell Focus Ring Changes for Aqua LAF

Changes: https://git.openjdk.java.net/jdk/pull/7768/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7768&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-7124282
  Stats: 197 lines in 2 files changed: 195 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7768/head:pull/7768

PR: https://git.openjdk.java.net/jdk/pull/7768


From prr at openjdk.java.net  Thu Mar 10 04:15:14 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 10 Mar 2022 04:15:14 GMT
Subject: RFR: 8282577: ICC_Profile.setData(int,
 byte[]) invalidates the profile [v4]
In-Reply-To: <ecPAoejPCnfczdYoQmH89792PmRZxg4Rc5LaEHlsnXo=.3ad1b170-e862-4322-9164-df0501b298a0@github.com>
References: <ecPAoejPCnfczdYoQmH89792PmRZxg4Rc5LaEHlsnXo=.3ad1b170-e862-4322-9164-df0501b298a0@github.com>
Message-ID: <C2-ER2XdjF99O4ZdwRHmP8Lx1VKry4_ip0hCxR-0Sb4=.50b124da-464b-4c7e-a649-7203cb0ec509@github.com>

> As per the bug eval, we are returning a pointer to a native raw LittleCMS profile and it should be a cooked one.
> The simple test fails before the fix with
> ~/jdk17/Contents/Home/bin/java SetTagDataValidation                               
> Exception in thread "main" java.awt.color.CMMException: LCMS error 13: Couldn't link the profiles
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createNativeTransform(Native Method)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createTransform(LCMS.java:104)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.doTransform(LCMSTransform.java:143)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.colorConvert(LCMSTransform.java:633)
> 	at java.desktop/java.awt.color.ICC_ColorSpace.toRGB(ICC_ColorSpace.java:224)
> 	at SetTagDataValidation.main(SetTagDataValidation.java:61)
> 
> and with the fix  just prints 
> java SetTagDataValidation
> 0.4
> 0.5000076
> 0.6

Phil Race has updated the pull request incrementally with two additional commits since the last revision:

 - 8282577: ICC_Profile.setData(int, byte[]) invalidates the profile
 - 8282577: ICC_Profile.setData(int, byte[]) invalidates the profile

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7668/files
  - new: https://git.openjdk.java.net/jdk/pull/7668/files/5bf31b11..29c836ac

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7668&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7668&range=02-03

  Stats: 25 lines in 3 files changed: 11 ins; 9 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7668.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7668/head:pull/7668

PR: https://git.openjdk.java.net/jdk/pull/7668


From prr at openjdk.java.net  Thu Mar 10 04:20:37 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 10 Mar 2022 04:20:37 GMT
Subject: RFR: 8282577: ICC_Profile.setData(int,
 byte[]) invalidates the profile [v4]
In-Reply-To: <C2-ER2XdjF99O4ZdwRHmP8Lx1VKry4_ip0hCxR-0Sb4=.50b124da-464b-4c7e-a649-7203cb0ec509@github.com>
References: <ecPAoejPCnfczdYoQmH89792PmRZxg4Rc5LaEHlsnXo=.3ad1b170-e862-4322-9164-df0501b298a0@github.com>
 <C2-ER2XdjF99O4ZdwRHmP8Lx1VKry4_ip0hCxR-0Sb4=.50b124da-464b-4c7e-a649-7203cb0ec509@github.com>
Message-ID: <ss0meG82jGNicko-z0lvj_BdMKXC_14PSOGpCFobwZM=.362d4303-b9af-4e7c-bb15-5f59b00257e6@github.com>

On Thu, 10 Mar 2022 04:15:14 GMT, Phil Race <prr at openjdk.org> wrote:

>> As per the bug eval, we are returning a pointer to a native raw LittleCMS profile and it should be a cooked one.
>> The simple test fails before the fix with
>> ~/jdk17/Contents/Home/bin/java SetTagDataValidation                               
>> Exception in thread "main" java.awt.color.CMMException: LCMS error 13: Couldn't link the profiles
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createNativeTransform(Native Method)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createTransform(LCMS.java:104)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.doTransform(LCMSTransform.java:143)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.colorConvert(LCMSTransform.java:633)
>> 	at java.desktop/java.awt.color.ICC_ColorSpace.toRGB(ICC_ColorSpace.java:224)
>> 	at SetTagDataValidation.main(SetTagDataValidation.java:61)
>> 
>> and with the fix  just prints 
>> java SetTagDataValidation
>> 0.4
>> 0.5000076
>> 0.6
>
> Phil Race has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8282577: ICC_Profile.setData(int, byte[]) invalidates the profile
>  - 8282577: ICC_Profile.setData(int, byte[]) invalidates the profile

This latest commit allows ReadWriteProfileTest.java to pass again.
But a more sophisticated test that triggers use of the profile before doing the comparison would, I expect, still fail.
Basically the value proposition of this entire change is that if "setData(tag, data)" works it should result in a profile that works.
The results of querying the data back again are secondary. 
Maybe we should have a spec. update but we can't backport that and this should bake first anyway.
I am not sure the value of the get/set is worth it. I suspect there's been minimal use of these APIs ever else we'd have had complaints about how it hasn't worked since JDK 7 ..

-------------

PR: https://git.openjdk.java.net/jdk/pull/7668


From serb at openjdk.java.net  Thu Mar 10 04:25:36 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 10 Mar 2022 04:25:36 GMT
Subject: RFR: 8282577: ICC_Profile.setData(int,
 byte[]) invalidates the profile [v4]
In-Reply-To: <C2-ER2XdjF99O4ZdwRHmP8Lx1VKry4_ip0hCxR-0Sb4=.50b124da-464b-4c7e-a649-7203cb0ec509@github.com>
References: <ecPAoejPCnfczdYoQmH89792PmRZxg4Rc5LaEHlsnXo=.3ad1b170-e862-4322-9164-df0501b298a0@github.com>
 <C2-ER2XdjF99O4ZdwRHmP8Lx1VKry4_ip0hCxR-0Sb4=.50b124da-464b-4c7e-a649-7203cb0ec509@github.com>
Message-ID: <MLtSQu_ARTw2KsH_-3PItgsK_JENvGpdZb8gFNf8iwE=.aa4a2172-b179-4fc3-b497-585af0af5f23@github.com>

On Thu, 10 Mar 2022 04:15:14 GMT, Phil Race <prr at openjdk.org> wrote:

>> As per the bug eval, we are returning a pointer to a native raw LittleCMS profile and it should be a cooked one.
>> The simple test fails before the fix with
>> ~/jdk17/Contents/Home/bin/java SetTagDataValidation                               
>> Exception in thread "main" java.awt.color.CMMException: LCMS error 13: Couldn't link the profiles
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createNativeTransform(Native Method)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createTransform(LCMS.java:104)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.doTransform(LCMSTransform.java:143)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.colorConvert(LCMSTransform.java:633)
>> 	at java.desktop/java.awt.color.ICC_ColorSpace.toRGB(ICC_ColorSpace.java:224)
>> 	at SetTagDataValidation.main(SetTagDataValidation.java:61)
>> 
>> and with the fix  just prints 
>> java SetTagDataValidation
>> 0.4
>> 0.5000076
>> 0.6
>
> Phil Race has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8282577: ICC_Profile.setData(int, byte[]) invalidates the profile
>  - 8282577: ICC_Profile.setData(int, byte[]) invalidates the profile

src/java.desktop/share/native/liblcms/LCMS.c line 745:

> 743:                 pfSanity = cmsOpenProfileFromMem(buf, pfSize);
> 744:             }
> 745:             //free(buf);

Can be removed?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7668


From duke at openjdk.java.net  Thu Mar 10 04:32:07 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Thu, 10 Mar 2022 04:32:07 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage
Message-ID: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>

Removed the println() line from the Interrupted catch block. Since waitForID() Interrupt indicates completion of Image Loading, println as Interrupt handling was not required.

-------------

Commit messages:
 - 8236987: Remove call to System.out.println from ImageIcon.loadImage
 - 8236987: Remove call to System.out.println from ImageIcon.loadImage
 - Merge branch 'master' of github.com:TejeshR13/jdk
 - Initial Commit.

Changes: https://git.openjdk.java.net/jdk/pull/7754/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7754&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8236987
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7754.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7754/head:pull/7754

PR: https://git.openjdk.java.net/jdk/pull/7754


From prr at openjdk.java.net  Thu Mar 10 04:32:41 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 10 Mar 2022 04:32:41 GMT
Subject: RFR: 8282577: ICC_Profile.setData(int,
 byte[]) invalidates the profile [v4]
In-Reply-To: <C2-ER2XdjF99O4ZdwRHmP8Lx1VKry4_ip0hCxR-0Sb4=.50b124da-464b-4c7e-a649-7203cb0ec509@github.com>
References: <ecPAoejPCnfczdYoQmH89792PmRZxg4Rc5LaEHlsnXo=.3ad1b170-e862-4322-9164-df0501b298a0@github.com>
 <C2-ER2XdjF99O4ZdwRHmP8Lx1VKry4_ip0hCxR-0Sb4=.50b124da-464b-4c7e-a649-7203cb0ec509@github.com>
Message-ID: <E7LcK5cVv_ix0enoNOopL8fhHQeMG7yNlglfGixdVes=.ef224466-fdc7-4afd-9a9e-34159df0691f@github.com>

On Thu, 10 Mar 2022 04:15:14 GMT, Phil Race <prr at openjdk.org> wrote:

>> As per the bug eval, we are returning a pointer to a native raw LittleCMS profile and it should be a cooked one.
>> The simple test fails before the fix with
>> ~/jdk17/Contents/Home/bin/java SetTagDataValidation                               
>> Exception in thread "main" java.awt.color.CMMException: LCMS error 13: Couldn't link the profiles
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createNativeTransform(Native Method)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createTransform(LCMS.java:104)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.doTransform(LCMSTransform.java:143)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.colorConvert(LCMSTransform.java:633)
>> 	at java.desktop/java.awt.color.ICC_ColorSpace.toRGB(ICC_ColorSpace.java:224)
>> 	at SetTagDataValidation.main(SetTagDataValidation.java:61)
>> 
>> and with the fix  just prints 
>> java SetTagDataValidation
>> 0.4
>> 0.5000076
>> 0.6
>
> Phil Race has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8282577: ICC_Profile.setData(int, byte[]) invalidates the profile
>  - 8282577: ICC_Profile.setData(int, byte[]) invalidates the profile

> Can be removed? 

I did .. seconds after I pushed when I noticed it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7668


From serb at openjdk.java.net  Thu Mar 10 05:12:45 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 10 Mar 2022 05:12:45 GMT
Subject: RFR: 8282577: ICC_Profile.setData(int,
 byte[]) invalidates the profile [v4]
In-Reply-To: <C2-ER2XdjF99O4ZdwRHmP8Lx1VKry4_ip0hCxR-0Sb4=.50b124da-464b-4c7e-a649-7203cb0ec509@github.com>
References: <ecPAoejPCnfczdYoQmH89792PmRZxg4Rc5LaEHlsnXo=.3ad1b170-e862-4322-9164-df0501b298a0@github.com>
 <C2-ER2XdjF99O4ZdwRHmP8Lx1VKry4_ip0hCxR-0Sb4=.50b124da-464b-4c7e-a649-7203cb0ec509@github.com>
Message-ID: <TVYrBflX5HRf4wug5r4qNRzBPvInDVerAWXqpyzsIZk=.3716b18a-02c1-42d4-8ad3-0a040fdf6d30@github.com>

On Thu, 10 Mar 2022 04:15:14 GMT, Phil Race <prr at openjdk.org> wrote:

>> As per the bug eval, we are returning a pointer to a native raw LittleCMS profile and it should be a cooked one.
>> The simple test fails before the fix with
>> ~/jdk17/Contents/Home/bin/java SetTagDataValidation                               
>> Exception in thread "main" java.awt.color.CMMException: LCMS error 13: Couldn't link the profiles
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createNativeTransform(Native Method)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createTransform(LCMS.java:104)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.doTransform(LCMSTransform.java:143)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.colorConvert(LCMSTransform.java:633)
>> 	at java.desktop/java.awt.color.ICC_ColorSpace.toRGB(ICC_ColorSpace.java:224)
>> 	at SetTagDataValidation.main(SetTagDataValidation.java:61)
>> 
>> and with the fix  just prints 
>> java SetTagDataValidation
>> 0.4
>> 0.5000076
>> 0.6
>
> Phil Race has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8282577: ICC_Profile.setData(int, byte[]) invalidates the profile
>  - 8282577: ICC_Profile.setData(int, byte[]) invalidates the profile

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7668


From duke at openjdk.java.net  Thu Mar 10 05:12:46 2022
From: duke at openjdk.java.net (Rajat Mahajan)
Date: Thu, 10 Mar 2022 05:12:46 GMT
Subject: Integrated: 8249592 : Robot.mouseMove moves cursor to incorrect
 location when display scale varies and Java runs in DPI Unaware mode
In-Reply-To: <7SyMjVox8LbT2ZqI1n0fj8nwb3YsCXfrap6VuGtNVbc=.e8c0bd94-c477-4a69-839f-25e7b3d31f7d@github.com>
References: <7SyMjVox8LbT2ZqI1n0fj8nwb3YsCXfrap6VuGtNVbc=.e8c0bd94-c477-4a69-839f-25e7b3d31f7d@github.com>
Message-ID: <cz621bcJwup9YVIqzBkofciRY9EpvIaZzUDuZuTf93U=.10641fa2-78cf-4e2c-8da8-5b7e3ba7c3c5@github.com>

On Mon, 7 Mar 2022 23:47:42 GMT, Rajat Mahajan <duke at openjdk.java.net> wrote:

> 8249592 : Robot.mouseMove moves cursor to incorrect location when display scale varies and Java runs in DPI Unaware mode

This pull request has now been integrated.

Changeset: 8aba4de9
Author:    Rajat Mahajan <rajat.m.mahajan at oracle.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8aba4de98477a3bcfcde8db71e0d797965f774c7
Stats:     26 lines in 1 file changed: 18 ins; 5 del; 3 mod

8249592: Robot.mouseMove moves cursor to incorrect location when display scale varies and Java runs in DPI Unaware mode

Reviewed-by: serb, aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/7736


From serb at openjdk.java.net  Thu Mar 10 05:23:45 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 10 Mar 2022 05:23:45 GMT
Subject: RFR: 8277922: Unable to click JCheckBox in JTable through Java
 Access Bridge [v3]
In-Reply-To: <Vz4HgwEIrd3001wrGJ2-Vt55yX-YU8pfKgkw3qrb3Rc=.06e4fa2a-e91b-489d-af57-50499468371a@github.com>
References: <68JPxsadS5K_WkQgEkMdD_qCt1DWBpBVHV23b0oQKGU=.0b4e520a-205d-4cf1-b506-dd48616ebece@github.com>
 <Vz4HgwEIrd3001wrGJ2-Vt55yX-YU8pfKgkw3qrb3Rc=.06e4fa2a-e91b-489d-af57-50499468371a@github.com>
Message-ID: <09kuxnFMQVyhE8r2Pi9kStPdBp41_-3d6QXN5COc1z0=.e50ae23f-5576-47eb-bd4a-b0c7daa28d49@github.com>

On Wed, 9 Mar 2022 16:11:02 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

>> Hello,
>> 
>> Could you please review the following fix for the bug. The bug consists in the fact that When an assistive technology software by means of Java Access Bridge API executes "AccessibleAction" "click" on "AccessibleContext" which corresponds to "javax.swing.JTable" cell containing "javax.swing.JCheckBox", then the cell's value and cell's view represented by "JCheckBox" stay unchanged. The issue is a bug in JDK and should be fixed in JDK, because JDK informs the assistive technology software through Java Access Bridge API in particular through the function
>> 
>> "BOOL getAccessibleActions(long vmID, AccessibleContext accessibleContext, AccessibleActions *actions)"
>> 
>> that "AccessibleContext" of the table cell with "JCheckBox" supports one action "click", while real execution of this action on this accessible context does not lead to any result.
>> 
>> THE ROOT CAUSE OF THE BUG:
>> 
>> The reason of the issue is the fact that when the assistive technology software tries to do "AccessibleAction" on "AccessibleContext" associated with a cell with boolean data type in "JTable" component through Java Access Bridge (JAB), the JDK executes this "AccessibleAction" on "AccessibleContext" of a renderer, which is an instance of the class "javax.swing.JTable.BooleanRenderer" which is a derivative of "JCheckBox" class, and the instance of this renderer is single and common for all cells of boolean data type. Therefore execution of "click" "AccessibleAction" on this renderer component which is not permanently bound to any particular cell in the table does not lead to update of the table cell value.
>> 
>> THE FIX:
>> 
>> The fix implements an approach which guarantees setting of new values to the table's cells with boolean data type on each execution of "AccessibleAction" of "javax.swing.JTable.BooleanRenderer" instance, when execution of this action changes the "selected" state of this "BooleanRenderer" JCheckBox component.
>> 
>> Please take into account that the created automatic regression test simulates the issue only with Java Accessibility API what is not fully equal to the original test scenario which requires the assistive technology software and usage of Java Access Bridge API and which can be tested using the manual test case attached to the issue in JBS. However the regression test still allows to reproduce the issue and verify that the fix resolves it.
>> 
>> Thank you,
>> Anton
>
> Anton Litvinov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The third version of the fix for JDK-8277922

The last version looks fine to me.

-------------

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7416


From serb at openjdk.java.net  Thu Mar 10 05:24:49 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 10 Mar 2022 05:24:49 GMT
Subject: RFR: 8264666: Reuse Math.multiplyExact/addExact in the
 LCMSImageLayout class
In-Reply-To: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
References: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
Message-ID: <2mHa1XhAV5i0fzCgFcqfgON-H1ZdVr2zd2sXtsda1SQ=.6eb1556b-4ca0-460d-8e30-bb4d99f365cf@github.com>

On Fri, 2 Apr 2021 23:02:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> - The hand-crafted methods for addition and multiplication are replaced by the "Math" versions.
> - Cleanup: the usage of do/while(false) is removed

not now

-------------

PR: https://git.openjdk.java.net/jdk/pull/3333


From serb at openjdk.java.net  Thu Mar 10 05:26:42 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 10 Mar 2022 05:26:42 GMT
Subject: RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese
 characters were garbled [v5]
In-Reply-To: <bvGn8F7PAOMCJr3X5ztXNN8t9F7yk_GFjJzntQbIemA=.28ce4f93-8d23-40de-b4fa-a74e134e647e@github.com>
References: <JM1ajWFlO67nrSxj3JOiLZ1h4l-IVFkZVI1kf4nd3vo=.cae6dc96-15a2-4856-a2b9-352492a41bbb@github.com>
 <bvGn8F7PAOMCJr3X5ztXNN8t9F7yk_GFjJzntQbIemA=.28ce4f93-8d23-40de-b4fa-a74e134e647e@github.com>
Message-ID: <RUTPRCDjRYKurh6YQZrlU5us-LhwPFbfl_rkCFH_RxU=.bea62357-cc40-4469-b5c0-bf49fce2c5bb@github.com>

On Mon, 21 Feb 2022 05:12:44 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

>> Hi,
>> 
>> Could you review the fix?
>> When non-English characters were printed from JTable on MacOS, CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However, CTextPipe seems not support glyph with slot number of composite fonts.
>> 
>> The slot data mask of GlyphVector is 0xff000000. In my environment, Japanese font was loaded at slot 4, and glyph data is like [0x40003e5]. Then, unexpected glyph was drawn.
>
> Toshio Nakamura 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 11 additional commits since the last revision:
> 
>  - Deleting unused line
>  - Merge branch 'master' into 8240756
>  - Revised according to review comments
>  - Merge branch 'master' into 8240756
>  - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled
>  - revert previous proposal
>  - Merge branch 'master' into 8240756
>  - 2nd proposal
>  - Revert previous change
>  - Merge branch 'master' into 8240756
>    merge master
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/c0abfff5...b623a123

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3619


From psadhukhan at openjdk.java.net  Thu Mar 10 09:27:47 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 10 Mar 2022 09:27:47 GMT
Subject: Integrated: 7017094: ParsedSynthStyle: parameter name "direction"
 should be changed to "tabIndex"
In-Reply-To: <VwlUM4QDKOnh4_pNaV2cwYvW8zqI0HyAc8nYqaBYgyY=.bc90ec24-8575-4e02-810f-2cd14914caa3@github.com>
References: <VwlUM4QDKOnh4_pNaV2cwYvW8zqI0HyAc8nYqaBYgyY=.bc90ec24-8575-4e02-810f-2cd14914caa3@github.com>
Message-ID: <THkInjIueAQwaozAnpPGVFlev1aHPhTD9m9ZS8_pIPM=.fd0ce636-ed07-4d37-a4b9-e81d4c38bdb2@github.com>

On Mon, 21 Feb 2022 04:59:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> [SynthPainter](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthPainter.java#L1759)
> and 
> [SynthPainterImpl](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/nimbus/SynthPainterImpl.java#L2074)
> expects a "tabIndex" although the parameter is not used currently.

This pull request has now been integrated.

Changeset: 5b78a82e
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5b78a82e9d4b73e5bf3c6e099564206ecbda889b
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

7017094: ParsedSynthStyle: parameter name "direction" should be changed to "tabIndex"

Reviewed-by: jdv, aivanov, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/7551


From psadhukhan at openjdk.java.net  Thu Mar 10 09:30:45 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 10 Mar 2022 09:30:45 GMT
Subject: Integrated: 6218162: DefaultTableColumnModel.getColumn() method should
 mention ArrayIndexOutOfBoundsException
In-Reply-To: <KYDs0LbJF3OqE_Wncy3XvCymxYe5dHfrN9PQXkXCEYE=.2e310ed0-910f-433c-93a3-e1f691f2131b@github.com>
References: <KYDs0LbJF3OqE_Wncy3XvCymxYe5dHfrN9PQXkXCEYE=.2e310ed0-910f-433c-93a3-e1f691f2131b@github.com>
Message-ID: <legNf6TBzZPG5tf6eEu2NDMhtp_gpNJ9Y2Gk0LrCWoo=.b99b4041-b5ad-41f8-ad49-f4577f8d7a89@github.com>

On Wed, 23 Feb 2022 11:20:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> If invalid ie 0 or > getColumnCount() index is passed to DefaultTableColumnModel.getColumn() then it returns AIOBE in current implementation which should be documented in the spec. Fixed the spec to mention the exception.

This pull request has now been integrated.

Changeset: 6a3a7b94
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6a3a7b94a4c342ce12ad553f1ba2818ca3a77f36
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

6218162: DefaultTableColumnModel.getColumn() method should mention ArrayIndexOutOfBoundsException

Reviewed-by: aivanov, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/7587


From duke at openjdk.java.net  Thu Mar 10 09:33:45 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Thu, 10 Mar 2022 09:33:45 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v3]
In-Reply-To: <6pGT5DmJQoDUOkO7uGHHh3DgPrtciQWTerAigWPh4-4=.85547921-1017-438c-9af4-7e3b90c06bb2@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <6pGT5DmJQoDUOkO7uGHHh3DgPrtciQWTerAigWPh4-4=.85547921-1017-438c-9af4-7e3b90c06bb2@github.com>
Message-ID: <Hk_E7llMFY1wtI-3XuTwcAC8hwuZxCTdswgjp1u_p6Y=.83f1db0a-c2cb-4161-9712-09c4a94359df@github.com>

On Wed, 9 Mar 2022 13:35:44 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> The two tests `ScreenCaptureGtkTest.java` and `HiDPIRobotScreenCaptureTest.java` under `java/awt/Robot/HiDPIScreenCapture` started to intermittently fail under Windows and Linux after the [recent changes](https://github.com/openjdk/jdk/commit/cc7cf81256ed4d74493472017b1c4df20fa2208a) made exclusively for the Linux `Robot` implementation.
>> 
>> `HiDPIRobotScreenCaptureTest.java`
>> Since the Windows failures cannot possibly have their origin in the fix made - the latter being Linux-only - the test apparently either exposes an existing bug in the Windows `Robot` or is bumping against a peculiarity of that platform. The test is reverted back to its original form that didn't fail.
>> 
>> `ScreenCaptureGtkTest.java`
>> The coordinates in the log `(83, 78)` of a failure are higher up than the test suggests `(83, 97)`. I've seen similar failures on Ubuntu 20.04 when the coordinates were set to `(0, 0)`. The color then picked matched the color of the bar drawn at the top of the screen. I believe it's best to place the test pixels towards the center of the window to avoid desktop elements interference.
>> 
>> The other possible reason for intermittent failures are window coordinates. Suppose that the test is executing with `sun.java2d.uiScale` set to 2. This effectively means that it can only pick colors of pixels at even coordinates (in the absolute desktop space). So if the window is placed at, say, `(201, 201)`, `Robot` can only pick the color at either `(200, 200)` or `(202, 202)`. Since the test only makes sense if it is pixel-accurate, I removed all `@run`s with `sun.java2d.uiScale` other than 1. This way window placement will not cause a failure.
>> 
>> This was tested on Ubuntu 20.04 and 18.04 with desktop scaling set to 100%, 200%, and 300%.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   HiDPIRobotScreenCaptureTest.java: smaller frame size such that it fits on a 1200x600 screen.
>   
>   ScreenCaptureGtkTest.java: smaller frame size; added code to save
>   the image on failure.

The `ScreenCaptureGtkTest` is not supposed to be run with `-Dsun.java2d.uiScale=3` anymore as we've discovered the problem with precise window positioning. Let's try this test from [my branch](https://github.com/mkartashev/jdk/tree/JDK-8282270).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From tnakamura at openjdk.java.net  Thu Mar 10 09:46:39 2022
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Thu, 10 Mar 2022 09:46:39 GMT
Subject: RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese
 characters were garbled
In-Reply-To: <4lgBU_G-xdIAebIcknY7c3Xg8BeWIVkLaWv6YlDSv1o=.37bf8684-d954-4dfb-8348-8d0a89464a38@github.com>
References: <JM1ajWFlO67nrSxj3JOiLZ1h4l-IVFkZVI1kf4nd3vo=.cae6dc96-15a2-4856-a2b9-352492a41bbb@github.com>
 <4lgBU_G-xdIAebIcknY7c3Xg8BeWIVkLaWv6YlDSv1o=.37bf8684-d954-4dfb-8348-8d0a89464a38@github.com>
Message-ID: <ipfBh8q60iDxQYtenLprmLcr-lmFdM4fFi1gCCLz8BA=.a4318c0d-af1f-424d-aac1-fd24ce8bc0aa@github.com>

On Fri, 23 Apr 2021 06:49:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Hi,
>> 
>> Could you review the fix?
>> When non-English characters were printed from JTable on MacOS, CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However, CTextPipe seems not support glyph with slot number of composite fonts.
>> 
>> The slot data mask of GlyphVector is 0xff000000. In my environment, Japanese font was loaded at slot 4, and glyph data is like [0x40003e5]. Then, unexpected glyph was drawn.
>
> As far as I understand it is not directly related to the JTable and the bug is reproduced if some specific font is used when any text is printed? Did you check why the CTextPipe does not support it directly? It looks like the JavaCT_DrawGlyphVector uses pure core graphics, which I think should support this font?

@mrserb  Thank you for the review.

@mrserb @prrace Could you sponsor this fix?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3619


From dfuchs at openjdk.java.net  Thu Mar 10 10:34:43 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 10 Mar 2022 10:34:43 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <p1RcBIafcDBf0k6FeY60oiHc94CG5wc5mJMDaNAO7js=.1bce7a1c-81cd-475d-bcbb-4423a5040b6b@github.com>

On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung <achung at openjdk.org> wrote:

> msg drop for jdk19, Mar 9, 2022

For simple webserver resource files - should the copyright year be 2022?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7765


From aivanov at openjdk.java.net  Thu Mar 10 11:07:46 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 10 Mar 2022 11:07:46 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v3]
In-Reply-To: <Hk_E7llMFY1wtI-3XuTwcAC8hwuZxCTdswgjp1u_p6Y=.83f1db0a-c2cb-4161-9712-09c4a94359df@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <6pGT5DmJQoDUOkO7uGHHh3DgPrtciQWTerAigWPh4-4=.85547921-1017-438c-9af4-7e3b90c06bb2@github.com>
 <Hk_E7llMFY1wtI-3XuTwcAC8hwuZxCTdswgjp1u_p6Y=.83f1db0a-c2cb-4161-9712-09c4a94359df@github.com>
Message-ID: <T8qDluwEX0V22Mi28c_W765hScdFGYikd5XsmfWU6qM=.bcd41809-344f-48fc-827a-c398cd92e1fb@github.com>

On Thu, 10 Mar 2022 09:30:33 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

> The `ScreenCaptureGtkTest` is not supposed to be run with `-Dsun.java2d.uiScale=3` anymore as we've discovered the problem with precise window positioning. Let's try this test from [my branch](https://github.com/mkartashev/jdk/tree/JDK-8282270).

I'll run them. However, the test passes successfully on the same host when the frame is smaller: 100?100 and 50?20. So it looks in both cases the reason for failure was that the frame was too large.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From duke at openjdk.java.net  Thu Mar 10 11:25:43 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Thu, 10 Mar 2022 11:25:43 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v3]
In-Reply-To: <6pGT5DmJQoDUOkO7uGHHh3DgPrtciQWTerAigWPh4-4=.85547921-1017-438c-9af4-7e3b90c06bb2@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <6pGT5DmJQoDUOkO7uGHHh3DgPrtciQWTerAigWPh4-4=.85547921-1017-438c-9af4-7e3b90c06bb2@github.com>
Message-ID: <AjXPovXtONhw81RyxSHYTlzz3h9z_spSVyqbRDRNTYM=.72af466a-c0bc-4567-b47c-cca03fa51940@github.com>

On Wed, 9 Mar 2022 13:35:44 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> The two tests `ScreenCaptureGtkTest.java` and `HiDPIRobotScreenCaptureTest.java` under `java/awt/Robot/HiDPIScreenCapture` started to intermittently fail under Windows and Linux after the [recent changes](https://github.com/openjdk/jdk/commit/cc7cf81256ed4d74493472017b1c4df20fa2208a) made exclusively for the Linux `Robot` implementation.
>> 
>> `HiDPIRobotScreenCaptureTest.java`
>> Since the Windows failures cannot possibly have their origin in the fix made - the latter being Linux-only - the test apparently either exposes an existing bug in the Windows `Robot` or is bumping against a peculiarity of that platform. The test is reverted back to its original form that didn't fail.
>> 
>> `ScreenCaptureGtkTest.java`
>> The coordinates in the log `(83, 78)` of a failure are higher up than the test suggests `(83, 97)`. I've seen similar failures on Ubuntu 20.04 when the coordinates were set to `(0, 0)`. The color then picked matched the color of the bar drawn at the top of the screen. I believe it's best to place the test pixels towards the center of the window to avoid desktop elements interference.
>> 
>> The other possible reason for intermittent failures are window coordinates. Suppose that the test is executing with `sun.java2d.uiScale` set to 2. This effectively means that it can only pick colors of pixels at even coordinates (in the absolute desktop space). So if the window is placed at, say, `(201, 201)`, `Robot` can only pick the color at either `(200, 200)` or `(202, 202)`. Since the test only makes sense if it is pixel-accurate, I removed all `@run`s with `sun.java2d.uiScale` other than 1. This way window placement will not cause a failure.
>> 
>> This was tested on Ubuntu 20.04 and 18.04 with desktop scaling set to 100%, 200%, and 300%.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   HiDPIRobotScreenCaptureTest.java: smaller frame size such that it fits on a 1200x600 screen.
>   
>   ScreenCaptureGtkTest.java: smaller frame size; added code to save
>   the image on failure.

The initial reason for `ScreenCaptureGtkTest` failure was that on Linux the window was *sometimes* positioned such that some of the pixels targeted by `Robot` couldn't be pointed to by the underlying GTK API. So these failures were intermittent and out of control of the test itself; change of the windows' size could've simply changed the window manager's logic for position calculation and thus accidentally made the test pass.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From psadhukhan at openjdk.java.net  Thu Mar 10 13:02:47 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 10 Mar 2022 13:02:47 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage
In-Reply-To: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
Message-ID: <x2z-m3Sq-k2cUBobgCe9KwHBgQFY3fvHa4ZpHld9GHA=.39ce100a-a89a-4247-a265-bf79508b7e1e@github.com>

On Wed, 9 Mar 2022 10:04:09 GMT, Tejesh R <duke at openjdk.java.net> wrote:

> Removed the println() line from the Interrupted catch block. Since waitForID() Interrupt indicates completion of Image Loading, println as Interrupt handling was not required.

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 331:

> 329:                 mTracker.waitForID(id, 0);
> 330:             } catch (InterruptedException e) {
> 331:                 System.out.println("INTERRUPTED while loading Image");

should be ok. Only question is, should we set the Thread interrupt flag or MediaTracker ABORTED flag too here but seems like this file does not check for error status after calling loadImage and it's been there for long so it might affect existing application using ImageIcon.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From aivanov at openjdk.java.net  Thu Mar 10 13:22:45 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 10 Mar 2022 13:22:45 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage
In-Reply-To: <x2z-m3Sq-k2cUBobgCe9KwHBgQFY3fvHa4ZpHld9GHA=.39ce100a-a89a-4247-a265-bf79508b7e1e@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <x2z-m3Sq-k2cUBobgCe9KwHBgQFY3fvHa4ZpHld9GHA=.39ce100a-a89a-4247-a265-bf79508b7e1e@github.com>
Message-ID: <2s6htwoTFM0N9DBj0Ub2zK2TepiNjRuLVJsij4mnXcM=.ba4724c1-aee4-4683-acac-cb6912dc7016@github.com>

On Thu, 10 Mar 2022 12:59:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Removed the println() line from the Interrupted catch block. Since waitForID() Interrupt indicates completion of Image Loading, println as Interrupt handling was not required.
>
> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 331:
> 
>> 329:                 mTracker.waitForID(id, 0);
>> 330:             } catch (InterruptedException e) {
>> 331:                 System.out.println("INTERRUPTED while loading Image");
> 
> should be ok. Only question is, should we set the Thread interrupt flag or MediaTracker ABORTED flag too here but seems like this file does not check for error status after calling loadImage and it's been there for long so it might affect existing application using ImageIcon.

That was my concern too. In fact, `InterruptedException` is not in the regular flow, it indicates a somewhat error condition which isn't actually handled.

If `loadStatus` of the image is not `COMPLETE` or `ERRORED`, we should probably move it to `ABORTED`.

I don't think we should raise Thread.interrupt flag again.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From alitvinov at openjdk.java.net  Thu Mar 10 15:13:51 2022
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Thu, 10 Mar 2022 15:13:51 GMT
Subject: RFR: 8277922: Unable to click JCheckBox in JTable through Java
 Access Bridge [v3]
In-Reply-To: <LnYrdRZZrxNBaQqNon8wZU4NlG4l63XPVtkDGFN1ftk=.7f878212-5d70-45fb-b50d-beb28a9566bd@github.com>
References: <68JPxsadS5K_WkQgEkMdD_qCt1DWBpBVHV23b0oQKGU=.0b4e520a-205d-4cf1-b506-dd48616ebece@github.com>
 <Vz4HgwEIrd3001wrGJ2-Vt55yX-YU8pfKgkw3qrb3Rc=.06e4fa2a-e91b-489d-af57-50499468371a@github.com>
 <LnYrdRZZrxNBaQqNon8wZU4NlG4l63XPVtkDGFN1ftk=.7f878212-5d70-45fb-b50d-beb28a9566bd@github.com>
Message-ID: <4usJeu-S7P-Lfo4DZrRoTJJAWrl8eKzuKzeyGbZKSDI=.a5ac400d-b59e-4a69-be03-e8f8c160d3a0@github.com>

On Wed, 9 Mar 2022 23:00:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Anton Litvinov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   The third version of the fix for JDK-8277922
>
> src/java.desktop/share/classes/javax/swing/JTable.java line 8417:
> 
>> 8415:                 if (ac != null) {
>> 8416:                     return ac.getAccessibleAction();
>> 8417:                 }
> 
> This is the fix for possible NPE, right?

Yes, correct, this "if" condition is a fix for possible NPE, the method "javax.swing.JTable.AccessibleJTable.AccessibleJTableCell.getCurrentAccessibleContext()" may return "null" according to its documentation and to its code. I already took into account this possible NPE in the 1st and 2nd versions of the fix for this bug, and saw it amoral not to take it into account in the 3rd version of the fix, therefore I added this "if (ac != null) {" block in the 3rd fix version.

> test/jdk/javax/accessibility/JTable/BooleanRendererHasAccessibleActionTest.java line 48:
> 
>> 46: import javax.swing.table.TableCellRenderer;
>> 47: 
>> 48: public class BooleanRendererHasAccessibleActionTest {
> 
> Would `BooleanRendererHasNoAccessibleActionTest` be a better name? After all, you test for *no* accessible action.

For almost 10 years of fixing bugs in JDK, I have always given names to the regression tests to describe exactly the failing test scenario, rather then the expected and not failing behavior. So for me the test name "BooleanRendererHasNoAccessibleActionTest" would mean that the test should fail when BooleanRenderer does not have "AccessibleAction", and this is the opposite from what the bug and what I am fixing by the 3rd fix version. I am not going to change the test name.

> test/jdk/javax/accessibility/JTable/BooleanRendererHasAccessibleActionTest.java line 50:
> 
>> 48: public class BooleanRendererHasAccessibleActionTest {
>> 49:     private volatile JFrame frame;
>> 50:     private volatile JTable table;
> 
> Neither `frame` nor `table` are accessed from any other thread but EDT, I believe `volatile` isn't necessary in this case.

I am not going to remove these "volatile" modifiers. These two variables are initialized and assigned "null" values on the Main thread in "main" method and then other values are assigned to them as well as they are accessed from EDT. Hence we got two threads accessing these two references, therefore these references must be thread-safe from my view point. I do not want to start again our endless arguing on this subject, which we periodically had before, in this review request and about variables in the regression test, especially when you are suggesting to decrease thread-safety.

> test/jdk/javax/accessibility/JTable/BooleanRendererHasAccessibleActionTest.java line 142:
> 
>> 140: 
>> 141:     private void testAccessibleActionInCellRenderer(int row, int column,
>> 142:             boolean shouldBeNull) {
> 
> Since `shouldBeNull` is always `true`, I propose to drop it.

In my opinion this argument does not create any troubles for the test but makes real goals achieved by the method "testAccessibleActionInCellRenderer" more clear and makes this test method more generic. I do not want to remove it. If the goal is to optimize the code, then everything in this test can be rearranged, rewritten, I am not trying to achieve the goal to write absolutely minimal test case.

> test/jdk/javax/accessibility/JTable/BooleanRendererHasAccessibleActionTest.java line 143:
> 
>> 141:     private void testAccessibleActionInCellRenderer(int row, int column,
>> 142:             boolean shouldBeNull) {
>> 143:         System.out.println(String.format(
> 
> I suggest using `System.out.printf`, just add `"\n"` to the end of format string.

I am not against that somebody prefers "System.out.printf", let they use it, if they want, but I personally like to use "System.out.println" and "System.out.print" and have full right to use it.

> test/jdk/javax/accessibility/JTable/BooleanRendererHasAccessibleActionTest.java line 161:
> 
>> 159:         AccessibleAction cellRendererAa = cellRendererAc.getAccessibleAction();
>> 160:         if ((shouldBeNull && (cellRendererAa != null)) ||
>> 161:             (!shouldBeNull && (cellRendererAa == null))) {
> 
> If `shouldBeNull` is dropped from parameters, this condition can be simplified to
> Suggestion:
> 
>         if (cellRendererAa != null)) {
> 
> 
> And the error message below should say _'cellRendererAa' is not null_.

Alexey, I refuse to make the forth version of the fix just to remove this innocent "shouldBeNull" argument. Information in the current error message "Test failed. 'cellRendererAa' is not as should be" is enough to understand what is the reason of the failure. To understand what value was expected by the failing test scenario, it is needed just to read in "System.out" the output of the code

143         System.out.println(String.format(
144                 "testAccessibleActionInCellRenderer():" +
145                     " row='%d', column='%d', shouldBeNull='%b'",
146                 row, column, shouldBeNull));

-------------

PR: https://git.openjdk.java.net/jdk/pull/7416


From duke at openjdk.java.net  Thu Mar 10 15:33:57 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Thu, 10 Mar 2022 15:33:57 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage
In-Reply-To: <2s6htwoTFM0N9DBj0Ub2zK2TepiNjRuLVJsij4mnXcM=.ba4724c1-aee4-4683-acac-cb6912dc7016@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <x2z-m3Sq-k2cUBobgCe9KwHBgQFY3fvHa4ZpHld9GHA=.39ce100a-a89a-4247-a265-bf79508b7e1e@github.com>
 <2s6htwoTFM0N9DBj0Ub2zK2TepiNjRuLVJsij4mnXcM=.ba4724c1-aee4-4683-acac-cb6912dc7016@github.com>
Message-ID: <_Eb1usYXvARXBUeKntPJnjhdArtK4D5MycXBiTcqtTA=.ba1f35c0-aede-4348-b2f6-3370fcaf1d96@github.com>

On Thu, 10 Mar 2022 13:19:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 331:
>> 
>>> 329:                 mTracker.waitForID(id, 0);
>>> 330:             } catch (InterruptedException e) {
>>> 331:                 System.out.println("INTERRUPTED while loading Image");
>> 
>> should be ok. Only question is, should we set the Thread interrupt flag or MediaTracker ABORTED flag too here but seems like this file does not check for error status after calling loadImage and it's been there for long so it might affect existing application using ImageIcon.
>
> That was my concern too. In fact, `InterruptedException` is not in the regular flow, it indicates a somewhat error condition which isn't actually handled.
> 
> If `loadStatus` of the image is not `COMPLETE` or `ERRORED`, we should probably move it to `ABORTED`.
> 
> I don't think we should raise Thread.interrupt flag again.

WaitForID() definition states that "If there is an error while loading or scaling an image, then that image is considered to have finished loading". Does this indicates that no error checking is required.....?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From aivanov at openjdk.java.net  Thu Mar 10 16:02:46 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 10 Mar 2022 16:02:46 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage
In-Reply-To: <_Eb1usYXvARXBUeKntPJnjhdArtK4D5MycXBiTcqtTA=.ba1f35c0-aede-4348-b2f6-3370fcaf1d96@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <x2z-m3Sq-k2cUBobgCe9KwHBgQFY3fvHa4ZpHld9GHA=.39ce100a-a89a-4247-a265-bf79508b7e1e@github.com>
 <2s6htwoTFM0N9DBj0Ub2zK2TepiNjRuLVJsij4mnXcM=.ba4724c1-aee4-4683-acac-cb6912dc7016@github.com>
 <_Eb1usYXvARXBUeKntPJnjhdArtK4D5MycXBiTcqtTA=.ba1f35c0-aede-4348-b2f6-3370fcaf1d96@github.com>
Message-ID: <2vwMFlely_NGI2XBJ_R58vD6lAqElz39ZWB7U9gavTk=.05c9e4a2-58e6-48d9-9612-2340258ee93c@github.com>

On Thu, 10 Mar 2022 15:30:51 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> That was my concern too. In fact, `InterruptedException` is not in the regular flow, it indicates a somewhat error condition which isn't actually handled.
>> 
>> If `loadStatus` of the image is not `COMPLETE` or `ERRORED`, we should probably move it to `ABORTED`.
>> 
>> I don't think we should raise Thread.interrupt flag again.
>
> WaitForID() definition states that "If there is an error while loading or scaling an image, then that image is considered to have finished loading". Does this indicates that no error checking is required.....?

But in this case it's the waiting thread that is interrupted. The `MediaTracker` could complete loading the image successfully yet `ImageIcon` instance wouldn't update its `loadStatus` because it removes itself from the media tracker.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From aivanov at openjdk.java.net  Thu Mar 10 16:06:46 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 10 Mar 2022 16:06:46 GMT
Subject: RFR: 8277922: Unable to click JCheckBox in JTable through Java
 Access Bridge [v3]
In-Reply-To: <Vz4HgwEIrd3001wrGJ2-Vt55yX-YU8pfKgkw3qrb3Rc=.06e4fa2a-e91b-489d-af57-50499468371a@github.com>
References: <68JPxsadS5K_WkQgEkMdD_qCt1DWBpBVHV23b0oQKGU=.0b4e520a-205d-4cf1-b506-dd48616ebece@github.com>
 <Vz4HgwEIrd3001wrGJ2-Vt55yX-YU8pfKgkw3qrb3Rc=.06e4fa2a-e91b-489d-af57-50499468371a@github.com>
Message-ID: <tlydDa83IZZx1tN6yN8W9dBbZSrcJCsTzuEUiyDCPx0=.f806849d-7cd9-4f63-a478-5524a5b864ea@github.com>

On Wed, 9 Mar 2022 16:11:02 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

>> Hello,
>> 
>> Could you please review the following fix for the bug. The bug consists in the fact that When an assistive technology software by means of Java Access Bridge API executes "AccessibleAction" "click" on "AccessibleContext" which corresponds to "javax.swing.JTable" cell containing "javax.swing.JCheckBox", then the cell's value and cell's view represented by "JCheckBox" stay unchanged. The issue is a bug in JDK and should be fixed in JDK, because JDK informs the assistive technology software through Java Access Bridge API in particular through the function
>> 
>> "BOOL getAccessibleActions(long vmID, AccessibleContext accessibleContext, AccessibleActions *actions)"
>> 
>> that "AccessibleContext" of the table cell with "JCheckBox" supports one action "click", while real execution of this action on this accessible context does not lead to any result.
>> 
>> THE ROOT CAUSE OF THE BUG:
>> 
>> The reason of the issue is the fact that when the assistive technology software tries to do "AccessibleAction" on "AccessibleContext" associated with a cell with boolean data type in "JTable" component through Java Access Bridge (JAB), the JDK executes this "AccessibleAction" on "AccessibleContext" of a renderer, which is an instance of the class "javax.swing.JTable.BooleanRenderer" which is a derivative of "JCheckBox" class, and the instance of this renderer is single and common for all cells of boolean data type. Therefore execution of "click" "AccessibleAction" on this renderer component which is not permanently bound to any particular cell in the table does not lead to update of the table cell value.
>> 
>> THE FIX:
>> 
>> The fix implements an approach which guarantees setting of new values to the table's cells with boolean data type on each execution of "AccessibleAction" of "javax.swing.JTable.BooleanRenderer" instance, when execution of this action changes the "selected" state of this "BooleanRenderer" JCheckBox component.
>> 
>> Please take into account that the created automatic regression test simulates the issue only with Java Accessibility API what is not fully equal to the original test scenario which requires the assistive technology software and usage of Java Access Bridge API and which can be tested using the manual test case attached to the issue in JBS. However the regression test still allows to reproduce the issue and verify that the fix resolves it.
>> 
>> Thank you,
>> Anton
>
> Anton Litvinov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The third version of the fix for JDK-8277922

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7416


From aivanov at openjdk.java.net  Thu Mar 10 16:23:43 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 10 Mar 2022 16:23:43 GMT
Subject: RFR: 8277922: Unable to click JCheckBox in JTable through Java
 Access Bridge [v3]
In-Reply-To: <4usJeu-S7P-Lfo4DZrRoTJJAWrl8eKzuKzeyGbZKSDI=.a5ac400d-b59e-4a69-be03-e8f8c160d3a0@github.com>
References: <68JPxsadS5K_WkQgEkMdD_qCt1DWBpBVHV23b0oQKGU=.0b4e520a-205d-4cf1-b506-dd48616ebece@github.com>
 <Vz4HgwEIrd3001wrGJ2-Vt55yX-YU8pfKgkw3qrb3Rc=.06e4fa2a-e91b-489d-af57-50499468371a@github.com>
 <LnYrdRZZrxNBaQqNon8wZU4NlG4l63XPVtkDGFN1ftk=.7f878212-5d70-45fb-b50d-beb28a9566bd@github.com>
 <4usJeu-S7P-Lfo4DZrRoTJJAWrl8eKzuKzeyGbZKSDI=.a5ac400d-b59e-4a69-be03-e8f8c160d3a0@github.com>
Message-ID: <LZt6iqu79sNkVr9_cc0Z02nMDUoq6Cd0TjxmtYhU6l4=.e56441ab-4a64-450a-b125-2d17c8d74dbb@github.com>

On Thu, 10 Mar 2022 15:10:42 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JTable.java line 8417:
>> 
>>> 8415:                 if (ac != null) {
>>> 8416:                     return ac.getAccessibleAction();
>>> 8417:                 }
>> 
>> This is the fix for possible NPE, right?
>
> Yes, correct, this "if" condition is a fix for possible NPE, the method "javax.swing.JTable.AccessibleJTable.AccessibleJTableCell.getCurrentAccessibleContext()" may return "null" according to its documentation and to its code. I already took into account this possible NPE in the 1st and 2nd versions of the fix for this bug, and saw it amoral not to take it into account in the 3rd version of the fix, therefore I added this "if (ac != null) {" block in the 3rd fix version.

Got it! Thanks.

>> test/jdk/javax/accessibility/JTable/BooleanRendererHasAccessibleActionTest.java line 48:
>> 
>>> 46: import javax.swing.table.TableCellRenderer;
>>> 47: 
>>> 48: public class BooleanRendererHasAccessibleActionTest {
>> 
>> Would `BooleanRendererHasNoAccessibleActionTest` be a better name? After all, you test for *no* accessible action.
>
> For almost 10 years of fixing bugs in JDK, I have always given names to the regression tests to describe exactly the failing test scenario, rather then the expected and not failing behavior. So for me the test name "BooleanRendererHasNoAccessibleActionTest" would mean that the test should fail when BooleanRenderer does not have "AccessibleAction", and this is the opposite from what the bug and what I am fixing by the 3rd fix version. I am not going to change the test name.

Makes sense.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7416


From alitvinov at openjdk.java.net  Thu Mar 10 16:41:46 2022
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Thu, 10 Mar 2022 16:41:46 GMT
Subject: Integrated: 8277922: Unable to click JCheckBox in JTable through Java
 Access Bridge
In-Reply-To: <68JPxsadS5K_WkQgEkMdD_qCt1DWBpBVHV23b0oQKGU=.0b4e520a-205d-4cf1-b506-dd48616ebece@github.com>
References: <68JPxsadS5K_WkQgEkMdD_qCt1DWBpBVHV23b0oQKGU=.0b4e520a-205d-4cf1-b506-dd48616ebece@github.com>
Message-ID: <kDjAqTbZM39itkb8FY7veBnF035-_5XeDkaa6iGl_x8=.dc360b82-d9a4-470a-bc96-bfb7a73d95ab@github.com>

On Thu, 10 Feb 2022 04:59:33 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

> Hello,
> 
> Could you please review the following fix for the bug. The bug consists in the fact that When an assistive technology software by means of Java Access Bridge API executes "AccessibleAction" "click" on "AccessibleContext" which corresponds to "javax.swing.JTable" cell containing "javax.swing.JCheckBox", then the cell's value and cell's view represented by "JCheckBox" stay unchanged. The issue is a bug in JDK and should be fixed in JDK, because JDK informs the assistive technology software through Java Access Bridge API in particular through the function
> 
> "BOOL getAccessibleActions(long vmID, AccessibleContext accessibleContext, AccessibleActions *actions)"
> 
> that "AccessibleContext" of the table cell with "JCheckBox" supports one action "click", while real execution of this action on this accessible context does not lead to any result.
> 
> THE ROOT CAUSE OF THE BUG:
> 
> The reason of the issue is the fact that when the assistive technology software tries to do "AccessibleAction" on "AccessibleContext" associated with a cell with boolean data type in "JTable" component through Java Access Bridge (JAB), the JDK executes this "AccessibleAction" on "AccessibleContext" of a renderer, which is an instance of the class "javax.swing.JTable.BooleanRenderer" which is a derivative of "JCheckBox" class, and the instance of this renderer is single and common for all cells of boolean data type. Therefore execution of "click" "AccessibleAction" on this renderer component which is not permanently bound to any particular cell in the table does not lead to update of the table cell value.
> 
> THE FIX:
> 
> The fix implements an approach which guarantees setting of new values to the table's cells with boolean data type on each execution of "AccessibleAction" of "javax.swing.JTable.BooleanRenderer" instance, when execution of this action changes the "selected" state of this "BooleanRenderer" JCheckBox component.
> 
> Please take into account that the created automatic regression test simulates the issue only with Java Accessibility API what is not fully equal to the original test scenario which requires the assistive technology software and usage of Java Access Bridge API and which can be tested using the manual test case attached to the issue in JBS. However the regression test still allows to reproduce the issue and verify that the fix resolves it.
> 
> Thank you,
> Anton

This pull request has now been integrated.

Changeset: 1668c02e
Author:    Anton Litvinov <alitvinov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1668c02ee83cc4f7bd7b2fe5bb7ef59b5dbda081
Stats:     212 lines in 2 files changed: 211 ins; 0 del; 1 mod

8277922: Unable to click JCheckBox in JTable through Java Access Bridge

Reviewed-by: aivanov, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/7416


From naoto at openjdk.java.net  Thu Mar 10 17:03:45 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 10 Mar 2022 17:03:45 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <TdJhSkQwWvukmhDKrxi5K9E0-pzh1UxqBFSKi0a1r18=.3eb1eada-4b4e-4856-85df-a1c7d04f92ed@github.com>

On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung <achung at openjdk.org> wrote:

> msg drop for jdk19, Mar 9, 2022

IIRC, localized resource files should have the same copyright year as the base English one. That's what I was told by the l10n engineer when I had the same comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7765


From dfuchs at openjdk.java.net  Thu Mar 10 17:09:44 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 10 Mar 2022 17:09:44 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10
In-Reply-To: <TdJhSkQwWvukmhDKrxi5K9E0-pzh1UxqBFSKi0a1r18=.3eb1eada-4b4e-4856-85df-a1c7d04f92ed@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <TdJhSkQwWvukmhDKrxi5K9E0-pzh1UxqBFSKi0a1r18=.3eb1eada-4b4e-4856-85df-a1c7d04f92ed@github.com>
Message-ID: <eFN7SFB4835Ai-NMuO6yzfs0cdy5aM90VdU3qr7ctpQ=.52d046e1-33b6-407f-905f-1ca762f286d7@github.com>

On Thu, 10 Mar 2022 17:00:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> IIRC, localized resource files should have the same copyright year as the base English one. That's what I was told by the l10n engineer when I had the same comment.

Thanks Naoto! I have no objection then.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7765


From achung at openjdk.java.net  Thu Mar 10 17:55:44 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Thu, 10 Mar 2022 17:55:44 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2]
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>

> msg drop for jdk19, Mar 9, 2022

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  moved CurrencyNames changes to jdk.localedata

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7765/files
  - new: https://git.openjdk.java.net/jdk/pull/7765/files/fb51cf60..4735722d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=00-01

  Stats: 2807 lines in 6 files changed: 693 ins; 1527 del; 587 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7765.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765

PR: https://git.openjdk.java.net/jdk/pull/7765


From duke at openjdk.java.net  Thu Mar 10 18:23:18 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Thu, 10 Mar 2022 18:23:18 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v2]
In-Reply-To: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
Message-ID: <GNS_FidJndPCJ8cQZcouUYG-EYSLo1VV6mI0ct0u69Y=.dcdaf9d9-5d94-4d61-8db4-a9b739c3d1c3@github.com>

> Previously while tabbing through the JTable cell, the cell highlighter/focus ring was not visible against the selection background. 
> 
> Changes are made to Aqua LAF to derive a brighter focus ring color by changing hue, saturation and brightness of selection background color so that it is visible while tabbing through `JTable` cells. A new method is added for this purpose which takes in `selectionBackground` color, does the hue, saturation and brightness manipulation and returns a new focus ring color. There are edge cases where the HSB transformation does not yield the right focus ring color, for these cases a default color is returned that is different and can be seen against the `selectionBackground`.
> 
> **Edge Cases**
> **Selection Background**     -----       **Returned Focus Ring Color**
> - White/ Black                        ----->          Gray
> 
> - Shade of Gray 
> towards white (r=g=b >= 128)  ----->      Black
> 
> - Shade of Gray 
> towards Black (r=g=b < 128)    ------>     White
> 
> A test case is added to compare the RGB difference between the original focus ring color & selection background and the brighter focus ring color & selection background.
> 
> PS: The native L&F (Mac OS) and Swing L&F for JTable cell tabbing differs (on native tables the cell background turns white on focus with a cell focus ring). Since the background for Swing tables can be set by users and also overridden by subclassing `DefaultTableCellRenderer`, and to adhere to current implementation of Swing, the cell background changes are not incorporated. Only the Focus Ring/ Cell Highlighter is made more prominent against the selection background.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  formatted line lengths, added method-level comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7768/files
  - new: https://git.openjdk.java.net/jdk/pull/7768/files/dbba08fc..ffe3d6ba

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7768&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7768&range=00-01

  Stats: 19 lines in 1 file changed: 7 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7768/head:pull/7768

PR: https://git.openjdk.java.net/jdk/pull/7768


From cjplummer at openjdk.java.net  Thu Mar 10 19:06:43 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 10 Mar 2022 19:06:43 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2]
In-Reply-To: <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
Message-ID: <8cpPZ7PatfiigWBze5jL-LUXa6urMiCgdhpm1otQHhA=.1862cf26-296b-438e-acfe-2a83b64dc539@github.com>

On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved CurrencyNames changes to jdk.localedata

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 305:

> 303:         {"Thread not suspended", "Thread nicht unterbrochen"},
> 304:         {"thread group number description name", "{0,number,integer}. {1} {2}"},
> 305:         {"Threadgroup name not specified.", "Name der Threadgruppe nicht angegeben."},

Same comment here as mentioned in TTYResources_ja.java.

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 342:

> 340:         {"watch modification of", "\u00C4nderung von {0}.{1} \u00FCberwachen"},
> 341:         {"zz help text",
> 342:              "** Befehlsliste **\nconnectors                -- Listet verf\u00FCgbare Connectors und Transporte in dieser VM auf\n\nrun [class [args]]        -- Startet die Ausf\u00FChrung der Hauptklasse der Anwendung\n\nthreads [threadgroup]     -- Listet Threads auf\nthread <Thread-ID>        -- Legt den Standardthread fest\nsuspend [thread id(s)]    -- Unterbricht Threads (Standard: all)\nresume [thread id(s)]    -- Nimmt Threads wieder auf (Standard: all)\nwhere [<Thread-ID> | all] -- Gibt den Stack eines Threads aus\nwherei [<Thread-ID> | all] -- Gibt den Stack eines Threads mit PC-Informationen aus\nup [n frames]             -- Verschiebt den Stack eines Threads nach oben\ndown [n frames]             -- Verschiebt den Stack eines Threads nach unten\nkill <Thread-ID> <Ausdruck>   -- Bricht einen Thread mit dem angegebenen Ausnahmeobjekt ab\ninterrupt <Thread-ID>     -- Unterbricht einen Thread\n\nprint <Ausdruck>              -- Gibt den Wert eines Ausdrucks aus\ndump <A
 usdruck>               -- Gibt alle Objektinformationen aus\neval <Ausdruck>               -- Bewertet einen Ausdruck (wie \"print\")\nset <lvalue> = <Ausdruck>     -- Weist einem Feld/einer Variablen/einem Arrayelement einen neuen Wert zu\nlocals                    -- Gibt alle lokalen Variablen im aktuellen Stackframe aus\n\nclasses                   -- Listet derzeit bekannte Klassen auf\nclass <Klassen-ID>          -- Zeigt Details einer benannten Klasse an\nmethods <Klassen-ID>        -- Listet die Methoden einer Klasse auf\nfields <Klassen-ID>        -- Listet die Felder einer Klasse auf\n\nthreadgroups              -- Listet Threadgruppen auf\nthreadgroup <Name>        -- Legt die aktuelle Threadgruppe fest\n\nstop [go|thread] [<thread_id>] <at|in> <Position>\n                          -- Legt einen Breakpoint fest\n                          -- Wenn Sie keine Optionen angeben, wird die aktuelle Breakpoint-Liste ausgegeben\n                          -- Wenn Sie \"go\" angeben,
  wird der Vorgang nach dem Stoppen sofort wiederaufgenommen\n                          -- Wenn Sie \"thread\" angeben, wird nur der Thread unterbrochen, in dem gestoppt wurde\n                          -- Wenn Sie weder \"go\" noch \"thread\" angeben, werden alle Threads unterbrochen\n                          -- Wenn Sie eine ganzzahlige <thread_id> angeben, wird der Vorgang nur im angegebenen Thread gestoppt\n                          -- \"at\" und \"in\" haben die gleiche Bedeutung\n                          -- <Position> kann eine Zeilennummer oder eine Methode sein:\n                          --   <class_id>:<line_number>\n                          --   <class_id>.<Methode>[(argument_type,...)]\nclear <class id>.<Methode>[(argument_type,...)]\n                          -- L\u00F6scht einen Breakpoint in einer Methode\nclear <Klassen-ID>:<Zeile>   -- L\u00F6scht einen Breakpoint bei einer Zeile\nclear                     -- Listet Breakpoints auf\ncatch [uncaught|caught|all] <Kl
 assen-ID>|<Klassenmuster>\n                          -- Break bei der angegebenen Ausnahme\nignore [uncaught|caught|all] <Klassen-ID>|<Klassenmuster>\n                          -- Bricht \"catch\" f\u00FCr die angegebene Ausnahme ab\nwatch [access|all] <Klassen-ID>.<Feldname>\n                          -- \u00DCberwacht Zugriffe/\u00C4nderungen eines Feldes\nunwatch [access|all] <Klassen-ID>.<Feldname>\n                          -- Hebt die \u00DCberwachung der Zugriffe/\u00C4nderungen eines Feldes auf\ntrace [go] methods [thread]\n                          -- Verfolgt Methodenstarts und -beendigungen.\n                          -- Alle Threads werden unterbrochen, es sei denn, \"go\" ist angegeben\ntrace [go] method exit | exits [thread]\n                          -- Verfolgt die Beendigung der aktuellen Methode oder die Beendigungen aller Methoden\n                          -- Alle Threads werden unterbrochen, es sei denn, \"go\" ist angegeben\nuntrace [methods]         -- Stoppt 
 das Tracing von Methodenstarts und/oder -beendigungen\nstep                      -- F\u00FChrt die aktuelle Zeile aus\nstep up                   -- Ausf\u00FChren, bis die aktuelle Methode an den Aufrufer zur\u00FCckgegeben wird\nstepi                     -- F\u00FChrt die aktuelle Anweisung aus\nnext                      -- Eine Zeile weiter (Aufrufe auslassen)\ncont                      -- Setzt die Ausf\u00FChrung ab dem Breakpoint fort\n\nlist [line number|method] -- Gibt den Quellcode aus\nuse (or sourcepath) [source file path]\n                          -- Zeigt den Quellpfad an oder \u00E4ndert diesen\nexclude [<Klassenmuster>, ... | \"none\"]\n                          -- Meldet keine Schritt- oder Methodenereignisse f\u00FCr angegebene Klassen\nclasspath                 -- Gibt Classpath-Informationen aus der Ziel-VM aus\n\nmonitor <Befehl>         -- F\u00FChrt bei jedem Programmstopp einen Befehl aus\nmonitor                   -- Listet Monitore auf\nunmonitor <Monitornum
 mer>      -- L\u00F6scht einen Monitor\nread <Dateiname>           -- Liest eine Befehlsdatei und f\u00FChrt diese aus\n\nlock <Ausdruck>               -- Gibt Sperrinformationen f\u00FCr ein Objekt aus\nthreadlocks [thread id]   -- Gibt Sperrinformationen f\u00FCr einen Thread aus\n\npop                       -- Holt den Stack bis zum aktuellen Frame (einschlie\u00DFlich)\nreenter                   -- Wie \"pop\", aber der aktuelle Frame wird wieder eingegeben\nredefine <Klassen-ID> <Klassendateiname>\n                          -- Definiert den Code f\u00FCr eine Klasse neu\n\ndisablegc <Ausdruck>          -- Verhindert die Garbage Collection eines Objekts\nenablegc <Ausdruck>          -- L\u00E4sst die Garbage Collection eines Objekts zu\n\n!!                        -- Wiederholt den letzten Befehl\n<n> <Befehl>             -- Wiederholt einen Befehl n-mal\nrepeat                    -- Zeigt an, ob die Wiederholung durch leeren Befehl im GDB-Stil aktiviert ist\nrepeat <on|off>    
        -- Aktiviert/deaktiviert die Wiederholung im GDB-Stil\n# <Befehl>               -- Verwerfen (kein Vorgang)\nhelp (oder ?)               -- Listet Befehle auf\ndbgtrace [flag]           -- Identisch mit der Befehlszeilenoption \"dbgtrace\"\nversion                   -- Gibt Versionsinformationen aus\nexit (oder quit)            -- Beendet den Debugger\n\n<Klassen-ID>: Ein vollst\u00E4ndiger Klassenname mit Package-Qualifiers\n<Klassenmuster>: Ein Klassenname mit einem Platzhalter am Anfang oder Ende (\"*\")\n<Thread-ID>: Threadnummer aus dem Befehl \"threads\"\n<Ausdruck>: Ein Ausdruck der Java(TM)-Programmiersprache.\nDer Gro\u00DFteil der g\u00E4ngigen Syntax wird unterst\u00FCtzt.\n\nStartbefehle k\u00F6nnen in \"jdb.ini\" oder \".jdbrc\" abgelegt werden\nin user.home oder user.dir"},

Same comment here as mentioned in TTYResources_ja.java.

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java line 305:

> 303:         {"Thread not suspended", "\u30B9\u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u3066\u3044\u307E\u305B\u3093"},
> 304:         {"thread group number description name", "{0,number,integer}. {1} {2}"},
> 305:         {"Threadgroup name not specified.", "\u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u540D\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u307E\u305B\u3093\u3002"},

I'm not sure what happened here. This resource was just removed yesterday as part of #7687. It had been around for a long time before that (probably from the beginning of this file), so I'm not sure what triggered getting it re-added.

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java line 342:

> 340:         {"watch modification of", "{0}.{1}\u306E\u5909\u66F4\u306E\u30A6\u30A9\u30C3\u30C1"},
> 341:         {"zz help text",
> 342:              "** \u30B3\u30DE\u30F3\u30C9\u30FB\u30EA\u30B9\u30C8 **\nconnectors                -- \u3053\u306EVM\u5185\u306E\u4F7F\u7528\u53EF\u80FD\u306A\u30B3\u30CD\u30AF\u30BF\u3068\u30C8\u30E9\u30F3\u30B9\u30DD\u30FC\u30C8\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\n\nrun [class [args]]        -- \u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u306E\u30E1\u30A4\u30F3\u30FB\u30AF\u30E9\u30B9\u306E\u5B9F\u884C\u3092\u958B\u59CB\u3057\u307E\u3059\n\nthreads [threadgroup]     -- \u30B9\u30EC\u30C3\u30C9\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nthread <thread id>        -- \u30C7\u30D5\u30A9\u30EB\u30C8\u306E\u30B9\u30EC\u30C3\u30C9\u3092\u8A2D\u5B9A\u3057\u307E\u3059\nsuspend [thread id(s)]    -- \u30B9\u30EC\u30C3\u30C9\u3092\u4E2D\u65AD\u3057\u307E\u3059(\u30C7\u30D5\u30A9\u30EB\u30C8: \u3059\u3079\u3066)\nresume [thread id(s)]     -- \u30B9\u30EC\u30C3\u30C9\u3092\u518D\u958B\u3057\u307E\u3059(\u30C7\u30D5\u30A9\u30EB\u30C8: \u3059\u3079\u3066)\nwhere [<thread id> | all]
  -- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u30C0\u30F3\u30D7\u3057\u307E\u3059\nwherei [<thread id> | all]-- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092pc\u60C5\u5831\u3068\u3068\u3082\u306B\u30C0\u30F3\u30D7\u3057\u307E\u3059\nup [n frames]             -- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u4E0A\u306B\u79FB\u52D5\u3057\u307E\u3059\ndown [n frames]           -- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u4E0B\u306B\u79FB\u52D5\u3057\u307E\u3059\nkill <thread id> <expr>   -- \u6307\u5B9A\u3055\u308C\u305F\u4F8B\u5916\u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u3067\u30B9\u30EC\u30C3\u30C9\u3092\u5F37\u5236\u7D42\u4E86\u3057\u307E\u3059\ninterrupt <thread id>     -- \u30B9\u30EC\u30C3\u30C9\u3092\u4E2D\u65AD\u3057\u307E\u3059\n\nprint <expr>              -- \u5F0F\u306E\u5024\u3092\u51FA\u529B\u3057\u307E\u3059\ndump <expr>               -- \u3059\u3079\u3066\u306E\u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u60C5\u58
 31\u3092\u51FA\u529B\u3057\u307E\u3059\neval <expr>               -- \u5F0F\u3092\u8A55\u4FA1\u3057\u307E\u3059(print\u3068\u540C\u3058)\nset <lvalue> = <expr>     -- \u65B0\u3057\u3044\u5024\u3092\u30D5\u30A3\u30FC\u30EB\u30C9/\u5909\u6570/\u914D\u5217\u8981\u7D20\u306B\u4EE3\u5165\u3057\u307E\u3059\nlocals                    -- \u73FE\u5728\u306E\u30B9\u30BF\u30C3\u30AF\u30FB\u30D5\u30EC\u30FC\u30E0\u5185\u306E\u3059\u3079\u3066\u306E\u30ED\u30FC\u30AB\u30EB\u5909\u6570\u3092\u51FA\u529B\u3057\u307E\u3059\n\nclasses                   -- \u73FE\u5728\u65E2\u77E5\u306E\u30AF\u30E9\u30B9\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nclass <class id>          -- \u6307\u5B9A\u3057\u305F\u30AF\u30E9\u30B9\u306E\u8A73\u7D30\u3092\u8868\u793A\u3057\u307E\u3059\nmethods <class id>        -- \u30AF\u30E9\u30B9\u306E\u30E1\u30BD\u30C3\u30C9\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nfields <class id>         -- \u30AF\u30E9\u30B9\u306E\u30D5\u30A3\u30FC\u30EB\u30C9\u3092\u30EA\u30B9\u30C8\u305
 7\u307E\u3059\n\nthreadgroups              -- \u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nthreadgroup <name>        -- \u73FE\u5728\u306E\u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u3092\u8A2D\u5B9A\u3057\u307E\u3059\n\nstop [go|thread] [<thread_id>] <at|in> <location>\n                          -- \u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u8A2D\u5B9A\u3057\u307E\u3059\n                          -- \u30AA\u30D7\u30B7\u30E7\u30F3\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u306A\u3044\u5834\u5408\u306F\u3001\u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u306E\u73FE\u5728\u306E\u30EA\u30B9\u30C8\u304C\u51FA\u529B\u3055\u308C\u307E\u3059\n                          -- \"go\"\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u306F\u3001\u505C\u6B62\u5F8C\u3059\u3050\u306B\u518D\u958B\u3057\u307E\u3059\n                          -- \"thread\"\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u306F\u3001\
 u505C\u6B62\u3057\u305F\u30B9\u30EC\u30C3\u30C9\u306E\u307F\u4E2D\u65AD\u3057\u307E\u3059\n                          -- \"go\"\u3082\"thread\"\u3082\u6307\u5B9A\u3055\u308C\u3066\u3044\u306A\u3044\u5834\u5408\u306F\u3001\u3059\u3079\u3066\u306E\u30B9\u30EC\u30C3\u30C9\u3092\u4E2D\u65AD\u3057\u307E\u3059\n                          -- \u6574\u6570\u306E<thread_id>\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u306F\u3001\u6307\u5B9A\u3055\u308C\u305F\u30B9\u30EC\u30C3\u30C9\u3067\u306E\u307F\u505C\u6B62\u3057\u307E\u3059\n                          -- \"at\"\u3068\"in\"\u306F\u540C\u3058\u610F\u5473\u3092\u6301\u3061\u307E\u3059\n                          -- <location>\u306F\u884C\u756A\u53F7\u307E\u305F\u306F\u30E1\u30BD\u30C3\u30C9\u306B\u3059\u308B\u3053\u3068\u304C\u3067\u304D\u307E\u3059:\n                          --   <class_id>:<line_number>\n                          --   <class_id>.<method>[(argument_type,...)]\nclear <class id>.<method>[(argument_type,...)]\n  
                         -- \u30E1\u30BD\u30C3\u30C9\u5185\u306E\u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u30AF\u30EA\u30A2\u3057\u307E\u3059\nclear <class id>:<line>   -- \u884C\u306E\u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u30AF\u30EA\u30A2\u3057\u307E\u3059\nclear                     -- \u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\ncatch [uncaught|caught|all] <class id>|<class pattern>\n                          -- \u6307\u5B9A\u3055\u308C\u305F\u4F8B\u5916\u304C\u767A\u751F\u3057\u305F\u3068\u304D\u306B\u30D6\u30EC\u30FC\u30AF\u3057\u307E\u3059\nignore [uncaught|caught|all] <class id>|<class pattern>\n                          -- \u6307\u5B9A\u3055\u308C\u305F\u4F8B\u5916\u306E'catch'\u3092\u53D6\u308A\u6D88\u3057\u307E\u3059\nwatch [access|all] <class id>.<field name>\n                          -- \u30D5\u30A3\u30FC\u30EB\u30C9\u3078\u306E\u30A2\u30AF\u30BB\u30B9\u307E\u305F\u306F\u5909\u66F4\u3092\u30A6\u3
 0A9\u30C3\u30C1\u3057\u307E\u3059\nunwatch [access|all] <class id>.<field name>\n                          -- \u30D5\u30A3\u30FC\u30EB\u30C9\u3078\u306E\u30A2\u30AF\u30BB\u30B9\u307E\u305F\u306F\u5909\u66F4\u306E\u30A6\u30A9\u30C3\u30C1\u3092\u4E2D\u6B62\u3057\u307E\u3059\ntrace [go] methods [thread]\n                          -- \u30E1\u30BD\u30C3\u30C9\u306E\u5165\u308A\u53E3\u3068\u51FA\u53E3\u3092\u30C8\u30EC\u30FC\u30B9\u3057\u307E\u3059\u3002\n                          -- 'go'\u304C\u6307\u5B9A\u3055\u308C\u308B\u307E\u3067\u3059\u3079\u3066\u306E\u30B9\u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u307E\u3059\ntrace [go] method exit | exits [thread]\n                          -- \u73FE\u5728\u306E\u30E1\u30BD\u30C3\u30C9\u306E\u51FA\u53E3\u307E\u305F\u306F\u3059\u3079\u3066\u306E\u30E1\u30BD\u30C3\u30C9\u306E\u51FA\u53E3\u3092\u30C8\u30EC\u30FC\u30B9\u3057\u307E\u3059\n                          -- 'go'\u304C\u6307\u5B9A\u3055\u308C\u308B\u307E\u3067\u3059\u3079\u3066\u306E\u30B9\
 u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u307E\u3059\nuntrace [methods]         -- \u30E1\u30BD\u30C3\u30C9\u306E\u958B\u59CB\u307E\u305F\u306F\u7D42\u4E86\u306E\u30C8\u30EC\u30FC\u30B9\u3092\u505C\u6B62\u3057\u307E\u3059\nstep                      -- \u73FE\u5728\u306E\u884C\u3092\u5B9F\u884C\u3057\u307E\u3059\nstep up                   -- \u73FE\u5728\u306E\u30E1\u30BD\u30C3\u30C9\u304C\u30E1\u30BD\u30C3\u30C9\u306E\u547C\u51FA\u3057\u5143\u306B\u623B\u308B\u307E\u3067\u5B9F\u884C\u3057\u307E\u3059\nstepi                     -- \u73FE\u5728\u306E\u547D\u4EE4\u3092\u5B9F\u884C\u3057\u307E\u3059\nnext                      -- 1\u884C\u3092\u30B9\u30C6\u30C3\u30D7\u5B9F\u884C\u3057\u307E\u3059(\u547C\u51FA\u3057\u3092\u30B9\u30C6\u30C3\u30D7\u30AA\u30FC\u30D0\u30FC)\ncont                      -- \u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u304B\u3089\u5B9F\u884C\u3092\u7D9A\u884C\u3057\u307E\u3059\n\nlist [line number|method] -- \u30BD\u30FC\u30B9\u30FB\u30B3\u30FC\u30C9\u3092\u
 51FA\u529B\u3057\u307E\u3059\nuse (or sourcepath) [source file path]\n                          -- \u30BD\u30FC\u30B9\u30FB\u30D1\u30B9\u3092\u8868\u793A\u307E\u305F\u306F\u5909\u66F4\u3057\u307E\u3059\nexclude [<class pattern>, ... | \"none\"]\n                          -- \u6307\u5B9A\u3057\u305F\u30AF\u30E9\u30B9\u306E\u30B9\u30C6\u30C3\u30D7\u3084\u30E1\u30BD\u30C3\u30C9\u30FB\u30A4\u30D9\u30F3\u30C8\u3092\u5831\u544A\u3057\u307E\u305B\u3093\nclasspath                 -- \u30BF\u30FC\u30B2\u30C3\u30C8VM\u304B\u3089\u30AF\u30E9\u30B9\u30D1\u30B9\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\n\nmonitor <command>         -- \u30D7\u30ED\u30B0\u30E9\u30E0\u304C\u505C\u6B62\u3059\u308B\u305F\u3073\u306B\u30B3\u30DE\u30F3\u30C9\u3092\u5B9F\u884C\u3057\u307E\u3059\nmonitor                   -- \u30E2\u30CB\u30BF\u30FC\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nunmonitor <monitor#>      -- \u30E2\u30CB\u30BF\u30FC\u3092\u524A\u9664\u3057\u307E\u3059\nread <filename>           -- \u30B
 3\u30DE\u30F3\u30C9\u30FB\u30D5\u30A1\u30A4\u30EB\u3092\u8AAD\u307F\u53D6\u3063\u3066\u5B9F\u884C\u3057\u307E\u3059\n\nlock <expr>               -- \u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u306E\u30ED\u30C3\u30AF\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\nthreadlocks [thread id]   -- \u30B9\u30EC\u30C3\u30C9\u306E\u30ED\u30C3\u30AF\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\n\npop                       -- \u73FE\u5728\u306E\u30D5\u30EC\u30FC\u30E0\u307E\u3067\u306E\u3059\u3079\u3066\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u30DD\u30C3\u30D7\u3057\u307E\u3059\nreenter                   -- pop\u3068\u540C\u3058\u3067\u3059\u304C\u3001\u73FE\u5728\u306E\u30D5\u30EC\u30FC\u30E0\u304C\u518D\u5165\u529B\u3055\u308C\u307E\u3059\nredefine <class id> <class file name>\n                          -- \u30AF\u30E9\u30B9\u306E\u30B3\u30FC\u30C9\u3092\u518D\u5B9A\u7FA9\u3057\u307E\u3059\n\ndisablegc <expr>          -- \u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u306E\u30AC\u30D9\u30FC\u30B8\u30FB\u30B3
 \u30EC\u30AF\u30B7\u30E7\u30F3\u3092\u6291\u5236\u3057\u307E\u3059\nenablegc <expr>           -- \u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u306E\u30AC\u30D9\u30FC\u30B8\u30FB\u30B3\u30EC\u30AF\u30B7\u30E7\u30F3\u3092\u8A31\u53EF\u3057\u307E\u3059\n\n!!                        -- \u6700\u5F8C\u306E\u30B3\u30DE\u30F3\u30C9\u3092\u7E70\u308A\u8FD4\u3057\u307E\u3059\n<n> <command>             -- \u30B3\u30DE\u30F3\u30C9\u3092n\u56DE\u7E70\u308A\u8FD4\u3057\u307E\u3059\nrepeat                    -- GDB\u5F62\u5F0F\u306E\u7A7A\u306E\u30B3\u30DE\u30F3\u30C9\u306E\u7E70\u8FD4\u3057\u304C\u6709\u52B9\u306B\u306A\u3063\u3066\u3044\u308B\u304B\u3069\u3046\u304B\u3092\u793A\u3057\u307E\u3059\nrepeat <on|off>           -- GDB\u5F62\u5F0F\u306E\u7E70\u8FD4\u3057\u3092\u6709\u52B9/\u7121\u52B9\u306B\u3057\u307E\u3059\n# <command>               -- \u7834\u68C4\u3057\u307E\u3059(\u64CD\u4F5C\u306A\u3057)\nhelp (\u307E\u305F\u306F?)               -- \u30B3\u30DE\u30F3\u30C9\u3092\u30EA\u30B9\u30C8\u3057\u3
 07E\u3059\ndbgtrace [flag]           -- dbgtrace\u30B3\u30DE\u30F3\u30C9\u30FB\u30E9\u30A4\u30F3\u30FB\u30AA\u30D7\u30B7\u30E7\u30F3\u3068\u540C\u3058\u3067\u3059\nversion                   -- \u30D0\u30FC\u30B8\u30E7\u30F3\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\nexit (\u307E\u305F\u306Fquit)            -- \u30C7\u30D0\u30C3\u30AC\u3092\u7D42\u4E86\u3057\u307E\u3059\n\n<class id>: \u30D1\u30C3\u30B1\u30FC\u30B8\u4FEE\u98FE\u5B50\u3092\u542B\u3080\u5B8C\u5168\u30AF\u30E9\u30B9\u540D\n<class pattern>: \u5148\u982D\u307E\u305F\u306F\u672B\u5C3E\u306E\u30EF\u30A4\u30EB\u30C9\u30AB\u30FC\u30C9('*')\u3092\u542B\u3080\u30AF\u30E9\u30B9\u540D\n<thread id>: 'threads'\u30B3\u30DE\u30F3\u30C9\u3067\u5831\u544A\u3055\u308C\u308B\u30B9\u30EC\u30C3\u30C9\u756A\u53F7\n<expr>: Java(TM)\u30D7\u30ED\u30B0\u30E9\u30DF\u30F3\u30B0\u8A00\u8A9E\u306E\u5F0F\u3002\n\u307B\u3068\u3093\u3069\u306E\u4E00\u822C\u7684\u306A\u69CB\u6587\u304C\u30B5\u30DD\u30FC\u30C8\u3055\u308C\u3066\u3044\u307E\u3059\u
 3002\n\n\u8D77\u52D5\u30B3\u30DE\u30F3\u30C9\u306F\u3001\"jdb.ini\"\u307E\u305F\u306F\".jdbrc\"\u306B\u914D\u7F6E\u3067\u304D\u307E\u3059\n(user.home\u307E\u305F\u306Fuser.dir\u5185)"},

Also as part of #7687 there is a new entry for the `threadgroup` command without any argument. This used to produce the "Threadgroup name not specified" error message which is I mentioned above was removed. It now has supported functionality, so there should be two `threadgroup` entries:

             "threadgroup <name>        -- set current threadgroup to <name>\n" +
             "threadgroup               -- set current threadgroup back to the top level threadgroup\n" +

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java line 305:

> 303:         {"Thread not suspended", "\u672A\u6302\u8D77\u7EBF\u7A0B"},
> 304:         {"thread group number description name", "{0,number,integer}\u3002{1} {2}"},
> 305:         {"Threadgroup name not specified.", "\u672A\u6307\u5B9A\u7EBF\u7A0B\u7EC4\u540D\u3002"},

Same comment here as mentioned in TTYResources_ja.java.

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java line 342:

> 340:         {"watch modification of", "\u76D1\u89C6{0}.{1}\u7684\u4FEE\u6539"},
> 341:         {"zz help text",
> 342:              "** \u547D\u4EE4\u5217\u8868 **\nconnectors                -- \u5217\u51FA\u6B64 VM \u4E2D\u53EF\u7528\u7684\u8FDE\u63A5\u5668\u548C\u4F20\u8F93\n\nrun [class [args]]        -- \u5F00\u59CB\u6267\u884C\u5E94\u7528\u7A0B\u5E8F\u7684\u4E3B\u7C7B\n\nthreads [threadgroup]     -- \u5217\u51FA\u7EBF\u7A0B\nthread <thread id>        -- \u8BBE\u7F6E\u9ED8\u8BA4\u7EBF\u7A0B\nsuspend [thread id(s)]    -- \u6302\u8D77\u7EBF\u7A0B (\u9ED8\u8BA4\u503C: all)\nresume [thread id(s)]     -- \u6062\u590D\u7EBF\u7A0B (\u9ED8\u8BA4\u503C: all)\nwhere [<thread id> | all] -- \u8F6C\u50A8\u7EBF\u7A0B\u7684\u5806\u6808\nwherei [<thread id> | all]-- \u8F6C\u50A8\u7EBF\u7A0B\u7684\u5806\u6808, \u4EE5\u53CA pc \u4FE1\u606F\nup [n frames]             -- \u4E0A\u79FB\u7EBF\u7A0B\u7684\u5806\u6808\ndown [n frames]           -- \u4E0B\u79FB\u7EBF\u7A0B\u7684\u5806\u6808\nkill <thread id> <expr>   -- \u7EC8\u6B62\u5177\u6709\u7ED9\u5B9A\u7684\u5F02\u5E38\u9519\u8BEF\u5BF9\u8C61\u7684\u7EBF\u7A0B
 \ninterrupt <thread id>     -- \u4E2D\u65AD\u7EBF\u7A0B\n\nprint <expr>              -- \u8F93\u51FA\u8868\u8FBE\u5F0F\u7684\u503C\ndump <expr>               -- \u8F93\u51FA\u6240\u6709\u5BF9\u8C61\u4FE1\u606F\neval <expr>               -- \u5BF9\u8868\u8FBE\u5F0F\u6C42\u503C (\u4E0E print \u76F8\u540C)\nset <lvalue> = <expr>     -- \u5411\u5B57\u6BB5/\u53D8\u91CF/\u6570\u7EC4\u5143\u7D20\u5206\u914D\u65B0\u503C\nlocals                    -- \u8F93\u51FA\u5F53\u524D\u5806\u6808\u5E27\u4E2D\u7684\u6240\u6709\u672C\u5730\u53D8\u91CF\n\nclasses                   -- \u5217\u51FA\u5F53\u524D\u5DF2\u77E5\u7684\u7C7B\nclass <class id>          -- \u663E\u793A\u5DF2\u547D\u540D\u7C7B\u7684\u8BE6\u7EC6\u8D44\u6599\nmethods <class id>        -- \u5217\u51FA\u7C7B\u7684\u65B9\u6CD5\nfields <class id>         -- \u5217\u51FA\u7C7B\u7684\u5B57\u6BB5\n\nthreadgroups              -- \u5217\u51FA\u7EBF\u7A0B\u7EC4\nthreadgroup <name>        -- \u8BBE\u7F6E\u5F53\u524D\u7EBF\u7A0B\u7EC4\n\nstop [go|
 thread] [<thread_id>] <at|in> <location>\n                          -- \u8BBE\u7F6E\u65AD\u70B9\n                          -- \u5982\u679C\u672A\u63D0\u4F9B\u4EFB\u4F55\u9009\u9879\uFF0C\u5219\u5C06\u6253\u5370\u5F53\u524D\u65AD\u70B9\u5217\u8868\n                          -- \u5982\u679C\u6307\u5B9A \"go\"\uFF0C\u5219\u5728\u505C\u6B62\u540E\u7ACB\u5373\u6062\u590D\n                          -- \u5982\u679C\u6307\u5B9A \"thread\"\uFF0C\u5219\u4EC5\u6302\u8D77\u5728\u5176\u4E2D\u505C\u6B62\u7684\u7EBF\u7A0B\n                          -- \u5982\u679C\u65E2\u672A\u6307\u5B9A \"go\" \u4E5F\u672A\u6307\u5B9A \"thread\"\uFF0C\u5219\u6302\u8D77\u6240\u6709\u7EBF\u7A0B\n                          -- \u5982\u679C\u6307\u5B9A\u4EE5\u6574\u6570\u8868\u793A\u7684 <thread_id>\uFF0C\u5219\u4EC5\u5728\u6307\u5B9A\u7684\u7EBF\u7A0B\u4E2D\u505C\u6B62\n                          -- \"at\" \u548C \"in\" \u7684\u542B\u4E49\u76F8\u540C\n                          -- <location> \u53EF\u4EE5\u662F\u884C\u53
 F7\u6216\u65B9\u6CD5\uFF1A\n                          --   <class_id>:<line_number>\n                          --   <class_id>.<method>[(argument_type,...)]\nclear <class id>.<method>[(argument_type,...)]\n                          -- \u6E05\u9664\u65B9\u6CD5\u4E2D\u7684\u65AD\u70B9\nclear <class id>:<line>   -- \u6E05\u9664\u884C\u4E2D\u7684\u65AD\u70B9\nclear                     -- \u5217\u51FA\u65AD\u70B9\ncatch [uncaught|caught|all] <class id>|<class pattern>\n                          -- \u51FA\u73B0\u6307\u5B9A\u7684\u5F02\u5E38\u9519\u8BEF\u65F6\u4E2D\u65AD\nignore [uncaught|caught|all] <class id>|<class pattern>\n                          -- \u5BF9\u4E8E\u6307\u5B9A\u7684\u5F02\u5E38\u9519\u8BEF, \u53D6\u6D88 'catch'\nwatch [access|all] <class id>.<field name>\n                          -- \u76D1\u89C6\u5BF9\u5B57\u6BB5\u7684\u8BBF\u95EE/\u4FEE\u6539\nunwatch [access|all] <class id>.<field name>\n                          -- \u505C\u6B62\u76D1\u89C6\u5BF9\u5B57\u6BB5\u7684\u
 8BBF\u95EE/\u4FEE\u6539\ntrace [go] methods [thread]\n                          -- \u8DDF\u8E2A\u65B9\u6CD5\u8FDB\u5165\u548C\u9000\u51FA\u3002\n                          -- \u9664\u975E\u6307\u5B9A 'go', \u5426\u5219\u6302\u8D77\u6240\u6709\u7EBF\u7A0B\ntrace [go] method exit | exits [thread]\n                          -- \u8DDF\u8E2A\u5F53\u524D\u65B9\u6CD5\u7684\u9000\u51FA, \u6216\u8005\u6240\u6709\u65B9\u6CD5\u7684\u9000\u51FA\n                          -- \u9664\u975E\u6307\u5B9A 'go', \u5426\u5219\u6302\u8D77\u6240\u6709\u7EBF\u7A0B\nuntrace [methods]         -- \u505C\u6B62\u8DDF\u8E2A\u65B9\u6CD5\u8FDB\u5165\u548C/\u6216\u9000\u51FA\nstep                      -- \u6267\u884C\u5F53\u524D\u884C\nstep up                   -- \u4E00\u76F4\u6267\u884C, \u76F4\u5230\u5F53\u524D\u65B9\u6CD5\u8FD4\u56DE\u5230\u5176\u8C03\u7528\u65B9\nstepi                     -- \u6267\u884C\u5F53\u524D\u6307\u4EE4\n\u4E0B\u4E00\u6B65                      -- \u6B65\u8FDB\u4E00\u884C (\u6B65\u8FC7\u
 8C03\u7528)\ncont                      -- \u4ECE\u65AD\u70B9\u5904\u7EE7\u7EED\u6267\u884C\n\nlist [line number|method] -- \u8F93\u51FA\u6E90\u4EE3\u7801\nuse (\u6216 sourcepath) [source file path]\n                          -- \u663E\u793A\u6216\u66F4\u6539\u6E90\u8DEF\u5F84\nexclude [<class pattern>, ... | \"none\"]\n                          -- \u5BF9\u4E8E\u6307\u5B9A\u7684\u7C7B, \u4E0D\u62A5\u544A\u6B65\u9AA4\u6216\u65B9\u6CD5\u4E8B\u4EF6\nclasspath                 -- \u4ECE\u76EE\u6807 VM \u8F93\u51FA\u7C7B\u8DEF\u5F84\u4FE1\u606F\n\nmonitor <command>         -- \u6BCF\u6B21\u7A0B\u5E8F\u505C\u6B62\u65F6\u6267\u884C\u547D\u4EE4\nmonitor                   -- \u5217\u51FA\u76D1\u89C6\u5668\nunmonitor <monitor#>      -- \u5220\u9664\u76D1\u89C6\u5668\nread <filename>           -- \u8BFB\u53D6\u5E76\u6267\u884C\u547D\u4EE4\u6587\u4EF6\n\nlock <expr>               -- \u8F93\u51FA\u5BF9\u8C61\u7684\u9501\u4FE1\u606F\nthreadlocks [thread id]   -- \u8F93\u51FA\u7EBF\u7A0B\u7684\u9501
 \u4FE1\u606F\n\npop                       -- \u901A\u8FC7\u5F53\u524D\u5E27\u51FA\u6808, \u4E14\u5305\u542B\u5F53\u524D\u5E27\nreenter                   -- \u4E0E pop \u76F8\u540C, \u4F46\u91CD\u65B0\u8FDB\u5165\u5F53\u524D\u5E27\nredefine <class id> <class file name>\n                          -- \u91CD\u65B0\u5B9A\u4E49\u7C7B\u7684\u4EE3\u7801\n\ndisablegc <expr>          -- \u7981\u6B62\u5BF9\u8C61\u7684\u5783\u573E\u6536\u96C6\nenablegc <expr>           -- \u5141\u8BB8\u5BF9\u8C61\u7684\u5783\u573E\u6536\u96C6\n\n!!                        -- \u91CD\u590D\u6267\u884C\u6700\u540E\u4E00\u4E2A\u547D\u4EE4\n<n> <command>             -- \u5C06\u547D\u4EE4\u91CD\u590D\u6267\u884C n \u6B21\nrepeat                    -- \u663E\u793A\u662F\u5426\u542F\u7528\u4E86 GDB \u6837\u5F0F\u7684\u7A7A\u547D\u4EE4\u91CD\u590D\nrepeat <on|off>           -- \u542F\u7528/\u7981\u7528 GDB \u6837\u5F0F\u7684\u91CD\u590D\n# <command>               -- \u653E\u5F03 (\u65E0\u64CD\u4F5C)\nhelp (\u6216 ?)     
           -- \u5217\u51FA\u547D\u4EE4\ndbgtrace [flag]           -- \u4E0E dbgtrace \u547D\u4EE4\u884C\u9009\u9879\u76F8\u540C\nversion                   -- \u8F93\u51FA\u7248\u672C\u4FE1\u606F\nexit (\u6216 quit)            -- \u9000\u51FA\u8C03\u8BD5\u5668\n\n<class id>: \u5E26\u6709\u7A0B\u5E8F\u5305\u9650\u5B9A\u7B26\u7684\u5B8C\u6574\u7C7B\u540D\n<class pattern>: \u5E26\u6709\u524D\u5BFC\u6216\u5C3E\u968F\u901A\u914D\u7B26 ('*') \u7684\u7C7B\u540D\n<thread id>: 'threads' \u547D\u4EE4\u4E2D\u62A5\u544A\u7684\u7EBF\u7A0B\u7F16\u53F7\n<expr>: Java(TM) \u7F16\u7A0B\u8BED\u8A00\u8868\u8FBE\u5F0F\u3002\n\u652F\u6301\u5927\u591A\u6570\u5E38\u89C1\u8BED\u6CD5\u3002\n\n\u53EF\u4EE5\u5C06\u542F\u52A8\u547D\u4EE4\u7F6E\u4E8E \"jdb.ini\" \u6216 \".jdbrc\" \u4E2D\n\u4F4D\u4E8E user.home \u6216 user.dir \u4E2D"},

Same comment here as mentioned in TTYResources_ja.java.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7765


From duke at openjdk.java.net  Thu Mar 10 19:18:41 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Thu, 10 Mar 2022 19:18:41 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v2]
In-Reply-To: <GNS_FidJndPCJ8cQZcouUYG-EYSLo1VV6mI0ct0u69Y=.dcdaf9d9-5d94-4d61-8db4-a9b739c3d1c3@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <GNS_FidJndPCJ8cQZcouUYG-EYSLo1VV6mI0ct0u69Y=.dcdaf9d9-5d94-4d61-8db4-a9b739c3d1c3@github.com>
Message-ID: <DxmC0LD8DcS91SSCfpIOCVBbN606UmuZefzXZ1AdUWQ=.29ba91a2-6653-4a72-b910-f03d8a0df487@github.com>

On Thu, 10 Mar 2022 18:23:18 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> Previously while tabbing through the JTable cell, the cell highlighter/focus ring was not visible against the selection background. 
>> 
>> Changes are made to Aqua LAF to derive a brighter focus ring color by changing hue, saturation and brightness of selection background color so that it is visible while tabbing through `JTable` cells. A new method is added for this purpose which takes in `selectionBackground` color, does the hue, saturation and brightness manipulation and returns a new focus ring color. There are edge cases where the HSB transformation does not yield the right focus ring color, for these cases a default color is returned that is different and can be seen against the `selectionBackground`.
>> 
>> **Edge Cases**
>> **Selection Background**     -----       **Returned Focus Ring Color**
>> - White/ Black                        ----->          Gray
>> 
>> - Shade of Gray 
>> towards white (r=g=b >= 128)  ----->      Black
>> 
>> - Shade of Gray 
>> towards Black (r=g=b < 128)    ------>     White
>> 
>> A test case is added to compare the RGB difference between the original focus ring color & selection background and the brighter focus ring color & selection background.
>> 
>> PS: The native L&F (Mac OS) and Swing L&F for JTable cell tabbing differs (on native tables the cell background turns white on focus with a cell focus ring). Since the background for Swing tables can be set by users and also overridden by subclassing `DefaultTableCellRenderer`, and to adhere to current implementation of Swing, the cell background changes are not incorporated. Only the Focus Ring/ Cell Highlighter is made more prominent against the selection background.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   formatted line lengths, added method-level comments

Before and After images of cell focus ring changes on SwingSet2. (cell focus on first cell)

![image](https://user-images.githubusercontent.com/95945681/157737713-91694dc9-6bf4-4d3c-8948-59896e952e36.png)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From naoto at openjdk.java.net  Thu Mar 10 19:54:44 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 10 Mar 2022 19:54:44 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2]
In-Reply-To: <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
Message-ID: <oMFrgMwp9G7NK7ODUrjTKrPIFUgFnperV1nrSzNBU_A=.4014965c-a571-40a9-8ed2-40559c24fadb@github.com>

On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved CurrencyNames changes to jdk.localedata

src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_de.properties line 63:

> 61: # written authorization of the copyright holder.
> 62: 
> 63: ADP=ADP

No need for these lines in each localized files, as English bundle contains them.

src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ja.properties line 63:

> 61: # written authorization of the copyright holder.
> 62: 
> 63: ADP=ADP

Same here with `de` bundle.

src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties line 63:

> 61: # written authorization of the copyright holder.
> 62: 
> 63: ADP=ADP

and here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7765


From philip.race at oracle.com  Thu Mar 10 20:47:54 2022
From: philip.race at oracle.com (Philip Race)
Date: Thu, 10 Mar 2022 12:47:54 -0800
Subject: Client Libraries now has an OpenJDK Wiki Page
Message-ID: <43b54c74-c0d8-e24e-386b-6fbb2a925971@oracle.com>

https://wiki.openjdk.java.net/display/ClientLibs is the new group wiki page.

Although we do have a? Group page at : 
https://openjdk.java.net/groups/client-libs/
that web content only editable by Oracle employees whereas the wiki is 
editable
by ANY member of the Client Libraries group listed at 
https://openjdk.java.net/census#client-libs
Login to the wiki in the same way as you login to JBS.

I have added some basic initial content and a child page on test system 
set up based on some notes/wisdom we've been accumulating.

-phil.


From zgu at openjdk.java.net  Thu Mar 10 21:19:03 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 10 Mar 2022 21:19:03 GMT
Subject: RFR: 8282978: Wrong parameter passed to GetStringXXXChars in various
 places
Message-ID: <5CXGspb5JmMAfTBvqIM6lwKqphxffVSdjvOkqtN7oYg=.0ed04b08-bdf0-4339-9180-4101f8b78634@github.com>

Another trivial cleanup to fix the last parameter of `GetStringXXXChars` calls, should be a `jboolean*` instead of a `jboolean`.

-------------

Commit messages:
 - Fix
 - 8282978: Wrong parameter passed to GetStringXXXChars in various places

Changes: https://git.openjdk.java.net/jdk/pull/7779/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7779&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282978
  Stats: 22 lines in 9 files changed: 0 ins; 0 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7779.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7779/head:pull/7779

PR: https://git.openjdk.java.net/jdk/pull/7779


From duke at openjdk.java.net  Thu Mar 10 22:22:29 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Thu, 10 Mar 2022 22:22:29 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v3]
In-Reply-To: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
Message-ID: <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>

> Previously while tabbing through the JTable cell, the cell highlighter/focus ring was not visible against the selection background. 
> 
> Changes are made to Aqua LAF to derive a brighter focus ring color by changing hue, saturation and brightness of selection background color so that it is visible while tabbing through `JTable` cells. A new method is added for this purpose which takes in `selectionBackground` color, does the hue, saturation and brightness manipulation and returns a new focus ring color. There are edge cases where the HSB transformation does not yield the right focus ring color, for these cases a default color is returned that is different and can be seen against the `selectionBackground`.
> 
> **Edge Cases**
> **Selection Background**     -----       **Returned Focus Ring Color**
> - White/ Black                        ----->          Gray
> 
> - Shade of Gray 
> towards white (r=g=b >= 128)  ----->      Black
> 
> - Shade of Gray 
> towards Black (r=g=b < 128)    ------>     White
> 
> A test case is added to compare the RGB difference between the original focus ring color & selection background and the brighter focus ring color & selection background.
> 
> PS: The native L&F (Mac OS) and Swing L&F for JTable cell tabbing differs (on native tables the cell background turns white on focus with a cell focus ring). Since the background for Swing tables can be set by users and also overridden by subclassing `DefaultTableCellRenderer`, and to adhere to current implementation of Swing, the cell background changes are not incorporated. Only the Focus Ring/ Cell Highlighter is made more prominent against the selection background.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  formatting changes to test case

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7768/files
  - new: https://git.openjdk.java.net/jdk/pull/7768/files/ffe3d6ba..d715aa7d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7768&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7768&range=01-02

  Stats: 22 lines in 1 file changed: 7 ins; 1 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7768/head:pull/7768

PR: https://git.openjdk.java.net/jdk/pull/7768


From prr at openjdk.java.net  Fri Mar 11 03:36:50 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 11 Mar 2022 03:36:50 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v3]
In-Reply-To: <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
Message-ID: <oHDYWJF3NuPvNGt67fddARSbf0-09arKk028R1gnCgc=.32d9bbd1-09ac-4896-a9ad-75aa754ef3f0@github.com>

On Fri, 4 Mar 2022 05:07:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert dialogInput. Add Bolditalic

I'm reviewing https://docs.oracle.com/javase/8/docs/technotes/guides/intl/fontconfig.html#windows where it says
The keys have the forms:

        allfonts.CharacterSubsetName
        LogicalFontName.StyleName.CharacterSubsetName
The first form is used if the same font is used for a character subset independent of logical font and style (in this case, the font rendering engines apply algorithmic styles to the font). The second form is used if different physical fonts are used for a character subset for different logical fonts and styles. In this case, properties must be specified for each combination of logical font and style, so 20 properties for one character subset. If a property of the first form is present for a character subset, then properties of the second form for the same character subset are ignored.

So if you remove the allfonts entry, does it pick up serif.plain.korean (etc) ?

And the allfonts entry does (I am fairly sure) then apply to the fallback sequence if there are no "second form" entries, but regardless it seems odd that fallback entries are ignored because the second form is present, but ignored and in turn causing the fallback to be ignored ? 

This does not seem to be working intuitively.
Perhaps it hasn't been much of an issue if serif.plain.korean (etc) generally refers to an existent font that is usually installed and no one needs to worry about the fallback entries. But I think nothing should "hide" fallback entries.

So this may need code changes as well. And that doc may need to be updated ..

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From prr at openjdk.java.net  Fri Mar 11 03:40:46 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 11 Mar 2022 03:40:46 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v3]
In-Reply-To: <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
Message-ID: <AxqPEj6CDyNlhmXG_7ZttrzUwNxqDJ9_YMYcqCoaKsg=.ccdceff0-d279-4a9c-9393-43cca66c1435@github.com>

On Fri, 4 Mar 2022 05:07:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert dialogInput. Add Bolditalic

Hmm .. I have not tried this but a "hack" might be to replace
korean.allfonts
with
korean-fallback.allfonts
and similarly update sequence.fallback to refer to korean-fallback

It is all just name matching so korean could be "foo" and if the duplicate use is the issue that could fix it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From prr at openjdk.java.net  Fri Mar 11 03:49:45 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 11 Mar 2022 03:49:45 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v3]
In-Reply-To: <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
Message-ID: <hOBBwEPB5okFV2RxzriYsfMW4NNS_sJ32dRLSpkofU0=.7eed641f-cbfb-41c7-868e-5c616c7e1082@github.com>

On Fri, 4 Mar 2022 05:07:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert dialogInput. Add Bolditalic

I just did a quick hack test and it looks like it might do it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From prr at openjdk.java.net  Fri Mar 11 05:37:43 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 11 Mar 2022 05:37:43 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v3]
In-Reply-To: <7FJIWE5xd3Fh0W0iu6nmtcuZoWq2cuPDUidpy5l8jjs=.47bc0c69-86c1-43ef-b7da-29d9b6f34af5@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
 <eLpNVkpn7dXZ1qqUsgjHrw8g-gPQEgO-ZHSnQK5l4TQ=.e8fd41f7-41a0-4bc7-8499-36b111bd6f76@github.com>
 <7FJIWE5xd3Fh0W0iu6nmtcuZoWq2cuPDUidpy5l8jjs=.47bc0c69-86c1-43ef-b7da-29d9b6f34af5@github.com>
Message-ID: <R_oVuevCYrDC8StEO17brpgC9NStW-z-DS23yyRe-Ng=.b8d83c07-b325-46c4-a7a8-4bc56df07cae@github.com>

On Sat, 5 Mar 2022 10:35:12 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

>> But serif.plain.korean isn't used unless it is a Korean locale .. so what's the point ?
>> 
>> And this one line already added 
>> allfonts.korean=Malgun Gothic
>> will provide it as a fall back so I don't see the need.
>> If I am an English language user running in a US / UK locale I'll get my Korean glyphs from there with the only difference being it isn't in the same place in the precedence order.
>> This also ensures that any "new" code points added in that font not present in the older ones will always be available.
>
>> But serif.plain.korean isn't used unless it is a Korean locale
> 
> That's not the case, and is easily verifiable for English locale - whatever font is specified there will become a component of Serif composite. 'korean' here is a script id, which is referenced from `sequence.fallback`, used for all locales.
> 
>> And this one line already added
> allfonts.korean=Malgun Gothic
> will provide it as a fall back so I don't see the need.
> 
> That's also not the case. With the patch applied, Serif font still doesn't have Malgun Gothic as a component.
> That line in the current patch has no effect at all - `allfonts.<script>` lines only have an effect for scripts, which don't have assigned fonts in `<composite>.<style>.<script>` properties. 
> 
>> BTW does anyone know if this is a problem for Chinese or Japanese too ?
> I think Indic might have needs a font pack too .. maybe not in this bug but should we be looking wider than Korean ?
> 
> Didn't hear about related problems for Chinese or Japanese, but the same problem exists for Thai script - DokChampa font isn't available by default on Windows 10, and we use Tahoma as a replacement currently.
> 
> BTW, maybe it's worth to create a test case for this problem? As Korean support is explicitly coded in `windows.fontconfig.properties`, it might be good to check that all 20 logical fonts can display Korean on Windows. If a newer Windows version will change the bundled font again, the problem will become apparent at once.

And @JB-Dmitry what did you actually test ? The current PR state ? 
I assume that @prsadhuk tested that before updating the PR.
But the current PR state looks like what you say doesn't work so I am getting confused.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From dbatrak at openjdk.java.net  Fri Mar 11 07:30:41 2022
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Fri, 11 Mar 2022 07:30:41 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v3]
In-Reply-To: <oHDYWJF3NuPvNGt67fddARSbf0-09arKk028R1gnCgc=.32d9bbd1-09ac-4896-a9ad-75aa754ef3f0@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
 <oHDYWJF3NuPvNGt67fddARSbf0-09arKk028R1gnCgc=.32d9bbd1-09ac-4896-a9ad-75aa754ef3f0@github.com>
Message-ID: <u6JAg-K0dnU8KClqTlGAn8HBFt7g7I2YWQPHlmwDocQ=.99df093b-563b-47e6-a146-bf016454ae19@github.com>

On Fri, 11 Mar 2022 03:33:38 GMT, Phil Race <prr at openjdk.org> wrote:

> So if you remove the allfonts entry, does it pick up serif.plain.korean (etc) ?

JDK picks up `<LogicalFontName>.<StyleName>.korean` entries regardless of whether `allfonts.korean` entry is present - the former take precedence over the latter. Yes, it goes against the phrase "If a property of the first form is present for a character subset, then properties of the second form for the same character subset are ignored." in documentation, but that's how code in `sun.awt.FontConfiguration.PropertiesHandler.initBinaryTable()` currently works. Indeed it would be good to fix either the code or the documentation. 

> And the allfonts entry does (I am fairly sure) then apply to the fallback sequence if there are no "second form" entries, but regardless it seems odd that fallback entries are ignored because the second form is present, but ignored and in turn causing the fallback to be ignored ?

Not sure what you mean by fallback entries here. If it's about `sequence.fallback` entries, they aren't ignored, they just use fonts specified by the "second form", not the "first form".

> And @JB-Dmitry what did you actually test ? The current PR state ?

Yes, I tested the latest PR state. Just like the initial PR version, and current code in master, in that state Serif font will display boxes for Korean text, if Korean font pack isn't installed, at least on my Windows 10 machine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From itakiguchi at openjdk.java.net  Fri Mar 11 07:46:43 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Fri, 11 Mar 2022 07:46:43 GMT
Subject: RFR: 8282422: JTable.print() failed with
 UnsupportedCharsetException on AIX ko_KR locale
In-Reply-To: <WoFYqSGq8S5uRqiDH_FJ3ebGeinGkEI1c5_6H7omPnM=.db3d9c13-c0a7-454b-8872-034fec9daedc@github.com>
References: <WoFYqSGq8S5uRqiDH_FJ3ebGeinGkEI1c5_6H7omPnM=.db3d9c13-c0a7-454b-8872-034fec9daedc@github.com>
Message-ID: <npiNznKU7gkMHwci3WgDCVl4_u-giei-3pNNy_XKin0=.c1ee09ed-43c2-405c-b965-3cfa3db73eab@github.com>

On Sat, 26 Feb 2022 16:24:07 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> On AIX ko_KR locale, I could see following exception after JTable.print() was called
> 
> java.nio.charset.UnsupportedCharsetException: sun.font.X11KSC5601
>         at java.base/java.nio.charset.Charset.forName(Charset.java:527)
>         at java.desktop/sun.awt.FontConfiguration.getFontCharsetEncoder(FontConfiguration.java:964)
> ......
> 
> According to my investigation, sun.font.X11KSC5601 moved from sun.awt.motif.X11KSC5601.

May I have a second reviewer, please ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7630


From smandalika at openjdk.java.net  Fri Mar 11 08:37:07 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Fri, 11 Mar 2022 08:37:07 GMT
Subject: RFR: JDK-8282933: Create a test for JDK-4529616
Message-ID: <3d_szd4R6oyDqof-g7sLsV_wkAzuEuma-aXiiUZ03Zw=.6579f560-f11e-4bea-a292-dfcee111a246@github.com>

AccessibleJTableCell.isShowing() returns false when the cell is actually on
the screen.
The test validates the fix for the above issue by verifying that the isShowing call returns true when invoked via the  accessiblity context.

-------------

Commit messages:
 - 8282933:Create a test for JDK-4529616
 - 8282933:Create a test for JDK-4529616

Changes: https://git.openjdk.java.net/jdk/pull/7783/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7783&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282933
  Stats: 82 lines in 1 file changed: 82 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7783.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7783/head:pull/7783

PR: https://git.openjdk.java.net/jdk/pull/7783


From alanb at openjdk.java.net  Fri Mar 11 10:37:40 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 11 Mar 2022 10:37:40 GMT
Subject: RFR: 8282978: Wrong parameter passed to GetStringXXXChars in
 various places
In-Reply-To: <5CXGspb5JmMAfTBvqIM6lwKqphxffVSdjvOkqtN7oYg=.0ed04b08-bdf0-4339-9180-4101f8b78634@github.com>
References: <5CXGspb5JmMAfTBvqIM6lwKqphxffVSdjvOkqtN7oYg=.0ed04b08-bdf0-4339-9180-4101f8b78634@github.com>
Message-ID: <BNMwHhMjYJEFw30ktYz5mTaPUr3SvoZ9u0mY_Uc_2VY=.e4fd2970-18dc-4e4b-884f-3c1b75eba8f1@github.com>

On Thu, 10 Mar 2022 21:12:46 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Another trivial cleanup to fix the last parameter of `GetStringXXXChars` calls, should be a `jboolean*` instead of a `jboolean`.

The changes to the usages in src/java.base look okay.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7779


From dfuchs at openjdk.java.net  Fri Mar 11 10:37:40 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 11 Mar 2022 10:37:40 GMT
Subject: RFR: 8282978: Wrong parameter passed to GetStringXXXChars in
 various places
In-Reply-To: <5CXGspb5JmMAfTBvqIM6lwKqphxffVSdjvOkqtN7oYg=.0ed04b08-bdf0-4339-9180-4101f8b78634@github.com>
References: <5CXGspb5JmMAfTBvqIM6lwKqphxffVSdjvOkqtN7oYg=.0ed04b08-bdf0-4339-9180-4101f8b78634@github.com>
Message-ID: <EXgjOMjqS6Fc5W-zNB0VyC1bkR5mGdvzvGS1J03ube4=.e80155a9-b469-45d0-b3b5-5d2c0d099965@github.com>

On Thu, 10 Mar 2022 21:12:46 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Another trivial cleanup to fix the last parameter of `GetStringXXXChars` calls, should be a `jboolean*` instead of a `jboolean`.

Marked as reviewed by dfuchs (Reviewer).

The `libnet` changes look good to me - but please get someone from the client team to approve the client changes before integrating (though I didn't see any issue with these).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7779


From psadhukhan at openjdk.java.net  Fri Mar 11 12:07:48 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 11 Mar 2022 12:07:48 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack
In-Reply-To: <Ie0Hc_efRCpzXXumHYnU4Z6GPUiDmSbgIU6aMnp3rxM=.4d04cf07-641d-471b-81a2-90b5ba6578b0@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <XKieA-webWAuC43kHFQbwVUcGlHbluLooOWeSoq3NCA=.ba301c32-83d6-4228-b3c6-5e483cf6831c@github.com>
 <Ie0Hc_efRCpzXXumHYnU4Z6GPUiDmSbgIU6aMnp3rxM=.4d04cf07-641d-471b-81a2-90b5ba6578b0@github.com>
Message-ID: <7XnWmGeCX4mglxn05MSaKh4moJuuXe_fGmN8ghDNpsk=.9ab2664c-70f5-4a6a-82ae-7a525427de99@github.com>

On Thu, 3 Mar 2022 07:46:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> There's no chaining mechanism in the way you describe it .. it would have to be in our fallback list.
>> 
>> Batang and Gulim are the fonts that have been available since .. well at least XP.
>> 
>> https://docs.microsoft.com/en-us/typography/font-list/batang
>> 
>> https://docs.microsoft.com/en-us/typography/font-list/gulim
>> 
>> Malun Gothic only came in with Windows 7 :-
>> https://docs.microsoft.com/en-us/typography/font-list/malgun-gothic
>> 
>> I think it reasonable to put malun.ttf in the "allfonts" as a fallback  if it really is pre-installed on ALL systems.
>> 
>> But actual Korean users really should be installing the Korean font pack regardless and then
>> we should pick the best available font. Maybe its the new ones now.
>> 
>> Replacing them would not have been possible in the past but now Vista isn't supported
>> 
>> Note that Gulim is a Sans Serif font, Batang a Serif font.
>> Malun Gothic is described as suitable for on screen display - it sounds like a replacement for Gulim
>> but not for Batang so it is correct you aren't replacing that.
>> But is there a new Serif font available too ?
>> Please investigate / check.
>> 
>> And it seems (ah I see Naoto spotted this too) there is a Bold version of
>> Malgun Gothic in its own ttf file : Malgunbd.ttf So we should start using that.
>> To your point about it not being in the pre-installed fonts it doesn't matter for the reason I gave.
>> 
>> One other thing you are going to have to check is the rendering of other scripts when running in a Korean locale.
>> 
>> Batang lists support for Arabic .. Malun does not .. but then neither does Gulim .. so it may be no worse.
>> 
>> But sequence.fallback doesn't have any obvious Arabic support.
>> We used to be able to count on Lucida Sans for that .. but may be there's another gap there.
>> Mainly make sure you don't increase that gap.
>
>> But is there a new Serif font available too ?
> 
> I could not find any replacement for Batang serif font so have kept it same.
> 
>> Bold version of Malgun Gothic in its own ttf file : Malgunbd.ttf So we should start using that
> 
> Added
> 
>> Arabic support.
> 
> Tested with java/awt/font/NumericShaper/EasternArabicTest and MTTest..Rendered same before and after this fix.

> I assume that @prsadhuk tested that before updating the PR.

I tested with the testcase attached with the bug...not sure of the Serif usage..

![image](https://user-images.githubusercontent.com/43534309/157863549-06e83424-99b5-4cff-9714-ae8ce7f573a9.png)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From psadhukhan at openjdk.java.net  Fri Mar 11 12:50:44 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 11 Mar 2022 12:50:44 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v3]
In-Reply-To: <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
Message-ID: <UQcrUuodpF0jEN8i65mkFlVp9oQK4_thtM3MABU1A_k=.7eaac0ef-03ee-4f7f-b1f0-22b14a79bb17@github.com>

On Fri, 4 Mar 2022 05:07:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert dialogInput. Add Bolditalic

I tested with this test and I got the following output which seems to suggest "serif" korean is working...

BufferedImage bi = new BufferedImage(400, 200, BufferedImage.TYPE_INT_RGB);
        Graphics2D g = bi.createGraphics();
        g.setColor(Color.WHITE);
        g.fillRect(0,0,400,200);
        g.setColor(Color.BLACK);
        g.setFont(new Font("sansserif", Font.PLAIN, 20));
        g.drawString("???", 100, 150);
        g.setFont(new Font("serif", Font.BOLD, 20));
        g.drawString("???", 100, 100);
        ImageIO.write(bi, "png", new File("image.png"));

![image](https://user-images.githubusercontent.com/43534309/157869281-caece0c1-6a79-4a0a-93dc-bec9565709be.png)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From dbatrak at openjdk.java.net  Fri Mar 11 13:08:44 2022
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Fri, 11 Mar 2022 13:08:44 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v3]
In-Reply-To: <UQcrUuodpF0jEN8i65mkFlVp9oQK4_thtM3MABU1A_k=.7eaac0ef-03ee-4f7f-b1f0-22b14a79bb17@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
 <UQcrUuodpF0jEN8i65mkFlVp9oQK4_thtM3MABU1A_k=.7eaac0ef-03ee-4f7f-b1f0-22b14a79bb17@github.com>
Message-ID: <U5wFgDoh9XFCrmGlnirtfm1tLIb42FpksA6fBS4P8Pc=.689581c1-0e4c-493c-bd78-e5e2455c3818@github.com>

On Fri, 11 Mar 2022 12:47:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert dialogInput. Add Bolditalic
>
> I tested with this test and I got the following output which seems to suggest "serif" korean is working...
> 
> BufferedImage bi = new BufferedImage(400, 200, BufferedImage.TYPE_INT_RGB);
>         Graphics2D g = bi.createGraphics();
>         g.setColor(Color.WHITE);
>         g.fillRect(0,0,400,200);
>         g.setColor(Color.BLACK);
>         g.setFont(new Font("sansserif", Font.PLAIN, 20));
>         g.drawString("???", 100, 150);
>         g.setFont(new Font("serif", Font.BOLD, 20));
>         g.drawString("???", 100, 100);
>         ImageIO.write(bi, "png", new File("image.png"));
> 
> ![image](https://user-images.githubusercontent.com/43534309/157869281-caece0c1-6a79-4a0a-93dc-bec9565709be.png)

@prsadhuk Do you have Korean font pack installed? Batang font, in particular.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From psadhukhan at openjdk.java.net  Fri Mar 11 13:24:42 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 11 Mar 2022 13:24:42 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v3]
In-Reply-To: <UQcrUuodpF0jEN8i65mkFlVp9oQK4_thtM3MABU1A_k=.7eaac0ef-03ee-4f7f-b1f0-22b14a79bb17@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
 <UQcrUuodpF0jEN8i65mkFlVp9oQK4_thtM3MABU1A_k=.7eaac0ef-03ee-4f7f-b1f0-22b14a79bb17@github.com>
Message-ID: <GBvjSLit_-Q0FectlKGCP6xa92-r17gMaFMjseUX4b4=.b7a99616-3403-48b6-a6ea-6b7bc5c688de@github.com>

On Fri, 11 Mar 2022 12:47:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert dialogInput. Add Bolditalic
>
> I tested with this test and I got the following output which seems to suggest "serif" korean is working...
> 
> BufferedImage bi = new BufferedImage(400, 200, BufferedImage.TYPE_INT_RGB);
>         Graphics2D g = bi.createGraphics();
>         g.setColor(Color.WHITE);
>         g.fillRect(0,0,400,200);
>         g.setColor(Color.BLACK);
>         g.setFont(new Font("sansserif", Font.PLAIN, 20));
>         g.drawString("???", 100, 150);
>         g.setFont(new Font("serif", Font.BOLD, 20));
>         g.drawString("???", 100, 100);
>         ImageIO.write(bi, "png", new File("image.png"));
> 
> ![image](https://user-images.githubusercontent.com/43534309/157869281-caece0c1-6a79-4a0a-93dc-bec9565709be.png)

> @prsadhuk Do you have Korean font pack installed? Batang font, in particular.

I tested with both Korean pack installed and after uninstalling it...But I have batang.ttc even when I removed korean font pack..

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From zgu at openjdk.java.net  Fri Mar 11 13:28:42 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 11 Mar 2022 13:28:42 GMT
Subject: RFR: 8282978: Wrong parameter passed to GetStringXXXChars in
 various places
In-Reply-To: <BNMwHhMjYJEFw30ktYz5mTaPUr3SvoZ9u0mY_Uc_2VY=.e4fd2970-18dc-4e4b-884f-3c1b75eba8f1@github.com>
References: <5CXGspb5JmMAfTBvqIM6lwKqphxffVSdjvOkqtN7oYg=.0ed04b08-bdf0-4339-9180-4101f8b78634@github.com>
 <BNMwHhMjYJEFw30ktYz5mTaPUr3SvoZ9u0mY_Uc_2VY=.e4fd2970-18dc-4e4b-884f-3c1b75eba8f1@github.com>
Message-ID: <EfGcC-dhLrfyHSVInZVBnAG4kz64UujpJlUw0QyvmPg=.f9f399e1-3de5-4edc-af8d-08b49d087b1e@github.com>

On Fri, 11 Mar 2022 10:33:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Another trivial cleanup to fix the last parameter of `GetStringXXXChars` calls, should be a `jboolean*` instead of a `jboolean`.
>
> The changes to the usages in src/java.base look okay.

Thanks, @AlanBateman @dfuch

-------------

PR: https://git.openjdk.java.net/jdk/pull/7779


From zgu at openjdk.java.net  Fri Mar 11 13:28:42 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 11 Mar 2022 13:28:42 GMT
Subject: Integrated: 8282978: Wrong parameter passed to GetStringXXXChars in
 various places
In-Reply-To: <5CXGspb5JmMAfTBvqIM6lwKqphxffVSdjvOkqtN7oYg=.0ed04b08-bdf0-4339-9180-4101f8b78634@github.com>
References: <5CXGspb5JmMAfTBvqIM6lwKqphxffVSdjvOkqtN7oYg=.0ed04b08-bdf0-4339-9180-4101f8b78634@github.com>
Message-ID: <wEmH-aA323woAamnIrek6fd-j8ewcEWMQysh0tfX9uw=.b540b2b9-1666-4bb7-9f8c-ed2e985a0030@github.com>

On Thu, 10 Mar 2022 21:12:46 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Another trivial cleanup to fix the last parameter of `GetStringXXXChars` calls, should be a `jboolean*` instead of a `jboolean`.

This pull request has now been integrated.

Changeset: 0fd09d38
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0fd09d383b9921f26d2d609ab330630a4520325a
Stats:     22 lines in 9 files changed: 0 ins; 0 del; 22 mod

8282978: Wrong parameter passed to GetStringXXXChars in various places

Reviewed-by: alanb, dfuchs

-------------

PR: https://git.openjdk.java.net/jdk/pull/7779


From alanb at openjdk.java.net  Fri Mar 11 13:37:44 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 11 Mar 2022 13:37:44 GMT
Subject: RFR: 8282978: Wrong parameter passed to GetStringXXXChars in
 various places
In-Reply-To: <BNMwHhMjYJEFw30ktYz5mTaPUr3SvoZ9u0mY_Uc_2VY=.e4fd2970-18dc-4e4b-884f-3c1b75eba8f1@github.com>
References: <5CXGspb5JmMAfTBvqIM6lwKqphxffVSdjvOkqtN7oYg=.0ed04b08-bdf0-4339-9180-4101f8b78634@github.com>
 <BNMwHhMjYJEFw30ktYz5mTaPUr3SvoZ9u0mY_Uc_2VY=.e4fd2970-18dc-4e4b-884f-3c1b75eba8f1@github.com>
Message-ID: <WLTY-zcBWgTtbZzyyxKPEiS0LGNXTjOZWbEQf9Rq618=.f2d90293-6b59-44f4-b125-196c4b84c4e1@github.com>

On Fri, 11 Mar 2022 10:33:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Another trivial cleanup to fix the last parameter of `GetStringXXXChars` calls, should be a `jboolean*` instead of a `jboolean`.
>
> The changes to the usages in src/java.base look okay.

> Thanks, @AlanBateman @dfuch

but make sure to get someone from the client libs area to okay the changes in src/java.desktop.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7779


From smandalika at openjdk.java.net  Fri Mar 11 14:01:44 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Fri, 11 Mar 2022 14:01:44 GMT
Subject: RFR: JDK-8282046: Create a regression test for CCC8000326 [v2]
In-Reply-To: <FtIv0TNvzWFJ2ou3Eiku4QfO_R0fr9kCM8a14_7EocE=.f22595e7-9a17-4389-afe5-30edb3ce2c8d@github.com>
References: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
 <FtIv0TNvzWFJ2ou3Eiku4QfO_R0fr9kCM8a14_7EocE=.f22595e7-9a17-4389-afe5-30edb3ce2c8d@github.com>
Message-ID: <Hyq78cD4ChtTJ6esAcW-jPm8SW3QmJW85w9YJ0zaw58=.b29fd74d-1441-4826-821e-5f2c3950991a@github.com>

On Mon, 28 Feb 2022 11:57:41 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a regression test for CCC8000326
>> 
>> Issue is identified by [JDK-8000326](https://bugs.openjdk.java.net/browse/JDK-8000326), which identifies that after focus moves into JMenuBar, whose focus traversal key is disabled by default, it never moves to other focusable component.
>>  
>> By default, pressing the Tab key does not transfer focus from a JMenuBar which is added to a container together with other Swing components, because the focusTraversalKeysEnabled property of JMenuBar is set to false. To resolve this, you should call the JMenuBar.setFocusTraversalKeysEnabled(true) method.
>>  
>> The test verifies focus traversal for the above described scenario.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: file name changed, volatile dimension, static call to doTest

This review is for migrating tests from a closed test suite to open.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7512


From smandalika at openjdk.java.net  Fri Mar 11 14:01:48 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Fri, 11 Mar 2022 14:01:48 GMT
Subject: RFR: 8282640: Create a test for JDK-4740761
In-Reply-To: <Rr2xSJSr1_1WFxavIZtwz_rlxf15Yvd5dCxZ_1dcggs=.7415074d-6beb-434e-b463-04388e50b0c8@github.com>
References: <Rr2xSJSr1_1WFxavIZtwz_rlxf15Yvd5dCxZ_1dcggs=.7415074d-6beb-434e-b463-04388e50b0c8@github.com>
Message-ID: <lz6QjHkDIYd6ZKk78fDszgBT7VCllKTr5vSEIUeQb_U=.6c4811ed-1284-4775-97d5-9490326da0f4@github.com>

On Fri, 4 Mar 2022 05:35:38 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Create a test for [JDK-4740761](https://bugs.openjdk.java.net/browse/JDK-4740761)
> 
> The issue observed is in a JFrame with a JTextField and a JScrollPane which contains focused component. When the JScrollPane was
> is removed from its parent, focus stays with the the scroller
> of the removed JScrollPane, instead of moving to the TextField.
> 
> The test verifies the same - i.e. it verifies that the removal of the scrollpane moves the focus to the JTextField present in the JFrame.
> This review is for migrating tests from a closed test suite to open.

This review is for migrating tests from a closed test suite to open.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7686


From smandalika at openjdk.java.net  Fri Mar 11 14:24:04 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Fri, 11 Mar 2022 14:24:04 GMT
Subject: RFR: JDK-8283015: Create a test for JDK-4715496
Message-ID: <FZTHpImv7BXOuuYK-42rwC55GssXPQH2S8hwVIvAsfw=.1ba518e0-5c7f-4ed6-a9ce-667a859142c1@github.com>

Create a test for JDK-4715496

Issue observed in the above bug is that the JTable.AccessibleJTableCell.getAccessible name returns the cell instance string instead of the cell text.
The test is being added to verify the same.
This review is for migrating tests from a closed test suite to open.

-------------

Commit messages:
 - 8283015: Create a test for JDK-4715496

Changes: https://git.openjdk.java.net/jdk/pull/7787/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7787&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283015
  Stats: 86 lines in 1 file changed: 86 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7787.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7787/head:pull/7787

PR: https://git.openjdk.java.net/jdk/pull/7787


From smandalika at openjdk.java.net  Fri Mar 11 14:38:28 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Fri, 11 Mar 2022 14:38:28 GMT
Subject: RFR: JDK-8282046: Create a regression test for CCC8000326 [v3]
In-Reply-To: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
References: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
Message-ID: <h8OcXU4ZzuDPAR85ywBYRfgCCexY7DoQEKc6c2eQXXM=.935fbc18-b48b-4e33-8e99-3fbb9a4294d3@github.com>

> Create a regression test for CCC8000326
> 
> Issue is identified by [JDK-8000326](https://bugs.openjdk.java.net/browse/JDK-8000326), which identifies that after focus moves into JMenuBar, whose focus traversal key is disabled by default, it never moves to other focusable component.
>  
> By default, pressing the Tab key does not transfer focus from a JMenuBar which is added to a container together with other Swing components, because the focusTraversalKeysEnabled property of JMenuBar is set to false. To resolve this, you should call the JMenuBar.setFocusTraversalKeysEnabled(true) method.
>  
> The test verifies focus traversal for the above described scenario.
> This review is for migrating tests from a closed test suite to open.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Added @bug keyword

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7512/files
  - new: https://git.openjdk.java.net/jdk/pull/7512/files/c0fcaf89..26adac9d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7512&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7512&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7512.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7512/head:pull/7512

PR: https://git.openjdk.java.net/jdk/pull/7512


From smandalika at openjdk.java.net  Fri Mar 11 14:44:25 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Fri, 11 Mar 2022 14:44:25 GMT
Subject: RFR: 8282640: Create a test for JDK-4740761 [v2]
In-Reply-To: <Rr2xSJSr1_1WFxavIZtwz_rlxf15Yvd5dCxZ_1dcggs=.7415074d-6beb-434e-b463-04388e50b0c8@github.com>
References: <Rr2xSJSr1_1WFxavIZtwz_rlxf15Yvd5dCxZ_1dcggs=.7415074d-6beb-434e-b463-04388e50b0c8@github.com>
Message-ID: <MxC6iXzgDe8DbPKKvE4ZLW8Gr7VmlcgQdqD2T3zRiuo=.a1e71d71-262f-4ac7-b815-254e8045fe87@github.com>

> Create a test for [JDK-4740761](https://bugs.openjdk.java.net/browse/JDK-4740761)
> 
> The issue observed is in a JFrame with a JTextField and a JScrollPane which contains focused component. When the JScrollPane was
> is removed from its parent, focus stays with the the scroller
> of the removed JScrollPane, instead of moving to the TextField.
> 
> The test verifies the same - i.e. it verifies that the removal of the scrollpane moves the focus to the JTextField present in the JFrame.
> This review is for migrating tests from a closed test suite to open.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Added @bug keyword

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7686/files
  - new: https://git.openjdk.java.net/jdk/pull/7686/files/803145c5..44016225

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7686&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7686&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7686.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7686/head:pull/7686

PR: https://git.openjdk.java.net/jdk/pull/7686


From weijun at openjdk.java.net  Fri Mar 11 15:32:52 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 11 Mar 2022 15:32:52 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2]
In-Reply-To: <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
Message-ID: <OJXsIql3eK0cuKV5iLH_tmXrzKQkov7dukuN5CU5FQ4=.fb66f4aa-ff5d-45b9-a6fb-7fcb9c29f5bc@github.com>

On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved CurrencyNames changes to jdk.localedata

The security related changes look fine, except for the year 2021.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7765


From smandalika at openjdk.java.net  Fri Mar 11 15:36:24 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Fri, 11 Mar 2022 15:36:24 GMT
Subject: RFR: JDK-8282777: Create a Regression test for JDK-4515031 [v2]
In-Reply-To: <D8K1EcGCjhQQzplHsgYncKPvGmSPhrAs7RNDIl_pQlo=.e8d60f67-9cf4-4ac7-957b-ddbecffc85de@github.com>
References: <D8K1EcGCjhQQzplHsgYncKPvGmSPhrAs7RNDIl_pQlo=.e8d60f67-9cf4-4ac7-957b-ddbecffc85de@github.com>
Message-ID: <-raG_iRydEjRXVhvPFrPPzvHJl2MvPQcBMO2elN4z84=.f81046b8-d697-4dff-a3dc-0fdd8fdb7dff@github.com>

> Create a Regression test for [JDK-4515031](https://bugs.openjdk.java.net/browse/JDK-4515031)
> 
> The issue indicates the need for a a getAccessibleDescription being implemented for the JFileChooser.
> The test added verifies the same.
> This review is for migrating tests from a closed test suite to open.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Added @bug keyword

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7738/files
  - new: https://git.openjdk.java.net/jdk/pull/7738/files/311b55a0..c239c2c9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7738&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7738&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7738.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7738/head:pull/7738

PR: https://git.openjdk.java.net/jdk/pull/7738


From smandalika at openjdk.java.net  Fri Mar 11 15:39:31 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Fri, 11 Mar 2022 15:39:31 GMT
Subject: RFR: JDK-8282778: Create a regression test for JDK-4699544 [v2]
In-Reply-To: <IDgBuK7aFq5DBF_2mWS-l27LMVG9XSZe-2Zl_bITg3M=.527d9ca4-e081-4ce2-b123-1f2580f5e017@github.com>
References: <IDgBuK7aFq5DBF_2mWS-l27LMVG9XSZe-2Zl_bITg3M=.527d9ca4-e081-4ce2-b123-1f2580f5e017@github.com>
Message-ID: <e15b5kZEOO-Likj62PfSpWiQsFF3aioponmsDrh21EU=.f4538490-131a-4d9c-aff7-b0ce10951973@github.com>

> Create a regression test for JDK-4699544
> 
> The subclass of javax.swing.JRootPane (AccessibleJRootPane) that implements the accessibility interface javax.accessibility.AccessibleComponent is derived from java.awt.AccessibleAWTComponent, which returns null for getAccessibleAt() because a component does not necessarily have childs.
> 
> The root pane always has a content pane child, so getAccessibleAt() should be overwritten by AccessibleJRootPane appropriately.
> The test added verifies the same.
> This review is for migrating tests from a closed test suite to open.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Added @bug keyword

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7739/files
  - new: https://git.openjdk.java.net/jdk/pull/7739/files/508ac461..9ecb27e8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7739&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7739&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7739.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7739/head:pull/7739

PR: https://git.openjdk.java.net/jdk/pull/7739


From smandalika at openjdk.java.net  Fri Mar 11 15:46:32 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Fri, 11 Mar 2022 15:46:32 GMT
Subject: RFR: 8282857: Create a regression test for JDK-4702690 [v2]
In-Reply-To: <jklfp2oMIJWjzE4tz62KCLHfBqlaV0GlyZqk-wUiFHI=.7a721efc-e549-4058-819e-2785e64d9e8d@github.com>
References: <jklfp2oMIJWjzE4tz62KCLHfBqlaV0GlyZqk-wUiFHI=.7a721efc-e549-4058-819e-2785e64d9e8d@github.com>
Message-ID: <4O-Asx5MbywARXyvbWuSaIKgwaRnJkmEuSDu_x5LJ-Y=.bca6b199-c272-4882-8645-51cd11bee03c@github.com>

> Create a regression test for [JDK-4702690](https://bugs.openjdk.java.net/browse/JDK-4702690)
> 
> In many cases in Swing it is possible to easily programatically determine that a JScrollBar (or two) is scrolling some JPanel (the cannonical case is a JScrollPane).
> In these cases, when accessibility support is instantiated (e.g. the AccessibleJScrollBar is created), a Controller_For and Controled_By relation should be instantiated between the AccessibleJScrollBar and the AccessibleJPanel that the JScrollBar and JPanel are associated with.
> 
> This allows various assistive technologies, especially voice-recognition technologies, to better interact with scrolling items.
> 
> The test put up validates that the target object for these properties(CONTROLLED_BY, CONTROLLED_FOR) are set appropriately for JScrollPane and JScrollBar.
> This review is for migrating tests from a closed test suite to open.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Added @bug keyword

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7753/files
  - new: https://git.openjdk.java.net/jdk/pull/7753/files/cda8eccc..f712f33f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7753&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7753&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7753.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7753/head:pull/7753

PR: https://git.openjdk.java.net/jdk/pull/7753


From prr at openjdk.java.net  Fri Mar 11 17:56:52 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 11 Mar 2022 17:56:52 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v3]
In-Reply-To: <u6JAg-K0dnU8KClqTlGAn8HBFt7g7I2YWQPHlmwDocQ=.99df093b-563b-47e6-a146-bf016454ae19@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
 <oHDYWJF3NuPvNGt67fddARSbf0-09arKk028R1gnCgc=.32d9bbd1-09ac-4896-a9ad-75aa754ef3f0@github.com>
 <u6JAg-K0dnU8KClqTlGAn8HBFt7g7I2YWQPHlmwDocQ=.99df093b-563b-47e6-a146-bf016454ae19@github.com>
Message-ID: <EM0rP7NFKs8lBXaB9vtrBfPovoyh6HPxRr7NGNk5bOI=.71022aeb-56f3-49fd-8713-7bbc3b4376fe@github.com>

On Fri, 11 Mar 2022 07:27:32 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

>> And the allfonts entry does (I am fairly sure) then apply to the fallback sequence
>> if there are no "second form" entries, but regardless it seems odd that fallback
>> entries are ignored because the second form is present, but ignored and in turn
>> causing the fallback to be ignored ?

> Not sure what you mean by fallback entries here. If it's about sequence.fallback entries,
> they aren't ignored, they just use fonts specified by the "second form", not the "first form".

Yes, the sequence.fallback but I am relaying my observation that adding
korean.allfonts=..
did not work even though sequence.fallback lists korean whereas adding
korean-foo.allfonts=..
and adding korean-foo into sequence.fallback DID work.

So the "first form" being present in the non-working case is the only difference and infer that it hides the usage of allfonts by the fallback sequence.

Someone would need to follow through the code to see why.

And I did not have the korean font pack installed.

Probably this hiding should be regarded as a bug unless we look and see a good reason for it, but it isn't obvious or documented.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From prr at openjdk.java.net  Fri Mar 11 18:05:44 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 11 Mar 2022 18:05:44 GMT
Subject: RFR: 8282978: Wrong parameter passed to GetStringXXXChars in
 various places
In-Reply-To: <EfGcC-dhLrfyHSVInZVBnAG4kz64UujpJlUw0QyvmPg=.f9f399e1-3de5-4edc-af8d-08b49d087b1e@github.com>
References: <5CXGspb5JmMAfTBvqIM6lwKqphxffVSdjvOkqtN7oYg=.0ed04b08-bdf0-4339-9180-4101f8b78634@github.com>
 <BNMwHhMjYJEFw30ktYz5mTaPUr3SvoZ9u0mY_Uc_2VY=.e4fd2970-18dc-4e4b-884f-3c1b75eba8f1@github.com>
 <EfGcC-dhLrfyHSVInZVBnAG4kz64UujpJlUw0QyvmPg=.f9f399e1-3de5-4edc-af8d-08b49d087b1e@github.com>
Message-ID: <xKM_Y_GLzpvuafmYj1H9WDytaxfF--poyL0bgphvvVU=.ab0a2a09-709d-4625-be65-e7116979d93c@github.com>

On Fri, 11 Mar 2022 13:23:23 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> The changes to the usages in src/java.base look okay.
>
> Thanks, @AlanBateman @dfuch

@zhengyu123 - why did you ignore the request to wait for a client reviewer ?
Over half the files touched are in client ? Might I ask what tests you ran ?
And as far as I can see this was pushed only 16 hours after the RFR went out so you can hardly claim that you waited .. and this surely wasn't urgent.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7779


From dbatrak at openjdk.java.net  Fri Mar 11 18:19:42 2022
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Fri, 11 Mar 2022 18:19:42 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v3]
In-Reply-To: <EM0rP7NFKs8lBXaB9vtrBfPovoyh6HPxRr7NGNk5bOI=.71022aeb-56f3-49fd-8713-7bbc3b4376fe@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
 <oHDYWJF3NuPvNGt67fddARSbf0-09arKk028R1gnCgc=.32d9bbd1-09ac-4896-a9ad-75aa754ef3f0@github.com>
 <u6JAg-K0dnU8KClqTlGAn8HBFt7g7I2YWQPHlmwDocQ=.99df093b-563b-47e6-a146-bf016454ae19@github.com>
 <EM0rP7NFKs8lBXaB9vtrBfPovoyh6HPxRr7NGNk5bOI=.71022aeb-56f3-49fd-8713-7bbc3b4376fe@github.com>
Message-ID: <gn_dX0RP1lSR1cutyc6AZ9rR-ws95jJlXvCaasaEdfU=.1ec661c1-9674-46de-b4da-851e49cad675@github.com>

On Fri, 11 Mar 2022 17:53:12 GMT, Phil Race <prr at openjdk.org> wrote:

> Yes, the sequence.fallback but I am relaying my observation that adding
korean.allfonts=..
did not work even though sequence.fallback lists korean whereas adding
korean-foo.allfonts=..
and adding korean-foo into sequence.fallback DID work.

It's just there are (only) two ways to define Korean (or any other script) font to be used for fallback - either use only one of them for all 20 logical Java fonts (like e.g. it's currently done for Thai language), or configure a different Korean font for each of those 20 fonts separately (like it's currently done in OpenJDK for Korean language). It's not possible to 'mix' those two approaches - by using 'allfonts' entry as a kind of 'fallback' for the case when a specific font doesn't exist. When both ways (forms) are provided in the configuration file, current code picks the 'second' form, ignoring `allfonts` entry. That's why adding `allfonts.korean` in the patch didn't have any effect. But there are no existing entries like `serif.plain.korean-foo`, so adding `allfonts.korean-foo` does have an effect.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From prr at openjdk.java.net  Fri Mar 11 18:38:47 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 11 Mar 2022 18:38:47 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage
In-Reply-To: <2vwMFlely_NGI2XBJ_R58vD6lAqElz39ZWB7U9gavTk=.05c9e4a2-58e6-48d9-9612-2340258ee93c@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <x2z-m3Sq-k2cUBobgCe9KwHBgQFY3fvHa4ZpHld9GHA=.39ce100a-a89a-4247-a265-bf79508b7e1e@github.com>
 <2s6htwoTFM0N9DBj0Ub2zK2TepiNjRuLVJsij4mnXcM=.ba4724c1-aee4-4683-acac-cb6912dc7016@github.com>
 <_Eb1usYXvARXBUeKntPJnjhdArtK4D5MycXBiTcqtTA=.ba1f35c0-aede-4348-b2f6-3370fcaf1d96@github.com>
 <2vwMFlely_NGI2XBJ_R58vD6lAqElz39ZWB7U9gavTk=.05c9e4a2-58e6-48d9-9612-2340258ee93c@github.com>
Message-ID: <ff1wAeY7Sxa0YIlM3ZDDI4TJEyd0ci02_mLC_0EUhPQ=.69d61074-8e2e-4dbf-b8b1-ccb1d5b6b7ca@github.com>

On Thu, 10 Mar 2022 15:59:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> WaitForID() definition states that "If there is an error while loading or scaling an image, then that image is considered to have finished loading". Does this indicates that no error checking is required.....?
>
> But in this case it's the waiting thread that is interrupted. The `MediaTracker` could complete loading the image successfully yet `ImageIcon` instance wouldn't update its `loadStatus` because it removes itself from the media tracker.

We shouldn't be setting any MediaTracker status here - this is the caller ! It would be absolutely wrong. And it seems likely to me that this println was put there by the developer of this code who was him/herself not sure if this would occur and what to do about it so wanted to have a message if it ever occurred so they could figure out how to handle it.
It seems to me that if the thread were interrupted there'd only be a very narrow window in which it likely that the image were complete and that if interrupted then I agree with what I think Alexey is saying which is that the MediaTracker may not have had a chance to even update status since it was interrupted .. depends how sophisticated the implementation is.
Since ImageIcon.getLoadStatus() specifies only 3 possible return values then yes, we should ensure it is one of those . So if it is LOADING then set it to ABORTED .. However a possible wrinkle is that this call being interrupted may not actually prevent the separate threads the MediaTracker kicks off from continuing .. so it may actually be still loading. And it is just that the waiting was interrupted.
Someone would need to dig into MediaTracker to check.
But since the code removes the image from the tracker .. maybe we don't care ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From prr at openjdk.java.net  Fri Mar 11 18:49:52 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 11 Mar 2022 18:49:52 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v3]
In-Reply-To: <6pGT5DmJQoDUOkO7uGHHh3DgPrtciQWTerAigWPh4-4=.85547921-1017-438c-9af4-7e3b90c06bb2@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <6pGT5DmJQoDUOkO7uGHHh3DgPrtciQWTerAigWPh4-4=.85547921-1017-438c-9af4-7e3b90c06bb2@github.com>
Message-ID: <fi8MEGQe9erx0-u_LMq9-q7ALJ1Zf94YIJq3pKHFr64=.5e22a698-3cfc-40d6-bc0c-c4198c243a2f@github.com>

On Wed, 9 Mar 2022 13:35:44 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> The two tests `ScreenCaptureGtkTest.java` and `HiDPIRobotScreenCaptureTest.java` under `java/awt/Robot/HiDPIScreenCapture` started to intermittently fail under Windows and Linux after the [recent changes](https://github.com/openjdk/jdk/commit/cc7cf81256ed4d74493472017b1c4df20fa2208a) made exclusively for the Linux `Robot` implementation.
>> 
>> `HiDPIRobotScreenCaptureTest.java`
>> Since the Windows failures cannot possibly have their origin in the fix made - the latter being Linux-only - the test apparently either exposes an existing bug in the Windows `Robot` or is bumping against a peculiarity of that platform. The test is reverted back to its original form that didn't fail.
>> 
>> `ScreenCaptureGtkTest.java`
>> The coordinates in the log `(83, 78)` of a failure are higher up than the test suggests `(83, 97)`. I've seen similar failures on Ubuntu 20.04 when the coordinates were set to `(0, 0)`. The color then picked matched the color of the bar drawn at the top of the screen. I believe it's best to place the test pixels towards the center of the window to avoid desktop elements interference.
>> 
>> The other possible reason for intermittent failures are window coordinates. Suppose that the test is executing with `sun.java2d.uiScale` set to 2. This effectively means that it can only pick colors of pixels at even coordinates (in the absolute desktop space). So if the window is placed at, say, `(201, 201)`, `Robot` can only pick the color at either `(200, 200)` or `(202, 202)`. Since the test only makes sense if it is pixel-accurate, I removed all `@run`s with `sun.java2d.uiScale` other than 1. This way window placement will not cause a failure.
>> 
>> This was tested on Ubuntu 20.04 and 18.04 with desktop scaling set to 100%, 200%, and 300%.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   HiDPIRobotScreenCaptureTest.java: smaller frame size such that it fits on a 1200x600 screen.
>   
>   ScreenCaptureGtkTest.java: smaller frame size; added code to save
>   the image on failure.

We try to ensure all our test systems have at least a 1920x1080 display and we think it reasonable to require that tests can live with a desktop of that size.

So if we are setting a UI scale then yes, it would be prudent to dial down the user space pixels so it can fit.
I recognise that positioning is another issue but I've never seen a window manager position a window so that it is partially off-screen unless it cannot fit !

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From prr at openjdk.java.net  Fri Mar 11 19:05:44 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 11 Mar 2022 19:05:44 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v2]
In-Reply-To: <FekRgDLssGtJkXCN1Z-po6L4liDWivTfMM0SE2IOdSY=.6c5792c4-3d8f-49f4-a32f-99466c97ae6c@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <FekRgDLssGtJkXCN1Z-po6L4liDWivTfMM0SE2IOdSY=.6c5792c4-3d8f-49f4-a32f-99466c97ae6c@github.com>
Message-ID: <t-7jn4Ie28pUCE9SQNXx29xxGqt-PrXDPn69uxiWFVQ=.df587ede-f510-45e5-86c1-2d00e8556898@github.com>

On Fri, 4 Mar 2022 00:49:39 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - adjusted pixels to check for border
>  - typo
>  - reverted old change, swapped order of painting to prevent overdrawing

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 139:

> 137:         g.translate(x, y);
> 138: 
> 139:         if (etchType == LOWERED) {

So if you think we need to draw the darker colour - shadow - 2nd then please add a comment here.
Also I don't like the repeated blocks of code and I can't follow what they represent
could we have something like
<pre>
drawFoo(Graphics g, Color, c, int w, int h) {
      g.setColor(c);
      g.drawLine(1, h-3, 1, 1);
      g.drawLine(1, 1, w-3, 1);

       g.drawLine(0, h-1, w-1, h-1);
      g.drawLine(w-1, h-1, w-1, 0);
}

drawBar(Graphics g, Color c, int w, int h) {
 g.setColor(c);
 g.drawRect(0, 0, w-2, h-2);
}

then it would become
if (etchType == LOWERED) {
  drawFoo(g, getHighlightColor(c), w, h);
  drawBar(g, getShadowColor(c), w, h);
} else {
  drawBar(g, getHighlightColor(c)w, h);
  drawFoo(g, getShadowColor(c), w, h); 

</pre>
and of course we won't use "Foo" and "Bar" but something that actually represents what these do .. .which really isn't clear to me
Is "Bar" something like "Border" and "Foo" ... hmm I don't know.

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 162:

> 160: 
> 161: 
> 162:         g.translate(-x-1, -y);

Why is this translate changed ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From prr at openjdk.java.net  Fri Mar 11 19:07:57 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 11 Mar 2022 19:07:57 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated
In-Reply-To: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
Message-ID: <XxLXIIQ5Ic7DgNJaLk4xFDNI6zqN8nR1NzxzGkBcZV4=.31c29356-fa7d-40aa-a0b3-6681d8f70555@github.com>

On Fri, 11 Feb 2022 19:20:16 GMT, DamonGuy <duke at openjdk.java.net> wrote:

> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.

What is the current status of this PR ? I can't work it out.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7446


From aivanov at openjdk.java.net  Fri Mar 11 21:49:57 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 11 Mar 2022 21:49:57 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage
In-Reply-To: <ff1wAeY7Sxa0YIlM3ZDDI4TJEyd0ci02_mLC_0EUhPQ=.69d61074-8e2e-4dbf-b8b1-ccb1d5b6b7ca@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <x2z-m3Sq-k2cUBobgCe9KwHBgQFY3fvHa4ZpHld9GHA=.39ce100a-a89a-4247-a265-bf79508b7e1e@github.com>
 <2s6htwoTFM0N9DBj0Ub2zK2TepiNjRuLVJsij4mnXcM=.ba4724c1-aee4-4683-acac-cb6912dc7016@github.com>
 <_Eb1usYXvARXBUeKntPJnjhdArtK4D5MycXBiTcqtTA=.ba1f35c0-aede-4348-b2f6-3370fcaf1d96@github.com>
 <2vwMFlely_NGI2XBJ_R58vD6lAqElz39ZWB7U9gavTk=.05c9e4a2-58e6-48d9-9612-2340258ee93c@github.com>
 <ff1wAeY7Sxa0YIlM3ZDDI4TJEyd0ci02_mLC_0EUhPQ=.69d61074-8e2e-4dbf-b8b1-ccb1d5b6b7ca@github.com>
Message-ID: <12bhwN6rQ-1c7HJtuPK7hrR0zsOeTbv0yYC2_f57v2g=.7f32d881-58e5-4d40-857c-553a855f2d7d@github.com>

On Fri, 11 Mar 2022 18:35:21 GMT, Phil Race <prr at openjdk.org> wrote:

>> But in this case it's the waiting thread that is interrupted. The `MediaTracker` could complete loading the image successfully yet `ImageIcon` instance wouldn't update its `loadStatus` because it removes itself from the media tracker.
>
> We shouldn't be setting any MediaTracker status here - this is the caller ! It would be absolutely wrong. And it seems likely to me that this println was put there by the developer of this code who was him/herself not sure if this would occur and what to do about it so wanted to have a message if it ever occurred so they could figure out how to handle it.
> It seems to me that if the thread were interrupted there'd only be a very narrow window in which it likely that the image were complete and that if interrupted then I agree with what I think Alexey is saying which is that the MediaTracker may not have had a chance to even update status since it was interrupted .. depends how sophisticated the implementation is.
> Since ImageIcon.getLoadStatus() specifies only 3 possible return values then yes, we should ensure it is one of those . So if it is LOADING then set it to ABORTED .. However a possible wrinkle is that this call being interrupted may not actually prevent the separate threads the MediaTracker kicks off from continuing .. so it may actually be still loading. And it is just that the waiting was interrupted.
> Someone would need to dig into MediaTracker to check.
> But since the code removes the image from the tracker .. maybe we don't care ?

Since the image is removed from MediaTracker, its status can't change after that. Therefore `LOADING` status should be changed to `ABORTED`.
[JDK-6421373](https://bugs.openjdk.java.net/browse/JDK-6421373) has a test case which can be modified to load an image and check `loadStatus` of the image.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From duke at openjdk.java.net  Fri Mar 11 23:22:46 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Fri, 11 Mar 2022 23:22:46 GMT
Subject: Withdrawn: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated
In-Reply-To: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
Message-ID: <an0WUIR4kkH1N8rdzlmfpTN6LvJU_BtsiuUXkZIiNAs=.7c148a52-632a-4c33-9c51-4a95b1b3efd2@github.com>

On Fri, 11 Feb 2022 19:20:16 GMT, DamonGuy <duke at openjdk.java.net> wrote:

> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7446


From duke at openjdk.java.net  Fri Mar 11 23:22:46 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Fri, 11 Mar 2022 23:22:46 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated
In-Reply-To: <XxLXIIQ5Ic7DgNJaLk4xFDNI6zqN8nR1NzxzGkBcZV4=.31c29356-fa7d-40aa-a0b3-6681d8f70555@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <XxLXIIQ5Ic7DgNJaLk4xFDNI6zqN8nR1NzxzGkBcZV4=.31c29356-fa7d-40aa-a0b3-6681d8f70555@github.com>
Message-ID: <Owl-7L83KR54vuXtemNAEZ8rvwijD2BOXHA2zAVpON0=.7f35f198-6bc9-4a7e-8135-e5fa8d0d281c@github.com>

On Fri, 11 Mar 2022 19:04:27 GMT, Phil Race <prr at openjdk.org> wrote:

> What is the current status of this PR ? I can't work it out.

I spent time to double check script tag contents. The script tag's behavior Jay mentioned is correct from the traces I made as well. So I wrote a test with a JEditorPane loading HTML from a file, but couldn't get HTML buttons to render properly in JEditorPane. I wanted HTML buttons to test a foo function encased in script tags in my HTML file to see if script tags are parsed or just ignored via a proper test.

Since this took longer than expected, it was suggested that I put this issue aside to finish other issues I was working on before returning.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7446


From duke at openjdk.java.net  Fri Mar 11 23:23:03 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Fri, 11 Mar 2022 23:23:03 GMT
Subject: RFR: 8024624: [TEST_BUG] [macosx] CTRL+RIGHT(LEFT) doesn't move
 selection on next cell in JTable on Aqua L&F
Message-ID: <LdWWDPfwqpCC-_EBaYQLX4rFIyV9FLAG5ugIJb0ruI4=.bc296640-5df9-41a1-b857-14f334c1be8e@github.com>

Aqua L&F tables lacked support for `CTRL+ARROW`, `CTRL+PG_UP/DOWN`, and `CTRL+SHIFT+PG_UP/DOWN` key bindings. This allows for navigation and selection of table cells without the need of a mouse and without deselecting the current selected cell group. 

Those key bindings are added to Aqua's key bindings for tables. The `SPACE` key binding was also added because it allows for the selection of cells after navigating using the `CTRL+ARROW` bindings, and some of the new bindings are only useful with the `SPACE` binding added. The closed test that this bug originates from tests for both left-to-right and right-to-left functionality, so the new directional bindings are also added to the right-to-left key bindings table where needed.

This requires mission control shortcuts in macOS to be disabled as `CTRL+ARROW` keys are normally used for virtual desktop navigation.

-------------

Commit messages:
 - Organized the RTL bindings for Aqua JTable as well.
 - Organized additional key bindings to better match Metal bindings.
 - Added additional key bindings for Aqua JTable.

Changes: https://git.openjdk.java.net/jdk/pull/7792/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7792&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8024624
  Stats: 34 lines in 1 file changed: 27 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7792.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7792/head:pull/7792

PR: https://git.openjdk.java.net/jdk/pull/7792


From serb at openjdk.java.net  Sat Mar 12 00:10:43 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 12 Mar 2022 00:10:43 GMT
Subject: RFR: 8024624: [TEST_BUG] [macosx] CTRL+RIGHT(LEFT) doesn't move
 selection on next cell in JTable on Aqua L&F
In-Reply-To: <LdWWDPfwqpCC-_EBaYQLX4rFIyV9FLAG5ugIJb0ruI4=.bc296640-5df9-41a1-b857-14f334c1be8e@github.com>
References: <LdWWDPfwqpCC-_EBaYQLX4rFIyV9FLAG5ugIJb0ruI4=.bc296640-5df9-41a1-b857-14f334c1be8e@github.com>
Message-ID: <i7w4_YI08R-jGwPNIeZG_4UEo-0yv1noFlu-nwX8L4A=.e57943be-1ed6-4a21-8935-28831c8984cc@github.com>

On Fri, 11 Mar 2022 23:13:15 GMT, DamonGuy <duke at openjdk.java.net> wrote:

> Aqua L&F tables lacked support for `CTRL+ARROW`, `CTRL+PG_UP/DOWN`, and `CTRL+SHIFT+PG_UP/DOWN` key bindings. This allows for navigation and selection of table cells without the need of a mouse and without deselecting the current selected cell group. 
> 
> Those key bindings are added to Aqua's key bindings for tables. The `SPACE` key binding was also added because it allows for the selection of cells after navigating using the `CTRL+ARROW` bindings, and some of the new bindings are only useful with the `SPACE` binding added. The closed test that this bug originates from tests for both left-to-right and right-to-left functionality, so the new directional bindings are also added to the right-to-left key bindings table where needed.
> 
> This requires mission control shortcuts in macOS to be disabled as `CTRL+ARROW` keys are normally used for virtual desktop navigation.

What shortcuts are used by the native macOS applications for such navigation? Aqua should align bihaviour to the native app and not other cross platform L&F or windows/linux.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7792


From prr at openjdk.java.net  Sat Mar 12 00:38:45 2022
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 12 Mar 2022 00:38:45 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated
In-Reply-To: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
Message-ID: <HmcDQVUPGwfIaQgZklq5ECPg9LssgjV5Xdjwg7bZgAc=.3df233a0-1741-4db8-b458-30c1f46dcd2a@github.com>

On Fri, 11 Feb 2022 19:20:16 GMT, DamonGuy <duke at openjdk.java.net> wrote:

> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.

Ok. For future reference, you also have the option of moving a PR back to "Draft" using a button somewhere top right of the web page.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7446


From duke at openjdk.java.net  Sat Mar 12 01:29:44 2022
From: duke at openjdk.java.net (duke)
Date: Sat, 12 Mar 2022 01:29:44 GMT
Subject: Withdrawn: 8181571: printing to CUPS fails on mac sandbox app
In-Reply-To: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com>
References: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com>
Message-ID: <PILyLGCDG7MNdxK0AmVc_9gUXjxNsJhtVRRGKaLvbco=.7c62aede-2331-49e1-ab18-29d0268adf29@github.com>

On Wed, 21 Jul 2021 15:45:55 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> The issue is reproduced on macOS Big Sur 11.0.1 with jdk 16.0.1+9.
> 
> Create a native macOS app from the Hello.java file, sign and run it in sandbox:
> 
> import javax.print.*;
> import javax.swing.*;
> 
> public class Hello {
> 
>     public static void main(String[] args) throws Exception {
>         SwingUtilities.invokeAndWait(() -> {
>             boolean isSandboxed = System.getenv("APP_SANDBOX_CONTAINER_ID") != null;
>             PrintService defaultPrinter = PrintServiceLookup.lookupDefaultPrintService();
>             PrintService[] services = PrintServiceLookup.lookupPrintServices(null, null);
> 
>             StringBuilder builder = new StringBuilder();
>             builder.append("is sandboxed: ").append(isSandboxed).append("\n");
>             builder.append("default printer: ").append(defaultPrinter).append("\n");
>             int size = services.length;
>             for (int i = 0; i < size; i++) {
>                 builder.append("printer[").append(i).append("]=").append(services[i]).append("\n");
>             }
>             JOptionPane.showMessageDialog(null, builder.toString());
>         });
>     }
> }
> 
> The signed app in sandbox shows null default printer and PrintServiceLookup.lookupPrintServices(null, null) returns "Unix Printer: lp".
> ![PrintSandboxedApp](https://bugs.openjdk.java.net/secure/attachment/95629/PrintSandboxedApp.png)
> 
> The problem has been discussed on  2d-dev mail list:
>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-June/008375.html
>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-July/008418.html
> 
> According to the discussion:
> 
>> I've submitted a DTS incident to Apple and a friend there has followed-up.
>> Their unofficial position is that java should be connecting to the cups interface returned
>> by the cupsServer() function and not changing the interface string to "localhost".
>> Security changes in 10.12.4 reject the TCP connection which they say confuses
>> network-client access with print access.  They don't seem interested in loosening that change.
> 
> 
> The proposed solution is to use the domain socket pathname in httpConnect(...) cups function and cupsGetDests(...) to get list of printers from cups  when the app is signed and is run in sandbox on MacOs.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4861


From duke at openjdk.java.net  Sat Mar 12 01:30:38 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Sat, 12 Mar 2022 01:30:38 GMT
Subject: RFR: 8024624: [TEST_BUG] [macosx] CTRL+RIGHT(LEFT) doesn't move
 selection on next cell in JTable on Aqua L&F
In-Reply-To: <i7w4_YI08R-jGwPNIeZG_4UEo-0yv1noFlu-nwX8L4A=.e57943be-1ed6-4a21-8935-28831c8984cc@github.com>
References: <LdWWDPfwqpCC-_EBaYQLX4rFIyV9FLAG5ugIJb0ruI4=.bc296640-5df9-41a1-b857-14f334c1be8e@github.com>
 <i7w4_YI08R-jGwPNIeZG_4UEo-0yv1noFlu-nwX8L4A=.e57943be-1ed6-4a21-8935-28831c8984cc@github.com>
Message-ID: <7T7g_WIUi3-5wTGIJIUFEUWt4zJoYMM6jnEQFG87n-I=.837d0723-d797-4f43-bf41-d5ab973b685c@github.com>

On Sat, 12 Mar 2022 00:07:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> What shortcuts are used by the native macOS applications for such navigation? Aqua should align bihaviour to the native app and not other cross platform L&F or windows/linux.

The only shortcuts that allow for non-adjacent cell selection on tables is `COMMAND+LEFT_CLICK`. This requires the use of a mouse on top of keyboard inputs.

Apple Pages has no support at all for these table navigation functions other than `COMMAND+LEFT_CLICK`. Excel has a selection mode that can be toggled on/off using SHIFT+F8. I also tested in macOS's `System Preferences > Keyboard > Text` and `CMD+CLICK` is the only supported way to select non-adjacent cells as well.

The two paths to fixing this issue was either adding the shortcuts and functionality to Aqua L&F tables or to make the test exclude macOS. The benefit of adding the shortcuts to Aqua allows for users to navigate without the need for a mouse or touchpad. The Oracle doc for tables [here](https://docs.oracle.com/javase/tutorial/uiswing/components/table.html) shows that `CTRL+ARROW` is a supported keyboard action as an alternative for `CTRL+CLICK`, and has no mention of excluding macOS or Aqua L&F. 

So, I thought it is appropriate to add the shortcuts to Aqua, but I can make changes if needed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7792


From duke at openjdk.java.net  Sun Mar 13 01:45:42 2022
From: duke at openjdk.java.net (duke)
Date: Sun, 13 Mar 2022 01:45:42 GMT
Subject: Withdrawn: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy
In-Reply-To: <rlwasPohJ8GF9X1_VT4k5fnUxLp6SKb3c1Da1pHGcUg=.5bcce64c-3ef4-4f37-9f3e-b72ff3e5ed7e@github.com>
References: <rlwasPohJ8GF9X1_VT4k5fnUxLp6SKb3c1Da1pHGcUg=.5bcce64c-3ef4-4f37-9f3e-b72ff3e5ed7e@github.com>
Message-ID: <YtwjLYWE2qkqPRfI_FeqYcw4VN-nkfFBhnqSTli3-CI=.a0417fa5-4134-4978-8ea9-95f7cfec4417@github.com>

On Sat, 15 Jan 2022 23:22:19 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).
> 
> It also contains a fix for the subset of [JDK-8278620](https://bugs.openjdk.java.net/browse/JDK-8278620) necessary for the test to pass with the updated serialized objects.
> 
> See also discussion in https://git.openjdk.java.net/jdk/pull/6603

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7100


From mvs at openjdk.java.net  Sun Mar 13 13:49:19 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Sun, 13 Mar 2022 13:49:19 GMT
Subject: RFR: 8282860: Write a regression test for JDK-4164779
Message-ID: <P0Nh5jqNbGyTlAXOw-82iw2zJl61Tf9iUKDq4OOH9rE=.34986f4d-60e5-4430-862f-91ea34620c2f@github.com>

Write a regression test for [JDK-4164779](https://bugs.openjdk.java.net/browse/JDK-4164779) : JSplitPane keyboard navigation does not support F6 and Ctrl+Tab
Context: Migrating tests from a closed tonga based test suite to open regression based one.

Issue:
The specified keyboard support for JSplitPane also requires F6 and Ctrl+Tab (navigate out) for the JSplitPane. Those are currently not implemented.

F6 is supposed to move the focus from the current focused component on one side of the JSplitPane to the other side of the JSplitPane without having to tab through to that.

Ctrl+Tab is supposed to move the input focus from whatever component inside the JSplitPane that has the focus to the next component outside the JSplitPane.


Testing:
Java 1.4.0 -> Test Failed.
$ ./j2sdk1.4.0/bin/java JSplitPaneTest
Verifier 1 failed
Verifier 2 failed
Verifier 3 failed
Verifier 4 failed
Test Failed.

Java 1.4.1 -> Test Passed.
$ ./j2sdk1.4.1/bin/java JSplitPaneTest
Verifier 1 passed
Verifier 2 passed
Verifier 3 passed
Verifier 4 passed
Test Passed.

-------------

Commit messages:
 - 8282860: Write a regression test for JDK-4164779

Changes: https://git.openjdk.java.net/jdk/pull/7801/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7801&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282860
  Stats: 198 lines in 1 file changed: 198 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7801.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7801/head:pull/7801

PR: https://git.openjdk.java.net/jdk/pull/7801


From mvs at openjdk.java.net  Sun Mar 13 14:01:25 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Sun, 13 Mar 2022 14:01:25 GMT
Subject: RFR: 8282860: Write a regression test for JDK-4164779 [v2]
In-Reply-To: <P0Nh5jqNbGyTlAXOw-82iw2zJl61Tf9iUKDq4OOH9rE=.34986f4d-60e5-4430-862f-91ea34620c2f@github.com>
References: <P0Nh5jqNbGyTlAXOw-82iw2zJl61Tf9iUKDq4OOH9rE=.34986f4d-60e5-4430-862f-91ea34620c2f@github.com>
Message-ID: <9xEXTZSoDUKzYfNcIq1aUdM-k2E7ZlhRZe-CpYZlhaE=.9623ad32-bd07-42bb-994b-42af1605997d@github.com>

> Write a regression test for [JDK-4164779](https://bugs.openjdk.java.net/browse/JDK-4164779) : JSplitPane keyboard navigation does not support F6 and Ctrl+Tab
> Context: Migrating tests from a closed tonga based test suite to open regression based one.
> 
> Issue:
> The specified keyboard support for JSplitPane also requires F6 and Ctrl+Tab (navigate out) for the JSplitPane. Those are currently not implemented.
> 
> F6 is supposed to move the focus from the current focused component on one side of the JSplitPane to the other side of the JSplitPane without having to tab through to that.
> 
> Ctrl+Tab is supposed to move the input focus from whatever component inside the JSplitPane that has the focus to the next component outside the JSplitPane.
> 
> 
> Testing:
> Java 1.4.0 -> Test Failed.
> $ ./j2sdk1.4.0/bin/java JSplitPaneTest
> Verifier 1 failed
> Verifier 2 failed
> Verifier 3 failed
> Verifier 4 failed
> Test Failed.
> 
> Java 1.4.1 -> Test Passed.
> $ ./j2sdk1.4.1/bin/java JSplitPaneTest
> Verifier 1 passed
> Verifier 2 passed
> Verifier 3 passed
> Verifier 4 passed
> Test Passed.

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Added Copyright header

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7801/files
  - new: https://git.openjdk.java.net/jdk/pull/7801/files/4eb3365c..14b67eb6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7801&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7801&range=00-01

  Stats: 24 lines in 1 file changed: 23 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7801.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7801/head:pull/7801

PR: https://git.openjdk.java.net/jdk/pull/7801


From mvs at openjdk.java.net  Sun Mar 13 14:02:02 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Sun, 13 Mar 2022 14:02:02 GMT
Subject: RFR: 8282936: Write a regression test for JDK-4615365
Message-ID: <9V6N62EUXtJ_TlONZHRMlwpDU3Pqymgs7daipoaSrB4=.f9110cf2-ba95-4e23-a93d-45ba5dbfeca2@github.com>

Write a regression test for [JDK-4615365](https://bugs.openjdk.java.net/browse/JDK-4615365) : JSplitPane current and last divider positions incorrect when realized

Issue:
JSplitPane component with a left and right component has its current divider
position incorrectly set to -1 once it is fully realized. For JDK 1.3.1, its
value is set to 0. The current position of the divider should be the current
position of the divider once layout management is complete. If the divider is
moved one pixel, the current divider position is updated to the correct value
but the last divider position is then set to -1 (i.e. the last value of the
current divider position). If the divider is moved again, everything is OK.

Testing:
Java 1.4.0 -> Test Failed.
$ j2sdk1.4.0/bin/java bug4615365
current= -1, last= 0
Test Failed.

Java 1.4.1 -> Test Passed.
$ j2sdk1.4.1/bin/java bug4615365
current= 97, last= -1
Test Passed.

-------------

Commit messages:
 - 8282936: Write a regression test for JDK-4615365

Changes: https://git.openjdk.java.net/jdk/pull/7802/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7802&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282936
  Stats: 183 lines in 1 file changed: 183 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7802.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7802/head:pull/7802

PR: https://git.openjdk.java.net/jdk/pull/7802


From mvs at openjdk.java.net  Sun Mar 13 14:16:13 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Sun, 13 Mar 2022 14:16:13 GMT
Subject: RFR: 8282937: Write a regression test for JDK-4820080
Message-ID: <4bbhbCGRMxaAZkJPXi3B79QCUehtUtB5OuhmtCEm3Vw=.8a6e03c0-3215-48eb-8a6e-9c57cf01b095@github.com>

Write a regression test for [JDK-4820080](https://bugs.openjdk.java.net/browse/JDK-4820080) : RFE: Cannot Change the JSplitPane Divider Color while dragging

Issue(as per bug description):
I want to change the color of the JSplitPane divider. I
opened the code and found that, the color is hard coded to
darkGray while one is dragging the splitDivider. I have an
application where the components on SplitPane have black
background, So when i drag I can not see the split getting
dragged. Can some one fix this, by externelising the
SplitDivider color so that it can be changed at run time.

Testing:
Java 1.4.1 -> Test Failed.
$ ./j2sdk1.4.1/bin/java JSplitPaneDragColorTest
Metal uses correct drag color false
CDE/Motif uses correct drag color false
Windows uses correct drag color false
Test Failed.

Java 1.5.0 -> Test Failed.
$ ./jdk1.5.0/bin/java JSplitPaneDragColorTest
Metal uses correct drag color true
Windows uses correct drag color true
Windows Classic uses correct drag color true
Test Passed.

-------------

Commit messages:
 - 8282937: Write a regression test for JDK-4820080

Changes: https://git.openjdk.java.net/jdk/pull/7803/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7803&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282937
  Stats: 194 lines in 1 file changed: 194 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7803.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7803/head:pull/7803

PR: https://git.openjdk.java.net/jdk/pull/7803


From kizune at openjdk.java.net  Sun Mar 13 21:16:07 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sun, 13 Mar 2022 21:16:07 GMT
Subject: RFR: 8282526: Default icon is not painted properly
Message-ID: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>

Detect the situation where we do need to perform interpolation during ImageIcon
painting and set a hint to the rendering to perform bicubic approximation so
image details are preserved during transition.

-------------

Commit messages:
 - 8282526: Default icon is not painted properly

Changes: https://git.openjdk.java.net/jdk/pull/7805/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7805&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282526
  Stats: 153 lines in 3 files changed: 148 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7805.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7805/head:pull/7805

PR: https://git.openjdk.java.net/jdk/pull/7805


From kizune at openjdk.java.net  Sun Mar 13 21:16:07 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sun, 13 Mar 2022 21:16:07 GMT
Subject: RFR: 8282526: Default icon is not painted properly
In-Reply-To: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
Message-ID: <cZLsQAkt3yYGipvTXzX5Iy_1MlbmgUva2OHgt4FIm-U=.14a652d5-26b9-4cb9-be72-a8bd71886fcf@github.com>

On Sun, 13 Mar 2022 21:06:24 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Detect the situation where we do need to perform interpolation during ImageIcon
> painting and set a hint to the rendering to perform bicubic approximation so
> image details are preserved during transition.

The icon returned by the system is 32x32 icon that looks like this:
![FileIcon](https://user-images.githubusercontent.com/69642324/158079313-800ba0de-d009-4b6a-8b08-de71bf18b106.png)
After approximation to the 16x16 with nearest neighbor  it now looks like this:
![FileIconNearest](https://user-images.githubusercontent.com/69642324/158079342-b1f111fd-7f9c-4eda-af59-59a25d236fb9.png)
So the significant details are lost and the resulting icon looks cropped. After the fix the icon in the test looks fine:
![FileIconBiqubic](https://user-images.githubusercontent.com/69642324/158079416-65cb3dcd-514f-4a9b-9677-c12ae9312792.png)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7805


From duke at openjdk.java.net  Sun Mar 13 23:31:44 2022
From: duke at openjdk.java.net (Jeremy)
Date: Sun, 13 Mar 2022 23:31:44 GMT
Subject: RFR: 8282526: Default icon is not painted properly
In-Reply-To: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
Message-ID: <rWCyzbxnTraucb96bdEvdDEv7Dx0SdlW0ur1RFoTzMA=.0c697691-3dba-476b-80ac-2a8f0306cf80@github.com>

On Sun, 13 Mar 2022 21:06:24 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Detect the situation where we do need to perform interpolation during ImageIcon
> painting and set a hint to the rendering to perform bicubic approximation so
> image details are preserved during transition.

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 463:

> 461:         if (hintChanged) {
> 462:             ((Graphics2D) g).setRenderingHint(RenderingHints.KEY_INTERPOLATION,
> 463:                     oldHint == null ? RenderingHints.VALUE_INTERPOLATION_NEAREST_NEIGHBOR : oldHint);

This might be a rookie question:

When it comes to modifying and restoring a Graphics, I've seen two common patterns:
A. Call `newG = g.create()` and later `newG.dispose()`
B. Call `g.setX(newValue)` and then call `g.setX(oldValue)` later

Is there guidance on when to use which? Or is one always preferred?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7805


From kizune at openjdk.java.net  Mon Mar 14 01:50:48 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 14 Mar 2022 01:50:48 GMT
Subject: RFR: 8282526: Default icon is not painted properly
In-Reply-To: <rWCyzbxnTraucb96bdEvdDEv7Dx0SdlW0ur1RFoTzMA=.0c697691-3dba-476b-80ac-2a8f0306cf80@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <rWCyzbxnTraucb96bdEvdDEv7Dx0SdlW0ur1RFoTzMA=.0c697691-3dba-476b-80ac-2a8f0306cf80@github.com>
Message-ID: <ykpowK0z6aNXzTun2818uIhiF1V-VIF5ZTzmWtaGKDk=.ebb3750e-f8f0-4e81-9358-be6a6618e259@github.com>

On Sun, 13 Mar 2022 23:28:01 GMT, Jeremy <duke at openjdk.java.net> wrote:

> This might be a rookie question:
> 
> When it comes to modifying and restoring a Graphics, I've seen two common patterns: A. Call `newG = g.create()` and later `newG.dispose()` B. Call `g.setX(newValue)` and then call `g.setX(oldValue)` later
> 
> Is there guidance on when to use which? Or is one always preferred?

Usually i follow the rule of minimal action. When i need to set a lot of hints that needs to be later unrolled such as changing graphics coordinates and such - i'm creating a new Graphics. When i only need to manipulate a single hint and it can easily be unrolled - i am using the same object. In this case i'm changing just a single hint.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7805


From duke at openjdk.java.net  Mon Mar 14 02:32:44 2022
From: duke at openjdk.java.net (Jeremy)
Date: Mon, 14 Mar 2022 02:32:44 GMT
Subject: RFR: 8282526: Default icon is not painted properly
In-Reply-To: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
Message-ID: <JwSc0m39F3Fq8zZn27a77G166ydpKoExnQqHObthslM=.bd8445fc-9b59-4ca5-843b-6b89a8fcbee2@github.com>

On Sun, 13 Mar 2022 21:06:24 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Detect the situation where we do need to perform interpolation during ImageIcon
> painting and set a hint to the rendering to perform bicubic approximation so
> image details are preserved during transition.

test/jdk/javax/swing/ImageIcon/MultiResolutionImageIcon.java line 127:

> 125:         return null;
> 126:     }
> 127: }

This test reads a little strange to me. (I'm not an official openjdk reviewer, though, so feel free to disregard.)

If I run this test with the existing ImageIcon class it creates an image that resembles:
![image](https://user-images.githubusercontent.com/7669569/158093894-be7a73c6-6936-4725-bb09-cd054a2dccc2.png)

If I run this test with the revised code it creates an image that resembles:
![image](https://user-images.githubusercontent.com/7669569/158093939-bffc62c7-7a5c-4b0e-b71e-710c5049daf6.png)

Based on the changes in ImageIcon: I only expected to see changes related to rendering hints. (That is: I expected to see differences in antialiasing and scaling artifacts.)

Would you mind if I proposed a different test?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7805


From dbatrak at openjdk.java.net  Mon Mar 14 04:26:43 2022
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Mon, 14 Mar 2022 04:26:43 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v3]
In-Reply-To: <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
Message-ID: <Yu60xcJmK2GCi1XFs_qN2UnxccOx3GkW2JVt3RE2DZc=.3687c143-14e5-47ed-a1c1-0f9310c5aae7@github.com>

On Fri, 4 Mar 2022 05:07:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert dialogInput. Add Bolditalic

It's a bit hard to talk about 'fallback' fonts here without confusion, as this word might mean at least two things - we have Korean fallback fonts, in a sense that `sequence.fallback` contains `korean` entry, so all logical fonts are supposed to support Korean. And we also want e.g. Batang font to 'fallback' to Malgun Gothic, if Batang font is not installed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From psadhukhan at openjdk.java.net  Mon Mar 14 04:26:43 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 14 Mar 2022 04:26:43 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v3]
In-Reply-To: <Yu60xcJmK2GCi1XFs_qN2UnxccOx3GkW2JVt3RE2DZc=.3687c143-14e5-47ed-a1c1-0f9310c5aae7@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
 <Yu60xcJmK2GCi1XFs_qN2UnxccOx3GkW2JVt3RE2DZc=.3687c143-14e5-47ed-a1c1-0f9310c5aae7@github.com>
Message-ID: <6xs4-PbuPxBkxDverzrbM1V63pQpwxUebjo5JpQqcGg=.b7042da0-9acb-4784-a22e-c4877b6f565e@github.com>

On Fri, 11 Mar 2022 18:25:02 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> It's a bit hard to talk about 'fallback' fonts here without confusion, as this word might mean at least two things - we have Korean fallback fonts, in a sense that `sequence.fallback` contains `korean` entry, so all logical fonts are supposed to support Korean. And we also want e.g. Batang font to 'fallback' to Malgun Gothic, if Batang font is not installed.

It seems then if we have
`allfonts.korean-fallback=Malgun Gothic`
and add this `korean-fallback` to `sequence.fallback` instead of `korean` then I guess we can have fix for both.
Will this be accepted change?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From smandalika at openjdk.java.net  Mon Mar 14 06:19:27 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Mon, 14 Mar 2022 06:19:27 GMT
Subject: RFR: JDK-8282933: Create a test for JDK-4529616 [v2]
In-Reply-To: <3d_szd4R6oyDqof-g7sLsV_wkAzuEuma-aXiiUZ03Zw=.6579f560-f11e-4bea-a292-dfcee111a246@github.com>
References: <3d_szd4R6oyDqof-g7sLsV_wkAzuEuma-aXiiUZ03Zw=.6579f560-f11e-4bea-a292-dfcee111a246@github.com>
Message-ID: <YZwQi9VVBAtOghkT1CK7SVgEfynhucTe_BI3srKY8Ec=.9f2504e3-14bd-4846-b914-2da6e0a80034@github.com>

> JDK-8282933: Create a test for JDK-4529616 
> AccessibleJTableCell.isShowing() returns false when the cell is actually on
> the screen.
> The test validates the fix for the above issue by verifying that the isShowing call returns true when invoked via the  accessiblity context.
> This review is for migrating tests from a closed test suite to open.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  frame dispose call on EDT

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7783/files
  - new: https://git.openjdk.java.net/jdk/pull/7783/files/c1ba7b68..787ad251

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7783&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7783&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7783.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7783/head:pull/7783

PR: https://git.openjdk.java.net/jdk/pull/7783


From smandalika at openjdk.java.net  Mon Mar 14 06:29:30 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Mon, 14 Mar 2022 06:29:30 GMT
Subject: RFR: JDK-8283015: Create a test for JDK-4715496 [v2]
In-Reply-To: <FZTHpImv7BXOuuYK-42rwC55GssXPQH2S8hwVIvAsfw=.1ba518e0-5c7f-4ed6-a9ce-667a859142c1@github.com>
References: <FZTHpImv7BXOuuYK-42rwC55GssXPQH2S8hwVIvAsfw=.1ba518e0-5c7f-4ed6-a9ce-667a859142c1@github.com>
Message-ID: <MH7nOHyv83GCYpLD9yKdQZkvoEFr8Cx1hO-aPZYhUoA=.9b5c843c-f02d-471f-84bb-168e0cce3b8a@github.com>

> Create a test for JDK-4715496
> 
> Issue observed in the above bug is that the JTable.AccessibleJTableCell.getAccessible name returns the cell instance string instead of the cell text.
> The test is being added to verify the same.
> This review is for migrating tests from a closed test suite to open.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  frame dispose call on EDT

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7787/files
  - new: https://git.openjdk.java.net/jdk/pull/7787/files/ff26d6cb..2a91f085

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7787&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7787&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7787.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7787/head:pull/7787

PR: https://git.openjdk.java.net/jdk/pull/7787


From smandalika at openjdk.java.net  Mon Mar 14 09:36:18 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Mon, 14 Mar 2022 09:36:18 GMT
Subject: RFR: JDK-8283087: Create a test or JDK-4715503
Message-ID: <EKaHEfjou-QbJWzk5d74cD23a62vFExxy0w7BPkxWho=.a3fad8f0-dfb2-46d1-939b-61bf89d03f24@github.com>

Create a test or [JDK-4715503](https://bugs.openjdk.java.net/browse/JDK-4715503)

The getAccessibleContext method for JTable column header cells returns an
 AccessibleContext which cannot get the Bounding Rectangle for table header cells. The Bug causes problems with screen reader review mode.

The test added verifies that the are not exceptions and Bounding rectangles are returned for the Accessible Table Header Cells.

This review is for migrating tests from a closed test suite to open.

-------------

Commit messages:
 - 8283087: Create a test or JDK-4715503

Changes: https://git.openjdk.java.net/jdk/pull/7807/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7807&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283087
  Stats: 83 lines in 1 file changed: 83 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7807.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7807/head:pull/7807

PR: https://git.openjdk.java.net/jdk/pull/7807


From duke at openjdk.java.net  Mon Mar 14 12:06:46 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Mon, 14 Mar 2022 12:06:46 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage
In-Reply-To: <12bhwN6rQ-1c7HJtuPK7hrR0zsOeTbv0yYC2_f57v2g=.7f32d881-58e5-4d40-857c-553a855f2d7d@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <x2z-m3Sq-k2cUBobgCe9KwHBgQFY3fvHa4ZpHld9GHA=.39ce100a-a89a-4247-a265-bf79508b7e1e@github.com>
 <2s6htwoTFM0N9DBj0Ub2zK2TepiNjRuLVJsij4mnXcM=.ba4724c1-aee4-4683-acac-cb6912dc7016@github.com>
 <_Eb1usYXvARXBUeKntPJnjhdArtK4D5MycXBiTcqtTA=.ba1f35c0-aede-4348-b2f6-3370fcaf1d96@github.com>
 <2vwMFlely_NGI2XBJ_R58vD6lAqElz39ZWB7U9gavTk=.05c9e4a2-58e6-48d9-9612-2340258ee93c@github.com>
 <ff1wAeY7Sxa0YIlM3ZDDI4TJEyd0ci02_mLC_0EUhPQ=.69d61074-8e2e-4dbf-b8b1-ccb1d5b6b7ca@github.com>
 <12bhwN6rQ-1c7HJtuPK7hrR0zsOeTbv0yYC2_f57v2g=.7f32d881-58e5-4d40-857c-553a855f2d7d@github.com>
Message-ID: <FE0bLrx9TZCYWJCSyMBYQxLJG4krm39Q18V9iK5KECI=.1a29e466-647e-4297-a167-59375a631bb4@github.com>

On Fri, 11 Mar 2022 21:46:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> We shouldn't be setting any MediaTracker status here - this is the caller ! It would be absolutely wrong. And it seems likely to me that this println was put there by the developer of this code who was him/herself not sure if this would occur and what to do about it so wanted to have a message if it ever occurred so they could figure out how to handle it.
>> It seems to me that if the thread were interrupted there'd only be a very narrow window in which it likely that the image were complete and that if interrupted then I agree with what I think Alexey is saying which is that the MediaTracker may not have had a chance to even update status since it was interrupted .. depends how sophisticated the implementation is.
>> Since ImageIcon.getLoadStatus() specifies only 3 possible return values then yes, we should ensure it is one of those . So if it is LOADING then set it to ABORTED .. However a possible wrinkle is that this call being interrupted may not actually prevent the separate threads the MediaTracker kicks off from continuing .. so it may actually be still loading. And it is just that the waiting was interrupted.
>> Someone would need to dig into MediaTracker to check.
>> But since the code removes the image from the tracker .. maybe we don't care ?
>
> Since the image is removed from MediaTracker, its status can't change after that. Therefore `LOADING` status should be changed to `ABORTED`.
> [JDK-6421373](https://bugs.openjdk.java.net/browse/JDK-6421373) has a test case which can be modified to load an image and check `loadStatus` of the image.

Ok, will modify the code and check the status.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From psadhukhan at openjdk.java.net  Mon Mar 14 13:18:54 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 14 Mar 2022 13:18:54 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v3]
In-Reply-To: <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>
Message-ID: <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>

On Thu, 10 Mar 2022 22:22:29 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> Previously while tabbing through the JTable cell, the cell highlighter/focus ring was not visible against the selection background. 
>> 
>> Changes are made to Aqua LAF to derive a brighter focus ring color by changing hue, saturation and brightness of selection background color so that it is visible while tabbing through `JTable` cells. A new method is added for this purpose which takes in `selectionBackground` color, does the hue, saturation and brightness manipulation and returns a new focus ring color. There are edge cases where the HSB transformation does not yield the right focus ring color, for these cases a default color is returned that is different and can be seen against the `selectionBackground`.
>> 
>> **Edge Cases**
>> **Selection Background**     -----       **Returned Focus Ring Color**
>> - White/ Black                        ----->          Gray
>> 
>> - Shade of Gray 
>> towards white (r=g=b >= 128)  ----->      Black
>> 
>> - Shade of Gray 
>> towards Black (r=g=b < 128)    ------>     White
>> 
>> A test case is added to compare the RGB difference between the original focus ring color & selection background and the brighter focus ring color & selection background.
>> 
>> PS: The native L&F (Mac OS) and Swing L&F for JTable cell tabbing differs (on native tables the cell background turns white on focus with a cell focus ring). Since the background for Swing tables can be set by users and also overridden by subclassing `DefaultTableCellRenderer`, and to adhere to current implementation of Swing, the cell background changes are not incorporated. Only the Focus Ring/ Cell Highlighter is made more prominent against the selection background.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   formatting changes to test case

src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java line 892:

> 890:             "Table.focusCellBackground", textHighlightText,
> 891:             "Table.focusCellForeground", textHighlight,
> 892:             "Table.focusCellHighlightBorder", new BorderUIResource.LineBorderUIResource(deriveContrastFocusRing(selectionBackground), 2),

You have used border thickness as 2 without relying on scale factor. Did you check if it looks same in retina as well as non-retina display?

src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java line 1192:

> 1190: 
> 1191:         //create and return Color corresponding to new hsbValues
> 1192:         return Color.getHSBColor(hsbValues[0], hsbValues[1], hsbValues[2]);

It seems you are only manipulating hue and saturation, not the brightness which is set to 1.0f throughout..need to change the javadoc comment

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From psadhukhan at openjdk.java.net  Mon Mar 14 13:18:55 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 14 Mar 2022 13:18:55 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v3]
In-Reply-To: <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>
 <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>
Message-ID: <oAZ5tpWpksvN6sfEYoblyucXf_EqcxKAIiVvkvIugjU=.a10e37ec-b8e8-4ac3-9faf-f2a8d85189af@github.com>

On Mon, 14 Mar 2022 12:39:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   formatting changes to test case
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java line 892:
> 
>> 890:             "Table.focusCellBackground", textHighlightText,
>> 891:             "Table.focusCellForeground", textHighlight,
>> 892:             "Table.focusCellHighlightBorder", new BorderUIResource.LineBorderUIResource(deriveContrastFocusRing(selectionBackground), 2),
> 
> You have used border thickness as 2 without relying on scale factor. Did you check if it looks same in retina as well as non-retina display?

Do we also need to do the same for List.focusCellHighlightBorder?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From achung at openjdk.java.net  Mon Mar 14 16:15:47 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 14 Mar 2022 16:15:47 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v3]
In-Reply-To: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
Message-ID: <HYjNkqqcwMFOo-6mM2Q_4-1B5ePKD3-DRICoaF_1-bA=.53f59ac5-02f8-4c57-924c-40d22a760db1@github.com>

> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  added functions for drawing border, fixed translate

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7449/files
  - new: https://git.openjdk.java.net/jdk/pull/7449/files/6056faf8..7b7732f8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=01-02

  Stats: 35 lines in 1 file changed: 16 ins; 14 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7449.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7449/head:pull/7449

PR: https://git.openjdk.java.net/jdk/pull/7449


From achung at openjdk.java.net  Mon Mar 14 16:15:48 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 14 Mar 2022 16:15:48 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v2]
In-Reply-To: <FekRgDLssGtJkXCN1Z-po6L4liDWivTfMM0SE2IOdSY=.6c5792c4-3d8f-49f4-a32f-99466c97ae6c@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <FekRgDLssGtJkXCN1Z-po6L4liDWivTfMM0SE2IOdSY=.6c5792c4-3d8f-49f4-a32f-99466c97ae6c@github.com>
Message-ID: <-_9bt07nsB3J9avR9Z5uHHML1ExIyYpQaxFvWX-OFRQ=.67fe0299-5ad0-4b2a-991c-f720f0d43c30@github.com>

On Fri, 4 Mar 2022 00:49:39 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - adjusted pixels to check for border
>  - typo
>  - reverted old change, swapped order of painting to prevent overdrawing

I just added the functions Phil suggested, @azuev-java could you also review?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From achung at openjdk.java.net  Mon Mar 14 16:41:48 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 14 Mar 2022 16:41:48 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2]
In-Reply-To: <8cpPZ7PatfiigWBze5jL-LUXa6urMiCgdhpm1otQHhA=.1862cf26-296b-438e-acfe-2a83b64dc539@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
 <8cpPZ7PatfiigWBze5jL-LUXa6urMiCgdhpm1otQHhA=.1862cf26-296b-438e-acfe-2a83b64dc539@github.com>
Message-ID: <aFQYlAxHrt1xgVqg6IzAILy_arxPtISUJjV4XTInMIc=.98676675-43ef-44ef-bc29-935fb586e100@github.com>

On Thu, 10 Mar 2022 18:56:41 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   moved CurrencyNames changes to jdk.localedata
>
> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java line 305:
> 
>> 303:         {"Thread not suspended", "\u30B9\u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u3066\u3044\u307E\u305B\u3093"},
>> 304:         {"thread group number description name", "{0,number,integer}. {1} {2}"},
>> 305:         {"Threadgroup name not specified.", "\u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u540D\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u307E\u305B\u3093\u3002"},
> 
> I'm not sure what happened here. This resource was just removed yesterday as part of #7687. It had been around for a long time before that (probably from the beginning of this file), so I'm not sure what triggered getting it re-added.

The translation was started before the updates to this file. This update can be done in the next msg drop.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7765


From cushon at openjdk.java.net  Mon Mar 14 16:57:45 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Mon, 14 Mar 2022 16:57:45 GMT
Subject: RFR: 8280054: BadSerializationTest and
 DragGestureEvent/DragGestureRecognizer constructors
In-Reply-To: <hYkHCEJK_Hi2MR2trNzd0ZWWHk51VzvTvddIB9COzPs=.74cc983b-d21b-4370-af18-32dd61f8efb7@github.com>
References: <hYkHCEJK_Hi2MR2trNzd0ZWWHk51VzvTvddIB9COzPs=.74cc983b-d21b-4370-af18-32dd61f8efb7@github.com>
Message-ID: <DwUVciWF3C-eLKtRUOY5za-93gsPCWTqFRqQcx1Fr7Q=.70a6b839-8a43-4259-a653-e2b7de1bb189@github.com>

On Sat, 15 Jan 2022 23:20:56 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Please consider this enhancement to `test/jdk/java/awt/dnd/BadSerializationTest/BadSerializationTest.java`, which simplifies the process of manually generating serialized test data by using reflection to generate invalid instances of `DragGestureEvent` and `DragGestureRecognizer`, instead of relying on patching the constructors of those classes to disable validation checks.
> 
> This cleanup was proposed in the review for a possible fix for [JDK-8277817](https://bugs.openjdk.java.net/browse/JDK-8277817): https://git.openjdk.java.net/jdk/pull/6603#issuecomment-997054470

Closing due to lack of interest

-------------

PR: https://git.openjdk.java.net/jdk/pull/7099


From cushon at openjdk.java.net  Mon Mar 14 16:57:45 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Mon, 14 Mar 2022 16:57:45 GMT
Subject: Withdrawn: 8280054: BadSerializationTest and
 DragGestureEvent/DragGestureRecognizer constructors
In-Reply-To: <hYkHCEJK_Hi2MR2trNzd0ZWWHk51VzvTvddIB9COzPs=.74cc983b-d21b-4370-af18-32dd61f8efb7@github.com>
References: <hYkHCEJK_Hi2MR2trNzd0ZWWHk51VzvTvddIB9COzPs=.74cc983b-d21b-4370-af18-32dd61f8efb7@github.com>
Message-ID: <RCFafb3xC3Mnw_REzUTsE68RC178nLbziB6yCAseI5E=.e53dbb86-c232-45c4-8bf5-ab5305aea1aa@github.com>

On Sat, 15 Jan 2022 23:20:56 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Please consider this enhancement to `test/jdk/java/awt/dnd/BadSerializationTest/BadSerializationTest.java`, which simplifies the process of manually generating serialized test data by using reflection to generate invalid instances of `DragGestureEvent` and `DragGestureRecognizer`, instead of relying on patching the constructors of those classes to disable validation checks.
> 
> This cleanup was proposed in the review for a possible fix for [JDK-8277817](https://bugs.openjdk.java.net/browse/JDK-8277817): https://git.openjdk.java.net/jdk/pull/6603#issuecomment-997054470

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7099


From cushon at openjdk.java.net  Mon Mar 14 17:01:53 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Mon, 14 Mar 2022 17:01:53 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v10]
In-Reply-To: <W2s9WCAQ0PrTJ6_74UYEZKrNcArdyqeqFjPDL60ugsU=.ddb42dc6-f07c-48cb-bf69-0625ac3e5ea4@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <W2s9WCAQ0PrTJ6_74UYEZKrNcArdyqeqFjPDL60ugsU=.ddb42dc6-f07c-48cb-bf69-0625ac3e5ea4@github.com>
Message-ID: <-D2vTGfZGTesIygswPIh5fRbxwjXdc664k8QQcHGTtI=.d31809e2-c473-44fd-8adb-ec526babb9b5@github.com>

On Wed, 12 Jan 2022 18:14:45 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge master
>  - Write serialized objects at test-time in BadSerializationTest
>  - Merge branch 'master' into JDK-8277817
>  - Revert WIP
>  - Add a few more missing calls to LookAndFeel.uninstallColors
>  - Use LookAndFeel.uninstallColorsAndFont in BasicListUI
>  - Add @since 19 to new methods
>  - Add uninstallColorsAndFont
>  - 8277817: java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed: ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy

I'm going to close this PR, since there doesn't seem to be a path forward here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6603


From cushon at openjdk.java.net  Mon Mar 14 17:01:54 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Mon, 14 Mar 2022 17:01:54 GMT
Subject: Withdrawn: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy
In-Reply-To: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
Message-ID: <kJd8h7IklVFxgeqKES0_1pgZNkX13ksQ6HcwoqM8dZE=.e6a78268-4c42-4422-9c79-c18164ef3259@github.com>

On Tue, 30 Nov 2021 01:31:24 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6603


From kizune at openjdk.java.net  Mon Mar 14 17:39:48 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 14 Mar 2022 17:39:48 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v3]
In-Reply-To: <HYjNkqqcwMFOo-6mM2Q_4-1B5ePKD3-DRICoaF_1-bA=.53f59ac5-02f8-4c57-924c-40d22a760db1@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <HYjNkqqcwMFOo-6mM2Q_4-1B5ePKD3-DRICoaF_1-bA=.53f59ac5-02f8-4c57-924c-40d22a760db1@github.com>
Message-ID: <B7n2Xnle9h4yGeElKvv0Bp1FIT4z8WetQ2oGJUrGX5A=.e115c9c7-d0ba-443f-8a43-aa4046fb6156@github.com>

On Mon, 14 Mar 2022 16:15:47 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added functions for drawing border, fixed translate

Latest version looks Ok to me.

-------------

Marked as reviewed by kizune (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7449


From kizune at openjdk.java.net  Mon Mar 14 17:41:55 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 14 Mar 2022 17:41:55 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2]
In-Reply-To: <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
Message-ID: <czftHGbEDrHytjmuT25dBWmgpN3gaiEPLmzDFtod0pA=.0c2274f6-25af-43fa-817f-0e41ede1c530@github.com>

On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved CurrencyNames changes to jdk.localedata

Marked as reviewed by kizune (Reviewer).

Clientlibs related stuff looks correct.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7765


From prr at openjdk.java.net  Mon Mar 14 18:09:53 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 14 Mar 2022 18:09:53 GMT
Subject: Integrated: 8282577: ICC_Profile.setData(int,
 byte[]) invalidates the profile
In-Reply-To: <ecPAoejPCnfczdYoQmH89792PmRZxg4Rc5LaEHlsnXo=.3ad1b170-e862-4322-9164-df0501b298a0@github.com>
References: <ecPAoejPCnfczdYoQmH89792PmRZxg4Rc5LaEHlsnXo=.3ad1b170-e862-4322-9164-df0501b298a0@github.com>
Message-ID: <F7zlXSZBPP9jKA9At346xhqd-mH8NmnJ90VkD-p8SsU=.33804073-d51c-4ad1-a9d4-9a69138a07f7@github.com>

On Wed, 2 Mar 2022 20:53:03 GMT, Phil Race <prr at openjdk.org> wrote:

> As per the bug eval, we are returning a pointer to a native raw LittleCMS profile and it should be a cooked one.
> The simple test fails before the fix with
> ~/jdk17/Contents/Home/bin/java SetTagDataValidation                               
> Exception in thread "main" java.awt.color.CMMException: LCMS error 13: Couldn't link the profiles
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createNativeTransform(Native Method)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createTransform(LCMS.java:104)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.doTransform(LCMSTransform.java:143)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.colorConvert(LCMSTransform.java:633)
> 	at java.desktop/java.awt.color.ICC_ColorSpace.toRGB(ICC_ColorSpace.java:224)
> 	at SetTagDataValidation.main(SetTagDataValidation.java:61)
> 
> and with the fix  just prints 
> java SetTagDataValidation
> 0.4
> 0.5000076
> 0.6

This pull request has now been integrated.

Changeset: f66070b0
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f66070b00d4311c6e3a6fbf38956fa2d5da5fada
Stats:     98 lines in 3 files changed: 89 ins; 3 del; 6 mod

8282577: ICC_Profile.setData(int, byte[]) invalidates the profile

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/7668


From prr at openjdk.java.net  Mon Mar 14 18:22:47 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 14 Mar 2022 18:22:47 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v3]
In-Reply-To: <6xs4-PbuPxBkxDverzrbM1V63pQpwxUebjo5JpQqcGg=.b7042da0-9acb-4784-a22e-c4877b6f565e@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
 <Yu60xcJmK2GCi1XFs_qN2UnxccOx3GkW2JVt3RE2DZc=.3687c143-14e5-47ed-a1c1-0f9310c5aae7@github.com>
 <6xs4-PbuPxBkxDverzrbM1V63pQpwxUebjo5JpQqcGg=.b7042da0-9acb-4784-a22e-c4877b6f565e@github.com>
Message-ID: <B7EdIDIhmBuVOTHOth_aWOk_byPfoC5JUJQJ9NXPEtw=.1860e678-8538-4604-9d75-452bba56b9e6@github.com>

On Mon, 14 Mar 2022 04:22:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It's a bit hard to talk about 'fallback' fonts here without confusion, as this word might mean at least two things - we have Korean fallback fonts, in a sense that `sequence.fallback` contains `korean` entry, so all logical fonts are supposed to support Korean. And we also want e.g. Batang font to 'fallback' to Malgun Gothic, if Batang font is not installed.

I don't see why it is hard. In fact there's actually only one thing.
The fallback sequence is appended to all logical fonts of all styles.
It means that if a font that is specified in a particular logical font isn't present, something from this sequence will provide the fallback.
There's no font or script specific fallback logic along the lines of if (!batang) then insert malgun in its same place.
It is really code point fallback : if asked for codepoint \u1101, then search the component fonts in order until you find it or run out of fonts. 

There's some unintended behaviour (bug) that "foo" in the logical fonts is hiding "foo" in the fallback sequence but that doesn't change the above logic.

> It seems then if we have
allfonts.korean-fallback=Malgun Gothic
and add this korean-fallback to sequence.fallback instead of korean then I guess we can have fix for both.
Will this be accepted change?

It is fine by me. I just want to be hear that you have tested all the scenarios and it works as we want it to.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From achung at openjdk.java.net  Mon Mar 14 20:39:46 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 14 Mar 2022 20:39:46 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v3]
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <EX20WV-YgdYDcf8bAQVowI8_bLWbhpIVbE6VcPJuoAQ=.1bb0d805-0b7c-4e02-8a95-5c7d86b31c70@github.com>

> msg drop for jdk19, Mar 9, 2022

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  removed repeated lines from ROOT bundle in CurrencyNames

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7765/files
  - new: https://git.openjdk.java.net/jdk/pull/7765/files/4735722d..d5c9b884

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=01-02

  Stats: 675 lines in 3 files changed: 0 ins; 675 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7765.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765

PR: https://git.openjdk.java.net/jdk/pull/7765


From aivanov at openjdk.java.net  Mon Mar 14 21:04:43 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 14 Mar 2022 21:04:43 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v3]
In-Reply-To: <HYjNkqqcwMFOo-6mM2Q_4-1B5ePKD3-DRICoaF_1-bA=.53f59ac5-02f8-4c57-924c-40d22a760db1@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <HYjNkqqcwMFOo-6mM2Q_4-1B5ePKD3-DRICoaF_1-bA=.53f59ac5-02f8-4c57-924c-40d22a760db1@github.com>
Message-ID: <IzxCtzPKGyFGR-8VFzfo-BK7b9erJFjghrHFEybbyLA=.5e3f5268-2c45-4e37-8316-131666732c84@github.com>

On Mon, 14 Mar 2022 16:15:47 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added functions for drawing border, fixed translate

The test uses 2 spaces for indentation. It should use 4 spaces for each level of indentation.

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 154:

> 152: 
> 153:         // 8279614: The dark line was being overdrawn by the light line. The fix was to
> 154:         // make sure that the dark line is always drawn second.

Suggestion:

        // 8279614: The dark line was overdrawn by the light line.
        // The fix makes sure that the dark line is always drawn second.


Does the opposite never happen? That the shadow overdraws the highlight.

src/java.desktop/share/classes/javax/swing/border/TitledBorder.java line 36:

> 34: import java.awt.Rectangle;
> 35: import java.awt.geom.Path2D;
> 36: import java.awt.geom.Rectangle2D;

This import isn't used. There are no other changes to this file but this added import.

In addition to it, you can also remove java.beans.PropertyChangeEvent from imports which is unused as well.

test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 56:

> 54: 
> 55:   public static void main(String[] args) throws Exception {
> 56:     LookAndFeelInfo laf = UIManager.getInstalledLookAndFeels()[3];

Is the test needs to be run in a specific LookAndFeel? If so, you have to set explicitly rather than rely on the order of LAFs.

test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 68:

> 66:     graph.scale(1.5, 1.5);
> 67:     frame.paint(graph);
> 68:     graph.dispose();

If we paint to `BufferedImage`, it makes sense to bypass creating and showing the frame, a panel with `TitledBorder` will be enough. In this case, the test can be headless.

Shall we run the test with a set of scales: 1.00, 1.25, 1.50, 1.75, 2.00?

Without the fix, the left line looks clipped at 2.0 scale too: the shadow is 1-pixel wide on the left whereas the highlight is 2-pixel wide on the four edges.

test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 74:

> 72:     for (int i = 15; i < 25 && testFail == true; i++) {
> 73:       for (int j = 80; j < 100; j++) {
> 74:         if (buff.getRGB(i, j) == -6250336) {

Using hex for colors is better.

Getting the highlight or shadow color from the border would make the test more generic. If the color used by border changes, the test will fail but it shouldn't.

test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 115:

> 113:       ImageIO.write(image, "png", new File(filename));
> 114:     } catch (IOException e) {
> 115:       // Don?t propagate the exception

I recommend using a regular apostrophe (') instead of typographic one (?). It should cause issues with compiling because it's in the comment, yet the character may be displayed incorrectly if the default system encoding doesn't match the encoding of the file.

-------------

Changes requested by aivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7449


From naoto at openjdk.java.net  Mon Mar 14 21:58:45 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 14 Mar 2022 21:58:45 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v3]
In-Reply-To: <EX20WV-YgdYDcf8bAQVowI8_bLWbhpIVbE6VcPJuoAQ=.1bb0d805-0b7c-4e02-8a95-5c7d86b31c70@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <EX20WV-YgdYDcf8bAQVowI8_bLWbhpIVbE6VcPJuoAQ=.1bb0d805-0b7c-4e02-8a95-5c7d86b31c70@github.com>
Message-ID: <AePZQwkLsjSCRROANYizCTzIfiMBaWBOgZaVcnJtm5k=.132459fa-34c1-487f-b2c0-ce1d9e9e5f60@github.com>

On Mon, 14 Mar 2022 20:39:46 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed repeated lines from ROOT bundle in CurrencyNames

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/ct_ja.properties line 1:

> 1: #

The change to this file (moving ct.properties to ct_ja.properties) does look suspicious. Looks like this is not a translation file, but some kind of a configuration for `javac`. If so, it should not be translated (and translation configuration in the closed repository should exclude this file)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7765


From duke at openjdk.java.net  Mon Mar 14 22:25:47 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Mon, 14 Mar 2022 22:25:47 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v3]
In-Reply-To: <oAZ5tpWpksvN6sfEYoblyucXf_EqcxKAIiVvkvIugjU=.a10e37ec-b8e8-4ac3-9faf-f2a8d85189af@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>
 <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>
 <oAZ5tpWpksvN6sfEYoblyucXf_EqcxKAIiVvkvIugjU=.a10e37ec-b8e8-4ac3-9faf-f2a8d85189af@github.com>
Message-ID: <r9ujiKOC7dRsKCLNjUEt-V8mCstzXKJLFPRQ1O6kqKs=.2b96988b-85c6-45d5-9d95-2e0112b458fb@github.com>

On Mon, 14 Mar 2022 13:14:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java line 892:
>> 
>>> 890:             "Table.focusCellBackground", textHighlightText,
>>> 891:             "Table.focusCellForeground", textHighlight,
>>> 892:             "Table.focusCellHighlightBorder", new BorderUIResource.LineBorderUIResource(deriveContrastFocusRing(selectionBackground), 2),
>> 
>> You have used border thickness as 2 without relying on scale factor. Did you check if it looks same in retina as well as non-retina display?
>
> Do we also need to do the same for List.focusCellHighlightBorder?

@prsadhuk Thank you for reviewing. 

Earlier when I used the default thickness (thickness=1) the cell focus ring was visible but not prominent as shown in the following screenshot. Please let me know if I need to change thickness to 1 or keep it the same?

**Thickness=1**

![image](https://user-images.githubusercontent.com/95945681/158270171-8260c71f-511f-481e-b88e-f226818a8219.png)

The thickness looks the same on retina as well as non-retina display. I have included the screenshots for comparison-

![image](https://user-images.githubusercontent.com/95945681/158270568-b3018b09-8227-4bf0-9751-80d30df4e411.png)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From duke at openjdk.java.net  Mon Mar 14 22:30:41 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Mon, 14 Mar 2022 22:30:41 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v3]
In-Reply-To: <r9ujiKOC7dRsKCLNjUEt-V8mCstzXKJLFPRQ1O6kqKs=.2b96988b-85c6-45d5-9d95-2e0112b458fb@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>
 <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>
 <oAZ5tpWpksvN6sfEYoblyucXf_EqcxKAIiVvkvIugjU=.a10e37ec-b8e8-4ac3-9faf-f2a8d85189af@github.com>
 <r9ujiKOC7dRsKCLNjUEt-V8mCstzXKJLFPRQ1O6kqKs=.2b96988b-85c6-45d5-9d95-2e0112b458fb@github.com>
Message-ID: <AUeNFfcZNdDhRKJExOY7lT7_eG07ZQ_E124iHS_oiVI=.af2824b3-dc46-4318-92c3-27a861269339@github.com>

On Mon, 14 Mar 2022 22:22:23 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> Do we also need to do the same for List.focusCellHighlightBorder?
>
> @prsadhuk Thank you for reviewing. 
> 
> Earlier when I used the default thickness (thickness=1) the cell focus ring was visible but not prominent as shown in the following screenshot. Please let me know if I need to change thickness to 1 or keep it the same?
> 
> **Thickness=1**
> 
> ![image](https://user-images.githubusercontent.com/95945681/158270171-8260c71f-511f-481e-b88e-f226818a8219.png)
> 
> The thickness looks the same on retina as well as non-retina display. I have included the screenshots for comparison-
> 
> ![image](https://user-images.githubusercontent.com/95945681/158270568-b3018b09-8227-4bf0-9751-80d30df4e411.png)

Since List.focusCellHighlightBorder uses the same focusRingColor as used by Table we can change it for List as well. Can I make changes to List using this issue and PR or should I track it by adding a new JBS bug/PR ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From prr at openjdk.java.net  Mon Mar 14 22:40:45 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 14 Mar 2022 22:40:45 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v3]
In-Reply-To: <IzxCtzPKGyFGR-8VFzfo-BK7b9erJFjghrHFEybbyLA=.5e3f5268-2c45-4e37-8316-131666732c84@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <HYjNkqqcwMFOo-6mM2Q_4-1B5ePKD3-DRICoaF_1-bA=.53f59ac5-02f8-4c57-924c-40d22a760db1@github.com>
 <IzxCtzPKGyFGR-8VFzfo-BK7b9erJFjghrHFEybbyLA=.5e3f5268-2c45-4e37-8316-131666732c84@github.com>
Message-ID: <6vDLClAWm0uTKgb8a7aZqB7r_kniBC9c91SkLkIwGqs=.dad03632-7e9e-4414-843d-f66cd4d4097a@github.com>

On Mon, 14 Mar 2022 20:57:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added functions for drawing border, fixed translate
>
> src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 154:
> 
>> 152: 
>> 153:         // 8279614: The dark line was being overdrawn by the light line. The fix was to
>> 154:         // make sure that the dark line is always drawn second.
> 
> Suggestion:
> 
>         // 8279614: The dark line was overdrawn by the light line.
>         // The fix makes sure that the dark line is always drawn second.
> 
> 
> Does the opposite never happen? That the shadow overdraws the highlight.

This is a comment on the actual comment rather than whether the intent is correct.
I'm not in favour of putting bug ids into the comments. Our code will end up utterly cluttered with them
Also it is phrased to describe a fix.
So IF it were to stand as is, I would have phrased it as "what we are doing now and why", ie
// Make sure the shadow line always is drawn second because it needs to over draw the border.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From duke at openjdk.java.net  Mon Mar 14 22:41:39 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Mon, 14 Mar 2022 22:41:39 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v3]
In-Reply-To: <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>
 <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>
Message-ID: <Q1G2VjJWeUqZtNByY1lCvq7CDa7pPfk9MzeOZJ2mXeg=.704e32d0-8812-4fb5-8175-6a45ae033f32@github.com>

On Mon, 14 Mar 2022 12:54:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   formatting changes to test case
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java line 1192:
> 
>> 1190: 
>> 1191:         //create and return Color corresponding to new hsbValues
>> 1192:         return Color.getHSBColor(hsbValues[0], hsbValues[1], hsbValues[2]);
> 
> It seems you are only manipulating hue and saturation, not the brightness which is set to 1.0f throughout..need to change the javadoc comment

Sure. I will change the Javadocs comments as suggested.
The reason for setting brightness to max value is that for any color returned by hue and saturation offset, setting brightness=1 gives the brightest color for the new color used for cell highlighting purpose.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From aivanov at openjdk.java.net  Mon Mar 14 23:07:45 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 14 Mar 2022 23:07:45 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v2]
In-Reply-To: <X20yOeSYQ3aDABuDUvVWyy7sjXKFbphtUpA7V1vfwrI=.1f366364-dc10-4110-a719-f6f7f40a7722@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <FekRgDLssGtJkXCN1Z-po6L4liDWivTfMM0SE2IOdSY=.6c5792c4-3d8f-49f4-a32f-99466c97ae6c@github.com>
 <dAi-3yVWhSzLp-xxgY_4kJcgR-sjI0Gawzs_Oy5R3pQ=.bb14e735-3133-4581-9741-8ea5c2b0aca8@github.com>
 <X20yOeSYQ3aDABuDUvVWyy7sjXKFbphtUpA7V1vfwrI=.1f366364-dc10-4110-a719-f6f7f40a7722@github.com>
Message-ID: <Jn62qsxYtCAOS0eqdud3EBMgpAfedDbHMXy7rHBjpuo=.db09ff14-1977-4d80-b5d6-ad2ab76aace3@github.com>

On Sat, 5 Mar 2022 01:56:04 GMT, Alisen Chung <achung at openjdk.org> wrote:

> > Can you explain (walk through) why the old code was wrong and the new code is correct ? There's a lot of things that aren't obvious to me. The old code would use the same coords and just toggle which parts were in highlight/shadow Now you've spilit is so that lowered does things in a different order and so forth and I find it impossible without an explanation of your reasoning to say if that reasoning is correct ...
> > Also the bug report deserves an evaluation.
> 
> I think currently the problem is the lighter color is overdrawing the darker color, so I swapped the drawing order so that the darker color is always drawn second. I think the reason the rect and lines are drawn at the same x value probably has to do with the affine transform in the graphics object, but I'm not sure why it happens.

Is it possible that in the new order the darker colour is drawn over the lighter one?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From achung at openjdk.java.net  Mon Mar 14 23:07:45 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 14 Mar 2022 23:07:45 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v3]
In-Reply-To: <HYjNkqqcwMFOo-6mM2Q_4-1B5ePKD3-DRICoaF_1-bA=.53f59ac5-02f8-4c57-924c-40d22a760db1@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <HYjNkqqcwMFOo-6mM2Q_4-1B5ePKD3-DRICoaF_1-bA=.53f59ac5-02f8-4c57-924c-40d22a760db1@github.com>
Message-ID: <9H0wQMoUjvCun9VKm7hnVGRe4nxkCoCUaWFulzzJbAg=.1d247d37-c92f-4c56-997f-a44c308e4c31@github.com>

On Mon, 14 Mar 2022 16:15:47 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added functions for drawing border, fixed translate

I think you're right that now the darker colour is drawing over the lighter one. I'm currently changing the drawing of the border to take into account the scaling to prevent either color from overdrawing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From aivanov at openjdk.java.net  Mon Mar 14 23:07:47 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 14 Mar 2022 23:07:47 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v3]
In-Reply-To: <6vDLClAWm0uTKgb8a7aZqB7r_kniBC9c91SkLkIwGqs=.dad03632-7e9e-4414-843d-f66cd4d4097a@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <HYjNkqqcwMFOo-6mM2Q_4-1B5ePKD3-DRICoaF_1-bA=.53f59ac5-02f8-4c57-924c-40d22a760db1@github.com>
 <IzxCtzPKGyFGR-8VFzfo-BK7b9erJFjghrHFEybbyLA=.5e3f5268-2c45-4e37-8316-131666732c84@github.com>
 <6vDLClAWm0uTKgb8a7aZqB7r_kniBC9c91SkLkIwGqs=.dad03632-7e9e-4414-843d-f66cd4d4097a@github.com>
Message-ID: <kXwzfKAffHp93WpuLqjttMTTxJ_yqj1SLnZ32uZh4jw=.28e334fc-0178-4cef-92b8-d59ffd5d8aa5@github.com>

On Mon, 14 Mar 2022 22:37:35 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 154:
>> 
>>> 152: 
>>> 153:         // 8279614: The dark line was being overdrawn by the light line. The fix was to
>>> 154:         // make sure that the dark line is always drawn second.
>> 
>> Suggestion:
>> 
>>         // 8279614: The dark line was overdrawn by the light line.
>>         // The fix makes sure that the dark line is always drawn second.
>> 
>> 
>> Does the opposite never happen? That the shadow overdraws the highlight.
>
> This is a comment on the actual comment rather than whether the intent is correct.
> I'm not in favour of putting bug ids into the comments. Our code will end up utterly cluttered with them
> Also it is phrased to describe a fix.
> So IF it were to stand as is, I would have phrased it as "what we are doing now and why", ie
> // Make sure the shadow line always is drawn second because it needs to over draw the border.

I should've posted my question separately rather than as a comment to the comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From duke at openjdk.java.net  Mon Mar 14 23:19:27 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Mon, 14 Mar 2022 23:19:27 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v4]
In-Reply-To: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
Message-ID: <aLI_dMXtYbaG3lIJVkvPykzoozYl23YVacGJb4RrpsM=.ed55cebd-9a5f-4763-b425-b0fc869b80db@github.com>

> Previously while tabbing through the JTable cell, the cell highlighter/focus ring was not visible against the selection background. 
> 
> Changes are made to Aqua LAF to derive a brighter focus ring color by changing hue, saturation and brightness of selection background color so that it is visible while tabbing through `JTable` cells. A new method is added for this purpose which takes in `selectionBackground` color, does the hue, saturation and brightness manipulation and returns a new focus ring color. There are edge cases where the HSB transformation does not yield the right focus ring color, for these cases a default color is returned that is different and can be seen against the `selectionBackground`.
> 
> **Edge Cases**
> **Selection Background**     -----       **Returned Focus Ring Color**
> - White/ Black                        ----->          Gray
> 
> - Shade of Gray 
> towards white (r=g=b >= 128)  ----->      Black
> 
> - Shade of Gray 
> towards Black (r=g=b < 128)    ------>     White
> 
> A test case is added to compare the RGB difference between the original focus ring color & selection background and the brighter focus ring color & selection background.
> 
> PS: The native L&F (Mac OS) and Swing L&F for JTable cell tabbing differs (on native tables the cell background turns white on focus with a cell focus ring). Since the background for Swing tables can be set by users and also overridden by subclassing `DefaultTableCellRenderer`, and to adhere to current implementation of Swing, the cell background changes are not incorporated. Only the Focus Ring/ Cell Highlighter is made more prominent against the selection background.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  changed javadocs for the new method and expanded imports

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7768/files
  - new: https://git.openjdk.java.net/jdk/pull/7768/files/d715aa7d..d32560ce

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7768&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7768&range=02-03

  Stats: 20 lines in 2 files changed: 6 ins; 2 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7768/head:pull/7768

PR: https://git.openjdk.java.net/jdk/pull/7768


From aivanov at openjdk.java.net  Mon Mar 14 23:30:40 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 14 Mar 2022 23:30:40 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v3]
In-Reply-To: <HYjNkqqcwMFOo-6mM2Q_4-1B5ePKD3-DRICoaF_1-bA=.53f59ac5-02f8-4c57-924c-40d22a760db1@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <HYjNkqqcwMFOo-6mM2Q_4-1B5ePKD3-DRICoaF_1-bA=.53f59ac5-02f8-4c57-924c-40d22a760db1@github.com>
Message-ID: <rW_oKMhSxIudcJoRHZBZ4wxP4loqGkQQ3w8btSsCLKQ=.2b2c4bfd-2df9-4ef3-a7b3-c7acc54426df@github.com>

On Mon, 14 Mar 2022 16:15:47 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added functions for drawing border, fixed translate

I believe is the issue is broader. I modified the test to display four panels, each panel is moved pixel to the left. The screenshots below are taken with the current JDK code _without_ Alisen's fix.

**125%**
![Border painting @ 125%](https://user-images.githubusercontent.com/70774172/158275701-d08c3ecd-d7a3-4443-aaf1-2a6a6cc3778a.png)

**150%**
![Border painting @ 150%](https://user-images.githubusercontent.com/70774172/158276212-162e0b18-5ed9-4b38-b602-c7f07e2509c7.png)


When uiScale=1.25, you can see there's background color between the shadow and highlight on the second panel. The same problem is seen for the upper border. When uiScale=1.5, you can see that some lines are 2-pixel wide and some are 1-pixel wide.

I believe it's because of rounding. I don't know how we can make sure the lines are always drawn next to each other and always have the same thickness.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From duke at openjdk.java.net  Tue Mar 15 06:12:45 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Tue, 15 Mar 2022 06:12:45 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage
In-Reply-To: <12bhwN6rQ-1c7HJtuPK7hrR0zsOeTbv0yYC2_f57v2g=.7f32d881-58e5-4d40-857c-553a855f2d7d@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <x2z-m3Sq-k2cUBobgCe9KwHBgQFY3fvHa4ZpHld9GHA=.39ce100a-a89a-4247-a265-bf79508b7e1e@github.com>
 <2s6htwoTFM0N9DBj0Ub2zK2TepiNjRuLVJsij4mnXcM=.ba4724c1-aee4-4683-acac-cb6912dc7016@github.com>
 <_Eb1usYXvARXBUeKntPJnjhdArtK4D5MycXBiTcqtTA=.ba1f35c0-aede-4348-b2f6-3370fcaf1d96@github.com>
 <2vwMFlely_NGI2XBJ_R58vD6lAqElz39ZWB7U9gavTk=.05c9e4a2-58e6-48d9-9612-2340258ee93c@github.com>
 <ff1wAeY7Sxa0YIlM3ZDDI4TJEyd0ci02_mLC_0EUhPQ=.69d61074-8e2e-4dbf-b8b1-ccb1d5b6b7ca@github.com>
 <12bhwN6rQ-1c7HJtuPK7hrR0zsOeTbv0yYC2_f57v2g=.7f32d881-58e5-4d40-857c-553a855f2d7d@github.com>
Message-ID: <CmXhKsdWszhZMI9P5P4JTzXXxQhfIRkr9ivKiAkRbr8=.9200b54a-7787-4cb2-917f-8d47018783c0@github.com>

On Fri, 11 Mar 2022 21:46:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> We shouldn't be setting any MediaTracker status here - this is the caller ! It would be absolutely wrong. And it seems likely to me that this println was put there by the developer of this code who was him/herself not sure if this would occur and what to do about it so wanted to have a message if it ever occurred so they could figure out how to handle it.
>> It seems to me that if the thread were interrupted there'd only be a very narrow window in which it likely that the image were complete and that if interrupted then I agree with what I think Alexey is saying which is that the MediaTracker may not have had a chance to even update status since it was interrupted .. depends how sophisticated the implementation is.
>> Since ImageIcon.getLoadStatus() specifies only 3 possible return values then yes, we should ensure it is one of those . So if it is LOADING then set it to ABORTED .. However a possible wrinkle is that this call being interrupted may not actually prevent the separate threads the MediaTracker kicks off from continuing .. so it may actually be still loading. And it is just that the waiting was interrupted.
>> Someone would need to dig into MediaTracker to check.
>> But since the code removes the image from the tracker .. maybe we don't care ?
>
> Since the image is removed from MediaTracker, its status can't change after that. Therefore `LOADING` status should be changed to `ABORTED`.
> [JDK-6421373](https://bugs.openjdk.java.net/browse/JDK-6421373) has a test case which can be modified to load an image and check `loadStatus` of the image.

@aivanov-jdk , even after interrupted the load status gets the "COMPLETE" status and I'm able to use the Imageicon for frame......

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From kizune at openjdk.java.net  Tue Mar 15 08:17:36 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 15 Mar 2022 08:17:36 GMT
Subject: RFR: 8024624: [TEST_BUG] [macosx] CTRL+RIGHT(LEFT) doesn't move
 selection on next cell in JTable on Aqua L&F
In-Reply-To: <LdWWDPfwqpCC-_EBaYQLX4rFIyV9FLAG5ugIJb0ruI4=.bc296640-5df9-41a1-b857-14f334c1be8e@github.com>
References: <LdWWDPfwqpCC-_EBaYQLX4rFIyV9FLAG5ugIJb0ruI4=.bc296640-5df9-41a1-b857-14f334c1be8e@github.com>
Message-ID: <U-G3bGg09vZ44Cllf28bjPAj3tPeA-tJd_YkTSDXQoQ=.1c2ab91c-d188-4bb2-b763-1354ce17fa25@github.com>

On Fri, 11 Mar 2022 23:13:15 GMT, DamonGuy <duke at openjdk.java.net> wrote:

> Aqua L&F tables lacked support for `CTRL+ARROW`, `CTRL+PG_UP/DOWN`, and `CTRL+SHIFT+PG_UP/DOWN` key bindings. This allows for navigation and selection of table cells without the need of a mouse and without deselecting the current selected cell group. 
> 
> Those key bindings are added to Aqua's key bindings for tables. The `SPACE` key binding was also added because it allows for the selection of cells after navigating using the `CTRL+ARROW` bindings, and some of the new bindings are only useful with the `SPACE` binding added. The closed test that this bug originates from tests for both left-to-right and right-to-left functionality, so the new directional bindings are also added to the right-to-left key bindings table where needed.
> 
> This requires mission control shortcuts in macOS to be disabled as `CTRL+ARROW` keys are normally used for virtual desktop navigation.

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7792


From mvs at openjdk.java.net  Tue Mar 15 09:40:42 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 15 Mar 2022 09:40:42 GMT
Subject: RFR: 8282789: Create a regression test for the JTree usecase of
 JDK-4618767
In-Reply-To: <8OsXQ_pAltihbq8L16yTW3IsYGF3nahH-Xa7fy7G3vI=.35818df7-7c9c-4acc-9b1c-63a03942914c@github.com>
References: <8OsXQ_pAltihbq8L16yTW3IsYGF3nahH-Xa7fy7G3vI=.35818df7-7c9c-4acc-9b1c-63a03942914c@github.com>
Message-ID: <HxtmM_Hk8NEymYyWHKZGuwT0AwQW3WlPHXDnUDRnucw=.ec345df3-0887-4e9d-bf3d-f48e7c4785a5@github.com>

On Tue, 8 Mar 2022 10:52:44 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Create a regression test for the JTree usecase of [JDK-4618767](https://bugs.openjdk.java.net/browse/JDK-4618767)
> Context: Migrating tests from a closed tonga based test suite to open regression based one.
> 
> Issue identified in [JDK-4618767](https://bugs.openjdk.java.net/browse/JDK-4618767):
> Typing a letter while a JTree has focus now makes the selection jump to the first/next node/item whose text starts with that letter even though that letter is accompanied by modifier keys such as ALT or CTRL.
> 
> Fix:
> Only enable JTree letter navigation when the user doesn't press any modifier keys such as ALT or CTRL.
> 
> Testing:
> Java 1.4.0 -> Test Failed.
> $ ./j2sdk1.4.0/bin/java JTreeOld
> LookAndFeel: javax.swing.plaf.metal.MetalLookAndFeel
> OS = windows nt (unknown)
> java.lang.RuntimeException: Test Failed, expected colors, but got food
>         at JTreeOld.doTest(JTreeOld.java:166)
>         at JTreeOld.main(JTreeOld.java:32)
> Exception in thread "main"
> 
> Java 1.4.1 -> Test Passed.
> $ ./j2sdk1.4.1/bin/java JTreeOld
> LookAndFeel: javax.swing.plaf.metal.MetalLookAndFeel
> OS = windows nt (unknown)
> Test passed javax.swing.plaf.metal.MetalLookAndFeel
> LookAndFeel: com.sun.java.swing.plaf.motif.MotifLookAndFeel
> OS = windows nt (unknown)
> Test passed com.sun.java.swing.plaf.motif.MotifLookAndFeel
> LookAndFeel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> OS = windows nt (unknown)
> Test passed com.sun.java.swing.plaf.windows.WindowsLookAndFeel

Any volunteers?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7742


From mvs at openjdk.java.net  Tue Mar 15 09:40:43 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 15 Mar 2022 09:40:43 GMT
Subject: RFR: 8282548: Create a regression test for JDK-4330998
In-Reply-To: <7HqoT6jmH4HyYQUli2v_MDFwkk8BV-e-0uAEFyxBmkI=.735e0071-2c02-423a-9647-9f33a0fedfa4@github.com>
References: <7HqoT6jmH4HyYQUli2v_MDFwkk8BV-e-0uAEFyxBmkI=.735e0071-2c02-423a-9647-9f33a0fedfa4@github.com>
Message-ID: <DHbZM-Y8PM-mM3_NSy2WNGTJS1vlkd1UxD4LtnweXO8=.5cfc555b-406c-4944-8772-4b5344a038f5@github.com>

On Tue, 8 Mar 2022 10:06:23 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Create a regression test for [JDK-4330998](https://bugs.openjdk.java.net/browse/JDK-4330998)
> Context: Migrating tests from a closed tonga based test suite to open regression based one.
> 
> Issue tested:
> When calling JEditorPane.setText(null), the following exception is thrown:
> 
> java.lang.NullPointerException:
>         at java.io.StringReader.<init>(StringReader.java:38)
> 
> Testing:
> Java 1.4.0 -> Test Failed.
> $ ./j2sdk1.4.0/bin/java bug4330998Win
> java.lang.RuntimeException: Test failed, caught Exception java.lang.NullPointerException when calling text.setText(null)
>         at bug4330998Win.runTest(bug4330998Win.java:45)
>         at bug4330998Win.main(bug4330998Win.java:51)
> Exception in thread "main"
> 
> Java 1.4.1 -> Test Passed.
> $ ./j2sdk1.4.1/bin/java bug4330998Win
> Test passed

Any volunteers?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7740


From aivanov at openjdk.java.net  Tue Mar 15 09:46:44 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 15 Mar 2022 09:46:44 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage
In-Reply-To: <CmXhKsdWszhZMI9P5P4JTzXXxQhfIRkr9ivKiAkRbr8=.9200b54a-7787-4cb2-917f-8d47018783c0@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <x2z-m3Sq-k2cUBobgCe9KwHBgQFY3fvHa4ZpHld9GHA=.39ce100a-a89a-4247-a265-bf79508b7e1e@github.com>
 <2s6htwoTFM0N9DBj0Ub2zK2TepiNjRuLVJsij4mnXcM=.ba4724c1-aee4-4683-acac-cb6912dc7016@github.com>
 <_Eb1usYXvARXBUeKntPJnjhdArtK4D5MycXBiTcqtTA=.ba1f35c0-aede-4348-b2f6-3370fcaf1d96@github.com>
 <2vwMFlely_NGI2XBJ_R58vD6lAqElz39ZWB7U9gavTk=.05c9e4a2-58e6-48d9-9612-2340258ee93c@github.com>
 <ff1wAeY7Sxa0YIlM3ZDDI4TJEyd0ci02_mLC_0EUhPQ=.69d61074-8e2e-4dbf-b8b1-ccb1d5b6b7ca@github.com>
 <12bhwN6rQ-1c7HJtuPK7hrR0zsOeTbv0yYC2_f57v2g=.7f32d881-58e5-4d40-857c-553a855f2d7d@github.com>
 <CmXhKsdWszhZMI9P5P4JTzXXxQhfIRkr9ivKiAkRbr8=.9200b54a-7787-4cb2-917f-8d47018783c0@github.com>
Message-ID: <l3sl0PH750Jmpq4Fwemhh6mbNZ8GMIaPnkIY_CFhULc=.b787aeee-6a15-44d7-9d22-40cb208f89a5@github.com>

On Tue, 15 Mar 2022 06:09:40 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> Since the image is removed from MediaTracker, its status can't change after that. Therefore `LOADING` status should be changed to `ABORTED`.
>> [JDK-6421373](https://bugs.openjdk.java.net/browse/JDK-6421373) has a test case which can be modified to load an image and check `loadStatus` of the image.
>
> @aivanov-jdk , even after interrupted the load status gets the "COMPLETE" status and I'm able to use the Imageicon for frame......

@TejeshR13, What kind of image do you load?

If I load an image from the Internet, I get `LOADING` status. I've attached `ImageIconInterrupt.java` to [JDK-6421373](https://bugs.openjdk.java.net/browse/JDK-6421373). It produces the following output:


INTERRUPTED while loading Image
false
1
    LOADING

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From duke at openjdk.java.net  Tue Mar 15 11:51:41 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Tue, 15 Mar 2022 11:51:41 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage
In-Reply-To: <l3sl0PH750Jmpq4Fwemhh6mbNZ8GMIaPnkIY_CFhULc=.b787aeee-6a15-44d7-9d22-40cb208f89a5@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <x2z-m3Sq-k2cUBobgCe9KwHBgQFY3fvHa4ZpHld9GHA=.39ce100a-a89a-4247-a265-bf79508b7e1e@github.com>
 <2s6htwoTFM0N9DBj0Ub2zK2TepiNjRuLVJsij4mnXcM=.ba4724c1-aee4-4683-acac-cb6912dc7016@github.com>
 <_Eb1usYXvARXBUeKntPJnjhdArtK4D5MycXBiTcqtTA=.ba1f35c0-aede-4348-b2f6-3370fcaf1d96@github.com>
 <2vwMFlely_NGI2XBJ_R58vD6lAqElz39ZWB7U9gavTk=.05c9e4a2-58e6-48d9-9612-2340258ee93c@github.com>
 <ff1wAeY7Sxa0YIlM3ZDDI4TJEyd0ci02_mLC_0EUhPQ=.69d61074-8e2e-4dbf-b8b1-ccb1d5b6b7ca@github.com>
 <12bhwN6rQ-1c7HJtuPK7hrR0zsOeTbv0yYC2_f57v2g=.7f32d881-58e5-4d40-857c-553a855f2d7d@github.com>
 <CmXhKsdWszhZMI9P5P4JTzXXxQhfIRkr9ivKiAkRbr8=.9200b54a-7787-4cb2-917f-8d47018783c0@github.com>
 <l3sl0PH750Jmpq4Fwemhh6mbNZ8GMIaPnkIY_CFhULc=.b787aeee-6a15-44d7-9d22-40cb208f89a5@github.com>
Message-ID: <eQvsDJueLEcrNuhX7rWh7U0ve7Y35WT3RbyM4TlFQf4=.6aca8551-bd28-450a-98cb-1459ad184d76@github.com>

On Tue, 15 Mar 2022 09:43:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @aivanov-jdk , even after interrupted the load status gets the "COMPLETE" status and I'm able to use the Imageicon for frame......
>
> @TejeshR13, What kind of image do you load?
> 
> If I load an image from the Internet, I get `LOADING` status. I've attached `ImageIconInterrupt.java` to [JDK-6421373](https://bugs.openjdk.java.net/browse/JDK-6421373). It produces the following output:
> 
> 
> INTERRUPTED while loading Image
> false
> 1
>     LOADING

I have loaded gif image from local storage.....

INTERRUPTED while loading Image
false
    COMPLETE

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From duke at openjdk.java.net  Tue Mar 15 11:51:41 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Tue, 15 Mar 2022 11:51:41 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage
In-Reply-To: <eQvsDJueLEcrNuhX7rWh7U0ve7Y35WT3RbyM4TlFQf4=.6aca8551-bd28-450a-98cb-1459ad184d76@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <x2z-m3Sq-k2cUBobgCe9KwHBgQFY3fvHa4ZpHld9GHA=.39ce100a-a89a-4247-a265-bf79508b7e1e@github.com>
 <2s6htwoTFM0N9DBj0Ub2zK2TepiNjRuLVJsij4mnXcM=.ba4724c1-aee4-4683-acac-cb6912dc7016@github.com>
 <_Eb1usYXvARXBUeKntPJnjhdArtK4D5MycXBiTcqtTA=.ba1f35c0-aede-4348-b2f6-3370fcaf1d96@github.com>
 <2vwMFlely_NGI2XBJ_R58vD6lAqElz39ZWB7U9gavTk=.05c9e4a2-58e6-48d9-9612-2340258ee93c@github.com>
 <ff1wAeY7Sxa0YIlM3ZDDI4TJEyd0ci02_mLC_0EUhPQ=.69d61074-8e2e-4dbf-b8b1-ccb1d5b6b7ca@github.com>
 <12bhwN6rQ-1c7HJtuPK7hrR0zsOeTbv0yYC2_f57v2g=.7f32d881-58e5-4d40-857c-553a855f2d7d@github.com>
 <CmXhKsdWszhZMI9P5P4JTzXXxQhfIRkr9ivKiAkRbr8=.9200b54a-7787-4cb2-917f-8d47018783c0@github.com>
 <l3sl0PH750Jmpq4Fwemhh6mbNZ8GMIaPnkIY_CFhULc=.b787aeee-6a15-44d7-9d22-40cb208f89a5@github.com>
 <eQvsDJueLEcrNuhX7rWh7U0ve7Y35WT3RbyM4TlFQf4=.6aca8551-bd28-450a-98cb-1459ad184d76@github.com>
Message-ID: <h0p_NhQwSKmP8OuBHOGEYoyzeo6l2UPXG3q3HZDc90E=.14c53922-5eac-4899-a30a-e3247b7aedb2@github.com>

On Tue, 15 Mar 2022 11:47:28 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> @TejeshR13, What kind of image do you load?
>> 
>> If I load an image from the Internet, I get `LOADING` status. I've attached `ImageIconInterrupt.java` to [JDK-6421373](https://bugs.openjdk.java.net/browse/JDK-6421373). It produces the following output:
>> 
>> 
>> INTERRUPTED while loading Image
>> false
>> 1
>>     LOADING
>
> I have loaded gif image from local storage.....
> 
> INTERRUPTED while loading Image
> false
>     COMPLETE

For url image I'm getting "ERRORED" as output......

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From aivanov at openjdk.java.net  Tue Mar 15 12:03:42 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 15 Mar 2022 12:03:42 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage
In-Reply-To: <h0p_NhQwSKmP8OuBHOGEYoyzeo6l2UPXG3q3HZDc90E=.14c53922-5eac-4899-a30a-e3247b7aedb2@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <x2z-m3Sq-k2cUBobgCe9KwHBgQFY3fvHa4ZpHld9GHA=.39ce100a-a89a-4247-a265-bf79508b7e1e@github.com>
 <2s6htwoTFM0N9DBj0Ub2zK2TepiNjRuLVJsij4mnXcM=.ba4724c1-aee4-4683-acac-cb6912dc7016@github.com>
 <_Eb1usYXvARXBUeKntPJnjhdArtK4D5MycXBiTcqtTA=.ba1f35c0-aede-4348-b2f6-3370fcaf1d96@github.com>
 <2vwMFlely_NGI2XBJ_R58vD6lAqElz39ZWB7U9gavTk=.05c9e4a2-58e6-48d9-9612-2340258ee93c@github.com>
 <ff1wAeY7Sxa0YIlM3ZDDI4TJEyd0ci02_mLC_0EUhPQ=.69d61074-8e2e-4dbf-b8b1-ccb1d5b6b7ca@github.com>
 <12bhwN6rQ-1c7HJtuPK7hrR0zsOeTbv0yYC2_f57v2g=.7f32d881-58e5-4d40-857c-553a855f2d7d@github.com>
 <CmXhKsdWszhZMI9P5P4JTzXXxQhfIRkr9ivKiAkRbr8=.9200b54a-7787-4cb2-917f-8d47018783c0@github.com>
 <l3sl0PH750Jmpq4Fwemhh6mbNZ8GMIaPnkIY_CFhULc=.b787aeee-6a15-44d7-9d22-40cb208f89a5@github.com>
 <eQvsDJueLEcrNuhX7rWh7U0ve7Y35WT3RbyM4TlFQf4=.6aca8551-bd28-450a-98cb-1459ad184d76@github.com>
 <h0p_NhQwSKmP8OuBHOGEYoyzeo6l2UPXG3q
 3HZDc90E=.14c53922-5eac-4899-a30a-e3247b7aedb2@github.com>
Message-ID: <g7rzM90QOJYOWPCassms0VpEItLd5sK4QPWQbvuBRHQ=.0988cf8e-a060-43e1-82d8-9c45636a6cdd@github.com>

On Tue, 15 Mar 2022 11:48:23 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> I have loaded gif image from local storage.....
>> 
>> INTERRUPTED while loading Image
>> false
>>     COMPLETE
>
> For url image I'm getting "ERRORED" as output......

A small file from local storage loads fast enough. By the time you get to read status, load could complete.

For the url, do you use the same URL? If the connection can be established, it should load pretty fast too. However, if you need a proxy server to access the Internet but you won't provide one, it won't load as fast, nor will it report error fast enough.

Anyway, my example above confirms *it's possible the status remains `LOADING`*. But the image isn't loading, it will never load and its status will never change, so you have to amend the status to a correct one.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From duke at openjdk.java.net  Tue Mar 15 12:13:48 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Tue, 15 Mar 2022 12:13:48 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage
In-Reply-To: <g7rzM90QOJYOWPCassms0VpEItLd5sK4QPWQbvuBRHQ=.0988cf8e-a060-43e1-82d8-9c45636a6cdd@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <x2z-m3Sq-k2cUBobgCe9KwHBgQFY3fvHa4ZpHld9GHA=.39ce100a-a89a-4247-a265-bf79508b7e1e@github.com>
 <2s6htwoTFM0N9DBj0Ub2zK2TepiNjRuLVJsij4mnXcM=.ba4724c1-aee4-4683-acac-cb6912dc7016@github.com>
 <_Eb1usYXvARXBUeKntPJnjhdArtK4D5MycXBiTcqtTA=.ba1f35c0-aede-4348-b2f6-3370fcaf1d96@github.com>
 <2vwMFlely_NGI2XBJ_R58vD6lAqElz39ZWB7U9gavTk=.05c9e4a2-58e6-48d9-9612-2340258ee93c@github.com>
 <ff1wAeY7Sxa0YIlM3ZDDI4TJEyd0ci02_mLC_0EUhPQ=.69d61074-8e2e-4dbf-b8b1-ccb1d5b6b7ca@github.com>
 <12bhwN6rQ-1c7HJtuPK7hrR0zsOeTbv0yYC2_f57v2g=.7f32d881-58e5-4d40-857c-553a855f2d7d@github.com>
 <CmXhKsdWszhZMI9P5P4JTzXXxQhfIRkr9ivKiAkRbr8=.9200b54a-7787-4cb2-917f-8d47018783c0@github.com>
 <l3sl0PH750Jmpq4Fwemhh6mbNZ8GMIaPnkIY_CFhULc=.b787aeee-6a15-44d7-9d22-40cb208f89a5@github.com>
 <eQvsDJueLEcrNuhX7rWh7U0ve7Y35WT3RbyM4TlFQf4=.6aca8551-bd28-450a-98cb-1459ad184d76@github.com>
 <h0p_NhQwSKmP8OuBHOGEYoyzeo6l2UPXG3q
 3HZDc90E=.14c53922-5eac-4899-a30a-e3247b7aedb2@github.com>
 <g7rzM90QOJYOWPCassms0VpEItLd5sK4QPWQbvuBRHQ=.0988cf8e-a060-43e1-82d8-9c45636a6cdd@github.com>
Message-ID: <vuhx4d5_DhaHgit3e6huWZk6h7Md-SQSQpg9pzubINI=.5cd57716-85fd-4e65-984c-8ce9a443cf4c@github.com>

On Tue, 15 Mar 2022 12:00:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> For url image I'm getting "ERRORED" as output......
>
> A small file from local storage loads fast enough. By the time you get to read status, load could complete.
> 
> For the url, do you use the same URL? If the connection can be established, it should load pretty fast too. However, if you need a proxy server to access the Internet but you won't provide one, it won't load as fast, nor will it report error fast enough.
> 
> Anyway, my example above confirms *it's possible the status remains `LOADING`*. But the image isn't loading, it will never load and its status will never change, so you have to amend the status to a correct one.

Yeah, got it...... I used the same url though......

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From duke at openjdk.java.net  Tue Mar 15 12:13:48 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Tue, 15 Mar 2022 12:13:48 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage
In-Reply-To: <vuhx4d5_DhaHgit3e6huWZk6h7Md-SQSQpg9pzubINI=.5cd57716-85fd-4e65-984c-8ce9a443cf4c@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <x2z-m3Sq-k2cUBobgCe9KwHBgQFY3fvHa4ZpHld9GHA=.39ce100a-a89a-4247-a265-bf79508b7e1e@github.com>
 <2s6htwoTFM0N9DBj0Ub2zK2TepiNjRuLVJsij4mnXcM=.ba4724c1-aee4-4683-acac-cb6912dc7016@github.com>
 <_Eb1usYXvARXBUeKntPJnjhdArtK4D5MycXBiTcqtTA=.ba1f35c0-aede-4348-b2f6-3370fcaf1d96@github.com>
 <2vwMFlely_NGI2XBJ_R58vD6lAqElz39ZWB7U9gavTk=.05c9e4a2-58e6-48d9-9612-2340258ee93c@github.com>
 <ff1wAeY7Sxa0YIlM3ZDDI4TJEyd0ci02_mLC_0EUhPQ=.69d61074-8e2e-4dbf-b8b1-ccb1d5b6b7ca@github.com>
 <12bhwN6rQ-1c7HJtuPK7hrR0zsOeTbv0yYC2_f57v2g=.7f32d881-58e5-4d40-857c-553a855f2d7d@github.com>
 <CmXhKsdWszhZMI9P5P4JTzXXxQhfIRkr9ivKiAkRbr8=.9200b54a-7787-4cb2-917f-8d47018783c0@github.com>
 <l3sl0PH750Jmpq4Fwemhh6mbNZ8GMIaPnkIY_CFhULc=.b787aeee-6a15-44d7-9d22-40cb208f89a5@github.com>
 <eQvsDJueLEcrNuhX7rWh7U0ve7Y35WT3RbyM4TlFQf4=.6aca8551-bd28-450a-98cb-1459ad184d76@github.com>
 <h0p_NhQwSKmP8OuBHOGEYoyzeo6l2UPXG3q
 3HZDc90E=.14c53922-5eac-4899-a30a-e3247b7aedb2@github.com>
 <g7rzM90QOJYOWPCassms0VpEItLd5sK4QPWQbvuBRHQ=.0988cf8e-a060-43e1-82d8-9c45636a6cdd@github.com>
 <vuhx4d5_DhaHgit3e6huWZk6h7Md-SQSQpg9pzubINI=.5cd57716-85fd-4e65-984c-8ce9a443cf4c@github.com>
Message-ID: <Dw2TE7TgfsSKpDLvaDDFXzch5SJo__BNHTUAx6UGud8=.57bfa980-c939-43e2-adc3-da23cd60e75a@github.com>

On Tue, 15 Mar 2022 12:09:12 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> A small file from local storage loads fast enough. By the time you get to read status, load could complete.
>> 
>> For the url, do you use the same URL? If the connection can be established, it should load pretty fast too. However, if you need a proxy server to access the Internet but you won't provide one, it won't load as fast, nor will it report error fast enough.
>> 
>> Anyway, my example above confirms *it's possible the status remains `LOADING`*. But the image isn't loading, it will never load and its status will never change, so you have to amend the status to a correct one.
>
> Yeah, got it...... I used the same url though......

N for current bug, where to change to change the status to "ABORTED"......?? As I cannot change in ImageIcon class......

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From duke at openjdk.java.net  Tue Mar 15 13:33:48 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Tue, 15 Mar 2022 13:33:48 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage
In-Reply-To: <g7rzM90QOJYOWPCassms0VpEItLd5sK4QPWQbvuBRHQ=.0988cf8e-a060-43e1-82d8-9c45636a6cdd@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <x2z-m3Sq-k2cUBobgCe9KwHBgQFY3fvHa4ZpHld9GHA=.39ce100a-a89a-4247-a265-bf79508b7e1e@github.com>
 <2s6htwoTFM0N9DBj0Ub2zK2TepiNjRuLVJsij4mnXcM=.ba4724c1-aee4-4683-acac-cb6912dc7016@github.com>
 <_Eb1usYXvARXBUeKntPJnjhdArtK4D5MycXBiTcqtTA=.ba1f35c0-aede-4348-b2f6-3370fcaf1d96@github.com>
 <2vwMFlely_NGI2XBJ_R58vD6lAqElz39ZWB7U9gavTk=.05c9e4a2-58e6-48d9-9612-2340258ee93c@github.com>
 <ff1wAeY7Sxa0YIlM3ZDDI4TJEyd0ci02_mLC_0EUhPQ=.69d61074-8e2e-4dbf-b8b1-ccb1d5b6b7ca@github.com>
 <12bhwN6rQ-1c7HJtuPK7hrR0zsOeTbv0yYC2_f57v2g=.7f32d881-58e5-4d40-857c-553a855f2d7d@github.com>
 <CmXhKsdWszhZMI9P5P4JTzXXxQhfIRkr9ivKiAkRbr8=.9200b54a-7787-4cb2-917f-8d47018783c0@github.com>
 <l3sl0PH750Jmpq4Fwemhh6mbNZ8GMIaPnkIY_CFhULc=.b787aeee-6a15-44d7-9d22-40cb208f89a5@github.com>
 <eQvsDJueLEcrNuhX7rWh7U0ve7Y35WT3RbyM4TlFQf4=.6aca8551-bd28-450a-98cb-1459ad184d76@github.com>
 <h0p_NhQwSKmP8OuBHOGEYoyzeo6l2UPXG3q
 3HZDc90E=.14c53922-5eac-4899-a30a-e3247b7aedb2@github.com>
 <g7rzM90QOJYOWPCassms0VpEItLd5sK4QPWQbvuBRHQ=.0988cf8e-a060-43e1-82d8-9c45636a6cdd@github.com>
Message-ID: <cI824Y1ZXkOkmJAKg78Hf0hSGnvujX831Ebl-VWprJY=.11a0627d-7d00-41e4-8d8c-d9a2f45848ff@github.com>

On Tue, 15 Mar 2022 12:00:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> For url image I'm getting "ERRORED" as output......
>
> A small file from local storage loads fast enough. By the time you get to read status, load could complete.
> 
> For the url, do you use the same URL? If the connection can be established, it should load pretty fast too. However, if you need a proxy server to access the Internet but you won't provide one, it won't load as fast, nor will it report error fast enough.
> 
> Anyway, my example above confirms *it's possible the status remains `LOADING`*. But the image isn't loading, it will never load and its status will never change, so you have to amend the status to a correct one.

@aivanov-jdk , U r right, the status remains LOADING for url...... I was getting "ERRORED" because I was showing a message using `JOptionPane.showMessageDialog(null, "");` before setting ImageIcon.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From aivanov at openjdk.java.net  Tue Mar 15 16:45:49 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 15 Mar 2022 16:45:49 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage
In-Reply-To: <g7rzM90QOJYOWPCassms0VpEItLd5sK4QPWQbvuBRHQ=.0988cf8e-a060-43e1-82d8-9c45636a6cdd@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <x2z-m3Sq-k2cUBobgCe9KwHBgQFY3fvHa4ZpHld9GHA=.39ce100a-a89a-4247-a265-bf79508b7e1e@github.com>
 <2s6htwoTFM0N9DBj0Ub2zK2TepiNjRuLVJsij4mnXcM=.ba4724c1-aee4-4683-acac-cb6912dc7016@github.com>
 <_Eb1usYXvARXBUeKntPJnjhdArtK4D5MycXBiTcqtTA=.ba1f35c0-aede-4348-b2f6-3370fcaf1d96@github.com>
 <2vwMFlely_NGI2XBJ_R58vD6lAqElz39ZWB7U9gavTk=.05c9e4a2-58e6-48d9-9612-2340258ee93c@github.com>
 <ff1wAeY7Sxa0YIlM3ZDDI4TJEyd0ci02_mLC_0EUhPQ=.69d61074-8e2e-4dbf-b8b1-ccb1d5b6b7ca@github.com>
 <12bhwN6rQ-1c7HJtuPK7hrR0zsOeTbv0yYC2_f57v2g=.7f32d881-58e5-4d40-857c-553a855f2d7d@github.com>
 <CmXhKsdWszhZMI9P5P4JTzXXxQhfIRkr9ivKiAkRbr8=.9200b54a-7787-4cb2-917f-8d47018783c0@github.com>
 <l3sl0PH750Jmpq4Fwemhh6mbNZ8GMIaPnkIY_CFhULc=.b787aeee-6a15-44d7-9d22-40cb208f89a5@github.com>
 <eQvsDJueLEcrNuhX7rWh7U0ve7Y35WT3RbyM4TlFQf4=.6aca8551-bd28-450a-98cb-1459ad184d76@github.com>
 <h0p_NhQwSKmP8OuBHOGEYoyzeo6l2UPXG3q
 3HZDc90E=.14c53922-5eac-4899-a30a-e3247b7aedb2@github.com>
 <g7rzM90QOJYOWPCassms0VpEItLd5sK4QPWQbvuBRHQ=.0988cf8e-a060-43e1-82d8-9c45636a6cdd@github.com>
Message-ID: <gKc7_on4YFxqKyJNk7by9Aclvm2PE7pdyVlPs4ezSe8=.5e841e2f-645f-43b8-800a-bf490c698d64@github.com>

On Tue, 15 Mar 2022 12:00:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> For url image I'm getting "ERRORED" as output......
>
> A small file from local storage loads fast enough. By the time you get to read status, load could complete.
> 
> For the url, do you use the same URL? If the connection can be established, it should load pretty fast too. However, if you need a proxy server to access the Internet but you won't provide one, it won't load as fast, nor will it report error fast enough.
> 
> Anyway, my example above confirms *it's possible the status remains `LOADING`*. But the image isn't loading, it will never load and its status will never change, so you have to amend the status to a correct one.

> @aivanov-jdk , U r right, the status remains LOADING for url...... I was getting "ERRORED" because I was showing a message using `JOptionPane.showMessageDialog(null, "");` before setting ImageIcon.

Ah, with the message dialog shown there's enough time to complete loading the image.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From aivanov at openjdk.java.net  Tue Mar 15 16:52:50 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 15 Mar 2022 16:52:50 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage
In-Reply-To: <gKc7_on4YFxqKyJNk7by9Aclvm2PE7pdyVlPs4ezSe8=.5e841e2f-645f-43b8-800a-bf490c698d64@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <x2z-m3Sq-k2cUBobgCe9KwHBgQFY3fvHa4ZpHld9GHA=.39ce100a-a89a-4247-a265-bf79508b7e1e@github.com>
 <2s6htwoTFM0N9DBj0Ub2zK2TepiNjRuLVJsij4mnXcM=.ba4724c1-aee4-4683-acac-cb6912dc7016@github.com>
 <_Eb1usYXvARXBUeKntPJnjhdArtK4D5MycXBiTcqtTA=.ba1f35c0-aede-4348-b2f6-3370fcaf1d96@github.com>
 <2vwMFlely_NGI2XBJ_R58vD6lAqElz39ZWB7U9gavTk=.05c9e4a2-58e6-48d9-9612-2340258ee93c@github.com>
 <ff1wAeY7Sxa0YIlM3ZDDI4TJEyd0ci02_mLC_0EUhPQ=.69d61074-8e2e-4dbf-b8b1-ccb1d5b6b7ca@github.com>
 <12bhwN6rQ-1c7HJtuPK7hrR0zsOeTbv0yYC2_f57v2g=.7f32d881-58e5-4d40-857c-553a855f2d7d@github.com>
 <CmXhKsdWszhZMI9P5P4JTzXXxQhfIRkr9ivKiAkRbr8=.9200b54a-7787-4cb2-917f-8d47018783c0@github.com>
 <l3sl0PH750Jmpq4Fwemhh6mbNZ8GMIaPnkIY_CFhULc=.b787aeee-6a15-44d7-9d22-40cb208f89a5@github.com>
 <eQvsDJueLEcrNuhX7rWh7U0ve7Y35WT3RbyM4TlFQf4=.6aca8551-bd28-450a-98cb-1459ad184d76@github.com>
 <h0p_NhQwSKmP8OuBHOGEYoyzeo6l2UPXG3q
 3HZDc90E=.14c53922-5eac-4899-a30a-e3247b7aedb2@github.com>
 <g7rzM90QOJYOWPCassms0VpEItLd5sK4QPWQbvuBRHQ=.0988cf8e-a060-43e1-82d8-9c45636a6cdd@github.com>
 <gKc7_on4YFxqKyJNk7by9Aclvm2PE7pdyVlPs4ezSe8=.5e841e2f-645f-43b8-800a-bf490c698d64@github.com>
Message-ID: <84GSdxltlxqnh0OMbSAV0VufpS9yb1PAmAQETFNBtg0=.7f504119-83bf-4920-8514-0e3818ca6b75@github.com>

On Tue, 15 Mar 2022 16:42:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> A small file from local storage loads fast enough. By the time you get to read status, load could complete.
>> 
>> For the url, do you use the same URL? If the connection can be established, it should load pretty fast too. However, if you need a proxy server to access the Internet but you won't provide one, it won't load as fast, nor will it report error fast enough.
>> 
>> Anyway, my example above confirms *it's possible the status remains `LOADING`*. But the image isn't loading, it will never load and its status will never change, so you have to amend the status to a correct one.
>
>> @aivanov-jdk , U r right, the status remains LOADING for url...... I was getting "ERRORED" because I was showing a message using `JOptionPane.showMessageDialog(null, "");` before setting ImageIcon.
> 
> Ah, with the message dialog shown there's enough time to complete loading the image.

> N for current bug, where to change to change the status to "ABORTED"......?? As I cannot change in ImageIcon class......

Why can't you change the status in `ImageIcon`? It's where you change it.


            loadStatus = mTracker.statusID(id, false);
            mTracker.removeImage(image, id);
            if (loadStatus & MediaTracker.LOADING != 0) {
                loadStatus = MediaTracker.ABORTED;
            }

The first two lines already exist, right after the catching `InterruptedException`. You just need to add the `if` block to amend the status.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From aivanov at openjdk.java.net  Tue Mar 15 17:02:40 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 15 Mar 2022 17:02:40 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v3]
In-Reply-To: <fi8MEGQe9erx0-u_LMq9-q7ALJ1Zf94YIJq3pKHFr64=.5e22a698-3cfc-40d6-bc0c-c4198c243a2f@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <6pGT5DmJQoDUOkO7uGHHh3DgPrtciQWTerAigWPh4-4=.85547921-1017-438c-9af4-7e3b90c06bb2@github.com>
 <fi8MEGQe9erx0-u_LMq9-q7ALJ1Zf94YIJq3pKHFr64=.5e22a698-3cfc-40d6-bc0c-c4198c243a2f@github.com>
Message-ID: <HyoXHjBNe-uEzk4Okizp-SxKqKANc--oMs6U9l0izYw=.d861cb3c-70c2-463f-9424-61f19bdbac25@github.com>

On Fri, 11 Mar 2022 18:46:25 GMT, Phil Race <prr at openjdk.org> wrote:

> I recognise that positioning is another issue but I've never seen a window manager position a window so that it is partially off-screen unless it cannot fit !

Windows allows positioning a window so that it's partially or completely off screen. It has happened to me a few times that an app displayed its window off screen when display arrangement changed from the previous start of the app. I had to use the window context menu to move it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From duke at openjdk.java.net  Tue Mar 15 17:34:48 2022
From: duke at openjdk.java.net (lukeu)
Date: Tue, 15 Mar 2022 17:34:48 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v3]
In-Reply-To: <HYjNkqqcwMFOo-6mM2Q_4-1B5ePKD3-DRICoaF_1-bA=.53f59ac5-02f8-4c57-924c-40d22a760db1@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <HYjNkqqcwMFOo-6mM2Q_4-1B5ePKD3-DRICoaF_1-bA=.53f59ac5-02f8-4c57-924c-40d22a760db1@github.com>
Message-ID: <JWOVqPWqxmWGG0SQV97rQGTPcZNPcGcgcmNwc1YRO6I=.224d5021-d155-477b-a144-7becafbe08e1@github.com>

On Mon, 14 Mar 2022 16:15:47 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added functions for drawing border, fixed translate

Good catch. I'm not in a position to build this patch right now, but I suspect that if you put such a border in the right-hand-side of a splitter pane, then as you drag the splitter's divider, the light lines would still be jumping in and out from underneath the dark ones and/or 'jiggling' in width. (When tested at 125%, 175% etc)

> I believe it's because of rounding. I don't know how we can make sure the lines are always drawn next to each other and always have the same thickness.

I believe the only way to get pixel-perfect (& balanced weight) rendering of 2 lines next to each other at non-integer scale factors, when using integer based APIs like `drawLine`, will be to undo the affine transformation upon the pre-scaled `Graphics2D` object, and render it at 1x scaling. Then you'd need to decide how to compute the desired line thickness (like: should it jump 1px > 2px at 150% scaling or 175% scaling?)

(IMHO, the JDK-9+ approach of passing in a pre-scaled Graphics object is a bit of a coarse approximation - useful for components that haven't natively considered HiDPI yet. I'm happy to see the built-in L&F code being improved in cases like this; while noting that there are many more.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From aivanov at openjdk.java.net  Tue Mar 15 17:38:49 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 15 Mar 2022 17:38:49 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v3]
In-Reply-To: <AjXPovXtONhw81RyxSHYTlzz3h9z_spSVyqbRDRNTYM=.72af466a-c0bc-4567-b47c-cca03fa51940@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <6pGT5DmJQoDUOkO7uGHHh3DgPrtciQWTerAigWPh4-4=.85547921-1017-438c-9af4-7e3b90c06bb2@github.com>
 <AjXPovXtONhw81RyxSHYTlzz3h9z_spSVyqbRDRNTYM=.72af466a-c0bc-4567-b47c-cca03fa51940@github.com>
Message-ID: <Y-qRKm6tX3cAFHK4miwhphfSXjUm-NkJocqI1wc0rKw=.6e23594b-c2ab-4dc0-a617-c342f18a26c8@github.com>

On Thu, 10 Mar 2022 11:22:15 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   HiDPIRobotScreenCaptureTest.java: smaller frame size such that it fits on a 1200x600 screen.
>>   
>>   ScreenCaptureGtkTest.java: smaller frame size; added code to save
>>   the image on failure.
>
> The initial reason for `ScreenCaptureGtkTest` failure was that on Linux the window was *sometimes* positioned such that some of the pixels targeted by `Robot` couldn't be pointed to by the underlying GTK API. So these failures were intermittent and out of control of the test itself; change of the windows' size could've simply changed the window manager's logic for position calculation and thus accidentally made the test pass.

@mkartashev The test results are good.

> The initial reason for ScreenCaptureGtkTest failure was that on Linux the window was sometimes positioned such that some of the pixels targeted by Robot couldn't be pointed to by the underlying GTK API. So these failures were intermittent and out of control of the test itself; change of the windows' size could've simply changed the window manager's logic for position calculation and thus accidentally made the test pass.

I see, thank you for clarification.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From aivanov at openjdk.java.net  Tue Mar 15 18:39:47 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 15 Mar 2022 18:39:47 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v3]
In-Reply-To: <6pGT5DmJQoDUOkO7uGHHh3DgPrtciQWTerAigWPh4-4=.85547921-1017-438c-9af4-7e3b90c06bb2@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <6pGT5DmJQoDUOkO7uGHHh3DgPrtciQWTerAigWPh4-4=.85547921-1017-438c-9af4-7e3b90c06bb2@github.com>
Message-ID: <YjMqSHlsU6LfGWIXUQvAgXfZ48wyneNTPdyJ6csbFHo=.0916e014-4ce9-4903-888b-5a132a5f52e8@github.com>

On Wed, 9 Mar 2022 13:35:44 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> The two tests `ScreenCaptureGtkTest.java` and `HiDPIRobotScreenCaptureTest.java` under `java/awt/Robot/HiDPIScreenCapture` started to intermittently fail under Windows and Linux after the [recent changes](https://github.com/openjdk/jdk/commit/cc7cf81256ed4d74493472017b1c4df20fa2208a) made exclusively for the Linux `Robot` implementation.
>> 
>> `HiDPIRobotScreenCaptureTest.java`
>> Since the Windows failures cannot possibly have their origin in the fix made - the latter being Linux-only - the test apparently either exposes an existing bug in the Windows `Robot` or is bumping against a peculiarity of that platform. The test is reverted back to its original form that didn't fail.
>> 
>> `ScreenCaptureGtkTest.java`
>> The coordinates in the log `(83, 78)` of a failure are higher up than the test suggests `(83, 97)`. I've seen similar failures on Ubuntu 20.04 when the coordinates were set to `(0, 0)`. The color then picked matched the color of the bar drawn at the top of the screen. I believe it's best to place the test pixels towards the center of the window to avoid desktop elements interference.
>> 
>> The other possible reason for intermittent failures are window coordinates. Suppose that the test is executing with `sun.java2d.uiScale` set to 2. This effectively means that it can only pick colors of pixels at even coordinates (in the absolute desktop space). So if the window is placed at, say, `(201, 201)`, `Robot` can only pick the color at either `(200, 200)` or `(202, 202)`. Since the test only makes sense if it is pixel-accurate, I removed all `@run`s with `sun.java2d.uiScale` other than 1. This way window placement will not cause a failure.
>> 
>> This was tested on Ubuntu 20.04 and 18.04 with desktop scaling set to 100%, 200%, and 300%.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   HiDPIRobotScreenCaptureTest.java: smaller frame size such that it fits on a 1200x600 screen.
>   
>   ScreenCaptureGtkTest.java: smaller frame size; added code to save
>   the image on failure.

test/jdk/java/awt/Robot/HiDPIScreenCapture/HiDPIRobotScreenCaptureTest.java line 42:

> 40:  * @key headful
> 41:  * @bug 8073320
> 42:  * @summary  Windows HiDPI support

The test is run on Linux, so it makes sense to keep Linux in the summary.

Why do you remove 8280861 from the list of bugs?

test/jdk/java/awt/Robot/HiDPIScreenCapture/HiDPIRobotScreenCaptureTest.java line 49:

> 47:  *                    HiDPIRobotScreenCaptureTest
> 48:  * @run main/othervm -Dsun.java2d.uiScale=1 HiDPIRobotScreenCaptureTest
> 49:  * @run main/othervm -Dsun.java2d.uiScale=2 HiDPIRobotScreenCaptureTest

I propose keeping these added variants if they add value. However, the test will need rerunning.

It proved that the test failed on the first variant with uiScale set to 3?2.

test/jdk/java/awt/Robot/HiDPIScreenCapture/HiDPIRobotScreenCaptureTest.java line 66:

> 64: 
> 65:         Frame frame = new Frame();
> 66:         frame.setBounds(83, 97, 100, 100);

Does it make sense to preserve the comment? It explain the rationale for using the prime numbers as coordinates. The location remains unchanged, so the comment applies.

test/jdk/java/awt/Robot/HiDPIScreenCapture/HiDPIRobotScreenCaptureTest.java line 111:

> 109:         checkRectColor(image, 3 * w / 4, h / 4, COLORS[1]);
> 110:         checkRectColor(image, w / 4, 3 * h / 4, COLORS[2]);
> 111:         checkRectColor(image, 3 * w / 4, 3 * h / 4, COLORS[3]);

As my testing showed, this test was stable enough with the changes introduced by [JDK-8282270](https://bugs.openjdk.java.net/browse/JDK-8282270), #7425, with the reduced size of the frame.

test/jdk/java/awt/Robot/HiDPIScreenCapture/ScreenCaptureGtkTest.java line 68:

> 66:         // by the system because that area's occupied by the global
> 67:         // menu bar and such.
> 68:         frame.setBounds(89, 99, 100, 100);

99 is not a prime number. Is it intentional?

test/jdk/java/awt/Robot/HiDPIScreenCapture/ScreenCaptureGtkTest.java line 84:

> 82:                 for (int i = 1; i < 4; i++) {
> 83:                     g.setColor(COLORS[i]);
> 84:                     g.fillRect(leftOffset + i, topOffset, 1, 1);

May I suggest using `COLORS.length` instead of 4 in the for-loops for painting and checking?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From aivanov at openjdk.java.net  Tue Mar 15 18:39:47 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 15 Mar 2022 18:39:47 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v2]
In-Reply-To: <r1RvzuRuDC0e_agpDZsdu6obb8f5i-Hs5Du5_ghXYJA=.4e59556e-e8e7-4b6e-a569-b636f0f676f7@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <6sowygRcdclz1LCYIHZSWMKV2LhuPo0D_EaYC_JIq0c=.b25c1f95-2510-4372-a8e4-99178d1762ce@github.com>
 <9TbYruwfo7JM4xbW6Mwj_WAAXdbrZR3O62Cc6xgt2TI=.74af7b62-adef-4b98-b195-4f9d47d5098d@github.com>
 <e2kuv7ZIhCBFVsdOaBTQLsvEah30BhTsk721cke6nsc=.a16cdabb-7566-418d-b89e-de43b9573290@github.com>
 <oTP9s3hH1t5pNZz3PA-VvGs07r7KcBory6QosyVesRA=.cf4b7478-116d-4a28-88da-5dd7c91e0bbe@github.com>
 <r1RvzuRuDC0e_agpDZsdu6obb8f5i-Hs5Du5_ghXYJA=.4e59556e-e8e7-4b6e-a569-b636f0f676f7@github.com>
Message-ID: <gPMGgZlJ9JD7OAeOq7uNjcLajqOW0istIlpCkrK00H4=.71525541-3ae1-4c10-8b53-335e827f86ce@github.com>

On Wed, 9 Mar 2022 07:01:57 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> you can check both cases, if the scale=1 then use high precision.
>> if the scale > 1 then you can use low precision -> if the scale is equal to 2 then shift by two/four pixels or something like that?
>
>> if the scale > 1 then you can use low precision -> if the scale is equal to 2 then shift by two/four pixels or something like that?
> 
> @mrserb I suppose I could do that, but then it wouldn't be much different from the existing tests that verify color inside a sufficiently large area. I can make this area smaller, but this still won't help to find a rounding error in `gtk3_get_drawable_data()`.

You mentioned uiScale=3 doesn't work correctly. Does it not work with uiScale=2 either?

Is it proven the test can't get the colored pixels precisely with uiScale=2?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From aivanov at openjdk.java.net  Tue Mar 15 18:44:49 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 15 Mar 2022 18:44:49 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v3]
In-Reply-To: <de8SseltKYp0wACfzOkrvVbqq0YzXqju1fPDWpPlBVo=.8ca42205-8b1b-4ede-959e-47f28847b030@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <6pGT5DmJQoDUOkO7uGHHh3DgPrtciQWTerAigWPh4-4=.85547921-1017-438c-9af4-7e3b90c06bb2@github.com>
 <ydXqoU6eOcbICNMi2XpmrL6YSZJHqc25IOEzWmt8KCk=.58e0eafe-f236-4766-8bc6-d9030d2e38d6@github.com>
 <de8SseltKYp0wACfzOkrvVbqq0YzXqju1fPDWpPlBVo=.8ca42205-8b1b-4ede-959e-47f28847b030@github.com>
Message-ID: <vn9hAM9A7QiNWI230CzFOcgt2INg2Z44s5_s0efT-xs=.1373233b-4437-428d-9d84-79c1cf248171@github.com>

On Wed, 9 Mar 2022 15:04:13 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

> > Does it make sense to run all the checks before throwing the exception?
> > I mean run all the checks that the test performs and accumulate failures if any. If the list of failures isn't empty, throw an exception to fail the entire test.
> 
> That might turn out to be useful for debugging a failure, I think.

Yes, it will provide the results for all the points that are verified as well as the screenshot. The screenshot should probably be taken with `createMultiResolutionScreenCapture` especially where the uiScale is above 1. I partially implemented it in my own branch while I was running the tests.

Shall I submit a new issue?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From zgu at openjdk.java.net  Tue Mar 15 19:32:06 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 15 Mar 2022 19:32:06 GMT
Subject: RFR: 8283217: Leak FcObjectSet in getFontConfigLocations() in
 fontpath.c
Message-ID: <1VS7SH0RB3qQDRunQQ8s3xp6CNYpCrHX6u5KlH6LWMU=.8d5ad8cc-f5de-4099-a4d3-f1b90a44e6c5@github.com>

Please review this small patch to fix leaking of `FcObjectSet` in  `getFontConfigLocations()`


Test:
- [x]  jdk_2d

-------------

Commit messages:
 - v0

Changes: https://git.openjdk.java.net/jdk/pull/7826/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7826&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283217
  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7826.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7826/head:pull/7826

PR: https://git.openjdk.java.net/jdk/pull/7826


From ihse at openjdk.java.net  Tue Mar 15 23:50:20 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Mar 2022 23:50:20 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v6]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'master' into shuffle-data-reborn
 - Fix merge
 - Merge tag 'jdk-19+13' into shuffle-data-reborn
   
   Added tag jdk-19+13 for changeset 5df2a057
 - Move characterdata templates to share/classes/java/lang.
 - Update comment refering to "make" dir
 - Move new symbols to jdk.compiler
 - Merge branch 'master' into shuffle-data
 - Move macosxicons from share to macosx
 - Move to share/data, and move jdwp.spec to java.se
 - Update references in test
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f

-------------

Changes: https://git.openjdk.java.net/jdk/pull/1611/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=05
  Stats: 85 lines in 1695 files changed: 4 ins; 1 del; 80 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Tue Mar 15 23:50:22 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Mar 2022 23:50:22 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v5]
In-Reply-To: <VOISxSWArxxc_b4jkanMxAHICUEnv3wmh7yub1so5yg=.f062b37b-e0ef-4362-be5f-f73f170f3438@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <VOISxSWArxxc_b4jkanMxAHICUEnv3wmh7yub1so5yg=.f062b37b-e0ef-4362-be5f-f73f170f3438@github.com>
Message-ID: <ePFQlPZKK1cep2aZwODf_fUMzH_h_PIkUpuE4X4YIYc=.e2e51be7-635a-423b-97d2-41eeaf9ad5e0@github.com>

On Mon, 18 Jan 2021 13:47:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move characterdata templates to share/classes/java/lang.

This PR was almost ready to merge, but unfortunately got closed about a year ago when I disappeared on medical leave. :-( I've been putting off coming back to to this, worried that the merge conflicts would be bad. But no! Git handled the merge fantastically well; the default merge mode even realized that new files in a directory which had been moved elsewhere should probably also be moved to the same place. I was pleasantly surprised how easy this was. 

Nevertheless, I have carefully studied the automatic merge for any signs or mistakes. I only found one: a single renamed file (blacklist -> blocked) that it failed to match.

So I believe this PR is back in the same integrateable state that it was when I left it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Tue Mar 15 23:59:55 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Mar 2022 23:59:55 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v6]
In-Reply-To: <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
Message-ID: <qZZeW4Wwn9Rj_m5O9Cc6BKPn5k-6UHcuS1_1vd4ojPY=.b53ec8c1-cb6e-4b6c-ae9e-276ffcd9fd29@github.com>

On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge branch 'master' into shuffle-data-reborn
>  - Fix merge
>  - Merge tag 'jdk-19+13' into shuffle-data-reborn
>    
>    Added tag jdk-19+13 for changeset 5df2a057
>  - Move characterdata templates to share/classes/java/lang.
>  - Update comment refering to "make" dir
>  - Move new symbols to jdk.compiler
>  - Merge branch 'master' into shuffle-data
>  - Move macosxicons from share to macosx
>  - Move to share/data, and move jdwp.spec to java.se
>  - Update references in test
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f

I have carefully reviewed all PR comments, and the changes I made in response to them. I believe I have resolved all requests from reviewers. What remained to do was to create an informational JEP about the new source structure, and file some follow-up issues.

I have now created and submitted a new informational JEP ("JDK Source Structure"), available at https://bugs.openjdk.java.net/browse/JDK-8283227. When creating this JEP, it felt increasingly silly to just copy and extend the part about src/$MODULE from JEP 201, so I extended it to cover a relevant overview of the entire JDK source base structure. I actually think this JEP has a good merit on its own, notwithstanding it being a reviewer requirement for this PR.

I have also filed follow up issues for the non-standard jdk.hotspot.agent `doc` and `test` directories (https://bugs.openjdk.java.net/browse/JDK-8283197 and https://bugs.openjdk.java.net/browse/JDK-8283198, respectively).

I have filed a follow up issue for continued efforts to clean up charsetmapping, https://bugs.openjdk.java.net/browse/JDK-8283228.

There were two open questions:

 * should jdwp.spec belong to specs directory instead of data
 * should bin/idea.sh be changed to exclude data

but they sounded so exploratory that I decided not to open JBS issues for them.

@wangweij  @naotoj  @prrace  @erikj79 @jonathan-gibbons  You have all approved this PR at an older revision. Can you please reconfirm that your approval stands for the latest revision? (Sorry for the mass ping)

-------------

PR: https://git.openjdk.java.net/jdk/pull/1611


From zgu at openjdk.java.net  Wed Mar 16 01:05:19 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 16 Mar 2022 01:05:19 GMT
Subject: RFR: 8283217: Leak FcObjectSet in getFontConfigLocations() in
 fontpath.c [v2]
In-Reply-To: <1VS7SH0RB3qQDRunQQ8s3xp6CNYpCrHX6u5KlH6LWMU=.8d5ad8cc-f5de-4099-a4d3-f1b90a44e6c5@github.com>
References: <1VS7SH0RB3qQDRunQQ8s3xp6CNYpCrHX6u5KlH6LWMU=.8d5ad8cc-f5de-4099-a4d3-f1b90a44e6c5@github.com>
Message-ID: <YhIvt5k1ZBzVgVSjhZShELHLLR6Y3j_mH40iY6j9aU8=.0b35b045-6d77-4489-aea0-75c67c74dee9@github.com>

> Please review this small patch to fix leaking of `FcObjectSet` in  `getFontConfigLocations()`
> 
> 
> Test:
> - [x]  jdk_2d

Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into JDK-8283217-destroy-FcObjectSet
 - v0

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7826/files
  - new: https://git.openjdk.java.net/jdk/pull/7826/files/6caca241..754e33b5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7826&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7826&range=00-01

  Stats: 587 lines in 28 files changed: 374 ins; 73 del; 140 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7826.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7826/head:pull/7826

PR: https://git.openjdk.java.net/jdk/pull/7826


From duke at openjdk.java.net  Wed Mar 16 01:12:37 2022
From: duke at openjdk.java.net (lukeu)
Date: Wed, 16 Mar 2022 01:12:37 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v3]
In-Reply-To: <HYjNkqqcwMFOo-6mM2Q_4-1B5ePKD3-DRICoaF_1-bA=.53f59ac5-02f8-4c57-924c-40d22a760db1@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <HYjNkqqcwMFOo-6mM2Q_4-1B5ePKD3-DRICoaF_1-bA=.53f59ac5-02f8-4c57-924c-40d22a760db1@github.com>
Message-ID: <3TnxM6EQFTobWcfvS0TkUolT8ezoMZGCePjT-x21OTo=.cee2e10b-6db2-4885-b700-a9bf50fa77ac@github.com>

On Mon, 14 Mar 2022 16:15:47 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added functions for drawing border, fixed translate

OK after many hours of "bash"ing, I've convinced the JDK, cygwin and VS-2017 to play nicely again :-)

My suspicions were close: the lines jump apart, rather than overlap at 125%, and jiggle between 1 & 2px at 175%. The following screenshot is with the patched code at 125% display scaling on Windows, then zoomed in 3x: 

![JDK-8279614-patched-zoom_x3](https://user-images.githubusercontent.com/2722420/158495184-6ee71afb-32f9-42d4-9123-d36c6361f785.png)

Each subsequent titled border is offset 1 extra pixel (as given in the code) to the right, and you can see only the 3rd lets the background between the lines on the left side, at this particular splitter position.  If it might be of use, here's my interactive test harness:


import java.awt.*;
import javax.swing.*;

public class Test {
    public static void main(String[] args) {
        SwingUtilities.invokeLater(new Test()::run);
    }

    private void run() {
        try {
            UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
        } catch (Exception e) {
            e.printStackTrace();
        }
        var frame = new JFrame();
        frame.getContentPane().add(createSplitters());
        frame.setSize(new Dimension(800, 600));
        frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
        frame.setVisible(true);
    }

    private JSplitPane createSplitters() {
        return createSplit(
                JSplitPane.HORIZONTAL_SPLIT,
                new JPanel(),
                createSplit(
                        JSplitPane.VERTICAL_SPLIT,
                        new JPanel(),
                        createTestArea()));
    }

    private JSplitPane createSplit(int dir, JComponent left, JComponent right) {
        var split = new JSplitPane(dir, true, left, right);
        split.setDividerLocation(200);
        return split;
    }

    private Box createTestArea() {
        Box box = Box.createVerticalBox();
        box.add(createBorderedCheckbox(1));
        box.add(createBorderedCheckbox(2));
        box.add(createBorderedCheckbox(3));
        return box;
    }

    private JComponent createBorderedCheckbox(int i) {
        JPanel childPanel = new JPanel(new BorderLayout());
        childPanel.setBorder(BorderFactory.createCompoundBorder(
                BorderFactory.createEmptyBorder(0, i, 0, 0),
                BorderFactory.createTitledBorder("Title " + i)));
        childPanel.add(new JCheckBox(), BorderLayout.CENTER);
        childPanel.setBackground(new Color(190, 190 + 20 * i , 190));
        return childPanel;
    }
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From tnakamura at openjdk.java.net  Wed Mar 16 01:15:49 2022
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Wed, 16 Mar 2022 01:15:49 GMT
Subject: Integrated: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese
 characters were garbled
In-Reply-To: <JM1ajWFlO67nrSxj3JOiLZ1h4l-IVFkZVI1kf4nd3vo=.cae6dc96-15a2-4856-a2b9-352492a41bbb@github.com>
References: <JM1ajWFlO67nrSxj3JOiLZ1h4l-IVFkZVI1kf4nd3vo=.cae6dc96-15a2-4856-a2b9-352492a41bbb@github.com>
Message-ID: <w3Jy-Rvpg26WsSoess9QbnKEnes1RIienaQSSQmzxOQ=.f9c64c25-043c-4854-9693-978f466acc05@github.com>

On Thu, 22 Apr 2021 09:21:20 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

> Hi,
> 
> Could you review the fix?
> When non-English characters were printed from JTable on MacOS, CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However, CTextPipe seems not support glyph with slot number of composite fonts.
> 
> The slot data mask of GlyphVector is 0xff000000. In my environment, Japanese font was loaded at slot 4, and glyph data is like [0x40003e5]. Then, unexpected glyph was drawn.

This pull request has now been integrated.

Changeset: 27fe3d7f
Author:    Toshio Nakamura <tnakamura at openjdk.org>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/27fe3d7f8db4ede6441a7cc325d9f29eb4a1d10d
Stats:     212 lines in 2 files changed: 208 ins; 0 del; 4 mod

8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled

Reviewed-by: prr, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/3619


From serb at openjdk.java.net  Wed Mar 16 01:52:46 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 16 Mar 2022 01:52:46 GMT
Subject: RFR: 8024624: [TEST_BUG] [macosx] CTRL+RIGHT(LEFT) doesn't move
 selection on next cell in JTable on Aqua L&F
In-Reply-To: <7T7g_WIUi3-5wTGIJIUFEUWt4zJoYMM6jnEQFG87n-I=.837d0723-d797-4f43-bf41-d5ab973b685c@github.com>
References: <LdWWDPfwqpCC-_EBaYQLX4rFIyV9FLAG5ugIJb0ruI4=.bc296640-5df9-41a1-b857-14f334c1be8e@github.com>
 <i7w4_YI08R-jGwPNIeZG_4UEo-0yv1noFlu-nwX8L4A=.e57943be-1ed6-4a21-8935-28831c8984cc@github.com>
 <7T7g_WIUi3-5wTGIJIUFEUWt4zJoYMM6jnEQFG87n-I=.837d0723-d797-4f43-bf41-d5ab973b685c@github.com>
Message-ID: <W2fCp90d04ksGYj8Ce5vhPf9v8M0un5I-N9sfyVp77s=.ca53f183-b111-4590-a76b-d016ac1fa45f@github.com>

On Sat, 12 Mar 2022 01:27:34 GMT, DamonGuy <duke at openjdk.java.net> wrote:

> Apple Pages has no support at all for these table navigation functions other than `COMMAND+LEFT_CLICK`. Excel has a selection mode that can be toggled on/off using SHIFT+F8. I also tested in macOS's `System Preferences > Keyboard > Text` and `CMD+CLICK` is the only supported way to select non-adjacent cells as well.

Since for any reason the macOS does not supported such navigation in the tables and use it by mission control it seems correct to do the same in the native look and feel, and ignore the test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7792


From serb at openjdk.java.net  Wed Mar 16 05:39:40 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 16 Mar 2022 05:39:40 GMT
Subject: RFR: 8282526: Default icon is not painted properly
In-Reply-To: <ykpowK0z6aNXzTun2818uIhiF1V-VIF5ZTzmWtaGKDk=.ebb3750e-f8f0-4e81-9358-be6a6618e259@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <rWCyzbxnTraucb96bdEvdDEv7Dx0SdlW0ur1RFoTzMA=.0c697691-3dba-476b-80ac-2a8f0306cf80@github.com>
 <ykpowK0z6aNXzTun2818uIhiF1V-VIF5ZTzmWtaGKDk=.ebb3750e-f8f0-4e81-9358-be6a6618e259@github.com>
Message-ID: <GPzIIvLxz-v5hjtHLPCqEmpMn0dyJybVfPhQbVtMvKM=.517d28de-1197-4f4b-97da-7f7109c6df0d@github.com>

On Mon, 14 Mar 2022 01:47:20 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 463:
>> 
>>> 461:         if (hintChanged) {
>>> 462:             ((Graphics2D) g).setRenderingHint(RenderingHints.KEY_INTERPOLATION,
>>> 463:                     oldHint == null ? RenderingHints.VALUE_INTERPOLATION_NEAREST_NEIGHBOR : oldHint);
>> 
>> This might be a rookie question:
>> 
>> When it comes to modifying and restoring a Graphics, I've seen two common patterns:
>> A. Call `newG = g.create()` and later `newG.dispose()`
>> B. Call `g.setX(newValue)` and then call `g.setX(oldValue)` later
>> 
>> Is there guidance on when to use which? Or is one always preferred?
>
>> This might be a rookie question:
>> 
>> When it comes to modifying and restoring a Graphics, I've seen two common patterns: A. Call `newG = g.create()` and later `newG.dispose()` B. Call `g.setX(newValue)` and then call `g.setX(oldValue)` later
>> 
>> Is there guidance on when to use which? Or is one always preferred?
> 
> Usually i follow the rule of minimal action. When i need to set a lot of hints that needs to be later unrolled such as changing graphics coordinates and such - i'm creating a new Graphics. When i only need to manipulate a single hint and it can easily be unrolled - i am using the same object. In this case i'm changing just a single hint.

I am not sure that this is the right place to change the hints.
If we want to always scale the icon using the bicubic interpolation then it is better to do it where we call the paintIcon() method in some jcomponent(this probably may be configured by some option - similar to the text antialisaing). But it will affect performance since the bicubic is much slower.

But before discussing this shared code change could you please provide some info on why it worked fine before? Why we try to downscale the image and do not get an exact size from the native.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7805


From serb at openjdk.java.net  Wed Mar 16 05:56:40 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 16 Mar 2022 05:56:40 GMT
Subject: RFR: 8282937: Write a regression test for JDK-4820080
In-Reply-To: <4bbhbCGRMxaAZkJPXi3B79QCUehtUtB5OuhmtCEm3Vw=.8a6e03c0-3215-48eb-8a6e-9c57cf01b095@github.com>
References: <4bbhbCGRMxaAZkJPXi3B79QCUehtUtB5OuhmtCEm3Vw=.8a6e03c0-3215-48eb-8a6e-9c57cf01b095@github.com>
Message-ID: <IE__GuhW-YQVw9R3bpUGt_a0SHml1fukWexPP9TqurI=.95946009-871d-4b60-9aa3-569e8076c6b7@github.com>

On Sun, 13 Mar 2022 14:07:22 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Write a regression test for [JDK-4820080](https://bugs.openjdk.java.net/browse/JDK-4820080) : RFE: Cannot Change the JSplitPane Divider Color while dragging
> 
> Issue(as per bug description):
> I want to change the color of the JSplitPane divider. I
> opened the code and found that, the color is hard coded to
> darkGray while one is dragging the splitDivider. I have an
> application where the components on SplitPane have black
> background, So when i drag I can not see the split getting
> dragged. Can some one fix this, by externelising the
> SplitDivider color so that it can be changed at run time.
> 
> Testing:
> Java 1.4.1 -> Test Failed.
> $ ./j2sdk1.4.1/bin/java JSplitPaneDragColorTest
> Metal uses correct drag color false
> CDE/Motif uses correct drag color false
> Windows uses correct drag color false
> Test Failed.
> 
> Java 1.5.0 -> Test Failed.
> $ ./jdk1.5.0/bin/java JSplitPaneDragColorTest
> Metal uses correct drag color true
> Windows uses correct drag color true
> Windows Classic uses correct drag color true
> Test Passed.

test/jdk/javax/swing/JSplitPane/4820080/JSplitPaneDragColorTest.java line 71:

> 69:         robot.setAutoWaitForIdle(true);
> 70:         robot.setAutoDelay(200);
> 71:         // Skipping NimbusLookAndFeel & GTKLookAndFeel as both are not supported for this feature - JDK-8075914

Please split the long lines using 80 chars per line.
Note that JDK-8075914 is closed so it is unclear why this is unsupported by Nimbus/GTK l&f.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7803


From psadhukhan at openjdk.java.net  Wed Mar 16 06:02:28 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 16 Mar 2022 06:02:28 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v4]
In-Reply-To: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
Message-ID: <px566UftzNVHlLSDErQ3n9S7ZPQ_6sqMrDjNy6Z_4_Y=.e8381b27-170d-4eee-a4a2-47681573859f@github.com>

> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  korean fallback added

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7643/files
  - new: https://git.openjdk.java.net/jdk/pull/7643/files/0f74bf39..1b7a5993

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7643&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7643&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7643.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7643/head:pull/7643

PR: https://git.openjdk.java.net/jdk/pull/7643


From psadhukhan at openjdk.java.net  Wed Mar 16 06:02:28 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 16 Mar 2022 06:02:28 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v3]
In-Reply-To: <B7EdIDIhmBuVOTHOth_aWOk_byPfoC5JUJQJ9NXPEtw=.1860e678-8538-4604-9d75-452bba56b9e6@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <FXQsKzb0k2ieq5xQBWDxiIQXSqUsXHwH4Rhyysc71Hc=.6237ac07-228f-4c65-9bd6-b16de717642d@github.com>
 <Yu60xcJmK2GCi1XFs_qN2UnxccOx3GkW2JVt3RE2DZc=.3687c143-14e5-47ed-a1c1-0f9310c5aae7@github.com>
 <6xs4-PbuPxBkxDverzrbM1V63pQpwxUebjo5JpQqcGg=.b7042da0-9acb-4784-a22e-c4877b6f565e@github.com>
 <B7EdIDIhmBuVOTHOth_aWOk_byPfoC5JUJQJ9NXPEtw=.1860e678-8538-4604-9d75-452bba56b9e6@github.com>
Message-ID: <NUB8iyXz5vprl1JAAEDY2XY1nZQIW0a-bGHHkxAQsZw=.2063dd46-4873-4121-8a8d-e1889204e33b@github.com>

On Mon, 14 Mar 2022 18:19:19 GMT, Phil Race <prr at openjdk.org> wrote:

> > It seems then if we have
> > allfonts.korean-fallback=Malgun Gothic
> > and add this korean-fallback to sequence.fallback instead of korean then I guess we can have fix for both.
> > Will this be accepted change?
> 
> It is fine by me. I just want to be hear that you have tested all the scenarios and it works as we want it to.

I have tested with sanserif, serif, monospaced, dialog, dialoginput with PLAIN, BOLD, ITALIC, BOLD-ITALIC style in that order which is rendered correctly
![image](https://user-images.githubusercontent.com/43534309/158526001-8dfb8fb7-ffdd-4ded-8f56-714b0680d998.png)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From serb at openjdk.java.net  Wed Mar 16 06:03:44 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 16 Mar 2022 06:03:44 GMT
Subject: RFR: JDK-8283087: Create a test or JDK-4715503
In-Reply-To: <EKaHEfjou-QbJWzk5d74cD23a62vFExxy0w7BPkxWho=.a3fad8f0-dfb2-46d1-939b-61bf89d03f24@github.com>
References: <EKaHEfjou-QbJWzk5d74cD23a62vFExxy0w7BPkxWho=.a3fad8f0-dfb2-46d1-939b-61bf89d03f24@github.com>
Message-ID: <Dj1NwUBskiHC1VBmjRP_bUIIp0qm90babXqSKfa-Saw=.6f32ec19-ece3-4af1-a7d8-3bf73589319c@github.com>

On Mon, 14 Mar 2022 09:28:50 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Create a test or [JDK-4715503](https://bugs.openjdk.java.net/browse/JDK-4715503)
> 
> The getAccessibleContext method for JTable column header cells returns an
>  AccessibleContext which cannot get the Bounding Rectangle for table header cells. The Bug causes problems with screen reader review mode.
> 
> The test added verifies that the are not exceptions and Bounding rectangles are returned for the Accessible Table Header Cells.
> 
> This review is for migrating tests from a closed test suite to open.

test/jdk/javax/accessibility/4715503/AccessibleJTableCellBoundingRectangleTest.java line 59:

> 57:                     System.out.println("Column " + i + " Bounds: "
> 58:                         + jTable.getTableHeader().getAccessibleContext().getAccessibleChild(i)
> 59:                         .getAccessibleContext().getAccessibleComponent().getBounds());

Can we add quick validation of the returned value? I assume it at least should not be null.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7807


From swingguy1024 at yahoo.com  Wed Mar 16 06:21:53 2022
From: swingguy1024 at yahoo.com (Miguel Munoz)
Date: Wed, 16 Mar 2022 06:21:53 +0000 (UTC)
Subject: RFR: 8024624: [TEST_BUG] [macosx] CTRL+RIGHT(LEFT) doesn't move
 selection on next cell in JTable on Aqua L&F
In-Reply-To: <W2fCp90d04ksGYj8Ce5vhPf9v8M0un5I-N9sfyVp77s=.ca53f183-b111-4590-a76b-d016ac1fa45f@github.com>
References: <LdWWDPfwqpCC-_EBaYQLX4rFIyV9FLAG5ugIJb0ruI4=.bc296640-5df9-41a1-b857-14f334c1be8e@github.com>
 <i7w4_YI08R-jGwPNIeZG_4UEo-0yv1noFlu-nwX8L4A=.e57943be-1ed6-4a21-8935-28831c8984cc@github.com>
 <7T7g_WIUi3-5wTGIJIUFEUWt4zJoYMM6jnEQFG87n-I=.837d0723-d797-4f43-bf41-d5ab973b685c@github.com>
 <W2fCp90d04ksGYj8Ce5vhPf9v8M0un5I-N9sfyVp77s=.ca53f183-b111-4590-a76b-d016ac1fa45f@github.com>
Message-ID: <903806783.104456.1647411713894@mail.yahoo.com>

On the MacOS, it's the OPTION-CLICK event, not the COMMAND-CLICK event that does the same thing as CONTROL-CLICK on Windows and other platforms. Every platform has modifier key used to advance the cursor by words instead of characters, but the modifiers are different on the Mac.

To see this working correctly, try an app running under JDK 8, which was the last one they worked under. (Actually, I haven't tried 9 or 10) Or you can try any non-java application. This is a standard user interface convention, and Java should continue to support it like it did through Java -8.

? Miguel Mu?oz
    On Tuesday, March 15, 2022, 06:53:19 PM PDT, Sergey Bylokhov <serb at openjdk.java.net> wrote:  
 
 On Sat, 12 Mar 2022 01:27:34 GMT, DamonGuy <duke at openjdk.java.net> wrote:

> Apple Pages has no support at all for these table navigation functions other than `COMMAND+LEFT_CLICK`. Excel has a selection mode that can be toggled on/off using SHIFT+F8. I also tested in macOS's `System Preferences > Keyboard > Text` and `CMD+CLICK` is the only supported way to select non-adjacent cells as well.

Since for any reason the macOS does not supported such navigation in the tables and use it by mission control it seems correct to do the same in the native look and feel, and ignore the test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7792
  

From mvs at openjdk.java.net  Wed Mar 16 06:34:48 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 16 Mar 2022 06:34:48 GMT
Subject: RFR: 8282937: Write a regression test for JDK-4820080
In-Reply-To: <IE__GuhW-YQVw9R3bpUGt_a0SHml1fukWexPP9TqurI=.95946009-871d-4b60-9aa3-569e8076c6b7@github.com>
References: <4bbhbCGRMxaAZkJPXi3B79QCUehtUtB5OuhmtCEm3Vw=.8a6e03c0-3215-48eb-8a6e-9c57cf01b095@github.com>
 <IE__GuhW-YQVw9R3bpUGt_a0SHml1fukWexPP9TqurI=.95946009-871d-4b60-9aa3-569e8076c6b7@github.com>
Message-ID: <X4qpStIccIcwRbMBzlrCycH-RP1lDIxEdcRCEDXhVLE=.359eab15-a8f6-4be5-94e3-e8bcc9ee8ecf@github.com>

On Wed, 16 Mar 2022 05:53:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Write a regression test for [JDK-4820080](https://bugs.openjdk.java.net/browse/JDK-4820080) : RFE: Cannot Change the JSplitPane Divider Color while dragging
>> 
>> Issue(as per bug description):
>> I want to change the color of the JSplitPane divider. I
>> opened the code and found that, the color is hard coded to
>> darkGray while one is dragging the splitDivider. I have an
>> application where the components on SplitPane have black
>> background, So when i drag I can not see the split getting
>> dragged. Can some one fix this, by externelising the
>> SplitDivider color so that it can be changed at run time.
>> 
>> Testing:
>> Java 1.4.1 -> Test Failed.
>> $ ./j2sdk1.4.1/bin/java JSplitPaneDragColorTest
>> Metal uses correct drag color false
>> CDE/Motif uses correct drag color false
>> Windows uses correct drag color false
>> Test Failed.
>> 
>> Java 1.5.0 -> Test Failed.
>> $ ./jdk1.5.0/bin/java JSplitPaneDragColorTest
>> Metal uses correct drag color true
>> Windows uses correct drag color true
>> Windows Classic uses correct drag color true
>> Test Passed.
>
> test/jdk/javax/swing/JSplitPane/4820080/JSplitPaneDragColorTest.java line 71:
> 
>> 69:         robot.setAutoWaitForIdle(true);
>> 70:         robot.setAutoDelay(200);
>> 71:         // Skipping NimbusLookAndFeel & GTKLookAndFeel as both are not supported for this feature - JDK-8075914
> 
> Please split the long lines using 80 chars per line.
> Note that JDK-8075914 is closed so it is unclear why this is unsupported by Nimbus/GTK l&f.

I think the closed bug is JDK-8075608, but JDK-8075914 is still open. But anyway JDK-8075608 was closed as 'Won't Fix', so I think the problem remains.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7803


From duke at openjdk.java.net  Wed Mar 16 06:38:38 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Wed, 16 Mar 2022 06:38:38 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v2]
In-Reply-To: <gPMGgZlJ9JD7OAeOq7uNjcLajqOW0istIlpCkrK00H4=.71525541-3ae1-4c10-8b53-335e827f86ce@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <6sowygRcdclz1LCYIHZSWMKV2LhuPo0D_EaYC_JIq0c=.b25c1f95-2510-4372-a8e4-99178d1762ce@github.com>
 <9TbYruwfo7JM4xbW6Mwj_WAAXdbrZR3O62Cc6xgt2TI=.74af7b62-adef-4b98-b195-4f9d47d5098d@github.com>
 <e2kuv7ZIhCBFVsdOaBTQLsvEah30BhTsk721cke6nsc=.a16cdabb-7566-418d-b89e-de43b9573290@github.com>
 <oTP9s3hH1t5pNZz3PA-VvGs07r7KcBory6QosyVesRA=.cf4b7478-116d-4a28-88da-5dd7c91e0bbe@github.com>
 <r1RvzuRuDC0e_agpDZsdu6obb8f5i-Hs5Du5_ghXYJA=.4e59556e-e8e7-4b6e-a569-b636f0f676f7@github.com>
 <gPMGgZlJ9JD7OAeOq7uNjcLajqOW0istIlpCkrK00H4=.71525541-3ae1-4c10-8b53-335e827f86ce@github.com>
Message-ID: <ecokINu0jDB36ZtSJPEJiqc0YlTJwRoo44NZNa8Eyu4=.ccc554b4-5d3f-4fbc-aaa5-e13943216989@github.com>

On Tue, 15 Mar 2022 18:33:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> You mentioned uiScale=3 doesn't work correctly. Does it not work with uiScale=2 either?
> 
> Is it proven the test can't get the colored pixels precisely with uiScale=2?

Yes to both.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From duke at openjdk.java.net  Wed Mar 16 06:54:54 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Wed, 16 Mar 2022 06:54:54 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v3]
In-Reply-To: <YjMqSHlsU6LfGWIXUQvAgXfZ48wyneNTPdyJ6csbFHo=.0916e014-4ce9-4903-888b-5a132a5f52e8@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <6pGT5DmJQoDUOkO7uGHHh3DgPrtciQWTerAigWPh4-4=.85547921-1017-438c-9af4-7e3b90c06bb2@github.com>
 <YjMqSHlsU6LfGWIXUQvAgXfZ48wyneNTPdyJ6csbFHo=.0916e014-4ce9-4903-888b-5a132a5f52e8@github.com>
Message-ID: <2vhBaThUck-mqaxo3XA73SzK93VTw15aut6X5GAzCug=.6772989d-d5c7-45e1-bcdd-860f12387b7a@github.com>

On Tue, 15 Mar 2022 17:38:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The test is run on Linux, so it makes sense to keep Linux in the summary.

True; will rectify that.

> Why do you remove 8280861 from the list of bugs?

While the test technically executes the lines of code changed for 8280861, I cannot imagine a scenario where this test would fail without the 8280861 fix and wouldn't fail with this fix.

> test/jdk/java/awt/Robot/HiDPIScreenCapture/HiDPIRobotScreenCaptureTest.java line 66:
> 
>> 64: 
>> 65:         Frame frame = new Frame();
>> 66:         frame.setBounds(83, 97, 100, 100);
> 
> Does it make sense to preserve the comment? It explain the rationale for using the prime numbers as coordinates. The location remains unchanged, so the comment applies.

Yes, I guess so. Will reinstate the comment.

> test/jdk/java/awt/Robot/HiDPIScreenCapture/ScreenCaptureGtkTest.java line 68:
> 
>> 66:         // by the system because that area's occupied by the global
>> 67:         // menu bar and such.
>> 68:         frame.setBounds(89, 99, 100, 100);
> 
> 99 is not a prime number. Is it intentional?

Now that there's an offset within the frame, the numbers should take that into account: (50+89)==139 and (50+99)==149 and these are prime numbers.

> test/jdk/java/awt/Robot/HiDPIScreenCapture/ScreenCaptureGtkTest.java line 84:
> 
>> 82:                 for (int i = 1; i < 4; i++) {
>> 83:                     g.setColor(COLORS[i]);
>> 84:                     g.fillRect(leftOffset + i, topOffset, 1, 1);
> 
> May I suggest using `COLORS.length` instead of 4 in the for-loops for painting and checking?

Sure. Will fix that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From duke at openjdk.java.net  Wed Mar 16 07:16:40 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Wed, 16 Mar 2022 07:16:40 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v3]
In-Reply-To: <YjMqSHlsU6LfGWIXUQvAgXfZ48wyneNTPdyJ6csbFHo=.0916e014-4ce9-4903-888b-5a132a5f52e8@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <6pGT5DmJQoDUOkO7uGHHh3DgPrtciQWTerAigWPh4-4=.85547921-1017-438c-9af4-7e3b90c06bb2@github.com>
 <YjMqSHlsU6LfGWIXUQvAgXfZ48wyneNTPdyJ6csbFHo=.0916e014-4ce9-4903-888b-5a132a5f52e8@github.com>
Message-ID: <sjzHwggXVfaEMU5Cwg--bwGmXVZ-Cmr_EwxBjSufEiE=.7d6023e3-b315-4d12-8626-6d54dc7cb696@github.com>

On Tue, 15 Mar 2022 18:20:48 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   HiDPIRobotScreenCaptureTest.java: smaller frame size such that it fits on a 1200x600 screen.
>>   
>>   ScreenCaptureGtkTest.java: smaller frame size; added code to save
>>   the image on failure.
>
> test/jdk/java/awt/Robot/HiDPIScreenCapture/HiDPIRobotScreenCaptureTest.java line 111:
> 
>> 109:         checkRectColor(image, 3 * w / 4, h / 4, COLORS[1]);
>> 110:         checkRectColor(image, w / 4, 3 * h / 4, COLORS[2]);
>> 111:         checkRectColor(image, 3 * w / 4, 3 * h / 4, COLORS[3]);
> 
> As my testing showed, this test was stable enough with the changes introduced by [JDK-8282270](https://bugs.openjdk.java.net/browse/JDK-8282270), #7425, with the reduced size of the frame.

I can revert the changes for this one test, but will do that in a separate commit so it's easier to revert in case there are troubles.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From duke at openjdk.java.net  Wed Mar 16 07:32:16 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Wed, 16 Mar 2022 07:32:16 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v4]
In-Reply-To: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
Message-ID: <75aFxVdg8f3KCz4W5HJ2ryIWiJXQOVvbgZ1DIycwrAY=.3333cdcf-6ea5-4d6d-bd4f-353254d24c99@github.com>

> The two tests `ScreenCaptureGtkTest.java` and `HiDPIRobotScreenCaptureTest.java` under `java/awt/Robot/HiDPIScreenCapture` started to intermittently fail under Windows and Linux after the [recent changes](https://github.com/openjdk/jdk/commit/cc7cf81256ed4d74493472017b1c4df20fa2208a) made exclusively for the Linux `Robot` implementation.
> 
> `HiDPIRobotScreenCaptureTest.java`
> Since the Windows failures cannot possibly have their origin in the fix made - the latter being Linux-only - the test apparently either exposes an existing bug in the Windows `Robot` or is bumping against a peculiarity of that platform. The test is reverted back to its original form that didn't fail.
> 
> `ScreenCaptureGtkTest.java`
> The coordinates in the log `(83, 78)` of a failure are higher up than the test suggests `(83, 97)`. I've seen similar failures on Ubuntu 20.04 when the coordinates were set to `(0, 0)`. The color then picked matched the color of the bar drawn at the top of the screen. I believe it's best to place the test pixels towards the center of the window to avoid desktop elements interference.
> 
> The other possible reason for intermittent failures are window coordinates. Suppose that the test is executing with `sun.java2d.uiScale` set to 2. This effectively means that it can only pick colors of pixels at even coordinates (in the absolute desktop space). So if the window is placed at, say, `(201, 201)`, `Robot` can only pick the color at either `(200, 200)` or `(202, 202)`. Since the test only makes sense if it is pixel-accurate, I removed all `@run`s with `sun.java2d.uiScale` other than 1. This way window placement will not cause a failure.
> 
> This was tested on Ubuntu 20.04 and 18.04 with desktop scaling set to 100%, 200%, and 300%.

Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:

  Addressed some of the review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7613/files
  - new: https://git.openjdk.java.net/jdk/pull/7613/files/351626cf..e58cc949

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7613&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7613&range=02-03

  Stats: 12 lines in 2 files changed: 8 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7613.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7613/head:pull/7613

PR: https://git.openjdk.java.net/jdk/pull/7613


From psadhukhan at openjdk.java.net  Wed Mar 16 07:36:37 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 16 Mar 2022 07:36:37 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v3]
In-Reply-To: <AUeNFfcZNdDhRKJExOY7lT7_eG07ZQ_E124iHS_oiVI=.af2824b3-dc46-4318-92c3-27a861269339@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>
 <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>
 <oAZ5tpWpksvN6sfEYoblyucXf_EqcxKAIiVvkvIugjU=.a10e37ec-b8e8-4ac3-9faf-f2a8d85189af@github.com>
 <r9ujiKOC7dRsKCLNjUEt-V8mCstzXKJLFPRQ1O6kqKs=.2b96988b-85c6-45d5-9d95-2e0112b458fb@github.com>
 <AUeNFfcZNdDhRKJExOY7lT7_eG07ZQ_E124iHS_oiVI=.af2824b3-dc46-4318-92c3-27a861269339@github.com>
Message-ID: <0U4ZvK_ui_ieG7pPZAdhL1AyrJYQNqT0A_HRJIE8InQ=.26f7a810-a6a0-47d0-99d9-e2ffcfebe596@github.com>

On Mon, 14 Mar 2022 22:27:37 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> @prsadhuk Thank you for reviewing. 
>> 
>> Earlier when I used the default thickness (thickness=1) the cell focus ring was visible but not prominent as shown in the following screenshot. Please let me know if I need to change thickness to 1 or keep it the same?
>> 
>> **Thickness=1**
>> 
>> ![image](https://user-images.githubusercontent.com/95945681/158270171-8260c71f-511f-481e-b88e-f226818a8219.png)
>> 
>> The thickness looks the same on retina as well as non-retina display. I have included the screenshots for comparison-
>> 
>> ![image](https://user-images.githubusercontent.com/95945681/158270568-b3018b09-8227-4bf0-9751-80d30df4e411.png)
>
> Since List.focusCellHighlightBorder uses the same focusRingColor as used by Table we can change it for List as well. Can I make changes to List using this issue and PR or should I track it by adding a new JBS bug/PR ?

Just thinking,  Do we need to manipulate hue and saturation for focus ring?
It seems from native "Numbers" app which is closest to Tables & cells, I see the focus ring is always blue irrespective of what the selection background (and system accent color) is
and since Aqua should mimic native look, so I guess just this change will probably do
 ```
- Table.focusCellHighlightBorder", focusCellHighlightBorder,
 + Table.focusCellHighlightBorder", new BorderUIResouce.LineBorderUIResouce(Color.blue), 2),

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From duke at openjdk.java.net  Wed Mar 16 07:41:32 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Wed, 16 Mar 2022 07:41:32 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v5]
In-Reply-To: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
Message-ID: <F6o4zlCFWhp6lwZS3avKExKm94xu6chWTlfLZy1Ur0U=.ef89e65a-4b8d-458c-b36a-3e3236fdb950@github.com>

> The two tests `ScreenCaptureGtkTest.java` and `HiDPIRobotScreenCaptureTest.java` under `java/awt/Robot/HiDPIScreenCapture` started to intermittently fail under Windows and Linux after the [recent changes](https://github.com/openjdk/jdk/commit/cc7cf81256ed4d74493472017b1c4df20fa2208a) made exclusively for the Linux `Robot` implementation.
> 
> `HiDPIRobotScreenCaptureTest.java`
> Since the Windows failures cannot possibly have their origin in the fix made - the latter being Linux-only - the test apparently either exposes an existing bug in the Windows `Robot` or is bumping against a peculiarity of that platform. The test is reverted back to its original form that didn't fail.
> 
> `ScreenCaptureGtkTest.java`
> The coordinates in the log `(83, 78)` of a failure are higher up than the test suggests `(83, 97)`. I've seen similar failures on Ubuntu 20.04 when the coordinates were set to `(0, 0)`. The color then picked matched the color of the bar drawn at the top of the screen. I believe it's best to place the test pixels towards the center of the window to avoid desktop elements interference.
> 
> The other possible reason for intermittent failures are window coordinates. Suppose that the test is executing with `sun.java2d.uiScale` set to 2. This effectively means that it can only pick colors of pixels at even coordinates (in the absolute desktop space). So if the window is placed at, say, `(201, 201)`, `Robot` can only pick the color at either `(200, 200)` or `(202, 202)`. Since the test only makes sense if it is pixel-accurate, I removed all `@run`s with `sun.java2d.uiScale` other than 1. This way window placement will not cause a failure.
> 
> This was tested on Ubuntu 20.04 and 18.04 with desktop scaling set to 100%, 200%, and 300%.

Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:

  Reverted HiDPIRobotScreenCaptureTest back to 8280861 with minor changes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7613/files
  - new: https://git.openjdk.java.net/jdk/pull/7613/files/e58cc949..f76fc4ee

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7613&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7613&range=03-04

  Stats: 42 lines in 1 file changed: 18 ins; 4 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7613.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7613/head:pull/7613

PR: https://git.openjdk.java.net/jdk/pull/7613


From duke at openjdk.java.net  Wed Mar 16 07:46:05 2022
From: duke at openjdk.java.net (Dmitry Kulikov)
Date: Wed, 16 Mar 2022 07:46:05 GMT
Subject: RFR: 8282863:
 java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on
 Windows 10 with HiDPI screen
Message-ID: <SogRHLx2pQzRLxpE6FW6BAjwW0qaawCm-A6Ff4Z3N54=.233a4715-0ec7-491a-ba75-c7c3f16b9ee8@github.com>

Hello,
Please review this fix for JDK-8282863.

The failing `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test basically checks that full-screen window remains full-screen when a display mode change occurs. It has been introduced in JDK-8211999, which also contains numerous fixes for HiDPI displays. In particular, JDK-8211999 changed the code of `Win32GraphicsDevice.setDisplayMode()` so that it uses screen dimensions in user space instead of device space, which is correct. However, if the display mode change incurs display scaling change, as it has been observed on Windows 10 laptop with HiDPI screen, the method used for obtaining screen bounds in user space returns incorrect values under certain conditions.

The issue is reproducible on Windows 10, when resolution of the primary screen is higher than 1024x768 with scaling greater than 100%. Resolution and scaling of secondary screen(s) is irrelevant. I used a laptop with 2160x1350 display resolution and scaling set to 150%. When the `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test is run with these initial conditions, roughly the following happens:

1. `java.awt.Frame` is created and set as full-screen.
2. `Win32GraphicsDevice.setDisplayMode()` is called to change screen resolution from 2160x1350 to 1024x768.
3. `Win32GraphicsDevice.configDisplayMode()` call immediately changes the display resolution to 1024x768, which also incurs the immediate display scaling change from 150% to 100%.
4. Inside the `Win32GraphicsDevice.setDisplayMode()` screen bounds in user space are obtained via `Win32GraphicsConfig.getBounds()`:
5. In the native code of `Win32GraphicsConfig.getBounds()` new screen bounds in device space (1024x768) are correctly obtained via `MonitorBounds()`.
6. Then screen bounds are converted to user space by applying **scaling factors, which are not yet updated and correspond to previous display mode**. In our case, 1024x768 is scaled down by 150% and becomes 683x512.
7. Back in `Win32GraphicsDevice.setDisplayMode()` full-screen window bounds are set to incorrectly scaled 683x512 instead of 1024x768.
8. After returning from `Win32GraphicsDevice.setDisplayMode()` the test waits 4 seconds.
9. `WM_DISPLAYCHANGE` message is received and processed, followed by `WM_DPICHANGED`, which updates the scaling factors used by `Win32GraphicsConfig.getBounds()` to the correct value of 100%.
10. After 4 seconds test wakes up and obtains screen bounds in user space by calling `Win32GraphicsConfig.getBounds()`, which now correctly returns 1024x768.
11. Test compares full-screen window bounds with screen bounds, and fails with `java.lang.RuntimeException: width is wrong` as 683 is not equal to 1024 ? 30 pixels.

Proposed fix adds a `Win32GraphicsDevice.initScaleFactors()` call to `Win32GraphicsDevice.setDisplayMode()` code, between calling `Win32GraphicsDevice.configDisplayMode()` and `Win32GraphicsConfig.getBounds()`. This updates the scaling factors without waiting for `WM_DISPLAYCHANGE` or `WM_DPICHANGED`, `Win32GraphicsConfig.getBounds()` returns correctly scaled screen bounds in user space, and full-screen window remains correctly sized after display mode change.

I've run tests from `jdk_awt` group, and applying the fix did not introduce any new test failures.

-------------

Commit messages:
 - 8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen

Changes: https://git.openjdk.java.net/jdk/pull/7835/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7835&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282863
  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7835.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7835/head:pull/7835

PR: https://git.openjdk.java.net/jdk/pull/7835


From psadhukhan at openjdk.java.net  Wed Mar 16 07:46:35 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 16 Mar 2022 07:46:35 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v3]
In-Reply-To: <0U4ZvK_ui_ieG7pPZAdhL1AyrJYQNqT0A_HRJIE8InQ=.26f7a810-a6a0-47d0-99d9-e2ffcfebe596@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>
 <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>
 <oAZ5tpWpksvN6sfEYoblyucXf_EqcxKAIiVvkvIugjU=.a10e37ec-b8e8-4ac3-9faf-f2a8d85189af@github.com>
 <r9ujiKOC7dRsKCLNjUEt-V8mCstzXKJLFPRQ1O6kqKs=.2b96988b-85c6-45d5-9d95-2e0112b458fb@github.com>
 <AUeNFfcZNdDhRKJExOY7lT7_eG07ZQ_E124iHS_oiVI=.af2824b3-dc46-4318-92c3-27a861269339@github.com>
 <0U4ZvK_ui_ieG7pPZAdhL1AyrJYQNqT0A_HRJIE8InQ=.26f7a810-a6a0-47d0-99d9-e2ffcfebe596@github.com>
Message-ID: <ML4CSxlvMzInAbk9K0LicDa--V4QlgiUzzL1u7XkJ0s=.d8c7a73c-402a-4813-8fc6-faf9fd07745a@github.com>

On Wed, 16 Mar 2022 06:05:13 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Since List.focusCellHighlightBorder uses the same focusRingColor as used by Table we can change it for List as well. Can I make changes to List using this issue and PR or should I track it by adding a new JBS bug/PR ?
>
> Just thinking,  Do we need to manipulate hue and saturation for focus ring?
> It seems from native "Numbers" app which is closest to Tables & cells, I see the focus ring is always blue irrespective of what the selection background (and system accent color) is
> and since Aqua should mimic native look, so I guess just this change will probably do
>  ```
> - Table.focusCellHighlightBorder", focusCellHighlightBorder,
>  + Table.focusCellHighlightBorder", new BorderUIResouce.LineBorderUIResouce(Color.blue), 2),

<img width="1273" alt="Screenshot 2022-03-16 at 1 04 56 PM" src="https://user-images.githubusercontent.com/43534309/158540377-e97cc3c7-64e9-487d-948d-bc1941d5af28.png">

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From psadhukhan at openjdk.java.net  Wed Mar 16 07:46:35 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 16 Mar 2022 07:46:35 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v3]
In-Reply-To: <ML4CSxlvMzInAbk9K0LicDa--V4QlgiUzzL1u7XkJ0s=.d8c7a73c-402a-4813-8fc6-faf9fd07745a@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>
 <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>
 <oAZ5tpWpksvN6sfEYoblyucXf_EqcxKAIiVvkvIugjU=.a10e37ec-b8e8-4ac3-9faf-f2a8d85189af@github.com>
 <r9ujiKOC7dRsKCLNjUEt-V8mCstzXKJLFPRQ1O6kqKs=.2b96988b-85c6-45d5-9d95-2e0112b458fb@github.com>
 <AUeNFfcZNdDhRKJExOY7lT7_eG07ZQ_E124iHS_oiVI=.af2824b3-dc46-4318-92c3-27a861269339@github.com>
 <0U4ZvK_ui_ieG7pPZAdhL1AyrJYQNqT0A_HRJIE8InQ=.26f7a810-a6a0-47d0-99d9-e2ffcfebe596@github.com>
 <ML4CSxlvMzInAbk9K0LicDa--V4QlgiUzzL1u7XkJ0s=.d8c7a73c-402a-4813-8fc6-faf9fd07745a@github.com>
Message-ID: <9-KCaxc5kvdWS_6nETGIRiJgbTEWTWEPxmKT5JHSphw=.0bf35082-2b55-4cfd-bc7a-636a6d7a721a@github.com>

On Wed, 16 Mar 2022 07:42:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Just thinking,  Do we need to manipulate hue and saturation for focus ring?
>> It seems from native "Numbers" app which is closest to Tables & cells, I see the focus ring is always blue irrespective of what the selection background (and system accent color) is
>> and since Aqua should mimic native look, so I guess just this change will probably do
>>  ```
>> - Table.focusCellHighlightBorder", focusCellHighlightBorder,
>>  + Table.focusCellHighlightBorder", new BorderUIResouce.LineBorderUIResouce(Color.blue), 2),
>
> <img width="1273" alt="Screenshot 2022-03-16 at 1 04 56 PM" src="https://user-images.githubusercontent.com/43534309/158540377-e97cc3c7-64e9-487d-948d-bc1941d5af28.png">

Probably to get an identical focus ring, we need to use
[NSSetFocusRingStyle](https://developer.apple.com/documentation/appkit/1473702-nssetfocusringstyle?language=objc)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From smandalika at openjdk.java.net  Wed Mar 16 08:21:26 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 16 Mar 2022 08:21:26 GMT
Subject: RFR: JDK-8283087: Create a test or JDK-4715503 [v2]
In-Reply-To: <EKaHEfjou-QbJWzk5d74cD23a62vFExxy0w7BPkxWho=.a3fad8f0-dfb2-46d1-939b-61bf89d03f24@github.com>
References: <EKaHEfjou-QbJWzk5d74cD23a62vFExxy0w7BPkxWho=.a3fad8f0-dfb2-46d1-939b-61bf89d03f24@github.com>
Message-ID: <--CGwuv4hE9W-Dd1coeg3-wFQpHK4TSv0KW8cnr6tlY=.1cc4e819-6bd3-4c23-bff6-15f4f4bcd4bf@github.com>

> Create a test or [JDK-4715503](https://bugs.openjdk.java.net/browse/JDK-4715503)
> 
> The getAccessibleContext method for JTable column header cells returns an
>  AccessibleContext which cannot get the Bounding Rectangle for table header cells. The Bug causes problems with screen reader review mode.
> 
> The test added verifies that the are not exceptions and Bounding rectangles are returned for the Accessible Table Header Cells.
> 
> This review is for migrating tests from a closed test suite to open.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed: null check added for Bounding Rectangles Returned.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7807/files
  - new: https://git.openjdk.java.net/jdk/pull/7807/files/e8c21db0..2976ae1d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7807&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7807&range=00-01

  Stats: 11 lines in 1 file changed: 8 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7807.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7807/head:pull/7807

PR: https://git.openjdk.java.net/jdk/pull/7807


From smandalika at openjdk.java.net  Wed Mar 16 08:21:28 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 16 Mar 2022 08:21:28 GMT
Subject: RFR: JDK-8283087: Create a test or JDK-4715503 [v2]
In-Reply-To: <Dj1NwUBskiHC1VBmjRP_bUIIp0qm90babXqSKfa-Saw=.6f32ec19-ece3-4af1-a7d8-3bf73589319c@github.com>
References: <EKaHEfjou-QbJWzk5d74cD23a62vFExxy0w7BPkxWho=.a3fad8f0-dfb2-46d1-939b-61bf89d03f24@github.com>
 <Dj1NwUBskiHC1VBmjRP_bUIIp0qm90babXqSKfa-Saw=.6f32ec19-ece3-4af1-a7d8-3bf73589319c@github.com>
Message-ID: <RvIu6HQeh_BEPOalRM-djW-naEsuR9_WLx2dvcphT_k=.367193a2-1eeb-4dac-af8c-d40c05ad70de@github.com>

On Wed, 16 Mar 2022 06:00:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments fixed: null check added for Bounding Rectangles Returned.
>
> test/jdk/javax/accessibility/4715503/AccessibleJTableCellBoundingRectangleTest.java line 59:
> 
>> 57:                     System.out.println("Column " + i + " Bounds: "
>> 58:                         + jTable.getTableHeader().getAccessibleContext().getAccessibleChild(i)
>> 59:                         .getAccessibleContext().getAccessibleComponent().getBounds());
> 
> Can we add quick validation of the returned value? I assume it at least should not be null.

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7807


From magnus.ihse.bursie at oracle.com  Wed Mar 16 08:44:51 2022
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 16 Mar 2022 09:44:51 +0100
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v6]
In-Reply-To: <4dd8052d-b376-ef82-0dfd-ccaf0297a27c@oracle.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
 <qZZeW4Wwn9Rj_m5O9Cc6BKPn5k-6UHcuS1_1vd4ojPY=.b53ec8c1-cb6e-4b6c-ae9e-276ffcd9fd29@github.com>
 <4dd8052d-b376-ef82-0dfd-ccaf0297a27c@oracle.com>
Message-ID: <47cf38cc-2a72-0e2e-f626-707dd8cd4434@oracle.com>

On 2022-03-16 07:31, Alan Bateman wrote:
> Magnus,
>
> This proposal does not address the previous concerns. As before, you 
> are proposing to put the data files used to generate the classes for 
> jdk.localedata and jdk.charsets into src/java.base and I don't think 
> we should do that. I really think this PR needs to be withdraw n or 
> closed until there is at least some agreement on placement. I know you 
> want to get the files moved out of the make tree but there are many 
> issues to work through before that can happen.

I'm sorry that you feel I did not properly address your concerns. You wrote:

"If you are moving them into the src tree then src/java.base (as you 
have it) is best but will still have the ugly wart that some of these 
mapping tables will be used to generate code for the jdk.charsets module."

which I interpreted as a need to file a follow-up issue to sort that 
out, not a veto on the entire PR.

If you have such strong opinions on the data files shared between 
java.base and jdk.charsets/jdk.localedata, I propose we leave them in 
make/data for the time being, clean up the associated mess, and then 
work out where they actually should be. Does that sound okay to you?

/Magnus
>
> -Alan
>
> On 15/03/2022 23:59, Magnus Ihse Bursie wrote:
>> On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie 
>> <ihse at openjdk.org> wrote:
>>
>>>> A lot (but not all) of the data in make/data is tied to a specific 
>>>> module. For instance, the publicsuffixlist is used by java.base, 
>>>> and fontconfig by java.desktop. (A few directories, like 
>>>> mainmanifest, is *actually* used by make for the whole build.)
>>>>
>>>> These data files should move to the module they belong to. The are, 
>>>> after all, "source code" for that module that is "compiler" into 
>>>> resulting deliverables, for that module. (But the "source code" 
>>>> language is not Java or C, but typically a highly domain specific 
>>>> language or data format, and the "compilation" is, often, a 
>>>> specialized transformation.)
>>>>
>>>> This misplacement of the data directory is most visible at code 
>>>> review time. When such data is changed, most of the time build-dev 
>>>> (or the new build label) is involved, even though this has nothing 
>>>> to do with the build. While this is annoying, a worse problem is if 
>>>> the actual team that needs to review the patch (i.e., the team 
>>>> owning the module) is missed in the review.
>>>>
>>>> ### Modules reviewed
>>>>
>>>> - [x] java.base
>>>> - [x] java.desktop
>>>> - [x] jdk.compiler
>>>> - [x] java.se
>>> Magnus Ihse Bursie has updated the pull request with a new target 
>>> base due to a merge or a rebase. The pull request now contains 12 
>>> commits:
>>>
>>> ? - Merge branch 'master' into shuffle-data-reborn
>>> ? - Fix merge
>>> ? - Merge tag 'jdk-19+13' into shuffle-data-reborn
>>> ??? ??? Added tag jdk-19+13 for changeset 5df2a057
>>> ? - Move characterdata templates to share/classes/java/lang.
>>> ? - Update comment refering to "make" dir
>>> ? - Move new symbols to jdk.compiler
>>> ? - Merge branch 'master' into shuffle-data
>>> ? - Move macosxicons from share to macosx
>>> ? - Move to share/data, and move jdwp.spec to java.se
>>> ? - Update references in test
>>> ? - ... and 2 more: 
>>> https://git.openjdk.java.net/jdk/compare/83d77186...598f740f
>> I have carefully reviewed all PR comments, and the changes I made in 
>> response to them. I believe I have resolved all requests from 
>> reviewers. What remained to do was to create an informational JEP 
>> about the new source structure, and file some follow-up issues.
>>
>> I have now created and submitted a new informational JEP ("JDK Source 
>> Structure"), available at 
>> https://bugs.openjdk.java.net/browse/JDK-8283227. When creating this 
>> JEP, it felt increasingly silly to just copy and extend the part 
>> about src/$MODULE from JEP 201, so I extended it to cover a relevant 
>> overview of the entire JDK source base structure. I actually think 
>> this JEP has a good merit on its own, notwithstanding it being a 
>> reviewer requirement for this PR.
>>
>> I have also filed follow up issues for the non-standard 
>> jdk.hotspot.agent `doc` and `test` directories 
>> (https://bugs.openjdk.java.net/browse/JDK-8283197 and 
>> https://bugs.openjdk.java.net/browse/JDK-8283198, respectively).
>>
>> I have filed a follow up issue for continued efforts to clean up 
>> charsetmapping, https://bugs.openjdk.java.net/browse/JDK-8283228.
>>
>> There were two open questions:
>>
>> ? * should jdwp.spec belong to specs directory instead of data
>> ? * should bin/idea.sh be changed to exclude data
>>
>> but they sounded so exploratory that I decided not to open JBS issues 
>> for them.
>>
>> @wangweij? @naotoj? @prrace? @erikj79 @jonathan-gibbons? You have all 
>> approved this PR at an older revision. Can you please reconfirm that 
>> your approval stands for the latest revision? (Sorry for the mass ping)
>>
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/1611
>



From mvs at openjdk.java.net  Wed Mar 16 10:12:16 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 16 Mar 2022 10:12:16 GMT
Subject: RFR: 8282937: Write a regression test for JDK-4820080 [v2]
In-Reply-To: <4bbhbCGRMxaAZkJPXi3B79QCUehtUtB5OuhmtCEm3Vw=.8a6e03c0-3215-48eb-8a6e-9c57cf01b095@github.com>
References: <4bbhbCGRMxaAZkJPXi3B79QCUehtUtB5OuhmtCEm3Vw=.8a6e03c0-3215-48eb-8a6e-9c57cf01b095@github.com>
Message-ID: <cmTAZPAtha668RNpdvSbgv3xE7r0zCsbtkmZ8ygE3Zo=.b334607d-5699-4257-9aeb-13fdb3c643ff@github.com>

> Write a regression test for [JDK-4820080](https://bugs.openjdk.java.net/browse/JDK-4820080) : RFE: Cannot Change the JSplitPane Divider Color while dragging
> 
> Issue(as per bug description):
> I want to change the color of the JSplitPane divider. I
> opened the code and found that, the color is hard coded to
> darkGray while one is dragging the splitDivider. I have an
> application where the components on SplitPane have black
> background, So when i drag I can not see the split getting
> dragged. Can some one fix this, by externelising the
> SplitDivider color so that it can be changed at run time.
> 
> Testing:
> Java 1.4.1 -> Test Failed.
> $ ./j2sdk1.4.1/bin/java JSplitPaneDragColorTest
> Metal uses correct drag color false
> CDE/Motif uses correct drag color false
> Windows uses correct drag color false
> Test Failed.
> 
> Java 1.5.0 -> Test Failed.
> $ ./jdk1.5.0/bin/java JSplitPaneDragColorTest
> Metal uses correct drag color true
> Windows uses correct drag color true
> Windows Classic uses correct drag color true
> Test Passed.

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed: Formatting changes, split long lines

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7803/files
  - new: https://git.openjdk.java.net/jdk/pull/7803/files/b1c14ff7..afb0a2b0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7803&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7803&range=00-01

  Stats: 26 lines in 1 file changed: 11 ins; 0 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7803.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7803/head:pull/7803

PR: https://git.openjdk.java.net/jdk/pull/7803


From mvs at openjdk.java.net  Wed Mar 16 10:12:18 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 16 Mar 2022 10:12:18 GMT
Subject: RFR: 8282937: Write a regression test for JDK-4820080 [v2]
In-Reply-To: <X4qpStIccIcwRbMBzlrCycH-RP1lDIxEdcRCEDXhVLE=.359eab15-a8f6-4be5-94e3-e8bcc9ee8ecf@github.com>
References: <4bbhbCGRMxaAZkJPXi3B79QCUehtUtB5OuhmtCEm3Vw=.8a6e03c0-3215-48eb-8a6e-9c57cf01b095@github.com>
 <IE__GuhW-YQVw9R3bpUGt_a0SHml1fukWexPP9TqurI=.95946009-871d-4b60-9aa3-569e8076c6b7@github.com>
 <X4qpStIccIcwRbMBzlrCycH-RP1lDIxEdcRCEDXhVLE=.359eab15-a8f6-4be5-94e3-e8bcc9ee8ecf@github.com>
Message-ID: <lo_N26_CcsAVcnciiwMVPfWTVlwJxmi5R6LN5jSYPOk=.75da3d0f-2882-438a-948a-dcf2b69f73f8@github.com>

On Wed, 16 Mar 2022 06:31:52 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> test/jdk/javax/swing/JSplitPane/4820080/JSplitPaneDragColorTest.java line 71:
>> 
>>> 69:         robot.setAutoWaitForIdle(true);
>>> 70:         robot.setAutoDelay(200);
>>> 71:         // Skipping NimbusLookAndFeel & GTKLookAndFeel as both are not supported for this feature - JDK-8075914
>> 
>> Please split the long lines using 80 chars per line.
>> Note that JDK-8075914 is closed so it is unclear why this is unsupported by Nimbus/GTK l&f.
>
> I think the closed bug is JDK-8075608, but JDK-8075914 is still open. But anyway JDK-8075608 was closed as 'Won't Fix', so I think the problem remains.

Fixed the long lines issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7803


From aivanov at openjdk.java.net  Wed Mar 16 13:11:47 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 16 Mar 2022 13:11:47 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v5]
In-Reply-To: <F6o4zlCFWhp6lwZS3avKExKm94xu6chWTlfLZy1Ur0U=.ef89e65a-4b8d-458c-b36a-3e3236fdb950@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <F6o4zlCFWhp6lwZS3avKExKm94xu6chWTlfLZy1Ur0U=.ef89e65a-4b8d-458c-b36a-3e3236fdb950@github.com>
Message-ID: <4Qe1Mw3eKO0aYaELI89BTVPc0uEWftPY5R39HbeOmHk=.e26e9115-8b23-472b-a95c-d7e63e1e71ff@github.com>

On Wed, 16 Mar 2022 07:41:32 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> The two tests `ScreenCaptureGtkTest.java` and `HiDPIRobotScreenCaptureTest.java` under `java/awt/Robot/HiDPIScreenCapture` started to intermittently fail under Windows and Linux after the [recent changes](https://github.com/openjdk/jdk/commit/cc7cf81256ed4d74493472017b1c4df20fa2208a) made exclusively for the Linux `Robot` implementation.
>> 
>> `HiDPIRobotScreenCaptureTest.java`
>> Since the Windows failures cannot possibly have their origin in the fix made - the latter being Linux-only - the test apparently either exposes an existing bug in the Windows `Robot` or is bumping against a peculiarity of that platform. The test is reverted back to its original form that didn't fail.
>> 
>> `ScreenCaptureGtkTest.java`
>> The coordinates in the log `(83, 78)` of a failure are higher up than the test suggests `(83, 97)`. I've seen similar failures on Ubuntu 20.04 when the coordinates were set to `(0, 0)`. The color then picked matched the color of the bar drawn at the top of the screen. I believe it's best to place the test pixels towards the center of the window to avoid desktop elements interference.
>> 
>> The other possible reason for intermittent failures are window coordinates. Suppose that the test is executing with `sun.java2d.uiScale` set to 2. This effectively means that it can only pick colors of pixels at even coordinates (in the absolute desktop space). So if the window is placed at, say, `(201, 201)`, `Robot` can only pick the color at either `(200, 200)` or `(202, 202)`. Since the test only makes sense if it is pixel-accurate, I removed all `@run`s with `sun.java2d.uiScale` other than 1. This way window placement will not cause a failure.
>> 
>> This was tested on Ubuntu 20.04 and 18.04 with desktop scaling set to 100%, 200%, and 300%.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverted HiDPIRobotScreenCaptureTest back to 8280861 with minor changes

Test results are green.
(I hope I didn't mess anything up.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From aivanov at openjdk.java.net  Wed Mar 16 13:27:39 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 16 Mar 2022 13:27:39 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v5]
In-Reply-To: <F6o4zlCFWhp6lwZS3avKExKm94xu6chWTlfLZy1Ur0U=.ef89e65a-4b8d-458c-b36a-3e3236fdb950@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <F6o4zlCFWhp6lwZS3avKExKm94xu6chWTlfLZy1Ur0U=.ef89e65a-4b8d-458c-b36a-3e3236fdb950@github.com>
Message-ID: <2u5A1_ytkmz362TAutMwgUI2U6gvDoWYeDIbgqIeSjY=.93c9ef50-b7ad-4461-bd84-7e9090818b30@github.com>

On Wed, 16 Mar 2022 07:41:32 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> The two tests `ScreenCaptureGtkTest.java` and `HiDPIRobotScreenCaptureTest.java` under `java/awt/Robot/HiDPIScreenCapture` started to intermittently fail under Windows and Linux after the [recent changes](https://github.com/openjdk/jdk/commit/cc7cf81256ed4d74493472017b1c4df20fa2208a) made exclusively for the Linux `Robot` implementation.
>> 
>> `HiDPIRobotScreenCaptureTest.java`
>> Since the Windows failures cannot possibly have their origin in the fix made - the latter being Linux-only - the test apparently either exposes an existing bug in the Windows `Robot` or is bumping against a peculiarity of that platform. The test is reverted back to its original form that didn't fail.
>> 
>> `ScreenCaptureGtkTest.java`
>> The coordinates in the log `(83, 78)` of a failure are higher up than the test suggests `(83, 97)`. I've seen similar failures on Ubuntu 20.04 when the coordinates were set to `(0, 0)`. The color then picked matched the color of the bar drawn at the top of the screen. I believe it's best to place the test pixels towards the center of the window to avoid desktop elements interference.
>> 
>> The other possible reason for intermittent failures are window coordinates. Suppose that the test is executing with `sun.java2d.uiScale` set to 2. This effectively means that it can only pick colors of pixels at even coordinates (in the absolute desktop space). So if the window is placed at, say, `(201, 201)`, `Robot` can only pick the color at either `(200, 200)` or `(202, 202)`. Since the test only makes sense if it is pixel-accurate, I removed all `@run`s with `sun.java2d.uiScale` other than 1. This way window placement will not cause a failure.
>> 
>> This was tested on Ubuntu 20.04 and 18.04 with desktop scaling set to 100%, 200%, and 300%.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverted HiDPIRobotScreenCaptureTest back to 8280861 with minor changes

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From aivanov at openjdk.java.net  Wed Mar 16 14:50:45 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 16 Mar 2022 14:50:45 GMT
Subject: RFR: JDK-8282046: Create a regression test for JDK-8000326 [v3]
In-Reply-To: <h8OcXU4ZzuDPAR85ywBYRfgCCexY7DoQEKc6c2eQXXM=.935fbc18-b48b-4e33-8e99-3fbb9a4294d3@github.com>
References: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
 <h8OcXU4ZzuDPAR85ywBYRfgCCexY7DoQEKc6c2eQXXM=.935fbc18-b48b-4e33-8e99-3fbb9a4294d3@github.com>
Message-ID: <LcdplfzUn2U4T6fNkXjvo296996jI5diboM_bDz6CsU=.0b34c522-32a3-44ad-b8ca-b295fea4ef9f@github.com>

On Fri, 11 Mar 2022 14:38:28 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a regression test for CCC8000326
>> 
>> Issue is identified by [JDK-8000326](https://bugs.openjdk.java.net/browse/JDK-8000326), which identifies that after focus moves into JMenuBar, whose focus traversal key is disabled by default, it never moves to other focusable component.
>>  
>> By default, pressing the Tab key does not transfer focus from a JMenuBar which is added to a container together with other Swing components, because the focusTraversalKeysEnabled property of JMenuBar is set to false. To resolve this, you should call the JMenuBar.setFocusTraversalKeysEnabled(true) method.
>>  
>> The test verifies focus traversal for the above described scenario.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added @bug keyword

You copied the test into the new folder but the old folder still remains. You have to remove it. We don't want two identical tests in different locations.

test/jdk/java/awt/Focus/8000326/SetFocusTraversalKeysEnabledTest.java line 51:

> 49:     private static volatile JFrame jFrame;
> 50:     private static volatile Component currentFocusOwner;
> 51:     private static Robot robot;

This field is unused.

test/jdk/java/awt/Focus/8000326/SetFocusTraversalKeysEnabledTest.java line 83:

> 81:     private static void createGUI() {
> 82:         jFrame = new JFrame("Focus Traversal Test");
> 83:         jFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

Suggestion:

        jFrame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);

jtreg tests should never call `System.exit`, it's safer to use `DISPOSE_ON_CLOSE`.

test/jdk/java/awt/Focus/8000326/SetFocusTraversalKeysEnabledTest.java line 101:

> 99:         jFrame.pack();
> 100:         northButton.requestFocusInWindow();
> 101:         jFrame.setVisible(true);

You can add

        jFrame.setLocationRelativeTo(null);

before calling `setVisible` to show the frame in the center of the screen, which is the recommended location for tests.

-------------

Changes requested by aivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7512


From aivanov at openjdk.java.net  Wed Mar 16 15:32:45 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 16 Mar 2022 15:32:45 GMT
Subject: RFR: JDK-8282046: Create a regression test for JDK-8000326 [v3]
In-Reply-To: <h8OcXU4ZzuDPAR85ywBYRfgCCexY7DoQEKc6c2eQXXM=.935fbc18-b48b-4e33-8e99-3fbb9a4294d3@github.com>
References: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
 <h8OcXU4ZzuDPAR85ywBYRfgCCexY7DoQEKc6c2eQXXM=.935fbc18-b48b-4e33-8e99-3fbb9a4294d3@github.com>
Message-ID: <G1LRo54IeLDG8rWPhwe1KYaKdYbmkSHDcRaE2Lcto8Y=.7f45680d-a29d-481e-8c10-954030a726b0@github.com>

On Fri, 11 Mar 2022 14:38:28 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a regression test for CCC8000326
>> 
>> Issue is identified by [JDK-8000326](https://bugs.openjdk.java.net/browse/JDK-8000326), which identifies that after focus moves into JMenuBar, whose focus traversal key is disabled by default, it never moves to other focusable component.
>>  
>> By default, pressing the Tab key does not transfer focus from a JMenuBar which is added to a container together with other Swing components, because the focusTraversalKeysEnabled property of JMenuBar is set to false. To resolve this, you should call the JMenuBar.setFocusTraversalKeysEnabled(true) method.
>>  
>> The test verifies focus traversal for the above described scenario.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added @bug keyword

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/Focus/8000326/SetFocusTraversalKeysEnabledTest.java line 64:

> 62:                 SwingUtilities.invokeAndWait(() -> {
> 63:                     currentFocusOwner = jFrame.getFocusOwner();
> 64:                 });

When there's only one statement in the lambda statement, it can be replaced with expression lambda:
Suggestion:

                SwingUtilities.invokeAndWait(() ->
                        currentFocusOwner = jFrame.getFocusOwner());

Just like you did for `createGUI()`.

This also applies to `jFrame.dispose()` statement.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7512


From aivanov at openjdk.java.net  Wed Mar 16 15:36:44 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 16 Mar 2022 15:36:44 GMT
Subject: RFR: JDK-8282046: Create a regression test for JDK-8000326 [v3]
In-Reply-To: <h8OcXU4ZzuDPAR85ywBYRfgCCexY7DoQEKc6c2eQXXM=.935fbc18-b48b-4e33-8e99-3fbb9a4294d3@github.com>
References: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
 <h8OcXU4ZzuDPAR85ywBYRfgCCexY7DoQEKc6c2eQXXM=.935fbc18-b48b-4e33-8e99-3fbb9a4294d3@github.com>
Message-ID: <ppHGgBX6S7d9nAFmfzHxubsp_9kFr_Nk032KKUaMlW8=.cae70ecb-38cf-495b-8291-d70d808b48a2@github.com>

On Fri, 11 Mar 2022 14:38:28 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a regression test for CCC8000326
>> 
>> Issue is identified by [JDK-8000326](https://bugs.openjdk.java.net/browse/JDK-8000326), which identifies that after focus moves into JMenuBar, whose focus traversal key is disabled by default, it never moves to other focusable component.
>>  
>> By default, pressing the Tab key does not transfer focus from a JMenuBar which is added to a container together with other Swing components, because the focusTraversalKeysEnabled property of JMenuBar is set to false. To resolve this, you should call the JMenuBar.setFocusTraversalKeysEnabled(true) method.
>>  
>> The test verifies focus traversal for the above described scenario.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added @bug keyword

Does the test reproduce the problem described in JDK-8000326?

The bug was resolved in 8-b78. So the test should fail when run with 8-b77. Could you please confirm?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7512


From aivanov at openjdk.java.net  Wed Mar 16 15:47:42 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 16 Mar 2022 15:47:42 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v3]
In-Reply-To: <JWOVqPWqxmWGG0SQV97rQGTPcZNPcGcgcmNwc1YRO6I=.224d5021-d155-477b-a144-7becafbe08e1@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <HYjNkqqcwMFOo-6mM2Q_4-1B5ePKD3-DRICoaF_1-bA=.53f59ac5-02f8-4c57-924c-40d22a760db1@github.com>
 <JWOVqPWqxmWGG0SQV97rQGTPcZNPcGcgcmNwc1YRO6I=.224d5021-d155-477b-a144-7becafbe08e1@github.com>
Message-ID: <i1uqQBLKdWa7-H8nLrXeJD2l8uqJnmsKqCmzDnRGkiI=.26a3dfde-5ca4-4ac1-9cb7-ebaa282634f0@github.com>

On Tue, 15 Mar 2022 16:51:56 GMT, lukeu <duke at openjdk.java.net> wrote:

> I believe the only way to get pixel-perfect (& balanced weight) rendering of 2 lines next to each other at non-integer scale factors, when using integer based APIs like `drawLine`, will be to undo the affine transformation upon the pre-scaled `Graphics2D` object, and render it at 1x scaling. Then you'd need to decide how to compute the desired line thickness (like: should it jump 1px > 2px at 150% scaling or 175% scaling?)

I've been thinking about it. It could be the approach to use for drawing borders. Windows controls render 1-pixel borders when the scale is 200%.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From aivanov at openjdk.java.net  Wed Mar 16 16:00:56 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 16 Mar 2022 16:00:56 GMT
Subject: RFR: 8282789: Create a regression test for the JTree usecase of
 JDK-4618767
In-Reply-To: <8OsXQ_pAltihbq8L16yTW3IsYGF3nahH-Xa7fy7G3vI=.35818df7-7c9c-4acc-9b1c-63a03942914c@github.com>
References: <8OsXQ_pAltihbq8L16yTW3IsYGF3nahH-Xa7fy7G3vI=.35818df7-7c9c-4acc-9b1c-63a03942914c@github.com>
Message-ID: <GXJUhgbSmsOfX8M52ffDLngrtcu9q1RVH-oner2ee6s=.1f012936-c19f-43d2-83f3-efa01f73312b@github.com>

On Tue, 8 Mar 2022 10:52:44 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Create a regression test for the JTree usecase of [JDK-4618767](https://bugs.openjdk.java.net/browse/JDK-4618767)
> Context: Migrating tests from a closed tonga based test suite to open regression based one.
> 
> Issue identified in [JDK-4618767](https://bugs.openjdk.java.net/browse/JDK-4618767):
> Typing a letter while a JTree has focus now makes the selection jump to the first/next node/item whose text starts with that letter even though that letter is accompanied by modifier keys such as ALT or CTRL.
> 
> Fix:
> Only enable JTree letter navigation when the user doesn't press any modifier keys such as ALT or CTRL.
> 
> Testing:
> Java 1.4.0 -> Test Failed.
> $ ./j2sdk1.4.0/bin/java JTreeOld
> LookAndFeel: javax.swing.plaf.metal.MetalLookAndFeel
> OS = windows nt (unknown)
> java.lang.RuntimeException: Test Failed, expected colors, but got food
>         at JTreeOld.doTest(JTreeOld.java:166)
>         at JTreeOld.main(JTreeOld.java:32)
> Exception in thread "main"
> 
> Java 1.4.1 -> Test Passed.
> $ ./j2sdk1.4.1/bin/java JTreeOld
> LookAndFeel: javax.swing.plaf.metal.MetalLookAndFeel
> OS = windows nt (unknown)
> Test passed javax.swing.plaf.metal.MetalLookAndFeel
> LookAndFeel: com.sun.java.swing.plaf.motif.MotifLookAndFeel
> OS = windows nt (unknown)
> Test passed com.sun.java.swing.plaf.motif.MotifLookAndFeel
> LookAndFeel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> OS = windows nt (unknown)
> Test passed com.sun.java.swing.plaf.windows.WindowsLookAndFeel

Marked as reviewed by aivanov (Reviewer).

test/jdk/javax/swing/JTree/4618767/JTreeSelectedElementTest.java line 166:

> 164:             final Point locationOnScreen = tree.getLocationOnScreen();
> 165:             Rectangle rt = tree.getPathBounds(tree.getPathForRow(rowCount));
> 166:             locationOnScreen.translate((int) (rt.getX() + rt.getWidth() / 2), (int) (rt.getY() + rt.getHeight() / 2));

Suggestion:

            locationOnScreen.translate(rt.x + rt.width / 2, rt.y + rt.height / 2);

-------------

PR: https://git.openjdk.java.net/jdk/pull/7742


From mvs at openjdk.java.net  Wed Mar 16 16:25:25 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 16 Mar 2022 16:25:25 GMT
Subject: RFR: 8282789: Create a regression test for the JTree usecase of
 JDK-4618767 [v2]
In-Reply-To: <8OsXQ_pAltihbq8L16yTW3IsYGF3nahH-Xa7fy7G3vI=.35818df7-7c9c-4acc-9b1c-63a03942914c@github.com>
References: <8OsXQ_pAltihbq8L16yTW3IsYGF3nahH-Xa7fy7G3vI=.35818df7-7c9c-4acc-9b1c-63a03942914c@github.com>
Message-ID: <UIegL6YsFiyUP0gFER_87r3z9_XMliwd63Sb2OU5SA4=.263fcc98-a222-495f-8438-6cf875b87793@github.com>

> Create a regression test for the JTree usecase of [JDK-4618767](https://bugs.openjdk.java.net/browse/JDK-4618767)
> Context: Migrating tests from a closed tonga based test suite to open regression based one.
> 
> Issue identified in [JDK-4618767](https://bugs.openjdk.java.net/browse/JDK-4618767):
> Typing a letter while a JTree has focus now makes the selection jump to the first/next node/item whose text starts with that letter even though that letter is accompanied by modifier keys such as ALT or CTRL.
> 
> Fix:
> Only enable JTree letter navigation when the user doesn't press any modifier keys such as ALT or CTRL.
> 
> Testing:
> Java 1.4.0 -> Test Failed.
> $ ./j2sdk1.4.0/bin/java JTreeOld
> LookAndFeel: javax.swing.plaf.metal.MetalLookAndFeel
> OS = windows nt (unknown)
> java.lang.RuntimeException: Test Failed, expected colors, but got food
>         at JTreeOld.doTest(JTreeOld.java:166)
>         at JTreeOld.main(JTreeOld.java:32)
> Exception in thread "main"
> 
> Java 1.4.1 -> Test Passed.
> $ ./j2sdk1.4.1/bin/java JTreeOld
> LookAndFeel: javax.swing.plaf.metal.MetalLookAndFeel
> OS = windows nt (unknown)
> Test passed javax.swing.plaf.metal.MetalLookAndFeel
> LookAndFeel: com.sun.java.swing.plaf.motif.MotifLookAndFeel
> OS = windows nt (unknown)
> Test passed com.sun.java.swing.plaf.motif.MotifLookAndFeel
> LookAndFeel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> OS = windows nt (unknown)
> Test passed com.sun.java.swing.plaf.windows.WindowsLookAndFeel

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed: Removed (int) casting and directly used variables x,y

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7742/files
  - new: https://git.openjdk.java.net/jdk/pull/7742/files/95c3640b..3c558772

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7742&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7742&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7742.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7742/head:pull/7742

PR: https://git.openjdk.java.net/jdk/pull/7742


From aivanov at openjdk.java.net  Wed Mar 16 16:31:49 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 16 Mar 2022 16:31:49 GMT
Subject: RFR: 8282789: Create a regression test for the JTree usecase of
 JDK-4618767 [v2]
In-Reply-To: <UIegL6YsFiyUP0gFER_87r3z9_XMliwd63Sb2OU5SA4=.263fcc98-a222-495f-8438-6cf875b87793@github.com>
References: <8OsXQ_pAltihbq8L16yTW3IsYGF3nahH-Xa7fy7G3vI=.35818df7-7c9c-4acc-9b1c-63a03942914c@github.com>
 <UIegL6YsFiyUP0gFER_87r3z9_XMliwd63Sb2OU5SA4=.263fcc98-a222-495f-8438-6cf875b87793@github.com>
Message-ID: <MvKIJR6wHgk51Igs7Y2csF_s5l_8bOkCU3xz1K00ZXg=.053dcb6e-e29e-4548-af26-27a9a34592ed@github.com>

On Wed, 16 Mar 2022 16:25:25 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Create a regression test for the JTree usecase of [JDK-4618767](https://bugs.openjdk.java.net/browse/JDK-4618767)
>> Context: Migrating tests from a closed tonga based test suite to open regression based one.
>> 
>> Issue identified in [JDK-4618767](https://bugs.openjdk.java.net/browse/JDK-4618767):
>> Typing a letter while a JTree has focus now makes the selection jump to the first/next node/item whose text starts with that letter even though that letter is accompanied by modifier keys such as ALT or CTRL.
>> 
>> Fix:
>> Only enable JTree letter navigation when the user doesn't press any modifier keys such as ALT or CTRL.
>> 
>> Testing:
>> Java 1.4.0 -> Test Failed.
>> $ ./j2sdk1.4.0/bin/java JTreeOld
>> LookAndFeel: javax.swing.plaf.metal.MetalLookAndFeel
>> OS = windows nt (unknown)
>> java.lang.RuntimeException: Test Failed, expected colors, but got food
>>         at JTreeOld.doTest(JTreeOld.java:166)
>>         at JTreeOld.main(JTreeOld.java:32)
>> Exception in thread "main"
>> 
>> Java 1.4.1 -> Test Passed.
>> $ ./j2sdk1.4.1/bin/java JTreeOld
>> LookAndFeel: javax.swing.plaf.metal.MetalLookAndFeel
>> OS = windows nt (unknown)
>> Test passed javax.swing.plaf.metal.MetalLookAndFeel
>> LookAndFeel: com.sun.java.swing.plaf.motif.MotifLookAndFeel
>> OS = windows nt (unknown)
>> Test passed com.sun.java.swing.plaf.motif.MotifLookAndFeel
>> LookAndFeel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>> OS = windows nt (unknown)
>> Test passed com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: Removed (int) casting and directly used variables x,y

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7742


From aivanov at openjdk.java.net  Wed Mar 16 16:31:52 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 16 Mar 2022 16:31:52 GMT
Subject: RFR: 8282548: Create a regression test for JDK-4330998
In-Reply-To: <7HqoT6jmH4HyYQUli2v_MDFwkk8BV-e-0uAEFyxBmkI=.735e0071-2c02-423a-9647-9f33a0fedfa4@github.com>
References: <7HqoT6jmH4HyYQUli2v_MDFwkk8BV-e-0uAEFyxBmkI=.735e0071-2c02-423a-9647-9f33a0fedfa4@github.com>
Message-ID: <JSkA25nmVVTPTkA9zffiscso3uu939vgoHJ_1EGQNpY=.dc03833f-bf1a-479e-b480-341f52cd10d3@github.com>

On Tue, 8 Mar 2022 10:06:23 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Create a regression test for [JDK-4330998](https://bugs.openjdk.java.net/browse/JDK-4330998)
> Context: Migrating tests from a closed tonga based test suite to open regression based one.
> 
> Issue tested:
> When calling JEditorPane.setText(null), the following exception is thrown:
> 
> java.lang.NullPointerException:
>         at java.io.StringReader.<init>(StringReader.java:38)
> 
> Testing:
> Java 1.4.0 -> Test Failed.
> $ ./j2sdk1.4.0/bin/java bug4330998Win
> java.lang.RuntimeException: Test failed, caught Exception java.lang.NullPointerException when calling text.setText(null)
>         at bug4330998Win.runTest(bug4330998Win.java:45)
>         at bug4330998Win.main(bug4330998Win.java:51)
> Exception in thread "main"
> 
> Java 1.4.1 -> Test Passed.
> $ ./j2sdk1.4.1/bin/java bug4330998Win
> Test passed

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JEditorPane/4330998/JEditorPaneSetTextNullTest.java line 41:

> 39: 
> 40:          try {
> 41:              SwingUtilities.invokeAndWait(() -> editorPane.setText(null));

I believe the test could be simplified to
Suggestion:

             SwingUtilities.invokeAndWait(() -> new JEditorPane().setText(null));

And `createUI()` can be removed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7740


From mvs at openjdk.java.net  Wed Mar 16 16:43:25 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 16 Mar 2022 16:43:25 GMT
Subject: RFR: 8282548: Create a regression test for JDK-4330998 [v2]
In-Reply-To: <7HqoT6jmH4HyYQUli2v_MDFwkk8BV-e-0uAEFyxBmkI=.735e0071-2c02-423a-9647-9f33a0fedfa4@github.com>
References: <7HqoT6jmH4HyYQUli2v_MDFwkk8BV-e-0uAEFyxBmkI=.735e0071-2c02-423a-9647-9f33a0fedfa4@github.com>
Message-ID: <u0dEXPmVur9-7ubI7ciUV4ifRgSp6dcZDwrLBn31OSE=.cf133b00-4d3e-4e1c-b6ff-5d6d0ff0d3f0@github.com>

> Create a regression test for [JDK-4330998](https://bugs.openjdk.java.net/browse/JDK-4330998)
> Context: Migrating tests from a closed tonga based test suite to open regression based one.
> 
> Issue tested:
> When calling JEditorPane.setText(null), the following exception is thrown:
> 
> java.lang.NullPointerException:
>         at java.io.StringReader.<init>(StringReader.java:38)
> 
> Testing:
> Java 1.4.0 -> Test Failed.
> $ ./j2sdk1.4.0/bin/java bug4330998Win
> java.lang.RuntimeException: Test failed, caught Exception java.lang.NullPointerException when calling text.setText(null)
>         at bug4330998Win.runTest(bug4330998Win.java:45)
>         at bug4330998Win.main(bug4330998Win.java:51)
> Exception in thread "main"
> 
> Java 1.4.1 -> Test Passed.
> $ ./j2sdk1.4.1/bin/java bug4330998Win
> Test passed

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed: Simplified the test, removed unwanted method

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7740/files
  - new: https://git.openjdk.java.net/jdk/pull/7740/files/f2e2bac8..990b6720

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7740&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7740&range=00-01

  Stats: 12 lines in 1 file changed: 0 ins; 10 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7740.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7740/head:pull/7740

PR: https://git.openjdk.java.net/jdk/pull/7740


From aivanov at openjdk.java.net  Wed Mar 16 16:43:27 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 16 Mar 2022 16:43:27 GMT
Subject: RFR: 8282548: Create a regression test for JDK-4330998 [v2]
In-Reply-To: <JSkA25nmVVTPTkA9zffiscso3uu939vgoHJ_1EGQNpY=.dc03833f-bf1a-479e-b480-341f52cd10d3@github.com>
References: <7HqoT6jmH4HyYQUli2v_MDFwkk8BV-e-0uAEFyxBmkI=.735e0071-2c02-423a-9647-9f33a0fedfa4@github.com>
 <JSkA25nmVVTPTkA9zffiscso3uu939vgoHJ_1EGQNpY=.dc03833f-bf1a-479e-b480-341f52cd10d3@github.com>
Message-ID: <P_-eR_ETumkjiohGxXA_xQXfaN7Vq-8lHdrKyGKnTOI=.c2d8910e-5c15-46cc-b020-d774d16a2143@github.com>

On Wed, 16 Mar 2022 16:23:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments fixed: Simplified the test, removed unwanted method
>
> test/jdk/javax/swing/JEditorPane/4330998/JEditorPaneSetTextNullTest.java line 41:
> 
>> 39: 
>> 40:          try {
>> 41:              SwingUtilities.invokeAndWait(() -> editorPane.setText(null));
> 
> I believe the test could be simplified to
> Suggestion:
> 
>              SwingUtilities.invokeAndWait(() -> new JEditorPane().setText(null));
> 
> And `createUI()` can be removed.

If you like to make sure the test expects `NullPointerException` only, you can use try-catch inside the lambda expression and propagate the exception thrown from `invokeAndWait`.

Yet it's not required: we don't expect any exceptions thrown. Therefore try-catch can be dropped too. If an exception is thrown, test fails. However, in this case a clarifying comment would be useful.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7740


From mvs at openjdk.java.net  Wed Mar 16 16:43:28 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 16 Mar 2022 16:43:28 GMT
Subject: RFR: 8282548: Create a regression test for JDK-4330998 [v2]
In-Reply-To: <P_-eR_ETumkjiohGxXA_xQXfaN7Vq-8lHdrKyGKnTOI=.c2d8910e-5c15-46cc-b020-d774d16a2143@github.com>
References: <7HqoT6jmH4HyYQUli2v_MDFwkk8BV-e-0uAEFyxBmkI=.735e0071-2c02-423a-9647-9f33a0fedfa4@github.com>
 <JSkA25nmVVTPTkA9zffiscso3uu939vgoHJ_1EGQNpY=.dc03833f-bf1a-479e-b480-341f52cd10d3@github.com>
 <P_-eR_ETumkjiohGxXA_xQXfaN7Vq-8lHdrKyGKnTOI=.c2d8910e-5c15-46cc-b020-d774d16a2143@github.com>
Message-ID: <66zXV-E68gzUWPwl8zs7b_GWV6S9kSlj_BYGxPQWh4w=.beb65cc3-d9f8-4bc1-bbf6-be2aab61c07b@github.com>

On Wed, 16 Mar 2022 16:36:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/JEditorPane/4330998/JEditorPaneSetTextNullTest.java line 41:
>> 
>>> 39: 
>>> 40:          try {
>>> 41:              SwingUtilities.invokeAndWait(() -> editorPane.setText(null));
>> 
>> I believe the test could be simplified to
>> Suggestion:
>> 
>>              SwingUtilities.invokeAndWait(() -> new JEditorPane().setText(null));
>> 
>> And `createUI()` can be removed.
>
> If you like to make sure the test expects `NullPointerException` only, you can use try-catch inside the lambda expression and propagate the exception thrown from `invokeAndWait`.
> 
> Yet it's not required: we don't expect any exceptions thrown. Therefore try-catch can be dropped too. If an exception is thrown, test fails. However, in this case a clarifying comment would be useful.

But if we want to throw the RuntimeException with a failure message, I think we need to catch it, right?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7740


From mvs at openjdk.java.net  Wed Mar 16 16:46:47 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 16 Mar 2022 16:46:47 GMT
Subject: RFR: 8282548: Create a regression test for JDK-4330998 [v3]
In-Reply-To: <7HqoT6jmH4HyYQUli2v_MDFwkk8BV-e-0uAEFyxBmkI=.735e0071-2c02-423a-9647-9f33a0fedfa4@github.com>
References: <7HqoT6jmH4HyYQUli2v_MDFwkk8BV-e-0uAEFyxBmkI=.735e0071-2c02-423a-9647-9f33a0fedfa4@github.com>
Message-ID: <Nj57xtyFgnJwnVqRI8QZR0kT_YU4OTMgtV58eP3yIB0=.46b31a34-7535-4e22-bb96-270bf2ce430d@github.com>

> Create a regression test for [JDK-4330998](https://bugs.openjdk.java.net/browse/JDK-4330998)
> Context: Migrating tests from a closed tonga based test suite to open regression based one.
> 
> Issue tested:
> When calling JEditorPane.setText(null), the following exception is thrown:
> 
> java.lang.NullPointerException:
>         at java.io.StringReader.<init>(StringReader.java:38)
> 
> Testing:
> Java 1.4.0 -> Test Failed.
> $ ./j2sdk1.4.0/bin/java bug4330998Win
> java.lang.RuntimeException: Test failed, caught Exception java.lang.NullPointerException when calling text.setText(null)
>         at bug4330998Win.runTest(bug4330998Win.java:45)
>         at bug4330998Win.main(bug4330998Win.java:51)
> Exception in thread "main"
> 
> Java 1.4.1 -> Test Passed.
> $ ./j2sdk1.4.1/bin/java bug4330998Win
> Test passed

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Fixed jcheck whitespace error

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7740/files
  - new: https://git.openjdk.java.net/jdk/pull/7740/files/990b6720..9291aa4e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7740&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7740&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7740.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7740/head:pull/7740

PR: https://git.openjdk.java.net/jdk/pull/7740


From aivanov at openjdk.java.net  Wed Mar 16 16:50:49 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 16 Mar 2022 16:50:49 GMT
Subject: RFR: 8282548: Create a regression test for JDK-4330998 [v3]
In-Reply-To: <66zXV-E68gzUWPwl8zs7b_GWV6S9kSlj_BYGxPQWh4w=.beb65cc3-d9f8-4bc1-bbf6-be2aab61c07b@github.com>
References: <7HqoT6jmH4HyYQUli2v_MDFwkk8BV-e-0uAEFyxBmkI=.735e0071-2c02-423a-9647-9f33a0fedfa4@github.com>
 <JSkA25nmVVTPTkA9zffiscso3uu939vgoHJ_1EGQNpY=.dc03833f-bf1a-479e-b480-341f52cd10d3@github.com>
 <P_-eR_ETumkjiohGxXA_xQXfaN7Vq-8lHdrKyGKnTOI=.c2d8910e-5c15-46cc-b020-d774d16a2143@github.com>
 <66zXV-E68gzUWPwl8zs7b_GWV6S9kSlj_BYGxPQWh4w=.beb65cc3-d9f8-4bc1-bbf6-be2aab61c07b@github.com>
Message-ID: <j0reqCQ0tIl-WM1KjK81Nefebln73dfDqF9FA--bCmw=.5766fca4-b757-4ae5-9a23-ed4df4d5dc77@github.com>

On Wed, 16 Mar 2022 16:39:24 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> But if we want to throw the RuntimeException with a failure message, I think we need to catch it, right?

Yes, if you want to provide a more specific error message.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7740


From mvs at openjdk.java.net  Wed Mar 16 17:03:33 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 16 Mar 2022 17:03:33 GMT
Subject: RFR: 8282548: Create a regression test for JDK-4330998 [v4]
In-Reply-To: <7HqoT6jmH4HyYQUli2v_MDFwkk8BV-e-0uAEFyxBmkI=.735e0071-2c02-423a-9647-9f33a0fedfa4@github.com>
References: <7HqoT6jmH4HyYQUli2v_MDFwkk8BV-e-0uAEFyxBmkI=.735e0071-2c02-423a-9647-9f33a0fedfa4@github.com>
Message-ID: <-S8NPqpEvoouTBODZBc5iP6YuQxw6WkLvdlhELNfDQs=.6743558b-1d26-4cf1-b7bb-26bc6ca2f005@github.com>

> Create a regression test for [JDK-4330998](https://bugs.openjdk.java.net/browse/JDK-4330998)
> Context: Migrating tests from a closed tonga based test suite to open regression based one.
> 
> Issue tested:
> When calling JEditorPane.setText(null), the following exception is thrown:
> 
> java.lang.NullPointerException:
>         at java.io.StringReader.<init>(StringReader.java:38)
> 
> Testing:
> Java 1.4.0 -> Test Failed.
> $ ./j2sdk1.4.0/bin/java bug4330998Win
> java.lang.RuntimeException: Test failed, caught Exception java.lang.NullPointerException when calling text.setText(null)
>         at bug4330998Win.runTest(bug4330998Win.java:45)
>         at bug4330998Win.main(bug4330998Win.java:51)
> Exception in thread "main"
> 
> Java 1.4.1 -> Test Passed.
> $ ./j2sdk1.4.1/bin/java bug4330998Win
> Test passed

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Renamed mains() parameter to args

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7740/files
  - new: https://git.openjdk.java.net/jdk/pull/7740/files/9291aa4e..03d7475a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7740&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7740&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7740.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7740/head:pull/7740

PR: https://git.openjdk.java.net/jdk/pull/7740


From aivanov at openjdk.java.net  Wed Mar 16 17:09:50 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 16 Mar 2022 17:09:50 GMT
Subject: RFR: 8282548: Create a regression test for JDK-4330998 [v4]
In-Reply-To: <-S8NPqpEvoouTBODZBc5iP6YuQxw6WkLvdlhELNfDQs=.6743558b-1d26-4cf1-b7bb-26bc6ca2f005@github.com>
References: <7HqoT6jmH4HyYQUli2v_MDFwkk8BV-e-0uAEFyxBmkI=.735e0071-2c02-423a-9647-9f33a0fedfa4@github.com>
 <-S8NPqpEvoouTBODZBc5iP6YuQxw6WkLvdlhELNfDQs=.6743558b-1d26-4cf1-b7bb-26bc6ca2f005@github.com>
Message-ID: <ddDEHwFG_2jGB9qPZswCq7JYPv77WsOjQrLBKSvZf34=.145811a2-2eeb-4da8-9b41-4721848d6431@github.com>

On Wed, 16 Mar 2022 17:03:33 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Create a regression test for [JDK-4330998](https://bugs.openjdk.java.net/browse/JDK-4330998)
>> Context: Migrating tests from a closed tonga based test suite to open regression based one.
>> 
>> Issue tested:
>> When calling JEditorPane.setText(null), the following exception is thrown:
>> 
>> java.lang.NullPointerException:
>>         at java.io.StringReader.<init>(StringReader.java:38)
>> 
>> Testing:
>> Java 1.4.0 -> Test Failed.
>> $ ./j2sdk1.4.0/bin/java bug4330998Win
>> java.lang.RuntimeException: Test failed, caught Exception java.lang.NullPointerException when calling text.setText(null)
>>         at bug4330998Win.runTest(bug4330998Win.java:45)
>>         at bug4330998Win.main(bug4330998Win.java:51)
>> Exception in thread "main"
>> 
>> Java 1.4.1 -> Test Passed.
>> $ ./j2sdk1.4.1/bin/java bug4330998Win
>> Test passed
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renamed mains() parameter to args

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7740


From prr at openjdk.java.net  Wed Mar 16 17:13:48 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 16 Mar 2022 17:13:48 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v4]
In-Reply-To: <px566UftzNVHlLSDErQ3n9S7ZPQ_6sqMrDjNy6Z_4_Y=.e8381b27-170d-4eee-a4a2-47681573859f@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <px566UftzNVHlLSDErQ3n9S7ZPQ_6sqMrDjNy6Z_4_Y=.e8381b27-170d-4eee-a4a2-47681573859f@github.com>
Message-ID: <W7oNtp_fcveeOJYhUGCJAE-pHbn_ME-ELge6VdOBBCQ=.48713559-2645-4fb0-8f48-2696da065e72@github.com>

On Wed, 16 Mar 2022 06:02:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   korean fallback added

The image looks like it is using Malgun for all fonts, so I'd like to see one with the font pack installed too.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7643


From prr at openjdk.java.net  Wed Mar 16 17:19:57 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 16 Mar 2022 17:19:57 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v6]
In-Reply-To: <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
Message-ID: <_XwD8h3_L03wqvO0Na4_OoHwtdYInzjTKsOaFvqKfUY=.47ccb949-e5fe-49bb-b4b8-3bc36676910a@github.com>

On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge branch 'master' into shuffle-data-reborn
>  - Fix merge
>  - Merge tag 'jdk-19+13' into shuffle-data-reborn
>    
>    Added tag jdk-19+13 for changeset 5df2a057
>  - Move characterdata templates to share/classes/java/lang.
>  - Update comment refering to "make" dir
>  - Move new symbols to jdk.compiler
>  - Merge branch 'master' into shuffle-data
>  - Move macosxicons from share to macosx
>  - Move to share/data, and move jdwp.spec to java.se
>  - Update references in test
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f

How are folks reviewing this huge PR ?
My browser paints a few files and that's it, and the drop down list to "jump to" is too big to display - it says !

-------------

PR: https://git.openjdk.java.net/jdk/pull/1611


From duke at openjdk.java.net  Wed Mar 16 17:36:55 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Wed, 16 Mar 2022 17:36:55 GMT
Subject: RFR: 8024624: [TEST_BUG] [macosx] CTRL+RIGHT(LEFT) doesn't move
 selection on next cell in JTable on Aqua L&F
In-Reply-To: <LdWWDPfwqpCC-_EBaYQLX4rFIyV9FLAG5ugIJb0ruI4=.bc296640-5df9-41a1-b857-14f334c1be8e@github.com>
References: <LdWWDPfwqpCC-_EBaYQLX4rFIyV9FLAG5ugIJb0ruI4=.bc296640-5df9-41a1-b857-14f334c1be8e@github.com>
Message-ID: <PKnsF9qWEibIc11QJxy0KMZlqSE2of1CoKiMxJLPZ3U=.9e646b8f-76a9-4f35-895a-217e869f4496@github.com>

On Fri, 11 Mar 2022 23:13:15 GMT, DamonGuy <duke at openjdk.java.net> wrote:

> Aqua L&F tables lacked support for `CTRL+ARROW`, `CTRL+PG_UP/DOWN`, and `CTRL+SHIFT+PG_UP/DOWN` key bindings. This allows for navigation and selection of table cells without the need of a mouse and without deselecting the current selected cell group. 
> 
> Those key bindings are added to Aqua's key bindings for tables. The `SPACE` key binding was also added because it allows for the selection of cells after navigating using the `CTRL+ARROW` bindings, and some of the new bindings are only useful with the `SPACE` binding added. The closed test that this bug originates from tests for both left-to-right and right-to-left functionality, so the new directional bindings are also added to the right-to-left key bindings table where needed.
> 
> This requires mission control shortcuts in macOS to be disabled as `CTRL+ARROW` keys are normally used for virtual desktop navigation.

> _Mailing list message from [Miguel Munoz](mailto:swingguy1024 at yahoo.com) on [client-libs-dev](mailto:client-libs-dev at mail.openjdk.java.net):_
> 
> On the MacOS, it's the OPTION-CLICK event, not the COMMAND-CLICK event that does the same thing as CONTROL-CLICK on Windows and other platforms. Every platform has modifier key used to advance the cursor by words instead of characters, but the modifiers are different on the Mac.
> 
> To see this working correctly, try an app running under JDK 8, which was the last one they worked under. (Actually, I haven't tried 9 or 10) Or you can try any non-java application. This is a standard user interface convention, and Java should continue to support it like it did through Java -8.
> 
> ? Miguel Mu?oz On Tuesday, March 15, 2022, 06:53:19 PM PDT, Sergey Bylokhov <serb at openjdk.java.net> wrote:
> 
> On Sat, 12 Mar 2022 01:27:34 GMT, DamonGuy <duke at openjdk.java.net> wrote:
> 
> > Apple Pages has no support at all for these table navigation functions other than `COMMAND+LEFT_CLICK`. Excel has a selection mode that can be toggled on/off using SHIFT+F8. I also tested in macOS's `System Preferences > Keyboard > Text` and `CMD+CLICK` is the only supported way to select non-adjacent cells as well.
> 
> Since for any reason the macOS does not supported such navigation in the tables and use it by mission control it seems correct to do the same in the native look and feel, and ignore the test.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/7792

I tested again on native macOS tables, and CMD+CLICK seems to be the functioning modifier+key combination for selecting multiple non-adjacent cells. I also found [this](https://support.apple.com/guide/pages/select-tables-cells-rows-and-columns-tan661e2f40a/mac) information under `cells` and `rows and columns` that shows the same key bindings. I could change the bindings, but that would change Aqua L&F to be further from native macOS behavior.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7792


From achung at openjdk.java.net  Wed Mar 16 17:40:43 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 16 Mar 2022 17:40:43 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v3]
In-Reply-To: <HYjNkqqcwMFOo-6mM2Q_4-1B5ePKD3-DRICoaF_1-bA=.53f59ac5-02f8-4c57-924c-40d22a760db1@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <HYjNkqqcwMFOo-6mM2Q_4-1B5ePKD3-DRICoaF_1-bA=.53f59ac5-02f8-4c57-924c-40d22a760db1@github.com>
Message-ID: <asBfO1iRdLDIRqrQFH4T_vE4CDuLPWMoEmBnmfoPfQg=.7db95713-79a4-487c-8b51-2f98197a89a4@github.com>

On Mon, 14 Mar 2022 16:15:47 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added functions for drawing border, fixed translate

I also noticed what Luke noticed when I tried my idea: that the lines jump apart and it's not possible to align the highlight and shadow next to each other. I'll try implementing removing the transformation before rendering like you two suggested to see how it looks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From naoto at openjdk.java.net  Wed Mar 16 17:54:48 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 16 Mar 2022 17:54:48 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v4]
In-Reply-To: <px566UftzNVHlLSDErQ3n9S7ZPQ_6sqMrDjNy6Z_4_Y=.e8381b27-170d-4eee-a4a2-47681573859f@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <px566UftzNVHlLSDErQ3n9S7ZPQ_6sqMrDjNy6Z_4_Y=.e8381b27-170d-4eee-a4a2-47681573859f@github.com>
Message-ID: <utS8fOW4B4s4uIzQ53sUifa0cHIaw4mLiJot8AGspRY=.1624735d-9916-4424-a2f8-1eff390e5fa0@github.com>

On Wed, 16 Mar 2022 06:02:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   korean fallback added

Cannot confirm on my environment, but the current fontconfig seems fine to me.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7643


From aivanov at openjdk.java.net  Wed Mar 16 17:54:50 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 16 Mar 2022 17:54:50 GMT
Subject: RFR: 8282526: Default icon is not painted properly
In-Reply-To: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
Message-ID: <DaqPtq-Ln71smI_Bctip_y-cg4jWZ2EYhGzz5W41rtc=.de88e778-05bf-4faf-9bb9-0dcc0df7a3f8@github.com>

On Sun, 13 Mar 2022 21:06:24 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Detect the situation where we do need to perform interpolation during ImageIcon
> painting and set a hint to the rendering to perform bicubic approximation so
> image details are preserved during transition.

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 463:

> 461:         if (hintChanged) {
> 462:             ((Graphics2D) g).setRenderingHint(RenderingHints.KEY_INTERPOLATION,
> 463:                     oldHint == null ? RenderingHints.VALUE_INTERPOLATION_NEAREST_NEIGHBOR : oldHint);

Isn't the state of the Graphics object modified? Previously, the `KEY_INTERPOLATION` hint was set to `null` but it is set to `VALUE_INTERPOLATION_NEAREST_NEIGHBOR` on exit. Why can't it be set to `null`? Always to `oldHint`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7805


From duke at openjdk.java.net  Wed Mar 16 18:15:47 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Wed, 16 Mar 2022 18:15:47 GMT
Subject: RFR: 8024624: [TEST_BUG] [macosx] CTRL+RIGHT(LEFT) doesn't move
 selection on next cell in JTable on Aqua L&F
In-Reply-To: <903806783.104456.1647411713894@mail.yahoo.com>
References: <LdWWDPfwqpCC-_EBaYQLX4rFIyV9FLAG5ugIJb0ruI4=.bc296640-5df9-41a1-b857-14f334c1be8e@github.com>
 <903806783.104456.1647411713894@mail.yahoo.com>
Message-ID: <EiCRBqj4DFb-tyhEv8ueKZ9_V7QYeWpdm206oqS12CQ=.00e2fc5c-4eb7-4b2d-b0a8-bbced377d806@github.com>

On Wed, 16 Mar 2022 06:24:00 GMT, Miguel Munoz <swingguy1024 at yahoo.com> wrote:

> > Apple Pages has no support at all for these table navigation functions other than `COMMAND+LEFT_CLICK`. Excel has a selection mode that can be toggled on/off using SHIFT+F8. I also tested in macOS's `System Preferences > Keyboard > Text` and `CMD+CLICK` is the only supported way to select non-adjacent cells as well.
> 
> Since for any reason the macOS does not supported such navigation in the tables and use it by mission control it seems correct to do the same in the native look and feel, and ignore the test.

I see your point. I will update the closed repo changes to exclude macOS from testing to avoid any issues it may cause. Should a separate issue be raised to update [this](https://docs.oracle.com/javase/tutorial/uiswing/components/table.html) doc to mention that macOS isn't included for these key bindings?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7792


From achung at openjdk.java.net  Wed Mar 16 18:31:55 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 16 Mar 2022 18:31:55 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v4]
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <SJQ29Ut1Mvo1_wXVRH6czoCYrkVhBoLSsVr0-wC9H34=.78a2083f-774e-4f4a-97f7-b998a2042c49@github.com>

> msg drop for jdk19, Mar 9, 2022

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  removed incorrect translation of compiler configuration file

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7765/files
  - new: https://git.openjdk.java.net/jdk/pull/7765/files/d5c9b884..715a6ad7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=02-03

  Stats: 2310 lines in 3 files changed: 0 ins; 2310 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7765.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765

PR: https://git.openjdk.java.net/jdk/pull/7765


From kizune at openjdk.java.net  Wed Mar 16 18:59:45 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 16 Mar 2022 18:59:45 GMT
Subject: RFR: 8282526: Default icon is not painted properly
In-Reply-To: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
Message-ID: <w8kqU6plRfIVoQ59nyQeu3wC9AgGVZxP2NcXV_1OO7U=.89670c07-6dea-4d0d-bf86-ae491b393a1a@github.com>

On Sun, 13 Mar 2022 21:06:24 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Detect the situation where we do need to perform interpolation during ImageIcon
> painting and set a hint to the rendering to perform bicubic approximation so
> image details are preserved during transition.

The problem is attempt to set it back to null causes NPE. null value means it is not set and there is no method to remove the hint.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7805


From ihse at openjdk.java.net  Wed Mar 16 19:10:03 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Mar 2022 19:10:03 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v6]
In-Reply-To: <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
Message-ID: <l5MgAeu_4rZhm136NUZKKS0NdFXVMHC5GTel88Zq9nw=.4ca070cf-7a6c-4933-9ea0-a665344d1555@github.com>

On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge branch 'master' into shuffle-data-reborn
>  - Fix merge
>  - Merge tag 'jdk-19+13' into shuffle-data-reborn
>    
>    Added tag jdk-19+13 for changeset 5df2a057
>  - Move characterdata templates to share/classes/java/lang.
>  - Update comment refering to "make" dir
>  - Move new symbols to jdk.compiler
>  - Merge branch 'master' into shuffle-data
>  - Move macosxicons from share to macosx
>  - Move to share/data, and move jdwp.spec to java.se
>  - Update references in test
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f

It might be helpful to go to the webrev instead: https://openjdk.github.io/cr/?repo=jdk&pr=1611&range=05

Only the first dozen or so of files has actual changes; the rest are moved files.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1611


From serb at openjdk.java.net  Wed Mar 16 19:31:55 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 16 Mar 2022 19:31:55 GMT
Subject: RFR: 8024624: [TEST_BUG] [macosx] CTRL+RIGHT(LEFT) doesn't move
 selection on next cell in JTable on Aqua L&F
In-Reply-To: <EiCRBqj4DFb-tyhEv8ueKZ9_V7QYeWpdm206oqS12CQ=.00e2fc5c-4eb7-4b2d-b0a8-bbced377d806@github.com>
References: <LdWWDPfwqpCC-_EBaYQLX4rFIyV9FLAG5ugIJb0ruI4=.bc296640-5df9-41a1-b857-14f334c1be8e@github.com>
 <903806783.104456.1647411713894@mail.yahoo.com>
 <EiCRBqj4DFb-tyhEv8ueKZ9_V7QYeWpdm206oqS12CQ=.00e2fc5c-4eb7-4b2d-b0a8-bbced377d806@github.com>
Message-ID: <Q2oa9N5BKz5bK8piW6X1vmGD81zCGxLifJ6xObyYWME=.d29b1a10-835d-4fd2-9c14-5ab109612689@github.com>

On Wed, 16 Mar 2022 18:12:24 GMT, DamonGuy <duke at openjdk.java.net> wrote:

> I see your point. I will update the closed repo changes to exclude macOS from testing to avoid any issues it may cause. Should a separate issue be raised to update [this](https://docs.oracle.com/javase/tutorial/uiswing/components/table.html) doc to mention that macOS isn't included for these key bindings?

As far as I know that doc cannot be updated, see the header of that page.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7792


From serb at openjdk.java.net  Wed Mar 16 20:13:46 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 16 Mar 2022 20:13:46 GMT
Subject: RFR: 8282863:
 java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on
 Windows 10 with HiDPI screen
In-Reply-To: <SogRHLx2pQzRLxpE6FW6BAjwW0qaawCm-A6Ff4Z3N54=.233a4715-0ec7-491a-ba75-c7c3f16b9ee8@github.com>
References: <SogRHLx2pQzRLxpE6FW6BAjwW0qaawCm-A6Ff4Z3N54=.233a4715-0ec7-491a-ba75-c7c3f16b9ee8@github.com>
Message-ID: <4PdC0bYLhXuoTHhdp6XZ4ymDSmgPI6hxS7sww1goemo=.0c1e67f3-1144-4181-a76c-4c847e774d82@github.com>

On Wed, 16 Mar 2022 07:39:21 GMT, Dmitry Kulikov <duke at openjdk.java.net> wrote:

> Hello,
> Please review this fix for JDK-8282863.
> 
> The failing `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test basically checks that full-screen window remains full-screen when a display mode change occurs. It has been introduced in JDK-8211999, which also contains numerous fixes for HiDPI displays. In particular, JDK-8211999 changed the code of `Win32GraphicsDevice.setDisplayMode()` so that it uses screen dimensions in user space instead of device space, which is correct. However, if the display mode change incurs display scaling change, as it has been observed on Windows 10 laptop with HiDPI screen, the method used for obtaining screen bounds in user space returns incorrect values under certain conditions.
> 
> The issue is reproducible on Windows 10, when resolution of the primary screen is higher than 1024x768 with scaling greater than 100%. Resolution and scaling of secondary screen(s) is irrelevant. I used a laptop with 2160x1350 display resolution and scaling set to 150%. When the `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test is run with these initial conditions, roughly the following happens:
> 
> 1. `java.awt.Frame` is created and set as full-screen.
> 2. `Win32GraphicsDevice.setDisplayMode()` is called to change screen resolution from 2160x1350 to 1024x768.
> 3. `Win32GraphicsDevice.configDisplayMode()` call immediately changes the display resolution to 1024x768, which also incurs the immediate display scaling change from 150% to 100%.
> 4. Inside the `Win32GraphicsDevice.setDisplayMode()` screen bounds in user space are obtained via `Win32GraphicsConfig.getBounds()`:
> 5. In the native code of `Win32GraphicsConfig.getBounds()` new screen bounds in device space (1024x768) are correctly obtained via `MonitorBounds()`.
> 6. Then screen bounds are converted to user space by applying **scaling factors, which are not yet updated and correspond to previous display mode**. In our case, 1024x768 is scaled down by 150% and becomes 683x512.
> 7. Back in `Win32GraphicsDevice.setDisplayMode()` full-screen window bounds are set to incorrectly scaled 683x512 instead of 1024x768.
> 8. After returning from `Win32GraphicsDevice.setDisplayMode()` the test waits 4 seconds.
> 9. `WM_DISPLAYCHANGE` message is received and processed, followed by `WM_DPICHANGED`, which updates the scaling factors used by `Win32GraphicsConfig.getBounds()` to the correct value of 100%.
> 10. After 4 seconds test wakes up and obtains screen bounds in user space by calling `Win32GraphicsConfig.getBounds()`, which now correctly returns 1024x768.
> 11. Test compares full-screen window bounds with screen bounds, and fails with `java.lang.RuntimeException: width is wrong` as 683 is not equal to 1024 ? 30 pixels.
> 
> Proposed fix adds a `Win32GraphicsDevice.initScaleFactors()` call to `Win32GraphicsDevice.setDisplayMode()` code, between calling `Win32GraphicsDevice.configDisplayMode()` and `Win32GraphicsConfig.getBounds()`. This updates the scaling factors without waiting for `WM_DISPLAYCHANGE` or `WM_DPICHANGED`, `Win32GraphicsConfig.getBounds()` returns correctly scaled screen bounds in user space, and full-screen window remains correctly sized after display mode change.
> 
> I've run tests from `jdk_awt` group on Windows 10 using a laptop with the same settings that caused the issue (primary screen with 2160x1350 resolution and 150% scaling), and applying the fix did not introduce any new test failures.

Can you please check that this issue cannot be solved similarly to https://bugs.openjdk.java.net/browse/JDK-8232200?
The current fix will work if the java changes the screen resolution, but it won't work if the resolution will be changed by the system/user, so probably reposition of the window in the change listener will work better.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7835


From serb at openjdk.java.net  Wed Mar 16 20:15:43 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 16 Mar 2022 20:15:43 GMT
Subject: RFR: JDK-8283087: Create a test or JDK-4715503 [v2]
In-Reply-To: <--CGwuv4hE9W-Dd1coeg3-wFQpHK4TSv0KW8cnr6tlY=.1cc4e819-6bd3-4c23-bff6-15f4f4bcd4bf@github.com>
References: <EKaHEfjou-QbJWzk5d74cD23a62vFExxy0w7BPkxWho=.a3fad8f0-dfb2-46d1-939b-61bf89d03f24@github.com>
 <--CGwuv4hE9W-Dd1coeg3-wFQpHK4TSv0KW8cnr6tlY=.1cc4e819-6bd3-4c23-bff6-15f4f4bcd4bf@github.com>
Message-ID: <98wFqKtcm6f8ZOblwgL2O4VvBMx2_AzcQXC2fH-gCBg=.36702479-bbb2-41b1-9805-d78f659c5687@github.com>

On Wed, 16 Mar 2022 08:21:26 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a test or [JDK-4715503](https://bugs.openjdk.java.net/browse/JDK-4715503)
>> 
>> The getAccessibleContext method for JTable column header cells returns an
>>  AccessibleContext which cannot get the Bounding Rectangle for table header cells. The Bug causes problems with screen reader review mode.
>> 
>> The test added verifies that the are not exceptions and Bounding rectangles are returned for the Accessible Table Header Cells.
>> 
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: null check added for Bounding Rectangles Returned.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7807


From serb at openjdk.java.net  Wed Mar 16 20:23:47 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 16 Mar 2022 20:23:47 GMT
Subject: RFR: 8282937: Write a regression test for JDK-4820080 [v2]
In-Reply-To: <cmTAZPAtha668RNpdvSbgv3xE7r0zCsbtkmZ8ygE3Zo=.b334607d-5699-4257-9aeb-13fdb3c643ff@github.com>
References: <4bbhbCGRMxaAZkJPXi3B79QCUehtUtB5OuhmtCEm3Vw=.8a6e03c0-3215-48eb-8a6e-9c57cf01b095@github.com>
 <cmTAZPAtha668RNpdvSbgv3xE7r0zCsbtkmZ8ygE3Zo=.b334607d-5699-4257-9aeb-13fdb3c643ff@github.com>
Message-ID: <yvQi1W4amLexDTe7IxwKq5RYUpU6Las1Jr7ZQ-8jqNU=.5174f0f0-4c9a-48e6-90f6-f586274fdbd3@github.com>

On Wed, 16 Mar 2022 10:12:16 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Write a regression test for [JDK-4820080](https://bugs.openjdk.java.net/browse/JDK-4820080) : RFE: Cannot Change the JSplitPane Divider Color while dragging
>> 
>> Issue(as per bug description):
>> I want to change the color of the JSplitPane divider. I
>> opened the code and found that, the color is hard coded to
>> darkGray while one is dragging the splitDivider. I have an
>> application where the components on SplitPane have black
>> background, So when i drag I can not see the split getting
>> dragged. Can some one fix this, by externelising the
>> SplitDivider color so that it can be changed at run time.
>> 
>> Testing:
>> Java 1.4.1 -> Test Failed.
>> $ ./j2sdk1.4.1/bin/java JSplitPaneDragColorTest
>> Metal uses correct drag color false
>> CDE/Motif uses correct drag color false
>> Windows uses correct drag color false
>> Test Failed.
>> 
>> Java 1.5.0 -> Test Failed.
>> $ ./jdk1.5.0/bin/java JSplitPaneDragColorTest
>> Metal uses correct drag color true
>> Windows uses correct drag color true
>> Windows Classic uses correct drag color true
>> Test Passed.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: Formatting changes, split long lines

Looks fine, please confirm that mach5 is green before integration.

-------------

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7803


From aivanov at openjdk.java.net  Wed Mar 16 20:43:47 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 16 Mar 2022 20:43:47 GMT
Subject: RFR: 8276849: Refresh the window icon on graphics configuration
 changes [v4]
In-Reply-To: <elb291CEaz1C9fY4_1Md9urOqwoyoKeaU2LPPyCHBsQ=.ba5e0960-5334-4f55-86a4-062367d4e745@github.com>
References: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
 <0oxxlnAHynu4eIJIE8cMzXJlpU7I_CF1kBk4IYSN3YY=.e8b93bca-4b06-4a70-82db-aa608d6bb350@github.com>
 <elb291CEaz1C9fY4_1Md9urOqwoyoKeaU2LPPyCHBsQ=.ba5e0960-5334-4f55-86a4-062367d4e745@github.com>
Message-ID: <C7MwAEUbaX_NTl3mUU8aLsYRXXxRk0p9_jlrlHGuVds=.13d890ac-7477-41e9-b7fa-0236792d2f92@github.com>

On Wed, 23 Feb 2022 21:34:29 GMT, Emmanuel Bourg <duke at openjdk.java.net> wrote:

>> Emmanuel Bourg has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Test case for the window icon update on DPI change (Java generic font names are usually capitalized)
>>  - Test case for the window icon update on DPI change (dispose the frame after a timeout on the EDT)
>
> Just tested on macOS 12 with a non Retina screen and OpenJDK 8: the icon displayed in the dock when the test frame is minimized is the 32x32 one. If I add more icons to the list, it picks the biggest one, up to 128x128. Bigger icons are ignored.
> 
> The issue observed on Windows doesn't really transpose to macOS, I think I'll revert the change to `LWWindowPeer`.

@ebourg  How did you test on Linux? No icon is displayed in the title bar of the window on Linux Mint and on Ubuntu Linux.

For me, the icon on the taskbar always remains 32, it doesn't look sharp. In the system settings, the size of the icon is set to 48. The icon didn't refresh when I changed the size of the taskbar icon.

At the same time, the icon on the taskbar did animate as if changed when I moved the window from one monitor to another.

Does the set of icons in the test need to be increased to 48? Could it be the reason why on macOS dock the icon doesn't change? I mean there's no a higher resolution icon available.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6180


From aivanov at openjdk.java.net  Wed Mar 16 20:59:45 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 16 Mar 2022 20:59:45 GMT
Subject: RFR: 8282526: Default icon is not painted properly
In-Reply-To: <w8kqU6plRfIVoQ59nyQeu3wC9AgGVZxP2NcXV_1OO7U=.89670c07-6dea-4d0d-bf86-ae491b393a1a@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <w8kqU6plRfIVoQ59nyQeu3wC9AgGVZxP2NcXV_1OO7U=.89670c07-6dea-4d0d-bf86-ae491b393a1a@github.com>
Message-ID: <pGmDkgJjKZLK9z8ZBh0ajS0D7knd67N5yBqM2x-deVc=.52e3eef8-660e-4ad2-a8a5-a4e4c3be4ab3@github.com>

On Wed, 16 Mar 2022 18:56:39 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> The problem is attempt to set it back to null causes NPE. null value means it is not set and there is no method to remove the hint.

If the default value for `KEY_INTERPOLATION` is not `VALUE_INTERPOLATION_NEAREST_NEIGHBOR`, it will be changed to a non-default value after painting the icon. Right?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7805


From kizune at openjdk.java.net  Wed Mar 16 21:03:40 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 16 Mar 2022 21:03:40 GMT
Subject: RFR: 8282526: Default icon is not painted properly
In-Reply-To: <pGmDkgJjKZLK9z8ZBh0ajS0D7knd67N5yBqM2x-deVc=.52e3eef8-660e-4ad2-a8a5-a4e4c3be4ab3@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <w8kqU6plRfIVoQ59nyQeu3wC9AgGVZxP2NcXV_1OO7U=.89670c07-6dea-4d0d-bf86-ae491b393a1a@github.com>
 <pGmDkgJjKZLK9z8ZBh0ajS0D7knd67N5yBqM2x-deVc=.52e3eef8-660e-4ad2-a8a5-a4e4c3be4ab3@github.com>
Message-ID: <nD3jz7nTuzuRTF1_12Bt4zGQUn4hzZiOfS4-ITVIZBY=.984fa1b6-90f0-4015-848b-bcd5c7d11347@github.com>

On Wed, 16 Mar 2022 20:56:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> If the default value for `KEY_INTERPOLATION` is not `VALUE_INTERPOLATION_NEAREST_NEIGHBOR`, it will be changed to a non-default value after painting the icon. Right?

Yes, that code depends on the understanding that if no hint is set than default behavior is as if it set to VALUE_INTERPOLATION_NEAREST_NEIGHBOR. The alternative would be to create a new Graphics, set the hint there and discard that graphics immediately after painting.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7805


From duke at openjdk.java.net  Wed Mar 16 21:17:44 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Wed, 16 Mar 2022 21:17:44 GMT
Subject: RFR: 8282771 : Create test case for JDK-8262981 [v3]
In-Reply-To: <pbRcgoRd0mYiHu3ASOMDqfVCJuyKZsKKSZd3JlguYaM=.0770dc62-36be-42e8-b88e-6425263fd6dd@github.com>
References: <pbRcgoRd0mYiHu3ASOMDqfVCJuyKZsKKSZd3JlguYaM=.0770dc62-36be-42e8-b88e-6425263fd6dd@github.com>
Message-ID: <mt_vo_p7z80juhvjp6uSCtujUVrJxvlRYCgr5FiydOw=.ea947e60-f1ff-4fe8-8e01-c50117c135e2@github.com>

> Following methods are covered in this testcase
> getAccessibleAction()
> getAccessibleActionCount()
> doAccessibleAction(int direction) 
> 
> @shurymury

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  Fixed review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7734/files
  - new: https://git.openjdk.java.net/jdk/pull/7734/files/5caf9a3b..d0fb58df

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7734&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7734&range=01-02

  Stats: 598 lines in 2 files changed: 286 ins; 312 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7734.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7734/head:pull/7734

PR: https://git.openjdk.java.net/jdk/pull/7734


From duke at openjdk.java.net  Wed Mar 16 21:17:45 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Wed, 16 Mar 2022 21:17:45 GMT
Subject: RFR: 8282771 : Create test case for JDK-8262981 [v2]
In-Reply-To: <7EWmVHyewgaJ_TubMRdybp-GmJEtgtaC8jb7ULaJyyU=.6dc08b11-fe05-4c80-b031-a693ed65dbde@github.com>
References: <pbRcgoRd0mYiHu3ASOMDqfVCJuyKZsKKSZd3JlguYaM=.0770dc62-36be-42e8-b88e-6425263fd6dd@github.com>
 <usATVM-CnG-KZiEBBuQyS-D8Muz1H_u6iZvuv3NY-PA=.2a6b01bb-a8e7-4048-851d-4ba6bd129a82@github.com>
 <7EWmVHyewgaJ_TubMRdybp-GmJEtgtaC8jb7ULaJyyU=.6dc08b11-fe05-4c80-b031-a693ed65dbde@github.com>
Message-ID: <ddM7N-un5VueB3NDBiw5g0i5ewCq1WVcRWWoT9BdKWQ=.5dc4cdae-25df-49ff-8c38-cb8bf92aa69b@github.com>

On Wed, 9 Mar 2022 21:36:06 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added command after the date
>
> test/jdk/javax/swing/JSlider/8262981/JSliderAccessibleAction.java line 179:
> 
>> 177:         for (String laf : instLookAndFeels) {
>> 178:             try {
>> 179:                 invalidDecrementCountDownLatch = new CountDownLatch(1);
> 
> these fields are accessed both from EDT and the main test thread

Fixed

> test/jdk/javax/swing/JSlider/8262981/JSliderAccessibleAction.java line 264:
> 
>> 262:                             "Increment button");
>> 263:                 }
>> 264:                 if (jSliderInitialValue.get() != currentJSliderValue.get()) {
> 
> This is  fundamentally unstable. 
> 
> You are clicking on the decrease button. The actual decrease which happened in the slider after the click may be more than you expect. Or less. 
> 
> The only reliable condition perhaps is that the value has decreased and even that may have a delayed effect, so it needs to be waited for. 
> 
> For example see  sanity/client/SwingSet/src/SliderDemoTest.java.

Fixed this by adding addChangeListener to JSlider and updating the currentJSliderValue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7734


From naoto at openjdk.java.net  Wed Mar 16 21:39:02 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 16 Mar 2022 21:39:02 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v6]
In-Reply-To: <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
Message-ID: <uL1qYQhyw-HnhirdQVoQeH4tE13bCIN7DEObzGuCTRw=.5f300302-924b-447f-b075-a07602525e2e@github.com>

On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge branch 'master' into shuffle-data-reborn
>  - Fix merge
>  - Merge tag 'jdk-19+13' into shuffle-data-reborn
>    
>    Added tag jdk-19+13 for changeset 5df2a057
>  - Move characterdata templates to share/classes/java/lang.
>  - Update comment refering to "make" dir
>  - Move new symbols to jdk.compiler
>  - Merge branch 'master' into shuffle-data
>  - Move macosxicons from share to macosx
>  - Move to share/data, and move jdwp.spec to java.se
>  - Update references in test
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f

Looks good, with minor comments. Also I am assuming you will modify the copyright year for these files before the merge.

make/modules/jdk.charsets/Gensrc.gmk line 32:

> 30: # Generate files using the charsetmapping tool
> 31: #
> 32: CHARSET_DATA_DIR := $(TOPDIR)/src/java.base/share/data/charsetmapping

Is it intentional to leave `java.base` literal here, or should it be replaced with `$(MODULE_SRC)`? I see this inconsistency in other tools' `gensrc.gmk` too

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1611


From naoto at openjdk.java.net  Wed Mar 16 21:40:44 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 16 Mar 2022 21:40:44 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v4]
In-Reply-To: <SJQ29Ut1Mvo1_wXVRH6czoCYrkVhBoLSsVr0-wC9H34=.78a2083f-774e-4f4a-97f7-b998a2042c49@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <SJQ29Ut1Mvo1_wXVRH6czoCYrkVhBoLSsVr0-wC9H34=.78a2083f-774e-4f4a-97f7-b998a2042c49@github.com>
Message-ID: <e38JXXFphxIsB3GPU8tMLtEBR2d6nJ52y-1yWWYbA1I=.66a0c141-db54-4f02-8e75-28d9e562c002@github.com>

On Wed, 16 Mar 2022 18:31:55 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed incorrect translation of compiler configuration file

LGTM. Thanks for the change.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7765


From ihse at openjdk.java.net  Wed Mar 16 22:00:02 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Mar 2022 22:00:02 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v6]
In-Reply-To: <uL1qYQhyw-HnhirdQVoQeH4tE13bCIN7DEObzGuCTRw=.5f300302-924b-447f-b075-a07602525e2e@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
 <uL1qYQhyw-HnhirdQVoQeH4tE13bCIN7DEObzGuCTRw=.5f300302-924b-447f-b075-a07602525e2e@github.com>
Message-ID: <xPfvUF9d9MHdd1LV96sZzDSVwFPc38iwJnyzwtOB6e8=.b32d2a07-98ef-4471-8cec-780219f0eaa1@github.com>

On Wed, 16 Mar 2022 21:31:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Merge branch 'master' into shuffle-data-reborn
>>  - Fix merge
>>  - Merge tag 'jdk-19+13' into shuffle-data-reborn
>>    
>>    Added tag jdk-19+13 for changeset 5df2a057
>>  - Move characterdata templates to share/classes/java/lang.
>>  - Update comment refering to "make" dir
>>  - Move new symbols to jdk.compiler
>>  - Merge branch 'master' into shuffle-data
>>  - Move macosxicons from share to macosx
>>  - Move to share/data, and move jdwp.spec to java.se
>>  - Update references in test
>>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f
>
> make/modules/jdk.charsets/Gensrc.gmk line 32:
> 
>> 30: # Generate files using the charsetmapping tool
>> 31: #
>> 32: CHARSET_DATA_DIR := $(TOPDIR)/src/java.base/share/data/charsetmapping
> 
> Is it intentional to leave `java.base` literal here, or should it be replaced with `$(MODULE_SRC)`? I see this inconsistency in other tools' `gensrc.gmk` too

This is part of the weirdness of charsetmapping that Alan talks about. The charsetmapping data is shared between java.base and jdk.charsets in a way that makes it non-trivial to disentangle. 

So this reference to java.base is quite intentional -- replacing it with $(MODULE_SRC) would have pointed to src/jdk.charsets instead of src/java.base, which would have been incorrect.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1611


From naoto at openjdk.java.net  Wed Mar 16 22:04:49 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 16 Mar 2022 22:04:49 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v6]
In-Reply-To: <xPfvUF9d9MHdd1LV96sZzDSVwFPc38iwJnyzwtOB6e8=.b32d2a07-98ef-4471-8cec-780219f0eaa1@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
 <uL1qYQhyw-HnhirdQVoQeH4tE13bCIN7DEObzGuCTRw=.5f300302-924b-447f-b075-a07602525e2e@github.com>
 <xPfvUF9d9MHdd1LV96sZzDSVwFPc38iwJnyzwtOB6e8=.b32d2a07-98ef-4471-8cec-780219f0eaa1@github.com>
Message-ID: <r3Yu_TxywowIeqCXQloQP2bcfc0rJK0cqi9rrrRMEzA=.90371299-a157-4cff-8b98-59ed4c9df1cf@github.com>

On Wed, 16 Mar 2022 21:56:53 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/modules/jdk.charsets/Gensrc.gmk line 32:
>> 
>>> 30: # Generate files using the charsetmapping tool
>>> 31: #
>>> 32: CHARSET_DATA_DIR := $(TOPDIR)/src/java.base/share/data/charsetmapping
>> 
>> Is it intentional to leave `java.base` literal here, or should it be replaced with `$(MODULE_SRC)`? I see this inconsistency in other tools' `gensrc.gmk` too
>
> This is part of the weirdness of charsetmapping that Alan talks about. The charsetmapping data is shared between java.base and jdk.charsets in a way that makes it non-trivial to disentangle. 
> 
> So this reference to java.base is quite intentional -- replacing it with $(MODULE_SRC) would have pointed to src/jdk.charsets instead of src/java.base, which would have been incorrect.

Thanks for reminding me. Then yes, I'd agree with Alan. It'd be much simpler to exclude this from this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1611


From duke at openjdk.java.net  Wed Mar 16 22:05:44 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Wed, 16 Mar 2022 22:05:44 GMT
Subject: RFR: 8278828 : java/awt/a11y/AccessibleTextTest.java's
 createTextArea() just shows instructions on the UI [v3]
In-Reply-To: <HJPkwHFV7VoHACxsVK8kWa-3RcEXMoHNCDNR9mjAlsA=.3dc42967-c43f-454a-9ea3-376a82b49483@github.com>
References: <lUZ_t3uGgmRCL_I4jS_kmf7SBjW9FMFyt8e85GwAe4c=.c7f668a3-96e6-4fb9-9398-efa91fcd8cfc@github.com>
 <x00FxnlfbrZgvR0Qp0qPulsBoR7EJWqIXs8J6hCLu_I=.738661ef-82a4-426e-a19f-7e27a08e2353@github.com>
 <ZOYIQn0OAodE7KQ4BUcoSbc5ajwEAFsZ9W-Aq_d2CtM=.441ae440-4f0a-429f-815b-bc997f129a72@github.com>
 <HJPkwHFV7VoHACxsVK8kWa-3RcEXMoHNCDNR9mjAlsA=.3dc42967-c43f-454a-9ea3-376a82b49483@github.com>
Message-ID: <UpKuwVzudaKIptKSkmQeYIXF4HJu3IAtfh_0_dZBIcE=.5ffdd90d-7931-4f87-8f47-dff799bf1087@github.com>

On Thu, 16 Dec 2021 19:23:10 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> Hi @savoptik, 
>> a) The test createTextArea() does not have JTextArea . I have attached the screen shot of the test https://bugs.openjdk.java.net/browse/JDK-8278828
>> b) The test does not say its a non-editable JTextArea. Even the exception String also say as follows
>> exceptionString = "Simple text area test failed!";  . 
>> c) If user press "Pass" to see the next test then there is no need of  createTextArea() . Correct me if I am wrong?
>
> a) The test createTextArea() does not have JTextArea .
> YES, createTextArea () does not create a JTextArea, but the instruction field itself is not editable JTextArea. Take a look at the AccessibleComponentTest to be sure.
> b) The test does not say its a non-editable JTextArea. Even the exception String also say as follows
> exceptionString = "Simple text area test failed!"; .
> Yes, the instructions do not indicate that this is not an editable JTextArea, you can supplement the instructions. As well as an exception String.
> c) If user press "Pass" to see the next test then there is no need of createTextArea() .
> There is a need.This test tries to cover all cases and possible configurations of various text components: single-line, multi-line, editable, non-editable - and various possible combinations. It is also convenient to use them when developing and debugging native implementations of a11y, for which they were created by me.

I have changed the instruction.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6844


From duke at openjdk.java.net  Wed Mar 16 22:05:44 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Wed, 16 Mar 2022 22:05:44 GMT
Subject: RFR: 8278828 : java/awt/a11y/AccessibleTextTest.java's
 createTextArea() just shows instructions on the UI [v3]
In-Reply-To: <zt7D7C5IRyTxqO-bbcujyfVhQ0hu7GfVmhnksZexL1c=.73182c68-5d94-4360-abea-166dc47b23f2@github.com>
References: <lUZ_t3uGgmRCL_I4jS_kmf7SBjW9FMFyt8e85GwAe4c=.c7f668a3-96e6-4fb9-9398-efa91fcd8cfc@github.com>
 <zt7D7C5IRyTxqO-bbcujyfVhQ0hu7GfVmhnksZexL1c=.73182c68-5d94-4360-abea-166dc47b23f2@github.com>
Message-ID: <SBTUgSLD-PaY1kChfA5-xbj_rQf_MOnbBRwIVvMXQXQ=.784991a3-9601-4a17-b100-dd5ffa169eab@github.com>

On Thu, 27 Jan 2022 21:47:04 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> 1) Test scenario was just showing test instruction with JTextArea. So added the JTextArea as the instruction and method says. 
>> 2) JTextArea is filled with contents so that and an Emoji character making sure that screen reader can read Emoji also.
>> 3) Now user can user arrow keys to navigate the JTextArea and screen reader can read it.
>> 
>> @shurymury 
>> 
>> Attached the screen shot of the test UI which contains JTextArea along with the instruction.
>> <img width="623" alt="Screen Shot 2021-12-14 at 7 09 14 PM" src="https://user-images.githubusercontent.com/87324768/146111187-29f81aab-a138-442d-90bd-df24d512fe01.png">
>
> lawrence.andrews has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into jdk-8278828-ws
>  - Fixed instruction for createTextArea()
>  - Merge branch 'openjdk:master' into jdk-8278828-ws
>  - Added JTextArea createTextArea() in AccessibleTextTest.java

Yes, this is just a instruction change

-------------

PR: https://git.openjdk.java.net/jdk/pull/6844


From ihse at openjdk.java.net  Wed Mar 16 23:53:19 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Mar 2022 23:53:19 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v7]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <XxglJ5kwv5B_DSVjOYKoP_Ero8RuKTf6aSeH4ddyL4w=.19d3461a-df6d-4fe2-b3af-37cd3634510e@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1611/files
  - new: https://git.openjdk.java.net/jdk/pull/1611/files/598f740f..1c91b951

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=05-06

  Stats: 35 lines in 35 files changed: 0 ins; 0 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Thu Mar 17 00:07:53 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 17 Mar 2022 00:07:53 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v8]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <Pp09fmlRR4_79FfeYtzUqD8TTap-zHGwfDmE_9B6UA4=.103348e9-b253-4b85-bb18-0c7315da59de@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Restore charsetmapping and cldr to make/data

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1611/files
  - new: https://git.openjdk.java.net/jdk/pull/1611/files/1c91b951..34bb3c16

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=06-07

  Stats: 5 lines in 1079 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Thu Mar 17 00:12:38 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 17 Mar 2022 00:12:38 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v9]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix typos

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1611/files
  - new: https://git.openjdk.java.net/jdk/pull/1611/files/34bb3c16..b1d1e4d8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=07-08

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

PR: https://git.openjdk.java.net/jdk/pull/1611


From aivanov at openjdk.java.net  Thu Mar 17 00:21:03 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 17 Mar 2022 00:21:03 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v5]
In-Reply-To: <F6o4zlCFWhp6lwZS3avKExKm94xu6chWTlfLZy1Ur0U=.ef89e65a-4b8d-458c-b36a-3e3236fdb950@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <F6o4zlCFWhp6lwZS3avKExKm94xu6chWTlfLZy1Ur0U=.ef89e65a-4b8d-458c-b36a-3e3236fdb950@github.com>
Message-ID: <L1vRGB7-ntpIXCE5PgfCjxEIT7jOwqN8OTLM4tAsHI8=.2d5c1382-2a9d-41ec-aeae-12ee51224e07@github.com>

On Wed, 16 Mar 2022 07:41:32 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> The two tests `ScreenCaptureGtkTest.java` and `HiDPIRobotScreenCaptureTest.java` under `java/awt/Robot/HiDPIScreenCapture` started to intermittently fail under Windows and Linux after the [recent changes](https://github.com/openjdk/jdk/commit/cc7cf81256ed4d74493472017b1c4df20fa2208a) made exclusively for the Linux `Robot` implementation.
>> 
>> `HiDPIRobotScreenCaptureTest.java`
>> Since the Windows failures cannot possibly have their origin in the fix made - the latter being Linux-only - the test apparently either exposes an existing bug in the Windows `Robot` or is bumping against a peculiarity of that platform. The test is reverted back to its original form that didn't fail.
>> 
>> `ScreenCaptureGtkTest.java`
>> The coordinates in the log `(83, 78)` of a failure are higher up than the test suggests `(83, 97)`. I've seen similar failures on Ubuntu 20.04 when the coordinates were set to `(0, 0)`. The color then picked matched the color of the bar drawn at the top of the screen. I believe it's best to place the test pixels towards the center of the window to avoid desktop elements interference.
>> 
>> The other possible reason for intermittent failures are window coordinates. Suppose that the test is executing with `sun.java2d.uiScale` set to 2. This effectively means that it can only pick colors of pixels at even coordinates (in the absolute desktop space). So if the window is placed at, say, `(201, 201)`, `Robot` can only pick the color at either `(200, 200)` or `(202, 202)`. Since the test only makes sense if it is pixel-accurate, I removed all `@run`s with `sun.java2d.uiScale` other than 1. This way window placement will not cause a failure.
>> 
>> This was tested on Ubuntu 20.04 and 18.04 with desktop scaling set to 100%, 200%, and 300%.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverted HiDPIRobotScreenCaptureTest back to 8280861 with minor changes

Let's give a while for Sergey and/or Phil to take a look. If no comments are received by this evening in Europe, I'll sponsor it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From weijun at openjdk.java.net  Thu Mar 17 00:31:11 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 17 Mar 2022 00:31:11 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v9]
In-Reply-To: <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
Message-ID: <Qt1pz_nCJp8pAtbqP7EhgIGA52lOCSX8Si36QLEFnSo=.4f2ad0f6-50aa-49ec-8ebb-7aab0afc0c64@github.com>

On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos

The security-related change looks fine to me

-------------

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Thu Mar 17 00:31:13 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 17 Mar 2022 00:31:13 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <qWfRMXCZQRc38lL3CnICumC8ASqtFw-D52PmWzNXQ_M=.f618debd-e14b-4182-b5b4-be2f01b90817@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <d2m3ofq8QTd7qVrYxhohpEEktBzx_Pah1xcgdsTvlRY=.fd22beda-e27a-485f-b862-46cdb044c24f@github.com>
 <qWfRMXCZQRc38lL3CnICumC8ASqtFw-D52PmWzNXQ_M=.f618debd-e14b-4182-b5b4-be2f01b90817@github.com>
Message-ID: <QEFkbJ80L7Ak_7d7OzzarSIXPKLRQ9B6IYFtGKDumH4=.0d511e63-97cb-451c-b359-ff981aa7df78@github.com>

On Wed, 16 Dec 2020 18:34:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>>> @AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place.
>>> 
>>> I chose to put the data files used for both java.base and the "additional" modules in java.base, based on the comment that Naoto made in https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027044.html:
>>> 
>>> > As to charsetmapping and cldrconverter, I believe they can reside in
>>> > java.base, as jdk.charsets and jdk.localedata modules depend on it.
>>> 
>>> Of course it would be preferable to make a proper split, but that requires work done by the component teams to break the modules apart.
>>> 
>>> Specifically for make/modules/jdk.charsets/Gensrc.gmk; the code in that file is more or less duplicated in make/modules/java.base/gensrc/GensrcCharsetMapping.gmk, since the same data set is processed twice, once for java.base and once for jdk.charsets. I don't think that means that make/modules/jdk.charsets/Gensrc.gmk should move to any other place.
>> 
>> I still stand by what I wrote above. It's best to put data in java.base for charsets/localedata. Otherwise we would have to duplicate some in each modules source directory.
>
>>I also think that the person most qualified to judge about charsetmapping is @naotoj, which has already accepted this review as it is.
> 
> Although I am the current RE for the charsets component, I succeeded it from Alan/Sherman, so I would like to hear Alan's opinion on this.

@naotoj  @AlanBateman I have now rolled back any changes to make/data/cldr and make/data/charsetmapping.

I have also updated copyright years; thanks for reminding me Naoto!

-------------

PR: https://git.openjdk.java.net/jdk/pull/1611


From prr at openjdk.java.net  Thu Mar 17 03:31:18 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 17 Mar 2022 03:31:18 GMT
Subject: RFR: 8274735: javax.imageio.IIOException: Unsupported Image Type while
 processing a valid JPEG image
Message-ID: <gBv_Xtu5bmqpludbJWXwKpgvPCVz4BGYXbjErejjb1A=.cbe35817-d2cb-44bc-9f7b-d2597622623e@github.com>

The JDK's built-in Image I/O JPEG plugin decodes JPEGs which are YCbCr and RGb and Grayscale but rejects CMYK and YCCK JPEGs.
These would correspond to JFIF encapsulated JPEGs.

This was a reasonable decision to limit support to what was actually likely to be seen - CMYK JPEGs probably should just be created for direct to print devices and never seen on the internet as an interchange format.

Indeed this (below) RFC for mail suggests JFIF is what clients should transmit :

https://datatracker.ietf.org/doc/html/rfc2046 :  Multipurpose Internet Mail Extensions - Part 2


   A media type of "image" indicates that the body contains an image.
   The subtype names the specific image format.  These names are not
   case sensitive. An initial subtype is "jpeg" for the JPEG format
   using JFIF encoding [JPEG].

And for many years, browsers either failed to display CMYK JPEGs or displayed them incorrectly.

But alas they do crop up and when they do, Image I/O rejects them - to the surprise and
consternation of some developer who knows little of JPEGs and arcane colour spaces.

Full support of CMYK JPEGs via the whole Image I/O API including proper handling as metadata
will lead us down a path that might even extend into EXIF support for JPEG and likely will
require the JPEG Metadata spec to be updated. 

So the goal here is to skirt that as much as possible by just 
(1) not rejecting read of CMYK JPEGs and returning a BufferedImage with a suitable ColorModel
(2) allowing the same BufferedImage with that ColorSpace to be written back out again as CMYK JPEGs 

Reading will preserve any embedded ICC Color Profile, but writing will not re-encode it since
that requires work on metadata. That will have to be a follow-up fix, but at the very least it
means that a re-written JPEG will benefit from a default treatment CMYK by any other client.

A test is provided which verifies that the colours are interpreted reasonably, both on initial read
and on write and re-read. 

JPEGs with embedded profiles have been tested on read, but since there are licensing issues with those,
the test uses JPEGs which have no embedded profile and depend on an internal implementation class.

That class has its hashCode() method updated because testing showed that toString() invoked hashCode()
in a way that caused a StackOverflowError - so nothing per se to do with this fix but a necessary update.

Anyone who has trustworthy CMYK JPEGs that render properly in (eg) major web browsers but not with this
code can submit those JPEGs so I can evaluate.

But all our automated tests pass as well as some manual testing and evaluation etc.

-------------

Commit messages:
 - 8274735: javax.imageio.IIOException: Unsupported Image Type while processing a valid JPEG image

Changes: https://git.openjdk.java.net/jdk/pull/7849/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7849&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274735
  Stats: 284 lines in 13 files changed: 283 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7849.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7849/head:pull/7849

PR: https://git.openjdk.java.net/jdk/pull/7849


From psadhukhan at openjdk.java.net  Thu Mar 17 04:07:45 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 17 Mar 2022 04:07:45 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v4]
In-Reply-To: <px566UftzNVHlLSDErQ3n9S7ZPQ_6sqMrDjNy6Z_4_Y=.e8381b27-170d-4eee-a4a2-47681573859f@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <px566UftzNVHlLSDErQ3n9S7ZPQ_6sqMrDjNy6Z_4_Y=.e8381b27-170d-4eee-a4a2-47681573859f@github.com>
Message-ID: <LH7L2uxD0VIK3E7XPrJJDsfXHkzsKuX75GmrT2v9qJY=.b565bc88-e4cc-41a7-95de-1cdcda6e9e48@github.com>

On Wed, 16 Mar 2022 06:02:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   korean fallback added

With korean font pack installed, language set to Korean and calling Locale.setDefault(Locale.KOREAN) in testcase, we have
![image](https://user-images.githubusercontent.com/43534309/158734779-78e72fd2-e8e1-4991-a332-cd1624692282.png)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From prr at openjdk.java.net  Thu Mar 17 04:17:33 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 17 Mar 2022 04:17:33 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v4]
In-Reply-To: <LH7L2uxD0VIK3E7XPrJJDsfXHkzsKuX75GmrT2v9qJY=.b565bc88-e4cc-41a7-95de-1cdcda6e9e48@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <px566UftzNVHlLSDErQ3n9S7ZPQ_6sqMrDjNy6Z_4_Y=.e8381b27-170d-4eee-a4a2-47681573859f@github.com>
 <LH7L2uxD0VIK3E7XPrJJDsfXHkzsKuX75GmrT2v9qJY=.b565bc88-e4cc-41a7-95de-1cdcda6e9e48@github.com>
Message-ID: <_7vFYNIBxdW2zX4YMwHQXtvYbj3mEA3raCoh5aePCok=.58a4e54e-96eb-4d8b-b6e3-68ad729c7f87@github.com>

On Thu, 17 Mar 2022 04:03:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> With korean font pack installed, language set to Korean and calling Locale.setDefault(Locale.KOREAN) in testcase, we have
> ![image](https://user-images.githubusercontent.com/43534309/158734779-78e72fd2-e8e1-4991-a332-cd1624692282.png)

And if you revert your entire change and KEEP the Korean font pack ? What does the entire image look like ?
Because both your images look the same .. which isn't what I'd expect.
Basically SHOW there is a difference in one of the fonts that is replaced so I can be sure it is working.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From psadhukhan at openjdk.java.net  Thu Mar 17 05:08:43 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 17 Mar 2022 05:08:43 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v4]
In-Reply-To: <px566UftzNVHlLSDErQ3n9S7ZPQ_6sqMrDjNy6Z_4_Y=.e8381b27-170d-4eee-a4a2-47681573859f@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <px566UftzNVHlLSDErQ3n9S7ZPQ_6sqMrDjNy6Z_4_Y=.e8381b27-170d-4eee-a4a2-47681573859f@github.com>
Message-ID: <XqRLStzhj8pi-G4YXauFEn57h-yqfmINsFnWVEmlm9I=.db861bb8-03ac-41df-9e0c-6b8730d14e27@github.com>

On Wed, 16 Mar 2022 06:02:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   korean fallback added

Without the fix,
![image](https://user-images.githubusercontent.com/43534309/158740896-b0ee2daf-b8c3-4dc9-9f3b-7a1831562a12.png)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From mvs at openjdk.java.net  Thu Mar 17 05:21:36 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Thu, 17 Mar 2022 05:21:36 GMT
Subject: RFR: 8282937: Write a regression test for JDK-4820080 [v2]
In-Reply-To: <yvQi1W4amLexDTe7IxwKq5RYUpU6Las1Jr7ZQ-8jqNU=.5174f0f0-4c9a-48e6-90f6-f586274fdbd3@github.com>
References: <4bbhbCGRMxaAZkJPXi3B79QCUehtUtB5OuhmtCEm3Vw=.8a6e03c0-3215-48eb-8a6e-9c57cf01b095@github.com>
 <cmTAZPAtha668RNpdvSbgv3xE7r0zCsbtkmZ8ygE3Zo=.b334607d-5699-4257-9aeb-13fdb3c643ff@github.com>
 <yvQi1W4amLexDTe7IxwKq5RYUpU6Las1Jr7ZQ-8jqNU=.5174f0f0-4c9a-48e6-90f6-f586274fdbd3@github.com>
Message-ID: <eiOZELQBFt-BCBi3hfs4g8UmAJPaRUMZ6IkGqZ1UqFI=.fe43cd6c-6a1b-4400-8e0e-f4e71197a398@github.com>

On Wed, 16 Mar 2022 20:20:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Looks fine, please confirm that mach5 is green before integration.

Confirmed with Mach5 execution in Linux,Mac and Windows machines(10 times run in each platform) and got all pass.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7803


From prr at openjdk.java.net  Thu Mar 17 05:34:33 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 17 Mar 2022 05:34:33 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v4]
In-Reply-To: <px566UftzNVHlLSDErQ3n9S7ZPQ_6sqMrDjNy6Z_4_Y=.e8381b27-170d-4eee-a4a2-47681573859f@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <px566UftzNVHlLSDErQ3n9S7ZPQ_6sqMrDjNy6Z_4_Y=.e8381b27-170d-4eee-a4a2-47681573859f@github.com>
Message-ID: <5ulNi-_QPg5o95JdB6Og-I_Yryh0eBSg4mi59V-cBpM=.b6d2a12c-6c91-4f6e-b267-720bb844d5ae@github.com>

On Wed, 16 Mar 2022 06:02:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   korean fallback added

First I should say that I am not sure as to what I am seeing is right. It is very weird.
So clearly there is still something wrong with the fix. Some of these should not have changed. You'd see it even more clearly if you labelled each of the pieces of text with the font. I don't know what. I'm out of suggestions. It requires debugging which is beyond the scope of reviewing a proposed fix. So you really need to test it is doing what is expected and "something displays" is not enough. It has to be the expected and right something.
So please do that and come back with something that resolves all these problems.

Surely we can't have been displaying this even if you had the Korean font pack ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From psadhukhan at openjdk.java.net  Thu Mar 17 05:46:50 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 17 Mar 2022 05:46:50 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v4]
In-Reply-To: <XqRLStzhj8pi-G4YXauFEn57h-yqfmINsFnWVEmlm9I=.db861bb8-03ac-41df-9e0c-6b8730d14e27@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <px566UftzNVHlLSDErQ3n9S7ZPQ_6sqMrDjNy6Z_4_Y=.e8381b27-170d-4eee-a4a2-47681573859f@github.com>
 <XqRLStzhj8pi-G4YXauFEn57h-yqfmINsFnWVEmlm9I=.db861bb8-03ac-41df-9e0c-6b8730d14e27@github.com>
Message-ID: <x1EBYbVtjrumkUTvHw-d7wJhX8axvQX4m4iaiDUqces=.e2cbd619-d883-4909-8165-bc591704dab2@github.com>

On Thu, 17 Mar 2022 05:05:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Without the fix, ![image](https://user-images.githubusercontent.com/43534309/158740896-b0ee2daf-b8c3-4dc9-9f3b-7a1831562a12.png)

If I compile the testcase with in-built javac and then run with build jdk, then I get the above image
but if I compile testcase with build javac (as in ./jdk/bin/javac) and then run with build jdk then I get (This is without the change in fontconfig)
![image](https://user-images.githubusercontent.com/43534309/158744766-1cef1101-3738-4315-a421-6069a3840dff.png)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From smandalika at openjdk.java.net  Thu Mar 17 06:48:32 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Thu, 17 Mar 2022 06:48:32 GMT
Subject: RFR: JDK-8283087: Create a test or JDK-4715503 [v2]
In-Reply-To: <98wFqKtcm6f8ZOblwgL2O4VvBMx2_AzcQXC2fH-gCBg=.36702479-bbb2-41b1-9805-d78f659c5687@github.com>
References: <EKaHEfjou-QbJWzk5d74cD23a62vFExxy0w7BPkxWho=.a3fad8f0-dfb2-46d1-939b-61bf89d03f24@github.com>
 <--CGwuv4hE9W-Dd1coeg3-wFQpHK4TSv0KW8cnr6tlY=.1cc4e819-6bd3-4c23-bff6-15f4f4bcd4bf@github.com>
 <98wFqKtcm6f8ZOblwgL2O4VvBMx2_AzcQXC2fH-gCBg=.36702479-bbb2-41b1-9805-d78f659c5687@github.com>
Message-ID: <fwoNvLAErQgB0kU-8J2eG6Q8XQ1E-HOZJH9aG86T5p0=.e786485c-6a61-45a4-8471-c5a88355427a@github.com>

On Wed, 16 Mar 2022 20:12:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments fixed: null check added for Bounding Rectangles Returned.
>
> Marked as reviewed by serb (Reviewer).

@mrserb Can you please sponsor my changes?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7807


From smandalika at openjdk.java.net  Thu Mar 17 07:20:32 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Thu, 17 Mar 2022 07:20:32 GMT
Subject: RFR: JDK-8282046: Create a regression test for JDK-8000326 [v3]
In-Reply-To: <h8OcXU4ZzuDPAR85ywBYRfgCCexY7DoQEKc6c2eQXXM=.935fbc18-b48b-4e33-8e99-3fbb9a4294d3@github.com>
References: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
 <h8OcXU4ZzuDPAR85ywBYRfgCCexY7DoQEKc6c2eQXXM=.935fbc18-b48b-4e33-8e99-3fbb9a4294d3@github.com>
Message-ID: <UHI4LcEF5VVfDBWD5AKGiyGc1sOFO3uR2cdbSr4BhoI=.7fbcec0e-b1bf-4c70-97a3-ac85a242d480@github.com>

On Fri, 11 Mar 2022 14:38:28 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a regression test for CCC8000326
>> 
>> Issue is identified by [JDK-8000326](https://bugs.openjdk.java.net/browse/JDK-8000326), which identifies that after focus moves into JMenuBar, whose focus traversal key is disabled by default, it never moves to other focusable component.
>>  
>> By default, pressing the Tab key does not transfer focus from a JMenuBar which is added to a container together with other Swing components, because the focusTraversalKeysEnabled property of JMenuBar is set to false. To resolve this, you should call the JMenuBar.setFocusTraversalKeysEnabled(true) method.
>>  
>> The test verifies focus traversal for the above described scenario.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added @bug keyword

>
As indicated by the comment [here](https://bugs..openjdk.java.net/browse/JDK-8000326?focusedCommentId=13291129&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13291129) in bug [JDK-8000326](https://bugs.openjdk.java.net/browse/JDK-8000326), the fix in 8-b78 was made not in code but in the docs, to clarify that the failure in focus traversal from Menu Bar to the other components was due to the default false value set to jMenuBar's focusTraversalKeysEnabled and is as expected.

The test is to ensure that with jMenuBar.setFocusTraversalKeysEnabled(true), <Line no 82 in Test> the focus traversal across the components of the the UI is successful.

The test fails in jdk8-b77, jdk8-b78, as well as in latest JDK8u builds with  jMenuBar.setFocusTraversalKeysEnabled(**false**)
The test passes in jdk8-b77, jdk8-b78, as well as in latest JDK8u builds with  jMenuBar.setFocusTraversalKeysEnabled(**true**)
This is the expected behavior.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7512


From smandalika at openjdk.java.net  Thu Mar 17 07:37:29 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Thu, 17 Mar 2022 07:37:29 GMT
Subject: RFR: JDK-8282046: Create a regression test for JDK-8000326 [v4]
In-Reply-To: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
References: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
Message-ID: <BJyw5oT0iEdTeJySKWLv6yAz68v5Ei2t2wglmw6dDrc=.8518af12-f93d-453e-a3c4-874cf180f34b@github.com>

> Create a regression test for CCC8000326
> 
> Issue is identified by [JDK-8000326](https://bugs.openjdk.java.net/browse/JDK-8000326), which identifies that after focus moves into JMenuBar, whose focus traversal key is disabled by default, it never moves to other focusable component.
>  
> By default, pressing the Tab key does not transfer focus from a JMenuBar which is added to a container together with other Swing components, because the focusTraversalKeysEnabled property of JMenuBar is set to false. To resolve this, you should call the JMenuBar.setFocusTraversalKeysEnabled(true) method.
>  
> The test verifies focus traversal for the above described scenario.
> This review is for migrating tests from a closed test suite to open.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Moved the test to the correct location.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7512/files
  - new: https://git.openjdk.java.net/jdk/pull/7512/files/26adac9d..e35945ba

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7512&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7512&range=02-03

  Stats: 107 lines in 1 file changed: 0 ins; 107 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7512.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7512/head:pull/7512

PR: https://git.openjdk.java.net/jdk/pull/7512


From smandalika at openjdk.java.net  Thu Mar 17 08:13:20 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Thu, 17 Mar 2022 08:13:20 GMT
Subject: RFR: JDK-8282046: Create a regression test for JDK-8000326 [v5]
In-Reply-To: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
References: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
Message-ID: <ey8PY92wVdpIi7rFfwPcTb8KERivpiZv6d8rI-LJn5o=.e4e135e4-474a-404c-a4cc-ab0977408fcd@github.com>

> Create a regression test for CCC8000326
> 
> Issue is identified by [JDK-8000326](https://bugs.openjdk.java.net/browse/JDK-8000326), which identifies that after focus moves into JMenuBar, whose focus traversal key is disabled by default, it never moves to other focusable component.
>  
> By default, pressing the Tab key does not transfer focus from a JMenuBar which is added to a container together with other Swing components, because the focusTraversalKeysEnabled property of JMenuBar is set to false. To resolve this, you should call the JMenuBar.setFocusTraversalKeysEnabled(true) method.
>  
> The test verifies focus traversal for the above described scenario.
> This review is for migrating tests from a closed test suite to open.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed: setLocationRelativeTo(), DISPOSE_ON_CLOSE

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7512/files
  - new: https://git.openjdk.java.net/jdk/pull/7512/files/e35945ba..a1ad2f87

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7512&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7512&range=03-04

  Stats: 9 lines in 1 file changed: 1 ins; 4 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7512.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7512/head:pull/7512

PR: https://git.openjdk.java.net/jdk/pull/7512


From smandalika at openjdk.java.net  Thu Mar 17 08:13:21 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Thu, 17 Mar 2022 08:13:21 GMT
Subject: RFR: JDK-8282046: Create a regression test for JDK-8000326 [v3]
In-Reply-To: <LcdplfzUn2U4T6fNkXjvo296996jI5diboM_bDz6CsU=.0b34c522-32a3-44ad-b8ca-b295fea4ef9f@github.com>
References: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
 <h8OcXU4ZzuDPAR85ywBYRfgCCexY7DoQEKc6c2eQXXM=.935fbc18-b48b-4e33-8e99-3fbb9a4294d3@github.com>
 <LcdplfzUn2U4T6fNkXjvo296996jI5diboM_bDz6CsU=.0b34c522-32a3-44ad-b8ca-b295fea4ef9f@github.com>
Message-ID: <O61sAsDzQMnEW9MEZNjABfc2SrOBoBd2J2TT4742ePQ=.a1533892-53ca-417c-b15a-162da2a5fb8a@github.com>

On Wed, 16 Mar 2022 14:47:48 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> You copied the test into the new folder but the old folder still remains. You have to remove it. We don't want two identical tests in different locations.

I have now deleted the duplicate file.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7512


From psadhukhan at openjdk.java.net  Thu Mar 17 09:13:33 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 17 Mar 2022 09:13:33 GMT
Subject: Integrated: 8282473: Refactor swing classes javadoc to use @throws
 instead of @exception
In-Reply-To: <ZEDkB2AsCYNkyACgfH8htOz5VfAZobfGP6KviOHLZhU=.3c93f6f1-2058-4481-a1fb-ed752a2e3746@github.com>
References: <ZEDkB2AsCYNkyACgfH8htOz5VfAZobfGP6KviOHLZhU=.3c93f6f1-2058-4481-a1fb-ed752a2e3746@github.com>
Message-ID: <lMMHOXlfDV4hZKkN8dIMnRkbsLzrLbJyg5XlGrDaGXM=.634bd286-5019-4831-a597-ac2530f800a7@github.com>

On Tue, 1 Mar 2022 10:16:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Prevailing JDK coding practices use "@throws" rather than "@exception".
> Refactor existing swing classes javadoc to use @throws

This pull request has now been integrated.

Changeset: 096bca4a
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/096bca4a9c5e8ac2668dd965df92153ea1d80add
Stats:     533 lines in 114 files changed: 0 ins; 0 del; 533 mod

8282473: Refactor swing classes javadoc to use @throws instead of @exception

Reviewed-by: aivanov, dmarkov, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/7644


From psadhukhan at openjdk.java.net  Thu Mar 17 09:19:36 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 17 Mar 2022 09:19:36 GMT
Subject: Integrated: 8282602: Refactor awt classes javadoc to use @throws
 instead of @exception
In-Reply-To: <FVJL0ITAodybntUy2Ro7w5FmBxCQXDhgEZSckEcpW8o=.f25b6a6a-78b4-4c07-90d6-cb506cd73d87@github.com>
References: <FVJL0ITAodybntUy2Ro7w5FmBxCQXDhgEZSckEcpW8o=.f25b6a6a-78b4-4c07-90d6-cb506cd73d87@github.com>
Message-ID: <YlykKOS4BZPg-Vn5Whw11_qBqQkE70C7lEgtkODfVxg=.af080b91-3c76-48e1-a69f-13f1cda966cd@github.com>

On Thu, 3 Mar 2022 12:26:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Prevailing JDK coding practices use "@throws" rather than "@exception".
> Refactor existing java/awt classes javadoc to use @throws

This pull request has now been integrated.

Changeset: 249d5536
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/249d553659ab75a2271e98c77e7d62f662ffa684
Stats:     350 lines in 73 files changed: 0 ins; 0 del; 350 mod

8282602: Refactor awt classes javadoc to use @throws instead of @exception

Reviewed-by: aivanov, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/7675


From erikj at openjdk.java.net  Thu Mar 17 13:35:35 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 17 Mar 2022 13:35:35 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v9]
In-Reply-To: <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
Message-ID: <ZcrNp87tQwFuc1MKr8cIzCraEmoZ9TT_0L6R-oPo7To=.75b70b2c-b81a-456c-8145-f7d94e79ff58@github.com>

On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1611


From naoto at openjdk.java.net  Thu Mar 17 16:15:30 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 17 Mar 2022 16:15:30 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v9]
In-Reply-To: <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
Message-ID: <FXVfMSGbgAEEf__IzJBLOZFEefOlQbbwE0kMFWOPRbY=.db9b221e-e1b2-4b0f-a74f-b44e576f748a@github.com>

On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos

LGTM. Thanks for the change, Magnus!

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1611


From prr at openjdk.java.net  Thu Mar 17 16:38:36 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 17 Mar 2022 16:38:36 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v4]
In-Reply-To: <px566UftzNVHlLSDErQ3n9S7ZPQ_6sqMrDjNy6Z_4_Y=.e8381b27-170d-4eee-a4a2-47681573859f@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <px566UftzNVHlLSDErQ3n9S7ZPQ_6sqMrDjNy6Z_4_Y=.e8381b27-170d-4eee-a4a2-47681573859f@github.com>
Message-ID: <BFpd2vKxz_mOR7XbdRXzimzjL6U-jt6jsyksvfScirY=.4b92982b-d22e-42bf-833b-04516d917ae5@github.com>

On Wed, 16 Mar 2022 06:02:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   korean fallback added

It seems that the test program is not using \uXXXX unicode escapes but has the characters in some encoding that needs to be expected by javac.
So the first image is from a javac that was using default (eg US) locale and the latter was using a locale that can correctly interpret those.

I don't know why the two are different for you - probably it is a shell environment difference - but I recommend you always use \uXXXX in tests to avoid exactly this issue.

Now looking at the 2nd image it shows that there are differences (although again it would be nice if each line were labelled - eg "Dialog Bold Italic : " ...) and so something is not working as intended.

I don't know what the problem is, so it will require some extensive debugging.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From mvs at openjdk.java.net  Thu Mar 17 16:44:20 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Thu, 17 Mar 2022 16:44:20 GMT
Subject: RFR: 8282548: Create a regression test for JDK-4330998 [v5]
In-Reply-To: <7HqoT6jmH4HyYQUli2v_MDFwkk8BV-e-0uAEFyxBmkI=.735e0071-2c02-423a-9647-9f33a0fedfa4@github.com>
References: <7HqoT6jmH4HyYQUli2v_MDFwkk8BV-e-0uAEFyxBmkI=.735e0071-2c02-423a-9647-9f33a0fedfa4@github.com>
Message-ID: <HHb6yHa5K1GbWZ5I68Rqw9MMDTFLI6IQsLEhqa277g0=.b80aa86a-bfff-4ee2-a851-a5fa89976442@github.com>

> Create a regression test for [JDK-4330998](https://bugs.openjdk.java.net/browse/JDK-4330998)
> Context: Migrating tests from a closed tonga based test suite to open regression based one.
> 
> Issue tested:
> When calling JEditorPane.setText(null), the following exception is thrown:
> 
> java.lang.NullPointerException:
>         at java.io.StringReader.<init>(StringReader.java:38)
> 
> Testing:
> Java 1.4.0 -> Test Failed.
> $ ./j2sdk1.4.0/bin/java bug4330998Win
> java.lang.RuntimeException: Test failed, caught Exception java.lang.NullPointerException when calling text.setText(null)
>         at bug4330998Win.runTest(bug4330998Win.java:45)
>         at bug4330998Win.main(bug4330998Win.java:51)
> Exception in thread "main"
> 
> Java 1.4.1 -> Test Passed.
> $ ./j2sdk1.4.1/bin/java bug4330998Win
> Test passed

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Added a blank line before main()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7740/files
  - new: https://git.openjdk.java.net/jdk/pull/7740/files/03d7475a..954e8f0a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7740&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7740&range=03-04

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7740.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7740/head:pull/7740

PR: https://git.openjdk.java.net/jdk/pull/7740


From psadhukhan at openjdk.java.net  Thu Mar 17 16:46:34 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 17 Mar 2022 16:46:34 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v4]
In-Reply-To: <px566UftzNVHlLSDErQ3n9S7ZPQ_6sqMrDjNy6Z_4_Y=.e8381b27-170d-4eee-a4a2-47681573859f@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <px566UftzNVHlLSDErQ3n9S7ZPQ_6sqMrDjNy6Z_4_Y=.e8381b27-170d-4eee-a4a2-47681573859f@github.com>
Message-ID: <b-svQCCNSB39TH6HQfk0x4fbAsac7TXX6p2oKqNzoQ4=.26215ff8-1258-4ac2-be11-2282a290147c@github.com>

On Wed, 16 Mar 2022 06:02:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   korean fallback added

I was not sure how to use "???" korean (which was there in JBS testcase) in \uXXX unicode so I used
g.drawString("???", 100, 80);

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From serb at openjdk.java.net  Thu Mar 17 17:26:29 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 17 Mar 2022 17:26:29 GMT
Subject: RFR: 8274735: javax.imageio.IIOException: Unsupported Image Type
 while processing a valid JPEG image
In-Reply-To: <gBv_Xtu5bmqpludbJWXwKpgvPCVz4BGYXbjErejjb1A=.cbe35817-d2cb-44bc-9f7b-d2597622623e@github.com>
References: <gBv_Xtu5bmqpludbJWXwKpgvPCVz4BGYXbjErejjb1A=.cbe35817-d2cb-44bc-9f7b-d2597622623e@github.com>
Message-ID: <DKf04VfcDKdkaQe30aIRGPQE4hIi0jzzV_vRaC_QvNQ=.566fc4fa-a6c9-492a-b1a1-7043d9a00483@github.com>

On Thu, 17 Mar 2022 03:23:49 GMT, Phil Race <prr at openjdk.org> wrote:

> The JDK's built-in Image I/O JPEG plugin decodes JPEGs which are YCbCr and RGb and Grayscale but rejects CMYK and YCCK JPEGs.
> These would correspond to JFIF encapsulated JPEGs.
> 
> This was a reasonable decision to limit support to what was actually likely to be seen - CMYK JPEGs probably should just be created for direct to print devices and never seen on the internet as an interchange format.
> 
> Indeed this (below) RFC for mail suggests JFIF is what clients should transmit :
> 
> https://datatracker.ietf.org/doc/html/rfc2046 :  Multipurpose Internet Mail Extensions - Part 2
> 
> 
>    A media type of "image" indicates that the body contains an image.
>    The subtype names the specific image format.  These names are not
>    case sensitive. An initial subtype is "jpeg" for the JPEG format
>    using JFIF encoding [JPEG].
> 
> And for many years, browsers either failed to display CMYK JPEGs or displayed them incorrectly.
> 
> But alas they do crop up and when they do, Image I/O rejects them - to the surprise and
> consternation of some developer who knows little of JPEGs and arcane colour spaces.
> 
> Full support of CMYK JPEGs via the whole Image I/O API including proper handling as metadata
> will lead us down a path that might even extend into EXIF support for JPEG and likely will
> require the JPEG Metadata spec to be updated. 
> 
> So the goal here is to skirt that as much as possible by just 
> (1) not rejecting read of CMYK JPEGs and returning a BufferedImage with a suitable ColorModel
> (2) allowing the same BufferedImage with that ColorSpace to be written back out again as CMYK JPEGs 
> 
> Reading will preserve any embedded ICC Color Profile, but writing will not re-encode it since
> that requires work on metadata. That will have to be a follow-up fix, but at the very least it
> means that a re-written JPEG will benefit from a default treatment CMYK by any other client.
> 
> A test is provided which verifies that the colours are interpreted reasonably, both on initial read
> and on write and re-read. 
> 
> JPEGs with embedded profiles have been tested on read, but since there are licensing issues with those,
> the test uses JPEGs which have no embedded profile and depend on an internal implementation class.
> 
> That class has its hashCode() method updated because testing showed that toString() invoked hashCode()
> in a way that caused a StackOverflowError - so nothing per se to do with this fix but a necessary update.
> 
> Anyone who has trustworthy CMYK JPEGs that render properly in (eg) major web browsers but not with this
> code can submit those JPEGs so I can evaluate.
> 
> But all our automated tests pass as well as some manual testing and evaluation etc.

>Integration blocker
> ?? Failed to retrieve information on issue 8274735. Please make sure it exists and is accessible.

Looks like the JDK-8274735 is closed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7849


From duke at openjdk.java.net  Thu Mar 17 17:59:33 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Thu, 17 Mar 2022 17:59:33 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v3]
In-Reply-To: <9-KCaxc5kvdWS_6nETGIRiJgbTEWTWEPxmKT5JHSphw=.0bf35082-2b55-4cfd-bc7a-636a6d7a721a@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>
 <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>
 <oAZ5tpWpksvN6sfEYoblyucXf_EqcxKAIiVvkvIugjU=.a10e37ec-b8e8-4ac3-9faf-f2a8d85189af@github.com>
 <r9ujiKOC7dRsKCLNjUEt-V8mCstzXKJLFPRQ1O6kqKs=.2b96988b-85c6-45d5-9d95-2e0112b458fb@github.com>
 <AUeNFfcZNdDhRKJExOY7lT7_eG07ZQ_E124iHS_oiVI=.af2824b3-dc46-4318-92c3-27a861269339@github.com>
 <0U4ZvK_ui_ieG7pPZAdhL1AyrJYQNqT0A_HRJIE8InQ=.26f7a810-a6a0-47d0-99d9-e2ffcfebe596@github.com>
 <ML4CSxlvMzInAbk9K0LicDa--V4QlgiUzzL1u7XkJ0s=.d8c7a73c-402a-4813-8fc6-faf9fd07745a@github.com>
 <9-KCaxc5kvdWS_6nETGIRiJgbTEWTWEPxmKT5JHSphw=.0bf35082-2b55-4cfd-bc7a-636a6d7a721a@github.com>
Message-ID: <fYlGXZDTHTU5qaTisZmz9LLOKG7ShMugqXOMGDmiBPY=.b43629cd-7474-48a9-9e0f-3a9729808294@github.com>

On Wed, 16 Mar 2022 07:43:03 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> <img width="1273" alt="Screenshot 2022-03-16 at 1 04 56 PM" src="https://user-images.githubusercontent.com/43534309/158540377-e97cc3c7-64e9-487d-948d-bc1941d5af28.png">
>
> Probably to get an identical focus ring, we need to use
> [NSSetFocusRingStyle](https://developer.apple.com/documentation/appkit/1473702-nssetfocusringstyle?language=objc)

@prsadhuk Thank you for suggesting possible alternatives.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From duke at openjdk.java.net  Thu Mar 17 17:59:33 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Thu, 17 Mar 2022 17:59:33 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v3]
In-Reply-To: <fYlGXZDTHTU5qaTisZmz9LLOKG7ShMugqXOMGDmiBPY=.b43629cd-7474-48a9-9e0f-3a9729808294@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>
 <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>
 <oAZ5tpWpksvN6sfEYoblyucXf_EqcxKAIiVvkvIugjU=.a10e37ec-b8e8-4ac3-9faf-f2a8d85189af@github.com>
 <r9ujiKOC7dRsKCLNjUEt-V8mCstzXKJLFPRQ1O6kqKs=.2b96988b-85c6-45d5-9d95-2e0112b458fb@github.com>
 <AUeNFfcZNdDhRKJExOY7lT7_eG07ZQ_E124iHS_oiVI=.af2824b3-dc46-4318-92c3-27a861269339@github.com>
 <0U4ZvK_ui_ieG7pPZAdhL1AyrJYQNqT0A_HRJIE8InQ=.26f7a810-a6a0-47d0-99d9-e2ffcfebe596@github.com>
 <ML4CSxlvMzInAbk9K0LicDa--V4QlgiUzzL1u7XkJ0s=.d8c7a73c-402a-4813-8fc6-faf9fd07745a@github.com>
 <9-KCaxc5kvdWS_6nETGIRiJgbTEWTWEPxmKT5JHSphw=.0bf35082-2b55-4cfd-bc7a-636a6d7a721a@github.com>
 <fYlGXZDTHTU5qaTisZmz9LLOKG7ShMugqXOMGDmiBPY=.b43629cd-7474-48a9-9e0f-3a9729808294@github.com>
Message-ID: <-k8sDdAZltd4AcDIIOeKBcKLZ4q9XuTs6sT5Mmg2Q9I=.025a647c-34a7-478b-912d-7bfd4a7473b4@github.com>

On Thu, 17 Mar 2022 17:54:41 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> Probably to get an identical focus ring, we need to use
>> [NSSetFocusRingStyle](https://developer.apple.com/documentation/appkit/1473702-nssetfocusringstyle?language=objc)
>
> @prsadhuk Thank you for suggesting possible alternatives.

There are two different approaches that we can take at this point.

1. Do we go forward with the present changes? (hue and saturation offset, brightness set to 100%) 
2. Keep a common cell focus ring color - Blue as observed in few native apps (Numbers App). In this scenario we keep the cell focus ring color set to blue when selection background color is NOT blue and return a different color when selection background is Blue.

Trying to find the best solution that takes into account native L&F and present Aqua L&F implementations.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From duke at openjdk.java.net  Thu Mar 17 18:11:33 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Thu, 17 Mar 2022 18:11:33 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v3]
In-Reply-To: <-k8sDdAZltd4AcDIIOeKBcKLZ4q9XuTs6sT5Mmg2Q9I=.025a647c-34a7-478b-912d-7bfd4a7473b4@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>
 <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>
 <oAZ5tpWpksvN6sfEYoblyucXf_EqcxKAIiVvkvIugjU=.a10e37ec-b8e8-4ac3-9faf-f2a8d85189af@github.com>
 <r9ujiKOC7dRsKCLNjUEt-V8mCstzXKJLFPRQ1O6kqKs=.2b96988b-85c6-45d5-9d95-2e0112b458fb@github.com>
 <AUeNFfcZNdDhRKJExOY7lT7_eG07ZQ_E124iHS_oiVI=.af2824b3-dc46-4318-92c3-27a861269339@github.com>
 <0U4ZvK_ui_ieG7pPZAdhL1AyrJYQNqT0A_HRJIE8InQ=.26f7a810-a6a0-47d0-99d9-e2ffcfebe596@github.com>
 <ML4CSxlvMzInAbk9K0LicDa--V4QlgiUzzL1u7XkJ0s=.d8c7a73c-402a-4813-8fc6-faf9fd07745a@github.com>
 <9-KCaxc5kvdWS_6nETGIRiJgbTEWTWEPxmKT5JHSphw=.0bf35082-2b55-4cfd-bc7a-636a6d7a721a@github.com>
 <fYlGXZDTHTU5qaTisZmz9LLOKG7ShMugqXOMGDmiBPY=.b43629cd-7474-48a9-9e0f-3a9729808294@github.com>
 <-k8sDdAZltd4AcDIIOeKBcKLZ4q9XuTs6sT
 5Mmg2Q9I=.025a647c-34a7-478b-912d-7bfd4a7473b4@github.com>
Message-ID: <AI90_XpQ47CeM9u1p7brUJMBFddpJgfVXFfBZIYtGfw=.7489df4f-b643-4d9e-b1dd-b15ba1b6a1ad@github.com>

On Thu, 17 Mar 2022 17:56:03 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> @prsadhuk Thank you for suggesting possible alternatives.
>
> There are two different approaches that we can take at this point.
> 
> 1. Do we go forward with the present changes? (hue and saturation offset, brightness set to 100%) 
> 2. Keep a common cell focus ring color - Blue as observed in few native apps (Numbers App). In this scenario we keep the cell focus ring color set to blue when selection background color is NOT blue and return a different color when selection background is Blue.
> 
> Trying to find the best solution that takes into account native L&F and present Aqua L&F implementations.

> Probably to get an identical focus ring, we need to use [NSSetFocusRingStyle](https://developer.apple.com/documentation/appkit/1473702-nssetfocusringstyle?language=objc)

This is more about placement of the focus ring (and available only from macOS 10.1+ versions) and would require native code changes. Might not be an ideal solution in this context.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From prr at openjdk.java.net  Thu Mar 17 18:36:33 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 17 Mar 2022 18:36:33 GMT
Subject: RFR: 8274735: javax.imageio.IIOException: Unsupported Image Type
 while processing a valid JPEG image
In-Reply-To: <DKf04VfcDKdkaQe30aIRGPQE4hIi0jzzV_vRaC_QvNQ=.566fc4fa-a6c9-492a-b1a1-7043d9a00483@github.com>
References: <gBv_Xtu5bmqpludbJWXwKpgvPCVz4BGYXbjErejjb1A=.cbe35817-d2cb-44bc-9f7b-d2597622623e@github.com>
 <DKf04VfcDKdkaQe30aIRGPQE4hIi0jzzV_vRaC_QvNQ=.566fc4fa-a6c9-492a-b1a1-7043d9a00483@github.com>
Message-ID: <NQ7K4SZE2O-9jcVEioRmk7paOErYgab6VCO8juDopdw=.974f4f89-c985-4833-8a19-0409ec8f2d25@github.com>

On Thu, 17 Mar 2022 17:23:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Integration blocker
> > ?? Failed to retrieve information on issue 8274735. Please make sure it exists and is accessible.
> 
> Looks like the JDK-8274735 is closed.

Hmm it had been closed as a dup of 5100094 but that is about full support so I re-opened 8274735 before sending out the PR.
My emal log shows I re-opened it 9 minuutes before sending out the PR .. so skara must not be looking at the current database state .. I also realised you couldn't see it was open since the bug was not public. I've fixed that.

Since your comment didn't wake up skara I may have to try a /issue comment

-------------

PR: https://git.openjdk.java.net/jdk/pull/7849


From prr at openjdk.java.net  Thu Mar 17 20:42:32 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 17 Mar 2022 20:42:32 GMT
Subject: RFR: 8282863:
 java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on
 Windows 10 with HiDPI screen
In-Reply-To: <SogRHLx2pQzRLxpE6FW6BAjwW0qaawCm-A6Ff4Z3N54=.233a4715-0ec7-491a-ba75-c7c3f16b9ee8@github.com>
References: <SogRHLx2pQzRLxpE6FW6BAjwW0qaawCm-A6Ff4Z3N54=.233a4715-0ec7-491a-ba75-c7c3f16b9ee8@github.com>
Message-ID: <2WQOCUZLMZfCML3Xx6tRmbRj761oQ0A2SIi1OgaJR98=.3fde25a6-a6a0-442c-ac7f-6ad97c9d13b5@github.com>

On Wed, 16 Mar 2022 07:39:21 GMT, Dmitry Kulikov <duke at openjdk.java.net> wrote:

> Hello,
> Please review this fix for JDK-8282863.
> 
> The failing `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test basically checks that full-screen window remains full-screen when a display mode change occurs. It has been introduced in JDK-8211999, which also contains numerous fixes for HiDPI displays. In particular, JDK-8211999 changed the code of `Win32GraphicsDevice.setDisplayMode()` so that it uses screen dimensions in user space instead of device space, which is correct. However, if the display mode change incurs display scaling change, as it has been observed on Windows 10 laptop with HiDPI screen, the method used for obtaining screen bounds in user space returns incorrect values under certain conditions.
> 
> The issue is reproducible on Windows 10, when resolution of the primary screen is higher than 1024x768 with scaling greater than 100%. Resolution and scaling of secondary screen(s) is irrelevant. I used a laptop with 2160x1350 display resolution and scaling set to 150%. When the `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test is run with these initial conditions, roughly the following happens:
> 
> 1. `java.awt.Frame` is created and set as full-screen.
> 2. `Win32GraphicsDevice.setDisplayMode()` is called to change screen resolution from 2160x1350 to 1024x768.
> 3. `Win32GraphicsDevice.configDisplayMode()` call immediately changes the display resolution to 1024x768, which also incurs the immediate display scaling change from 150% to 100%.
> 4. Inside the `Win32GraphicsDevice.setDisplayMode()` screen bounds in user space are obtained via `Win32GraphicsConfig.getBounds()`:
> 5. In the native code of `Win32GraphicsConfig.getBounds()` new screen bounds in device space (1024x768) are correctly obtained via `MonitorBounds()`.
> 6. Then screen bounds are converted to user space by applying **scaling factors, which are not yet updated and correspond to previous display mode**. In our case, 1024x768 is scaled down by 150% and becomes 683x512.
> 7. Back in `Win32GraphicsDevice.setDisplayMode()` full-screen window bounds are set to incorrectly scaled 683x512 instead of 1024x768.
> 8. After returning from `Win32GraphicsDevice.setDisplayMode()` the test waits 4 seconds.
> 9. `WM_DISPLAYCHANGE` message is received and processed, followed by `WM_DPICHANGED`, which updates the scaling factors used by `Win32GraphicsConfig.getBounds()` to the correct value of 100%.
> 10. After 4 seconds test wakes up and obtains screen bounds in user space by calling `Win32GraphicsConfig.getBounds()`, which now correctly returns 1024x768.
> 11. Test compares full-screen window bounds with screen bounds, and fails with `java.lang.RuntimeException: width is wrong` as 683 is not equal to 1024 ? 30 pixels.
> 
> Proposed fix adds a `Win32GraphicsDevice.initScaleFactors()` call to `Win32GraphicsDevice.setDisplayMode()` code, between calling `Win32GraphicsDevice.configDisplayMode()` and `Win32GraphicsConfig.getBounds()`. This updates the scaling factors without waiting for `WM_DISPLAYCHANGE` or `WM_DPICHANGED`, `Win32GraphicsConfig.getBounds()` returns correctly scaled screen bounds in user space, and full-screen window remains correctly sized after display mode change.
> 
> I've run tests from `jdk_awt` group on Windows 10 using a laptop with the same settings that caused the issue (primary screen with 2160x1350 resolution and 150% scaling), and applying the fix did not introduce any new test failures.

src/java.desktop/windows/classes/sun/awt/Win32GraphicsDevice.java line 470:

> 468:             // otherwise getDefaultConfiguration().getBounds() will return incorrect results until
> 469:             // WM_DISPLAYCHANGE or WM_DPICHANGED is received, which happens to be too late for our purposes
> 470:             initScaleFactors();

So WM_DISPLAYCHANGE message is received and processed, followed by WM_DPICHANGED, which updates the scaling factors used by Win32GraphicsConfig.getBounds() to the correct value of 100%."

causes Win32GraphicsDevice.displayChanged() to be called, which makes the update, but too late.

Is there anything else that method does which is being done too late ?

Do we still need the call to initScaleFactors() in Win32GraphicsDevice.displayChanged() ?

And can you reduce the line length of all these comments to <= 80 chars

PS .. can we add this bug id to the @bug list of the test ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7835


From prr at openjdk.java.net  Thu Mar 17 20:50:35 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 17 Mar 2022 20:50:35 GMT
Subject: RFR: 8283217: Leak FcObjectSet in getFontConfigLocations() in
 fontpath.c [v2]
In-Reply-To: <YhIvt5k1ZBzVgVSjhZShELHLLR6Y3j_mH40iY6j9aU8=.0b35b045-6d77-4489-aea0-75c67c74dee9@github.com>
References: <1VS7SH0RB3qQDRunQQ8s3xp6CNYpCrHX6u5KlH6LWMU=.8d5ad8cc-f5de-4099-a4d3-f1b90a44e6c5@github.com>
 <YhIvt5k1ZBzVgVSjhZShELHLLR6Y3j_mH40iY6j9aU8=.0b35b045-6d77-4489-aea0-75c67c74dee9@github.com>
Message-ID: <TX42gECE8Ktd0nNA1g3NSl8W2BKfpiQRBHL7Kt2dWrE=.55d9b17c-862c-4f0a-9c50-0fe8036b03d3@github.com>

On Wed, 16 Mar 2022 01:05:19 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review this small patch to fix leaking of `FcObjectSet` in  `getFontConfigLocations()`
>> 
>> 
>> Test:
>> - [x]  jdk_2d
>
> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8283217-destroy-FcObjectSet
>  - v0

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7826


From prr at openjdk.java.net  Thu Mar 17 21:59:33 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 17 Mar 2022 21:59:33 GMT
Subject: RFR: 8282526: Default icon is not painted properly
In-Reply-To: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
Message-ID: <ob6enjzx9DmO98H5XHP0w2ND4ZYZEQpJuJoBtr2yrFI=.6466a37d-4cb2-4777-a3ad-dfc71cc01d9e@github.com>

On Sun, 13 Mar 2022 21:06:24 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Detect the situation where we do need to perform interpolation during ImageIcon
> painting and set a hint to the rendering to perform bicubic approximation so
> image details are preserved during transition.

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 463:

> 461:         if (hintChanged) {
> 462:             ((Graphics2D) g).setRenderingHint(RenderingHints.KEY_INTERPOLATION,
> 463:                     oldHint == null ? RenderingHints.VALUE_INTERPOLATION_NEAREST_NEIGHBOR : oldHint);

So this is one of only two hints which do not have an "_DEFAULT" value. I don't know why it doesn't.

Not authoritative but the only place where we currently set this hint and then restore it is here
share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java
                Object oldScaleingHints = g.getRenderingHint(RenderingHints.KEY_INTERPOLATION);
                g.setRenderingHint(RenderingHints.KEY_INTERPOLATION,RenderingHints.VALUE_INTERPOLATION_BILINEAR);
                ImageScalingHelper.paint(g, 0, 0, w, h, img, insets, dstInsets,
                        ImageScalingHelper.PaintType.PAINT9_STRETCH, ImageScalingHelper.PAINT_ALL);
                g.setRenderingHint(RenderingHints.KEY_INTERPOLATION,
                    oldScaleingHints!=null?oldScaleingHints:RenderingHints.VALUE_INTERPOLATION_NEAREST_NEIGHBOR);

if the get() returns null and you aren't happy with that then creating a new Graphics is the only alternative I see.


But it seems to me there are bigger problems to resolve first

> Image variant = ((MultiResolutionImage) image).getResolutionVariant(this.width, this.height);

So getResolutionVariant wants image pixels, but I expect ImageIcon is sized in user-space, isn't it ?

Don't you need to apply the scale from the Graphics ?

Next, if we have an exact match for what we want, why  do we need the hint ?

Next, as Sergey mentions, BICUBIC is expensive.
Probably how  that should be used is to redraw the image into a cached image that
is dw= iw*sx and dh= iwh*sy where sx and sy are the graphics scale
and that is the graphics on which you apply the hint and the graphics is disposed and the restore issue vanishes

then you can just blit that resulting image so long as the cached dw x dy isn't changed.

The MR is still useful for finding the best starting image

-------------

PR: https://git.openjdk.java.net/jdk/pull/7805


From duke at openjdk.java.net  Thu Mar 17 22:01:57 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 17 Mar 2022 22:01:57 GMT
Subject: RFR: 8270331 : [TESTBUG] Error: Not a test or directory containing
 tests: java/awt/print/PrinterJob/InitToBlack.java
Message-ID: <ILihQKqFsB85AIFHTbJK1Im9hB60SJ_OJzDgdUB1dbg=.bf0f4b07-fd40-4eca-b2eb-e5f38b311d72@github.com>

1) Removed =yesno since it was throwing Error: Not a test or directory containing tests
2) Test was just printing the "Test passes" on the printer and user did not had any option to mark the test as pass or fail and test was always passing. so created test UI with test instruction and test controls to mark the test pass or fail and checking the end result of the test.

@shurymury

-------------

Commit messages:
 - 8270331 : [TESTBUG] Error: Not a test or directory containing tests: java/awt/print/PrinterJob/InitToBlack.java
 - [TESTBUG] Error: Not a test or directory containing tests: java/awt/print/PrinterJob/InitToBlack.java

Changes: https://git.openjdk.java.net/jdk/pull/7860/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7860&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8270331
  Stats: 131 lines in 1 file changed: 116 ins; 0 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7860.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7860/head:pull/7860

PR: https://git.openjdk.java.net/jdk/pull/7860


From achung at openjdk.java.net  Thu Mar 17 22:35:35 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Thu, 17 Mar 2022 22:35:35 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v3]
In-Reply-To: <HYjNkqqcwMFOo-6mM2Q_4-1B5ePKD3-DRICoaF_1-bA=.53f59ac5-02f8-4c57-924c-40d22a760db1@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <HYjNkqqcwMFOo-6mM2Q_4-1B5ePKD3-DRICoaF_1-bA=.53f59ac5-02f8-4c57-924c-40d22a760db1@github.com>
Message-ID: <CdHYL_6LtcH1pzkP_C_KG_pU7WCl22uAc8Jy8beFpqM=.4200ea14-26a8-463c-a8be-7ae8d245d854@github.com>

On Mon, 14 Mar 2022 16:15:47 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added functions for drawing border, fixed translate

Here's how it looks (150%)
![image](https://user-images.githubusercontent.com/90066231/158905013-fd69d995-66da-4568-943a-de1ba8068e70.png)
Thoughts?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From achung at openjdk.java.net  Thu Mar 17 22:49:13 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Thu, 17 Mar 2022 22:49:13 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v4]
In-Reply-To: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
Message-ID: <XDHs6Py3_7tTx-vH5s1iD73_Xs5-U4KHsQETZu1I_qM=.e92af91a-4773-49a9-8f36-0797a587ae8a@github.com>

> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  changed approach to render border without transforms

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7449/files
  - new: https://git.openjdk.java.net/jdk/pull/7449/files/7b7732f8..06ac18d4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=02-03

  Stats: 33 lines in 1 file changed: 19 ins; 7 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7449.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7449/head:pull/7449

PR: https://git.openjdk.java.net/jdk/pull/7449


From achung at openjdk.java.net  Thu Mar 17 23:45:13 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Thu, 17 Mar 2022 23:45:13 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v5]
In-Reply-To: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
Message-ID: <DkQSVv4zg1NL5ODw9Dvdyqj-pFeBlK-D4egpjIWwFGg=.3d637c13-ca37-4bb7-ba04-3dbe9f229d3b@github.com>

> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  updated test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7449/files
  - new: https://git.openjdk.java.net/jdk/pull/7449/files/06ac18d4..3ecaf58f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=03-04

  Stats: 57 lines in 1 file changed: 39 ins; 1 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7449.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7449/head:pull/7449

PR: https://git.openjdk.java.net/jdk/pull/7449


From achung at openjdk.java.net  Thu Mar 17 23:50:21 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Thu, 17 Mar 2022 23:50:21 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v6]
In-Reply-To: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
Message-ID: <oc9A9PE5Mq_o16sPjsdgoqc2pGkAoEFft02Ee1jlA38=.f39df329-8872-445e-9fa8-8c4c3e289677@github.com>

> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  fixed apostrophe in comment of saveImage

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7449/files
  - new: https://git.openjdk.java.net/jdk/pull/7449/files/3ecaf58f..75ec24d4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7449.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7449/head:pull/7449

PR: https://git.openjdk.java.net/jdk/pull/7449


From duke at openjdk.java.net  Fri Mar 18 02:26:30 2022
From: duke at openjdk.java.net (lukeu)
Date: Fri, 18 Mar 2022 02:26:30 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v6]
In-Reply-To: <oc9A9PE5Mq_o16sPjsdgoqc2pGkAoEFft02Ee1jlA38=.f39df329-8872-445e-9fa8-8c4c3e289677@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oc9A9PE5Mq_o16sPjsdgoqc2pGkAoEFft02Ee1jlA38=.f39df329-8872-445e-9fa8-8c4c3e289677@github.com>
Message-ID: <LeCAIN50_WVZAIoW9lp6hdocBnDNMPYqxaY_1AsJwdM=.97ead633-8dc6-4f91-848c-8a3905300d5a@github.com>

On Thu, 17 Mar 2022 23:50:21 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed apostrophe in comment of saveImage

The rendering looks good to me now at 100%..175%.

When I look at this natively on my 4k laptop monitor @ 300% scaling though, the single-pixel lines are very thin and faint. Imagine the following image shrunk 3x smaller, for how I see it:

![JDK-8279614-patch2-scaling_300-zoom_x1](https://user-images.githubusercontent.com/2722420/158920127-8de7f1ed-3973-423e-b8ca-8fbc7b725057.png)

Notice how the black borders of the checkboxes have increased to 3px wide at this scaling level? I think the TitledBorder would look nicer doing similarly, i.e.: 
 * 2px width lines for [200% .. 300%)
 * 3px width lines for [300% .. 400%)
etc.

The border lines also look further off-center with respect to the text at these higher scaling levels. However if the lines are made fatter keeping at the same topmost pixel position then I _think_ (just eye-balling it) that will also resolve this issue.

(I guess this could raise a question of how the "etched" effect should be rendered at higher resolutions: Should some of the light lines have diagonal endings, extending the simplistic "lighting modal" that the etched style is supposed to represent? Or is it fine to just keep all lines square-ended, literally just zooming the original pixel-art-style borders? Personally, I'm fine with the latter.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From duke at openjdk.java.net  Fri Mar 18 06:11:28 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Fri, 18 Mar 2022 06:11:28 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v5]
In-Reply-To: <L1vRGB7-ntpIXCE5PgfCjxEIT7jOwqN8OTLM4tAsHI8=.2d5c1382-2a9d-41ec-aeae-12ee51224e07@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <F6o4zlCFWhp6lwZS3avKExKm94xu6chWTlfLZy1Ur0U=.ef89e65a-4b8d-458c-b36a-3e3236fdb950@github.com>
 <L1vRGB7-ntpIXCE5PgfCjxEIT7jOwqN8OTLM4tAsHI8=.2d5c1382-2a9d-41ec-aeae-12ee51224e07@github.com>
Message-ID: <tbj_yHlmrBOzP0N4JetfK-lLK5I-jmM6QcxqBIzKuZo=.56b9b186-3829-4561-91f6-334da6a39429@github.com>

On Wed, 16 Mar 2022 13:41:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reverted HiDPIRobotScreenCaptureTest back to 8280861 with minor changes
>
> Let's give a while for Sergey and/or Phil to take a look. If no comments are received by this evening in Europe, I'll sponsor it.

@aivanov-jdk ping

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From alanb at openjdk.java.net  Fri Mar 18 10:03:39 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 18 Mar 2022 10:03:39 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v9]
In-Reply-To: <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
Message-ID: <iaSVWMoy7XUxSHuU16EAsolpikohce17N2tOYMrI278=.5c8253db-c812-47c0-8d0b-b9ebc419175f@github.com>

On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos

Thanks for dropping the charset and locale data from the proposal. The updated proposal (b1d1e4d8) looks okay but I can't tell if you are planning to integrate this or wait until there is discussion on the locations proposed in the Informational JEP that you've just submitted. Maybe you plan to just integrate and then adjust/move again if needed? I suspect that JEP will need to includes a "specs" directory. It's okay to jdwp.spec into the java.se "data" directory for now I think "specs" would be a bette place for it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1611


From magnus.ihse.bursie at oracle.com  Fri Mar 18 14:13:58 2022
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 18 Mar 2022 14:13:58 +0000
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v9]
In-Reply-To: <iaSVWMoy7XUxSHuU16EAsolpikohce17N2tOYMrI278=.5c8253db-c812-47c0-8d0b-b9ebc419175f@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
 <iaSVWMoy7XUxSHuU16EAsolpikohce17N2tOYMrI278=.5c8253db-c812-47c0-8d0b-b9ebc419175f@github.com>
Message-ID: <62193BC0-B3FC-43E9-A65D-387708D85B3D@oracle.com>


> 18 mars 2022 kl. 11:04 skrev Alan Bateman <alanb at openjdk.java.net>:
> 
> I can't tell if you are planning to integrate this or wait until there is discussion on the locations proposed in the Informational JEP that you've just submitted. Maybe you plan to just integrate and then adjust/move again if needed?

I am *not* planning to wait for the JEP. (My perhaps cynical prediction is that it will be treated as a low-priority, bike-shedding playground which is unlikely to progress to its final stage for a year or so?)

The point of the informational JEP is that it is a living document. If the code changes, we can update the JEP. The JEP as it stands right now describes the code base as it will look when this PR is integrated. 

And yes, I?m open for more updates/changes in the future if we find the need. Things like code structure is something which we impose on the source code to be helpful. If it works against our best interests, we need to change it. And sometimes it?s hard to get things right the first time around. 

/Magnus


From duke at openjdk.java.net  Fri Mar 18 15:49:32 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Fri, 18 Mar 2022 15:49:32 GMT
Subject: RFR: 8274735: javax.imageio.IIOException: Unsupported Image Type
 while processing a valid JPEG image
In-Reply-To: <gBv_Xtu5bmqpludbJWXwKpgvPCVz4BGYXbjErejjb1A=.cbe35817-d2cb-44bc-9f7b-d2597622623e@github.com>
References: <gBv_Xtu5bmqpludbJWXwKpgvPCVz4BGYXbjErejjb1A=.cbe35817-d2cb-44bc-9f7b-d2597622623e@github.com>
Message-ID: <GJ9r4HEaApcqSWFwbKt9rNMDC8yJnOJqwvuPGl6Sbk8=.239055aa-60ab-4f4c-9f42-82222cb642ef@github.com>

On Thu, 17 Mar 2022 03:23:49 GMT, Phil Race <prr at openjdk.org> wrote:

> The JDK's built-in Image I/O JPEG plugin decodes JPEGs which are YCbCr and RGb and Grayscale but rejects CMYK and YCCK JPEGs.
> These would correspond to JFIF encapsulated JPEGs.
> 
> This was a reasonable decision to limit support to what was actually likely to be seen - CMYK JPEGs probably should just be created for direct to print devices and never seen on the internet as an interchange format.
> 
> Indeed this (below) RFC for mail suggests JFIF is what clients should transmit :
> 
> https://datatracker.ietf.org/doc/html/rfc2046 :  Multipurpose Internet Mail Extensions - Part 2
> 
> 
>    A media type of "image" indicates that the body contains an image.
>    The subtype names the specific image format.  These names are not
>    case sensitive. An initial subtype is "jpeg" for the JPEG format
>    using JFIF encoding [JPEG].
> 
> And for many years, browsers either failed to display CMYK JPEGs or displayed them incorrectly.
> 
> But alas they do crop up and when they do, Image I/O rejects them - to the surprise and
> consternation of some developer who knows little of JPEGs and arcane colour spaces.
> 
> Full support of CMYK JPEGs via the whole Image I/O API including proper handling as metadata
> will lead us down a path that might even extend into EXIF support for JPEG and likely will
> require the JPEG Metadata spec to be updated. 
> 
> So the goal here is to skirt that as much as possible by just 
> (1) not rejecting read of CMYK JPEGs and returning a BufferedImage with a suitable ColorModel
> (2) allowing the same BufferedImage with that ColorSpace to be written back out again as CMYK JPEGs 
> 
> Reading will preserve any embedded ICC Color Profile, but writing will not re-encode it since
> that requires work on metadata. That will have to be a follow-up fix, but at the very least it
> means that a re-written JPEG will benefit from a default treatment CMYK by any other client.
> 
> A test is provided which verifies that the colours are interpreted reasonably, both on initial read
> and on write and re-read. 
> 
> JPEGs with embedded profiles have been tested on read, but since there are licensing issues with those,
> the test uses JPEGs which have no embedded profile and depend on an internal implementation class.
> 
> That class has its hashCode() method updated because testing showed that toString() invoked hashCode()
> in a way that caused a StackOverflowError - so nothing per se to do with this fix but a necessary update.
> 
> Anyone who has trustworthy CMYK JPEGs that render properly in (eg) major web browsers but not with this
> code can submit those JPEGs so I can evaluate.
> 
> But all our automated tests pass as well as some manual testing and evaluation etc.

Note?that [`gray_cmyk.jpg`] ([![gray_cmyk.jpg]][`gray_cmyk.jpg`]) looks?more?like a?greyish?brown (`#4A4642`) on?my?end.

[`gray_cmyk.jpg`]: https://github.com/openjdk/jdk/blob/2573ebdc1afe0c46b621c39195ffd49bf2f724a2/test/jdk/javax/imageio/plugins/jpeg/CMYK/gray_cmyk.jpg
[gray_cmyk.jpg]: https://raw.githubusercontent.com/openjdk/jdk/2573ebdc1afe0c46b621c39195ffd49bf2f724a2/test/jdk/javax/imageio/plugins/jpeg/CMYK/gray_cmyk.jpg

src/java.desktop/share/classes/com/sun/imageio/plugins/common/SimpleCMYKColorSpace.java line 66:

> 64: 
> 65:     public int hashCode() {
> 66:         return getClass().hashCode()+7;

Alternatively, you?could?do:
Suggestion:

        return System.identityHashCode(theInstance);

which?seems to?have?been the?original?intent.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7849


From zgu at openjdk.java.net  Fri Mar 18 17:11:33 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 18 Mar 2022 17:11:33 GMT
Subject: RFR: 8283217: Leak FcObjectSet in getFontConfigLocations() in
 fontpath.c [v2]
In-Reply-To: <YhIvt5k1ZBzVgVSjhZShELHLLR6Y3j_mH40iY6j9aU8=.0b35b045-6d77-4489-aea0-75c67c74dee9@github.com>
References: <1VS7SH0RB3qQDRunQQ8s3xp6CNYpCrHX6u5KlH6LWMU=.8d5ad8cc-f5de-4099-a4d3-f1b90a44e6c5@github.com>
 <YhIvt5k1ZBzVgVSjhZShELHLLR6Y3j_mH40iY6j9aU8=.0b35b045-6d77-4489-aea0-75c67c74dee9@github.com>
Message-ID: <5GJf_qG4rVe43AdHXnwHkC80chivHyXM19_NoL9tOMo=.5e09e340-2085-4917-bab3-9b597998cbbe@github.com>

On Wed, 16 Mar 2022 01:05:19 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review this small patch to fix leaking of `FcObjectSet` in  `getFontConfigLocations()`
>> 
>> 
>> Test:
>> - [x]  jdk_2d
>
> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8283217-destroy-FcObjectSet
>  - v0

Friendly ping! May I have a second review.

Thanks,

-------------

PR: https://git.openjdk.java.net/jdk/pull/7826


From prr at openjdk.java.net  Fri Mar 18 18:21:06 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 18 Mar 2022 18:21:06 GMT
Subject: RFR: 8274735: javax.imageio.IIOException: Unsupported Image Type
 while processing a valid JPEG image [v2]
In-Reply-To: <gBv_Xtu5bmqpludbJWXwKpgvPCVz4BGYXbjErejjb1A=.cbe35817-d2cb-44bc-9f7b-d2597622623e@github.com>
References: <gBv_Xtu5bmqpludbJWXwKpgvPCVz4BGYXbjErejjb1A=.cbe35817-d2cb-44bc-9f7b-d2597622623e@github.com>
Message-ID: <kkMrJ3mLh2hD2fz968vOpUPm7XRMj2Nl6t0VPwFPpfc=.523668a3-3e68-4af1-a71f-d559252f04b9@github.com>

> The JDK's built-in Image I/O JPEG plugin decodes JPEGs which are YCbCr and RGb and Grayscale but rejects CMYK and YCCK JPEGs.
> These would correspond to JFIF encapsulated JPEGs.
> 
> This was a reasonable decision to limit support to what was actually likely to be seen - CMYK JPEGs probably should just be created for direct to print devices and never seen on the internet as an interchange format.
> 
> Indeed this (below) RFC for mail suggests JFIF is what clients should transmit :
> 
> https://datatracker.ietf.org/doc/html/rfc2046 :  Multipurpose Internet Mail Extensions - Part 2
> 
> 
>    A media type of "image" indicates that the body contains an image.
>    The subtype names the specific image format.  These names are not
>    case sensitive. An initial subtype is "jpeg" for the JPEG format
>    using JFIF encoding [JPEG].
> 
> And for many years, browsers either failed to display CMYK JPEGs or displayed them incorrectly.
> 
> But alas they do crop up and when they do, Image I/O rejects them - to the surprise and
> consternation of some developer who knows little of JPEGs and arcane colour spaces.
> 
> Full support of CMYK JPEGs via the whole Image I/O API including proper handling as metadata
> will lead us down a path that might even extend into EXIF support for JPEG and likely will
> require the JPEG Metadata spec to be updated. 
> 
> So the goal here is to skirt that as much as possible by just 
> (1) not rejecting read of CMYK JPEGs and returning a BufferedImage with a suitable ColorModel
> (2) allowing the same BufferedImage with that ColorSpace to be written back out again as CMYK JPEGs 
> 
> Reading will preserve any embedded ICC Color Profile, but writing will not re-encode it since
> that requires work on metadata. That will have to be a follow-up fix, but at the very least it
> means that a re-written JPEG will benefit from a default treatment CMYK by any other client.
> 
> A test is provided which verifies that the colours are interpreted reasonably, both on initial read
> and on write and re-read. 
> 
> JPEGs with embedded profiles have been tested on read, but since there are licensing issues with those,
> the test uses JPEGs which have no embedded profile and depend on an internal implementation class.
> 
> That class has its hashCode() method updated because testing showed that toString() invoked hashCode()
> in a way that caused a StackOverflowError - so nothing per se to do with this fix but a necessary update.
> 
> Anyone who has trustworthy CMYK JPEGs that render properly in (eg) major web browsers but not with this
> code can submit those JPEGs so I can evaluate.
> 
> But all our automated tests pass as well as some manual testing and evaluation etc.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8274735: javax.imageio.IIOException: Unsupported Image Type while processing a valid JPEG image

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7849/files
  - new: https://git.openjdk.java.net/jdk/pull/7849/files/2573ebdc..728e27a4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7849&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7849&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7849.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7849/head:pull/7849

PR: https://git.openjdk.java.net/jdk/pull/7849


From prr at openjdk.java.net  Fri Mar 18 18:21:08 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 18 Mar 2022 18:21:08 GMT
Subject: RFR: 8274735: javax.imageio.IIOException: Unsupported Image Type
 while processing a valid JPEG image
In-Reply-To: <gBv_Xtu5bmqpludbJWXwKpgvPCVz4BGYXbjErejjb1A=.cbe35817-d2cb-44bc-9f7b-d2597622623e@github.com>
References: <gBv_Xtu5bmqpludbJWXwKpgvPCVz4BGYXbjErejjb1A=.cbe35817-d2cb-44bc-9f7b-d2597622623e@github.com>
Message-ID: <sLyeI8sK4_icrqip1moBNDl36noT6b-2wpMeHLuGfeA=.b0b5a7c9-c859-448b-b912-fe81cbfbf5d5@github.com>

On Thu, 17 Mar 2022 03:23:49 GMT, Phil Race <prr at openjdk.org> wrote:

> The JDK's built-in Image I/O JPEG plugin decodes JPEGs which are YCbCr and RGb and Grayscale but rejects CMYK and YCCK JPEGs.
> These would correspond to JFIF encapsulated JPEGs.
> 
> This was a reasonable decision to limit support to what was actually likely to be seen - CMYK JPEGs probably should just be created for direct to print devices and never seen on the internet as an interchange format.
> 
> Indeed this (below) RFC for mail suggests JFIF is what clients should transmit :
> 
> https://datatracker.ietf.org/doc/html/rfc2046 :  Multipurpose Internet Mail Extensions - Part 2
> 
> 
>    A media type of "image" indicates that the body contains an image.
>    The subtype names the specific image format.  These names are not
>    case sensitive. An initial subtype is "jpeg" for the JPEG format
>    using JFIF encoding [JPEG].
> 
> And for many years, browsers either failed to display CMYK JPEGs or displayed them incorrectly.
> 
> But alas they do crop up and when they do, Image I/O rejects them - to the surprise and
> consternation of some developer who knows little of JPEGs and arcane colour spaces.
> 
> Full support of CMYK JPEGs via the whole Image I/O API including proper handling as metadata
> will lead us down a path that might even extend into EXIF support for JPEG and likely will
> require the JPEG Metadata spec to be updated. 
> 
> So the goal here is to skirt that as much as possible by just 
> (1) not rejecting read of CMYK JPEGs and returning a BufferedImage with a suitable ColorModel
> (2) allowing the same BufferedImage with that ColorSpace to be written back out again as CMYK JPEGs 
> 
> Reading will preserve any embedded ICC Color Profile, but writing will not re-encode it since
> that requires work on metadata. That will have to be a follow-up fix, but at the very least it
> means that a re-written JPEG will benefit from a default treatment CMYK by any other client.
> 
> A test is provided which verifies that the colours are interpreted reasonably, both on initial read
> and on write and re-read. 
> 
> JPEGs with embedded profiles have been tested on read, but since there are licensing issues with those,
> the test uses JPEGs which have no embedded profile and depend on an internal implementation class.
> 
> That class has its hashCode() method updated because testing showed that toString() invoked hashCode()
> in a way that caused a StackOverflowError - so nothing per se to do with this fix but a necessary update.
> 
> Anyone who has trustworthy CMYK JPEGs that render properly in (eg) major web browsers but not with this
> code can submit those JPEGs so I can evaluate.
> 
> But all our automated tests pass as well as some manual testing and evaluation etc.

> Note?that [`gray_cmyk.jpg`](https://github.com/openjdk/jdk/blob/2573ebdc1afe0c46b621c39195ffd49bf2f724a2/test/jdk/javax/imageio/plugins/jpeg/CMYK/gray_cmyk.jpg) ([![gray_cmyk.jpg](https://raw.githubusercontent.com/openjdk/jdk/2573ebdc1afe0c46b621c39195ffd49bf2f724a2/test/jdk/javax/imageio/plugins/jpeg/CMYK/gray_cmyk.jpg)](https://github.com/openjdk/jdk/blob/2573ebdc1afe0c46b621c39195ffd49bf2f724a2/test/jdk/javax/imageio/plugins/jpeg/CMYK/gray_cmyk.jpg)) looks?more?like a?greyish?brown (`#4A4642`) on?my?end.

It was created using java.awt.Color.gray which is 128.128,128 - ie #808080 as RGB, saved as JPG then converted via an online tool to CMYK  and the round trip tolerance check is passing when comparing to the original gray color, so it must be something about whatever you are using to display it and how it interprets that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7849


From prr at openjdk.java.net  Fri Mar 18 18:21:10 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 18 Mar 2022 18:21:10 GMT
Subject: RFR: 8274735: javax.imageio.IIOException: Unsupported Image Type
 while processing a valid JPEG image [v2]
In-Reply-To: <GJ9r4HEaApcqSWFwbKt9rNMDC8yJnOJqwvuPGl6Sbk8=.239055aa-60ab-4f4c-9f42-82222cb642ef@github.com>
References: <gBv_Xtu5bmqpludbJWXwKpgvPCVz4BGYXbjErejjb1A=.cbe35817-d2cb-44bc-9f7b-d2597622623e@github.com>
 <GJ9r4HEaApcqSWFwbKt9rNMDC8yJnOJqwvuPGl6Sbk8=.239055aa-60ab-4f4c-9f42-82222cb642ef@github.com>
Message-ID: <uCeD5bmIkg3BNTfSFpWaNxSxaMnTKO9AVEu6XoWYb0A=.5c1b3e9e-6e0d-45db-9df3-0f8e00e56ea1@github.com>

On Fri, 18 Mar 2022 15:33:05 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274735: javax.imageio.IIOException: Unsupported Image Type while processing a valid JPEG image
>
> src/java.desktop/share/classes/com/sun/imageio/plugins/common/SimpleCMYKColorSpace.java line 66:
> 
>> 64: 
>> 65:     public int hashCode() {
>> 66:         return getClass().hashCode()+7;
> 
> Alternatively, you?could?do:
> Suggestion:
> 
>         return System.identityHashCode(theInstance);
> 
> which?seems to?have?been the?original?intent.

I can do that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7849


From alanb at openjdk.java.net  Fri Mar 18 19:37:34 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 18 Mar 2022 19:37:34 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v9]
In-Reply-To: <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
Message-ID: <TThDYnpnGRT5MhJzfyt921c0w1PSkGTzCKyX4x5YgDo=.0da11dd1-a5f9-4c52-ac2c-b695d73e48c2@github.com>

On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1611


From prr at openjdk.java.net  Fri Mar 18 21:21:30 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 18 Mar 2022 21:21:30 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v9]
In-Reply-To: <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
Message-ID: <dzAkXMPIILgKRPK-x9XJVaFW2d_NA03CGuMkvlc0DVg=.39d1e835-937b-4c06-8208-889ba1f7ba26@github.com>

On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos

Changes requested by prr (Reviewer).

make/modules/java.desktop/gensrc/GensrcX11Wrappers.gmk line 27:

> 25: 
> 26: # Generate java sources using the X11 offsets that are precalculated in files
> 27: # src/java.desktop/share/data/x11wrappergen/sizes-<address size>.txt.

This doesn't seem right to me. This is X11 specific. It should not be in share.
Same for related files.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1611


From prr at openjdk.java.net  Fri Mar 18 21:27:36 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 18 Mar 2022 21:27:36 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v9]
In-Reply-To: <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
Message-ID: <ZqanUtqrGJAofH28Ht5RObs0jRwwMWF_xeZQiBGsu34=.17c94d0a-31bf-4368-8878-439f049d731c@github.com>

On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos

This doesn't seem right to me to put x11wrappergen into share.

This is X11 specific. It should not be in share.

Same for all of the fontconfig files. In make/data it did not seem too weird but it is very weird to put them all in share. If you were to go back and look how it used to be before someone moved them to make I am sure you'd find them in platform specific source directories.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1611


From aturbanov at openjdk.java.net  Sun Mar 20 13:50:42 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Mar 2022 13:50:42 GMT
Subject: RFR: 8283426: Fix 'exeption' typo
Message-ID: <GQ2texGEM2KygMGYrTfvdInxH8ERh-OqfDaQE-Ie_FY=.aa211bbb-47e1-455d-8a04-90d068574078@github.com>

Fix repeated type `exeption`

-------------

Commit messages:
 - [PATCH] Typo 'Exeption' instead of 'Exception'

Changes: https://git.openjdk.java.net/jdk/pull/7879/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7879&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283426
  Stats: 24 lines in 10 files changed: 0 ins; 2 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7879.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7879/head:pull/7879

PR: https://git.openjdk.java.net/jdk/pull/7879


From xuelei at openjdk.java.net  Sun Mar 20 14:41:37 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sun, 20 Mar 2022 14:41:37 GMT
Subject: RFR: 8283426: Fix 'exeption' typo
In-Reply-To: <GQ2texGEM2KygMGYrTfvdInxH8ERh-OqfDaQE-Ie_FY=.aa211bbb-47e1-455d-8a04-90d068574078@github.com>
References: <GQ2texGEM2KygMGYrTfvdInxH8ERh-OqfDaQE-Ie_FY=.aa211bbb-47e1-455d-8a04-90d068574078@github.com>
Message-ID: <_PAkHa5ReaDzrQiBnAEskX-GEe8viZdHkXfcUgMUBro=.f8aa01f8-13cf-4847-8f51-00e3b3e10516@github.com>

On Sun, 20 Mar 2022 13:30:01 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Fix repeated type `exeption`

Looks good to me.  Thanks!

-------------

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7879


From iris at openjdk.java.net  Sun Mar 20 14:57:22 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Sun, 20 Mar 2022 14:57:22 GMT
Subject: RFR: 8283426: Fix 'exeption' typo
In-Reply-To: <GQ2texGEM2KygMGYrTfvdInxH8ERh-OqfDaQE-Ie_FY=.aa211bbb-47e1-455d-8a04-90d068574078@github.com>
References: <GQ2texGEM2KygMGYrTfvdInxH8ERh-OqfDaQE-Ie_FY=.aa211bbb-47e1-455d-8a04-90d068574078@github.com>
Message-ID: <N5Z0tqFm-SymrqjVsR_KNYo6NY1fsEzxxbIGYtsjPec=.bc669c32-3397-4ba3-bebc-b6bf76510bce@github.com>

On Sun, 20 Mar 2022 13:30:01 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Fix repeated type `exeption`

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7879


From dholmes at openjdk.java.net  Mon Mar 21 00:56:30 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 21 Mar 2022 00:56:30 GMT
Subject: RFR: 8283426: Fix 'exeption' typo
In-Reply-To: <GQ2texGEM2KygMGYrTfvdInxH8ERh-OqfDaQE-Ie_FY=.aa211bbb-47e1-455d-8a04-90d068574078@github.com>
References: <GQ2texGEM2KygMGYrTfvdInxH8ERh-OqfDaQE-Ie_FY=.aa211bbb-47e1-455d-8a04-90d068574078@github.com>
Message-ID: <PIzgPCHXphvge-D607IBeO7dcve0ezYH57Dm2tAhFqo=.8d37baf9-9eb8-404b-855a-16b7db533ecd@github.com>

On Sun, 20 Mar 2022 13:30:01 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Fix repeated typo `exeption`

Looks good.

Thanks for cleaning this up.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7879


From duke at openjdk.java.net  Mon Mar 21 04:15:34 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Mon, 21 Mar 2022 04:15:34 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage
In-Reply-To: <84GSdxltlxqnh0OMbSAV0VufpS9yb1PAmAQETFNBtg0=.7f504119-83bf-4920-8514-0e3818ca6b75@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <x2z-m3Sq-k2cUBobgCe9KwHBgQFY3fvHa4ZpHld9GHA=.39ce100a-a89a-4247-a265-bf79508b7e1e@github.com>
 <2s6htwoTFM0N9DBj0Ub2zK2TepiNjRuLVJsij4mnXcM=.ba4724c1-aee4-4683-acac-cb6912dc7016@github.com>
 <_Eb1usYXvARXBUeKntPJnjhdArtK4D5MycXBiTcqtTA=.ba1f35c0-aede-4348-b2f6-3370fcaf1d96@github.com>
 <2vwMFlely_NGI2XBJ_R58vD6lAqElz39ZWB7U9gavTk=.05c9e4a2-58e6-48d9-9612-2340258ee93c@github.com>
 <ff1wAeY7Sxa0YIlM3ZDDI4TJEyd0ci02_mLC_0EUhPQ=.69d61074-8e2e-4dbf-b8b1-ccb1d5b6b7ca@github.com>
 <12bhwN6rQ-1c7HJtuPK7hrR0zsOeTbv0yYC2_f57v2g=.7f32d881-58e5-4d40-857c-553a855f2d7d@github.com>
 <CmXhKsdWszhZMI9P5P4JTzXXxQhfIRkr9ivKiAkRbr8=.9200b54a-7787-4cb2-917f-8d47018783c0@github.com>
 <l3sl0PH750Jmpq4Fwemhh6mbNZ8GMIaPnkIY_CFhULc=.b787aeee-6a15-44d7-9d22-40cb208f89a5@github.com>
 <eQvsDJueLEcrNuhX7rWh7U0ve7Y35WT3RbyM4TlFQf4=.6aca8551-bd28-450a-98cb-1459ad184d76@github.com>
 <h0p_NhQwSKmP8OuBHOGEYoyzeo6l2UPXG3q
 3HZDc90E=.14c53922-5eac-4899-a30a-e3247b7aedb2@github.com>
 <g7rzM90QOJYOWPCassms0VpEItLd5sK4QPWQbvuBRHQ=.0988cf8e-a060-43e1-82d8-9c45636a6cdd@github.com>
 <gKc7_on4YFxqKyJNk7by9Aclvm2PE7pdyVlPs4ezSe8=.5e841e2f-645f-43b8-800a-bf490c698d64@github.com>
 <84GSdxltlxqnh0OMbSAV0VufpS9yb1PAmAQETFNBtg0=.7f504119-83bf-4920-8514-0e3818ca6b75@github.com>
Message-ID: <N9JVGxo3Eofl5L04HgfDqYA1s7iXxHsW30ukxFuOIrI=.b2f086de-10b1-4ec6-9325-aaa433c395a5@github.com>

On Tue, 15 Mar 2022 16:49:56 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> @aivanov-jdk , U r right, the status remains LOADING for url...... I was getting "ERRORED" because I was showing a message using `JOptionPane.showMessageDialog(null, "");` before setting ImageIcon.
>> 
>> Ah, with the message dialog shown there's enough time to complete loading the image.
>
>> N for current bug, where to change to change the status to "ABORTED"......?? As I cannot change in ImageIcon class......
> 
> Why can't you change the status in `ImageIcon`? It's where you change it.
> 
> 
>             loadStatus = mTracker.statusID(id, false);
>             mTracker.removeImage(image, id);
>             if (loadStatus & MediaTracker.LOADING != 0) {
>                 loadStatus = MediaTracker.ABORTED;
>             }
> 
> The first two lines already exist, right after the catching `InterruptedException`. You just need to add the `if` block to amend the status.

How about setting the status to ABORTED only if it is Interrupted.....?

>             try {
>                 mTracker.waitForID(id, 0);
>             } catch (InterruptedException e) {
>                 bIsInterrupted = true;
>             }
>             if (bIsInterrupted == true)
>             {
>                 loadStatus = MediaTracker.ABORTED;
>             }
>             else
>             {
>                 loadStatus = mTracker.statusID(id, false);
>             }

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From itakiguchi at openjdk.java.net  Mon Mar 21 04:35:35 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Mon, 21 Mar 2022 04:35:35 GMT
Subject: RFR: 8282422: JTable.print() failed with
 UnsupportedCharsetException on AIX ko_KR locale
In-Reply-To: <WoFYqSGq8S5uRqiDH_FJ3ebGeinGkEI1c5_6H7omPnM=.db3d9c13-c0a7-454b-8872-034fec9daedc@github.com>
References: <WoFYqSGq8S5uRqiDH_FJ3ebGeinGkEI1c5_6H7omPnM=.db3d9c13-c0a7-454b-8872-034fec9daedc@github.com>
Message-ID: <NPBNztFjm1AXg6RPpQy7mc3Muf01VUp8Hp9upYgbnzM=.93ba67c7-d3c3-4940-8c94-31341b86377e@github.com>

On Sat, 26 Feb 2022 16:24:07 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> On AIX ko_KR locale, I could see following exception after JTable.print() was called
> 
> java.nio.charset.UnsupportedCharsetException: sun.font.X11KSC5601
>         at java.base/java.nio.charset.Charset.forName(Charset.java:527)
>         at java.desktop/sun.awt.FontConfiguration.getFontCharsetEncoder(FontConfiguration.java:964)
> ......
> 
> According to my investigation, sun.font.X11KSC5601 moved from sun.awt.motif.X11KSC5601.

Please give me your suggestion.
I need one more reviewer.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7630


From wetmore at openjdk.java.net  Mon Mar 21 04:49:33 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Mon, 21 Mar 2022 04:49:33 GMT
Subject: RFR: 8283426: Fix 'exeption' typo
In-Reply-To: <GQ2texGEM2KygMGYrTfvdInxH8ERh-OqfDaQE-Ie_FY=.aa211bbb-47e1-455d-8a04-90d068574078@github.com>
References: <GQ2texGEM2KygMGYrTfvdInxH8ERh-OqfDaQE-Ie_FY=.aa211bbb-47e1-455d-8a04-90d068574078@github.com>
Message-ID: <MDduVXDtX6Q7ZagVT1j1-nn5pRm5TVSU7B7ekMnE0i8=.0370ee23-e762-448c-96b7-48681bf15b45@github.com>

On Sun, 20 Mar 2022 13:30:01 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Fix repeated typo `exeption`

Good grief!  I wouldn't have expected it to be so widespread.  

Thanks for noticing and fixing.

-------------

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7879


From psadhukhan at openjdk.java.net  Mon Mar 21 06:20:55 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 21 Mar 2022 06:20:55 GMT
Subject: RFR: 8283437: Refactor imageio classes javadoc to use @throws instead
 of @exception
Message-ID: <uTbaZ1i1WHvZAds5WsKZT0-7hvyLSphP91wUPAyv4qc=.3aa4a4d5-1131-4901-ba5b-07ca05788f06@github.com>

Prevailing JDK coding practices use "@throws" rather than "@exception".
Refactor existing imageio classes javadoc to use @throws

-------------

Commit messages:
 - Fix
 - Fix
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/7885/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7885&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283437
  Stats: 775 lines in 51 files changed: 0 ins; 0 del; 775 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7885.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7885/head:pull/7885

PR: https://git.openjdk.java.net/jdk/pull/7885


From duke at openjdk.java.net  Mon Mar 21 07:24:37 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Mon, 21 Mar 2022 07:24:37 GMT
Subject: Integrated: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861
In-Reply-To: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
Message-ID: <YACoJcHokFWSL3IyqivvFcH7wf4THUA03Dx5s_oGLs4=.6a17c9e7-911e-41c8-a2c6-167ea33c7262@github.com>

On Thu, 24 Feb 2022 14:32:39 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

> The two tests `ScreenCaptureGtkTest.java` and `HiDPIRobotScreenCaptureTest.java` under `java/awt/Robot/HiDPIScreenCapture` started to intermittently fail under Windows and Linux after the [recent changes](https://github.com/openjdk/jdk/commit/cc7cf81256ed4d74493472017b1c4df20fa2208a) made exclusively for the Linux `Robot` implementation.
> 
> `HiDPIRobotScreenCaptureTest.java`
> Since the Windows failures cannot possibly have their origin in the fix made - the latter being Linux-only - the test apparently either exposes an existing bug in the Windows `Robot` or is bumping against a peculiarity of that platform. The test is reverted back to its original form that didn't fail.
> 
> `ScreenCaptureGtkTest.java`
> The coordinates in the log `(83, 78)` of a failure are higher up than the test suggests `(83, 97)`. I've seen similar failures on Ubuntu 20.04 when the coordinates were set to `(0, 0)`. The color then picked matched the color of the bar drawn at the top of the screen. I believe it's best to place the test pixels towards the center of the window to avoid desktop elements interference.
> 
> The other possible reason for intermittent failures are window coordinates. Suppose that the test is executing with `sun.java2d.uiScale` set to 2. This effectively means that it can only pick colors of pixels at even coordinates (in the absolute desktop space). So if the window is placed at, say, `(201, 201)`, `Robot` can only pick the color at either `(200, 200)` or `(202, 202)`. Since the test only makes sense if it is pixel-accurate, I removed all `@run`s with `sun.java2d.uiScale` other than 1. This way window placement will not cause a failure.
> 
> This was tested on Ubuntu 20.04 and 18.04 with desktop scaling set to 100%, 200%, and 300%.

This pull request has now been integrated.

Changeset: 8a2d5ab0
Author:    Maxim Kartashev <maxim.kartashev at jetbrains.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8a2d5ab07e6a1668f3e3918bdc8a30bd28a8f93b
Stats:     56 lines in 3 files changed: 36 ins; 7 del; 13 mod

8282270: java/awt/Robot Screen Capture tests fail after 8280861

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From aivanov at openjdk.java.net  Mon Mar 21 07:26:47 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 21 Mar 2022 07:26:47 GMT
Subject: RFR: 8283426: Fix 'exeption' typo
In-Reply-To: <GQ2texGEM2KygMGYrTfvdInxH8ERh-OqfDaQE-Ie_FY=.aa211bbb-47e1-455d-8a04-90d068574078@github.com>
References: <GQ2texGEM2KygMGYrTfvdInxH8ERh-OqfDaQE-Ie_FY=.aa211bbb-47e1-455d-8a04-90d068574078@github.com>
Message-ID: <wbic_pZ446rheD4dWT2u11T8bDZhMflVBejRolOSsmA=.83e2e3fc-f5fe-410f-9bcf-c308842bee94@github.com>

On Sun, 20 Mar 2022 13:30:01 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Fix repeated typo `exeption`

Marked as reviewed by aivanov (Reviewer).

src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java line 201:

> 199:     /*
> 200:      * The method could not be implemented due to CALayer restrictions.
> 201:      * The exception enforce clients not to use it.

Suggestion:

     * The exception enforces clients not to use it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7879


From mvs at openjdk.java.net  Mon Mar 21 07:36:38 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Mon, 21 Mar 2022 07:36:38 GMT
Subject: Integrated: 8282548: Create a regression test for JDK-4330998
In-Reply-To: <7HqoT6jmH4HyYQUli2v_MDFwkk8BV-e-0uAEFyxBmkI=.735e0071-2c02-423a-9647-9f33a0fedfa4@github.com>
References: <7HqoT6jmH4HyYQUli2v_MDFwkk8BV-e-0uAEFyxBmkI=.735e0071-2c02-423a-9647-9f33a0fedfa4@github.com>
Message-ID: <YVKP8R0LthKZ0pKSMFniozkSIExbT_3y7nnwYxYK03Y=.64543546-b4f9-4d98-b2d8-22ddd55e4a46@github.com>

On Tue, 8 Mar 2022 10:06:23 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Create a regression test for [JDK-4330998](https://bugs.openjdk.java.net/browse/JDK-4330998)
> 
> 
> Issue tested:
> When calling JEditorPane.setText(null), the following exception is thrown:
> 
> java.lang.NullPointerException:
>         at java.io.StringReader.<init>(StringReader.java:38)
> 
> Testing:
> Java 1.4.0 -> Test Failed.
> $ ./j2sdk1.4.0/bin/java bug4330998Win
> java.lang.RuntimeException: Test failed, caught Exception java.lang.NullPointerException when calling text.setText(null)
>         at bug4330998Win.runTest(bug4330998Win.java:45)
>         at bug4330998Win.main(bug4330998Win.java:51)
> Exception in thread "main"
> 
> Java 1.4.1 -> Test Passed.
> $ ./j2sdk1.4.1/bin/java bug4330998Win
> Test passed

This pull request has now been integrated.

Changeset: b451273d
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b451273d209d9dfce3d7c4464defe0df523dfc7c
Stats:     45 lines in 1 file changed: 45 ins; 0 del; 0 mod

8282548: Create a regression test for JDK-4330998

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/7740


From mvs at openjdk.java.net  Mon Mar 21 07:40:34 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Mon, 21 Mar 2022 07:40:34 GMT
Subject: Integrated: 8282789: Create a regression test for the JTree usecase of
 JDK-4618767
In-Reply-To: <8OsXQ_pAltihbq8L16yTW3IsYGF3nahH-Xa7fy7G3vI=.35818df7-7c9c-4acc-9b1c-63a03942914c@github.com>
References: <8OsXQ_pAltihbq8L16yTW3IsYGF3nahH-Xa7fy7G3vI=.35818df7-7c9c-4acc-9b1c-63a03942914c@github.com>
Message-ID: <Bdzt4MOG8JI5gVkh4QJDpv-PxBKjMPWEr9iIVXqfMmI=.d06145b8-25b2-405c-914a-590fee769e8b@github.com>

On Tue, 8 Mar 2022 10:52:44 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Create a regression test for the JTree usecase of [JDK-4618767](https://bugs.openjdk.java.net/browse/JDK-4618767)
> 
> 
> Issue identified in [JDK-4618767](https://bugs.openjdk.java.net/browse/JDK-4618767):
> Typing a letter while a JTree has focus now makes the selection jump to the first/next node/item whose text starts with that letter even though that letter is accompanied by modifier keys such as ALT or CTRL.
> 
> Fix:
> Only enable JTree letter navigation when the user doesn't press any modifier keys such as ALT or CTRL.
> 
> Testing:
> Java 1.4.0 -> Test Failed.
> $ ./j2sdk1.4.0/bin/java JTreeOld
> LookAndFeel: javax.swing.plaf.metal.MetalLookAndFeel
> OS = windows nt (unknown)
> java.lang.RuntimeException: Test Failed, expected colors, but got food
>         at JTreeOld.doTest(JTreeOld.java:166)
>         at JTreeOld.main(JTreeOld.java:32)
> Exception in thread "main"
> 
> Java 1.4.1 -> Test Passed.
> $ ./j2sdk1.4.1/bin/java JTreeOld
> LookAndFeel: javax.swing.plaf.metal.MetalLookAndFeel
> OS = windows nt (unknown)
> Test passed javax.swing.plaf.metal.MetalLookAndFeel
> LookAndFeel: com.sun.java.swing.plaf.motif.MotifLookAndFeel
> OS = windows nt (unknown)
> Test passed com.sun.java.swing.plaf.motif.MotifLookAndFeel
> LookAndFeel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> OS = windows nt (unknown)
> Test passed com.sun.java.swing.plaf.windows.WindowsLookAndFeel

This pull request has now been integrated.

Changeset: 83a1c904
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/83a1c90433343107eaa2a7fa41b9b07f86b6ce19
Stats:     226 lines in 1 file changed: 226 ins; 0 del; 0 mod

8282789: Create a regression test for the JTree usecase of JDK-4618767

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/7742


From serb at openjdk.java.net  Mon Mar 21 08:44:34 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 21 Mar 2022 08:44:34 GMT
Subject: RFR: 8283437: Refactor imageio classes javadoc to use @throws
 instead of @exception
In-Reply-To: <uTbaZ1i1WHvZAds5WsKZT0-7hvyLSphP91wUPAyv4qc=.3aa4a4d5-1131-4901-ba5b-07ca05788f06@github.com>
References: <uTbaZ1i1WHvZAds5WsKZT0-7hvyLSphP91wUPAyv4qc=.3aa4a4d5-1131-4901-ba5b-07ca05788f06@github.com>
Message-ID: <Bjqa4Y-cI8HpNd5ygq-1IK4a9dvs5fvsRibh9eUl8Nw=.c0e23905-23c5-4de8-8019-73c319bd33d9@github.com>

On Mon, 21 Mar 2022 06:13:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Prevailing JDK coding practices use "@throws" rather than "@exception".
> Refactor existing imageio classes javadoc to use @throws

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7885


From aturbanov at openjdk.java.net  Mon Mar 21 09:02:17 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Mon, 21 Mar 2022 09:02:17 GMT
Subject: RFR: 8283426: Fix 'exeption' typo [v2]
In-Reply-To: <GQ2texGEM2KygMGYrTfvdInxH8ERh-OqfDaQE-Ie_FY=.aa211bbb-47e1-455d-8a04-90d068574078@github.com>
References: <GQ2texGEM2KygMGYrTfvdInxH8ERh-OqfDaQE-Ie_FY=.aa211bbb-47e1-455d-8a04-90d068574078@github.com>
Message-ID: <1aOenacSYTb23hOLJFJBdM_k6vXL8gl5qxTn0RrocoA=.a0d88289-1e12-45f9-88ec-27981f9a0f74@github.com>

> Fix repeated typo `exeption`

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8283426: Fix 'exeption' typo
  
  Apply suggestion
  
  Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7879/files
  - new: https://git.openjdk.java.net/jdk/pull/7879/files/d93dde25..4c1e68ed

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7879&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7879&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7879.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7879/head:pull/7879

PR: https://git.openjdk.java.net/jdk/pull/7879


From aivanov at openjdk.java.net  Mon Mar 21 12:10:35 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 21 Mar 2022 12:10:35 GMT
Subject: RFR: 8283217: Leak FcObjectSet in getFontConfigLocations() in
 fontpath.c [v2]
In-Reply-To: <YhIvt5k1ZBzVgVSjhZShELHLLR6Y3j_mH40iY6j9aU8=.0b35b045-6d77-4489-aea0-75c67c74dee9@github.com>
References: <1VS7SH0RB3qQDRunQQ8s3xp6CNYpCrHX6u5KlH6LWMU=.8d5ad8cc-f5de-4099-a4d3-f1b90a44e6c5@github.com>
 <YhIvt5k1ZBzVgVSjhZShELHLLR6Y3j_mH40iY6j9aU8=.0b35b045-6d77-4489-aea0-75c67c74dee9@github.com>
Message-ID: <6A9zqnBweSOXuxnMQLYWwIuYov_vWKd6gKuySYzjTKE=.1f30f271-9a53-40c3-9d40-5d8bec7544c3@github.com>

On Wed, 16 Mar 2022 01:05:19 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review this small patch to fix leaking of `FcObjectSet` in  `getFontConfigLocations()`
>> 
>> 
>> Test:
>> - [x]  jdk_2d
>
> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8283217-destroy-FcObjectSet
>  - v0

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7826


From zgu at openjdk.java.net  Mon Mar 21 12:29:44 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 21 Mar 2022 12:29:44 GMT
Subject: RFR: 8283217: Leak FcObjectSet in getFontConfigLocations() in
 fontpath.c [v2]
In-Reply-To: <TX42gECE8Ktd0nNA1g3NSl8W2BKfpiQRBHL7Kt2dWrE=.55d9b17c-862c-4f0a-9c50-0fe8036b03d3@github.com>
References: <1VS7SH0RB3qQDRunQQ8s3xp6CNYpCrHX6u5KlH6LWMU=.8d5ad8cc-f5de-4099-a4d3-f1b90a44e6c5@github.com>
 <YhIvt5k1ZBzVgVSjhZShELHLLR6Y3j_mH40iY6j9aU8=.0b35b045-6d77-4489-aea0-75c67c74dee9@github.com>
 <TX42gECE8Ktd0nNA1g3NSl8W2BKfpiQRBHL7Kt2dWrE=.55d9b17c-862c-4f0a-9c50-0fe8036b03d3@github.com>
Message-ID: <4ne8eZjiWI2vPjHt3M9OT_0t3JNk-pum9CtSa5-Df9s=.92f4d614-469d-42e7-abb1-694891b14a5b@github.com>

On Thu, 17 Mar 2022 20:46:57 GMT, Phil Race <prr at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8283217-destroy-FcObjectSet
>>  - v0
>
> Marked as reviewed by prr (Reviewer).

Thanks, @prrace @aivanov-jdk

-------------

PR: https://git.openjdk.java.net/jdk/pull/7826


From zgu at openjdk.java.net  Mon Mar 21 12:29:46 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 21 Mar 2022 12:29:46 GMT
Subject: Integrated: 8283217: Leak FcObjectSet in getFontConfigLocations() in
 fontpath.c
In-Reply-To: <1VS7SH0RB3qQDRunQQ8s3xp6CNYpCrHX6u5KlH6LWMU=.8d5ad8cc-f5de-4099-a4d3-f1b90a44e6c5@github.com>
References: <1VS7SH0RB3qQDRunQQ8s3xp6CNYpCrHX6u5KlH6LWMU=.8d5ad8cc-f5de-4099-a4d3-f1b90a44e6c5@github.com>
Message-ID: <3nidoEWzkpU9Hzmv6SX9TVntfAroGL0bLPYuyJyLP6g=.38865577-7bc1-4081-b517-1e5735876023@github.com>

On Tue, 15 Mar 2022 19:26:19 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this small patch to fix leaking of `FcObjectSet` in  `getFontConfigLocations()`
> 
> 
> Test:
> - [x]  jdk_2d

This pull request has now been integrated.

Changeset: 909986c7
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/909986c7e110c8ac3ba16750be7707b1ec344ee5
Stats:     6 lines in 1 file changed: 6 ins; 0 del; 0 mod

8283217: Leak FcObjectSet in getFontConfigLocations() in fontpath.c

Reviewed-by: prr, aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/7826


From aivanov at openjdk.java.net  Mon Mar 21 13:22:31 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 21 Mar 2022 13:22:31 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage
In-Reply-To: <N9JVGxo3Eofl5L04HgfDqYA1s7iXxHsW30ukxFuOIrI=.b2f086de-10b1-4ec6-9325-aaa433c395a5@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <x2z-m3Sq-k2cUBobgCe9KwHBgQFY3fvHa4ZpHld9GHA=.39ce100a-a89a-4247-a265-bf79508b7e1e@github.com>
 <2s6htwoTFM0N9DBj0Ub2zK2TepiNjRuLVJsij4mnXcM=.ba4724c1-aee4-4683-acac-cb6912dc7016@github.com>
 <_Eb1usYXvARXBUeKntPJnjhdArtK4D5MycXBiTcqtTA=.ba1f35c0-aede-4348-b2f6-3370fcaf1d96@github.com>
 <2vwMFlely_NGI2XBJ_R58vD6lAqElz39ZWB7U9gavTk=.05c9e4a2-58e6-48d9-9612-2340258ee93c@github.com>
 <ff1wAeY7Sxa0YIlM3ZDDI4TJEyd0ci02_mLC_0EUhPQ=.69d61074-8e2e-4dbf-b8b1-ccb1d5b6b7ca@github.com>
 <12bhwN6rQ-1c7HJtuPK7hrR0zsOeTbv0yYC2_f57v2g=.7f32d881-58e5-4d40-857c-553a855f2d7d@github.com>
 <CmXhKsdWszhZMI9P5P4JTzXXxQhfIRkr9ivKiAkRbr8=.9200b54a-7787-4cb2-917f-8d47018783c0@github.com>
 <l3sl0PH750Jmpq4Fwemhh6mbNZ8GMIaPnkIY_CFhULc=.b787aeee-6a15-44d7-9d22-40cb208f89a5@github.com>
 <eQvsDJueLEcrNuhX7rWh7U0ve7Y35WT3RbyM4TlFQf4=.6aca8551-bd28-450a-98cb-1459ad184d76@github.com>
 <h0p_NhQwSKmP8OuBHOGEYoyzeo6l2UPXG3q
 3HZDc90E=.14c53922-5eac-4899-a30a-e3247b7aedb2@github.com>
 <g7rzM90QOJYOWPCassms0VpEItLd5sK4QPWQbvuBRHQ=.0988cf8e-a060-43e1-82d8-9c45636a6cdd@github.com>
 <gKc7_on4YFxqKyJNk7by9Aclvm2PE7pdyVlPs4ezSe8=.5e841e2f-645f-43b8-800a-bf490c698d64@github.com>
 <84GSdxltlxqnh0OMbSAV0VufpS9yb1PAmAQETFNBtg0=.7f504119-83bf-4920-8514-0e3818ca6b75@github.com>
 <N9JVGxo3Eofl5L04HgfDqYA1s7iXxHsW30ukxFuOIrI=.b2f086de-10b1-4ec6-9325-aaa433c395a5@github.com>
Message-ID: <bdaSP3a0Xw8A-Rc6fM1IEsAHwBudccK3lQ-PVeR6cBw=.9c86fd27-70af-401d-a1ea-e7a0491cb035@github.com>

On Mon, 21 Mar 2022 04:10:48 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>>> N for current bug, where to change to change the status to "ABORTED"......?? As I cannot change in ImageIcon class......
>> 
>> Why can't you change the status in `ImageIcon`? It's where you change it.
>> 
>> 
>>             loadStatus = mTracker.statusID(id, false);
>>             mTracker.removeImage(image, id);
>>             if (loadStatus & MediaTracker.LOADING != 0) {
>>                 loadStatus = MediaTracker.ABORTED;
>>             }
>> 
>> The first two lines already exist, right after the catching `InterruptedException`. You just need to add the `if` block to amend the status.
>
> How about setting the status to ABORTED only if it is Interrupted.....?
> 
>>             try {
>>                 mTracker.waitForID(id, 0);
>>             } catch (InterruptedException e) {
>>                 bIsInterrupted = true;
>>             }
>>             if (bIsInterrupted == true)
>>             {
>>                 loadStatus = MediaTracker.ABORTED;
>>             }
>>             else
>>             {
>>                 loadStatus = mTracker.statusID(id, false);
>>             }

That's a good point. However, you have get the status from `MediaTracker` first: the image could finish loading before the thread was interrupted.


        try {
            mTracker.waitForID(id, 0);
        } catch (InterruptedException e) {
            interrupted = true;
        }

        loadStatus = mTracker.statusID(id, false);
        mTracker.removeImage(image, id);
        if (interrupted && (loadStatus & MediaTracker.LOADING != 0)) {
            loadStatus = MediaTracker.ABORTED;
        }


On the other hand, if the thread isn't interrupted, `waitForID` returns only after the image moves into its final state: `LOADED`, `ABORTED`, or `ERRORED`; if its status is still `LOADING`, the thread is interrupted.

Therefore my original suggestion is still correct: the status is amended only when the thread is interrupted. Yet the intention of the code seems clearer with the additional `interrupted` flag. At the same time, I'm still inclined towards the shorter version without the flag.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From aivanov at openjdk.java.net  Mon Mar 21 13:23:30 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 21 Mar 2022 13:23:30 GMT
Subject: RFR: 8283426: Fix 'exeption' typo [v2]
In-Reply-To: <1aOenacSYTb23hOLJFJBdM_k6vXL8gl5qxTn0RrocoA=.a0d88289-1e12-45f9-88ec-27981f9a0f74@github.com>
References: <GQ2texGEM2KygMGYrTfvdInxH8ERh-OqfDaQE-Ie_FY=.aa211bbb-47e1-455d-8a04-90d068574078@github.com>
 <1aOenacSYTb23hOLJFJBdM_k6vXL8gl5qxTn0RrocoA=.a0d88289-1e12-45f9-88ec-27981f9a0f74@github.com>
Message-ID: <GFDB5JTSFpOXRomR-spe553FEWLSwKO59XviFIsa3N8=.c7ac428a-ab78-493d-9741-f4200ad0cdff@github.com>

On Mon, 21 Mar 2022 09:02:17 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Fix repeated typo `exeption`
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8283426: Fix 'exeption' typo
>   
>   Apply suggestion
>   
>   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7879


From ihse at openjdk.java.net  Mon Mar 21 13:41:40 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 21 Mar 2022 13:41:40 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v10]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <On8dlZu4vW14u7WoEcc7K-dxlfaR_LNubtfe1UylTX4=.0b49d0c3-978f-4ae0-8376-860a9e24ad1d@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix fontconfig according to review request

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1611/files
  - new: https://git.openjdk.java.net/jdk/pull/1611/files/b1d1e4d8..5a75e7d1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=08-09

  Stats: 26 lines in 5 files changed: 10 ins; 5 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Mon Mar 21 13:46:27 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 21 Mar 2022 13:46:27 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v11]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <Y7NUBj6Z_EjhTNfXABIhR-XtHoCimtCttXC-H9fN_vQ=.856678a9-ef4d-417b-9d65-fe21b0629e68@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

Magnus Ihse Bursie 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 tag 'jdk-19+14' into shuffle-data
   
   Added tag jdk-19+14 for changeset 08cadb47
 - Move x11wrappergen from share/data to unix/data
 - Fix fontconfig according to review request
 - Fix typos
 - Restore charsetmapping and cldr to make/data
 - Update copyright year
 - Merge branch 'master' into shuffle-data-reborn
 - Fix merge
 - Merge tag 'jdk-19+13' into shuffle-data-reborn
   
   Added tag jdk-19+13 for changeset 5df2a057
 - Move characterdata templates to share/classes/java/lang.
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/08cadb47...ea17b206

-------------

Changes: https://git.openjdk.java.net/jdk/pull/1611/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=10
  Stats: 140 lines in 619 files changed: 14 ins; 6 del; 120 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

PR: https://git.openjdk.java.net/jdk/pull/1611


From duke at openjdk.java.net  Mon Mar 21 13:59:45 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Mon, 21 Mar 2022 13:59:45 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage
In-Reply-To: <bdaSP3a0Xw8A-Rc6fM1IEsAHwBudccK3lQ-PVeR6cBw=.9c86fd27-70af-401d-a1ea-e7a0491cb035@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <x2z-m3Sq-k2cUBobgCe9KwHBgQFY3fvHa4ZpHld9GHA=.39ce100a-a89a-4247-a265-bf79508b7e1e@github.com>
 <2s6htwoTFM0N9DBj0Ub2zK2TepiNjRuLVJsij4mnXcM=.ba4724c1-aee4-4683-acac-cb6912dc7016@github.com>
 <_Eb1usYXvARXBUeKntPJnjhdArtK4D5MycXBiTcqtTA=.ba1f35c0-aede-4348-b2f6-3370fcaf1d96@github.com>
 <2vwMFlely_NGI2XBJ_R58vD6lAqElz39ZWB7U9gavTk=.05c9e4a2-58e6-48d9-9612-2340258ee93c@github.com>
 <ff1wAeY7Sxa0YIlM3ZDDI4TJEyd0ci02_mLC_0EUhPQ=.69d61074-8e2e-4dbf-b8b1-ccb1d5b6b7ca@github.com>
 <12bhwN6rQ-1c7HJtuPK7hrR0zsOeTbv0yYC2_f57v2g=.7f32d881-58e5-4d40-857c-553a855f2d7d@github.com>
 <CmXhKsdWszhZMI9P5P4JTzXXxQhfIRkr9ivKiAkRbr8=.9200b54a-7787-4cb2-917f-8d47018783c0@github.com>
 <l3sl0PH750Jmpq4Fwemhh6mbNZ8GMIaPnkIY_CFhULc=.b787aeee-6a15-44d7-9d22-40cb208f89a5@github.com>
 <eQvsDJueLEcrNuhX7rWh7U0ve7Y35WT3RbyM4TlFQf4=.6aca8551-bd28-450a-98cb-1459ad184d76@github.com>
 <h0p_NhQwSKmP8OuBHOGEYoyzeo6l2UPXG3q
 3HZDc90E=.14c53922-5eac-4899-a30a-e3247b7aedb2@github.com>
 <g7rzM90QOJYOWPCassms0VpEItLd5sK4QPWQbvuBRHQ=.0988cf8e-a060-43e1-82d8-9c45636a6cdd@github.com>
 <gKc7_on4YFxqKyJNk7by9Aclvm2PE7pdyVlPs4ezSe8=.5e841e2f-645f-43b8-800a-bf490c698d64@github.com>
 <84GSdxltlxqnh0OMbSAV0VufpS9yb1PAmAQETFNBtg0=.7f504119-83bf-4920-8514-0e3818ca6b75@github.com>
 <N9JVGxo3Eofl5L04HgfDqYA1s7iXxHsW30ukxFuOIrI=.b2f086de-10b1-4ec6-9325-aaa433c395a5@github.com>
 <bdaSP3a0Xw8A-Rc6fM1IEsAHwBudccK3lQ-PVeR6cBw=.9c86fd27-70af-401d-a1ea-e7a0491cb035@github.com>
Message-ID: <sVYDGGHGDQq0RKrH5EJHAMCQXLLHm6R1VgHDn6hLsLw=.133e9bf2-05bb-494e-b190-7f89d93f7b59@github.com>

On Mon, 21 Mar 2022 13:19:14 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> How about setting the status to ABORTED only if it is Interrupted.....?
>> 
>>>             try {
>>>                 mTracker.waitForID(id, 0);
>>>             } catch (InterruptedException e) {
>>>                 bIsInterrupted = true;
>>>             }
>>>             if (bIsInterrupted == true)
>>>             {
>>>                 loadStatus = MediaTracker.ABORTED;
>>>             }
>>>             else
>>>             {
>>>                 loadStatus = mTracker.statusID(id, false);
>>>             }
>
> That's a good point. However, you have get the status from `MediaTracker` first: the image could finish loading before the thread was interrupted.
> 
> 
>         try {
>             mTracker.waitForID(id, 0);
>         } catch (InterruptedException e) {
>             interrupted = true;
>         }
> 
>         loadStatus = mTracker.statusID(id, false);
>         mTracker.removeImage(image, id);
>         if (interrupted && (loadStatus & MediaTracker.LOADING != 0)) {
>             loadStatus = MediaTracker.ABORTED;
>         }
> 
> 
> On the other hand, if the thread isn't interrupted, `waitForID` returns only after the image moves into its final state: `LOADED`, `ABORTED`, or `ERRORED`; if its status is still `LOADING`, the thread is interrupted.
> 
> Therefore my original suggestion is still correct: the status is amended only when the thread is interrupted. Yet the intention of the code seems clearer with the additional `interrupted` flag. At the same time, I'm still inclined towards the shorter version without the flag.

Yeah, I was also thinking about the load COMPLETE case...... sure then will update the same......

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From ihse at openjdk.java.net  Mon Mar 21 14:15:36 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 21 Mar 2022 14:15:36 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v9]
In-Reply-To: <ZqanUtqrGJAofH28Ht5RObs0jRwwMWF_xeZQiBGsu34=.17c94d0a-31bf-4368-8878-439f049d731c@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
 <ZqanUtqrGJAofH28Ht5RObs0jRwwMWF_xeZQiBGsu34=.17c94d0a-31bf-4368-8878-439f049d731c@github.com>
Message-ID: <sTEilApbgCtDnzUN4M2UE2Uuie52Bp4KflqHS4lTL_s=.430bd2c4-76a5-47c0-aa07-7cbf26c6a4e0@github.com>

On Fri, 18 Mar 2022 21:24:43 GMT, Phil Race <prr at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typos
>
> This doesn't seem right to me to put x11wrappergen into share.
> 
> This is X11 specific. It should not be in share.
> 
> Same for all of the fontconfig files. In make/data it did not seem too weird but it is very weird to put them all in share. If you were to go back and look how it used to be before someone moved them to make I am sure you'd find them in platform specific source directories.

@prrace I have now moved the fontconfig files to `$OS/data`. (I also took the opportunity to clean up the GenData file, which had a quite hairy logic for a trivial task.) I have moved the x11wrappergen files to `unix/data`. 

(Strictly speaking, "unix" and "x11" do not have the same "sense" (in the Fregean meaning), even if it has the same "referent". But we've used that convention before so I'm sticking to it.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Mon Mar 21 16:06:35 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 21 Mar 2022 16:06:35 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v12]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <F5oPHTPSHGam_cd_srYyubqcjvB_0j3m4q3sxfawsAg=.7f5555b0-7b16-4dc9-857f-62a2a401da7a@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Correct name for bfc files

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1611/files
  - new: https://git.openjdk.java.net/jdk/pull/1611/files/ea17b206..f66afd1a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=10-11

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Mon Mar 21 16:29:25 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 21 Mar 2022 16:29:25 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v13]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <zgclPzWS5pSW1Sjeh0589MH3KXwez6WcnXILajQAQmA=.8e03cff3-3f44-45d5-908c-741a990d1517@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge branch 'master' into shuffle-data
 - Correct name for bfc files
 - Merge tag 'jdk-19+14' into shuffle-data
   
   Added tag jdk-19+14 for changeset 08cadb47
 - Move x11wrappergen from share/data to unix/data
 - Fix fontconfig according to review request
 - Fix typos
 - Restore charsetmapping and cldr to make/data
 - Update copyright year
 - Merge branch 'master' into shuffle-data-reborn
 - Fix merge
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/19d34bdf...1c47d82d

-------------

Changes: https://git.openjdk.java.net/jdk/pull/1611/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=12
  Stats: 140 lines in 619 files changed: 14 ins; 6 del; 120 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

PR: https://git.openjdk.java.net/jdk/pull/1611


From shurailine at openjdk.java.net  Mon Mar 21 17:01:35 2022
From: shurailine at openjdk.java.net (Alexandre Iline)
Date: Mon, 21 Mar 2022 17:01:35 GMT
Subject: RFR: 8282771 : Create test case for JDK-8262981 [v3]
In-Reply-To: <mt_vo_p7z80juhvjp6uSCtujUVrJxvlRYCgr5FiydOw=.ea947e60-f1ff-4fe8-8e01-c50117c135e2@github.com>
References: <pbRcgoRd0mYiHu3ASOMDqfVCJuyKZsKKSZd3JlguYaM=.0770dc62-36be-42e8-b88e-6425263fd6dd@github.com>
 <mt_vo_p7z80juhvjp6uSCtujUVrJxvlRYCgr5FiydOw=.ea947e60-f1ff-4fe8-8e01-c50117c135e2@github.com>
Message-ID: <piMmMYBjTLIJnQvJFb7ANrRDaJFPNbwIc0a0tXimgnU=.ea5685cd-f530-4160-9930-b60515887813@github.com>

On Wed, 16 Mar 2022 21:17:44 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> Following methods are covered in this testcase
>> getAccessibleAction()
>> getAccessibleActionCount()
>> doAccessibleAction(int direction) 
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed review comments

Changes requested by shurailine (Committer).

test/jdk/javax/accessibility/JSlider/AccessibleAction/JSliderAccessibleAction.java line 74:

> 72:     private static volatile AtomicInteger currentJSliderValue;
> 73:     private static volatile AtomicInteger jSliderInitialValue;
> 74:     private static volatile AccessibleAction accessibleAction;

This field seem to be only accessed from the EDT, similar to UI components above, so why is it volatile and the components are not?

test/jdk/javax/accessibility/JSlider/AccessibleAction/JSliderAccessibleAction.java line 179:

> 177:                 validDecrementCountDownLatch = new CountDownLatch(1);
> 178:                 validIncrementCountDownLatch = new CountDownLatch(1);
> 179:                 currentJSliderValue = new AtomicInteger();

if this is a volatile, than perhaps you do not need an atomic?

test/jdk/javax/accessibility/JSlider/AccessibleAction/JSliderAccessibleAction.java line 265:

> 263:         robot.waitForIdle();
> 264:         final Point[] point = new Point[1];
> 265:         final Rectangle[] rect = new Rectangle[1];

finals here are redundant although do not hurt

test/jdk/javax/accessibility/JSlider/AccessibleAction/JSliderAccessibleAction.java line 282:

> 280:     public static void main(String[] args) throws InterruptedException,
> 281:             InvocationTargetException, AWTException {
> 282:         JSliderAccessibleAction jSliderAccessibleAction =

The class appears to have no state, why do you need an instance of it? Why not to make the methods static?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7734


From erikj at openjdk.java.net  Mon Mar 21 17:07:40 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 21 Mar 2022 17:07:40 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v13]
In-Reply-To: <zgclPzWS5pSW1Sjeh0589MH3KXwez6WcnXILajQAQmA=.8e03cff3-3f44-45d5-908c-741a990d1517@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <zgclPzWS5pSW1Sjeh0589MH3KXwez6WcnXILajQAQmA=.8e03cff3-3f44-45d5-908c-741a990d1517@github.com>
Message-ID: <opdfm7Z0vWIQswV0Xb72GPj_qdNYKj5or6H8p6XaPaA=.19a39cd9-ff67-4a53-b086-2d1e2d261003@github.com>

On Mon, 21 Mar 2022 16:29:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge branch 'master' into shuffle-data
>  - Correct name for bfc files
>  - Merge tag 'jdk-19+14' into shuffle-data
>    
>    Added tag jdk-19+14 for changeset 08cadb47
>  - Move x11wrappergen from share/data to unix/data
>  - Fix fontconfig according to review request
>  - Fix typos
>  - Restore charsetmapping and cldr to make/data
>  - Update copyright year
>  - Merge branch 'master' into shuffle-data-reborn
>  - Fix merge
>  - ... and 10 more: https://git.openjdk.java.net/jdk/compare/19d34bdf...1c47d82d

OS specific X11 and fontconfig looks good.

make/modules/java.desktop/gendata/GendataFontConfig.gmk line 57:

> 55:   TARGETS += $(FONTCONFIG_OUT_BIN_FILE)
> 56: 
> 57: endif

It says no newline at end of file, maybe add that if it's true.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1611


From prr at openjdk.java.net  Mon Mar 21 17:57:38 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 21 Mar 2022 17:57:38 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v9]
In-Reply-To: <ZqanUtqrGJAofH28Ht5RObs0jRwwMWF_xeZQiBGsu34=.17c94d0a-31bf-4368-8878-439f049d731c@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
 <ZqanUtqrGJAofH28Ht5RObs0jRwwMWF_xeZQiBGsu34=.17c94d0a-31bf-4368-8878-439f049d731c@github.com>
Message-ID: <ssoH764XKtZcaeKQQUsZrr6Ox1mMgq-WTGu3Ke5UW38=.1de7c1bc-a106-4528-886f-ad0cc33b717a@github.com>

On Fri, 18 Mar 2022 21:24:43 GMT, Phil Race <prr at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typos
>
> This doesn't seem right to me to put x11wrappergen into share.
> 
> This is X11 specific. It should not be in share.
> 
> Same for all of the fontconfig files. In make/data it did not seem too weird but it is very weird to put them all in share. If you were to go back and look how it used to be before someone moved them to make I am sure you'd find them in platform specific source directories.

> @prrace I have now moved the fontconfig files to `$OS/data`. (I also took the opportunity to clean up the GenData file, which had a quite hairy logic for a trivial task.) I have moved the x11wrappergen files to `unix/data`.
> 
> (Strictly speaking, "unix" and "x11" do not have the same "sense" (in the Fregean meaning), even if it has the same "referent". But we've used that convention before so I'm sticking to it.)

Indeed they do not but it is a better approximation than "shared".

-------------

PR: https://git.openjdk.java.net/jdk/pull/1611


From jjg at openjdk.java.net  Mon Mar 21 19:00:36 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 21 Mar 2022 19:00:36 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v13]
In-Reply-To: <zgclPzWS5pSW1Sjeh0589MH3KXwez6WcnXILajQAQmA=.8e03cff3-3f44-45d5-908c-741a990d1517@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <zgclPzWS5pSW1Sjeh0589MH3KXwez6WcnXILajQAQmA=.8e03cff3-3f44-45d5-908c-741a990d1517@github.com>
Message-ID: <dzwmzU5bxVLo3jjEzFdqL3irm8gwaabl6Vvjxx19cVA=.ecfee429-d175-449e-9e33-c3e29d4852ff@github.com>

On Mon, 21 Mar 2022 16:29:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge branch 'master' into shuffle-data
>  - Correct name for bfc files
>  - Merge tag 'jdk-19+14' into shuffle-data
>    
>    Added tag jdk-19+14 for changeset 08cadb47
>  - Move x11wrappergen from share/data to unix/data
>  - Fix fontconfig according to review request
>  - Fix typos
>  - Restore charsetmapping and cldr to make/data
>  - Update copyright year
>  - Merge branch 'master' into shuffle-data-reborn
>  - Fix merge
>  - ... and 10 more: https://git.openjdk.java.net/jdk/compare/19d34bdf...1c47d82d

As before, the changes for `jdk.compiler` and `idk.javadoc` look OK, and if there is general consensus on the overall proposed move, then I think that overall it is a good idea.

I did not review the `jdk.compiler` in low-level detail, but scanning the webrev index file, the changes seemed OK, and a pure move (no lines changed.)

It might have been better to have handled this on a per-module basis, rather than all-at-once, but whatever ...

-------------

PR: https://git.openjdk.java.net/jdk/pull/1611


From mchung at openjdk.java.net  Mon Mar 21 19:42:33 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 21 Mar 2022 19:42:33 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v13]
In-Reply-To: <zgclPzWS5pSW1Sjeh0589MH3KXwez6WcnXILajQAQmA=.8e03cff3-3f44-45d5-908c-741a990d1517@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <zgclPzWS5pSW1Sjeh0589MH3KXwez6WcnXILajQAQmA=.8e03cff3-3f44-45d5-908c-741a990d1517@github.com>
Message-ID: <80sBZo5_9EhVEBljhwN7YRFwROLhSnYgNPH1Qg2tMOk=.061730ba-b085-4109-b5c9-ddbf0397301f@github.com>

On Mon, 21 Mar 2022 16:29:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge branch 'master' into shuffle-data
>  - Correct name for bfc files
>  - Merge tag 'jdk-19+14' into shuffle-data
>    
>    Added tag jdk-19+14 for changeset 08cadb47
>  - Move x11wrappergen from share/data to unix/data
>  - Fix fontconfig according to review request
>  - Fix typos
>  - Restore charsetmapping and cldr to make/data
>  - Update copyright year
>  - Merge branch 'master' into shuffle-data-reborn
>  - Fix merge
>  - ... and 10 more: https://git.openjdk.java.net/jdk/compare/19d34bdf...1c47d82d

I reviewed java.base and java.se.  I agree that java.se is a better home for jdwp.spec.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Mon Mar 21 21:30:29 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 21 Mar 2022 21:30:29 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v14]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <bQvx336XdMQBPLqKmuEYlQSxpZfq4KdyGGQlgXS9Lh4=.4525e76b-b105-4935-aec4-72e75b6faf9e@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Add missing newline at EOF

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1611/files
  - new: https://git.openjdk.java.net/jdk/pull/1611/files/1c47d82d..8faeff36

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=12-13

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

PR: https://git.openjdk.java.net/jdk/pull/1611


From duke at openjdk.java.net  Mon Mar 21 21:41:27 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Mon, 21 Mar 2022 21:41:27 GMT
Subject: RFR: 8281284 : Write JSlider accessibility test [v7]
In-Reply-To: <VB8Ldq_d1uZBKpyvvDlu7t9lUtAd_WhLl4meSv46ixo=.b8b023ee-6946-407d-8e05-223fb2d95062@github.com>
References: <VB8Ldq_d1uZBKpyvvDlu7t9lUtAd_WhLl4meSv46ixo=.b8b023ee-6946-407d-8e05-223fb2d95062@github.com>
Message-ID: <ffuhc7bE0polSSFA3gi1aDROXkbWZaww2fS5CHHpdD4=.94c24739-b557-4919-9b00-624cb89fa12f@github.com>

> This testcase covers both old and new api ( api added in jdk17  getAccessibleAction(), getAccessibleActionCount() , getAccessibleActionDescription )
> 
> @shurymury 
> @savoptik

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  Removed AccessibleJSliderTest.java and add SliderDemo.java & SliderDemo.html

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7355/files
  - new: https://git.openjdk.java.net/jdk/pull/7355/files/fcc32f70..ba20c416

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7355&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7355&range=05-06

  Stats: 202 lines in 5 files changed: 107 ins; 95 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7355.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7355/head:pull/7355

PR: https://git.openjdk.java.net/jdk/pull/7355


From ihse at openjdk.java.net  Mon Mar 21 21:39:38 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 21 Mar 2022 21:39:38 GMT
Subject: Integrated: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <vYbOrE22zzQ4_jNylB1fKhlWCWq6CqS1bBCYGTlDQP8=.f6c27d21-a538-40e8-9b85-7c538a888a72@github.com>

On Thu, 3 Dec 2020 23:44:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

This pull request has now been integrated.

Changeset: f8878cb0
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f8878cb0cc436993ef1222bc13b00b923d91aad1
Stats:     140 lines in 619 files changed: 14 ins; 6 del; 120 mod

8257733: Move module-specific data from make to respective module

Reviewed-by: jjg, weijun, naoto, erikj, prr, alanb, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/1611


From duke at openjdk.java.net  Mon Mar 21 22:40:32 2022
From: duke at openjdk.java.net (lukeu)
Date: Mon, 21 Mar 2022 22:40:32 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v6]
In-Reply-To: <oc9A9PE5Mq_o16sPjsdgoqc2pGkAoEFft02Ee1jlA38=.f39df329-8872-445e-9fa8-8c4c3e289677@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oc9A9PE5Mq_o16sPjsdgoqc2pGkAoEFft02Ee1jlA38=.f39df329-8872-445e-9fa8-8c4c3e289677@github.com>
Message-ID: <9ZrEOxmHFteNTo11Anh-0inJOYSDBZdF6F3AjfdHrdI=.2d7de6a6-6eee-4761-90a1-f86e96d7649a@github.com>

On Thu, 17 Mar 2022 23:50:21 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed apostrophe in comment of saveImage

I'm not sure if it'd be acceptable performance-wise (like across all platforms) but the code could jump to an area-based fill when needing to render lines with thickness > 1. For example (after removing scaling)...

    Color c1 = (etchType == LOWERED) ? getHighlightColor(c) : getShadowColor(c);
    Color c2 = (etchType == LOWERED) ? getShadowColor(c) : getHighlightColor(c);

    int thick = (int) Math.floor(Math.max(at.getScaleX(), at.getScaleY()));

    if (thick < 2) {
        // Use current line-based code (faster?)
    } else {
        g.setColor(c1);
        Area a = new Area(new Rectangle(0, 0, w, h));
        a.subtract(new Area(new Rectangle(thick*2, thick*2, w-thick*4, h-thick*4)));
        g2d.fill(a);

        g.setColor(c2);
        a = new Area(new Rectangle(0, 0, w - thick, h - thick));
        a.subtract(new Area(new Rectangle(thick, thick, w-thick*3, h-thick*3)));
        g2d.fill(a);
    }

Somehow this [post by Jim Graham ](https://markmail.org/search/?q=jim+graham+line+hidpi#query:jim%20graham%20line%20hidpi+page:1+mid:bwen5wqb5fogoh64+state:results )came back to mind while thinking about all this. I recall being interested that JavaFX "components are outlined using successive fills".

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From serb at openjdk.java.net  Tue Mar 22 01:29:38 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 22 Mar 2022 01:29:38 GMT
Subject: RFR: JDK-8283087: Create a test or JDK-4715503 [v2]
In-Reply-To: <fwoNvLAErQgB0kU-8J2eG6Q8XQ1E-HOZJH9aG86T5p0=.e786485c-6a61-45a4-8471-c5a88355427a@github.com>
References: <EKaHEfjou-QbJWzk5d74cD23a62vFExxy0w7BPkxWho=.a3fad8f0-dfb2-46d1-939b-61bf89d03f24@github.com>
 <--CGwuv4hE9W-Dd1coeg3-wFQpHK4TSv0KW8cnr6tlY=.1cc4e819-6bd3-4c23-bff6-15f4f4bcd4bf@github.com>
 <98wFqKtcm6f8ZOblwgL2O4VvBMx2_AzcQXC2fH-gCBg=.36702479-bbb2-41b1-9805-d78f659c5687@github.com>
 <fwoNvLAErQgB0kU-8J2eG6Q8XQ1E-HOZJH9aG86T5p0=.e786485c-6a61-45a4-8471-c5a88355427a@github.com>
Message-ID: <f5EL7umY1RJrEC0wse3YL4DeehDnPxbG9BssOplqeZ4=.a7c597b9-eea5-4af3-8e08-ca823e6a4d43@github.com>

On Thu, 17 Mar 2022 06:45:00 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Marked as reviewed by serb (Reviewer).
>
> @mrserb Can you please sponsor my changes?

@srmandal please confirm that the test works fine in the mach5.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7807


From mvs at openjdk.java.net  Tue Mar 22 01:31:35 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 22 Mar 2022 01:31:35 GMT
Subject: Integrated: 8282937: Write a regression test for JDK-4820080
In-Reply-To: <4bbhbCGRMxaAZkJPXi3B79QCUehtUtB5OuhmtCEm3Vw=.8a6e03c0-3215-48eb-8a6e-9c57cf01b095@github.com>
References: <4bbhbCGRMxaAZkJPXi3B79QCUehtUtB5OuhmtCEm3Vw=.8a6e03c0-3215-48eb-8a6e-9c57cf01b095@github.com>
Message-ID: <wzaK0v0c1yEFvDdYmrD7oyIm_TswzIp1YpbfzbNKUss=.a414cf0a-15c2-46f8-826a-57d24a860ee0@github.com>

On Sun, 13 Mar 2022 14:07:22 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Write a regression test for [JDK-4820080](https://bugs.openjdk.java.net/browse/JDK-4820080) : RFE: Cannot Change the JSplitPane Divider Color while dragging
> 
> Issue(as per bug description):
> I want to change the color of the JSplitPane divider. I
> opened the code and found that, the color is hard coded to
> darkGray while one is dragging the splitDivider. I have an
> application where the components on SplitPane have black
> background, So when i drag I can not see the split getting
> dragged. Can some one fix this, by externelising the
> SplitDivider color so that it can be changed at run time.
> 
> Testing:
> Java 1.4.1 -> Test Failed.
> $ ./j2sdk1.4.1/bin/java JSplitPaneDragColorTest
> Metal uses correct drag color false
> CDE/Motif uses correct drag color false
> Windows uses correct drag color false
> Test Failed.
> 
> Java 1.5.0 -> Test Failed.
> $ ./jdk1.5.0/bin/java JSplitPaneDragColorTest
> Metal uses correct drag color true
> Windows uses correct drag color true
> Windows Classic uses correct drag color true
> Test Passed.

This pull request has now been integrated.

Changeset: 849b1952
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/849b19523a666bd2ec110876bfd5679b20be77f4
Stats:     205 lines in 1 file changed: 205 ins; 0 del; 0 mod

8282937: Write a regression test for JDK-4820080

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/7803


From serb at openjdk.java.net  Tue Mar 22 01:34:41 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 22 Mar 2022 01:34:41 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v6]
In-Reply-To: <oc9A9PE5Mq_o16sPjsdgoqc2pGkAoEFft02Ee1jlA38=.f39df329-8872-445e-9fa8-8c4c3e289677@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oc9A9PE5Mq_o16sPjsdgoqc2pGkAoEFft02Ee1jlA38=.f39df329-8872-445e-9fa8-8c4c3e289677@github.com>
Message-ID: <4VLKsemnCqlgW4110GjZV8M53BN1Mok8eHDl1PZAP44=.1d4444b0-d90c-4763-9e74-6173d4dbcfae@github.com>

On Thu, 17 Mar 2022 23:50:21 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed apostrophe in comment of saveImage

It depends how slower the new code will be, probably performance will be similar?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From serb at openjdk.java.net  Tue Mar 22 01:37:34 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 22 Mar 2022 01:37:34 GMT
Subject: RFR: 8282860: Write a regression test for JDK-4164779 [v2]
In-Reply-To: <9xEXTZSoDUKzYfNcIq1aUdM-k2E7ZlhRZe-CpYZlhaE=.9623ad32-bd07-42bb-994b-42af1605997d@github.com>
References: <P0Nh5jqNbGyTlAXOw-82iw2zJl61Tf9iUKDq4OOH9rE=.34986f4d-60e5-4430-862f-91ea34620c2f@github.com>
 <9xEXTZSoDUKzYfNcIq1aUdM-k2E7ZlhRZe-CpYZlhaE=.9623ad32-bd07-42bb-994b-42af1605997d@github.com>
Message-ID: <eBsx5ChS9liALKpybb0TQlXzyFQJh6jFyU5TAx0EGTA=.c3110816-b481-47f4-8e7a-88c354a1a91c@github.com>

On Sun, 13 Mar 2022 14:01:25 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Write a regression test for [JDK-4164779](https://bugs.openjdk.java.net/browse/JDK-4164779) : JSplitPane keyboard navigation does not support F6 and Ctrl+Tab
>> 
>> 
>> Issue:
>> The specified keyboard support for JSplitPane also requires F6 and Ctrl+Tab (navigate out) for the JSplitPane. Those are currently not implemented.
>> 
>> F6 is supposed to move the focus from the current focused component on one side of the JSplitPane to the other side of the JSplitPane without having to tab through to that.
>> 
>> Ctrl+Tab is supposed to move the input focus from whatever component inside the JSplitPane that has the focus to the next component outside the JSplitPane.
>> 
>> 
>> Testing:
>> Java 1.4.0 -> Test Failed.
>> $ ./j2sdk1.4.0/bin/java JSplitPaneTest
>> Verifier 1 failed
>> Verifier 2 failed
>> Verifier 3 failed
>> Verifier 4 failed
>> Test Failed.
>> 
>> Java 1.4.1 -> Test Passed.
>> $ ./j2sdk1.4.1/bin/java JSplitPaneTest
>> Verifier 1 passed
>> Verifier 2 passed
>> Verifier 3 passed
>> Verifier 4 passed
>> Test Passed.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added Copyright header

Looks fine. I assume that mach5 is green

-------------

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7801


From serb at openjdk.java.net  Tue Mar 22 01:39:34 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 22 Mar 2022 01:39:34 GMT
Subject: RFR: 8282936: Write a regression test for JDK-4615365
In-Reply-To: <9V6N62EUXtJ_TlONZHRMlwpDU3Pqymgs7daipoaSrB4=.f9110cf2-ba95-4e23-a93d-45ba5dbfeca2@github.com>
References: <9V6N62EUXtJ_TlONZHRMlwpDU3Pqymgs7daipoaSrB4=.f9110cf2-ba95-4e23-a93d-45ba5dbfeca2@github.com>
Message-ID: <z8nLrvnpvlgIHmZtIdcezYTCC_yBVnGeIC6xnt9x77k=.7cb66fb4-89d0-4d21-b6eb-5462e797bd9c@github.com>

On Sun, 13 Mar 2022 13:54:47 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Write a regression test for [JDK-4615365](https://bugs.openjdk.java.net/browse/JDK-4615365) : JSplitPane current and last divider positions incorrect when realized
> 
> Issue:
> JSplitPane component with a left and right component has its current divider
> position incorrectly set to -1 once it is fully realized. For JDK 1.3.1, its
> value is set to 0. The current position of the divider should be the current
> position of the divider once layout management is complete. If the divider is
> moved one pixel, the current divider position is updated to the correct value
> but the last divider position is then set to -1 (i.e. the last value of the
> current divider position). If the divider is moved again, everything is OK.
> 
> Testing:
> Java 1.4.0 -> Test Failed.
> $ j2sdk1.4.0/bin/java bug4615365
> current= -1, last= 0
> Test Failed.
> 
> Java 1.4.1 -> Test Passed.
> $ j2sdk1.4.1/bin/java bug4615365
> current= 97, last= -1
> Test Passed.

test/jdk/javax/swing/JSplitPane/4615365/JSplitPaneDividerLocationTest.java line 52:

> 50:  * @key headful
> 51:  * @bug 4615365
> 52:  * @summary This test confirms that the JSplitPane current and last divider positions are correct when realized.

Please split the long lines to have 80 chars per line.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7802


From serb at openjdk.java.net  Tue Mar 22 02:05:28 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 22 Mar 2022 02:05:28 GMT
Subject: RFR: 8274735: javax.imageio.IIOException: Unsupported Image Type
 while processing a valid JPEG image [v2]
In-Reply-To: <kkMrJ3mLh2hD2fz968vOpUPm7XRMj2Nl6t0VPwFPpfc=.523668a3-3e68-4af1-a71f-d559252f04b9@github.com>
References: <gBv_Xtu5bmqpludbJWXwKpgvPCVz4BGYXbjErejjb1A=.cbe35817-d2cb-44bc-9f7b-d2597622623e@github.com>
 <kkMrJ3mLh2hD2fz968vOpUPm7XRMj2Nl6t0VPwFPpfc=.523668a3-3e68-4af1-a71f-d559252f04b9@github.com>
Message-ID: <Qw5ScniD19CHPmI6Lh42bmy0kS5uOiQZCrwOhHe6pWM=.240bcef2-e710-4166-b3c0-de14f9e48604@github.com>

On Fri, 18 Mar 2022 18:21:06 GMT, Phil Race <prr at openjdk.org> wrote:

>> The JDK's built-in Image I/O JPEG plugin decodes JPEGs which are YCbCr and RGb and Grayscale but rejects CMYK and YCCK JPEGs.
>> These would correspond to JFIF encapsulated JPEGs.
>> 
>> This was a reasonable decision to limit support to what was actually likely to be seen - CMYK JPEGs probably should just be created for direct to print devices and never seen on the internet as an interchange format.
>> 
>> Indeed this (below) RFC for mail suggests JFIF is what clients should transmit :
>> 
>> https://datatracker.ietf.org/doc/html/rfc2046 :  Multipurpose Internet Mail Extensions - Part 2
>> 
>> 
>>    A media type of "image" indicates that the body contains an image.
>>    The subtype names the specific image format.  These names are not
>>    case sensitive. An initial subtype is "jpeg" for the JPEG format
>>    using JFIF encoding [JPEG].
>> 
>> And for many years, browsers either failed to display CMYK JPEGs or displayed them incorrectly.
>> 
>> But alas they do crop up and when they do, Image I/O rejects them - to the surprise and
>> consternation of some developer who knows little of JPEGs and arcane colour spaces.
>> 
>> Full support of CMYK JPEGs via the whole Image I/O API including proper handling as metadata
>> will lead us down a path that might even extend into EXIF support for JPEG and likely will
>> require the JPEG Metadata spec to be updated. 
>> 
>> So the goal here is to skirt that as much as possible by just 
>> (1) not rejecting read of CMYK JPEGs and returning a BufferedImage with a suitable ColorModel
>> (2) allowing the same BufferedImage with that ColorSpace to be written back out again as CMYK JPEGs 
>> 
>> Reading will preserve any embedded ICC Color Profile, but writing will not re-encode it since
>> that requires work on metadata. That will have to be a follow-up fix, but at the very least it
>> means that a re-written JPEG will benefit from a default treatment CMYK by any other client.
>> 
>> A test is provided which verifies that the colours are interpreted reasonably, both on initial read
>> and on write and re-read. 
>> 
>> JPEGs with embedded profiles have been tested on read, but since there are licensing issues with those,
>> the test uses JPEGs which have no embedded profile and depend on an internal implementation class.
>> 
>> That class has its hashCode() method updated because testing showed that toString() invoked hashCode()
>> in a way that caused a StackOverflowError - so nothing per se to do with this fix but a necessary update.
>> 
>> Anyone who has trustworthy CMYK JPEGs that render properly in (eg) major web browsers but not with this
>> code can submit those JPEGs so I can evaluate.
>> 
>> But all our automated tests pass as well as some manual testing and evaluation etc.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274735: javax.imageio.IIOException: Unsupported Image Type while processing a valid JPEG image

src/java.desktop/share/classes/com/sun/imageio/plugins/common/SimpleCMYKColorSpace.java line 66:

> 64: 
> 65:     public int hashCode() {
> 66:         return System.identityHashCode(theInstance);

Is it just a cleanup or it has some other reason?

src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java line 1740:

> 1738:         raster.setRect(sourceLine);
> 1739:         if (invertCMYK) {
> 1740:             byte[] data = ((DataBufferByte)raster.getDataBuffer()).getData();

Is it known that the type of the raster here is always DataBufferByte?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7849


From smandalika at openjdk.java.net  Tue Mar 22 04:49:30 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Tue, 22 Mar 2022 04:49:30 GMT
Subject: RFR: JDK-8283087: Create a test or JDK-4715503 [v2]
In-Reply-To: <f5EL7umY1RJrEC0wse3YL4DeehDnPxbG9BssOplqeZ4=.a7c597b9-eea5-4af3-8e08-ca823e6a4d43@github.com>
References: <EKaHEfjou-QbJWzk5d74cD23a62vFExxy0w7BPkxWho=.a3fad8f0-dfb2-46d1-939b-61bf89d03f24@github.com>
 <--CGwuv4hE9W-Dd1coeg3-wFQpHK4TSv0KW8cnr6tlY=.1cc4e819-6bd3-4c23-bff6-15f4f4bcd4bf@github.com>
 <98wFqKtcm6f8ZOblwgL2O4VvBMx2_AzcQXC2fH-gCBg=.36702479-bbb2-41b1-9805-d78f659c5687@github.com>
 <fwoNvLAErQgB0kU-8J2eG6Q8XQ1E-HOZJH9aG86T5p0=.e786485c-6a61-45a4-8471-c5a88355427a@github.com>
 <f5EL7umY1RJrEC0wse3YL4DeehDnPxbG9BssOplqeZ4=.a7c597b9-eea5-4af3-8e08-ca823e6a4d43@github.com>
Message-ID: <cEm0VYgoQhFEWg4zSFLrlkRLeCKQcqMIIRRoboI1QcE=.eaad27bd-0b6c-4f87-bc0b-93bbe07ef822@github.com>

On Tue, 22 Mar 2022 01:26:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> @mrserb Can you please sponsor my changes?
>
> @srmandal please confirm that the test works fine in the mach5.

@mrserb Yes The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7807


From duke at openjdk.java.net  Tue Mar 22 05:31:32 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Tue, 22 Mar 2022 05:31:32 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable
In-Reply-To: <zfQQvk5LZ4fCIfoIZFBUjBcvPX2J6_Pa4A1KjGe2nhg=.29b270d9-3599-4f82-a69b-fc7dd3210d4f@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <uksHJqxb2IOTEeiGv1bGVuYlR1vpYwchxNpPKsxnIMA=.a4c5938e-457f-4238-9962-634abcc6a9d0@github.com>
 <zfQQvk5LZ4fCIfoIZFBUjBcvPX2J6_Pa4A1KjGe2nhg=.29b270d9-3599-4f82-a69b-fc7dd3210d4f@github.com>
Message-ID: <Y6Gq_Uw7ZXKia7lOC-i4xEFSBzXAMqdkNb9yoMRshQc=.51fa518f-adff-40cf-84b5-21f7bb969c1f@github.com>

On Mon, 21 Feb 2022 12:16:53 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Method `isAssignableFrom` is opposite: it brings unnecessary complexity in the code. And it's easy to confuse orders of parameters. Even JBS confirms that:

Maybe we?should?add `Class::isSubclassOf(Class<?>?that)` that?performs `that.isAssignableFrom(this)`:

-------------

PR: https://git.openjdk.java.net/jdk/pull/7061


From mvs at openjdk.java.net  Tue Mar 22 05:50:33 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 22 Mar 2022 05:50:33 GMT
Subject: RFR: 8282860: Write a regression test for JDK-4164779 [v2]
In-Reply-To: <9xEXTZSoDUKzYfNcIq1aUdM-k2E7ZlhRZe-CpYZlhaE=.9623ad32-bd07-42bb-994b-42af1605997d@github.com>
References: <P0Nh5jqNbGyTlAXOw-82iw2zJl61Tf9iUKDq4OOH9rE=.34986f4d-60e5-4430-862f-91ea34620c2f@github.com>
 <9xEXTZSoDUKzYfNcIq1aUdM-k2E7ZlhRZe-CpYZlhaE=.9623ad32-bd07-42bb-994b-42af1605997d@github.com>
Message-ID: <RhAkkZvaM5S74Bc_xOVJ4TNNboimuJLvr1NmJjpiNDc=.d7d9f9fb-028d-47b0-a674-a18b3859f2b9@github.com>

On Sun, 13 Mar 2022 14:01:25 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Write a regression test for [JDK-4164779](https://bugs.openjdk.java.net/browse/JDK-4164779) : JSplitPane keyboard navigation does not support F6 and Ctrl+Tab
>> 
>> 
>> Issue:
>> The specified keyboard support for JSplitPane also requires F6 and Ctrl+Tab (navigate out) for the JSplitPane. Those are currently not implemented.
>> 
>> F6 is supposed to move the focus from the current focused component on one side of the JSplitPane to the other side of the JSplitPane without having to tab through to that.
>> 
>> Ctrl+Tab is supposed to move the input focus from whatever component inside the JSplitPane that has the focus to the next component outside the JSplitPane.
>> 
>> 
>> Testing:
>> Java 1.4.0 -> Test Failed.
>> $ ./j2sdk1.4.0/bin/java JSplitPaneTest
>> Verifier 1 failed
>> Verifier 2 failed
>> Verifier 3 failed
>> Verifier 4 failed
>> Test Failed.
>> 
>> Java 1.4.1 -> Test Passed.
>> $ ./j2sdk1.4.1/bin/java JSplitPaneTest
>> Verifier 1 passed
>> Verifier 2 passed
>> Verifier 3 passed
>> Verifier 4 passed
>> Test Passed.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added Copyright header

> * JDK-8282860

Yes @mrserb, tested 10 times each in macos,windows and linux platforms using mach5 and got all pass.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7801


From mvs at openjdk.java.net  Tue Mar 22 06:29:16 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 22 Mar 2022 06:29:16 GMT
Subject: RFR: 8282936: Write a regression test for JDK-4615365 [v2]
In-Reply-To: <9V6N62EUXtJ_TlONZHRMlwpDU3Pqymgs7daipoaSrB4=.f9110cf2-ba95-4e23-a93d-45ba5dbfeca2@github.com>
References: <9V6N62EUXtJ_TlONZHRMlwpDU3Pqymgs7daipoaSrB4=.f9110cf2-ba95-4e23-a93d-45ba5dbfeca2@github.com>
Message-ID: <yw_9DjvBobMpI44IyNNqFJ3lcnwsl4uD9wlMupvPWRc=.3f861f01-a72e-49d5-b5c4-6bbb1ef9ee50@github.com>

> Write a regression test for [JDK-4615365](https://bugs.openjdk.java.net/browse/JDK-4615365) : JSplitPane current and last divider positions incorrect when realized
> 
> Issue:
> JSplitPane component with a left and right component has its current divider
> position incorrectly set to -1 once it is fully realized. For JDK 1.3.1, its
> value is set to 0. The current position of the divider should be the current
> position of the divider once layout management is complete. If the divider is
> moved one pixel, the current divider position is updated to the correct value
> but the last divider position is then set to -1 (i.e. the last value of the
> current divider position). If the divider is moved again, everything is OK.
> 
> Testing:
> Java 1.4.0 -> Test Failed.
> $ j2sdk1.4.0/bin/java bug4615365
> current= -1, last= 0
> Test Failed.
> 
> Java 1.4.1 -> Test Passed.
> $ j2sdk1.4.1/bin/java bug4615365
> current= 97, last= -1
> Test Passed.

Manukumar V S has updated the pull request incrementally with two additional commits since the last revision:

 - Removed extra blank line before import static
 - Review comment fixed: Limited 80 chars per line

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7802/files
  - new: https://git.openjdk.java.net/jdk/pull/7802/files/3ae1e194..9e810adf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7802&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7802&range=00-01

  Stats: 31 lines in 1 file changed: 17 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7802.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7802/head:pull/7802

PR: https://git.openjdk.java.net/jdk/pull/7802


From mvs at openjdk.java.net  Tue Mar 22 06:29:16 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 22 Mar 2022 06:29:16 GMT
Subject: RFR: 8282936: Write a regression test for JDK-4615365 [v2]
In-Reply-To: <z8nLrvnpvlgIHmZtIdcezYTCC_yBVnGeIC6xnt9x77k=.7cb66fb4-89d0-4d21-b6eb-5462e797bd9c@github.com>
References: <9V6N62EUXtJ_TlONZHRMlwpDU3Pqymgs7daipoaSrB4=.f9110cf2-ba95-4e23-a93d-45ba5dbfeca2@github.com>
 <z8nLrvnpvlgIHmZtIdcezYTCC_yBVnGeIC6xnt9x77k=.7cb66fb4-89d0-4d21-b6eb-5462e797bd9c@github.com>
Message-ID: <PDJvKuIiudJeflQQ2MyS9Z_0LozdMnHZT1i40s36zeM=.3423db81-4145-4768-a36b-c53cc29c427e@github.com>

On Tue, 22 Mar 2022 01:35:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Manukumar V S has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Removed extra blank line before import static
>>  - Review comment fixed: Limited 80 chars per line
>
> test/jdk/javax/swing/JSplitPane/4615365/JSplitPaneDividerLocationTest.java line 52:
> 
>> 50:  * @key headful
>> 51:  * @bug 4615365
>> 52:  * @summary This test confirms that the JSplitPane current and last divider positions are correct when realized.
> 
> Please split the long lines to have 80 chars per line.

Done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7802


From duke at openjdk.java.net  Tue Mar 22 06:45:23 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Tue, 22 Mar 2022 06:45:23 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v2]
In-Reply-To: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
Message-ID: <Wmpk5_KuW-4kGw0vYnCJTX-EkkvMvLBCV1GdINAOpi4=.3c653c01-b88a-4d20-822f-a2bc8833cc69@github.com>

> Removed the println() line from the Interrupted catch block. Since waitForID() Interrupt indicates completion of Image Loading, println as Interrupt handling was not required.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7754/files
  - new: https://git.openjdk.java.net/jdk/pull/7754/files/b2329828..2c5f048f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7754&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7754&range=00-01

  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7754.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7754/head:pull/7754

PR: https://git.openjdk.java.net/jdk/pull/7754


From smandalika at openjdk.java.net  Tue Mar 22 09:23:58 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Tue, 22 Mar 2022 09:23:58 GMT
Subject: Integrated: JDK-8283087: Create a test or JDK-4715503
In-Reply-To: <EKaHEfjou-QbJWzk5d74cD23a62vFExxy0w7BPkxWho=.a3fad8f0-dfb2-46d1-939b-61bf89d03f24@github.com>
References: <EKaHEfjou-QbJWzk5d74cD23a62vFExxy0w7BPkxWho=.a3fad8f0-dfb2-46d1-939b-61bf89d03f24@github.com>
Message-ID: <8yKg_DI-OTe3CtF41UMi2vlOScxstILGpHRK66uB3TU=.377753f2-536a-4dae-99ac-5d51ef17d3ea@github.com>

On Mon, 14 Mar 2022 09:28:50 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Create a test or [JDK-4715503](https://bugs.openjdk.java.net/browse/JDK-4715503)
> 
> The getAccessibleContext method for JTable column header cells returns an
>  AccessibleContext which cannot get the Bounding Rectangle for table header cells. The Bug causes problems with screen reader review mode.
> 
> The test added verifies that the are not exceptions and Bounding rectangles are returned for the Accessible Table Header Cells.
> 
> This review is for migrating tests from a closed test suite to open.

This pull request has now been integrated.

Changeset: a6fd0b21
Author:    Srinivas Mandalika <smandalika at openjdk.org>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a6fd0b21ddc1575366eed8d47191f6b14b2d7cb6
Stats:     91 lines in 1 file changed: 91 ins; 0 del; 0 mod

8283087: Create a test or JDK-4715503

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/7807


From aivanov at openjdk.java.net  Tue Mar 22 11:33:39 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 22 Mar 2022 11:33:39 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v2]
In-Reply-To: <Wmpk5_KuW-4kGw0vYnCJTX-EkkvMvLBCV1GdINAOpi4=.3c653c01-b88a-4d20-822f-a2bc8833cc69@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <Wmpk5_KuW-4kGw0vYnCJTX-EkkvMvLBCV1GdINAOpi4=.3c653c01-b88a-4d20-822f-a2bc8833cc69@github.com>
Message-ID: <0vX9Oiq882dqNtr8_jojM6V48M531uJYCmDSJLAqDe8=.1c960b8a-b862-4312-9cbe-6dd36b61babc@github.com>

On Tue, 22 Mar 2022 06:45:23 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> Removed the println() line from the Interrupted catch block. Since waitForID() Interrupt indicates completion of Image Loading, println as Interrupt handling was not required.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 324:

> 322:     protected void loadImage(Image image) {
> 323:         MediaTracker mTracker = getTracker();
> 324:         Boolean bIsInterrupted = false;

Why do you use object wrapper instead of the primitive `boolean` type?

In Java, you don't add type prefixes to variable names; `bIsInterrupted` should be `interrupted`.

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 341:

> 339:             {
> 340:                 loadStatus = MediaTracker.ABORTED;
> 341:             }

Did you compile this code?  
I can't see `interrupted` variable being declared.

Please follow Java Coding Style: a space between `if` and the opening parenthesis, the opening brace is on the same line rather than on its own line. The code that [I posted as a sample](https://github.com/openjdk/jdk/pull/7754#discussion_r831096445) follows the Java Style.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From duke at openjdk.java.net  Tue Mar 22 12:51:36 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Tue, 22 Mar 2022 12:51:36 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v2]
In-Reply-To: <0vX9Oiq882dqNtr8_jojM6V48M531uJYCmDSJLAqDe8=.1c960b8a-b862-4312-9cbe-6dd36b61babc@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <Wmpk5_KuW-4kGw0vYnCJTX-EkkvMvLBCV1GdINAOpi4=.3c653c01-b88a-4d20-822f-a2bc8833cc69@github.com>
 <0vX9Oiq882dqNtr8_jojM6V48M531uJYCmDSJLAqDe8=.1c960b8a-b862-4312-9cbe-6dd36b61babc@github.com>
Message-ID: <XMKt9ln5yA9WImY9SEGeaTlI7xIzjXTtSyGXjCdUsYg=.457c1da4-91e8-4f5d-a21f-5a3f20080774@github.com>

On Tue, 22 Mar 2022 11:30:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 341:
> 
>> 339:             {
>> 340:                 loadStatus = MediaTracker.ABORTED;
>> 341:             }
> 
> Did you compile this code?  
> I can't see `interrupted` variable being declared.
> 
> Please follow Java Coding Style: a space between `if` and the opening parenthesis, the opening brace is on the same line rather than on its own line. The code that [I posted as a sample](https://github.com/openjdk/jdk/pull/7754#discussion_r831096445) follows the Java Style.

Previous code I compiled and tested, the one I committed was not compiled and tested yet, had to commit coz I'm restoring my local repo, after restoring will make the changes and test locally and with mach5......

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From aivanov at openjdk.java.net  Tue Mar 22 13:22:34 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 22 Mar 2022 13:22:34 GMT
Subject: RFR: JDK-8282046: Create a regression test for JDK-8000326 [v5]
In-Reply-To: <ey8PY92wVdpIi7rFfwPcTb8KERivpiZv6d8rI-LJn5o=.e4e135e4-474a-404c-a4cc-ab0977408fcd@github.com>
References: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
 <ey8PY92wVdpIi7rFfwPcTb8KERivpiZv6d8rI-LJn5o=.e4e135e4-474a-404c-a4cc-ab0977408fcd@github.com>
Message-ID: <oSUEbIpTo8deKdTm9oGnFTeNCXek6AmxkdzBQzVwhjo=.f5a7238e-b066-44b8-b7ab-31e1e19b2dc7@github.com>

On Thu, 17 Mar 2022 08:13:20 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a regression test for CCC8000326
>> 
>> Issue is identified by [JDK-8000326](https://bugs.openjdk.java.net/browse/JDK-8000326), which identifies that after focus moves into JMenuBar, whose focus traversal key is disabled by default, it never moves to other focusable component.
>>  
>> By default, pressing the Tab key does not transfer focus from a JMenuBar which is added to a container together with other Swing components, because the focusTraversalKeysEnabled property of JMenuBar is set to false. To resolve this, you should call the JMenuBar.setFocusTraversalKeysEnabled(true) method.
>>  
>> The test verifies focus traversal for the above described scenario.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: setLocationRelativeTo(), DISPOSE_ON_CLOSE

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7512


From aivanov at openjdk.java.net  Tue Mar 22 13:22:34 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 22 Mar 2022 13:22:34 GMT
Subject: RFR: JDK-8282046: Create a regression test for JDK-8000326 [v2]
In-Reply-To: <Hyq78cD4ChtTJ6esAcW-jPm8SW3QmJW85w9YJ0zaw58=.b29fd74d-1441-4826-821e-5f2c3950991a@github.com>
References: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
 <FtIv0TNvzWFJ2ou3Eiku4QfO_R0fr9kCM8a14_7EocE=.f22595e7-9a17-4389-afe5-30edb3ce2c8d@github.com>
 <Hyq78cD4ChtTJ6esAcW-jPm8SW3QmJW85w9YJ0zaw58=.b29fd74d-1441-4826-821e-5f2c3950991a@github.com>
Message-ID: <ztENpJbd1MeexbWHnCyT-tVMbVdC3-nwFlrM0iyJtAE=.073ad98d-949f-4621-9261-cf1cba3a74f9@github.com>

On Fri, 11 Mar 2022 13:58:11 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> This review is for migrating tests from a closed test suite to open.

If you know when the test was first introduced, please update the copyright year to include the year when the test was originally written.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7512


From aivanov at openjdk.java.net  Tue Mar 22 13:27:37 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 22 Mar 2022 13:27:37 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v5]
In-Reply-To: <L1vRGB7-ntpIXCE5PgfCjxEIT7jOwqN8OTLM4tAsHI8=.2d5c1382-2a9d-41ec-aeae-12ee51224e07@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <F6o4zlCFWhp6lwZS3avKExKm94xu6chWTlfLZy1Ur0U=.ef89e65a-4b8d-458c-b36a-3e3236fdb950@github.com>
 <L1vRGB7-ntpIXCE5PgfCjxEIT7jOwqN8OTLM4tAsHI8=.2d5c1382-2a9d-41ec-aeae-12ee51224e07@github.com>
Message-ID: <DYEZfS9-CWcOxqbORZsrWRmRkQW070TH7Vq7SLzdAfM=.e6e1964c-5b6f-4c78-9ce3-ca33e5542107@github.com>

On Wed, 16 Mar 2022 13:41:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reverted HiDPIRobotScreenCaptureTest back to 8280861 with minor changes
>
> Let's give a while for Sergey and/or Phil to take a look. If no comments are received by this evening in Europe, I'll sponsor it.

> @aivanov-jdk ping

Sorry, @mkartashev, it slipped from my mind on Wednesday. And I decided not to integrate it over the long weekend because I wouldn't be watching CI mails closely.

The testing on CI has been successful so far.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From duke at openjdk.java.net  Tue Mar 22 13:36:40 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Tue, 22 Mar 2022 13:36:40 GMT
Subject: RFR: 8282270: java/awt/Robot Screen Capture tests fail after
 8280861 [v5]
In-Reply-To: <DYEZfS9-CWcOxqbORZsrWRmRkQW070TH7Vq7SLzdAfM=.e6e1964c-5b6f-4c78-9ce3-ca33e5542107@github.com>
References: <8HCDsHGSuDheojW6JRvidlZNmYGSftTKQ8f9mP_rI1A=.3407b062-6213-4960-b44c-1efc125ec7df@github.com>
 <F6o4zlCFWhp6lwZS3avKExKm94xu6chWTlfLZy1Ur0U=.ef89e65a-4b8d-458c-b36a-3e3236fdb950@github.com>
 <L1vRGB7-ntpIXCE5PgfCjxEIT7jOwqN8OTLM4tAsHI8=.2d5c1382-2a9d-41ec-aeae-12ee51224e07@github.com>
 <DYEZfS9-CWcOxqbORZsrWRmRkQW070TH7Vq7SLzdAfM=.e6e1964c-5b6f-4c78-9ce3-ca33e5542107@github.com>
Message-ID: <b2RXbwfTm8Ab-Fd8ZzHKKZuwSxP2gexsYMHiJHyWzl0=.86441d6e-6b59-4ed7-b3d2-b73728884d9e@github.com>

On Tue, 22 Mar 2022 13:24:15 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Let's give a while for Sergey and/or Phil to take a look. If no comments are received by this evening in Europe, I'll sponsor it.
>
>> @aivanov-jdk ping
> 
> Sorry, @mkartashev, it slipped from my mind on Wednesday. And I decided not to integrate it over the long weekend because I wouldn't be watching CI mails closely.
> 
> The testing on CI has been successful so far.

@aivanov-jdk No problem. Crossing fingers for a successful test run.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7613


From duke at openjdk.java.net  Tue Mar 22 15:14:34 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Tue, 22 Mar 2022 15:14:34 GMT
Subject: RFR: 8282771 : Create test case for JDK-8262981 [v4]
In-Reply-To: <pbRcgoRd0mYiHu3ASOMDqfVCJuyKZsKKSZd3JlguYaM=.0770dc62-36be-42e8-b88e-6425263fd6dd@github.com>
References: <pbRcgoRd0mYiHu3ASOMDqfVCJuyKZsKKSZd3JlguYaM=.0770dc62-36be-42e8-b88e-6425263fd6dd@github.com>
Message-ID: <GzhdPMWFiHKCcXkATmrIqnZdgMia_0zLbd1OtkgF3Ls=.81c65472-23b3-49e8-b194-f8647dd0c96b@github.com>

> Following methods are covered in this testcase
> getAccessibleAction()
> getAccessibleActionCount()
> doAccessibleAction(int direction) 
> 
> @shurymury

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  Fixed review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7734/files
  - new: https://git.openjdk.java.net/jdk/pull/7734/files/d0fb58df..8172e5cd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7734&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7734&range=02-03

  Stats: 25 lines in 1 file changed: 1 ins; 5 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7734.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7734/head:pull/7734

PR: https://git.openjdk.java.net/jdk/pull/7734


From duke at openjdk.java.net  Tue Mar 22 15:14:35 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Tue, 22 Mar 2022 15:14:35 GMT
Subject: RFR: 8282771 : Create test case for JDK-8262981 [v3]
In-Reply-To: <piMmMYBjTLIJnQvJFb7ANrRDaJFPNbwIc0a0tXimgnU=.ea5685cd-f530-4160-9930-b60515887813@github.com>
References: <pbRcgoRd0mYiHu3ASOMDqfVCJuyKZsKKSZd3JlguYaM=.0770dc62-36be-42e8-b88e-6425263fd6dd@github.com>
 <mt_vo_p7z80juhvjp6uSCtujUVrJxvlRYCgr5FiydOw=.ea947e60-f1ff-4fe8-8e01-c50117c135e2@github.com>
 <piMmMYBjTLIJnQvJFb7ANrRDaJFPNbwIc0a0tXimgnU=.ea5685cd-f530-4160-9930-b60515887813@github.com>
Message-ID: <6WpCzdQvOtg4np9Rh4BZNiaLAymrbxJShbM8Pnl9vWo=.e827c41e-c523-4919-b416-429ee9fa2d67@github.com>

On Mon, 21 Mar 2022 16:52:26 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed review comments
>
> test/jdk/javax/accessibility/JSlider/AccessibleAction/JSliderAccessibleAction.java line 74:
> 
>> 72:     private static volatile AtomicInteger currentJSliderValue;
>> 73:     private static volatile AtomicInteger jSliderInitialValue;
>> 74:     private static volatile AccessibleAction accessibleAction;
> 
> This field seem to be only accessed from the EDT, similar to UI components above, so why is it volatile and the components are not?

Fixed

> test/jdk/javax/accessibility/JSlider/AccessibleAction/JSliderAccessibleAction.java line 179:
> 
>> 177:                 validDecrementCountDownLatch = new CountDownLatch(1);
>> 178:                 validIncrementCountDownLatch = new CountDownLatch(1);
>> 179:                 currentJSliderValue = new AtomicInteger();
> 
> if this is a volatile, than perhaps you do not need an atomic?

Fixed

> test/jdk/javax/accessibility/JSlider/AccessibleAction/JSliderAccessibleAction.java line 265:
> 
>> 263:         robot.waitForIdle();
>> 264:         final Point[] point = new Point[1];
>> 265:         final Rectangle[] rect = new Rectangle[1];
> 
> finals here are redundant although do not hurt

Fixed

> test/jdk/javax/accessibility/JSlider/AccessibleAction/JSliderAccessibleAction.java line 282:
> 
>> 280:     public static void main(String[] args) throws InterruptedException,
>> 281:             InvocationTargetException, AWTException {
>> 282:         JSliderAccessibleAction jSliderAccessibleAction =
> 
> The class appears to have no state, why do you need an instance of it? Why not to make the methods static?

Fixed make the method to be static

-------------

PR: https://git.openjdk.java.net/jdk/pull/7734


From mvs at openjdk.java.net  Tue Mar 22 15:38:13 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 22 Mar 2022 15:38:13 GMT
Subject: RFR: 8283493: Create an automated regression test for RFE 4231298
Message-ID: <nVUH7AgirLhyqluMk5AAixvBtr64QzautJ7XTiHAHrM=.ae940c8a-cf66-4145-a0be-82f9d868ce76@github.com>

Create a regression test for [JDK-4231298](https://bugs.openjdk.java.net/browse/JDK-4231298)
Issue:
When a JComboBox first drops down, the renderer is called for
every element in the list, even those elements that will not
actually be drawn on the screen.

Fix:
Introduced new API to JComboBox: get/setPrototypeDisplayValue(). This API allows the UI to calculate the display size using this prototype value rather than iterated over a large list of items. See RFE 4289100 which also addresses this problem.

Testing:
1. Tested in Mach5, 10 times per platform(macos,linux and windows) and got all pass.

2. Tested in JDK 1.3.0 and JDK 1.4.0 and the results are given below.
Java 1.3.0 -> Test Failed.
$ jdk1.3/bin/java JComboBoxPrototypeTest
getListCellRendererComponent index = -1, isSelected = false, cellHasFocus = false
Value of the Counter is 1
....
getListCellRendererComponent index = -1, isSelected = false, cellHasFocus = false
Value of the Counter is 101
Test Failed
java.lang.RuntimeException: Custom Renderer got called 101 times, expected is maximum 6 times
        at JComboBoxPrototypeTestOld.main(JComboBoxPrototypeTest.java:107)

Java 1.4.0(added a call to setPrototypeDisplayValue()) -> Test Passed.
$ j2sdk1.4.0/bin/java JComboBoxPrototypeTest
getListCellRendererComponent index = -1, isSelected = false, cellHasFocus = false
Value of the Counter is 1
getListCellRendererComponent index = -1, isSelected = false, cellHasFocus = false
Value of the Counter is 2
getListCellRendererComponent index = -1, isSelected = false, cellHasFocus = false
Value of the Counter is 3
Test Passed

-------------

Commit messages:
 - 8283493: Create an automated regression test for RFE 4231298

Changes: https://git.openjdk.java.net/jdk/pull/7905/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7905&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283493
  Stats: 201 lines in 1 file changed: 201 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7905.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7905/head:pull/7905

PR: https://git.openjdk.java.net/jdk/pull/7905


From mvs at openjdk.java.net  Tue Mar 22 15:41:19 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 22 Mar 2022 15:41:19 GMT
Subject: RFR: 8283493: Create an automated regression test for RFE 4231298
 [v2]
In-Reply-To: <nVUH7AgirLhyqluMk5AAixvBtr64QzautJ7XTiHAHrM=.ae940c8a-cf66-4145-a0be-82f9d868ce76@github.com>
References: <nVUH7AgirLhyqluMk5AAixvBtr64QzautJ7XTiHAHrM=.ae940c8a-cf66-4145-a0be-82f9d868ce76@github.com>
Message-ID: <Fz7fEmoHO2zQfkVPtwGU49PQlOZI4o5w-jHjc-7cT-s=.53025d03-e6c1-4751-afae-94d141403ae9@github.com>

> Create a regression test for [JDK-4231298](https://bugs.openjdk.java.net/browse/JDK-4231298)
> Issue:
> When a JComboBox first drops down, the renderer is called for
> every element in the list, even those elements that will not
> actually be drawn on the screen.
> 
> Fix:
> Introduced new API to JComboBox: get/setPrototypeDisplayValue(). This API allows the UI to calculate the display size using this prototype value rather than iterated over a large list of items. See RFE 4289100 which also addresses this problem.
> 
> Testing:
> 1. Tested in Mach5, 10 times per platform(macos,linux and windows) and got all pass.
> 
> 2. Tested in JDK 1.3.0 and JDK 1.4.0 and the results are given below.
> Java 1.3.0 -> Test Failed.
> $ jdk1.3/bin/java JComboBoxPrototypeTest
> getListCellRendererComponent index = -1, isSelected = false, cellHasFocus = false
> Value of the Counter is 1
> ....
> getListCellRendererComponent index = -1, isSelected = false, cellHasFocus = false
> Value of the Counter is 101
> Test Failed
> java.lang.RuntimeException: Custom Renderer got called 101 times, expected is maximum 6 times
>         at JComboBoxPrototypeTestOld.main(JComboBoxPrototypeTest.java:107)
> 
> Java 1.4.0(added a call to setPrototypeDisplayValue()) -> Test Passed.
> $ j2sdk1.4.0/bin/java JComboBoxPrototypeTest
> getListCellRendererComponent index = -1, isSelected = false, cellHasFocus = false
> Value of the Counter is 1
> getListCellRendererComponent index = -1, isSelected = false, cellHasFocus = false
> Value of the Counter is 2
> getListCellRendererComponent index = -1, isSelected = false, cellHasFocus = false
> Value of the Counter is 3
> Test Passed

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Removed unwanted comment text

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7905/files
  - new: https://git.openjdk.java.net/jdk/pull/7905/files/2d5c9fb8..ce0e62e9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7905&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7905&range=00-01

  Stats: 17 lines in 1 file changed: 0 ins; 17 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7905.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7905/head:pull/7905

PR: https://git.openjdk.java.net/jdk/pull/7905


From mvs at openjdk.java.net  Tue Mar 22 16:26:32 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 22 Mar 2022 16:26:32 GMT
Subject: RFR: 8283507: Create a regression test for RFE 4287690
Message-ID: <SMPz0WRpMUC4SuuVSmlG6rsG_QudZ-1hCbjUzeMIdqk=.8318c1a4-4db6-4c0b-b24c-0b25b3d932a2@github.com>

Create a regression test for [JDK-4287690](https://bugs.openjdk.java.net/browse/JDK-4287690)
Issue description:
I want JComboBox to send an event just before the popup (drop down) list is displayed.

Fix:
This requires some additional API targeted for major release of the JDK (1.4).The PopupMenuEvent will from the JPopupMenu will be forwarded to the JComboBox. A client of the JComboBox can register itself as a PopupMenuListener to receive the notification.
So JComboBox should send drop down events when the drop down popup is visible as well as invisible. JComboBox.addPopupMenuListener(PopupMenuListener) can be used to register for pop up events.

Testing:
Tested using Mach5 in all platforms available(macos,linux and windows) and got all pass.

-------------

Commit messages:
 - 8283507: Create a regression test for RFE 4287690

Changes: https://git.openjdk.java.net/jdk/pull/7906/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7906&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283507
  Stats: 205 lines in 1 file changed: 205 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7906.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7906/head:pull/7906

PR: https://git.openjdk.java.net/jdk/pull/7906


From prr at openjdk.java.net  Tue Mar 22 19:01:11 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 22 Mar 2022 19:01:11 GMT
Subject: RFR: 8283457: [macos] libpng build failures with Xcode13.3
Message-ID: <wa3vN1iUpgY-40D25wQ3S6tQqVS4kLFKPlalc8BOeMM=.902111d4-e9ae-4b40-963c-6023ce6964d8@github.com>

Disable a warning from the Xcode 13.3 clang compiler when compiling libpng, which is used by libsplashscreen.

Policy is not to change the upstream code locally unless it is also changed in the same way upstream.
We could consider reporting it upstream but libpng releases are very infrequent.

-------------

Commit messages:
 - 8283457: [macos] libpng build failures with Xcode13.3

Changes: https://git.openjdk.java.net/jdk/pull/7911/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7911&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283457
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7911.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7911/head:pull/7911

PR: https://git.openjdk.java.net/jdk/pull/7911


From erikj at openjdk.java.net  Tue Mar 22 20:45:33 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 22 Mar 2022 20:45:33 GMT
Subject: RFR: 8283457: [macos] libpng build failures with Xcode13.3
In-Reply-To: <wa3vN1iUpgY-40D25wQ3S6tQqVS4kLFKPlalc8BOeMM=.902111d4-e9ae-4b40-963c-6023ce6964d8@github.com>
References: <wa3vN1iUpgY-40D25wQ3S6tQqVS4kLFKPlalc8BOeMM=.902111d4-e9ae-4b40-963c-6023ce6964d8@github.com>
Message-ID: <CG8qqJQJTm0xhZN0Z5XrATsvLJdj5BYuA-WGkz-Tce8=.1a1c08fa-8654-4704-adf3-4d4df309c378@github.com>

On Tue, 22 Mar 2022 18:53:20 GMT, Phil Race <prr at openjdk.org> wrote:

> Disable a warning from the Xcode 13.3 clang compiler when compiling libpng, which is used by libsplashscreen.
> 
> Policy is not to change the upstream code locally unless it is also changed in the same way upstream.
> We could consider reporting it upstream but libpng releases are very infrequent.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7911


From prr at openjdk.java.net  Tue Mar 22 21:52:29 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 22 Mar 2022 21:52:29 GMT
Subject: Integrated: 8283457: [macos] libpng build failures with Xcode13.3
In-Reply-To: <wa3vN1iUpgY-40D25wQ3S6tQqVS4kLFKPlalc8BOeMM=.902111d4-e9ae-4b40-963c-6023ce6964d8@github.com>
References: <wa3vN1iUpgY-40D25wQ3S6tQqVS4kLFKPlalc8BOeMM=.902111d4-e9ae-4b40-963c-6023ce6964d8@github.com>
Message-ID: <PbFrI4w1pYCtXIgy0pdDMf4vnUAVELECWmRnRO_YJ54=.1f8e66f1-ac50-4aa2-b1b8-11a12c39c8cc@github.com>

On Tue, 22 Mar 2022 18:53:20 GMT, Phil Race <prr at openjdk.org> wrote:

> Disable a warning from the Xcode 13.3 clang compiler when compiling libpng, which is used by libsplashscreen.
> 
> Policy is not to change the upstream code locally unless it is also changed in the same way upstream.
> We could consider reporting it upstream but libpng releases are very infrequent.

This pull request has now been integrated.

Changeset: 33eb89df
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/33eb89dfeb4a43e1ad2c3dd657ec3b6ee7abbb3a
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8283457: [macos] libpng build failures with Xcode13.3

Reviewed-by: erikj

-------------

PR: https://git.openjdk.java.net/jdk/pull/7911


From prr at openjdk.java.net  Tue Mar 22 21:53:33 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 22 Mar 2022 21:53:33 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v4]
In-Reply-To: <px566UftzNVHlLSDErQ3n9S7ZPQ_6sqMrDjNy6Z_4_Y=.e8381b27-170d-4eee-a4a2-47681573859f@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <px566UftzNVHlLSDErQ3n9S7ZPQ_6sqMrDjNy6Z_4_Y=.e8381b27-170d-4eee-a4a2-47681573859f@github.com>
Message-ID: <ie0g4psKNGe_3wmPrRnk1M3P_4O8e5LuGmvP9ADg8vE=.4b3f5866-9245-4f66-8733-7b081b0f46be@github.com>

On Wed, 16 Mar 2022 06:02:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   korean fallback added

Not ready yet

-------------

Changes requested by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7643


From serb at openjdk.java.net  Wed Mar 23 00:02:34 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 23 Mar 2022 00:02:34 GMT
Subject: RFR: 8282422: JTable.print() failed with
 UnsupportedCharsetException on AIX ko_KR locale
In-Reply-To: <WoFYqSGq8S5uRqiDH_FJ3ebGeinGkEI1c5_6H7omPnM=.db3d9c13-c0a7-454b-8872-034fec9daedc@github.com>
References: <WoFYqSGq8S5uRqiDH_FJ3ebGeinGkEI1c5_6H7omPnM=.db3d9c13-c0a7-454b-8872-034fec9daedc@github.com>
Message-ID: <ujcZQnOSiExl5IZkzYuVDT9ukgkbBUAbnm7t7Jo_0Zs=.e153c002-34bb-4de9-8254-886b2d1584f2@github.com>

On Sat, 26 Feb 2022 16:24:07 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> On AIX ko_KR locale, I could see following exception after JTable.print() was called
> 
> java.nio.charset.UnsupportedCharsetException: sun.font.X11KSC5601
>         at java.base/java.nio.charset.Charset.forName(Charset.java:527)
>         at java.desktop/sun.awt.FontConfiguration.getFontCharsetEncoder(FontConfiguration.java:964)
> ......
> 
> According to my investigation, sun.font.X11KSC5601 moved from sun.awt.motif.X11KSC5601.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7630


From serb at openjdk.java.net  Wed Mar 23 00:07:34 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 23 Mar 2022 00:07:34 GMT
Subject: RFR: JDK-8283015: Create a test for JDK-4715496 [v2]
In-Reply-To: <MH7nOHyv83GCYpLD9yKdQZkvoEFr8Cx1hO-aPZYhUoA=.9b5c843c-f02d-471f-84bb-168e0cce3b8a@github.com>
References: <FZTHpImv7BXOuuYK-42rwC55GssXPQH2S8hwVIvAsfw=.1ba518e0-5c7f-4ed6-a9ce-667a859142c1@github.com>
 <MH7nOHyv83GCYpLD9yKdQZkvoEFr8Cx1hO-aPZYhUoA=.9b5c843c-f02d-471f-84bb-168e0cce3b8a@github.com>
Message-ID: <PXlyVeHXD9v3CDLuoj0X6nhXGosGBwLKZIZbYv9a8FU=.909bc339-333c-42fc-8cbc-3e0c06302142@github.com>

On Mon, 14 Mar 2022 06:29:30 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a test for JDK-4715496
>> 
>> Issue observed in the above bug is that the JTable.AccessibleJTableCell.getAccessible name returns the cell instance string instead of the cell text.
>> The test is being added to verify the same.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   frame dispose call on EDT

test/jdk/javax/accessibility/8283015/AccessibleJTableCellNameTest.java line 28:

> 26:  * @key headful
> 27:  * @bug 4715496
> 28:  * @summary AccessibleJTableCell.getAccessible name incorrectly returns cell instance string instead of cell text.

Please split the long lines, use the 80 chars per line.

test/jdk/javax/accessibility/8283015/AccessibleJTableCellNameTest.java line 60:

> 58: 
> 59:             for (int i = 0; i <= colNames.length - 1; i++) {
> 60:                 Accessible accessible = jTable.getAccessibleContext().getAccessibleTable()

I remember a similar code in some other test which probably was integrated already. But I just found that the jtable here is a Swing component that should be accessed in the EDT.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7787


From serb at openjdk.java.net  Wed Mar 23 00:10:33 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 23 Mar 2022 00:10:33 GMT
Subject: RFR: 8283493: Create an automated regression test for RFE 4231298
 [v2]
In-Reply-To: <Fz7fEmoHO2zQfkVPtwGU49PQlOZI4o5w-jHjc-7cT-s=.53025d03-e6c1-4751-afae-94d141403ae9@github.com>
References: <nVUH7AgirLhyqluMk5AAixvBtr64QzautJ7XTiHAHrM=.ae940c8a-cf66-4145-a0be-82f9d868ce76@github.com>
 <Fz7fEmoHO2zQfkVPtwGU49PQlOZI4o5w-jHjc-7cT-s=.53025d03-e6c1-4751-afae-94d141403ae9@github.com>
Message-ID: <Miqq63SImgK26SgIWDoxTQjI08LhgoYTWfw2Q2GXy04=.f0c420ab-b1da-430b-a1b0-bd86749cb3ba@github.com>

On Tue, 22 Mar 2022 15:41:19 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Create a regression test for [JDK-4231298](https://bugs.openjdk.java.net/browse/JDK-4231298)
>> Issue:
>> When a JComboBox first drops down, the renderer is called for
>> every element in the list, even those elements that will not
>> actually be drawn on the screen.
>> 
>> Fix:
>> Introduced new API to JComboBox: get/setPrototypeDisplayValue(). This API allows the UI to calculate the display size using this prototype value rather than iterated over a large list of items. See RFE 4289100 which also addresses this problem.
>> 
>> Testing:
>> 1. Tested in Mach5, 10 times per platform(macos,linux and windows) and got all pass.
>> 
>> 2. Tested in JDK 1.3.0 and JDK 1.4.0 and the results are given below.
>> Java 1.3.0 -> Test Failed.
>> $ jdk1.3/bin/java JComboBoxPrototypeTest
>> getListCellRendererComponent index = -1, isSelected = false, cellHasFocus = false
>> Value of the Counter is 1
>> ....
>> getListCellRendererComponent index = -1, isSelected = false, cellHasFocus = false
>> Value of the Counter is 101
>> Test Failed
>> java.lang.RuntimeException: Custom Renderer got called 101 times, expected is maximum 6 times
>>         at JComboBoxPrototypeTestOld.main(JComboBoxPrototypeTest.java:107)
>> 
>> Java 1.4.0(added a call to setPrototypeDisplayValue()) -> Test Passed.
>> $ j2sdk1.4.0/bin/java JComboBoxPrototypeTest
>> getListCellRendererComponent index = -1, isSelected = false, cellHasFocus = false
>> Value of the Counter is 1
>> getListCellRendererComponent index = -1, isSelected = false, cellHasFocus = false
>> Value of the Counter is 2
>> getListCellRendererComponent index = -1, isSelected = false, cellHasFocus = false
>> Value of the Counter is 3
>> Test Passed
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unwanted comment text

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7905


From itakiguchi at openjdk.java.net  Wed Mar 23 01:42:32 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Wed, 23 Mar 2022 01:42:32 GMT
Subject: Integrated: 8282422: JTable.print() failed with
 UnsupportedCharsetException on AIX ko_KR locale
In-Reply-To: <WoFYqSGq8S5uRqiDH_FJ3ebGeinGkEI1c5_6H7omPnM=.db3d9c13-c0a7-454b-8872-034fec9daedc@github.com>
References: <WoFYqSGq8S5uRqiDH_FJ3ebGeinGkEI1c5_6H7omPnM=.db3d9c13-c0a7-454b-8872-034fec9daedc@github.com>
Message-ID: <jIJOd1PP13HREEHmTw8fLWsGHOJWDNe_VU95eCP4ixw=.05568e1e-a9d9-428e-8512-64a4445ed44b@github.com>

On Sat, 26 Feb 2022 16:24:07 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> On AIX ko_KR locale, I could see following exception after JTable.print() was called
> 
> java.nio.charset.UnsupportedCharsetException: sun.font.X11KSC5601
>         at java.base/java.nio.charset.Charset.forName(Charset.java:527)
>         at java.desktop/sun.awt.FontConfiguration.getFontCharsetEncoder(FontConfiguration.java:964)
> ......
> 
> According to my investigation, sun.font.X11KSC5601 moved from sun.awt.motif.X11KSC5601.

This pull request has now been integrated.

Changeset: 6ea996c2
Author:    Ichiroh Takiguchi <itakiguchi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6ea996c20591cafa9673d9c697437ce2c48e4616
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8282422: JTable.print() failed with UnsupportedCharsetException on AIX ko_KR locale

Reviewed-by: prr, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/7630


From mvs at openjdk.java.net  Wed Mar 23 05:31:10 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 23 Mar 2022 05:31:10 GMT
Subject: RFR: 8283507: Create a regression test for RFE 4287690 [v2]
In-Reply-To: <SMPz0WRpMUC4SuuVSmlG6rsG_QudZ-1hCbjUzeMIdqk=.8318c1a4-4db6-4c0b-b24c-0b25b3d932a2@github.com>
References: <SMPz0WRpMUC4SuuVSmlG6rsG_QudZ-1hCbjUzeMIdqk=.8318c1a4-4db6-4c0b-b24c-0b25b3d932a2@github.com>
Message-ID: <WnnAS2V7S8W5YMMCMbzOqtSYkhFbVrsakrGPFRRklYg=.4b504ee1-564d-44c1-be0a-07d90a93d288@github.com>

> Create a regression test for [JDK-4287690](https://bugs.openjdk.java.net/browse/JDK-4287690)
> Issue description:
> I want JComboBox to send an event just before the popup (drop down) list is displayed.
> 
> Fix:
> This requires some additional API targeted for major release of the JDK (1.4).The PopupMenuEvent will from the JPopupMenu will be forwarded to the JComboBox. A client of the JComboBox can register itself as a PopupMenuListener to receive the notification.
> So JComboBox should send drop down events when the drop down popup is visible as well as invisible. JComboBox.addPopupMenuListener(PopupMenuListener) can be used to register for pop up events.
> 
> Testing:
> Tested using Mach5 in all platforms available(macos,linux and windows) and got all pass.

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Added one more related bug id 4331058 to @bug tag

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7906/files
  - new: https://git.openjdk.java.net/jdk/pull/7906/files/d54c86aa..38a5e19e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7906&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7906&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7906.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7906/head:pull/7906

PR: https://git.openjdk.java.net/jdk/pull/7906


From smandalika at openjdk.java.net  Wed Mar 23 06:19:14 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 23 Mar 2022 06:19:14 GMT
Subject: RFR: JDK-8282046: Create a regression test for JDK-8000326 [v6]
In-Reply-To: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
References: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
Message-ID: <rEjS_yxXppRIrQ0peAVzBZ_6WHA8RJlVMRRtoZA1Wjs=.098d4ed2-b877-4a85-a167-08981cf4ea42@github.com>

> Create a regression test for CCC8000326
> 
> Issue is identified by [JDK-8000326](https://bugs.openjdk.java.net/browse/JDK-8000326), which identifies that after focus moves into JMenuBar, whose focus traversal key is disabled by default, it never moves to other focusable component.
>  
> By default, pressing the Tab key does not transfer focus from a JMenuBar which is added to a container together with other Swing components, because the focusTraversalKeysEnabled property of JMenuBar is set to false. To resolve this, you should call the JMenuBar.setFocusTraversalKeysEnabled(true) method.
>  
> The test verifies focus traversal for the above described scenario.
> This review is for migrating tests from a closed test suite to open.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed: Copyright header fixed with original year of test authorship

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7512/files
  - new: https://git.openjdk.java.net/jdk/pull/7512/files/a1ad2f87..ee31ac65

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7512&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7512&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7512.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7512/head:pull/7512

PR: https://git.openjdk.java.net/jdk/pull/7512


From duke at openjdk.java.net  Wed Mar 23 07:03:32 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 23 Mar 2022 07:03:32 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v3]
In-Reply-To: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
Message-ID: <cS_HA38cnBBMOkGGstw2bd7yPLkNct3LBhWduYmr2Zk=.92e3fafa-ce9f-41d2-9f1d-ac391a0e2889@github.com>

> Removed the println() line from the Interrupted catch block. Since waitForID() Interrupt indicates completion of Image Loading, println as Interrupt handling was not required.

Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' into branch_8236987
 - Merge branch 'master' of github.com:TejeshR13/jdk
 - Updated based on review comments
 - 8236987: Remove call to System.out.println from ImageIcon.loadImage
 - 8236987: Remove call to System.out.println from ImageIcon.loadImage
 - Merge branch 'master' of github.com:TejeshR13/jdk
 - Initial Commit.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7754/files
  - new: https://git.openjdk.java.net/jdk/pull/7754/files/2c5f048f..3b8c4456

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7754&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7754&range=01-02

  Stats: 391837 lines in 4935 files changed: 228417 ins; 138289 del; 25131 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7754.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7754/head:pull/7754

PR: https://git.openjdk.java.net/jdk/pull/7754


From aturbanov at openjdk.java.net  Wed Mar 23 07:31:23 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Wed, 23 Mar 2022 07:31:23 GMT
Subject: RFR: 8283426: Fix 'exeption' typo [v3]
In-Reply-To: <GQ2texGEM2KygMGYrTfvdInxH8ERh-OqfDaQE-Ie_FY=.aa211bbb-47e1-455d-8a04-90d068574078@github.com>
References: <GQ2texGEM2KygMGYrTfvdInxH8ERh-OqfDaQE-Ie_FY=.aa211bbb-47e1-455d-8a04-90d068574078@github.com>
Message-ID: <WmaCuM0G7lq-o4cq7c3Jn2Twu_mKdoK9760WnSywBmg=.fced4b27-2ab4-4c80-9950-320cf0273529@github.com>

> Fix repeated typo `exeption`

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8283426: Fix 'exeption' typo
  fix more typos, found by Sean Coffey

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7879/files
  - new: https://git.openjdk.java.net/jdk/pull/7879/files/4c1e68ed..1baca5ea

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7879&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7879&range=01-02

  Stats: 14 lines in 7 files changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7879.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7879/head:pull/7879

PR: https://git.openjdk.java.net/jdk/pull/7879


From smandalika at openjdk.java.net  Wed Mar 23 07:33:34 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 23 Mar 2022 07:33:34 GMT
Subject: RFR: JDK-8283015: Create a test for JDK-4715496 [v3]
In-Reply-To: <FZTHpImv7BXOuuYK-42rwC55GssXPQH2S8hwVIvAsfw=.1ba518e0-5c7f-4ed6-a9ce-667a859142c1@github.com>
References: <FZTHpImv7BXOuuYK-42rwC55GssXPQH2S8hwVIvAsfw=.1ba518e0-5c7f-4ed6-a9ce-667a859142c1@github.com>
Message-ID: <_M_UBaes7Rs0ab0_yXtYi5u2a9VsbXt011OL7fASmYI=.f98ca0e4-2f27-4997-a3ef-9fb8dad3844b@github.com>

> Create a test for JDK-4715496
> 
> Issue observed in the above bug is that the JTable.AccessibleJTableCell.getAccessible name returns the cell instance string instead of the cell text.
> The test is being added to verify the same.
> This review is for migrating tests from a closed test suite to open.

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

 - Review Comments Fixed: summary line character limit reduced and split for readability
 - Merge branch 'master' of github.com:openjdk/jdk into 8283015
 - frame dispose call on EDT
 - 8283015: Create a test for JDK-4715496

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7787/files
  - new: https://git.openjdk.java.net/jdk/pull/7787/files/2a91f085..0a775d62

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7787&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7787&range=01-02

  Stats: 342 lines in 29 files changed: 274 ins; 3 del; 65 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7787.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7787/head:pull/7787

PR: https://git.openjdk.java.net/jdk/pull/7787


From duke at openjdk.java.net  Wed Mar 23 08:18:07 2022
From: duke at openjdk.java.net (James Nord)
Date: Wed, 23 Mar 2022 08:18:07 GMT
Subject: RFR: 8280193: summary javadoc for
 java.awt.GraphicsEnvironment#preferPropotionalFonts broken
Message-ID: <mhGN4NF0_HP30ZMo4dmDmLnFMmciaf1fmAAEeWfIX5k=.f69d52f6-79ed-42bd-836b-3f31b2961be4@github.com>

https://bugs.openjdk.java.net/browse/JDK-8280193


Javadoc broke the first sentence at the full stop space (newline) so it rendered with `Indicates a preference for proportional over non-proportional (e.g.`

This is an incorrect sentence, and so this change fixes it by replacing the `e.g.` to `for example`

https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/GraphicsEnvironment.html

<img width="706" alt="image" src="https://user-images.githubusercontent.com/494726/149952315-651a4231-d641-4b73-8fea-93c83e1aa257.png">

-------------

Commit messages:
 - fix erronous javadoc first sentence

Changes: https://git.openjdk.java.net/jdk/pull/7127/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7127&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280193
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7127/head:pull/7127

PR: https://git.openjdk.java.net/jdk/pull/7127


From duke at openjdk.java.net  Wed Mar 23 08:18:07 2022
From: duke at openjdk.java.net (James Nord)
Date: Wed, 23 Mar 2022 08:18:07 GMT
Subject: RFR: 8280193: summary javadoc for
 java.awt.GraphicsEnvironment#preferPropotionalFonts broken
In-Reply-To: <mhGN4NF0_HP30ZMo4dmDmLnFMmciaf1fmAAEeWfIX5k=.f69d52f6-79ed-42bd-836b-3f31b2961be4@github.com>
References: <mhGN4NF0_HP30ZMo4dmDmLnFMmciaf1fmAAEeWfIX5k=.f69d52f6-79ed-42bd-836b-3f31b2961be4@github.com>
Message-ID: <YcYcLSD8JTt1_P9-jk07GVUw9RqcZQibXV-n0ifWcpw=.c75715bf-5602-4a6e-8fab-f999539fc274@github.com>

On Tue, 18 Jan 2022 14:05:55 GMT, James Nord <duke at openjdk.java.net> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8280193
> 
> 
> Javadoc broke the first sentence at the full stop space (newline) so it rendered with `Indicates a preference for proportional over non-proportional (e.g.`
> 
> This is an incorrect sentence, and so this change fixes it by replacing the `e.g.` to `for example`
> 
> https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/GraphicsEnvironment.html
> 
> <img width="706" alt="image" src="https://user-images.githubusercontent.com/494726/149952315-651a4231-d641-4b73-8fea-93c83e1aa257.png">

Bump

-------------

PR: https://git.openjdk.java.net/jdk/pull/7127


From djelinski at openjdk.java.net  Wed Mar 23 08:18:08 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 23 Mar 2022 08:18:08 GMT
Subject: RFR: 8280193: summary javadoc for
 java.awt.GraphicsEnvironment#preferPropotionalFonts broken
In-Reply-To: <mhGN4NF0_HP30ZMo4dmDmLnFMmciaf1fmAAEeWfIX5k=.f69d52f6-79ed-42bd-836b-3f31b2961be4@github.com>
References: <mhGN4NF0_HP30ZMo4dmDmLnFMmciaf1fmAAEeWfIX5k=.f69d52f6-79ed-42bd-836b-3f31b2961be4@github.com>
Message-ID: <370wekKFImLYylv24_U4OHeyt4YLhmdcyjpKcC2bRuQ=.e0575a41-0206-478f-a1a5-0ded4e63c119@github.com>

On Tue, 18 Jan 2022 14:05:55 GMT, James Nord <duke at openjdk.java.net> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8280193
> 
> 
> Javadoc broke the first sentence at the full stop space (newline) so it rendered with `Indicates a preference for proportional over non-proportional (e.g.`
> 
> This is an incorrect sentence, and so this change fixes it by replacing the `e.g.` to `for example`
> 
> https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/GraphicsEnvironment.html
> 
> <img width="706" alt="image" src="https://user-images.githubusercontent.com/494726/149952315-651a4231-d641-4b73-8fea-93c83e1aa257.png">

hi, you need to change the PR summary to get it reviewed; use this one:

8280193: summary javadoc for java.awt.GraphicsEnvironment#preferPropotionalFonts broken

-------------

PR: https://git.openjdk.java.net/jdk/pull/7127


From duke at openjdk.java.net  Wed Mar 23 09:03:31 2022
From: duke at openjdk.java.net (Jeremy)
Date: Wed, 23 Mar 2022 09:03:31 GMT
Subject: RFR: 8282526: Default icon is not painted properly
In-Reply-To: <JwSc0m39F3Fq8zZn27a77G166ydpKoExnQqHObthslM=.bd8445fc-9b59-4ca5-843b-6b89a8fcbee2@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <JwSc0m39F3Fq8zZn27a77G166ydpKoExnQqHObthslM=.bd8445fc-9b59-4ca5-843b-6b89a8fcbee2@github.com>
Message-ID: <a60VNcitBHhJjq7oKGwGe6PymmegejGAv5VkydEDKrY=.50ecf158-d308-4740-8798-8513b282a011@github.com>

On Mon, 14 Mar 2022 02:29:47 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> Detect the situation where we do need to perform interpolation during ImageIcon
>> painting and set a hint to the rendering to perform bicubic approximation so
>> image details are preserved during transition.
>
> test/jdk/javax/swing/ImageIcon/MultiResolutionImageIcon.java line 127:
> 
>> 125:         return null;
>> 126:     }
>> 127: }
> 
> This test reads a little strange to me. (I'm not an official openjdk reviewer, though, so feel free to disregard.)
> 
> If I run this test with the existing ImageIcon class it creates an image that resembles:
> ![image](https://user-images.githubusercontent.com/7669569/158093894-be7a73c6-6936-4725-bb09-cd054a2dccc2.png)
> 
> If I run this test with the revised code it creates an image that resembles:
> ![image](https://user-images.githubusercontent.com/7669569/158093939-bffc62c7-7a5c-4b0e-b71e-710c5049daf6.png)
> 
> Based on the changes in ImageIcon: I only expected to see changes related to rendering hints. (That is: I expected to see differences in antialiasing and scaling artifacts.)
> 
> Would you mind if I proposed a different test?

Ah, I figured out part of my confusion:

In my case (my primary monitor was set to 100% resolution): the ImageIcon we get back uses a BufferedImage that is 16x16. So when it is displayed on a 150% monitor it has to scale *up*.

Depending on your monitor resolution: you might start at a 32x32 BufferedImage that is scaling down. Or you might not have a BufferedImage at all: you might have their custom MultiResolutionIconImage (which is backed by a BufferedImage).

So all that is to say: I misunderstood the original code's design. And now it sounds like there a lot of separate convos here, so I'll make this my last comment unless someone wants to follow-up with anything.

Additional context/feedback:

The image in question is coming from Win32ShellFolder2#makeIcon(..)


<init>:315, BufferedImage (java.awt.image)
makeIcon:1020, Win32ShellFolder2 (sun.awt.shell)
call:1066, Win32ShellFolder2$15 (sun.awt.shell)
call:1039, Win32ShellFolder2$15 (sun.awt.shell)
run$$$capture:264, FutureTask (java.util.concurrent)
run:-1, FutureTask (java.util.concurrent)
 - Async stack trace
<init>:132, FutureTask (java.util.concurrent)
newTaskFor:108, AbstractExecutorService (java.util.concurrent)
submit:139, AbstractExecutorService (java.util.concurrent)
invoke:621, Win32ShellFolderManager2$ComInvoker (sun.awt.shell)
invoke:519, ShellFolder (sun.awt.shell)
invoke:505, ShellFolder (sun.awt.shell)
getIcon:1039, Win32ShellFolder2 (sun.awt.shell)
getSystemIcon:249, FileSystemView (javax.swing.filechooser)
main:19, SwingDemo


If we wanted to apply a resolution somewhere other than the ImageIcon class:

We could instead change makeIcon() to return a custom MultiResolutionImage that always applies interpolation. Here's a variation of the original bug's app that models this idea:

https://docs.google.com/document/d/1fcXJ9g6uTTZZlIt1BfzNFg2-Hs05CCpNRjyG1FnXKns/edit?usp=sharing

I could spin this up as a PR or discuss this further if requested. I'm not saying it's necessarily better; I'm just brainstorming other approaches.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7805


From smandalika at openjdk.java.net  Wed Mar 23 09:53:24 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 23 Mar 2022 09:53:24 GMT
Subject: RFR: JDK-8283015: Create a test for JDK-4715496 [v4]
In-Reply-To: <FZTHpImv7BXOuuYK-42rwC55GssXPQH2S8hwVIvAsfw=.1ba518e0-5c7f-4ed6-a9ce-667a859142c1@github.com>
References: <FZTHpImv7BXOuuYK-42rwC55GssXPQH2S8hwVIvAsfw=.1ba518e0-5c7f-4ed6-a9ce-667a859142c1@github.com>
Message-ID: <9zVu9UnNCZQw1c1uzZx6hantA_QC-VPr6gKsY0HEe-o=.4e3b01a4-4e0b-4ae2-a8e3-e83b27c4a8de@github.com>

> Create a test for JDK-4715496
> 
> Issue observed in the above bug is that the JTable.AccessibleJTableCell.getAccessible name returns the cell instance string instead of the cell text.
> The test is being added to verify the same.
> This review is for migrating tests from a closed test suite to open.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Review Comment Fixed: JTable accessed on EDT

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7787/files
  - new: https://git.openjdk.java.net/jdk/pull/7787/files/0a775d62..e78a4bca

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7787&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7787&range=02-03

  Stats: 10 lines in 1 file changed: 3 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7787.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7787/head:pull/7787

PR: https://git.openjdk.java.net/jdk/pull/7787


From duke at openjdk.java.net  Wed Mar 23 10:03:33 2022
From: duke at openjdk.java.net (James Nord)
Date: Wed, 23 Mar 2022 10:03:33 GMT
Subject: RFR: 8280193: summary javadoc for
 java.awt.GraphicsEnvironment#preferPropotionalFonts broken
In-Reply-To: <mhGN4NF0_HP30ZMo4dmDmLnFMmciaf1fmAAEeWfIX5k=.f69d52f6-79ed-42bd-836b-3f31b2961be4@github.com>
References: <mhGN4NF0_HP30ZMo4dmDmLnFMmciaf1fmAAEeWfIX5k=.f69d52f6-79ed-42bd-836b-3f31b2961be4@github.com>
Message-ID: <dwsLdJFqqY42zba8jrtsQFy_909pM9hheQuI97z64Iw=.03689527-d6a6-48b1-8a60-b77bdfe7805c@github.com>

On Tue, 18 Jan 2022 14:05:55 GMT, James Nord <duke at openjdk.java.net> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8280193
> 
> 
> Javadoc broke the first sentence at the full stop space (newline) so it rendered with `Indicates a preference for proportional over non-proportional (e.g.`
> 
> This is an incorrect sentence, and so this change fixes it by replacing the `e.g.` to `for example`
> 
> https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/GraphicsEnvironment.html
> 
> <img width="706" alt="image" src="https://user-images.githubusercontent.com/494726/149952315-651a4231-d641-4b73-8fea-93c83e1aa257.png">

src/java.desktop/share/classes/java/awt/GraphicsEnvironment.java line 360:

> 358: 
> 359:     /**
> 360:      * Indicates a preference for proportional over non-proportional (for

This does not use the newer `@summary` tag to allow for simple backporting to JDK8 which has the same issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7127


From smandalika at openjdk.java.net  Wed Mar 23 10:12:26 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 23 Mar 2022 10:12:26 GMT
Subject: RFR: JDK-8283015: Create a test for JDK-4715496 [v5]
In-Reply-To: <FZTHpImv7BXOuuYK-42rwC55GssXPQH2S8hwVIvAsfw=.1ba518e0-5c7f-4ed6-a9ce-667a859142c1@github.com>
References: <FZTHpImv7BXOuuYK-42rwC55GssXPQH2S8hwVIvAsfw=.1ba518e0-5c7f-4ed6-a9ce-667a859142c1@github.com>
Message-ID: <LZoJNyo70FyzluriaUuavhRaJHU9hAr2av72xD-hAQQ=.fd638c33-85e8-4f15-b3dd-b738d6cc20cb@github.com>

> Create a test for JDK-4715496
> 
> Issue observed in the above bug is that the JTable.AccessibleJTableCell.getAccessible name returns the cell instance string instead of the cell text.
> The test is being added to verify the same.
> This review is for migrating tests from a closed test suite to open.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Review Comment Fixed: JTable accessed on EDT

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7787/files
  - new: https://git.openjdk.java.net/jdk/pull/7787/files/e78a4bca..9e80598f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7787&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7787&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7787.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7787/head:pull/7787

PR: https://git.openjdk.java.net/jdk/pull/7787


From aivanov at openjdk.java.net  Wed Mar 23 10:15:36 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 23 Mar 2022 10:15:36 GMT
Subject: RFR: 8283426: Fix 'exeption' typo [v3]
In-Reply-To: <WmaCuM0G7lq-o4cq7c3Jn2Twu_mKdoK9760WnSywBmg=.fced4b27-2ab4-4c80-9950-320cf0273529@github.com>
References: <GQ2texGEM2KygMGYrTfvdInxH8ERh-OqfDaQE-Ie_FY=.aa211bbb-47e1-455d-8a04-90d068574078@github.com>
 <WmaCuM0G7lq-o4cq7c3Jn2Twu_mKdoK9760WnSywBmg=.fced4b27-2ab4-4c80-9950-320cf0273529@github.com>
Message-ID: <PHTlvzDTPTTNMLR4hVYVF-b6sT33nDUhum2LxtHNElk=.af6b9784-cf39-416f-bda6-5d46225c46a9@github.com>

On Wed, 23 Mar 2022 07:31:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Fix repeated typo `exeption`
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8283426: Fix 'exeption' typo
>   fix more typos, found by Sean Coffey

Marked as reviewed by aivanov (Reviewer).

test/jdk/javax/sql/testng/test/rowset/serial/SerialJavaObjectTests.java line 46:

> 44: 
> 45:     /*
> 46:      * Validate that an SerialException is thrown when the object specified

Suggestion:

     * Validate that a SerialException is thrown when the object specified

-------------

PR: https://git.openjdk.java.net/jdk/pull/7879


From aivanov at openjdk.java.net  Wed Mar 23 10:16:38 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 23 Mar 2022 10:16:38 GMT
Subject: RFR: JDK-8282046: Create a regression test for JDK-8000326 [v6]
In-Reply-To: <rEjS_yxXppRIrQ0peAVzBZ_6WHA8RJlVMRRtoZA1Wjs=.098d4ed2-b877-4a85-a167-08981cf4ea42@github.com>
References: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
 <rEjS_yxXppRIrQ0peAVzBZ_6WHA8RJlVMRRtoZA1Wjs=.098d4ed2-b877-4a85-a167-08981cf4ea42@github.com>
Message-ID: <Eiywl9-5cBk8YSdgpxSjCFtAzhenR2n9kY0DIdNvGKU=.1137b20a-b2b6-4459-a619-8304d1b86502@github.com>

On Wed, 23 Mar 2022 06:19:14 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a regression test for CCC8000326
>> 
>> Issue is identified by [JDK-8000326](https://bugs.openjdk.java.net/browse/JDK-8000326), which identifies that after focus moves into JMenuBar, whose focus traversal key is disabled by default, it never moves to other focusable component.
>>  
>> By default, pressing the Tab key does not transfer focus from a JMenuBar which is added to a container together with other Swing components, because the focusTraversalKeysEnabled property of JMenuBar is set to false. To resolve this, you should call the JMenuBar.setFocusTraversalKeysEnabled(true) method.
>>  
>> The test verifies focus traversal for the above described scenario.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: Copyright header fixed with original year of test authorship

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/Focus/8000326/SetFocusTraversalKeysEnabledTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2013,2022, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2013, 2022, Oracle and/or its affiliates. All rights reserved.

There has to be space after the comma.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7512


From ihse at openjdk.java.net  Wed Mar 23 12:33:05 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 23 Mar 2022 12:33:05 GMT
Subject: RFR: 8283323: libharfbuzz optimization level results in extreme build
 times
Message-ID: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>

[JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference linux machine. This was one of the four culprits that caused a 25-30% build time regression over the last two years.

The problem here was that the new HarfBuzz code caught really bad behaviour from gcc when compiling with optimizations. The official HarfBuzz build does not use any -O flags at all for gcc, so presumably the HarfBuzz team is:

a) not thinking compiler optimization is important for the performance of this library, and
b) unaware that their code causes such a headache for gcc.

(Other compilers fare much better: visual studio makes no difference at all, and for clang just a small regression was observed.)

The current optimization level was introduced by [JDK-8255790](https://bugs.openjdk.java.net/browse/JDK-8255790), which were really about moving libharfbuzz compilation back into libfontmanager. I could find no comments/discussion relating to the change of optimization level, so I assume it was incidental, and just seemed good at the time.

This patch changes the optimization level to `SIZE` (which is the closest thing we have to no optimization level) on gcc.

-------------

Commit messages:
 - 8283323: libharfbuzz optimization level results in extreme build times

Changes: https://git.openjdk.java.net/jdk/pull/7919/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7919&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283323
  Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7919.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7919/head:pull/7919

PR: https://git.openjdk.java.net/jdk/pull/7919


From duke at openjdk.java.net  Wed Mar 23 13:46:19 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 23 Mar 2022 13:46:19 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v4]
In-Reply-To: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
Message-ID: <mXKh2XjknyHCCLS9H3j9ImlKaCKsFee0Oj-Ewg_Q6RM=.4d194a95-c598-4f9e-925f-a5d9a9bea6d6@github.com>

> Removed the println() line from the Interrupted catch block. Since waitForID() Interrupt indicates completion of Image Loading, println as Interrupt handling was not required.

Tejesh R has updated the pull request incrementally with three additional commits since the last revision:

 - Merge branch 'branch_8236987' of github.com:TejeshR13/jdk into branch_8236987
 - Updated based on review comments
 - Merge remote-tracking branch 'upstream/master' into branch_8236987

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7754/files
  - new: https://git.openjdk.java.net/jdk/pull/7754/files/3b8c4456..a3268443

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7754&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7754&range=02-03

  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7754.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7754/head:pull/7754

PR: https://git.openjdk.java.net/jdk/pull/7754


From erikj at openjdk.java.net  Wed Mar 23 13:49:34 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 23 Mar 2022 13:49:34 GMT
Subject: RFR: 8283323: libharfbuzz optimization level results in extreme
 build times
In-Reply-To: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
References: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
Message-ID: <UL4GzHQTGhEh4lUgSHZia2oFzcJ7vvdd_7VCu-QgvK4=.1453217b-9b3d-46c4-a9e4-bdc4ab15cc07@github.com>

On Wed, 23 Mar 2022 12:25:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference linux machine. This was one of the four culprits that caused a 25-30% build time regression over the last two years.
> 
> The problem here was that the new HarfBuzz code caught really bad behaviour from gcc when compiling with optimizations. The official HarfBuzz build does not use any -O flags at all for gcc, so presumably the HarfBuzz team is:
> 
> a) not thinking compiler optimization is important for the performance of this library, and
> b) unaware that their code causes such a headache for gcc.
> 
> (Other compilers fare much better: visual studio makes no difference at all, and for clang just a small regression was observed.)
> 
> The current optimization level was introduced by [JDK-8255790](https://bugs.openjdk.java.net/browse/JDK-8255790), which were really about moving libharfbuzz compilation back into libfontmanager. I could find no comments/discussion relating to the change of optimization level, so I assume it was incidental, and just seemed good at the time.
> 
> This patch changes the optimization level to `SIZE` (which is the closest thing we have to no optimization level) on gcc.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7919


From duke at openjdk.java.net  Wed Mar 23 13:55:11 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 23 Mar 2022 13:55:11 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v5]
In-Reply-To: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
Message-ID: <ufxC9R6S5huL3GtQJ5G2-ev-ViVOhgXGYV3OwQtI35k=.8b695e80-9d9d-4956-babc-e6be6d69b641@github.com>

> Removed the println() line from the Interrupted catch block. Since waitForID() Interrupt indicates completion of Image Loading, println as Interrupt handling was not required.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7754/files
  - new: https://git.openjdk.java.net/jdk/pull/7754/files/a3268443..bb20e0ab

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7754&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7754&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7754.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7754/head:pull/7754

PR: https://git.openjdk.java.net/jdk/pull/7754


From duke at openjdk.java.net  Wed Mar 23 13:55:13 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 23 Mar 2022 13:55:13 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v2]
In-Reply-To: <0vX9Oiq882dqNtr8_jojM6V48M531uJYCmDSJLAqDe8=.1c960b8a-b862-4312-9cbe-6dd36b61babc@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <Wmpk5_KuW-4kGw0vYnCJTX-EkkvMvLBCV1GdINAOpi4=.3c653c01-b88a-4d20-822f-a2bc8833cc69@github.com>
 <0vX9Oiq882dqNtr8_jojM6V48M531uJYCmDSJLAqDe8=.1c960b8a-b862-4312-9cbe-6dd36b61babc@github.com>
Message-ID: <5vCYwwMSmlQP54-k0menNnzeM5WsS3A_r4HvI9WWkOQ=.bf53333c-d664-4052-9920-adf21efcc92d@github.com>

On Tue, 22 Mar 2022 11:30:31 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> Changes requested by aivanov (Reviewer).

@aivanov-jdk , could you please review now and check if the updates are fine.......? I've run in mach5 and tested locally...... In the testcase, without interrupt the output is `COMPLETE` and with interrupt the output is `ABORTED`....... Anything else needs to be tested.......?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From shade at openjdk.java.net  Wed Mar 23 15:57:31 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 23 Mar 2022 15:57:31 GMT
Subject: RFR: 8283323: libharfbuzz optimization level results in extreme
 build times
In-Reply-To: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
References: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
Message-ID: <YzmwOHvIDZiWxP3kAPIa2GXUm6AWQb1OhIgmlJFj1bc=.f1e34f6c-3f67-40a8-a891-5de70d106b6f@github.com>

On Wed, 23 Mar 2022 12:25:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference linux machine. This was one of the four culprits that caused a 25-30% build time regression over the last two years.
> 
> The problem here was that the new HarfBuzz code caught really bad behaviour from gcc when compiling with optimizations. The official HarfBuzz build does not use any -O flags at all for gcc, so presumably the HarfBuzz team is:
> 
> a) not thinking compiler optimization is important for the performance of this library, and
> b) unaware that their code causes such a headache for gcc.
> 
> (Other compilers fare much better: visual studio makes no difference at all, and for clang just a small regression was observed.)
> 
> The current optimization level was introduced by [JDK-8255790](https://bugs.openjdk.java.net/browse/JDK-8255790), which were really about moving libharfbuzz compilation back into libfontmanager. I could find no comments/discussion relating to the change of optimization level, so I assume it was incidental, and just seemed good at the time.
> 
> This patch changes the optimization level to `SIZE` (which is the closest thing we have to no optimization level) on gcc.

I have a question, though, because I suppose font rendering engine is performance sensitive. AFAICS, the `LIBFONTMANAGER_OPTIMIZATION` was changed from `HIGH` to `HIGHEST` here: https://github.com/openjdk/jdk/commit/05fe06a6#diff-c75e2d581b3730cf900075cedb66ac72eaba40fbbd92eaac5710161830b572b4L534-R491

Does it mean we should instead downgrade to `HIGH`, not `SIZE`? Would that recover the build times?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7919


From aivanov at openjdk.java.net  Wed Mar 23 18:22:31 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 23 Mar 2022 18:22:31 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v5]
In-Reply-To: <ufxC9R6S5huL3GtQJ5G2-ev-ViVOhgXGYV3OwQtI35k=.8b695e80-9d9d-4956-babc-e6be6d69b641@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <ufxC9R6S5huL3GtQJ5G2-ev-ViVOhgXGYV3OwQtI35k=.8b695e80-9d9d-4956-babc-e6be6d69b641@github.com>
Message-ID: <P5QO9YcTiVM_W9Su3IgsY0cSQAxI42svDRdIwLWYSYk=.79627a3a-e218-4a4f-b7e2-f1ef1e67cfda@github.com>

On Wed, 23 Mar 2022 13:55:11 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> Removed the println() line from the Interrupted catch block. Since waitForID() Interrupt indicates completion of Image Loading, println as Interrupt handling was not required.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

It looks good now.

Is it possible to add a regression test? We have one now, don't we? It just needs to be done as a jtreg automated test which verifies the status is any of the _done_ statuses, not `LOADING`.

A more complicated test could also verify the printed message is gone.

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 338:

> 336:             mTracker.removeImage(image, id);
> 337: 
> 338:             if (interrupted && ((loadStatus & MediaTracker.LOADING )!= 0)) {

Suggestion:

            if (interrupted && ((loadStatus & MediaTracker.LOADING ) != 0)) {

There should be one space on either side of a binary operator.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From achung at openjdk.java.net  Wed Mar 23 18:24:05 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 23 Mar 2022 18:24:05 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v7]
In-Reply-To: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
Message-ID: <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>

> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  scale stroke width at higher scalings

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7449/files
  - new: https://git.openjdk.java.net/jdk/pull/7449/files/75ec24d4..9109b84b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=05-06

  Stats: 17 lines in 1 file changed: 8 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7449.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7449/head:pull/7449

PR: https://git.openjdk.java.net/jdk/pull/7449


From achung at openjdk.java.net  Wed Mar 23 18:24:08 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 23 Mar 2022 18:24:08 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v6]
In-Reply-To: <oc9A9PE5Mq_o16sPjsdgoqc2pGkAoEFft02Ee1jlA38=.f39df329-8872-445e-9fa8-8c4c3e289677@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oc9A9PE5Mq_o16sPjsdgoqc2pGkAoEFft02Ee1jlA38=.f39df329-8872-445e-9fa8-8c4c3e289677@github.com>
Message-ID: <ajrWaaNFc62Pz0hyecjGJfdavBDcveCJx0V2AMdlqzQ=.579e49ca-30c6-4c74-aab4-feb94ede8dd4@github.com>

On Thu, 17 Mar 2022 23:50:21 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed apostrophe in comment of saveImage

I don't have a monitor that can go higher than 175%, so I'm not able to test the code well... Can you try the recent change to see if it works at 200+%? If not, I'll try using the area approach.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From aivanov at openjdk.java.net  Wed Mar 23 18:27:32 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 23 Mar 2022 18:27:32 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v6]
In-Reply-To: <ajrWaaNFc62Pz0hyecjGJfdavBDcveCJx0V2AMdlqzQ=.579e49ca-30c6-4c74-aab4-feb94ede8dd4@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oc9A9PE5Mq_o16sPjsdgoqc2pGkAoEFft02Ee1jlA38=.f39df329-8872-445e-9fa8-8c4c3e289677@github.com>
 <ajrWaaNFc62Pz0hyecjGJfdavBDcveCJx0V2AMdlqzQ=.579e49ca-30c6-4c74-aab4-feb94ede8dd4@github.com>
Message-ID: <E63RDxBkxozgxBZ_IP6mkIwsI9XNGqOIg3PmacBEGqM=.cb5396d4-0caa-4cbd-8692-1867e52d0803@github.com>

On Wed, 23 Mar 2022 18:19:58 GMT, Alisen Chung <achung at openjdk.org> wrote:

> I don't have a monitor that can go higher than 175%, so I'm not able to test the code well... Can you try the recent change to see if it works at 200+%? If not, I'll try using the area approach.

You can pass `-Dsun.java2d.uiScale=2.0` or `-Dsun.java2d.uiScale=3.0` to run the test as if the scale is set to 200% or 300%. You can also use 1.25, 1.5 or another value to change the app scale without changing your system settings.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From achung at openjdk.java.net  Wed Mar 23 18:27:33 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 23 Mar 2022 18:27:33 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v6]
In-Reply-To: <E63RDxBkxozgxBZ_IP6mkIwsI9XNGqOIg3PmacBEGqM=.cb5396d4-0caa-4cbd-8692-1867e52d0803@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oc9A9PE5Mq_o16sPjsdgoqc2pGkAoEFft02Ee1jlA38=.f39df329-8872-445e-9fa8-8c4c3e289677@github.com>
 <ajrWaaNFc62Pz0hyecjGJfdavBDcveCJx0V2AMdlqzQ=.579e49ca-30c6-4c74-aab4-feb94ede8dd4@github.com>
 <E63RDxBkxozgxBZ_IP6mkIwsI9XNGqOIg3PmacBEGqM=.cb5396d4-0caa-4cbd-8692-1867e52d0803@github.com>
Message-ID: <LDzOlJ6Z1rwgz8Tn_G6qiInDzNJMwzlQ-beuKg1Sz1Y=.8e2efa7b-015a-448a-a05a-e0b4ea9af328@github.com>

On Wed, 23 Mar 2022 18:23:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > I don't have a monitor that can go higher than 175%, so I'm not able to test the code well... Can you try the recent change to see if it works at 200+%? If not, I'll try using the area approach.
> 
> You can pass `-Dsun.java2d.uiScale=2.0` or `-Dsun.java2d.uiScale=3.0` to run the test as if the scale is set to 200% or 300%. You can also use 1.25, 1.5 or another value to change the app scale without changing your system settings.

Got it, let me do that then

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From ihse at openjdk.java.net  Wed Mar 23 18:55:27 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 23 Mar 2022 18:55:27 GMT
Subject: RFR: 8283323: libharfbuzz optimization level results in extreme
 build times
In-Reply-To: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
References: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
Message-ID: <ac1CwtLI8clz9AwvYtjz5OHBeOIf5tE-DJx5z4GYicQ=.32459598-6003-4d58-b797-72a7b7db38e5@github.com>

On Wed, 23 Mar 2022 12:25:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference linux machine. This was one of the four culprits that caused a 25-30% build time regression over the last two years.
> 
> The problem here was that the new HarfBuzz code caught really bad behaviour from gcc when compiling with optimizations. The official HarfBuzz build does not use any -O flags at all for gcc, so presumably the HarfBuzz team is:
> 
> a) not thinking compiler optimization is important for the performance of this library, and
> b) unaware that their code causes such a headache for gcc.
> 
> (Other compilers fare much better: visual studio makes no difference at all, and for clang just a small regression was observed.)
> 
> The current optimization level was introduced by [JDK-8255790](https://bugs.openjdk.java.net/browse/JDK-8255790), which were really about moving libharfbuzz compilation back into libfontmanager. I could find no comments/discussion relating to the change of optimization level, so I assume it was incidental, and just seemed good at the time.
> 
> This patch changes the optimization level to `SIZE` (which is the closest thing we have to no optimization level) on gcc.

No, unfortunately it won't. :( The problem started with the update to HarfBuzz 2.7.2,  and there the opt level was HIGH. I also tested manually compiling with -O1 (which we don't really have a level for in the build system) and even that was too problematic for gcc.

But another approach is possible. I talked off-list with Erik, and he had noticed (as had I) that a single file in harfbuzz was responsible for the lion's share of the build time regression. What he did, though, that I didn't come to think of, was to try to change optimization level for just that file. This fixes most of the build time regression, while being a much less intrusive fix. It also makes sense to do this fix for clang, since the 8 second regression seen there is basically also completely due to this file.

So I'll upload an update too this fix that is more conservative, and only changes opt level for a single file.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7919


From erikj at openjdk.java.net  Wed Mar 23 19:04:24 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 23 Mar 2022 19:04:24 GMT
Subject: RFR: 8283323: libharfbuzz optimization level results in extreme
 build times
In-Reply-To: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
References: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
Message-ID: <aolPiCjZJTZO0ByvGDdXmmMVWQI9hf9p3JriZBjzt88=.7177903a-e8d3-4cb3-9324-e76fd52716d1@github.com>

On Wed, 23 Mar 2022 12:25:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference linux machine. This was one of the four culprits that caused a 25-30% build time regression over the last two years.
> 
> The problem here was that the new HarfBuzz code caught really bad behaviour from gcc when compiling with optimizations. The official HarfBuzz build does not use any -O flags at all for gcc, so presumably the HarfBuzz team is:
> 
> a) not thinking compiler optimization is important for the performance of this library, and
> b) unaware that their code causes such a headache for gcc.
> 
> (Other compilers fare much better: visual studio makes no difference at all, and for clang just a small regression was observed.)
> 
> The current optimization level was introduced by [JDK-8255790](https://bugs.openjdk.java.net/browse/JDK-8255790), which were really about moving libharfbuzz compilation back into libfontmanager. I could find no comments/discussion relating to the change of optimization level, so I assume it was incidental, and just seemed good at the time.
> 
> This patch changes the optimization level to `SIZE` (which is the closest thing we have to no optimization level) on gcc.

> I have a question, though, because I suppose font rendering engine is performance sensitive. AFAICS, the `LIBFONTMANAGER_OPTIMIZATION` was changed from `HIGH` to `HIGHEST` here: [05fe06a6#diff-c75e2d581b3730cf900075cedb66ac72eaba40fbbd92eaac5710161830b572b4L534-R491](https://github.com/openjdk/jdk/commit/05fe06a6#diff-c75e2d581b3730cf900075cedb66ac72eaba40fbbd92eaac5710161830b572b4L534-R491)
> 
> Does it mean we should instead downgrade to `HIGH`, not `SIZE`? Would that recover the build times?

For GCC on Linux, that doesn't make a difference as both HIGH and HIGHEST translate to -O3.

I've been looking a bit at this too, and there are a handful of files that stick out, hb-subset.cc is the worst one. Here are the top three on my Linux host (using 31 threads), first with -O3 and then with Os:

[TIME:0:18.36] hb-subset-plan.cc
[TIME:0:21.53] hb-ot-layout.cc
[TIME:0:35.63] hb-subset.cc

[TIME:0:12.51] hb-subset-plan.cc
[TIME:0:14.81] hb-ot-layout.cc
[TIME:0:21.40] hb-subset.cc

On my mac (6 threads, but single core perf is higher), the corresponding numbers are:

[TIME:0:14.46] hb-subset-plan.cc
[TIME:0:19.64] hb-ot-layout.cc
[TIME:0:27.45] hb-subset.cc

[TIME:0:11.69] hb-subset-plan.cc
[TIME:0:16.00] hb-ot-layout.cc
[TIME:0:20.68] hb-subset.cc

This is certainly not quite as bad, but still a clear difference.

The reason this has such a high impact on total compilation time is due to how java.desktop ends up being one of the last top level targets on the critical path of possible concurrency. So a single compilation unit here will stall the whole process on a machine with many threads (32 in my case). On a smaller machine, this impact will be much less pronounced. Here are the total compilation times for "make exploded-image" with a few different settings:

all libfontmanager HIGHEST
linux: 4m14.174s
macosx: 7m8.736s

all libfontmanager SIZE
linux: 3m56.134s
macosx: 7m5.966s

just the above 3 files SIZE
linux: 3m57.009s
macosx: (skipped, no point)

The difference on the smaller macosx machine is negligible. Most of the compilation time gain on the big machine is gained by just dropping the optimization level on a few files. 

One could certainly argue that dropping the optimization level for libfontmanager is only helping a rather niche usecase. There could certainly be other compilation units that would have a similar effect on total build time due to how they end up on the critical path, I would be surprised if there aren't. The question is which ones we can safely drop the optimization level for without adversely affect performance of the finished product.

For this particular change it's probably better to at least just drop it for one or a few files.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7919


From prr at openjdk.java.net  Wed Mar 23 19:38:25 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 23 Mar 2022 19:38:25 GMT
Subject: RFR: 8283323: libharfbuzz optimization level results in extreme
 build times
In-Reply-To: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
References: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
Message-ID: <jNEreVt36E0asr1GOwuyhQnIE7WkVaxuUZEzThyr7Ao=.9d5bd45f-a2e0-44cb-9212-1a5f8f06c11c@github.com>

On Wed, 23 Mar 2022 12:25:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference linux machine. This was one of the four culprits that caused a 25-30% build time regression over the last two years.
> 
> The problem here was that the new HarfBuzz code caught really bad behaviour from gcc when compiling with optimizations. The official HarfBuzz build does not use any -O flags at all for gcc, so presumably the HarfBuzz team is:
> 
> a) not thinking compiler optimization is important for the performance of this library, and
> b) unaware that their code causes such a headache for gcc.
> 
> (Other compilers fare much better: visual studio makes no difference at all, and for clang just a small regression was observed.)
> 
> The current optimization level was introduced by [JDK-8255790](https://bugs.openjdk.java.net/browse/JDK-8255790), which were really about moving libharfbuzz compilation back into libfontmanager. I could find no comments/discussion relating to the change of optimization level, so I assume it was incidental, and just seemed good at the time.
> 
> This patch changes the optimization level to `SIZE` (which is the closest thing we have to no optimization level) on gcc.

We definitely do not want to downgrade the optimisation level of the entire library.
Performance of this library actually matters quite a lot.
When we added some additional checking to the previous library we used (ICU) we had complaints of as much as 20% loss
in PDF conversion (a backend process) and we've had escalations on user responsiveness in editors due to the computational complexity of layout vs just counting glyph advances.
Getting that performance back was a lot of work .. except increasing compiler optimisation was the easy one that made a big difference. 
To see the performance degradation may require a specific combination of font (Linux fonts vary widely) and the text being laid out. 
The example we used in the previous case required a windows font, so I don't have a handy test case  I know will show this .. and it was years ago .. 

Looking at the list of files from Erik, I think we don't use the subset functionality. Certainly not directly and likely not at all.
So downgrading that probably won't have any impact at all at runtime.

But hb-ot-layout.cc is one of the most important files in the library, maybe the most important.

I strongly suggest that one not be downgraded just for 7 seconds of build time.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7919


From aturbanov at openjdk.java.net  Wed Mar 23 19:41:58 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Wed, 23 Mar 2022 19:41:58 GMT
Subject: RFR: 8283426: Fix 'exeption' typo [v4]
In-Reply-To: <GQ2texGEM2KygMGYrTfvdInxH8ERh-OqfDaQE-Ie_FY=.aa211bbb-47e1-455d-8a04-90d068574078@github.com>
References: <GQ2texGEM2KygMGYrTfvdInxH8ERh-OqfDaQE-Ie_FY=.aa211bbb-47e1-455d-8a04-90d068574078@github.com>
Message-ID: <48NxGvP43iL5AnO2fxDF1vmpTZ6RxcQp4x6oaHxkEOQ=.ccd35bda-80d8-40da-8a89-bb004adc2ed2@github.com>

> Fix repeated typo `exeption`

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8283426: Fix 'exeption' typo
  
  Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7879/files
  - new: https://git.openjdk.java.net/jdk/pull/7879/files/1baca5ea..2ee3c98a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7879&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7879&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7879.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7879/head:pull/7879

PR: https://git.openjdk.java.net/jdk/pull/7879


From avu at openjdk.java.net  Wed Mar 23 20:41:18 2022
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Wed, 23 Mar 2022 20:41:18 GMT
Subject: RFR: 8273355: Flickering on tooltip appearance IntelliJ IDEA 2021.2.1
Message-ID: <_Q4d9YdOccAdjO6LsIlbIOt55Bn7PGAz3-NmVBF2vLU=.01b029e3-f88f-4b6b-b12b-3509f9dcd486@github.com>

Used setOpaque() method to set correct background of platform window
Extracted setting background to the particular method in PlatformWindow. Provided appropriate implementation in CPlatformWindow.

-------------

Commit messages:
 - 8273355: Flickering on tooltip appearance IntelliJ IDEA 2021.2.1

Changes: https://git.openjdk.java.net/jdk/pull/7931/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7931&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273355
  Stats: 25 lines in 5 files changed: 25 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7931.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7931/head:pull/7931

PR: https://git.openjdk.java.net/jdk/pull/7931


From ihse at openjdk.java.net  Wed Mar 23 20:56:46 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 23 Mar 2022 20:56:46 GMT
Subject: RFR: 8283323: libharfbuzz optimization level results in extreme
 build times
In-Reply-To: <jNEreVt36E0asr1GOwuyhQnIE7WkVaxuUZEzThyr7Ao=.9d5bd45f-a2e0-44cb-9212-1a5f8f06c11c@github.com>
References: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
 <jNEreVt36E0asr1GOwuyhQnIE7WkVaxuUZEzThyr7Ao=.9d5bd45f-a2e0-44cb-9212-1a5f8f06c11c@github.com>
Message-ID: <KfyTNOgRK92Mk7O9UILSbyEdTnFnSFIUE3GEUawMJAI=.82f68c81-1cd2-40d0-9a17-d434f45d3fcf@github.com>

On Wed, 23 Mar 2022 19:35:22 GMT, Phil Race <prr at openjdk.org> wrote:

>> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference linux machine. This was one of the four culprits that caused a 25-30% build time regression over the last two years.
>> 
>> The problem here was that the new HarfBuzz code caught really bad behaviour from gcc when compiling with optimizations. The official HarfBuzz build does not use any -O flags at all for gcc, so presumably the HarfBuzz team is:
>> 
>> a) not thinking compiler optimization is important for the performance of this library, and
>> b) unaware that their code causes such a headache for gcc.
>> 
>> (Other compilers fare much better: visual studio makes no difference at all, and for clang just a small regression was observed.)
>> 
>> The current optimization level was introduced by [JDK-8255790](https://bugs.openjdk.java.net/browse/JDK-8255790), which were really about moving libharfbuzz compilation back into libfontmanager. I could find no comments/discussion relating to the change of optimization level, so I assume it was incidental, and just seemed good at the time.
>> 
>> This patch changes the optimization level to `SIZE` (which is the closest thing we have to no optimization level) on gcc.
>
> We definitely do not want to downgrade the optimisation level of the entire library.
> Performance of this library actually matters quite a lot.
> When we added some additional checking to the previous library we used (ICU) we had complaints of as much as 20% loss
> in PDF conversion (a backend process) and we've had escalations on user responsiveness in editors due to the computational complexity of layout vs just counting glyph advances.
> Getting that performance back was a lot of work .. except increasing compiler optimisation was the easy one that made a big difference. 
> To see the performance degradation may require a specific combination of font (Linux fonts vary widely) and the text being laid out. 
> The example we used in the previous case required a windows font, so I don't have a handy test case  I know will show this .. and it was years ago .. 
> 
> Looking at the list of files from Erik, I think we don't use the subset functionality. Certainly not directly and likely not at all.
> So downgrading that probably won't have any impact at all at runtime.
> 
> But hb-ot-layout.cc is one of the most important files in the library, maybe the most important.
> 
> I strongly suggest that one not be downgraded just for 7 seconds of build time.

@prrace If we're not using the subset functionality, can we remove the files entirely, or exclude them from compilation?

(In the meantime, I'm preparing a patch which only limits optimization to the two subset files Erik listed)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7919


From prr at openjdk.java.net  Wed Mar 23 21:04:08 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 23 Mar 2022 21:04:08 GMT
Subject: RFR: 8283323: libharfbuzz optimization level results in extreme
 build times
In-Reply-To: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
References: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
Message-ID: <KQBTTH9Ql3WWCwKGYd10Q54jEXiuF83ySiG2fYs5X5k=.b0ad4890-25c4-4239-a0e8-12147a07e98a@github.com>

On Wed, 23 Mar 2022 12:25:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference linux machine. This was one of the four culprits that caused a 25-30% build time regression over the last two years.
> 
> The problem here was that the new HarfBuzz code caught really bad behaviour from gcc when compiling with optimizations. The official HarfBuzz build does not use any -O flags at all for gcc, so presumably the HarfBuzz team is:
> 
> a) not thinking compiler optimization is important for the performance of this library, and
> b) unaware that their code causes such a headache for gcc.
> 
> (Other compilers fare much better: visual studio makes no difference at all, and for clang just a small regression was observed.)
> 
> The current optimization level was introduced by [JDK-8255790](https://bugs.openjdk.java.net/browse/JDK-8255790), which were really about moving libharfbuzz compilation back into libfontmanager. I could find no comments/discussion relating to the change of optimization level, so I assume it was incidental, and just seemed good at the time.
> 
> This patch changes the optimization level to `SIZE` (which is the closest thing we have to no optimization level) on gcc.

harfbuzz does not make it easy to subset the build. So no.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7919


From ihse at openjdk.java.net  Wed Mar 23 21:13:30 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 23 Mar 2022 21:13:30 GMT
Subject: RFR: 8283323: libharfbuzz optimization level results in extreme
 build times [v2]
In-Reply-To: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
References: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
Message-ID: <k44JRBhviYe-x_vhHQ-n5NnMAwpnSmK7OQ8oPXxUhBw=.1af97bcf-87e5-4755-8d01-b578a61e7665@github.com>

> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference linux machine. This was one of the four culprits that caused a 25-30% build time regression over the last two years.
> 
> The problem here was that the new HarfBuzz code caught really bad behaviour from gcc when compiling with optimizations. The official HarfBuzz build does not use any -O flags at all for gcc, so presumably the HarfBuzz team is:
> 
> a) not thinking compiler optimization is important for the performance of this library, and
> b) unaware that their code causes such a headache for gcc.
> 
> (Other compilers fare much better: visual studio makes no difference at all, and for clang just a small regression was observed.)
> 
> The current optimization level was introduced by [JDK-8255790](https://bugs.openjdk.java.net/browse/JDK-8255790), which were really about moving libharfbuzz compilation back into libfontmanager. I could find no comments/discussion relating to the change of optimization level, so I assume it was incidental, and just seemed good at the time.
> 
> This patch changes the optimization level to `SIZE` (which is the closest thing we have to no optimization level) on gcc.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Restore HIGHEST for entire lib, just set SIZE to two files

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7919/files
  - new: https://git.openjdk.java.net/jdk/pull/7919/files/20ab768f..b491f6fb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7919&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7919&range=00-01

  Stats: 8 lines in 1 file changed: 1 ins; 2 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7919.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7919/head:pull/7919

PR: https://git.openjdk.java.net/jdk/pull/7919


From ihse at openjdk.java.net  Wed Mar 23 21:22:46 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 23 Mar 2022 21:22:46 GMT
Subject: RFR: 8283323: libharfbuzz optimization level results in extreme
 build times [v2]
In-Reply-To: <k44JRBhviYe-x_vhHQ-n5NnMAwpnSmK7OQ8oPXxUhBw=.1af97bcf-87e5-4755-8d01-b578a61e7665@github.com>
References: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
 <k44JRBhviYe-x_vhHQ-n5NnMAwpnSmK7OQ8oPXxUhBw=.1af97bcf-87e5-4755-8d01-b578a61e7665@github.com>
Message-ID: <f3HmHq8t9zeVsmdkqnQQk7N1bDnFu-ElB7JvYprseY4=.bc5047a8-a332-484b-a509-df5612c624a5@github.com>

On Wed, 23 Mar 2022 21:13:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference linux machine. This was one of the four culprits that caused a 25-30% build time regression over the last two years.
>> 
>> The problem here was that the new HarfBuzz code caught really bad behaviour from gcc when compiling with optimizations. The official HarfBuzz build does not use any -O flags at all for gcc, so presumably the HarfBuzz team is:
>> 
>> a) not thinking compiler optimization is important for the performance of this library, and
>> b) unaware that their code causes such a headache for gcc.
>> 
>> (Other compilers fare much better: visual studio makes no difference at all, and for clang just a small regression was observed.)
>> 
>> The current optimization level was introduced by [JDK-8255790](https://bugs.openjdk.java.net/browse/JDK-8255790), which were really about moving libharfbuzz compilation back into libfontmanager. I could find no comments/discussion relating to the change of optimization level, so I assume it was incidental, and just seemed good at the time.
>> 
>> This patch changes the optimization level to `SIZE` (which is the closest thing we have to no optimization level) on gcc.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore HIGHEST for entire lib, just set SIZE to two files

Changing just these two files removes most of the build time regression. I'm okay with that.

Going forward I'd like to understand *why* this is on the critical path, and if there's anything we can do about it. But that's much more complex than just addressing this regression in build times. I'm also pondering if we could help make somehow by hinting that files like subset and layout take a long time to compile, and schedule them early, so we don't suddenly find us inn the position of waiting for just them to be able to link the library. I'm suspecting that if the file was named hb-aarrdwark.cc it would not have impacted the total build time as much as now...

-------------

PR: https://git.openjdk.java.net/jdk/pull/7919


From prr at openjdk.java.net  Wed Mar 23 22:40:48 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 23 Mar 2022 22:40:48 GMT
Subject: RFR: 8283323: libharfbuzz optimization level results in extreme
 build times [v2]
In-Reply-To: <k44JRBhviYe-x_vhHQ-n5NnMAwpnSmK7OQ8oPXxUhBw=.1af97bcf-87e5-4755-8d01-b578a61e7665@github.com>
References: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
 <k44JRBhviYe-x_vhHQ-n5NnMAwpnSmK7OQ8oPXxUhBw=.1af97bcf-87e5-4755-8d01-b578a61e7665@github.com>
Message-ID: <EgZ4bxF2N2_AEhM3FxJZ2k8GmQ8VihVi91tK3A1MktQ=.f2eba44b-ded3-4698-b06b-7115f8a2786d@github.com>

On Wed, 23 Mar 2022 21:13:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference linux machine. This was one of the four culprits that caused a 25-30% build time regression over the last two years.
>> 
>> The problem here was that the new HarfBuzz code caught really bad behaviour from gcc when compiling with optimizations. The official HarfBuzz build does not use any -O flags at all for gcc, so presumably the HarfBuzz team is:
>> 
>> a) not thinking compiler optimization is important for the performance of this library, and
>> b) unaware that their code causes such a headache for gcc.
>> 
>> (Other compilers fare much better: visual studio makes no difference at all, and for clang just a small regression was observed.)
>> 
>> The current optimization level was introduced by [JDK-8255790](https://bugs.openjdk.java.net/browse/JDK-8255790), which were really about moving libharfbuzz compilation back into libfontmanager. I could find no comments/discussion relating to the change of optimization level, so I assume it was incidental, and just seemed good at the time.
>> 
>> This patch changes the optimization level to `SIZE` (which is the closest thing we have to no optimization level) on gcc.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore HIGHEST for entire lib, just set SIZE to two files

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 487:

> 485: LIBFONTMANAGER_OPTIMIZATION := HIGHEST
> 486: 
> 487: ifneq ($(filter $(TOOLCHAIN_TYPE), gcc clang), )

Can we have a note here that the de-opt is possible because these two files aren't important to OpenJDK ?
If these files were to be renamed in an updated version of harfbuzz, would there be a compilation error ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7919


From prr at openjdk.java.net  Wed Mar 23 22:54:47 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 23 Mar 2022 22:54:47 GMT
Subject: RFR: 8270331 : [TESTBUG] Error: Not a test or directory containing
 tests: java/awt/print/PrinterJob/InitToBlack.java
In-Reply-To: <ILihQKqFsB85AIFHTbJK1Im9hB60SJ_OJzDgdUB1dbg=.bf0f4b07-fd40-4eca-b2eb-e5f38b311d72@github.com>
References: <ILihQKqFsB85AIFHTbJK1Im9hB60SJ_OJzDgdUB1dbg=.bf0f4b07-fd40-4eca-b2eb-e5f38b311d72@github.com>
Message-ID: <AbVxDcg5hEqieFa5BVlxT5fgH8VY9M_GEjsPs0f13fo=.2e777ab3-88f3-4a39-a658-6f78473d95e8@github.com>

On Thu, 17 Mar 2022 21:47:12 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> 1) Removed =yesno since it was throwing Error: Not a test or directory containing tests
> 2) Test was just printing the "Test passes" on the printer and user did not had any option to mark the test as pass or fail and test was always passing. so created test UI with test instruction and test controls to mark the test pass or fail and checking the end result of the test.
> 
> @shurymury

Marked as reviewed by prr (Reviewer).

test/jdk/java/awt/print/PrinterJob/InitToBlack.java line 172:

> 170:         if (!CountDownLatch.await(2, TimeUnit.MINUTES)) {
> 171:             throw new RuntimeException("Timeout : User did not decided " +
> 172:                     "whether test passed or failed");

decided => decide

-------------

PR: https://git.openjdk.java.net/jdk/pull/7860


From duke at openjdk.java.net  Wed Mar 23 23:05:41 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Wed, 23 Mar 2022 23:05:41 GMT
Subject: RFR: 8270331 : [TESTBUG] Error: Not a test or directory containing
 tests: java/awt/print/PrinterJob/InitToBlack.java [v2]
In-Reply-To: <ILihQKqFsB85AIFHTbJK1Im9hB60SJ_OJzDgdUB1dbg=.bf0f4b07-fd40-4eca-b2eb-e5f38b311d72@github.com>
References: <ILihQKqFsB85AIFHTbJK1Im9hB60SJ_OJzDgdUB1dbg=.bf0f4b07-fd40-4eca-b2eb-e5f38b311d72@github.com>
Message-ID: <KGipHZETwiDWzFZKm0Bl-xVWnfrvNJvZ2P4-iE6P_qw=.e62963c4-8589-429f-8873-9808d617fd01@github.com>

> 1) Removed =yesno since it was throwing Error: Not a test or directory containing tests
> 2) Test was just printing the "Test passes" on the printer and user did not had any option to mark the test as pass or fail and test was always passing. so created test UI with test instruction and test controls to mark the test pass or fail and checking the end result of the test.
> 
> @shurymury

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  Fixed minor spelling

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7860/files
  - new: https://git.openjdk.java.net/jdk/pull/7860/files/0ec16305..a269ab3e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7860&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7860&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7860.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7860/head:pull/7860

PR: https://git.openjdk.java.net/jdk/pull/7860


From duke at openjdk.java.net  Wed Mar 23 23:05:42 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Wed, 23 Mar 2022 23:05:42 GMT
Subject: RFR: 8270331 : [TESTBUG] Error: Not a test or directory containing
 tests: java/awt/print/PrinterJob/InitToBlack.java [v2]
In-Reply-To: <AbVxDcg5hEqieFa5BVlxT5fgH8VY9M_GEjsPs0f13fo=.2e777ab3-88f3-4a39-a658-6f78473d95e8@github.com>
References: <ILihQKqFsB85AIFHTbJK1Im9hB60SJ_OJzDgdUB1dbg=.bf0f4b07-fd40-4eca-b2eb-e5f38b311d72@github.com>
 <AbVxDcg5hEqieFa5BVlxT5fgH8VY9M_GEjsPs0f13fo=.2e777ab3-88f3-4a39-a658-6f78473d95e8@github.com>
Message-ID: <iV0ZKEWyCK0OzI7oM9a5EyDggQREol8-8Vr-4PezdCc=.2d3cdf00-8d5a-4168-bea4-f1254452136d@github.com>

On Wed, 23 Mar 2022 22:51:17 GMT, Phil Race <prr at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed minor spelling
>
> test/jdk/java/awt/print/PrinterJob/InitToBlack.java line 172:
> 
>> 170:         if (!CountDownLatch.await(2, TimeUnit.MINUTES)) {
>> 171:             throw new RuntimeException("Timeout : User did not decided " +
>> 172:                     "whether test passed or failed");
> 
> decided => decide

Fixed decided => decide

-------------

PR: https://git.openjdk.java.net/jdk/pull/7860


From duke at openjdk.java.net  Wed Mar 23 23:13:47 2022
From: duke at openjdk.java.net (lukeu)
Date: Wed, 23 Mar 2022 23:13:47 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v6]
In-Reply-To: <LDzOlJ6Z1rwgz8Tn_G6qiInDzNJMwzlQ-beuKg1Sz1Y=.8e2efa7b-015a-448a-a05a-e0b4ea9af328@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oc9A9PE5Mq_o16sPjsdgoqc2pGkAoEFft02Ee1jlA38=.f39df329-8872-445e-9fa8-8c4c3e289677@github.com>
 <ajrWaaNFc62Pz0hyecjGJfdavBDcveCJx0V2AMdlqzQ=.579e49ca-30c6-4c74-aab4-feb94ede8dd4@github.com>
 <E63RDxBkxozgxBZ_IP6mkIwsI9XNGqOIg3PmacBEGqM=.cb5396d4-0caa-4cbd-8692-1867e52d0803@github.com>
 <LDzOlJ6Z1rwgz8Tn_G6qiInDzNJMwzlQ-beuKg1Sz1Y=.8e2efa7b-015a-448a-a05a-e0b4ea9af328@github.com>
Message-ID: <bQL6UKho0Da7UUeaiJCGIl9pJ12T1-XGy_xQz5ud-98=.362b4332-0384-422b-be1b-8c09d994dff2@github.com>

On Wed, 23 Mar 2022 18:25:31 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Can you try the recent change to see if it works at 200+%?

Sure, if it still helps here's a screenshot at 250% scaling. It shows `TitledBorder`  constructed with:
 * top: The JDK's `EtchedBorder` with the latest commit
 * bottom: a custom `Border` testing out the `Area` idea
 * (The "Title 2" in both cases is showing `RAISED`)

![JDK-8279614-patch3-scaling_250-zoom_x1](https://user-images.githubusercontent.com/2722420/159801708-592e9e4d-875b-4b89-aede-306a4f24d78a.png)

> It depends how slower the new code will be, probably performance will be similar?

Out of curiosity, is there is any code/documentation specific to micro-benchmarking or automated profiling of rendering code? (Also for future reference if I find time to dabble further in Swing tweaking.)

The following is not very scientific, but just putting the code for the screenshot above into in a large window (around 4000x1800px), and logging times like this:

        Box box = new Box(BoxLayout.Y_AXIS) {
            @Override
            protected void paintChildren(java.awt.Graphics g) {
                long t0 = System.nanoTime();
                super.paintChildren(g);
                long t1 = System.nanoTime();
                System.out.format("Paint JDK: %.2f ms\n", (t1 - t0) / 1000000f);
            };
        };

(Ditto for the bottom pane.)

After "warming it up" by dragging the slider around until times settle a bit:

Paint TEST: 2.04 ms  Paint JDK: 2.28 ms
Paint TEST: 2.56 ms  Paint JDK: 3.63 ms
Paint TEST: 2.33 ms  Paint JDK: 2.71 ms
Paint TEST: 6.15 ms  Paint JDK: 3.46 ms
Paint TEST: 4.25 ms  Paint JDK: 4.28 ms
Paint TEST: 4.93 ms  Paint JDK: 3.02 ms
Paint TEST: 3.99 ms  Paint JDK: 3.60 ms
Paint TEST: 3.41 ms  Paint JDK: 2.96 ms
Paint TEST: 4.79 ms  Paint JDK: 3.94 ms
Paint TEST: 4.19 ms  Paint JDK: 5.78 ms
Paint TEST: 3.78 ms  Paint JDK: 2.51 ms
Paint TEST: 4.13 ms  Paint JDK: 3.57 ms
Paint TEST: 3.25 ms  Paint JDK: 2.91 ms
Paint TEST: 3.31 ms  Paint JDK: 4.67 ms
Paint TEST: 3.26 ms  Paint JDK: 2.94 ms
Paint TEST: 3.58 ms  Paint JDK: 2.88 ms
Paint TEST: 3.78 ms  Paint JDK: 2.79 ms

So yeah not worlds apart, but I do feel ignorant about devices that might not have as strong graphics acceleration as my laptop.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From ihse at openjdk.java.net  Wed Mar 23 23:17:39 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 23 Mar 2022 23:17:39 GMT
Subject: RFR: 8283323: libharfbuzz optimization level results in extreme
 build times [v2]
In-Reply-To: <EgZ4bxF2N2_AEhM3FxJZ2k8GmQ8VihVi91tK3A1MktQ=.f2eba44b-ded3-4698-b06b-7115f8a2786d@github.com>
References: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
 <k44JRBhviYe-x_vhHQ-n5NnMAwpnSmK7OQ8oPXxUhBw=.1af97bcf-87e5-4755-8d01-b578a61e7665@github.com>
 <EgZ4bxF2N2_AEhM3FxJZ2k8GmQ8VihVi91tK3A1MktQ=.f2eba44b-ded3-4698-b06b-7115f8a2786d@github.com>
Message-ID: <pMxoT8ncGUFDojF-cdesBuCLHG-DHRR_Z-nFYZAAl2Q=.7fb1880f-20bd-4a6b-bc2c-cf808aaca4dd@github.com>

On Wed, 23 Mar 2022 22:37:55 GMT, Phil Race <prr at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore HIGHEST for entire lib, just set SIZE to two files
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 487:
> 
>> 485: LIBFONTMANAGER_OPTIMIZATION := HIGHEST
>> 486: 
>> 487: ifneq ($(filter $(TOOLCHAIN_TYPE), gcc clang), )
> 
> Can we have a note here that the de-opt is possible because these two files aren't important to OpenJDK ?
> If these files were to be renamed in an updated version of harfbuzz, would there be a compilation error ?

Comment updated.

No, these directives will be just silently ignored. So if that happens we run the risk of reintroducing the build performance regression. Not a big risk. In any case, at next harfbuzz update it can be worth re-checking if these exceptions are still needed. (If you're the one doing it and need help with that, just let me know!)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7919


From ihse at openjdk.java.net  Wed Mar 23 23:17:38 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 23 Mar 2022 23:17:38 GMT
Subject: RFR: 8283323: libharfbuzz optimization level results in extreme
 build times [v3]
In-Reply-To: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
References: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
Message-ID: <VlLT6x7sOuH6kaNBzDarXH_9a_885Q08IBNaCPglwWw=.982e18aa-3d27-4cf9-8554-84258e3b9359@github.com>

> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference linux machine. This was one of the four culprits that caused a 25-30% build time regression over the last two years.
> 
> The problem here was that the new HarfBuzz code caught really bad behaviour from gcc when compiling with optimizations. The official HarfBuzz build does not use any -O flags at all for gcc, so presumably the HarfBuzz team is:
> 
> a) not thinking compiler optimization is important for the performance of this library, and
> b) unaware that their code causes such a headache for gcc.
> 
> (Other compilers fare much better: visual studio makes no difference at all, and for clang just a small regression was observed.)
> 
> The current optimization level was introduced by [JDK-8255790](https://bugs.openjdk.java.net/browse/JDK-8255790), which were really about moving libharfbuzz compilation back into libfontmanager. I could find no comments/discussion relating to the change of optimization level, so I assume it was incidental, and just seemed good at the time.
> 
> This patch changes the optimization level to `SIZE` (which is the closest thing we have to no optimization level) on gcc.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Update comment to show we don't care about these files.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7919/files
  - new: https://git.openjdk.java.net/jdk/pull/7919/files/b491f6fb..99642af3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7919&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7919&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7919.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7919/head:pull/7919

PR: https://git.openjdk.java.net/jdk/pull/7919


From prr at openjdk.java.net  Wed Mar 23 23:28:46 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 23 Mar 2022 23:28:46 GMT
Subject: RFR: 8283323: libharfbuzz optimization level results in extreme
 build times [v3]
In-Reply-To: <VlLT6x7sOuH6kaNBzDarXH_9a_885Q08IBNaCPglwWw=.982e18aa-3d27-4cf9-8554-84258e3b9359@github.com>
References: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
 <VlLT6x7sOuH6kaNBzDarXH_9a_885Q08IBNaCPglwWw=.982e18aa-3d27-4cf9-8554-84258e3b9359@github.com>
Message-ID: <o8dHz1achhnBU6JAAZmE8dNMAswRSunboLwfTKXunFk=.609512ee-ea46-44b4-8d21-f9a57d72db4b@github.com>

On Wed, 23 Mar 2022 23:17:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference linux machine. This was one of the four culprits that caused a 25-30% build time regression over the last two years.
>> 
>> The problem here was that the new HarfBuzz code caught really bad behaviour from gcc when compiling with optimizations. The official HarfBuzz build does not use any -O flags at all for gcc, so presumably the HarfBuzz team is:
>> 
>> a) not thinking compiler optimization is important for the performance of this library, and
>> b) unaware that their code causes such a headache for gcc.
>> 
>> (Other compilers fare much better: visual studio makes no difference at all, and for clang just a small regression was observed.)
>> 
>> The current optimization level was introduced by [JDK-8255790](https://bugs.openjdk.java.net/browse/JDK-8255790), which were really about moving libharfbuzz compilation back into libfontmanager. I could find no comments/discussion relating to the change of optimization level, so I assume it was incidental, and just seemed good at the time.
>> 
>> This patch changes the optimization level to `SIZE` (which is the closest thing we have to no optimization level) on gcc.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comment to show we don't care about these files.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7919


From prr at openjdk.java.net  Wed Mar 23 23:28:46 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 23 Mar 2022 23:28:46 GMT
Subject: RFR: 8283323: libharfbuzz optimization level results in extreme
 build times [v2]
In-Reply-To: <pMxoT8ncGUFDojF-cdesBuCLHG-DHRR_Z-nFYZAAl2Q=.7fb1880f-20bd-4a6b-bc2c-cf808aaca4dd@github.com>
References: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
 <k44JRBhviYe-x_vhHQ-n5NnMAwpnSmK7OQ8oPXxUhBw=.1af97bcf-87e5-4755-8d01-b578a61e7665@github.com>
 <EgZ4bxF2N2_AEhM3FxJZ2k8GmQ8VihVi91tK3A1MktQ=.f2eba44b-ded3-4698-b06b-7115f8a2786d@github.com>
 <pMxoT8ncGUFDojF-cdesBuCLHG-DHRR_Z-nFYZAAl2Q=.7fb1880f-20bd-4a6b-bc2c-cf808aaca4dd@github.com>
Message-ID: <lQLkgnET5s_bwvmO0I8Hf5QDJXA_wiqkAskIxMGn9n0=.46f7617a-1728-43b0-8f2e-cbb6f6944a6a@github.com>

On Wed, 23 Mar 2022 23:13:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 487:
>> 
>>> 485: LIBFONTMANAGER_OPTIMIZATION := HIGHEST
>>> 486: 
>>> 487: ifneq ($(filter $(TOOLCHAIN_TYPE), gcc clang), )
>> 
>> Can we have a note here that the de-opt is possible because these two files aren't important to OpenJDK ?
>> If these files were to be renamed in an updated version of harfbuzz, would there be a compilation error ?
>
> Comment updated.
> 
> No, these directives will be just silently ignored. So if that happens we run the risk of reintroducing the build performance regression. Not a big risk. In any case, at next harfbuzz update it can be worth re-checking if these exceptions are still needed. (If you're the one doing it and need help with that, just let me know!)

As of today they are still there in upstream harfbuzz on github.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7919


From serb at openjdk.java.net  Wed Mar 23 23:33:50 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 23 Mar 2022 23:33:50 GMT
Subject: RFR: 8273355: Flickering on tooltip appearance IntelliJ IDEA
 2021.2.1
In-Reply-To: <_Q4d9YdOccAdjO6LsIlbIOt55Bn7PGAz3-NmVBF2vLU=.01b029e3-f88f-4b6b-b12b-3509f9dcd486@github.com>
References: <_Q4d9YdOccAdjO6LsIlbIOt55Bn7PGAz3-NmVBF2vLU=.01b029e3-f88f-4b6b-b12b-3509f9dcd486@github.com>
Message-ID: <88P-u7cRkyFDdNY_J7mxwjKA6UAd6Jqe31yuSZIYoV4=.865990c7-615b-4417-b10b-60ffe9f0d766@github.com>

On Wed, 23 Mar 2022 20:01:54 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Used setOpaque() method to set correct background of platform window
> Extracted setting background to the particular method in PlatformWindow. Provided appropriate implementation in CPlatformWindow.

src/java.desktop/macosx/classes/sun/lwawt/LWWindowPeer.java line 298:

> 296:             Color color = getBackground();
> 297:             if (color != null) {
> 298:                 platformWindow.setBackground(color);

If it skips the texture property I guess it will break it?
I think the easiest solution for this issue is to add a new method to the LWWindowPeer:
 ```
   public void setBackground(final Color c) {
        Color oldBg = getBackground();
        if (oldBg == c || (oldBg != null && oldBg.equals(c))) {
            return;
        }
        super.setBackground(c);
        updateOpaque();
    }
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/7931


From serb at openjdk.java.net  Wed Mar 23 23:41:47 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 23 Mar 2022 23:41:47 GMT
Subject: RFR: 8283323: libharfbuzz optimization level results in extreme
 build times [v3]
In-Reply-To: <VlLT6x7sOuH6kaNBzDarXH_9a_885Q08IBNaCPglwWw=.982e18aa-3d27-4cf9-8554-84258e3b9359@github.com>
References: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
 <VlLT6x7sOuH6kaNBzDarXH_9a_885Q08IBNaCPglwWw=.982e18aa-3d27-4cf9-8554-84258e3b9359@github.com>
Message-ID: <cxsg6M8rBMOyMH96Zqw6eQeeC2u3fnVh_6oX46IJ82E=.cdd74282-7838-4769-abd7-c9e15386d95e@github.com>

On Wed, 23 Mar 2022 23:17:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference linux machine. This was one of the four culprits that caused a 25-30% build time regression over the last two years.
>> 
>> The problem here was that the new HarfBuzz code caught really bad behaviour from gcc when compiling with optimizations. The official HarfBuzz build does not use any -O flags at all for gcc, so presumably the HarfBuzz team is:
>> 
>> a) not thinking compiler optimization is important for the performance of this library, and
>> b) unaware that their code causes such a headache for gcc.
>> 
>> (Other compilers fare much better: visual studio makes no difference at all, and for clang just a small regression was observed.)
>> 
>> The current optimization level was introduced by [JDK-8255790](https://bugs.openjdk.java.net/browse/JDK-8255790), which were really about moving libharfbuzz compilation back into libfontmanager. I could find no comments/discussion relating to the change of optimization level, so I assume it was incidental, and just seemed good at the time.
>> 
>> This patch changes the optimization level to `SIZE` (which is the closest thing we have to no optimization level) on gcc.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comment to show we don't care about these files.

Do we really want to change the product performance characteristics based on the compilation time? Can we try parallelize/cache or something first?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7919


From mvs at openjdk.java.net  Wed Mar 23 23:46:51 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 23 Mar 2022 23:46:51 GMT
Subject: Integrated: 8283493: Create an automated regression test for RFE
 4231298
In-Reply-To: <nVUH7AgirLhyqluMk5AAixvBtr64QzautJ7XTiHAHrM=.ae940c8a-cf66-4145-a0be-82f9d868ce76@github.com>
References: <nVUH7AgirLhyqluMk5AAixvBtr64QzautJ7XTiHAHrM=.ae940c8a-cf66-4145-a0be-82f9d868ce76@github.com>
Message-ID: <Q3yUkreQKZ_dsJMPXpU4zl2zwd8uSSskw5CQSk73VGQ=.dc189318-e15f-4892-a50b-f0b4faaf53fa@github.com>

On Tue, 22 Mar 2022 15:30:09 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Create a regression test for [JDK-4231298](https://bugs.openjdk.java.net/browse/JDK-4231298)
> Issue:
> When a JComboBox first drops down, the renderer is called for
> every element in the list, even those elements that will not
> actually be drawn on the screen.
> 
> Fix:
> Introduced new API to JComboBox: get/setPrototypeDisplayValue(). This API allows the UI to calculate the display size using this prototype value rather than iterated over a large list of items. See RFE 4289100 which also addresses this problem.
> 
> Testing:
> 1. Tested in Mach5, 10 times per platform(macos,linux and windows) and got all pass.
> 
> 2. Tested in JDK 1.3.0 and JDK 1.4.0 and the results are given below.
> Java 1.3.0 -> Test Failed.
> $ jdk1.3/bin/java JComboBoxPrototypeTest
> getListCellRendererComponent index = -1, isSelected = false, cellHasFocus = false
> Value of the Counter is 1
> ....
> getListCellRendererComponent index = -1, isSelected = false, cellHasFocus = false
> Value of the Counter is 101
> Test Failed
> java.lang.RuntimeException: Custom Renderer got called 101 times, expected is maximum 6 times
>         at JComboBoxPrototypeTestOld.main(JComboBoxPrototypeTest.java:107)
> 
> Java 1.4.0(added a call to setPrototypeDisplayValue()) -> Test Passed.
> $ j2sdk1.4.0/bin/java JComboBoxPrototypeTest
> getListCellRendererComponent index = -1, isSelected = false, cellHasFocus = false
> Value of the Counter is 1
> getListCellRendererComponent index = -1, isSelected = false, cellHasFocus = false
> Value of the Counter is 2
> getListCellRendererComponent index = -1, isSelected = false, cellHasFocus = false
> Value of the Counter is 3
> Test Passed

This pull request has now been integrated.

Changeset: 6917c39e
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6917c39e450e0564b8db7c96be132881a6b0a112
Stats:     184 lines in 1 file changed: 184 ins; 0 del; 0 mod

8283493: Create an automated regression test for RFE 4231298

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/7905


From mvs at openjdk.java.net  Wed Mar 23 23:50:53 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 23 Mar 2022 23:50:53 GMT
Subject: Integrated: 8282860: Write a regression test for JDK-4164779
In-Reply-To: <P0Nh5jqNbGyTlAXOw-82iw2zJl61Tf9iUKDq4OOH9rE=.34986f4d-60e5-4430-862f-91ea34620c2f@github.com>
References: <P0Nh5jqNbGyTlAXOw-82iw2zJl61Tf9iUKDq4OOH9rE=.34986f4d-60e5-4430-862f-91ea34620c2f@github.com>
Message-ID: <VOzCCErjsLePz96_w74b5l5GzE1aPYfQdcXT2C6jUoo=.7141c36a-b43b-4a5b-8334-4da7b98b2981@github.com>

On Sun, 13 Mar 2022 13:42:15 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Write a regression test for [JDK-4164779](https://bugs.openjdk.java.net/browse/JDK-4164779) : JSplitPane keyboard navigation does not support F6 and Ctrl+Tab
> 
> 
> Issue:
> The specified keyboard support for JSplitPane also requires F6 and Ctrl+Tab (navigate out) for the JSplitPane. Those are currently not implemented.
> 
> F6 is supposed to move the focus from the current focused component on one side of the JSplitPane to the other side of the JSplitPane without having to tab through to that.
> 
> Ctrl+Tab is supposed to move the input focus from whatever component inside the JSplitPane that has the focus to the next component outside the JSplitPane.
> 
> 
> Testing:
> Java 1.4.0 -> Test Failed.
> $ ./j2sdk1.4.0/bin/java JSplitPaneTest
> Verifier 1 failed
> Verifier 2 failed
> Verifier 3 failed
> Verifier 4 failed
> Test Failed.
> 
> Java 1.4.1 -> Test Passed.
> $ ./j2sdk1.4.1/bin/java JSplitPaneTest
> Verifier 1 passed
> Verifier 2 passed
> Verifier 3 passed
> Verifier 4 passed
> Test Passed.

This pull request has now been integrated.

Changeset: 8a044649
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8a044649bd722da54999f55ff2cf907682fdc180
Stats:     220 lines in 1 file changed: 220 ins; 0 del; 0 mod

8282860: Write a regression test for JDK-4164779

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/7801


From ihse at openjdk.java.net  Thu Mar 24 00:37:49 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 24 Mar 2022 00:37:49 GMT
Subject: RFR: 8283323: libharfbuzz optimization level results in extreme
 build times [v3]
In-Reply-To: <cxsg6M8rBMOyMH96Zqw6eQeeC2u3fnVh_6oX46IJ82E=.cdd74282-7838-4769-abd7-c9e15386d95e@github.com>
References: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
 <VlLT6x7sOuH6kaNBzDarXH_9a_885Q08IBNaCPglwWw=.982e18aa-3d27-4cf9-8554-84258e3b9359@github.com>
 <cxsg6M8rBMOyMH96Zqw6eQeeC2u3fnVh_6oX46IJ82E=.cdd74282-7838-4769-abd7-c9e15386d95e@github.com>
Message-ID: <kGmDFDEIw6a-0-Sd38FR4bN7tb7mS24YNVS9MY4Ehvk=.768628b2-3bb8-4de2-b3b0-cc75f4ed16c9@github.com>

On Wed, 23 Mar 2022 23:38:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update comment to show we don't care about these files.
>
> Do we really want to change the product performance characteristics based on the compilation time? Can we try parallelize/cache or something first?

@mrserb Phil said that we don't even use the subset part of harfbuzz. 

And unless you're backing up your claim that this patch is changing runtime characteristic with data, that's just a guess, just like the initial optimization level of this library (and as most of the native libraries in the JDK... :-() was just a guess. Otoh, that we get a build time regression for these two files is a proven fact.

What is it you want to cache?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7919


From prr at openjdk.java.net  Thu Mar 24 02:32:49 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 24 Mar 2022 02:32:49 GMT
Subject: RFR: 8241192: [macosx] Wrong letter typed after =?UTF-8?B?wrQ=?=
 symbol when using Finnish layout
In-Reply-To: <FrPt5p9Wh_Bqdu9qE0PqSr-41wsNalEgkg-v2KRc4sc=.3c0c2eeb-52a6-4c97-ba48-d550cd2892e6@github.com>
References: <FrPt5p9Wh_Bqdu9qE0PqSr-41wsNalEgkg-v2KRc4sc=.3c0c2eeb-52a6-4c97-ba48-d550cd2892e6@github.com>
Message-ID: <MtrLzY36H7FCS1KX3JWW4iIPmYmI8NNiA4B5SsQBl5Y=.7ce14476-2203-4872-8f08-7f979706d1ed@github.com>

On Fri, 28 Jan 2022 09:38:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> If we press " ? " (on U.S. keyboard layout it is the [+] button just before the [delete] button), and then press "s" , 2 "?" characters are entered in a text field instead of "?s" with "Finish" keyboard layout.
> This is because, although " ? " is construed as "complex" char and inserted properly the next "s" character is treated as non-complex character as it's utf8Length is 1 and utf16Length is 2, so we need to explicitly make it a "complex" char sequence if the code point is 0x73 ie "s" in Finnish layout for it to be inserted properly.

Please withdraw this until we are more sure about the right fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7262


From prr at openjdk.java.net  Thu Mar 24 02:33:46 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 24 Mar 2022 02:33:46 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux
In-Reply-To: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
Message-ID: <L9pvwhnoZ5LQTOjM0nZWqBHL2-k2HCLfgZ35NC2s2fA=.4fc0007b-825d-4982-9b22-8f842c43952f@github.com>

On Fri, 21 Jan 2022 17:02:38 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

> These crashes were not reproducible, so the fix is based on a hypothesis that there are two possible reasons for them:
> 1. `makeDefaultConfig()` returning `NULL`.
> 2. A race condition when the number of screens changes.
> The race scenario: `X11GraphisDevice.makeDefaultConfiguration()` is called on EDT so the call can race with `X11GraphisDevice.invalidate()` that re-sets the screen number of the device; the latter is invoked on the `AWT-XAWT` thread from `X11GraphicsEnvironment.rebuildDevices()`. So by the time `makeDefaultConfiguration()` makes a native call with the device's current screen number, the `x11Screens` array maintained by the native code could have become shorter. And the native methods like `Java_sun_awt_X11GraphicsDevice_getConfigColormap()` assume that the number passed to them is always current and valid. The AWT lock only protects against the changes during the native methods invocation and does not protect against them being called with an outdated screen number. With a larger screen number, those methods read past the end of the `x11Screens` array.
> 
> The fix for (1) is to die gracefully instead of crashing in an attempt to de-reference a `NULL` pointer, which might happen upon returning from `makeDefaultConfig()` in `getAllConfigs()`.
> 
> The fix for (2) is to eliminate the race by protecting `X11GraphisDevice.screen` with the AWT lock such that it doesn't change when the native methods working with it are active.
> 
> We've been shipping JetBrains Runtime with this fix for a few months now and there were no crash reports with those specific patterns against the versions with the fix.

Can we move this along ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7182


From prr at openjdk.java.net  Thu Mar 24 02:35:52 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 24 Mar 2022 02:35:52 GMT
Subject: RFR: 8269806: Emoji rendering on Linux
In-Reply-To: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
Message-ID: <3QVRsBAqs8znuPKlvR2u80Ribc4XYnj2Wx_qH3wT72o=.f7ed53f4-2126-49ef-ba5c-2bd167ce225f@github.com>

On Thu, 15 Jul 2021 17:29:01 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

> 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

It didn't build for me and it didn't work for me  - on X11. So is there an update or should it be returned to draft or handed off to someone else ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4798


From prr at openjdk.java.net  Thu Mar 24 02:38:51 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 24 Mar 2022 02:38:51 GMT
Subject: RFR: 8276849: Refresh the window icon on graphics configuration
 changes [v4]
In-Reply-To: <elb291CEaz1C9fY4_1Md9urOqwoyoKeaU2LPPyCHBsQ=.ba5e0960-5334-4f55-86a4-062367d4e745@github.com>
References: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
 <0oxxlnAHynu4eIJIE8cMzXJlpU7I_CF1kBk4IYSN3YY=.e8b93bca-4b06-4a70-82db-aa608d6bb350@github.com>
 <elb291CEaz1C9fY4_1Md9urOqwoyoKeaU2LPPyCHBsQ=.ba5e0960-5334-4f55-86a4-062367d4e745@github.com>
Message-ID: <gmxGmnLFpb-ZHVw_p2XBpVsjmbui_pnYQdAQudghMXE=.99dd0fa8-8184-4408-89b4-a6b6e7dc49a7@github.com>

On Wed, 23 Feb 2022 21:34:29 GMT, Emmanuel Bourg <duke at openjdk.java.net> wrote:

>> Emmanuel Bourg has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Test case for the window icon update on DPI change (Java generic font names are usually capitalized)
>>  - Test case for the window icon update on DPI change (dispose the frame after a timeout on the EDT)
>
> Just tested on macOS 12 with a non Retina screen and OpenJDK 8: the icon displayed in the dock when the test frame is minimized is the 32x32 one. If I add more icons to the list, it picks the biggest one, up to 128x128. Bigger icons are ignored.
> 
> The issue observed on Windows doesn't really transpose to macOS, I think I'll revert the change to `LWWindowPeer`.

@ebourg @aivanov-jdk are the remaining issues test issues, or might there still be product issues ?
No pressure to push but let's not forget about it either.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6180


From prr at openjdk.java.net  Thu Mar 24 02:43:50 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 24 Mar 2022 02:43:50 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v12]
In-Reply-To: <V_dusBmHOneHnSxQxMHeTd_Dk3zljmHwI2XSlDPOeok=.c9faa61f-d98a-40fd-b79c-0328ed985006@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <pkujGIpXv0UwX2gxeX6kOzKXHiqoImRI9BuglmWbHbE=.a4801fee-2fc4-4a78-97b6-4ea27396492a@github.com>
 <V_dusBmHOneHnSxQxMHeTd_Dk3zljmHwI2XSlDPOeok=.c9faa61f-d98a-40fd-b79c-0328ed985006@github.com>
Message-ID: <4iXAc1orXjzhOAzP0u9gItVzOKdxnNhMcL4UsUVHRPI=.5624c947-2092-4eb1-adb4-31f1d8325915@github.com>

On Fri, 4 Mar 2022 22:38:33 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>>   
>>   This is a second follow-up response to prrace's code review feedback about method modifiers.
>>   
>>   This commit more carefully preserves the getBounds2D() method modifiers for all 3 classes: the Path2D.Double, the Path2D.Float, and the Path2D itself.
>>   
>>   It is possible (if unlikely) that someone previously extended the Path2D class and overrode getBounds2D(), because the Path2D#getBounds2D() method was *not* final. So with this commit: any such existing code will not break. Meanwhile the subclasses (Double and Float) preserve their previous modifiers (final, synchronized).
>>   
>>   This is in response to prrace's code review:
>>   
>>   >    You are changing the signature of public API
>>   >    src/java.desktop/share/classes/java/awt/geom/Path2D.java
>>   >    public final synchronized Rectangle2D getBounds2D() => public Rectangle2D getBounds2D() {
>>   >
>>   > So no longer final, and no longer synchronized.
>>   > This means a CSR is required and we need to think about it ..
>>   > the intention was that the subclass not over-ride.
>>   > And why remove synchronized ? I am fairly sure it was there to
>>   > make sure no one was mutating the Path whilst
>>   > bounds are being calculated.
>>   > And you are using getPathIterator(AffineTransform) and the docs
>>   > for that say it isn't thread safe.
>>   > So I think this implementation needs to be thought about very carefully.
>
> I don't suppose any new client-lib members would be willing to set up a CSR for this PR?
> 
> No worries if not. I just wanted to double-check before this PR gets auto-closed.
> 
> (I'm under the impression I can't initiate a CSR and there's nothing else I can do here; if I'm wrong please let me know.)

So .. @mickleness please email me directly about any help needed with the CSR.  Give me the text you propose
or if you want me to write it just say so and I'll do it. I'd like to get this done in 19.
@bourgesl I've created the essentially blank CSR https://bugs.openjdk.java.net/browse/JDK-8283602
If you want to edit you can.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6227


From prr at openjdk.java.net  Thu Mar 24 02:50:52 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 24 Mar 2022 02:50:52 GMT
Subject: RFR: 8278828 : java/awt/a11y/AccessibleTextTest.java's
 createTextArea() just shows instructions on the UI [v3]
In-Reply-To: <zt7D7C5IRyTxqO-bbcujyfVhQ0hu7GfVmhnksZexL1c=.73182c68-5d94-4360-abea-166dc47b23f2@github.com>
References: <lUZ_t3uGgmRCL_I4jS_kmf7SBjW9FMFyt8e85GwAe4c=.c7f668a3-96e6-4fb9-9398-efa91fcd8cfc@github.com>
 <zt7D7C5IRyTxqO-bbcujyfVhQ0hu7GfVmhnksZexL1c=.73182c68-5d94-4360-abea-166dc47b23f2@github.com>
Message-ID: <kI4QABpR-Zc5zbcNDalNt1XhuvSGv9ms4Mzr-aXPlNo=.d7257d50-bc0b-4c54-8fdc-3fb7fa4f802a@github.com>

On Thu, 27 Jan 2022 21:47:04 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> 1) Test scenario was just showing test instruction with JTextArea. So added the JTextArea as the instruction and method says. 
>> 2) JTextArea is filled with contents so that and an Emoji character making sure that screen reader can read Emoji also.
>> 3) Now user can user arrow keys to navigate the JTextArea and screen reader can read it.
>> 
>> @shurymury 
>> 
>> Attached the screen shot of the test UI which contains JTextArea along with the instruction.
>> <img width="623" alt="Screen Shot 2021-12-14 at 7 09 14 PM" src="https://user-images.githubusercontent.com/87324768/146111187-29f81aab-a138-442d-90bd-df24d512fe01.png">
>
> lawrence.andrews has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into jdk-8278828-ws
>  - Fixed instruction for createTextArea()
>  - Merge branch 'openjdk:master' into jdk-8278828-ws
>  - Added JTextArea createTextArea() in AccessibleTextTest.java

I see no value in this. Please withdraw it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6844


From prr at openjdk.java.net  Thu Mar 24 02:51:56 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 24 Mar 2022 02:51:56 GMT
Subject: RFR: 8280193: summary javadoc for
 java.awt.GraphicsEnvironment#preferPropotionalFonts broken
In-Reply-To: <mhGN4NF0_HP30ZMo4dmDmLnFMmciaf1fmAAEeWfIX5k=.f69d52f6-79ed-42bd-836b-3f31b2961be4@github.com>
References: <mhGN4NF0_HP30ZMo4dmDmLnFMmciaf1fmAAEeWfIX5k=.f69d52f6-79ed-42bd-836b-3f31b2961be4@github.com>
Message-ID: <wQcQpY73rSgupJwgSVydYdui4ARumU0SqRrBWq6cv9g=.0e34e15c-36f2-4f9d-89cb-93a79c78699a@github.com>

On Tue, 18 Jan 2022 14:05:55 GMT, James Nord <duke at openjdk.java.net> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8280193
> 
> 
> Javadoc broke the first sentence at the full stop space (newline) so it rendered with `Indicates a preference for proportional over non-proportional (e.g.`
> 
> This is an incorrect sentence, and so this change fixes it by replacing the `e.g.` to `for example`
> 
> https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/GraphicsEnvironment.html
> 
> <img width="706" alt="image" src="https://user-images.githubusercontent.com/494726/149952315-651a4231-d641-4b73-8fea-93c83e1aa257.png">

Marked as reviewed by prr (Reviewer).

I am fine with this but there's probably a javadoc way to escape this

Fix the PR spelling or it won't integrate

-------------

PR: https://git.openjdk.java.net/jdk/pull/7127


From prr at openjdk.java.net  Thu Mar 24 02:52:50 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 24 Mar 2022 02:52:50 GMT
Subject: RFR: 8185261: Font fallback sometimes doesn't work in Swing text
 components [v2]
In-Reply-To: <4SfhJKrUWWmdo2ZioTjqiU5b3a4cZBwWhMX89auZBRg=.5bf8b903-dbb2-4e7c-adaf-59c5e8212e72@github.com>
References: <5qQoyooaZzlKSp4iMudwLZ16MotrGrPB7GhQ3aAVYjo=.8e97ba6f-4aab-40d7-944f-4f68dc2b7b1c@github.com>
 <4SfhJKrUWWmdo2ZioTjqiU5b3a4cZBwWhMX89auZBRg=.5bf8b903-dbb2-4e7c-adaf-59c5e8212e72@github.com>
Message-ID: <Ha2rM2oGB_blf1QlZgxBbGjJeWJS9QNbfahtnE3Rr5E=.87c3c1cc-671e-430a-a131-9c6b62692714@github.com>

On Tue, 1 Feb 2022 21:40:53 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

>> The proposed fix makes fonts with and without fallback components distinguishable (in terms of `equals` method), so that
>> font metrics cache (and other similar code) can handle them separately. This is achieved by adding a new boolean field
>> to `Font` class, specifically denoting fonts with fallback components. The latter ones don't need to pretend to be
>> 'created' fonts anymore, to preserve their `Font2D` handle.
>> It's not possible to use the existing `createdFont` field in `equals` implementation, as JCK requires a 'real' created
>> font (the one obtained using `Font.createFont` method) to be equal to the same font after serialization and
>> deserialization.
>
> Dmitry Batrak has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove 'headful' requirement from test case

I know .. I know .. I just (a) don't like it, and (b) don't have a good alternative.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7313


From prr at openjdk.java.net  Thu Mar 24 02:54:46 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 24 Mar 2022 02:54:46 GMT
Subject: RFR: 8281284 : Write JSlider accessibility test [v7]
In-Reply-To: <ffuhc7bE0polSSFA3gi1aDROXkbWZaww2fS5CHHpdD4=.94c24739-b557-4919-9b00-624cb89fa12f@github.com>
References: <VB8Ldq_d1uZBKpyvvDlu7t9lUtAd_WhLl4meSv46ixo=.b8b023ee-6946-407d-8e05-223fb2d95062@github.com>
 <ffuhc7bE0polSSFA3gi1aDROXkbWZaww2fS5CHHpdD4=.94c24739-b557-4919-9b00-624cb89fa12f@github.com>
Message-ID: <qe0eiF_7qZGsNUdvScvY9CiMKNSvHDPHudnuiz7Bei4=.35c48911-698a-4507-ab1c-139fb66908bd@github.com>

On Mon, 21 Mar 2022 21:41:27 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> This testcase covers both old and new api ( api added in jdk17  getAccessibleAction(), getAccessibleActionCount() , getAccessibleActionDescription )
>> 
>> @shurymury 
>> @savoptik
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed AccessibleJSliderTest.java and add SliderDemo.java & SliderDemo.html

Can we move this along ? It is getting old.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7355


From prr at openjdk.java.net  Thu Mar 24 02:56:49 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 24 Mar 2022 02:56:49 GMT
Subject: RFR: 8274735: javax.imageio.IIOException: Unsupported Image Type
 while processing a valid JPEG image [v2]
In-Reply-To: <Qw5ScniD19CHPmI6Lh42bmy0kS5uOiQZCrwOhHe6pWM=.240bcef2-e710-4166-b3c0-de14f9e48604@github.com>
References: <gBv_Xtu5bmqpludbJWXwKpgvPCVz4BGYXbjErejjb1A=.cbe35817-d2cb-44bc-9f7b-d2597622623e@github.com>
 <kkMrJ3mLh2hD2fz968vOpUPm7XRMj2Nl6t0VPwFPpfc=.523668a3-3e68-4af1-a71f-d559252f04b9@github.com>
 <Qw5ScniD19CHPmI6Lh42bmy0kS5uOiQZCrwOhHe6pWM=.240bcef2-e710-4166-b3c0-de14f9e48604@github.com>
Message-ID: <GEvsYdzfPsz0NRpK8YEWANuxd7tSuyBiGVFkMPwYI8w=.d83482ea-da92-4c94-8ac6-9c69de832552@github.com>

On Tue, 22 Mar 2022 01:45:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274735: javax.imageio.IIOException: Unsupported Image Type while processing a valid JPEG image
>
> src/java.desktop/share/classes/com/sun/imageio/plugins/common/SimpleCMYKColorSpace.java line 66:
> 
>> 64: 
>> 65:     public int hashCode() {
>> 66:         return System.identityHashCode(theInstance);
> 
> Is it just a cleanup or it has some other reason?

If toString() is called  then you get StackOverflowException(). 
I am surprised no-one hit this already but I hit it repeatedly during testing.

> src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java line 1740:
> 
>> 1738:         raster.setRect(sourceLine);
>> 1739:         if (invertCMYK) {
>> 1740:             byte[] data = ((DataBufferByte)raster.getDataBuffer()).getData();
> 
> Is it known that the type of the raster here is always DataBufferByte?

yes

-------------

PR: https://git.openjdk.java.net/jdk/pull/7849


From duke at openjdk.java.net  Thu Mar 24 02:58:50 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 24 Mar 2022 02:58:50 GMT
Subject: Integrated: 8270331 : [TESTBUG] Error: Not a test or directory
 containing tests: java/awt/print/PrinterJob/InitToBlack.java
In-Reply-To: <ILihQKqFsB85AIFHTbJK1Im9hB60SJ_OJzDgdUB1dbg=.bf0f4b07-fd40-4eca-b2eb-e5f38b311d72@github.com>
References: <ILihQKqFsB85AIFHTbJK1Im9hB60SJ_OJzDgdUB1dbg=.bf0f4b07-fd40-4eca-b2eb-e5f38b311d72@github.com>
Message-ID: <PhD5I5mQcvq8Ii71F_bDKwpMeLrYino88BExxBYGKhw=.442b240e-920f-4ba5-aefc-9f7de6aafae1@github.com>

On Thu, 17 Mar 2022 21:47:12 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> 1) Removed =yesno since it was throwing Error: Not a test or directory containing tests
> 2) Test was just printing the "Test passes" on the printer and user did not had any option to mark the test as pass or fail and test was always passing. so created test UI with test instruction and test controls to mark the test pass or fail and checking the end result of the test.
> 
> @shurymury

This pull request has now been integrated.

Changeset: 2ef9767a
Author:    lawrence.andrews <lawrence.andrews at oracle.com>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2ef9767aae8e1798661fea615b096833bdb9d985
Stats:     131 lines in 1 file changed: 116 ins; 0 del; 15 mod

8270331: [TESTBUG] Error: Not a test or directory containing tests: java/awt/print/PrinterJob/InitToBlack.java

Reviewed-by: prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/7860


From prr at openjdk.java.net  Thu Mar 24 03:10:48 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 24 Mar 2022 03:10:48 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v7]
In-Reply-To: <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
Message-ID: <WiEx5Y_45gZ6T87k39sxgvneubJBZ4mCWgoFo0Iytdc=.c4b9895f-e706-4124-91e6-2d21539d5226@github.com>

On Wed, 23 Mar 2022 18:24:05 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   scale stroke width at higher scalings

I have been following along although my comments may seem a bit dated.
1) @aivanov-jdk wrote (scroll up a lot)
When uiScale=1.25, you can see there's background color between the shadow and highlight on the second panel.

I have no idea where I should be seeing that. I see nothing like that. Perhaps I am looking in the wrong place

2) What I need here is a nice little statement of what we are INTENDING to draw. I mean what the UX person sketched out on their paper at infinite resolution. What are the components ? 
So something like
- a border drawn as a rectangle in a color derived from ????

- a shadow for the border drawn as 4 individual lines which are in a color derived from ??? and offset such that
to the left there's a pixel gap ??
to the right there's ??
to the top ?
to the bottom ?
they cross how ?

Can I please have a pretty picture ? Or is there one here already that shows this ideal ?
If so can we capture in words what it is doing ?

Let's assume highlight thickness has to match the border too ? Is that reasonable ?
This can definitely present challenges.

Is there a UI scale below which we special case and make sure of things and above which we say  - no issue its near enough to ideal resolution ?

I also think there's at least some analogy with OpenJFX's snap-to-pixel idea that it is sometimes better to pick a pixel and stick with it rather than span pixels and be fuzzy. Not an expert on the details of that by any means @kevinrushforth  might be able to point to something if it is relevant.  

If we figure this out properly it might be useful to apply to other cases rather than applying inconsistent hacks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From prr at openjdk.java.net  Thu Mar 24 03:32:48 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 24 Mar 2022 03:32:48 GMT
Subject: RFR: 8282640: Create a test for JDK-4740761 [v2]
In-Reply-To: <MxC6iXzgDe8DbPKKvE4ZLW8Gr7VmlcgQdqD2T3zRiuo=.a1e71d71-262f-4ac7-b815-254e8045fe87@github.com>
References: <Rr2xSJSr1_1WFxavIZtwz_rlxf15Yvd5dCxZ_1dcggs=.7415074d-6beb-434e-b463-04388e50b0c8@github.com>
 <MxC6iXzgDe8DbPKKvE4ZLW8Gr7VmlcgQdqD2T3zRiuo=.a1e71d71-262f-4ac7-b815-254e8045fe87@github.com>
Message-ID: <sIcj2VTJUwb2x3Y65R1-oyySW75Sm7SaMAltGbzxbio=.fdf6fe7c-de8c-4716-ac12-7c78d6559b24@github.com>

On Fri, 11 Mar 2022 14:44:25 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a test for [JDK-4740761](https://bugs.openjdk.java.net/browse/JDK-4740761)
>> 
>> The issue observed is in a JFrame with a JTextField and a JScrollPane which contains focused component. When the JScrollPane was
>> is removed from its parent, focus stays with the the scroller
>> of the removed JScrollPane, instead of moving to the TextField.
>> 
>> The test verifies the same - i.e. it verifies that the removal of the scrollpane moves the focus to the JTextField present in the JFrame.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added @bug keyword

Marked as reviewed by prr (Reviewer).

test/jdk/java/awt/Focus/8282640/ScrollPaneFocusBugTest.java line 102:

> 100:         robot.mousePress(InputEvent.BUTTON1_DOWN_MASK);
> 101:         robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
> 102: 

I presume the click is in case requestFocus didn't work and VK_1 is .. well any key will do ..

-------------

PR: https://git.openjdk.java.net/jdk/pull/7686


From prr at openjdk.java.net  Thu Mar 24 03:56:48 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 24 Mar 2022 03:56:48 GMT
Subject: RFR: 8283323: libharfbuzz optimization level results in extreme
 build times [v3]
In-Reply-To: <cxsg6M8rBMOyMH96Zqw6eQeeC2u3fnVh_6oX46IJ82E=.cdd74282-7838-4769-abd7-c9e15386d95e@github.com>
References: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
 <VlLT6x7sOuH6kaNBzDarXH_9a_885Q08IBNaCPglwWw=.982e18aa-3d27-4cf9-8554-84258e3b9359@github.com>
 <cxsg6M8rBMOyMH96Zqw6eQeeC2u3fnVh_6oX46IJ82E=.cdd74282-7838-4769-abd7-c9e15386d95e@github.com>
Message-ID: <LuBItrR8_wljBxAh_Piefw9YYM1VU_uomclmmdgcd9E=.f6446f71-3527-45ae-ab92-309bb987f86b@github.com>

On Wed, 23 Mar 2022 23:38:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update comment to show we don't care about these files.
>
> Do we really want to change the product performance characteristics based on the compilation time? Can we try parallelize/cache or something first?

> @mrserb Phil said that we don't even use the subset part of harfbuzz.
> 
> And unless you're backing up your claim that this patch is changing runtime characteristic with data, that's just a guess, just like the initial optimization level of this library (and as most of the native libraries in the JDK... :-() was just a guess. Otoh, that we get a build time regression for these two files is a proven fact.
> 
> What is it you want to cache?

It is a reasonable question. Build times might seem important to a small number of developers but runtime performance is King. That's why I asked to reduce it to just the files we don't care about. 
Would we give up even 0.1% of hotspot GC performance on Linux to avoid 30 seconds of compile time ?
I doubt it. 
And haven't we improved compile time a lot with the parallelism ? So are we now over-optimising in the wrong place ?
I mean good to keep an eye on it but I mean if a previous build arch took 15 mins and now with parallelism we take 3 mins and 45 secs .. is it so bad to be back up to 4 mins for more runtime benefit ? (Numbers entirely made up)
There's always going to be a long pole (something that is last) and the questions are whether its understood and for a good reason and so forth. I mean we can doubtless try to improve but at some point it is diminishing returns.
Perhaps someone can ask gcc devs why they are so slow on this code ? Maybe there's a good reason that helps runtime or maybe they just have design issues. They may want to know.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7919


From duke at openjdk.java.net  Thu Mar 24 04:02:51 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 24 Mar 2022 04:02:51 GMT
Subject: Withdrawn: 8278828 : java/awt/a11y/AccessibleTextTest.java's
 createTextArea() just shows instructions on the UI
In-Reply-To: <lUZ_t3uGgmRCL_I4jS_kmf7SBjW9FMFyt8e85GwAe4c=.c7f668a3-96e6-4fb9-9398-efa91fcd8cfc@github.com>
References: <lUZ_t3uGgmRCL_I4jS_kmf7SBjW9FMFyt8e85GwAe4c=.c7f668a3-96e6-4fb9-9398-efa91fcd8cfc@github.com>
Message-ID: <XsLUFm3xhIT56URN1H5QayCO-0AtL3-eKVYc8yVlcHo=.44570801-1188-49c8-8afe-797e90ac9631@github.com>

On Wed, 15 Dec 2021 02:21:35 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> 1) Test scenario was just showing test instruction with JTextArea. So added the JTextArea as the instruction and method says. 
> 2) JTextArea is filled with contents so that and an Emoji character making sure that screen reader can read Emoji also.
> 3) Now user can user arrow keys to navigate the JTextArea and screen reader can read it.
> 
> @shurymury 
> 
> Attached the screen shot of the test UI which contains JTextArea along with the instruction.
> <img width="623" alt="Screen Shot 2021-12-14 at 7 09 14 PM" src="https://user-images.githubusercontent.com/87324768/146111187-29f81aab-a138-442d-90bd-df24d512fe01.png">

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6844


From psadhukhan at openjdk.java.net  Thu Mar 24 04:33:48 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 24 Mar 2022 04:33:48 GMT
Subject: Withdrawn: 8241192: [macosx] Wrong letter typed after =?UTF-8?B?wrQ=?=
 symbol when using Finnish layout
In-Reply-To: <FrPt5p9Wh_Bqdu9qE0PqSr-41wsNalEgkg-v2KRc4sc=.3c0c2eeb-52a6-4c97-ba48-d550cd2892e6@github.com>
References: <FrPt5p9Wh_Bqdu9qE0PqSr-41wsNalEgkg-v2KRc4sc=.3c0c2eeb-52a6-4c97-ba48-d550cd2892e6@github.com>
Message-ID: <SGbSVj2Rc66790MkszpvuSbwSQc5r_mqBUFAvRFuDvQ=.159b4efa-59f8-489c-870a-ba7046cd158b@github.com>

On Fri, 28 Jan 2022 09:38:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> If we press " ? " (on U.S. keyboard layout it is the [+] button just before the [delete] button), and then press "s" , 2 "?" characters are entered in a text field instead of "?s" with "Finish" keyboard layout.
> This is because, although " ? " is construed as "complex" char and inserted properly the next "s" character is treated as non-complex character as it's utf8Length is 1 and utf16Length is 2, so we need to explicitly make it a "complex" char sequence if the code point is 0x73 ie "s" in Finnish layout for it to be inserted properly.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7262


From smandalika at openjdk.java.net  Thu Mar 24 04:42:45 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Thu, 24 Mar 2022 04:42:45 GMT
Subject: RFR: 8282640: Create a test for JDK-4740761 [v2]
In-Reply-To: <sIcj2VTJUwb2x3Y65R1-oyySW75Sm7SaMAltGbzxbio=.fdf6fe7c-de8c-4716-ac12-7c78d6559b24@github.com>
References: <Rr2xSJSr1_1WFxavIZtwz_rlxf15Yvd5dCxZ_1dcggs=.7415074d-6beb-434e-b463-04388e50b0c8@github.com>
 <MxC6iXzgDe8DbPKKvE4ZLW8Gr7VmlcgQdqD2T3zRiuo=.a1e71d71-262f-4ac7-b815-254e8045fe87@github.com>
 <sIcj2VTJUwb2x3Y65R1-oyySW75Sm7SaMAltGbzxbio=.fdf6fe7c-de8c-4716-ac12-7c78d6559b24@github.com>
Message-ID: <DmRLWRqMmcrBg2aMU6GRE_kOufP8qYaLf5zteewnmL0=.c78ca113-fadd-49d8-b6f3-7832d7ec54cd@github.com>

On Thu, 24 Mar 2022 03:29:45 GMT, Phil Race <prr at openjdk.org> wrote:

>> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added @bug keyword
>
> test/jdk/java/awt/Focus/8282640/ScrollPaneFocusBugTest.java line 102:
> 
>> 100:         robot.mousePress(InputEvent.BUTTON1_DOWN_MASK);
>> 101:         robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
>> 102: 
> 
> I presume the click is in case requestFocus didn't work and VK_1 is .. well any key will do ..

@prrace  Yes that is correct for both the points.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7686


From smandalika at openjdk.java.net  Thu Mar 24 04:45:49 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Thu, 24 Mar 2022 04:45:49 GMT
Subject: RFR: 8282640: Create a test for JDK-4740761 [v2]
In-Reply-To: <MxC6iXzgDe8DbPKKvE4ZLW8Gr7VmlcgQdqD2T3zRiuo=.a1e71d71-262f-4ac7-b815-254e8045fe87@github.com>
References: <Rr2xSJSr1_1WFxavIZtwz_rlxf15Yvd5dCxZ_1dcggs=.7415074d-6beb-434e-b463-04388e50b0c8@github.com>
 <MxC6iXzgDe8DbPKKvE4ZLW8Gr7VmlcgQdqD2T3zRiuo=.a1e71d71-262f-4ac7-b815-254e8045fe87@github.com>
Message-ID: <Kgtraf53rMNdQUmuKkF6Rbrz_hAvPV8TSsjVLzqFHEE=.475f0d8c-9579-40f6-96b7-f38abed8bc89@github.com>

On Fri, 11 Mar 2022 14:44:25 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a test for [JDK-4740761](https://bugs.openjdk.java.net/browse/JDK-4740761)
>> 
>> The issue observed is in a JFrame with a JTextField and a JScrollPane which contains focused component. When the JScrollPane was
>> is removed from its parent, focus stays with the the scroller
>> of the removed JScrollPane, instead of moving to the TextField.
>> 
>> The test verifies the same - i.e. it verifies that the removal of the scrollpane moves the focus to the JTextField present in the JFrame.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added @bug keyword

The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
@prrace Can you please sponsor this PR?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7686


From smandalika at openjdk.java.net  Thu Mar 24 04:54:39 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Thu, 24 Mar 2022 04:54:39 GMT
Subject: RFR: JDK-8283015: Create a test for JDK-4715496 [v5]
In-Reply-To: <LZoJNyo70FyzluriaUuavhRaJHU9hAr2av72xD-hAQQ=.fd638c33-85e8-4f15-b3dd-b738d6cc20cb@github.com>
References: <FZTHpImv7BXOuuYK-42rwC55GssXPQH2S8hwVIvAsfw=.1ba518e0-5c7f-4ed6-a9ce-667a859142c1@github.com>
 <LZoJNyo70FyzluriaUuavhRaJHU9hAr2av72xD-hAQQ=.fd638c33-85e8-4f15-b3dd-b738d6cc20cb@github.com>
Message-ID: <fiHpTwNFYm1zUa5d-cxp-sxcDOfxTVUQ8WrpjrNHV2M=.62f13103-d89c-472c-84a3-d673c11fc90f@github.com>

On Wed, 23 Mar 2022 10:12:26 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a test for JDK-4715496
>> 
>> Issue observed in the above bug is that the JTable.AccessibleJTableCell.getAccessible name returns the cell instance string instead of the cell text.
>> The test is being added to verify the same.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comment Fixed: JTable accessed on EDT

The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7787


From smandalika at openjdk.java.net  Thu Mar 24 04:58:32 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Thu, 24 Mar 2022 04:58:32 GMT
Subject: RFR: JDK-8282046: Create a regression test for JDK-8000326 [v7]
In-Reply-To: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
References: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
Message-ID: <ztlNmPdLbL8Ndda9Zu7cbLj4iY-SKiDvUpzqijeOMZE=.89d0b120-c82a-4947-b0bd-1605293e5cf2@github.com>

> Create a regression test for CCC8000326
> 
> Issue is identified by [JDK-8000326](https://bugs.openjdk.java.net/browse/JDK-8000326), which identifies that after focus moves into JMenuBar, whose focus traversal key is disabled by default, it never moves to other focusable component.
>  
> By default, pressing the Tab key does not transfer focus from a JMenuBar which is added to a container together with other Swing components, because the focusTraversalKeysEnabled property of JMenuBar is set to false. To resolve this, you should call the JMenuBar.setFocusTraversalKeysEnabled(true) method.
>  
> The test verifies focus traversal for the above described scenario.
> This review is for migrating tests from a closed test suite to open.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/awt/Focus/8000326/SetFocusTraversalKeysEnabledTest.java
  
  Added missing space after comma.
  
  Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7512/files
  - new: https://git.openjdk.java.net/jdk/pull/7512/files/ee31ac65..ea836807

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7512&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7512&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7512.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7512/head:pull/7512

PR: https://git.openjdk.java.net/jdk/pull/7512


From mvs at openjdk.java.net  Thu Mar 24 05:29:47 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Thu, 24 Mar 2022 05:29:47 GMT
Subject: RFR: 8282936: Write a regression test for JDK-4615365 [v2]
In-Reply-To: <yw_9DjvBobMpI44IyNNqFJ3lcnwsl4uD9wlMupvPWRc=.3f861f01-a72e-49d5-b5c4-6bbb1ef9ee50@github.com>
References: <9V6N62EUXtJ_TlONZHRMlwpDU3Pqymgs7daipoaSrB4=.f9110cf2-ba95-4e23-a93d-45ba5dbfeca2@github.com>
 <yw_9DjvBobMpI44IyNNqFJ3lcnwsl4uD9wlMupvPWRc=.3f861f01-a72e-49d5-b5c4-6bbb1ef9ee50@github.com>
Message-ID: <EgCMX4qa8ZnYbZP9cWETXpMl_Jy5_NHtas9btItDhmw=.88a9f6c0-e3f5-441e-a831-6ff8220b6112@github.com>

On Tue, 22 Mar 2022 06:29:16 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Write a regression test for [JDK-4615365](https://bugs.openjdk.java.net/browse/JDK-4615365) : JSplitPane current and last divider positions incorrect when realized
>> 
>> Issue:
>> JSplitPane component with a left and right component has its current divider
>> position incorrectly set to -1 once it is fully realized. For JDK 1.3.1, its
>> value is set to 0. The current position of the divider should be the current
>> position of the divider once layout management is complete. If the divider is
>> moved one pixel, the current divider position is updated to the correct value
>> but the last divider position is then set to -1 (i.e. the last value of the
>> current divider position). If the divider is moved again, everything is OK.
>> 
>> Testing:
>> Java 1.4.0 -> Test Failed.
>> $ j2sdk1.4.0/bin/java bug4615365
>> current= -1, last= 0
>> Test Failed.
>> 
>> Java 1.4.1 -> Test Passed.
>> $ j2sdk1.4.1/bin/java bug4615365
>> current= 97, last= -1
>> Test Passed.
>
> Manukumar V S has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Removed extra blank line before import static
>  - Review comment fixed: Limited 80 chars per line

@mrserb I have fixed the review comments, can you please have a look.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7802


From psadhukhan at openjdk.java.net  Thu Mar 24 06:34:50 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 24 Mar 2022 06:34:50 GMT
Subject: Integrated: 8283437: Refactor imageio classes javadoc to use @throws
 instead of @exception
In-Reply-To: <uTbaZ1i1WHvZAds5WsKZT0-7hvyLSphP91wUPAyv4qc=.3aa4a4d5-1131-4901-ba5b-07ca05788f06@github.com>
References: <uTbaZ1i1WHvZAds5WsKZT0-7hvyLSphP91wUPAyv4qc=.3aa4a4d5-1131-4901-ba5b-07ca05788f06@github.com>
Message-ID: <rTmX9GYKDRLw6KD7ZUx95fk7_y2U3-twGmyos79rAgE=.68d5145e-983f-407d-838b-f013e28fcfc6@github.com>

On Mon, 21 Mar 2022 06:13:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Prevailing JDK coding practices use "@throws" rather than "@exception".
> Refactor existing imageio classes javadoc to use @throws

This pull request has now been integrated.

Changeset: e6f707aa
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e6f707aa76ac231bef7d0abf1dd643bd7471067f
Stats:     775 lines in 51 files changed: 0 ins; 0 del; 775 mod

8283437: Refactor imageio classes javadoc to use @throws instead of @exception

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/7885


From psadhukhan at openjdk.java.net  Thu Mar 24 06:50:07 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 24 Mar 2022 06:50:07 GMT
Subject: RFR: 8283608: Refactor 2d,
 beans classes javadoc to use @throws instead of @exception
Message-ID: <cROy0eoUkBAdp5IOIcK9IcTzJtC7ZBDieR1ljOFnCmc=.9d1c8017-a0e2-4f16-85ea-42cd6f0a511c@github.com>

Prevailing JDK coding practices use "@throws" rather than "@exception".
Need to refactor remaining 2d, beans,sound classes to use @throws

-------------

Commit messages:
 - Fix
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/7937/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7937&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283608
  Stats: 56 lines in 22 files changed: 0 ins; 1 del; 55 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7937.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7937/head:pull/7937

PR: https://git.openjdk.java.net/jdk/pull/7937


From kizune at openjdk.java.net  Thu Mar 24 07:01:49 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 24 Mar 2022 07:01:49 GMT
Subject: RFR: 8281284 : Write JSlider accessibility test [v7]
In-Reply-To: <ffuhc7bE0polSSFA3gi1aDROXkbWZaww2fS5CHHpdD4=.94c24739-b557-4919-9b00-624cb89fa12f@github.com>
References: <VB8Ldq_d1uZBKpyvvDlu7t9lUtAd_WhLl4meSv46ixo=.b8b023ee-6946-407d-8e05-223fb2d95062@github.com>
 <ffuhc7bE0polSSFA3gi1aDROXkbWZaww2fS5CHHpdD4=.94c24739-b557-4919-9b00-624cb89fa12f@github.com>
Message-ID: <s9LpvoGe7oHcUlzDOTJyRVo36ZTJwAbOPIgUzhpLh3k=.637065a1-b5fa-4b43-9366-c403448bc1df@github.com>

On Mon, 21 Mar 2022 21:41:27 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> This testcase covers both old and new api ( api added in jdk17  getAccessibleAction(), getAccessibleActionCount() , getAccessibleActionDescription )
>> 
>> @shurymury 
>> @savoptik
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed AccessibleJSliderTest.java and add SliderDemo.java & SliderDemo.html

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7355


From serb at openjdk.java.net  Thu Mar 24 07:43:41 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 24 Mar 2022 07:43:41 GMT
Subject: RFR: 8283323: libharfbuzz optimization level results in extreme
 build times [v3]
In-Reply-To: <LuBItrR8_wljBxAh_Piefw9YYM1VU_uomclmmdgcd9E=.f6446f71-3527-45ae-ab92-309bb987f86b@github.com>
References: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
 <VlLT6x7sOuH6kaNBzDarXH_9a_885Q08IBNaCPglwWw=.982e18aa-3d27-4cf9-8554-84258e3b9359@github.com>
 <cxsg6M8rBMOyMH96Zqw6eQeeC2u3fnVh_6oX46IJ82E=.cdd74282-7838-4769-abd7-c9e15386d95e@github.com>
 <LuBItrR8_wljBxAh_Piefw9YYM1VU_uomclmmdgcd9E=.f6446f71-3527-45ae-ab92-309bb987f86b@github.com>
Message-ID: <KWgYAJsCxi9_Fyi6F2CR29Wc52L8DXinLJq3DTLEGmQ=.ad669abd-c3b5-443e-a5a8-c9771290e1f3@github.com>

On Thu, 24 Mar 2022 03:53:52 GMT, Phil Race <prr at openjdk.org> wrote:

> And unless you're backing up your claim that this patch is changing runtime characteristic with data, that's just a guess, just like the initial optimization level of this library (and as most of the native libraries in the JDK... :-() was just a guess. Otoh, that we get a build time regression for these two files is a proven fact.

All java2d libraries are compiled using HIGHEST, that option was bumped to this level over time because it was proved that they affect the performance, an example the last change: https://bugs.openjdk.java.net/browse/JDK-8264846
So I think we should check first that it does not affect performance, even if it is not used now it can be used in future version of harfbuzz.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7919


From iris at openjdk.java.net  Thu Mar 24 07:44:47 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 24 Mar 2022 07:44:47 GMT
Subject: RFR: 8283608: Refactor 2d,
 beans classes javadoc to use @throws instead of @exception
In-Reply-To: <cROy0eoUkBAdp5IOIcK9IcTzJtC7ZBDieR1ljOFnCmc=.9d1c8017-a0e2-4f16-85ea-42cd6f0a511c@github.com>
References: <cROy0eoUkBAdp5IOIcK9IcTzJtC7ZBDieR1ljOFnCmc=.9d1c8017-a0e2-4f16-85ea-42cd6f0a511c@github.com>
Message-ID: <rNuQgyRbCvzVQl6592yAZvQ178BGqk4b3CE6qwT3Lq4=.49d542e5-41a4-4273-b2c7-19c565ad0a02@github.com>

On Thu, 24 Mar 2022 06:43:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Prevailing JDK coding practices use "@throws" rather than "@exception".
> Need to refactor remaining 2d, beans,sound classes to use @throws

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7937


From serb at openjdk.java.net  Thu Mar 24 07:53:55 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 24 Mar 2022 07:53:55 GMT
Subject: RFR: 8274735: javax.imageio.IIOException: Unsupported Image Type
 while processing a valid JPEG image [v2]
In-Reply-To: <GEvsYdzfPsz0NRpK8YEWANuxd7tSuyBiGVFkMPwYI8w=.d83482ea-da92-4c94-8ac6-9c69de832552@github.com>
References: <gBv_Xtu5bmqpludbJWXwKpgvPCVz4BGYXbjErejjb1A=.cbe35817-d2cb-44bc-9f7b-d2597622623e@github.com>
 <kkMrJ3mLh2hD2fz968vOpUPm7XRMj2Nl6t0VPwFPpfc=.523668a3-3e68-4af1-a71f-d559252f04b9@github.com>
 <Qw5ScniD19CHPmI6Lh42bmy0kS5uOiQZCrwOhHe6pWM=.240bcef2-e710-4166-b3c0-de14f9e48604@github.com>
 <GEvsYdzfPsz0NRpK8YEWANuxd7tSuyBiGVFkMPwYI8w=.d83482ea-da92-4c94-8ac6-9c69de832552@github.com>
Message-ID: <4SlimA6QPSSOl8D7ERZNIZn9rp5ZO7Yqv60kMg_z4qQ=.78983f81-c175-4028-a6ee-ca92f6cb4ef5@github.com>

On Thu, 24 Mar 2022 02:52:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java line 1740:
>> 
>>> 1738:         raster.setRect(sourceLine);
>>> 1739:         if (invertCMYK) {
>>> 1740:             byte[] data = ((DataBufferByte)raster.getDataBuffer()).getData();
>> 
>> Is it known that the type of the raster here is always DataBufferByte?
>
> yes

As far as I understand the in the read code we create a DataBufferByte so later we can use the cast. But in this method we do not create it, and use what the user provide to us, can the user "craft custom " raster/metadata and the cs type?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7849


From serb at openjdk.java.net  Thu Mar 24 07:57:41 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 24 Mar 2022 07:57:41 GMT
Subject: RFR: JDK-8283015: Create a test for JDK-4715496 [v5]
In-Reply-To: <LZoJNyo70FyzluriaUuavhRaJHU9hAr2av72xD-hAQQ=.fd638c33-85e8-4f15-b3dd-b738d6cc20cb@github.com>
References: <FZTHpImv7BXOuuYK-42rwC55GssXPQH2S8hwVIvAsfw=.1ba518e0-5c7f-4ed6-a9ce-667a859142c1@github.com>
 <LZoJNyo70FyzluriaUuavhRaJHU9hAr2av72xD-hAQQ=.fd638c33-85e8-4f15-b3dd-b738d6cc20cb@github.com>
Message-ID: <DtybjT236sFAzHqa7dQ0WeA_VBiN9XEtdVjZ8wZVt18=.72c30feb-9ccc-4329-a088-bd8dcefac58f@github.com>

On Wed, 23 Mar 2022 10:12:26 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a test for JDK-4715496
>> 
>> Issue observed in the above bug is that the JTable.AccessibleJTableCell.getAccessible name returns the cell instance string instead of the cell text.
>> The test is being added to verify the same.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comment Fixed: JTable accessed on EDT

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7787


From serb at openjdk.java.net  Thu Mar 24 07:58:52 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 24 Mar 2022 07:58:52 GMT
Subject: RFR: 8282936: Write a regression test for JDK-4615365 [v2]
In-Reply-To: <yw_9DjvBobMpI44IyNNqFJ3lcnwsl4uD9wlMupvPWRc=.3f861f01-a72e-49d5-b5c4-6bbb1ef9ee50@github.com>
References: <9V6N62EUXtJ_TlONZHRMlwpDU3Pqymgs7daipoaSrB4=.f9110cf2-ba95-4e23-a93d-45ba5dbfeca2@github.com>
 <yw_9DjvBobMpI44IyNNqFJ3lcnwsl4uD9wlMupvPWRc=.3f861f01-a72e-49d5-b5c4-6bbb1ef9ee50@github.com>
Message-ID: <8Qd28-nr0KgUYDIn1NNagbt-AzIt6r633hW0ZUFFPPw=.041274ce-8aa7-4f08-bb82-58fbf69dc139@github.com>

On Tue, 22 Mar 2022 06:29:16 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Write a regression test for [JDK-4615365](https://bugs.openjdk.java.net/browse/JDK-4615365) : JSplitPane current and last divider positions incorrect when realized
>> 
>> Issue:
>> JSplitPane component with a left and right component has its current divider
>> position incorrectly set to -1 once it is fully realized. For JDK 1.3.1, its
>> value is set to 0. The current position of the divider should be the current
>> position of the divider once layout management is complete. If the divider is
>> moved one pixel, the current divider position is updated to the correct value
>> but the last divider position is then set to -1 (i.e. the last value of the
>> current divider position). If the divider is moved again, everything is OK.
>> 
>> Testing:
>> Java 1.4.0 -> Test Failed.
>> $ j2sdk1.4.0/bin/java bug4615365
>> current= -1, last= 0
>> Test Failed.
>> 
>> Java 1.4.1 -> Test Passed.
>> $ j2sdk1.4.1/bin/java bug4615365
>> current= 97, last= -1
>> Test Passed.
>
> Manukumar V S has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Removed extra blank line before import static
>  - Review comment fixed: Limited 80 chars per line

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7802


From smandalika at openjdk.java.net  Thu Mar 24 08:16:43 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Thu, 24 Mar 2022 08:16:43 GMT
Subject: RFR: JDK-8283015: Create a test for JDK-4715496 [v5]
In-Reply-To: <DtybjT236sFAzHqa7dQ0WeA_VBiN9XEtdVjZ8wZVt18=.72c30feb-9ccc-4329-a088-bd8dcefac58f@github.com>
References: <FZTHpImv7BXOuuYK-42rwC55GssXPQH2S8hwVIvAsfw=.1ba518e0-5c7f-4ed6-a9ce-667a859142c1@github.com>
 <LZoJNyo70FyzluriaUuavhRaJHU9hAr2av72xD-hAQQ=.fd638c33-85e8-4f15-b3dd-b738d6cc20cb@github.com>
 <DtybjT236sFAzHqa7dQ0WeA_VBiN9XEtdVjZ8wZVt18=.72c30feb-9ccc-4329-a088-bd8dcefac58f@github.com>
Message-ID: <awRcdNOcyCerbHdDonQCkcjmWSV0yMM8aB54nXxRZcg=.034107f3-3fbd-4135-a244-050dd16633b2@github.com>

On Thu, 24 Mar 2022 07:54:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review Comment Fixed: JTable accessed on EDT
>
> Marked as reviewed by serb (Reviewer).

@mrserb Can you please sponsor this PR ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7787


From mvs at openjdk.java.net  Thu Mar 24 08:51:50 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Thu, 24 Mar 2022 08:51:50 GMT
Subject: RFR: 8283507: Create a regression test for RFE 4287690 [v2]
In-Reply-To: <WnnAS2V7S8W5YMMCMbzOqtSYkhFbVrsakrGPFRRklYg=.4b504ee1-564d-44c1-be0a-07d90a93d288@github.com>
References: <SMPz0WRpMUC4SuuVSmlG6rsG_QudZ-1hCbjUzeMIdqk=.8318c1a4-4db6-4c0b-b24c-0b25b3d932a2@github.com>
 <WnnAS2V7S8W5YMMCMbzOqtSYkhFbVrsakrGPFRRklYg=.4b504ee1-564d-44c1-be0a-07d90a93d288@github.com>
Message-ID: <q9k4mCAxoY3d8UbX8nvHkNX4RjpD8gv6el_igwPvh0w=.43a14531-b407-4504-9a91-b82d0023a075@github.com>

On Wed, 23 Mar 2022 05:31:10 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Create a regression test for [JDK-4287690](https://bugs.openjdk.java.net/browse/JDK-4287690)
>> Issue description:
>> I want JComboBox to send an event just before the popup (drop down) list is displayed.
>> 
>> Fix:
>> This requires some additional API targeted for major release of the JDK (1.4).The PopupMenuEvent will from the JPopupMenu will be forwarded to the JComboBox. A client of the JComboBox can register itself as a PopupMenuListener to receive the notification.
>> So JComboBox should send drop down events when the drop down popup is visible as well as invisible. JComboBox.addPopupMenuListener(PopupMenuListener) can be used to register for pop up events.
>> 
>> Testing:
>> Tested using Mach5 in all platforms available(macos,linux and windows) and got all pass.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added one more related bug id 4331058 to @bug tag

Any volunteers please?.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7906


From kizune at openjdk.java.net  Thu Mar 24 08:55:48 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 24 Mar 2022 08:55:48 GMT
Subject: RFR: 8274735: javax.imageio.IIOException: Unsupported Image Type
 while processing a valid JPEG image [v2]
In-Reply-To: <kkMrJ3mLh2hD2fz968vOpUPm7XRMj2Nl6t0VPwFPpfc=.523668a3-3e68-4af1-a71f-d559252f04b9@github.com>
References: <gBv_Xtu5bmqpludbJWXwKpgvPCVz4BGYXbjErejjb1A=.cbe35817-d2cb-44bc-9f7b-d2597622623e@github.com>
 <kkMrJ3mLh2hD2fz968vOpUPm7XRMj2Nl6t0VPwFPpfc=.523668a3-3e68-4af1-a71f-d559252f04b9@github.com>
Message-ID: <Dt-JyySKRwBwaLIvU6eVevPiCbwB6Iq3EZJxH7X6fmA=.63133f49-68be-40b8-9462-d91fb5766f7a@github.com>

On Fri, 18 Mar 2022 18:21:06 GMT, Phil Race <prr at openjdk.org> wrote:

>> The JDK's built-in Image I/O JPEG plugin decodes JPEGs which are YCbCr and RGb and Grayscale but rejects CMYK and YCCK JPEGs.
>> These would correspond to JFIF encapsulated JPEGs.
>> 
>> This was a reasonable decision to limit support to what was actually likely to be seen - CMYK JPEGs probably should just be created for direct to print devices and never seen on the internet as an interchange format.
>> 
>> Indeed this (below) RFC for mail suggests JFIF is what clients should transmit :
>> 
>> https://datatracker.ietf.org/doc/html/rfc2046 :  Multipurpose Internet Mail Extensions - Part 2
>> 
>> 
>>    A media type of "image" indicates that the body contains an image.
>>    The subtype names the specific image format.  These names are not
>>    case sensitive. An initial subtype is "jpeg" for the JPEG format
>>    using JFIF encoding [JPEG].
>> 
>> And for many years, browsers either failed to display CMYK JPEGs or displayed them incorrectly.
>> 
>> But alas they do crop up and when they do, Image I/O rejects them - to the surprise and
>> consternation of some developer who knows little of JPEGs and arcane colour spaces.
>> 
>> Full support of CMYK JPEGs via the whole Image I/O API including proper handling as metadata
>> will lead us down a path that might even extend into EXIF support for JPEG and likely will
>> require the JPEG Metadata spec to be updated. 
>> 
>> So the goal here is to skirt that as much as possible by just 
>> (1) not rejecting read of CMYK JPEGs and returning a BufferedImage with a suitable ColorModel
>> (2) allowing the same BufferedImage with that ColorSpace to be written back out again as CMYK JPEGs 
>> 
>> Reading will preserve any embedded ICC Color Profile, but writing will not re-encode it since
>> that requires work on metadata. That will have to be a follow-up fix, but at the very least it
>> means that a re-written JPEG will benefit from a default treatment CMYK by any other client.
>> 
>> A test is provided which verifies that the colours are interpreted reasonably, both on initial read
>> and on write and re-read. 
>> 
>> JPEGs with embedded profiles have been tested on read, but since there are licensing issues with those,
>> the test uses JPEGs which have no embedded profile and depend on an internal implementation class.
>> 
>> That class has its hashCode() method updated because testing showed that toString() invoked hashCode()
>> in a way that caused a StackOverflowError - so nothing per se to do with this fix but a necessary update.
>> 
>> Anyone who has trustworthy CMYK JPEGs that render properly in (eg) major web browsers but not with this
>> code can submit those JPEGs so I can evaluate.
>> 
>> But all our automated tests pass as well as some manual testing and evaluation etc.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274735: javax.imageio.IIOException: Unsupported Image Type while processing a valid JPEG image

Tested it with some of the CMYK files that i created - seems like all the color conversions are valid and comparing screenshot of the decoded image with the native applications that support the format like Preview or Adobe Photoshop i see no noticeable deviations.

-------------

Marked as reviewed by kizune (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7849


From ihse at openjdk.java.net  Thu Mar 24 09:47:47 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 24 Mar 2022 09:47:47 GMT
Subject: RFR: 8283323: libharfbuzz optimization level results in extreme
 build times [v3]
In-Reply-To: <KWgYAJsCxi9_Fyi6F2CR29Wc52L8DXinLJq3DTLEGmQ=.ad669abd-c3b5-443e-a5a8-c9771290e1f3@github.com>
References: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
 <VlLT6x7sOuH6kaNBzDarXH_9a_885Q08IBNaCPglwWw=.982e18aa-3d27-4cf9-8554-84258e3b9359@github.com>
 <cxsg6M8rBMOyMH96Zqw6eQeeC2u3fnVh_6oX46IJ82E=.cdd74282-7838-4769-abd7-c9e15386d95e@github.com>
 <LuBItrR8_wljBxAh_Piefw9YYM1VU_uomclmmdgcd9E=.f6446f71-3527-45ae-ab92-309bb987f86b@github.com>
 <KWgYAJsCxi9_Fyi6F2CR29Wc52L8DXinLJq3DTLEGmQ=.ad669abd-c3b5-443e-a5a8-c9771290e1f3@github.com>
Message-ID: <JETfYU9ZaStSiQ8Mo0ffXp72KQYKlx7ZFLJounMrz5s=.32c5071a-ba83-4d70-ae7e-0861eddf3c4c@github.com>

On Thu, 24 Mar 2022 07:38:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> @mrserb Phil said that we don't even use the subset part of harfbuzz.
>>> 
>>> And unless you're backing up your claim that this patch is changing runtime characteristic with data, that's just a guess, just like the initial optimization level of this library (and as most of the native libraries in the JDK... :-() was just a guess. Otoh, that we get a build time regression for these two files is a proven fact.
>>> 
>>> What is it you want to cache?
>> 
>> It is a reasonable question. Build times might seem important to a small number of developers but runtime performance is King. That's why I asked to reduce it to just the files we don't care about. 
>> Would we give up even 0.1% of hotspot GC performance on Linux to avoid 30 seconds of compile time ?
>> I doubt it. 
>> And haven't we improved compile time a lot with the parallelism ? So are we now over-optimising in the wrong place ?
>> I mean good to keep an eye on it but I mean if a previous build arch took 15 mins and now with parallelism we take 3 mins and 45 secs .. is it so bad to be back up to 4 mins for more runtime benefit ? (Numbers entirely made up)
>> There's always going to be a long pole (something that is last) and the questions are whether its understood and for a good reason and so forth. I mean we can doubtless try to improve but at some point it is diminishing returns.
>> Perhaps someone can ask gcc devs why they are so slow on this code ? Maybe there's a good reason that helps runtime or maybe they just have design issues. They may want to know.
>
>> And unless you're backing up your claim that this patch is changing runtime characteristic with data, that's just a guess, just like the initial optimization level of this library (and as most of the native libraries in the JDK... :-() was just a guess. Otoh, that we get a build time regression for these two files is a proven fact.
> 
> All java2d libraries are compiled using HIGHEST, that option was bumped to this level over time because it was proved that they affect the performance, an example the last change: https://bugs.openjdk.java.net/browse/JDK-8264846
> So I think we should check first that it does not affect performance, even if it is not used now it can be used in future version of harfbuzz.

@mrserb As Phil has stated twice, this code is not used by the JDK, so will not affect performance.

It is impossible to predict what future changes in harfbuzz will do to our performance. That will of course needed to be tested when we update harfbuzz. If it turns out that setting this optimization level is detrimental to our performance at that point of time, we'll of course do what fixes needs to be done, at that point.

@prrace The sad truth is that java.desktop-libs is at the end of the long pole, due to how different modules are interrelated. :-( That means that the compilation time for these native libraries tend to dominate the entire build time, regardless of how parallelized the rest of the build can be made. (cf. Amdahl's law) 

I'll look into once more if we can do some shenanigans to try to get around some of these dependencies, but I'm not sure it's possible.

I encourage you to report this to both upstream harfbuzz and gcc.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7919


From ihse at openjdk.java.net  Thu Mar 24 09:52:48 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 24 Mar 2022 09:52:48 GMT
Subject: Integrated: 8283323: libharfbuzz optimization level results in extreme
 build times
In-Reply-To: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
References: <325HwYt25cVeEeXUTaz59Ymv_8rsSLOwJbpWNZGtdnQ=.aaaa2d55-75a2-4d47-9377-b6fe7cf862f5@github.com>
Message-ID: <ekJYWAbTMN2CpKeG0HB-o7Gu3mHr-Y09gi5IbMg6aPo=.7c2590e0-48bf-4106-8f06-d885fd532f4b@github.com>

On Wed, 23 Mar 2022 12:25:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference linux machine. This was one of the four culprits that caused a 25-30% build time regression over the last two years.
> 
> The problem here was that the new HarfBuzz code caught really bad behaviour from gcc when compiling with optimizations. The official HarfBuzz build does not use any -O flags at all for gcc, so presumably the HarfBuzz team is:
> 
> a) not thinking compiler optimization is important for the performance of this library, and
> b) unaware that their code causes such a headache for gcc.
> 
> (Other compilers fare much better: visual studio makes no difference at all, and for clang just a small regression was observed.)
> 
> The current optimization level was introduced by [JDK-8255790](https://bugs.openjdk.java.net/browse/JDK-8255790), which were really about moving libharfbuzz compilation back into libfontmanager. I could find no comments/discussion relating to the change of optimization level, so I assume it was incidental, and just seemed good at the time.
> 
> This patch changes the optimization level to `SIZE` (which is the closest thing we have to no optimization level) on gcc.

This pull request has now been integrated.

Changeset: 2c43ecb4
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2c43ecb43fa3c94b69478039f1cd70ed4a577768
Stats:     9 lines in 1 file changed: 8 ins; 1 del; 0 mod

8283323: libharfbuzz optimization level results in extreme build times

Reviewed-by: erikj, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/7919


From avu at openjdk.java.net  Thu Mar 24 14:33:26 2022
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Thu, 24 Mar 2022 14:33:26 GMT
Subject: RFR: 8273355: Flickering on tooltip appearance IntelliJ IDEA
 2021.2.1 [v2]
In-Reply-To: <_Q4d9YdOccAdjO6LsIlbIOt55Bn7PGAz3-NmVBF2vLU=.01b029e3-f88f-4b6b-b12b-3509f9dcd486@github.com>
References: <_Q4d9YdOccAdjO6LsIlbIOt55Bn7PGAz3-NmVBF2vLU=.01b029e3-f88f-4b6b-b12b-3509f9dcd486@github.com>
Message-ID: <I-IQ2EPZ_FM-zbqGAPxtHtkfFYCjaorAC6IO_WzokRM=.ec4826b6-e6ce-4067-ac23-a96fbf2021a9@github.com>

> Used setOpaque() method to set correct background of platform window
> Extracted setting background to the particular method in PlatformWindow. Provided appropriate implementation in CPlatformWindow.

Alexey Ushakov has updated the pull request incrementally with two additional commits since the last revision:

 - 8273355: Flickering on tooltip appearance IntelliJ IDEA 2021.2.1
   
   Override setBackground() for LWWindowPeer to set background color for native window.
 - Revert "8273355: Flickering on tooltip appearance IntelliJ IDEA 2021.2.1"
   
   This reverts commit 47a448c2a0781a79e0175914992af626c2eeb4b4.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7931/files
  - new: https://git.openjdk.java.net/jdk/pull/7931/files/47a448c2..8faccd68

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7931&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7931&range=00-01

  Stats: 36 lines in 5 files changed: 11 ins; 25 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7931.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7931/head:pull/7931

PR: https://git.openjdk.java.net/jdk/pull/7931


From avu at openjdk.java.net  Thu Mar 24 14:33:28 2022
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Thu, 24 Mar 2022 14:33:28 GMT
Subject: RFR: 8273355: Flickering on tooltip appearance IntelliJ IDEA
 2021.2.1 [v2]
In-Reply-To: <88P-u7cRkyFDdNY_J7mxwjKA6UAd6Jqe31yuSZIYoV4=.865990c7-615b-4417-b10b-60ffe9f0d766@github.com>
References: <_Q4d9YdOccAdjO6LsIlbIOt55Bn7PGAz3-NmVBF2vLU=.01b029e3-f88f-4b6b-b12b-3509f9dcd486@github.com>
 <88P-u7cRkyFDdNY_J7mxwjKA6UAd6Jqe31yuSZIYoV4=.865990c7-615b-4417-b10b-60ffe9f0d766@github.com>
Message-ID: <XUJMlk1enGMJLYHkYfUDOpIuTL2X0el-mQV1_PWqK-0=.43b55792-5da3-40c7-a5af-f39c91c22210@github.com>

On Wed, 23 Mar 2022 23:30:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> If it skips the texture property I guess it will break it?
I've not noticed it in my testing. Do you mean particular tests? But anyway your suggestion looks more elegant and it works in my scenarios, also I've run test-jdk_desktop_part1 with it. No related problem was found.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7931


From mvs at openjdk.java.net  Thu Mar 24 15:29:20 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Thu, 24 Mar 2022 15:29:20 GMT
Subject: RFR: 8283621: Write a regression test for CCC4400728
Message-ID: <rnjTXKruqaPPPREorlsQv7c8rcSNE9BUqiAdoVPML0w=.b9c187ff-9050-4cae-9c5a-435b451213dd@github.com>

Write a regression test for [JDK-4400728](https://bugs.openjdk.java.net/browse/JDK-4400728)

Issue:
JFileChooser constructors by default set current directory to the "Desktop" value on Windows,
but should use 'My Documents' property instead, also user.home for unix platforms.

javadoc says:
"public JFileChooser()
Constructs a JFileChooser pointing to the user's default directory. This default depends on the operating system. It is typically the 'My Documents' folder on Windows, and the user's home directory on Unix.
"
See this https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JFileChooser.html#%3Cinit%3E()

Testing:
1. Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.
2. Tested in original failed Java version and the fixed version;
Java 1.4.0 -> Test Failed.
$ j2sdk1.4.0/bin/java JFileChooserDefaultDirectoryTest
java.lang.NullPointerException
        at java.io.File.<init>(File.java:180)
        at sun.awt.shell.Win32ShellFolder.listFiles(Win32ShellFolder.java:517)
        at sun.awt.shell.Win32ShellFolderManager.get(Win32ShellFolderManager.java:152)
        at sun.awt.shell.ShellFolder.get(ShellFolder.java:208)
        at javax.swing.plaf.metal.MetalFileChooserUI.installComponents(MetalFileChooserUI.java:310)
        at javax.swing.plaf.basic.BasicFileChooserUI.installUI(BasicFileChooserUI.java:130)
        at javax.swing.plaf.metal.MetalFileChooserUI.installUI(MetalFileChooserUI.java:152)
        at javax.swing.JComponent.setUI(JComponent.java:445)
        at javax.swing.JFileChooser.updateUI(JFileChooser.java:1701)
        at javax.swing.JFileChooser.setup(JFileChooser.java:345)
        at javax.swing.JFileChooser.<init>(JFileChooser.java:320)
        at javax.swing.JFileChooser.<init>(JFileChooser.java:273)
        at JFileChooserDefaultDirectoryTest.main(JFileChooserDefaultDirectoryTest.java:15)
Exception in thread "main"

Java 1.5.0 -> Test Passed.
$ jdk1.5.0/bin/java JFileChooserDefaultDirectoryTest
UserHome dir = C:\Users\jpgansible
Test Passed

Java 1.8.0 -> Test Passed.
$ jdk1.8.0_331/bin/java JFileChooserDefaultDirectoryTest
UserHome dir = C:\Users\jpgansible
Test Passed

-------------

Commit messages:
 - 8283621: Write a regression test for CCC4400728

Changes: https://git.openjdk.java.net/jdk/pull/7942/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7942&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283621
  Stats: 71 lines in 1 file changed: 71 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7942.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7942/head:pull/7942

PR: https://git.openjdk.java.net/jdk/pull/7942


From aivanov at openjdk.java.net  Thu Mar 24 16:23:53 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 24 Mar 2022 16:23:53 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v7]
In-Reply-To: <WiEx5Y_45gZ6T87k39sxgvneubJBZ4mCWgoFo0Iytdc=.c4b9895f-e706-4124-91e6-2d21539d5226@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
 <WiEx5Y_45gZ6T87k39sxgvneubJBZ4mCWgoFo0Iytdc=.c4b9895f-e706-4124-91e6-2d21539d5226@github.com>
Message-ID: <Z3ucScsP7VGuLsY-WnSBP9mXOkycXG8K__K-nKYZDAo=.c65322bf-b117-4123-8a6e-edef4b6a593f@github.com>

On Thu, 24 Mar 2022 03:07:28 GMT, Phil Race <prr at openjdk.org> wrote:

> I have been following along although my comments may seem a bit dated.
> 
>     1. @aivanov-jdk wrote (scroll up a lot)
>        When uiScale=1.25, you can see there's background color between the shadow and highlight on the second panel.
> 
> I have no idea where I should be seeing that. I see nothing like that. Perhaps I am looking in the wrong place

I attached the screenshot to that comment. The second panel has this problem.

Yet you have to enlarge the image to see it clearly. Here's the part of that screenshot zoomed in to 400%:
![Titled Border @ 125% ? Enlarged to 400%](https://user-images.githubusercontent.com/70774172/159961706-9b6a3220-880f-4cb4-8722-b18e7857b573.png)

The left and top sides of the 'Title 1' border have gray background between the shadow and highlight; the right and bottom don't.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From aivanov at openjdk.java.net  Thu Mar 24 16:32:48 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 24 Mar 2022 16:32:48 GMT
Subject: RFR: 8276849: Refresh the window icon on graphics configuration
 changes [v4]
In-Reply-To: <elb291CEaz1C9fY4_1Md9urOqwoyoKeaU2LPPyCHBsQ=.ba5e0960-5334-4f55-86a4-062367d4e745@github.com>
References: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
 <0oxxlnAHynu4eIJIE8cMzXJlpU7I_CF1kBk4IYSN3YY=.e8b93bca-4b06-4a70-82db-aa608d6bb350@github.com>
 <elb291CEaz1C9fY4_1Md9urOqwoyoKeaU2LPPyCHBsQ=.ba5e0960-5334-4f55-86a4-062367d4e745@github.com>
Message-ID: <lnWwCSMRHYZo4ZZDUyHyIlMSL7Wxk4OgIlVYeXggROY=.a071c5f3-efd7-4347-ba6e-0adc7481342a@github.com>

On Wed, 23 Feb 2022 21:34:29 GMT, Emmanuel Bourg <duke at openjdk.java.net> wrote:

>> Emmanuel Bourg has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Test case for the window icon update on DPI change (Java generic font names are usually capitalized)
>>  - Test case for the window icon update on DPI change (dispose the frame after a timeout on the EDT)
>
> Just tested on macOS 12 with a non Retina screen and OpenJDK 8: the icon displayed in the dock when the test frame is minimized is the 32x32 one. If I add more icons to the list, it picks the biggest one, up to 128x128. Bigger icons are ignored.
> 
> The issue observed on Windows doesn't really transpose to macOS, I think I'll revert the change to `LWWindowPeer`.

> @ebourg @aivanov-jdk are the remaining issues test issues, or might there still be product issues ? No pressure to push but let's not forget about it either.

Windows side looks reasonable to me. The window updates the icon when it's dragged from one monitor to another with different scale.

macOS changes have been reverted.

I couldn't see the icon updates on Linux. Should the changes for Linux be reverted too?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6180


From aivanov at openjdk.java.net  Thu Mar 24 16:43:52 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 24 Mar 2022 16:43:52 GMT
Subject: RFR: 8276849: Refresh the window icon on graphics configuration
 changes [v5]
In-Reply-To: <8ubPWqU0vTLZW-eX7r2v9GAvrlp_4-mRKwuz8jwPHlM=.ee58d4d6-1ad0-409a-98cb-2d839e8187d6@github.com>
References: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
 <8ubPWqU0vTLZW-eX7r2v9GAvrlp_4-mRKwuz8jwPHlM=.ee58d4d6-1ad0-409a-98cb-2d839e8187d6@github.com>
Message-ID: <TxWUE191hJSeEVVusTwHAbR9MJLOqauwQWABUvejnbU=.57a2f792-81fb-49d2-a0ba-eb464e4987a9@github.com>

On Fri, 25 Feb 2022 12:39:50 GMT, Emmanuel Bourg <duke at openjdk.java.net> wrote:

>> When a list of icons is set on a window, the most appropiate icon is selected depending on the graphics configuration. But if the graphics configuration changes (because the window is moved to a different screen, or because the DPI settings of the screen is changed), the frame icon isn't updated.
>> 
>> Here is an example illustrating the issue:
>> 
>>     public static void main(String[] args) throws Exception {
>>         SwingUtilities.invokeLater(() -> {
>>             JFrame frame = new JFrame("Window Icon Test");
>>             frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
>>             frame.setSize(400, 300);
>>             frame.setVisible(true);
>> 
>>             List<Image> images = new ArrayList<>();
>>             for (int size = 16; size <= 32; size++) {
>>                 // create an image displaying the size used
>>                 BufferedImage image = new BufferedImage(size, size, BufferedImage.TYPE_INT_ARGB);
>>                 Graphics2D g = image.createGraphics();
>>                 g.setFont(new Font("dialog", Font.BOLD, 12));
>>                 g.setColor(Color.BLACK);
>>                 g.drawString(String.valueOf(size), 0, size - (size - g.getFont().getSize()) / 2);
>>                 images.add(image);
>>             }
>> 
>>             frame.setIconImages(images);
>>         });
>>     }
>> 
>> On Windows if the screen scaling is set to 100% the 16x16 icon is picked from the list. If the scaling of the screen is set to 150% while the application is running, the 16x16 icon is upscaled and looks blurry.
>> 
>> A way to work around this issue is to listen for graphics configuration changes with:
>> 
>>     frame.addPropertyChangeListener("graphicsConfiguration", event -> frame.setIconImages(frame.getIconImages()));
>> 
>> 
>> Ideally this should be done automatically by the JDK. Maybe the `WindowPeer` could call `updateIconImages()` when `updateGraphicsData()` or `displayChanged()` is invoked?
>
> Emmanuel Bourg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't refresh the frame icon on graphics configuration changes on macOS (not applicable)

The test should not be run on macOS because it doesn't apply.

Add the following tag to test tags comments.

 * @requires os.family != "mac"


If Linux modifications are removed, the test will be for Windows only:


 * @requires os.family == "windows"

-------------

Changes requested by aivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6180


From duke at openjdk.java.net  Thu Mar 24 16:57:50 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Thu, 24 Mar 2022 16:57:50 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v3]
In-Reply-To: <AI90_XpQ47CeM9u1p7brUJMBFddpJgfVXFfBZIYtGfw=.7489df4f-b643-4d9e-b1dd-b15ba1b6a1ad@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>
 <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>
 <oAZ5tpWpksvN6sfEYoblyucXf_EqcxKAIiVvkvIugjU=.a10e37ec-b8e8-4ac3-9faf-f2a8d85189af@github.com>
 <r9ujiKOC7dRsKCLNjUEt-V8mCstzXKJLFPRQ1O6kqKs=.2b96988b-85c6-45d5-9d95-2e0112b458fb@github.com>
 <AUeNFfcZNdDhRKJExOY7lT7_eG07ZQ_E124iHS_oiVI=.af2824b3-dc46-4318-92c3-27a861269339@github.com>
 <0U4ZvK_ui_ieG7pPZAdhL1AyrJYQNqT0A_HRJIE8InQ=.26f7a810-a6a0-47d0-99d9-e2ffcfebe596@github.com>
 <ML4CSxlvMzInAbk9K0LicDa--V4QlgiUzzL1u7XkJ0s=.d8c7a73c-402a-4813-8fc6-faf9fd07745a@github.com>
 <9-KCaxc5kvdWS_6nETGIRiJgbTEWTWEPxmKT5JHSphw=.0bf35082-2b55-4cfd-bc7a-636a6d7a721a@github.com>
 <fYlGXZDTHTU5qaTisZmz9LLOKG7ShMugqXOMGDmiBPY=.b43629cd-7474-48a9-9e0f-3a9729808294@github.com>
 <-k8sDdAZltd4AcDIIOeKBcKLZ4q9XuTs6sT
 5Mmg2Q9I=.025a647c-34a7-478b-912d-7bfd4a7473b4@github.com>
 <AI90_XpQ47CeM9u1p7brUJMBFddpJgfVXFfBZIYtGfw=.7489df4f-b643-4d9e-b1dd-b15ba1b6a1ad@github.com>
Message-ID: <RkgzdiaxcFiGijoKtrGci5FPKKcJU7d8vDLBdt1Rftk=.88653824-bf2f-4f5b-9c69-bbb536e49ee0@github.com>

On Thu, 17 Mar 2022 18:08:40 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> There are two different approaches that we can take at this point.
>> 
>> 1. Do we go forward with the present changes? (hue and saturation offset, brightness set to 100%) 
>> 2. Keep a common cell focus ring color - Blue as observed in few native apps (Numbers App). In this scenario we keep the cell focus ring color set to blue when selection background color is NOT blue and return a different color when selection background is Blue.
>> 
>> Trying to find the best solution that takes into account native L&F and present Aqua L&F implementations.
>
>> Probably to get an identical focus ring, we need to use [NSSetFocusRingStyle](https://developer.apple.com/documentation/appkit/1473702-nssetfocusringstyle?language=objc)
> 
> This is more about placement of the focus ring (and available only from macOS 10.1+ versions) and would require native code changes. Might not be an ideal solution in this context.

Following was another suggestion and if we could use the code to produce brighter focus ring color
[Github Link](https://github.com/openjdk/jdk/commit/2f16ca0f59892fead80b209f7819bdbdb713329a) 

Since the code uses a fixed value for minBrightnessDifference (which determines the returned color),  it did return brighter shade of the background, but it was not prominent/visible against the selection background color for all colors.
The same is true with using Color's brighter() and darker() methods to obtain the Cell Focus Ring color.

The idea behind the present solution is to obtain a cell focus ring color that is not just a brighter shade of selection background but to offset the hue and saturation such that it is prominent but at the same time a color close to the selection background color.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From psadhukhan at openjdk.java.net  Thu Mar 24 17:12:49 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 24 Mar 2022 17:12:49 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v3]
In-Reply-To: <RkgzdiaxcFiGijoKtrGci5FPKKcJU7d8vDLBdt1Rftk=.88653824-bf2f-4f5b-9c69-bbb536e49ee0@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>
 <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>
 <oAZ5tpWpksvN6sfEYoblyucXf_EqcxKAIiVvkvIugjU=.a10e37ec-b8e8-4ac3-9faf-f2a8d85189af@github.com>
 <r9ujiKOC7dRsKCLNjUEt-V8mCstzXKJLFPRQ1O6kqKs=.2b96988b-85c6-45d5-9d95-2e0112b458fb@github.com>
 <AUeNFfcZNdDhRKJExOY7lT7_eG07ZQ_E124iHS_oiVI=.af2824b3-dc46-4318-92c3-27a861269339@github.com>
 <0U4ZvK_ui_ieG7pPZAdhL1AyrJYQNqT0A_HRJIE8InQ=.26f7a810-a6a0-47d0-99d9-e2ffcfebe596@github.com>
 <ML4CSxlvMzInAbk9K0LicDa--V4QlgiUzzL1u7XkJ0s=.d8c7a73c-402a-4813-8fc6-faf9fd07745a@github.com>
 <9-KCaxc5kvdWS_6nETGIRiJgbTEWTWEPxmKT5JHSphw=.0bf35082-2b55-4cfd-bc7a-636a6d7a721a@github.com>
 <fYlGXZDTHTU5qaTisZmz9LLOKG7ShMugqXOMGDmiBPY=.b43629cd-7474-48a9-9e0f-3a9729808294@github.com>
 <-k8sDdAZltd4AcDIIOeKBcKLZ4q9XuTs6sT
 5Mmg2Q9I=.025a647c-34a7-478b-912d-7bfd4a7473b4@github.com>
 <AI90_XpQ47CeM9u1p7brUJMBFddpJgfVXFfBZIYtGfw=.7489df4f-b643-4d9e-b1dd-b15ba1b6a1ad@github.com>
 <RkgzdiaxcFiGijoKtrGci5FPKKcJU7d8vDLBdt1Rftk=.88653824-bf2f-4f5b-9c69-bbb536e49ee0@github.com>
Message-ID: <gWFZ-lD8CQMjC69_dKMfB7F8a_4ZxUGlWwlUeAwCYlU=.546f5569-0309-45ce-8228-000e56dbbe66@github.com>

On Thu, 24 Mar 2022 16:53:42 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>>> Probably to get an identical focus ring, we need to use [NSSetFocusRingStyle](https://developer.apple.com/documentation/appkit/1473702-nssetfocusringstyle?language=objc)
>> 
>> This is more about placement of the focus ring (and available only from macOS 10.1+ versions) and would require native code changes. Might not be an ideal solution in this context.
>
> Following was another suggestion and if we could use the code to produce brighter focus ring color
> [Github Link](https://github.com/openjdk/jdk/commit/2f16ca0f59892fead80b209f7819bdbdb713329a) 
> 
> Since the code uses a fixed value for minBrightnessDifference (which determines the returned color),  it did return brighter shade of the background, but it was not prominent/visible against the selection background color for all colors.
> The same is true with using Color's brighter() and darker() methods to obtain the Cell Focus Ring color.
> 
> The idea behind the present solution is to obtain a cell focus ring color that is not just a brighter shade of selection background but to offset the hue and saturation such that it is prominent but at the same time a color close to the selection background color.

I guess using "color close to selection background color" seems wrong to me...either we need to use "blue" as used in native Numbers app...or if we need to use system color, then maybe use the accent color (as defined in System Preference) as focus ring color [ there's another Apple bug [JDK-8261243](https://bugs.openjdk.java.net/browse/JDK-8261243) of JDK not following accent color for focus ring for some widgets]...

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From prr at openjdk.java.net  Thu Mar 24 18:02:45 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 24 Mar 2022 18:02:45 GMT
Subject: RFR: 8283608: Refactor 2d,
 beans classes javadoc to use @throws instead of @exception
In-Reply-To: <cROy0eoUkBAdp5IOIcK9IcTzJtC7ZBDieR1ljOFnCmc=.9d1c8017-a0e2-4f16-85ea-42cd6f0a511c@github.com>
References: <cROy0eoUkBAdp5IOIcK9IcTzJtC7ZBDieR1ljOFnCmc=.9d1c8017-a0e2-4f16-85ea-42cd6f0a511c@github.com>
Message-ID: <14oisFaQjimqr-z2Kj3phrWLl9koCRnAkvJ2TqruCK8=.319739f1-efc6-4aa9-bdbf-ac85a9d29c66@github.com>

On Thu, 24 Mar 2022 06:43:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Prevailing JDK coding practices use "@throws" rather than "@exception".
> Need to refactor remaining 2d, beans,sound classes to use @throws

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7937


From prr at openjdk.java.net  Thu Mar 24 18:13:43 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 24 Mar 2022 18:13:43 GMT
Subject: RFR: 8274735: javax.imageio.IIOException: Unsupported Image Type
 while processing a valid JPEG image [v2]
In-Reply-To: <4SlimA6QPSSOl8D7ERZNIZn9rp5ZO7Yqv60kMg_z4qQ=.78983f81-c175-4028-a6ee-ca92f6cb4ef5@github.com>
References: <gBv_Xtu5bmqpludbJWXwKpgvPCVz4BGYXbjErejjb1A=.cbe35817-d2cb-44bc-9f7b-d2597622623e@github.com>
 <kkMrJ3mLh2hD2fz968vOpUPm7XRMj2Nl6t0VPwFPpfc=.523668a3-3e68-4af1-a71f-d559252f04b9@github.com>
 <Qw5ScniD19CHPmI6Lh42bmy0kS5uOiQZCrwOhHe6pWM=.240bcef2-e710-4166-b3c0-de14f9e48604@github.com>
 <GEvsYdzfPsz0NRpK8YEWANuxd7tSuyBiGVFkMPwYI8w=.d83482ea-da92-4c94-8ac6-9c69de832552@github.com>
 <4SlimA6QPSSOl8D7ERZNIZn9rp5ZO7Yqv60kMg_z4qQ=.78983f81-c175-4028-a6ee-ca92f6cb4ef5@github.com>
Message-ID: <8Yijf4pThD4wJjpURwbT3oFzEBHZG097VZYZCnSDdFY=.d56c904b-6061-47ef-9142-7a3357ab2dd1@github.com>

On Thu, 24 Mar 2022 07:50:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> yes
>
> As far as I understand the in the read code we create a DataBufferByte so later we can use the cast. But in this method we do not create it, and use what the user provide to us, can the user "craft custom " raster/metadata and the cs type?

Yes we do. This raster is created here in the ImageWriter as follows 

        // Create an appropriate 1-line databuffer for writing
        int lineSize = sourceWidth*numBandsUsed;

        DataBufferByte buffer = new DataBufferByte(lineSize);

        // Create a raster from that
        int [] bandOffs = JPEG.bandOffsets[numBandsUsed-1];

        raster = Raster.createInterleavedRaster(buffer,
                                                sourceWidth, 1,
                                                lineSize,
                                                numBandsUsed,
                                                bandOffs,
                                                null);

-------------

PR: https://git.openjdk.java.net/jdk/pull/7849


From serb at openjdk.java.net  Thu Mar 24 18:28:52 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 24 Mar 2022 18:28:52 GMT
Subject: RFR: 8273355: Flickering on tooltip appearance IntelliJ IDEA
 2021.2.1 [v2]
In-Reply-To: <XUJMlk1enGMJLYHkYfUDOpIuTL2X0el-mQV1_PWqK-0=.43b55792-5da3-40c7-a5af-f39c91c22210@github.com>
References: <_Q4d9YdOccAdjO6LsIlbIOt55Bn7PGAz3-NmVBF2vLU=.01b029e3-f88f-4b6b-b12b-3509f9dcd486@github.com>
 <88P-u7cRkyFDdNY_J7mxwjKA6UAd6Jqe31yuSZIYoV4=.865990c7-615b-4417-b10b-60ffe9f0d766@github.com>
 <XUJMlk1enGMJLYHkYfUDOpIuTL2X0el-mQV1_PWqK-0=.43b55792-5da3-40c7-a5af-f39c91c22210@github.com>
Message-ID: <_ot6GP1XwCF5oSXrGTJgDedUDbbhEw-UNxd6uDP4EUo=.dda400c1-e463-46c2-b0e7-ff8b556c7d99@github.com>

On Thu, 24 Mar 2022 14:27:46 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/lwawt/LWWindowPeer.java line 298:
>> 
>>> 296:             Color color = getBackground();
>>> 297:             if (color != null) {
>>> 298:                 platformWindow.setBackground(color);
>> 
>> If it skips the texture property I guess it will break it?
>> I think the easiest solution for this issue is to add a new method to the LWWindowPeer:
>>  ```
>>    public void setBackground(final Color c) {
>>         Color oldBg = getBackground();
>>         if (oldBg == c || (oldBg != null && oldBg.equals(c))) {
>>             return;
>>         }
>>         super.setBackground(c);
>>         updateOpaque();
>>     }
>> }
>
>> If it skips the texture property I guess it will break it?
> I've not noticed it in my testing. Do you mean particular tests? But anyway your suggestion looks more elegant and it works in my scenarios, also I've run test-jdk_desktop_part1 with it. No related problem was found.

The CPlatformWindow.setOpaque() changes the background of the native window only if the texture property is not set. So if the code will change the color directly somewhere then the texture property will be broken. Not sure that we have a test for that.
Please update the copyright date.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7931


From serb at openjdk.java.net  Thu Mar 24 18:31:40 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 24 Mar 2022 18:31:40 GMT
Subject: RFR: 8274735: javax.imageio.IIOException: Unsupported Image Type
 while processing a valid JPEG image [v2]
In-Reply-To: <kkMrJ3mLh2hD2fz968vOpUPm7XRMj2Nl6t0VPwFPpfc=.523668a3-3e68-4af1-a71f-d559252f04b9@github.com>
References: <gBv_Xtu5bmqpludbJWXwKpgvPCVz4BGYXbjErejjb1A=.cbe35817-d2cb-44bc-9f7b-d2597622623e@github.com>
 <kkMrJ3mLh2hD2fz968vOpUPm7XRMj2Nl6t0VPwFPpfc=.523668a3-3e68-4af1-a71f-d559252f04b9@github.com>
Message-ID: <1gVW3LP-UNoy-upvIDN-sM0Ltbhr1f7cRvL0qIcZN5Q=.a3a4028c-50b0-42b0-8af3-8a78f601090f@github.com>

On Fri, 18 Mar 2022 18:21:06 GMT, Phil Race <prr at openjdk.org> wrote:

>> The JDK's built-in Image I/O JPEG plugin decodes JPEGs which are YCbCr and RGb and Grayscale but rejects CMYK and YCCK JPEGs.
>> These would correspond to JFIF encapsulated JPEGs.
>> 
>> This was a reasonable decision to limit support to what was actually likely to be seen - CMYK JPEGs probably should just be created for direct to print devices and never seen on the internet as an interchange format.
>> 
>> Indeed this (below) RFC for mail suggests JFIF is what clients should transmit :
>> 
>> https://datatracker.ietf.org/doc/html/rfc2046 :  Multipurpose Internet Mail Extensions - Part 2
>> 
>> 
>>    A media type of "image" indicates that the body contains an image.
>>    The subtype names the specific image format.  These names are not
>>    case sensitive. An initial subtype is "jpeg" for the JPEG format
>>    using JFIF encoding [JPEG].
>> 
>> And for many years, browsers either failed to display CMYK JPEGs or displayed them incorrectly.
>> 
>> But alas they do crop up and when they do, Image I/O rejects them - to the surprise and
>> consternation of some developer who knows little of JPEGs and arcane colour spaces.
>> 
>> Full support of CMYK JPEGs via the whole Image I/O API including proper handling as metadata
>> will lead us down a path that might even extend into EXIF support for JPEG and likely will
>> require the JPEG Metadata spec to be updated. 
>> 
>> So the goal here is to skirt that as much as possible by just 
>> (1) not rejecting read of CMYK JPEGs and returning a BufferedImage with a suitable ColorModel
>> (2) allowing the same BufferedImage with that ColorSpace to be written back out again as CMYK JPEGs 
>> 
>> Reading will preserve any embedded ICC Color Profile, but writing will not re-encode it since
>> that requires work on metadata. That will have to be a follow-up fix, but at the very least it
>> means that a re-written JPEG will benefit from a default treatment CMYK by any other client.
>> 
>> A test is provided which verifies that the colours are interpreted reasonably, both on initial read
>> and on write and re-read. 
>> 
>> JPEGs with embedded profiles have been tested on read, but since there are licensing issues with those,
>> the test uses JPEGs which have no embedded profile and depend on an internal implementation class.
>> 
>> That class has its hashCode() method updated because testing showed that toString() invoked hashCode()
>> in a way that caused a StackOverflowError - so nothing per se to do with this fix but a necessary update.
>> 
>> Anyone who has trustworthy CMYK JPEGs that render properly in (eg) major web browsers but not with this
>> code can submit those JPEGs so I can evaluate.
>> 
>> But all our automated tests pass as well as some manual testing and evaluation etc.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274735: javax.imageio.IIOException: Unsupported Image Type while processing a valid JPEG image

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7849


From serb at openjdk.java.net  Thu Mar 24 18:32:41 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 24 Mar 2022 18:32:41 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux
In-Reply-To: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
Message-ID: <D2_k9BLjawXWRWAOvp-6OAR2OjTmUsC-G4Y6FACQtdg=.e479e484-2c05-4b84-b7d3-377f3276beb5@github.com>

On Fri, 21 Jan 2022 17:02:38 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

> These crashes were not reproducible, so the fix is based on a hypothesis that there are two possible reasons for them:
> 1. `makeDefaultConfig()` returning `NULL`.
> 2. A race condition when the number of screens changes.
> The race scenario: `X11GraphisDevice.makeDefaultConfiguration()` is called on EDT so the call can race with `X11GraphisDevice.invalidate()` that re-sets the screen number of the device; the latter is invoked on the `AWT-XAWT` thread from `X11GraphicsEnvironment.rebuildDevices()`. So by the time `makeDefaultConfiguration()` makes a native call with the device's current screen number, the `x11Screens` array maintained by the native code could have become shorter. And the native methods like `Java_sun_awt_X11GraphicsDevice_getConfigColormap()` assume that the number passed to them is always current and valid. The AWT lock only protects against the changes during the native methods invocation and does not protect against them being called with an outdated screen number. With a larger screen number, those methods read past the end of the `x11Screens` array.
> 
> The fix for (1) is to die gracefully instead of crashing in an attempt to de-reference a `NULL` pointer, which might happen upon returning from `makeDefaultConfig()` in `getAllConfigs()`.
> 
> The fix for (2) is to eliminate the race by protecting `X11GraphisDevice.screen` with the AWT lock such that it doesn't change when the native methods working with it are active.
> 
> We've been shipping JetBrains Runtime with this fix for a few months now and there were no crash reports with those specific patterns against the versions with the fix.

I was able to reproduce the crash, so looking into the fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7182


From aivanov at openjdk.java.net  Thu Mar 24 19:14:56 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 24 Mar 2022 19:14:56 GMT
Subject: RFR: JDK-8282046: Create a regression test for JDK-8000326 [v7]
In-Reply-To: <ztlNmPdLbL8Ndda9Zu7cbLj4iY-SKiDvUpzqijeOMZE=.89d0b120-c82a-4947-b0bd-1605293e5cf2@github.com>
References: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
 <ztlNmPdLbL8Ndda9Zu7cbLj4iY-SKiDvUpzqijeOMZE=.89d0b120-c82a-4947-b0bd-1605293e5cf2@github.com>
Message-ID: <bUw5DLNdGdiZumINFMXI-mDeE3FMQoqRu6Tc8z2X2jI=.d3412cbc-7fe2-41a7-bfee-80da4b96dfff@github.com>

On Thu, 24 Mar 2022 04:58:32 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a regression test for CCC8000326
>> 
>> Issue is identified by [JDK-8000326](https://bugs.openjdk.java.net/browse/JDK-8000326), which identifies that after focus moves into JMenuBar, whose focus traversal key is disabled by default, it never moves to other focusable component.
>>  
>> By default, pressing the Tab key does not transfer focus from a JMenuBar which is added to a container together with other Swing components, because the focusTraversalKeysEnabled property of JMenuBar is set to false. To resolve this, you should call the JMenuBar.setFocusTraversalKeysEnabled(true) method.
>>  
>> The test verifies focus traversal for the above described scenario.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/awt/Focus/8000326/SetFocusTraversalKeysEnabledTest.java
>   
>   Added missing space after comma.
>   
>   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7512


From prr at openjdk.java.net  Thu Mar 24 19:22:21 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 24 Mar 2022 19:22:21 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v5]
In-Reply-To: <P5QO9YcTiVM_W9Su3IgsY0cSQAxI42svDRdIwLWYSYk=.79627a3a-e218-4a4f-b7e2-f1ef1e67cfda@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <ufxC9R6S5huL3GtQJ5G2-ev-ViVOhgXGYV3OwQtI35k=.8b695e80-9d9d-4956-babc-e6be6d69b641@github.com>
 <P5QO9YcTiVM_W9Su3IgsY0cSQAxI42svDRdIwLWYSYk=.79627a3a-e218-4a4f-b7e2-f1ef1e67cfda@github.com>
Message-ID: <hElMv9NoyfrWE5wX0TfcufnMZnNXprwYMlW9p05Tu4g=.ebdae3db-b911-43e1-94a8-c6bca773063d@github.com>

On Wed, 23 Mar 2022 18:15:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 338:
> 
>> 336:             mTracker.removeImage(image, id);
>> 337: 
>> 338:             if (interrupted && ((loadStatus & MediaTracker.LOADING )!= 0)) {
> 
> Suggestion:
> 
>             if (interrupted && ((loadStatus & MediaTracker.LOADING ) != 0)) {
> 
> There should be one space on either side of a binary operator.

It seems to me that as I mentioned there's at least a possibility that the image actually is loaded. This thread being interrupted doesn't stop the Media loading threads.

Since there's only one image for this id, LOADING and COMPLETE ought to be
mutually exclusive. In fact I'd expect only one of the flags to be set.

So I can I suppose see the logic that this API returning ABORTED instead of LOADING
makes sense, but that is because this method removes it from the tracker ..

So I guess I can live with it .. especially since I think this an unlikely scenario.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From aivanov at openjdk.java.net  Thu Mar 24 19:25:53 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 24 Mar 2022 19:25:53 GMT
Subject: RFR: 8283426: Fix 'exeption' typo [v4]
In-Reply-To: <48NxGvP43iL5AnO2fxDF1vmpTZ6RxcQp4x6oaHxkEOQ=.ccd35bda-80d8-40da-8a89-bb004adc2ed2@github.com>
References: <GQ2texGEM2KygMGYrTfvdInxH8ERh-OqfDaQE-Ie_FY=.aa211bbb-47e1-455d-8a04-90d068574078@github.com>
 <48NxGvP43iL5AnO2fxDF1vmpTZ6RxcQp4x6oaHxkEOQ=.ccd35bda-80d8-40da-8a89-bb004adc2ed2@github.com>
Message-ID: <Sp69S5ZSDBmnOZcHW58Zsp7gn3XBtaGlBsyBro6oxgo=.fdaa9244-52dd-4ebc-9dcf-62c5b73876f1@github.com>

On Wed, 23 Mar 2022 19:41:58 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Fix repeated typo `exeption`
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8283426: Fix 'exeption' typo
>   
>   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7879


From duke at openjdk.java.net  Thu Mar 24 19:49:44 2022
From: duke at openjdk.java.net (lukeu)
Date: Thu, 24 Mar 2022 19:49:44 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v7]
In-Reply-To: <WiEx5Y_45gZ6T87k39sxgvneubJBZ4mCWgoFo0Iytdc=.c4b9895f-e706-4124-91e6-2d21539d5226@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
 <WiEx5Y_45gZ6T87k39sxgvneubJBZ4mCWgoFo0Iytdc=.c4b9895f-e706-4124-91e6-2d21539d5226@github.com>
Message-ID: <nnxXSFIsfTGJp4fZX73zYNzPyn1VkiEEqc2M7C3DJgE=.81d32ae3-5679-4aa7-b9f8-61c72f2a0c99@github.com>

On Thu, 24 Mar 2022 03:07:28 GMT, Phil Race <prr at openjdk.org> wrote:

> 2. What I need here is a nice little statement of what we are INTENDING to draw. I mean what the UX person sketched out on their paper at infinite resolution.

Just my 2c: I'd say the main goal here is to enhance the fidelity of `EtchedBorder`. Magnify what we see already at 100% scaling nicely so that the "parts" don't fall apart or overlap inconsistently due to rounding. Note that:

 * `TitledBorder` defaults to using `EtchedBorder` in constructors not taking a `Border`. 
 * `EtchedBorder` defaults to deriving its 2 colors from the background of the component it is painting on, when not given explictly

        public Color getHighlightColor(Component c)   {
            return highlight != null? highlight : c.getBackground().brighter();
        }
        public Color getShadowColor(Component c)   {
            return shadow != null? shadow : c.getBackground().darker();
        }

> Let's assume highlight thickness has to match the border too ? (...) I also think there's at least some analogy with OpenJFX's snap-to-pixel idea that it is sometimes better to pick a pixel and stick with it rather than span pixels and be fuzzy.

These have been my working-assumptions, based on what I see of the built-in L&F code.

> Can I please have a pretty picture ? Or is there one here already that shows this ideal ?

How about an ugly one? ;-)  If there is agreement to use sharp, non-aliased lines of equal thickness at all scaling levels then I believe [the bottom half of this image ](https://user-images.githubusercontent.com/2722420/159801708-592e9e4d-875b-4b89-aede-306a4f24d78a.png) shows the desired result, captured @ 250% scaling (2px lines, matching the width of the CheckBox border). Specifying Red and Yellow explicitly ruins the '3D' illusion, but makes it easier to spot problems. Title 1 is `LOWERED` (default). Title 2 is `RAISED`

The trade-off is that the weight of the lines is "quantized" - not smoothly proportional w.r.t. the scaling. I think it's appropriate for the retro etched effect, to keep a sharp contrast. An alternative would be to use anti-aliasing rendering hints (such as is used almost exclusively through the popular [FlatLaf](https://github.com/JFormDesigner/FlatLaf)).

> If we figure this out properly it might be useful to apply to other cases rather than applying inconsistent hacks.

+1

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From aturbanov at openjdk.java.net  Thu Mar 24 19:54:48 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Thu, 24 Mar 2022 19:54:48 GMT
Subject: Integrated: 8283426: Fix 'exeption' typo
In-Reply-To: <GQ2texGEM2KygMGYrTfvdInxH8ERh-OqfDaQE-Ie_FY=.aa211bbb-47e1-455d-8a04-90d068574078@github.com>
References: <GQ2texGEM2KygMGYrTfvdInxH8ERh-OqfDaQE-Ie_FY=.aa211bbb-47e1-455d-8a04-90d068574078@github.com>
Message-ID: <NugOMD0BEuyANNnEWCjJtoC6529BGahSJpMPs6VIQAs=.07c87710-2981-42fd-a257-1c6da93c2535@github.com>

On Sun, 20 Mar 2022 13:30:01 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Fix repeated typo `exeption`

This pull request has now been integrated.

Changeset: dc5a65ab
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dc5a65ab378f0780f7760965f2b52cbbd7c62aad
Stats:     38 lines in 17 files changed: 0 ins; 2 del; 36 mod

8283426: Fix 'exeption' typo

Reviewed-by: xuelei, iris, dholmes, wetmore, aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/7879


From duke at openjdk.java.net  Thu Mar 24 20:31:10 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 24 Mar 2022 20:31:10 GMT
Subject: RFR: 8274082 : Wrong test case name specified in jtreg run tag for
 java/awt/print/PrinterJob/SwingUIText.java
Message-ID: <ZCvrnk1meFmsJa3Q5hk2onn7kUQL18cxrktRywdActc=.befc4c76-c87c-4261-8888-0cee83df9a80@github.com>

Following issues were fixed in this test 
1) Fixed - Parser error due to yesno in @run main/manual=yesno
2) Fixed Wrong test name specified in @run jtreg
@run main/manual=yesno PrintTextTest . It should be @run main/manual=yesno SwingUIText
3) Instruction frame does not have 'Pass' or 'Fail' button to mark the test as Pass or Fail after verifying Text on UI and print out. 
4) Fixed - Test UI ( test instruction frame, UI frame and Print Dialog) just gets disposed automatically without interacting via running the test case with jtreg. 

@shurymury

-------------

Commit messages:
 - 8274082 : Wrong test case name specified in jtreg run tag for java/awt/print/PrinterJob/SwingUIText.java

Changes: https://git.openjdk.java.net/jdk/pull/7946/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7946&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274082
  Stats: 271 lines in 1 file changed: 115 ins; 118 del; 38 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7946.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7946/head:pull/7946

PR: https://git.openjdk.java.net/jdk/pull/7946


From achung at openjdk.java.net  Thu Mar 24 21:20:40 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Thu, 24 Mar 2022 21:20:40 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v7]
In-Reply-To: <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
Message-ID: <9qj3TXJGoYRBrCYYC_Xvp1KnwkjsIDOW1WgEO5NPbV8=.de59451f-d737-4a97-8254-deb571237e85@github.com>

On Wed, 23 Mar 2022 18:24:05 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   scale stroke width at higher scalings

TitledBorder is using EtchedBorder and cutting out a portion to insert some text, so the root of the problem is actually in EtchedBorder and not TitledBorder. Here?s how the TitledBorder should look:
<img width="641" alt="Screen Shot 2022-03-24 at 2 12 00 PM" src="https://user-images.githubusercontent.com/90066231/160011029-54c6a06c-817e-4f78-88e4-ab9cbf22f53e.png">

The black line is the ?actual border?, and the white lines are shadows to create a pop-out effect. The original bug was: at n.5x scalings (n = 1,2,3,...), the two lines would overlap, so the white line would overdraw the black line. I think the root cause is that when the coordinate system is scaled up (before painting), Graphics2D object figures out where the lines should be painted based on the old coordinate system, then does some rounding to paint on the new coordinate system. If the two lines happen to round to the same integer, then we have the overdrawing problem.

This thought is a bit ad-hoc, but I think this reasoning can also explain the confusion we had about the unintuitive borderX and borderY values before: the reason the 150% scaling has a smaller borderX is because in both 100% and 150% scalings the location of the border is the same, but it takes less integer steps to reach that location in the 150% scaled image.

<img width="668" alt="Screen Shot 2022-03-24 at 2 12 43 PM" src="https://user-images.githubusercontent.com/90066231/160011116-310eb948-6625-48d8-bd57-b6ff5c34bfa5.png">

The ?jumping? of the lines was referring to the increased distance between the integer coordinates at higher scalings not matching up with the size of the stroke of the lines. The result was that when the lines are adjacent in the coordinate space (and not overdrawn), they wouldn?t actually be side-to-side when viewed. In other words, there was no exact integer coordinate the shadow could be such that it was adjacent to but not overdrawing the border.

<img width="415" alt="Screen Shot 2022-03-24 at 2 13 36 PM" src="https://user-images.githubusercontent.com/90066231/160011309-618d7fc8-994e-4699-9952-357547c62be6.png">

The solution Luke came up with was to undo the scaling first to prevent any of the coordinate rounding, then draw the border at 100% scaling, and reapply the scaling after finishing the drawing. Something like this:
<img width="657" alt="Screen Shot 2022-03-24 at 2 16 13 PM" src="https://user-images.githubusercontent.com/90066231/160011618-c526698e-78b3-4f52-93ab-a3b986f87056.png">

The current issue we just ran into was that at higher scalings using this approach, the lines would look too thin, so the stroke thickness needed to be scaled up as well, which would cause some changes in where to place the lines. I?m currently looking for where to place the lines given a stroke length (grabbed from the floor of the scale factor), but if that isn?t robust enough another approach suggested is to use area to draw.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From naoto at openjdk.java.net  Thu Mar 24 22:11:30 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 24 Mar 2022 22:11:30 GMT
Subject: RFR: 8282819: Deprecate Locale class constructors
Message-ID: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>

Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.

-------------

Commit messages:
 - 8282819: Deprecate Locale class constructors

Changes: https://git.openjdk.java.net/jdk/pull/7947/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282819
  Stats: 904 lines in 196 files changed: 74 ins; 22 del; 808 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7947.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7947/head:pull/7947

PR: https://git.openjdk.java.net/jdk/pull/7947


From duke at openjdk.java.net  Thu Mar 24 22:36:28 2022
From: duke at openjdk.java.net (Nikita Gubarkov)
Date: Thu, 24 Mar 2022 22:36:28 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v2]
In-Reply-To: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
Message-ID: <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>

> 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 incrementally with one additional commit since the last revision:

  8269806: Fix builds with old Freetype (before 2.5)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4798/files
  - new: https://git.openjdk.java.net/jdk/pull/4798/files/ccb864e5..5d99aee6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4798&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4798&range=00-01

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4798.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4798/head:pull/4798

PR: https://git.openjdk.java.net/jdk/pull/4798


From duke at openjdk.java.net  Thu Mar 24 22:42:46 2022
From: duke at openjdk.java.net (Nikita Gubarkov)
Date: Thu, 24 Mar 2022 22:42:46 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v2]
In-Reply-To: <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
Message-ID: <oVX9l37vtaCHWXlHMPBHDGsDCrI5_-cg1eAubf868A0=.66669d3a-e185-4f5a-8417-3c50fa27232e@github.com>

On Thu, 24 Mar 2022 22:36:28 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

>> 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 incrementally with one additional commit since the last revision:
> 
>   8269806: Fix builds with old Freetype (before 2.5)

Builds with old Freetype should work now, however I cannot reproduce rendering issues you mentioned, everything renders OK for me with `-Dsun.java2d.xrender=false` and `-Dsun.java2d.opengl=True` on Ubuntu 20.04 some 21 one, OL 8.5 and Fedora 35. Probably I'm missing something

-------------

PR: https://git.openjdk.java.net/jdk/pull/4798


From duke at openjdk.java.net  Thu Mar 24 22:52:51 2022
From: duke at openjdk.java.net (Nikita Gubarkov)
Date: Thu, 24 Mar 2022 22:52:51 GMT
Subject: RFR: 8269806: Emoji rendering on Linux
In-Reply-To: <3QVRsBAqs8znuPKlvR2u80Ribc4XYnj2Wx_qH3wT72o=.f7ed53f4-2126-49ef-ba5c-2bd167ce225f@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <3QVRsBAqs8znuPKlvR2u80Ribc4XYnj2Wx_qH3wT72o=.f7ed53f4-2126-49ef-ba5c-2bd167ce225f@github.com>
Message-ID: <ymZbMypDyAwQfzYYlltc7lHNxC7Zc8cSmdpPuAbb98w=.b574bad2-e11f-401e-82e4-044d391fd5fe@github.com>

On Thu, 24 Mar 2022 02:32:31 GMT, Phil Race <prr at openjdk.org> wrote:

>> 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
>
> It didn't build for me and it didn't work for me  - on X11. So is there an update or should it be returned to draft or handed off to someone else ?

@prrace do you have any ideas how can I reproduce these rendering issues?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4798


From prr at openjdk.java.net  Thu Mar 24 23:43:56 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 24 Mar 2022 23:43:56 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v2]
In-Reply-To: <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
Message-ID: <-Gs7E4avhZ_fCs_Z_nBeLtETEjk72YBKcvwwwzvMZWY=.30170b21-1b54-49be-822e-84399b3cecc1@github.com>

On Thu, 24 Mar 2022 22:36:28 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

>> 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 incrementally with one additional commit since the last revision:
> 
>   8269806: Fix builds with old Freetype (before 2.5)

It should just be -Dsun.java2d.xrender=false to use X11 instead of Xrender.
I am not able to say how that worked for you .. and not me ...
I can re-apply your patches and create a new build and test the current version.
You could trace through to see what loops are actually used for rendering the text

java -Dsun.java2d.trace=log ....

-------------

PR: https://git.openjdk.java.net/jdk/pull/4798


From duke at openjdk.java.net  Fri Mar 25 00:07:48 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Fri, 25 Mar 2022 00:07:48 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v3]
In-Reply-To: <gWFZ-lD8CQMjC69_dKMfB7F8a_4ZxUGlWwlUeAwCYlU=.546f5569-0309-45ce-8228-000e56dbbe66@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>
 <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>
 <oAZ5tpWpksvN6sfEYoblyucXf_EqcxKAIiVvkvIugjU=.a10e37ec-b8e8-4ac3-9faf-f2a8d85189af@github.com>
 <r9ujiKOC7dRsKCLNjUEt-V8mCstzXKJLFPRQ1O6kqKs=.2b96988b-85c6-45d5-9d95-2e0112b458fb@github.com>
 <AUeNFfcZNdDhRKJExOY7lT7_eG07ZQ_E124iHS_oiVI=.af2824b3-dc46-4318-92c3-27a861269339@github.com>
 <0U4ZvK_ui_ieG7pPZAdhL1AyrJYQNqT0A_HRJIE8InQ=.26f7a810-a6a0-47d0-99d9-e2ffcfebe596@github.com>
 <ML4CSxlvMzInAbk9K0LicDa--V4QlgiUzzL1u7XkJ0s=.d8c7a73c-402a-4813-8fc6-faf9fd07745a@github.com>
 <9-KCaxc5kvdWS_6nETGIRiJgbTEWTWEPxmKT5JHSphw=.0bf35082-2b55-4cfd-bc7a-636a6d7a721a@github.com>
 <fYlGXZDTHTU5qaTisZmz9LLOKG7ShMugqXOMGDmiBPY=.b43629cd-7474-48a9-9e0f-3a9729808294@github.com>
 <-k8sDdAZltd4AcDIIOeKBcKLZ4q9XuTs6sT
 5Mmg2Q9I=.025a647c-34a7-478b-912d-7bfd4a7473b4@github.com>
 <AI90_XpQ47CeM9u1p7brUJMBFddpJgfVXFfBZIYtGfw=.7489df4f-b643-4d9e-b1dd-b15ba1b6a1ad@github.com>
 <RkgzdiaxcFiGijoKtrGci5FPKKcJU7d8vDLBdt1Rftk=.88653824-bf2f-4f5b-9c69-bbb536e49ee0@github.com>
 <gWFZ-lD8CQMjC69_dKMfB7F8a_4ZxUGlWwlUeAwCYlU=.546f5569-0309-45ce-8228-000e56dbbe66@github.com>
Message-ID: <iyGfHY06FwqKUuJzNQlzG7CvXV9UZtQv0l3RhWUK2RQ=.cdb558c5-1983-4678-b299-35386cb3434a@github.com>

On Thu, 24 Mar 2022 17:09:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Following was another suggestion and if we could use the code to produce brighter focus ring color
>> [Github Link](https://github.com/openjdk/jdk/commit/2f16ca0f59892fead80b209f7819bdbdb713329a) 
>> 
>> Since the code uses a fixed value for minBrightnessDifference (which determines the returned color),  it did return brighter shade of the background, but it was not prominent/visible against the selection background color for all colors.
>> The same is true with using Color's brighter() and darker() methods to obtain the Cell Focus Ring color.
>> 
>> The idea behind the present solution is to obtain a cell focus ring color that is not just a brighter shade of selection background but to offset the hue and saturation such that it is prominent but at the same time a color close to the selection background color.
>
> I guess using "color close to selection background color" seems wrong to me...either we need to use "blue" as used in native Numbers app...or if we need to use system color, then maybe use the accent color (as defined in System Preference) as focus ring color [ there's another Apple bug [JDK-8261243](https://bugs.openjdk.java.net/browse/JDK-8261243) of JDK not following accent color for focus ring for some widgets]...

@prsadhuk Thank you for mentioning [JDK-8261243](https://bugs.openjdk.java.net/browse/JDK-8261243) issue. It is similar to the JTable cell focus ring. 

If we decide to go with the blue focus ring it would cause the same issue as described in [JDK-8261243](https://bugs.openjdk.java.net/browse/JDK-8261243)

If we choose the system color approach, below are my observations -

The selectionBackground in JTable matches the accent color. The selectionBackground is a system color that maps to [alternateSelectedControlColor](https://developer.apple.com/documentation/appkit/nscolor/1533135-alternateselectedcontrolcolor) type property. On the right we can see that the selectionBackground color of JTable (which matches the accent color). 

![image](https://user-images.githubusercontent.com/95945681/160025649-565b8e9e-6c32-4823-9971-c7573eec1451.png)

Since the selectionBackground color for JTable is same as the accent color the focus ring won't be visible unless it is **LIGHTER** than accent color as suggested in the [JDK-8261243](https://bugs.openjdk.java.net/browse/JDK-8261243). We could change the present code not to do any hue offsets which would look as follows -

![image](https://user-images.githubusercontent.com/95945681/160028845-6f78f81c-7028-4951-a3c5-aea5beb23fdb.png)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From smarks at openjdk.java.net  Fri Mar 25 00:25:47 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 25 Mar 2022 00:25:47 GMT
Subject: RFR: 8282819: Deprecate Locale class constructors
In-Reply-To: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
Message-ID: <RSdSQRML_fxp83kPgyjhwRAbLU9aQ7gmcwt485ai5MU=.e2fcbdd7-d325-4ac2-ade5-2a2bfa1658ee@github.com>

On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.

Specs looks good, with minor modifications. I'm not so sure about replacement of the constructors with string concatenation with ternary operators; see my other comment.

src/java.base/share/classes/java/util/Locale.java line 252:

> 250:  * <p>The {@code Locale} class provides a number of convenient constants
> 251:  * that you can use to obtain {@code Locale} objects for commonly used
> 252:  * locales. For example, the following obtains a {@code Locale} object

I'd replace this part (and the example below) with something like,

    For example, {@code Locale.US} is the {@code Locale} object for the United States.

src/java.base/share/classes/java/util/Locale.java line 2511:

> 2509:      * constructors, the {@code Builder} checks if a value configured by a
> 2510:      * setter satisfies the syntax requirements defined by the {@code Locale}
> 2511:      * class.  A {@code Locale} object obtained by a {@code Builder} is

...obtained from a Builder...

src/java.base/share/classes/java/util/Locale.java line 2526:

> 2524:      *
> 2525:      * <p>The following example shows how to obtain a {@code Locale} object
> 2526:      * with the {@code Builder}.

...shows how to obtain a Locale object using a Builder.

src/java.base/share/classes/java/util/Locale.java line 2660:

> 2658:          *
> 2659:          * <p>The country value in the {@code Locale} obtained by the
> 2660:          * {@code Builder} is always normalized to upper case.

...obtained from a Builder...

src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 375:

> 373:                         (locale.getLanguage().isEmpty() ? "und" : locale.getLanguage()) +
> 374:                         (locale.getCountry().isEmpty() ? "" : "-" + locale.getCountry()) +
> 375:                         (locale.getVariant().isEmpty() ? "" : "-x-lvariant-" + locale.getVariant()));

It seems like this snippet (and ones very similar to it) are repeated several times throughout the JDK code as replacements for the two- and three-arg constructors. This seems like a fair increase in complexity, and the use of "und" and "-x-lvariant-" are quite non-obvious. Would we recommend that third party code that uses the Locale constructors replace them with this snippet? Is there something better that we can provide?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7947


From naoto at openjdk.java.net  Fri Mar 25 01:59:51 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 25 Mar 2022 01:59:51 GMT
Subject: RFR: 8282819: Deprecate Locale class constructors
In-Reply-To: <RSdSQRML_fxp83kPgyjhwRAbLU9aQ7gmcwt485ai5MU=.e2fcbdd7-d325-4ac2-ade5-2a2bfa1658ee@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
 <RSdSQRML_fxp83kPgyjhwRAbLU9aQ7gmcwt485ai5MU=.e2fcbdd7-d325-4ac2-ade5-2a2bfa1658ee@github.com>
Message-ID: <OBsFbX0ds7pjRk7RgpbdV4Zn8KOlnZlxty5xXmq8tPs=.55c6d83e-91d9-4c7d-9157-cab06c6f2f0a@github.com>

On Fri, 25 Mar 2022 00:18:54 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.
>
> src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 375:
> 
>> 373:                         (locale.getLanguage().isEmpty() ? "und" : locale.getLanguage()) +
>> 374:                         (locale.getCountry().isEmpty() ? "" : "-" + locale.getCountry()) +
>> 375:                         (locale.getVariant().isEmpty() ? "" : "-x-lvariant-" + locale.getVariant()));
> 
> It seems like this snippet (and ones very similar to it) are repeated several times throughout the JDK code as replacements for the two- and three-arg constructors. This seems like a fair increase in complexity, and the use of "und" and "-x-lvariant-" are quite non-obvious. Would we recommend that third party code that uses the Locale constructors replace them with this snippet? Is there something better that we can provide?

True. One solution could be to expose `Locale.getInstance()`, which is currently a package-private static method, for this purpose. Though that means promoting `ill-formed` locale objects which defy some part of the deprecation cause.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7947


From duke at openjdk.java.net  Fri Mar 25 05:02:44 2022
From: duke at openjdk.java.net (Nikita Gubarkov)
Date: Fri, 25 Mar 2022 05:02:44 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v2]
In-Reply-To: <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
Message-ID: <FgkecPDjMIU2QlQQx4uAWKvvNqZB2Lv4j_XvxRgX5Qw=.6b09be98-a4aa-4e01-86c8-9d90833422c7@github.com>

On Thu, 24 Mar 2022 22:36:28 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

>> 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 incrementally with one additional commit since the last revision:
> 
>   8269806: Fix builds with old Freetype (before 2.5)

For `-Dsun.java2d.xrender=false`:

sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt)
sun.java2d.loops.FillParallelogram::FillParallelogram(AnyColor, SrcNoEa, AnyInt)
sun.java2d.loops.DrawGlyphListColor$General::DrawGlyphListColor(OpaqueColor, SrcNoEa, IntRgb)
sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbPre, SrcOverNoEa, IntRgb)
sun.java2d.loops.MaskBlit::MaskBlit(IntArgbPre, SrcOver, IntRgb)
sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntRgb)


For `-Dsun.java2d.opengl=True`:

OGLDrawGlyphs
sun.java2d.opengl.OGLRTTSurfaceToSurfaceBlit::Blit("OpenGL Surface (render-to-texture)", AnyAlpha, "OpenGL Surface")


And everything renders OK.
Actually it's exactly this version, I didn't rebase it over fresh master.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4798


From psadhukhan at openjdk.java.net  Fri Mar 25 05:23:49 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 25 Mar 2022 05:23:49 GMT
Subject: Integrated: 8283608: Refactor 2d,
 beans classes javadoc to use @throws instead of @exception
In-Reply-To: <cROy0eoUkBAdp5IOIcK9IcTzJtC7ZBDieR1ljOFnCmc=.9d1c8017-a0e2-4f16-85ea-42cd6f0a511c@github.com>
References: <cROy0eoUkBAdp5IOIcK9IcTzJtC7ZBDieR1ljOFnCmc=.9d1c8017-a0e2-4f16-85ea-42cd6f0a511c@github.com>
Message-ID: <ujvAynq5rJFF6Ag2XcbsuG28ZGwT71TcnkLI32-CbBo=.12b4df0c-f230-4d89-bf26-7a306285d9b5@github.com>

On Thu, 24 Mar 2022 06:43:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Prevailing JDK coding practices use "@throws" rather than "@exception".
> Need to refactor remaining 2d, beans,sound classes to use @throws

This pull request has now been integrated.

Changeset: 6b59760d
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6b59760da69ff769d30950cb4ec6ebf684d1bf50
Stats:     56 lines in 22 files changed: 0 ins; 1 del; 55 mod

8283608: Refactor 2d, beans classes javadoc to use @throws instead of @exception

Reviewed-by: iris, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/7937


From duke at openjdk.java.net  Fri Mar 25 06:51:47 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Fri, 25 Mar 2022 06:51:47 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v5]
In-Reply-To: <hElMv9NoyfrWE5wX0TfcufnMZnNXprwYMlW9p05Tu4g=.ebdae3db-b911-43e1-94a8-c6bca773063d@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <ufxC9R6S5huL3GtQJ5G2-ev-ViVOhgXGYV3OwQtI35k=.8b695e80-9d9d-4956-babc-e6be6d69b641@github.com>
 <P5QO9YcTiVM_W9Su3IgsY0cSQAxI42svDRdIwLWYSYk=.79627a3a-e218-4a4f-b7e2-f1ef1e67cfda@github.com>
 <hElMv9NoyfrWE5wX0TfcufnMZnNXprwYMlW9p05Tu4g=.ebdae3db-b911-43e1-94a8-c6bca773063d@github.com>
Message-ID: <R_1jOKb6_npdChw-ROTsoIDsO8hNSjkJGrUwKO-E9c0=.46a7974b-d23e-4873-8042-4ffe1076c91e@github.com>

On Thu, 24 Mar 2022 19:18:31 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 338:
>> 
>>> 336:             mTracker.removeImage(image, id);
>>> 337: 
>>> 338:             if (interrupted && ((loadStatus & MediaTracker.LOADING )!= 0)) {
>> 
>> Suggestion:
>> 
>>             if (interrupted && ((loadStatus & MediaTracker.LOADING ) != 0)) {
>> 
>> There should be one space on either side of a binary operator.
>
> It seems to me that as I mentioned there's at least a possibility that the image actually is loaded. This thread being interrupted doesn't stop the Media loading threads.
> 
> Since there's only one image for this id, LOADING and COMPLETE ought to be
> mutually exclusive. In fact I'd expect only one of the flags to be set.
> 
> So I can I suppose see the logic that this API returning ABORTED instead of LOADING
> makes sense, but that is because this method removes it from the tracker ..
> 
> So I guess I can live with it .. especially since I think this an unlikely scenario.
> 
> I can see both points of view on whether interrupted is needed.
> I'd be inclined to keep it since then you can PROVE that there's a change of behaviour only if interrupted.

There is a change of Behavior if its interrupted, for Not-Interrupted case the result would be ERRORED for url link and COMPLETE for local Image, but for Interrupted case the result would be LOADING for both, which we are changing to ABORTED.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From psadhukhan at openjdk.java.net  Fri Mar 25 08:00:43 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 25 Mar 2022 08:00:43 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v3]
In-Reply-To: <iyGfHY06FwqKUuJzNQlzG7CvXV9UZtQv0l3RhWUK2RQ=.cdb558c5-1983-4678-b299-35386cb3434a@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>
 <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>
 <oAZ5tpWpksvN6sfEYoblyucXf_EqcxKAIiVvkvIugjU=.a10e37ec-b8e8-4ac3-9faf-f2a8d85189af@github.com>
 <r9ujiKOC7dRsKCLNjUEt-V8mCstzXKJLFPRQ1O6kqKs=.2b96988b-85c6-45d5-9d95-2e0112b458fb@github.com>
 <AUeNFfcZNdDhRKJExOY7lT7_eG07ZQ_E124iHS_oiVI=.af2824b3-dc46-4318-92c3-27a861269339@github.com>
 <0U4ZvK_ui_ieG7pPZAdhL1AyrJYQNqT0A_HRJIE8InQ=.26f7a810-a6a0-47d0-99d9-e2ffcfebe596@github.com>
 <ML4CSxlvMzInAbk9K0LicDa--V4QlgiUzzL1u7XkJ0s=.d8c7a73c-402a-4813-8fc6-faf9fd07745a@github.com>
 <9-KCaxc5kvdWS_6nETGIRiJgbTEWTWEPxmKT5JHSphw=.0bf35082-2b55-4cfd-bc7a-636a6d7a721a@github.com>
 <fYlGXZDTHTU5qaTisZmz9LLOKG7ShMugqXOMGDmiBPY=.b43629cd-7474-48a9-9e0f-3a9729808294@github.com>
 <-k8sDdAZltd4AcDIIOeKBcKLZ4q9XuTs6sT
 5Mmg2Q9I=.025a647c-34a7-478b-912d-7bfd4a7473b4@github.com>
 <AI90_XpQ47CeM9u1p7brUJMBFddpJgfVXFfBZIYtGfw=.7489df4f-b643-4d9e-b1dd-b15ba1b6a1ad@github.com>
 <RkgzdiaxcFiGijoKtrGci5FPKKcJU7d8vDLBdt1Rftk=.88653824-bf2f-4f5b-9c69-bbb536e49ee0@github.com>
 <gWFZ-lD8CQMjC69_dKMfB7F8a_4ZxUGlWwlUeAwCYlU=.546f5569-0309-45ce-8228-000e56dbbe66@github.com>
 <iyGfHY06FwqKUuJzNQlzG7CvXV9UZtQv0l3RhWUK2RQ=.cdb558c5-1983-4678-b299-35386cb3434a@github.com>
Message-ID: <K80e0S6-JthHc7DhsDV3BQePXNNEesqd_y1uF9ecLWI=.03e52bae-752b-407c-be5d-ce98c47a83c4@github.com>

On Fri, 25 Mar 2022 00:02:21 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> I guess using "color close to selection background color" seems wrong to me...either we need to use "blue" as used in native Numbers app...or if we need to use system color, then maybe use the accent color (as defined in System Preference) as focus ring color [ there's another Apple bug [JDK-8261243](https://bugs.openjdk.java.net/browse/JDK-8261243) of JDK not following accent color for focus ring for some widgets]...
>
> @prsadhuk Thank you for mentioning [JDK-8261243](https://bugs.openjdk.java.net/browse/JDK-8261243) issue. It is similar to the JTable cell focus ring. 
> 
> If we decide to go with the blue focus ring it would cause the same issue as described in [JDK-8261243](https://bugs.openjdk.java.net/browse/JDK-8261243)
> 
> If we choose the system color approach, below are my observations -
> 
> The selectionBackground in JTable matches the accent color. The selectionBackground is a system color that maps to [alternateSelectedControlColor](https://developer.apple.com/documentation/appkit/nscolor/1533135-alternateselectedcontrolcolor) type property. On the right we can see that the selectionBackground color of JTable (which matches the accent color). 
> 
> ![image](https://user-images.githubusercontent.com/95945681/160025649-565b8e9e-6c32-4823-9971-c7573eec1451.png)
> 
> Since the selectionBackground color for JTable is same as the accent color the focus ring won't be visible unless it is **LIGHTER** than accent color as suggested in the [JDK-8261243](https://bugs.openjdk.java.net/browse/JDK-8261243). We could change the present code not to do any hue offsets which would look as follows -
> 
> ![image](https://user-images.githubusercontent.com/95945681/160028845-6f78f81c-7028-4951-a3c5-aea5beb23fdb.png)

I guess "selectionBackground" matches the "highlight" color which seems to follow accent color, by default but we can make highlight color different from accent color, but in this case focus color should match accent color, not highlight color...please confirm if this is what is happening..
Also, alternateSelectedControlColor is deprecated so you should consider replacing with [selectedContentBackgroundColor](https://developer.apple.com/documentation/appkit/nscolor/2998830-selectedcontentbackgroundcolor)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From duke at openjdk.java.net  Fri Mar 25 10:05:57 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Fri, 25 Mar 2022 10:05:57 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v5]
In-Reply-To: <P5QO9YcTiVM_W9Su3IgsY0cSQAxI42svDRdIwLWYSYk=.79627a3a-e218-4a4f-b7e2-f1ef1e67cfda@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <ufxC9R6S5huL3GtQJ5G2-ev-ViVOhgXGYV3OwQtI35k=.8b695e80-9d9d-4956-babc-e6be6d69b641@github.com>
 <P5QO9YcTiVM_W9Su3IgsY0cSQAxI42svDRdIwLWYSYk=.79627a3a-e218-4a4f-b7e2-f1ef1e67cfda@github.com>
Message-ID: <dja_OcGj6FJfILZz8qfB3RUp__A-c-Ev3CMEK_ikuMQ=.dca2cd4a-86ac-4d43-bdb3-0d574f36488e@github.com>

On Wed, 23 Mar 2022 18:18:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> It looks good now.
> 
> Is it possible to add a regression test? We have one now, don't we? It just needs to be done as a jtreg automated test which verifies the status is any of the _done_ statuses, not `LOADING`.
> 
> A more complicated test could also verify the printed message is gone.

Sure @aivanov-jdk , will add regression test......

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From avu at openjdk.java.net  Fri Mar 25 11:27:36 2022
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Fri, 25 Mar 2022 11:27:36 GMT
Subject: RFR: 8273355: Flickering on tooltip appearance IntelliJ IDEA
 2021.2.1 [v3]
In-Reply-To: <_Q4d9YdOccAdjO6LsIlbIOt55Bn7PGAz3-NmVBF2vLU=.01b029e3-f88f-4b6b-b12b-3509f9dcd486@github.com>
References: <_Q4d9YdOccAdjO6LsIlbIOt55Bn7PGAz3-NmVBF2vLU=.01b029e3-f88f-4b6b-b12b-3509f9dcd486@github.com>
Message-ID: <y7a-NyIztP3YHPLSjFTSk2fVEZ7jFLwFrj40hJgmZ8M=.a93db6c4-ddd6-472f-bd5d-6e2170610ad1@github.com>

> Used setOpaque() method to set correct background of platform window
> Extracted setting background to the particular method in PlatformWindow. Provided appropriate implementation in CPlatformWindow.

Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:

  8273355: Flickering on tooltip appearance IntelliJ IDEA 2021.2.1
  
  Copyright update

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7931/files
  - new: https://git.openjdk.java.net/jdk/pull/7931/files/8faccd68..9ecf1b30

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7931&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7931&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7931.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7931/head:pull/7931

PR: https://git.openjdk.java.net/jdk/pull/7931


From alexsch at openjdk.java.net  Fri Mar 25 13:21:42 2022
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Fri, 25 Mar 2022 13:21:42 GMT
Subject: RFR: 8181571: printing to CUPS fails on mac sandbox app [v4]
In-Reply-To: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com>
References: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com>
Message-ID: <Y-RMTKiJZGqlKoBHVRiGiprCjsLwqL5EWrhqHe2lSd8=.415879c7-f8fc-4525-86bd-bacc08177283@github.com>

> The issue is reproduced on macOS Big Sur 11.0.1 with jdk 16.0.1+9.
> 
> Create a native macOS app from the Hello.java file, sign and run it in sandbox:
> 
> import javax.print.*;
> import javax.swing.*;
> 
> public class Hello {
> 
>     public static void main(String[] args) throws Exception {
>         SwingUtilities.invokeAndWait(() -> {
>             boolean isSandboxed = System.getenv("APP_SANDBOX_CONTAINER_ID") != null;
>             PrintService defaultPrinter = PrintServiceLookup.lookupDefaultPrintService();
>             PrintService[] services = PrintServiceLookup.lookupPrintServices(null, null);
> 
>             StringBuilder builder = new StringBuilder();
>             builder.append("is sandboxed: ").append(isSandboxed).append("\n");
>             builder.append("default printer: ").append(defaultPrinter).append("\n");
>             int size = services.length;
>             for (int i = 0; i < size; i++) {
>                 builder.append("printer[").append(i).append("]=").append(services[i]).append("\n");
>             }
>             JOptionPane.showMessageDialog(null, builder.toString());
>         });
>     }
> }
> 
> The signed app in sandbox shows null default printer and PrintServiceLookup.lookupPrintServices(null, null) returns "Unix Printer: lp".
> ![PrintSandboxedApp](https://bugs.openjdk.java.net/secure/attachment/95629/PrintSandboxedApp.png)
> 
> The problem has been discussed on  2d-dev mail list:
>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-June/008375.html
>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-July/008418.html
> 
> According to the discussion:
> 
>> I've submitted a DTS incident to Apple and a friend there has followed-up.
>> Their unofficial position is that java should be connecting to the cups interface returned
>> by the cupsServer() function and not changing the interface string to "localhost".
>> Security changes in 10.12.4 reject the TCP connection which they say confuses
>> network-client access with print access.  They don't seem interested in loosening that change.
> 
> 
> The proposed solution is to use the domain socket pathname in httpConnect(...) cups function and cupsGetDests(...) to get list of printers from cups  when the app is signed and is run in sandbox on MacOs.

Alexander Scherbatiy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8181571
 - Return null if printers are not found in sandboxed app on MacOS
 - Clean utf_str and nameArray references
 - Split long line in CUPSPrinter.isCupsRunning() method
 - 8181571: printing to CUPS fails on mac sandbox app

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4861/files
  - new: https://git.openjdk.java.net/jdk/pull/4861/files/067d0025..9a83785b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4861&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4861&range=02-03

  Stats: 1544660 lines in 8566 files changed: 887512 ins; 607384 del; 49764 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4861.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4861/head:pull/4861

PR: https://git.openjdk.java.net/jdk/pull/4861


From prr at openjdk.java.net  Fri Mar 25 13:40:49 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 25 Mar 2022 13:40:49 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v7]
In-Reply-To: <Z3ucScsP7VGuLsY-WnSBP9mXOkycXG8K__K-nKYZDAo=.c65322bf-b117-4123-8a6e-edef4b6a593f@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
 <WiEx5Y_45gZ6T87k39sxgvneubJBZ4mCWgoFo0Iytdc=.c4b9895f-e706-4124-91e6-2d21539d5226@github.com>
 <Z3ucScsP7VGuLsY-WnSBP9mXOkycXG8K__K-nKYZDAo=.c65322bf-b117-4123-8a6e-edef4b6a593f@github.com>
Message-ID: <vhb01IRqACRb0LkSKkhZw2JXqup5fM7RTXQoSPHtOsE=.1bfe66ac-aa68-4b6a-8b84-532e2e3fe538@github.com>

On Thu, 24 Mar 2022 16:20:19 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> 1. @aivanov-jdk wrote (scroll up a lot)
>    When uiScale=1.25, you can see there's background color between the shadow and highlight on the second panel.
> 
> I have no idea where I should be seeing that. I see nothing like that. Perhaps I am looking in the wrong place

This is a bit of a tangent but I really could not see that on my display.
There's something weird about mac/macOS when displaying solely to an external monitor.
The background became so washed-out that it was white so there was no "shadow".
Saw this on two different monitors. i can't blame the connection or the color profile.
When dragged from built-in retina to external monitor it was still very clear.
As soon as I closed the lid of the macbook so the external display was the only active one,
the screen refreshed and the colours became washed out ..

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From alexsch at openjdk.java.net  Fri Mar 25 14:02:30 2022
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Fri, 25 Mar 2022 14:02:30 GMT
Subject: RFR: 8181571: printing to CUPS fails on mac sandbox app [v5]
In-Reply-To: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com>
References: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com>
Message-ID: <QkUNa7zB59HvUO9cJFQD_M1OY8gGxaOLoVIa2qkqjlQ=.6182fb9e-9a6e-4127-8e00-6a9f4c2334b8@github.com>

> The issue is reproduced on macOS Big Sur 11.0.1 with jdk 16.0.1+9.
> 
> Create a native macOS app from the Hello.java file, sign and run it in sandbox:
> 
> import javax.print.*;
> import javax.swing.*;
> 
> public class Hello {
> 
>     public static void main(String[] args) throws Exception {
>         SwingUtilities.invokeAndWait(() -> {
>             boolean isSandboxed = System.getenv("APP_SANDBOX_CONTAINER_ID") != null;
>             PrintService defaultPrinter = PrintServiceLookup.lookupDefaultPrintService();
>             PrintService[] services = PrintServiceLookup.lookupPrintServices(null, null);
> 
>             StringBuilder builder = new StringBuilder();
>             builder.append("is sandboxed: ").append(isSandboxed).append("\n");
>             builder.append("default printer: ").append(defaultPrinter).append("\n");
>             int size = services.length;
>             for (int i = 0; i < size; i++) {
>                 builder.append("printer[").append(i).append("]=").append(services[i]).append("\n");
>             }
>             JOptionPane.showMessageDialog(null, builder.toString());
>         });
>     }
> }
> 
> The signed app in sandbox shows null default printer and PrintServiceLookup.lookupPrintServices(null, null) returns "Unix Printer: lp".
> ![PrintSandboxedApp](https://bugs.openjdk.java.net/secure/attachment/95629/PrintSandboxedApp.png)
> 
> The problem has been discussed on  2d-dev mail list:
>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-June/008375.html
>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-July/008418.html
> 
> According to the discussion:
> 
>> I've submitted a DTS incident to Apple and a friend there has followed-up.
>> Their unofficial position is that java should be connecting to the cups interface returned
>> by the cupsServer() function and not changing the interface string to "localhost".
>> Security changes in 10.12.4 reject the TCP connection which they say confuses
>> network-client access with print access.  They don't seem interested in loosening that change.
> 
> 
> The proposed solution is to use the domain socket pathname in httpConnect(...) cups function and cupsGetDests(...) to get list of printers from cups  when the app is signed and is run in sandbox on MacOs.

Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:

  Add @SuppressWarnings(removal) for CUPSPrinter.isSandboxedApp() method

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4861/files
  - new: https://git.openjdk.java.net/jdk/pull/4861/files/9a83785b..f6697fa2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4861&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4861&range=03-04

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4861.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4861/head:pull/4861

PR: https://git.openjdk.java.net/jdk/pull/4861


From alexsch at openjdk.java.net  Fri Mar 25 14:40:48 2022
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Fri, 25 Mar 2022 14:40:48 GMT
Subject: RFR: 8181571: printing to CUPS fails on mac sandbox app [v5]
In-Reply-To: <Noj7YW0DvwQOOW-6mjfJzKzVCAro-5AccwCLjQ9A4ZY=.5475f0c7-82cb-4015-9a97-b8f444c1657e@github.com>
References: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com>
 <GiCn7RQLCIXsjuBtqWxnW32umwyG5GkiIZnvLM1lXCo=.9c7f43cf-d55f-4538-92e0-0ad5e11e8efb@github.com>
 <Noj7YW0DvwQOOW-6mjfJzKzVCAro-5AccwCLjQ9A4ZY=.5475f0c7-82cb-4015-9a97-b8f444c1657e@github.com>
Message-ID: <NnHUFCOmhdQ1Zd1znOlRRUf_n8BOcSGVFP9wvG3h7TY=.b3eaca3f-af9b-464b-91ae-a12107a746e6@github.com>

On Tue, 24 Aug 2021 16:06:40 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> src/java.desktop/unix/classes/sun/print/CUPSPrinter.java line 489:
>> 
>>> 487:         return domainSocketPathname;
>>> 488:     }
>>> 489: 
>> 
>> You will need to suppress deprecation warnings here.
>
> Should I add `@SuppressWarnings("deprecation")` to the getDomainSocketPathname() method?

@SuppressWarnings("removal") is added for the isSandboxedApp() method.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4861


From prr at openjdk.java.net  Fri Mar 25 15:11:45 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 25 Mar 2022 15:11:45 GMT
Subject: Integrated: 8274735: javax.imageio.IIOException: Unsupported Image
 Type  while processing a valid JPEG image
In-Reply-To: <gBv_Xtu5bmqpludbJWXwKpgvPCVz4BGYXbjErejjb1A=.cbe35817-d2cb-44bc-9f7b-d2597622623e@github.com>
References: <gBv_Xtu5bmqpludbJWXwKpgvPCVz4BGYXbjErejjb1A=.cbe35817-d2cb-44bc-9f7b-d2597622623e@github.com>
Message-ID: <QrzqXoXhuLzGVPmFuEjjeDVwqrL_o89R1mCeHxz0YCs=.3bf5c924-c7c2-4a22-9f8f-3fd24d5b94e5@github.com>

On Thu, 17 Mar 2022 03:23:49 GMT, Phil Race <prr at openjdk.org> wrote:

> The JDK's built-in Image I/O JPEG plugin decodes JPEGs which are YCbCr and RGb and Grayscale but rejects CMYK and YCCK JPEGs.
> These would correspond to JFIF encapsulated JPEGs.
> 
> This was a reasonable decision to limit support to what was actually likely to be seen - CMYK JPEGs probably should just be created for direct to print devices and never seen on the internet as an interchange format.
> 
> Indeed this (below) RFC for mail suggests JFIF is what clients should transmit :
> 
> https://datatracker.ietf.org/doc/html/rfc2046 :  Multipurpose Internet Mail Extensions - Part 2
> 
> 
>    A media type of "image" indicates that the body contains an image.
>    The subtype names the specific image format.  These names are not
>    case sensitive. An initial subtype is "jpeg" for the JPEG format
>    using JFIF encoding [JPEG].
> 
> And for many years, browsers either failed to display CMYK JPEGs or displayed them incorrectly.
> 
> But alas they do crop up and when they do, Image I/O rejects them - to the surprise and
> consternation of some developer who knows little of JPEGs and arcane colour spaces.
> 
> Full support of CMYK JPEGs via the whole Image I/O API including proper handling as metadata
> will lead us down a path that might even extend into EXIF support for JPEG and likely will
> require the JPEG Metadata spec to be updated. 
> 
> So the goal here is to skirt that as much as possible by just 
> (1) not rejecting read of CMYK JPEGs and returning a BufferedImage with a suitable ColorModel
> (2) allowing the same BufferedImage with that ColorSpace to be written back out again as CMYK JPEGs 
> 
> Reading will preserve any embedded ICC Color Profile, but writing will not re-encode it since
> that requires work on metadata. That will have to be a follow-up fix, but at the very least it
> means that a re-written JPEG will benefit from a default treatment CMYK by any other client.
> 
> A test is provided which verifies that the colours are interpreted reasonably, both on initial read
> and on write and re-read. 
> 
> JPEGs with embedded profiles have been tested on read, but since there are licensing issues with those,
> the test uses JPEGs which have no embedded profile and depend on an internal implementation class.
> 
> That class has its hashCode() method updated because testing showed that toString() invoked hashCode()
> in a way that caused a StackOverflowError - so nothing per se to do with this fix but a necessary update.
> 
> Anyone who has trustworthy CMYK JPEGs that render properly in (eg) major web browsers but not with this
> code can submit those JPEGs so I can evaluate.
> 
> But all our automated tests pass as well as some manual testing and evaluation etc.

This pull request has now been integrated.

Changeset: f8a16491
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f8a164915fff5e9e8f3c9c1996b51e7e4fe5d68d
Stats:     284 lines in 13 files changed: 283 ins; 0 del; 1 mod

8274735: javax.imageio.IIOException: Unsupported Image Type  while processing a valid JPEG image

Reviewed-by: kizune, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/7849


From rriggs at openjdk.java.net  Fri Mar 25 15:40:46 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 25 Mar 2022 15:40:46 GMT
Subject: RFR: 8282819: Deprecate Locale class constructors
In-Reply-To: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
Message-ID: <tyOR0vEQfJzdx8ZwYHY45srRuXftQXscF48fPmAXqRs=.fd7f148b-cef1-41d9-8f7c-59c8bfcda8e5@github.com>

On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.

src/java.base/share/classes/java/util/Locale.java line 245:

> 243:  * <h4>Factory Method</h4>
> 244:  *
> 245:  * <p>The method {@link #forLanguageTag} obtains a {@code Locale}

The factory name `forLanguageTag` is a bit off-putting, it doesn't seem like the best name for the factory.
Yes, it already exists and does what's required but you might get better uptake with a more natural name.

Some alternatives:
 - `Locale.of("en_US")` - short and conventional
 - `Locale.ofLanguage("en_US")` - 'of' prefix is used in other factories
 - `Locale.forLanguage("en_US")` - natural but less conventional

-------------

PR: https://git.openjdk.java.net/jdk/pull/7947


From rriggs at openjdk.java.net  Fri Mar 25 16:21:52 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 25 Mar 2022 16:21:52 GMT
Subject: RFR: 8282819: Deprecate Locale class constructors
In-Reply-To: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
Message-ID: <rvpu-eVSZUdEqfnckoWr-J9r6wzDOxNjzSbyW5aFOjE=.8654bef5-9b34-4618-92f7-b9a1bf0c13fa@github.com>

On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.

Given the large number of cleanups, I would have suggested to keep them separate from the change to re-focus the API on factories.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7947


From naoto at openjdk.java.net  Fri Mar 25 16:21:52 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 25 Mar 2022 16:21:52 GMT
Subject: RFR: 8282819: Deprecate Locale class constructors
In-Reply-To: <tyOR0vEQfJzdx8ZwYHY45srRuXftQXscF48fPmAXqRs=.fd7f148b-cef1-41d9-8f7c-59c8bfcda8e5@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
 <tyOR0vEQfJzdx8ZwYHY45srRuXftQXscF48fPmAXqRs=.fd7f148b-cef1-41d9-8f7c-59c8bfcda8e5@github.com>
Message-ID: <WWaUZ9i-O6PCG638nKOBsZabzM2ssK5gzG_SDVattvE=.d63a8f82-17f8-4ed2-bed6-ba717c04b545@github.com>

On Fri, 25 Mar 2022 15:37:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.
>
> src/java.base/share/classes/java/util/Locale.java line 245:
> 
>> 243:  * <h4>Factory Method</h4>
>> 244:  *
>> 245:  * <p>The method {@link #forLanguageTag} obtains a {@code Locale}
> 
> The factory name `forLanguageTag` is a bit off-putting, it doesn't seem like the best name for the factory.
> Yes, it already exists and does what's required but you might get better uptake with a more natural name.
> 
> Some alternatives:
>  - `Locale.of("en_US")` - short and conventional
>  - `Locale.ofLanguage("en_US")` - 'of' prefix is used in other factories
>  - `Locale.forLanguage("en_US")` - natural but less conventional

I was thinking of a *new* factory method, along the line with Stuart's suggestion, something like this:

Locale.of(String... elements)

where elements can either `(lang)`, `(lang, ctry)`, `(lang, ctry, vrnt)`, or `(lang, ctry, vrnt, scpt)`. Either element can be an empty string, but cannot be null. These elements are *not* language tags, but conventional arguments to constructors, so it is compatible (and works as a stop-gap) to the old constructors. This way third parties will not have to deal with the boilerplate code mentioned above on migration.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7947


From prr at openjdk.java.net  Fri Mar 25 17:34:51 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 25 Mar 2022 17:34:51 GMT
Subject: RFR: 8181571: printing to CUPS fails on mac sandbox app [v5]
In-Reply-To: <Noj7YW0DvwQOOW-6mjfJzKzVCAro-5AccwCLjQ9A4ZY=.5475f0c7-82cb-4015-9a97-b8f444c1657e@github.com>
References: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com>
 <GiCn7RQLCIXsjuBtqWxnW32umwyG5GkiIZnvLM1lXCo=.9c7f43cf-d55f-4538-92e0-0ad5e11e8efb@github.com>
 <Noj7YW0DvwQOOW-6mjfJzKzVCAro-5AccwCLjQ9A4ZY=.5475f0c7-82cb-4015-9a97-b8f444c1657e@github.com>
Message-ID: <MHgDIa0zqSzB6bPEb7DnRIOWzOGYmOzzrt44Z9CAZCE=.542d910a-51a6-4220-a266-07b2623b9807@github.com>

On Tue, 24 Aug 2021 15:57:40 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> src/java.desktop/unix/native/common/awt/CUPSfuncs.c line 244:
>> 
>>> 242:         DPRINTF("CUPSfuncs::bad alloc new array\n", "")
>>> 243:         (*env)->ExceptionClear(env);
>>> 244:         JNU_ThrowOutOfMemoryError(env, "OutOfMemoryError");
>> 
>> I find this weird. What is the ExceptionClear for ? The only possible exception here is for
>> an OOME which might be thrown by NewObjectArray. So you clear that and then re-create it ?
>> And who do will catch this ? What's the point ? Maybe just clear and return null.
>
> The array creation error handling is implemented in the similar way as it is done in the getMedia() function.
> The ExceptionClear() has been added to the getMedia() by `8031001: [Parfait] warnings from b121 for jdk/src/solaris/native/sun/awt: JNI-related warnings`
> I would prefer to have unified error handling in these methods. If ExceptionClear is not suitable in this place it would be better to recheck JDK-8031001 and update all places accordingly in a separate fix.

I can't agree with the apparent reasoning that "well that thing over there is wrong, so it's ok for me to add something here that's wrong too".

And the getMedia(..) case is different.  It doesn't re-create the same exception.
It wants to create an OOME which is not actually thrown by GetStringUTFChars() since it needs to throw some exception and with an appropriate string reason.
And the clear there is just prudence since it is creating a new one and can't be 100% sure there isn't one pending.

In your case the JNI spec documents OOME 
https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#newobjectarray

So in your case it is pointless. Please just remote the Clear()

-------------

PR: https://git.openjdk.java.net/jdk/pull/4861


From duke at openjdk.java.net  Fri Mar 25 19:20:43 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Fri, 25 Mar 2022 19:20:43 GMT
Subject: RFR: 8024624: [TEST_BUG] [macosx] CTRL+RIGHT(LEFT) doesn't move
 selection on next cell in JTable on Aqua L&F [v2]
In-Reply-To: <LdWWDPfwqpCC-_EBaYQLX4rFIyV9FLAG5ugIJb0ruI4=.bc296640-5df9-41a1-b857-14f334c1be8e@github.com>
References: <LdWWDPfwqpCC-_EBaYQLX4rFIyV9FLAG5ugIJb0ruI4=.bc296640-5df9-41a1-b857-14f334c1be8e@github.com>
Message-ID: <euSIvXa4E3AN7zAwwJtcrRKViubhVvKosTMgpEJ72FY=.546f4164-50b8-4890-ab57-d59feeaf723c@github.com>

> Aqua L&F tables lacked support for `CTRL+ARROW`, `CTRL+PG_UP/DOWN`, and `CTRL+SHIFT+PG_UP/DOWN` key bindings. This allows for navigation and selection of table cells without the need of a mouse and without deselecting the current selected cell group. 
> 
> Those key bindings are added to Aqua's key bindings for tables. The `SPACE` key binding was also added because it allows for the selection of cells after navigating using the `CTRL+ARROW` bindings, and some of the new bindings are only useful with the `SPACE` binding added. The closed test that this bug originates from tests for both left-to-right and right-to-left functionality, so the new directional bindings are also added to the right-to-left key bindings table where needed.
> 
> This requires mission control shortcuts in macOS to be disabled as `CTRL+ARROW` keys are normally used for virtual desktop navigation.

DamonGuy has updated the pull request incrementally with one additional commit since the last revision:

  Converted closed repo test to open repo. Removed changes to Aqua key bindings.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7792/files
  - new: https://git.openjdk.java.net/jdk/pull/7792/files/e5ce124e..b2492f21

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7792&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7792&range=00-01

  Stats: 329 lines in 2 files changed: 295 ins; 27 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7792.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7792/head:pull/7792

PR: https://git.openjdk.java.net/jdk/pull/7792


From duke at openjdk.java.net  Fri Mar 25 19:20:43 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Fri, 25 Mar 2022 19:20:43 GMT
Subject: RFR: 8024624: [TEST_BUG] [macosx] CTRL+RIGHT(LEFT) doesn't move
 selection on next cell in JTable on Aqua L&F
In-Reply-To: <LdWWDPfwqpCC-_EBaYQLX4rFIyV9FLAG5ugIJb0ruI4=.bc296640-5df9-41a1-b857-14f334c1be8e@github.com>
References: <LdWWDPfwqpCC-_EBaYQLX4rFIyV9FLAG5ugIJb0ruI4=.bc296640-5df9-41a1-b857-14f334c1be8e@github.com>
Message-ID: <-s410xcKZIZL5JeUmsdZ7B0PBxn9ZZMYrzG7Mu11jYk=.dc7f3f65-a39c-42c0-b44e-7ae048bc657b@github.com>

On Fri, 11 Mar 2022 23:13:15 GMT, DamonGuy <duke at openjdk.java.net> wrote:

> Aqua L&F tables lacked support for `CTRL+ARROW`, `CTRL+PG_UP/DOWN`, and `CTRL+SHIFT+PG_UP/DOWN` key bindings. This allows for navigation and selection of table cells without the need of a mouse and without deselecting the current selected cell group. 
> 
> Those key bindings are added to Aqua's key bindings for tables. The `SPACE` key binding was also added because it allows for the selection of cells after navigating using the `CTRL+ARROW` bindings, and some of the new bindings are only useful with the `SPACE` binding added. The closed test that this bug originates from tests for both left-to-right and right-to-left functionality, so the new directional bindings are also added to the right-to-left key bindings table where needed.
> 
> This requires mission control shortcuts in macOS to be disabled as `CTRL+ARROW` keys are normally used for virtual desktop navigation.

I have removed the additional key bindings. Instead, I excluded macOS from the test. I also converted the closed test to be appropriate for open repo use. I removed the reliance on deprecated and closed-exclusive libraries, like JRobot and SwingTestHelper. I also re-organized the test methods since SwingTestHelper's method naming convention does not need to be adhered to.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7792


From prr at openjdk.java.net  Fri Mar 25 20:43:49 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 25 Mar 2022 20:43:49 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v2]
In-Reply-To: <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
Message-ID: <z8brzGtp5pifluV2nbjveWccL3sQkR3ZJvq0mnYd5Zw=.6e9a4a00-375a-487e-84e0-9a1c15188b87@github.com>

On Thu, 24 Mar 2022 22:36:28 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

>> 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 incrementally with one additional commit since the last revision:
> 
>   8269806: Fix builds with old Freetype (before 2.5)

![font2dtest](https://user-images.githubusercontent.com/30127347/160197568-d9f79b93-1444-4700-adfd-cabd022addc1.png)

This  screenshot is Font2DTest with your current patch and -Dsun.java2d.xrender=false on Ubuntu 20.04
I don't understand how you aren't seeing the garbage emojis, since your patch has no X11 support.
Where the garbage glyphs are, they appear as correct colour emojis with xrender.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4798


From prr at openjdk.java.net  Fri Mar 25 20:52:50 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 25 Mar 2022 20:52:50 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v2]
In-Reply-To: <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
Message-ID: <I-BU98fVkH55Ndu98D8dUJ_KejgFQoiOnWBWzR5NxUg=.49cd9730-b072-4c04-8a80-ae2e50721b89@github.com>

On Thu, 24 Mar 2022 22:36:28 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

>> 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 incrementally with one additional commit since the last revision:
> 
>   8269806: Fix builds with old Freetype (before 2.5)

Ah - I bet you haven't tested AA=OFF ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4798


From duke at openjdk.java.net  Fri Mar 25 21:13:12 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Fri, 25 Mar 2022 21:13:12 GMT
Subject: RFR: 8283712 : Create a manual test framework class
Message-ID: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>

We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
1) Frame which contains test instruction .
2) Pass & Fail button so that user can mark the test pass or fail
3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
4) Disposing of all the frames.

@aivanov-jdk

-------------

Commit messages:
 - 8283712 : Create a manual test framework class

Changes: https://git.openjdk.java.net/jdk/pull/7966/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7966&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283712
  Stats: 119 lines in 1 file changed: 119 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7966.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7966/head:pull/7966

PR: https://git.openjdk.java.net/jdk/pull/7966


From prr at openjdk.java.net  Fri Mar 25 21:31:44 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 25 Mar 2022 21:31:44 GMT
Subject: RFR: 8024624: [TEST_BUG] [macosx] CTRL+RIGHT(LEFT) doesn't move
 selection on next cell in JTable on Aqua L&F [v2]
In-Reply-To: <euSIvXa4E3AN7zAwwJtcrRKViubhVvKosTMgpEJ72FY=.546f4164-50b8-4890-ab57-d59feeaf723c@github.com>
References: <LdWWDPfwqpCC-_EBaYQLX4rFIyV9FLAG5ugIJb0ruI4=.bc296640-5df9-41a1-b857-14f334c1be8e@github.com>
 <euSIvXa4E3AN7zAwwJtcrRKViubhVvKosTMgpEJ72FY=.546f4164-50b8-4890-ab57-d59feeaf723c@github.com>
Message-ID: <-Kg8rJyDVy01WIxsR1tzzlcilcMD7X76QCLAsTUWYbg=.91ed3b11-02bd-4823-b452-eba42df45bc0@github.com>

On Fri, 25 Mar 2022 19:20:43 GMT, DamonGuy <duke at openjdk.java.net> wrote:

>> Aqua L&F tables lacked support for `CTRL+ARROW`, `CTRL+PG_UP/DOWN`, and `CTRL+SHIFT+PG_UP/DOWN` key bindings. This allows for navigation and selection of table cells without the need of a mouse and without deselecting the current selected cell group. 
>> 
>> Those key bindings are added to Aqua's key bindings for tables. The `SPACE` key binding was also added because it allows for the selection of cells after navigating using the `CTRL+ARROW` bindings, and some of the new bindings are only useful with the `SPACE` binding added. The closed test that this bug originates from tests for both left-to-right and right-to-left functionality, so the new directional bindings are also added to the right-to-left key bindings table where needed.
>> 
>> This requires mission control shortcuts in macOS to be disabled as `CTRL+ARROW` keys are normally used for virtual desktop navigation.
>
> DamonGuy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Converted closed repo test to open repo. Removed changes to Aqua key bindings.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7792


From prr at openjdk.java.net  Fri Mar 25 21:39:45 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 25 Mar 2022 21:39:45 GMT
Subject: RFR: 8283712 : Create a manual test framework class
In-Reply-To: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
Message-ID: <lmT81M4HHrZBlNZYWuw8bdXfCZgf7NF3q2CcgY2uYq8=.bf4b2cb4-4346-4d13-a9b0-4612eee7c9c4@github.com>

On Fri, 25 Mar 2022 21:06:12 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
> 1) Frame which contains test instruction .
> 2) Pass & Fail button so that user can mark the test pass or fail
> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
> 4) Disposing of all the frames.
> 
> @aivanov-jdk

This really needs to be delivered in the same PR as something using it so it can actually be tested.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 42:

> 40:     private JTextArea instructionsText;
> 41:     private int maxStringLength = 50;
> 42:     private int timeoutMinutes = 3;

why can't this be configured ?

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 68:

> 66:         setLocationRelativeTo(null);
> 67:         setVisible(true);
> 68:     }

Hmm. Why can't this be wrapped in invokeAndWait to save the test having to do it ?

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 76:

> 74:             System.out.println(f.getTitle() + " is getting disposed");
> 75:             f.dispose();
> 76:         }

Same here for invokeAndWait ?
You just need to document that these shouldn't be called on the EDT ..
in fact you need to document the threading regardless.

Mind you I am not sure this code should be destroying all frames.
It is a  non-obvious side effect ..

-------------

Changes requested by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7966


From aivanov at openjdk.java.net  Fri Mar 25 22:01:40 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 25 Mar 2022 22:01:40 GMT
Subject: RFR: JDK-8280193: summary javadoc for
 java.awt.GraphicsEnvironment#preferProportionalFonts broken
In-Reply-To: <mhGN4NF0_HP30ZMo4dmDmLnFMmciaf1fmAAEeWfIX5k=.f69d52f6-79ed-42bd-836b-3f31b2961be4@github.com>
References: <mhGN4NF0_HP30ZMo4dmDmLnFMmciaf1fmAAEeWfIX5k=.f69d52f6-79ed-42bd-836b-3f31b2961be4@github.com>
Message-ID: <-ljp_FSqytjJVwXlbDPXQKWVvPC7A7TPPFqouHiWunc=.1567bec4-7501-4806-b839-787726bf355e@github.com>

On Tue, 18 Jan 2022 14:05:55 GMT, James Nord <duke at openjdk.java.net> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8280193
> 
> 
> Javadoc broke the first sentence at the full stop space (newline) so it rendered with `Indicates a preference for proportional over non-proportional (e.g.`
> 
> This is an incorrect sentence, and so this change fixes it by replacing the `e.g.` to `for example`
> 
> https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/GraphicsEnvironment.html
> 
> <img width="706" alt="image" src="https://user-images.githubusercontent.com/494726/149952315-651a4231-d641-4b73-8fea-93c83e1aa257.png">

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7127


From aivanov at openjdk.java.net  Fri Mar 25 22:01:40 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 25 Mar 2022 22:01:40 GMT
Subject: RFR: JDK-8280193: summary javadoc for
 java.awt.GraphicsEnvironment#preferProportionalFonts broken
In-Reply-To: <wQcQpY73rSgupJwgSVydYdui4ARumU0SqRrBWq6cv9g=.0e34e15c-36f2-4f9d-89cb-93a79c78699a@github.com>
References: <mhGN4NF0_HP30ZMo4dmDmLnFMmciaf1fmAAEeWfIX5k=.f69d52f6-79ed-42bd-836b-3f31b2961be4@github.com>
 <wQcQpY73rSgupJwgSVydYdui4ARumU0SqRrBWq6cv9g=.0e34e15c-36f2-4f9d-89cb-93a79c78699a@github.com>
Message-ID: <dn82B_E0cghk_tLMYU69EqT3YXvo-uELj7MdHVGjtJI=.04df292b-57f3-4a29-a374-6c0350c2c7bb@github.com>

On Thu, 24 Mar 2022 02:46:03 GMT, Phil Race <prr at openjdk.org> wrote:

> I am fine with this but there's probably a javadoc way to escape this

Yes, there is: use an HTML entity to avoid the sequence of the period followed by a space. See the example in the [First Sentence](https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html#firstsentence) section in ?How to Write Doc Comments for the Javadoc Tool.?

The following should work: `e.g.&#x20;` or `e.g.&nbsp;`. The former uses a regular space, the latter uses a non-breaking space.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7127


From aivanov at openjdk.java.net  Fri Mar 25 22:06:41 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 25 Mar 2022 22:06:41 GMT
Subject: RFR: JDK-8280193: summary javadoc for
 java.awt.GraphicsEnvironment#preferProportionalFonts broken
In-Reply-To: <dn82B_E0cghk_tLMYU69EqT3YXvo-uELj7MdHVGjtJI=.04df292b-57f3-4a29-a374-6c0350c2c7bb@github.com>
References: <mhGN4NF0_HP30ZMo4dmDmLnFMmciaf1fmAAEeWfIX5k=.f69d52f6-79ed-42bd-836b-3f31b2961be4@github.com>
 <wQcQpY73rSgupJwgSVydYdui4ARumU0SqRrBWq6cv9g=.0e34e15c-36f2-4f9d-89cb-93a79c78699a@github.com>
 <dn82B_E0cghk_tLMYU69EqT3YXvo-uELj7MdHVGjtJI=.04df292b-57f3-4a29-a374-6c0350c2c7bb@github.com>
Message-ID: <8UlWtOL1FzZmIIitTSJFnSc-UMeMuWmXSiEETY_d4Es=.7371a54a-748d-4f58-b5a7-3e1fd5f589ab@github.com>

On Fri, 25 Mar 2022 21:55:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > I am fine with this but there's probably a javadoc way to escape this
> 
> Yes, there is: use an HTML entity to avoid the sequence of the period followed by a space. See the example in the [First Sentence](https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html#firstsentence) section in ?How to Write Doc Comments for the Javadoc Tool.?
> 
> The following should work: `e.g.&#x20;` or `e.g.&nbsp;`. The former uses a regular space, the latter uses a non-breaking space.

The new text that uses ?for example? follows another recommendation: **Avoid Latin** point under [A Style Guide](https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html#styleguide).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7127


From duke at openjdk.java.net  Fri Mar 25 22:29:47 2022
From: duke at openjdk.java.net (Nikita Gubarkov)
Date: Fri, 25 Mar 2022 22:29:47 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v2]
In-Reply-To: <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
Message-ID: <b4JCn0nXIp0zgqlkb9vjDA7nilE37wW21knV4ovRm4k=.6898bde5-2cde-48e6-8c2d-35dff0c0ebf6@github.com>

On Thu, 24 Mar 2022 22:36:28 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

>> 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 incrementally with one additional commit since the last revision:
> 
>   8269806: Fix builds with old Freetype (before 2.5)

Nope, AA=OFF does work for me as well with XR, X11 and OGL. Maybe the problem is in selecting the appropriate fallback font, in my test I select the specific emoji font which does work, but in your Font2DTest it's more complicated, like it must require a fallback emoji font. I'll investigate this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4798


From prr at openjdk.java.net  Fri Mar 25 22:43:39 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 25 Mar 2022 22:43:39 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v2]
In-Reply-To: <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
Message-ID: <sF4H2GN2qU7Tedlp0tLbeaAKbJ2-VyKKkvrPVJxbQM0=.159a5ee7-0d0b-4a36-9f34-c6b2c39e2889@github.com>

On Thu, 24 Mar 2022 22:36:28 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

>> 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 incrementally with one additional commit since the last revision:
> 
>   8269806: Fix builds with old Freetype (before 2.5)

The actual font they are coming from is Noto Color Emoji. The same problem occurs if I select the font directly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4798


From duke at openjdk.java.net  Sat Mar 26 00:36:39 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Sat, 26 Mar 2022 00:36:39 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v3]
In-Reply-To: <K80e0S6-JthHc7DhsDV3BQePXNNEesqd_y1uF9ecLWI=.03e52bae-752b-407c-be5d-ce98c47a83c4@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>
 <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>
 <oAZ5tpWpksvN6sfEYoblyucXf_EqcxKAIiVvkvIugjU=.a10e37ec-b8e8-4ac3-9faf-f2a8d85189af@github.com>
 <r9ujiKOC7dRsKCLNjUEt-V8mCstzXKJLFPRQ1O6kqKs=.2b96988b-85c6-45d5-9d95-2e0112b458fb@github.com>
 <AUeNFfcZNdDhRKJExOY7lT7_eG07ZQ_E124iHS_oiVI=.af2824b3-dc46-4318-92c3-27a861269339@github.com>
 <0U4ZvK_ui_ieG7pPZAdhL1AyrJYQNqT0A_HRJIE8InQ=.26f7a810-a6a0-47d0-99d9-e2ffcfebe596@github.com>
 <ML4CSxlvMzInAbk9K0LicDa--V4QlgiUzzL1u7XkJ0s=.d8c7a73c-402a-4813-8fc6-faf9fd07745a@github.com>
 <9-KCaxc5kvdWS_6nETGIRiJgbTEWTWEPxmKT5JHSphw=.0bf35082-2b55-4cfd-bc7a-636a6d7a721a@github.com>
 <fYlGXZDTHTU5qaTisZmz9LLOKG7ShMugqXOMGDmiBPY=.b43629cd-7474-48a9-9e0f-3a9729808294@github.com>
 <-k8sDdAZltd4AcDIIOeKBcKLZ4q9XuTs6sT
 5Mmg2Q9I=.025a647c-34a7-478b-912d-7bfd4a7473b4@github.com>
 <AI90_XpQ47CeM9u1p7brUJMBFddpJgfVXFfBZIYtGfw=.7489df4f-b643-4d9e-b1dd-b15ba1b6a1ad@github.com>
 <RkgzdiaxcFiGijoKtrGci5FPKKcJU7d8vDLBdt1Rftk=.88653824-bf2f-4f5b-9c69-bbb536e49ee0@github.com>
 <gWFZ-lD8CQMjC69_dKMfB7F8a_4ZxUGlWwlUeAwCYlU=.546f5569-0309-45ce-8228-000e56dbbe66@github.com>
 <iyGfHY06FwqKUuJzNQlzG7CvXV9UZtQv0l3RhWUK2RQ=.cdb558c5-1983-4678-b299-35386cb3434a@github.com>
 <K80e0S6-JthHc7DhsDV3BQePXNNEesqd_y1uF9ecLWI=.03e52bae-752b-407c-be5d-ce98c47a83c4@github.com>
Message-ID: <HRR-kzpsYhfv5i3XdtQokkw4cjUl9fwxTPUlfeHSvC0=.c48b8a56-0dfc-4207-bf3b-9302b5728301@github.com>

On Fri, 25 Mar 2022 07:57:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> @prsadhuk Thank you for mentioning [JDK-8261243](https://bugs.openjdk.java.net/browse/JDK-8261243) issue. It is similar to the JTable cell focus ring. 
>> 
>> If we decide to go with the blue focus ring it would cause the same issue as described in [JDK-8261243](https://bugs.openjdk.java.net/browse/JDK-8261243)
>> 
>> If we choose the system color approach, below are my observations -
>> 
>> The selectionBackground in JTable matches the accent color. The selectionBackground is a system color that maps to [alternateSelectedControlColor](https://developer.apple.com/documentation/appkit/nscolor/1533135-alternateselectedcontrolcolor) type property. On the right we can see that the selectionBackground color of JTable (which matches the accent color). 
>> 
>> ![image](https://user-images.githubusercontent.com/95945681/160025649-565b8e9e-6c32-4823-9971-c7573eec1451.png)
>> 
>> Since the selectionBackground color for JTable is same as the accent color the focus ring won't be visible unless it is **LIGHTER** than accent color as suggested in the [JDK-8261243](https://bugs.openjdk.java.net/browse/JDK-8261243). We could change the present code not to do any hue offsets which would look as follows -
>> 
>> ![image](https://user-images.githubusercontent.com/95945681/160028845-6f78f81c-7028-4951-a3c5-aea5beb23fdb.png)
>
> I guess "selectionBackground" matches the "highlight" color which seems to follow accent color, by default but we can make highlight color different from accent color, but in this case focus color should match accent color, not highlight color...please confirm if this is what is happening..
> Also, alternateSelectedControlColor is deprecated so you should consider replacing with [selectedContentBackgroundColor](https://developer.apple.com/documentation/appkit/nscolor/2998830-selectedcontentbackgroundcolor)

@prsadhuk Cell Focus ring color does not change with highlight color settings. Tested for following cases -

<img width="1060" alt="image" src="https://user-images.githubusercontent.com/95945681/160217226-7d4236c7-1d3e-4062-8fad-974a13374624.png">

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From duke at openjdk.java.net  Sat Mar 26 00:55:40 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Sat, 26 Mar 2022 00:55:40 GMT
Subject: RFR: 8283712 : Create a manual test framework class
In-Reply-To: <lmT81M4HHrZBlNZYWuw8bdXfCZgf7NF3q2CcgY2uYq8=.bf4b2cb4-4346-4d13-a9b0-4612eee7c9c4@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <lmT81M4HHrZBlNZYWuw8bdXfCZgf7NF3q2CcgY2uYq8=.bf4b2cb4-4346-4d13-a9b0-4612eee7c9c4@github.com>
Message-ID: <9W97cvQQLz2wKzq7qu6wwqQ1xOpvkYEwdkMjCF-ItuA=.6bb93e8b-62c9-4965-a0fd-7b21958e6d38@github.com>

On Fri, 25 Mar 2022 21:33:46 GMT, Phil Race <prr at openjdk.org> wrote:

>> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
>> 1) Frame which contains test instruction .
>> 2) Pass & Fail button so that user can mark the test pass or fail
>> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
>> 4) Disposing of all the frames.
>> 
>> @aivanov-jdk
>
> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 42:
> 
>> 40:     private JTextArea instructionsText;
>> 41:     private int maxStringLength = 50;
>> 42:     private int timeoutMinutes = 3;
> 
> why can't this be configured ?

Yes, this can be configured.

> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 68:
> 
>> 66:         setLocationRelativeTo(null);
>> 67:         setVisible(true);
>> 68:     }
> 
> Hmm. Why can't this be wrapped in invokeAndWait to save the test having to do it ?

Sure will do.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7966


From duke at openjdk.java.net  Sat Mar 26 02:13:24 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Sat, 26 Mar 2022 02:13:24 GMT
Subject: RFR: 8283712 : Create a manual test framework class [v2]
In-Reply-To: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
Message-ID: <dtjZE2m9bJrH5Zqk5i5aYf0wBDa905IyM4qpa0MlqQQ=.1c5fcd75-7237-49c9-8484-a10454a99ed5@github.com>

> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
> 1) Frame which contains test instruction .
> 2) Pass & Fail button so that user can mark the test pass or fail
> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
> 4) Disposing of all the frames.
> 
> @aivanov-jdk

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  Fixed the review comments and fixed the test using PassFailJFrame.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7966/files
  - new: https://git.openjdk.java.net/jdk/pull/7966/files/8f7706bc..746ceab6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7966&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7966&range=00-01

  Stats: 140 lines in 2 files changed: 56 ins; 29 del; 55 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7966.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7966/head:pull/7966

PR: https://git.openjdk.java.net/jdk/pull/7966


From duke at openjdk.java.net  Sat Mar 26 02:13:26 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Sat, 26 Mar 2022 02:13:26 GMT
Subject: RFR: 8283712 : Create a manual test framework class [v2]
In-Reply-To: <lmT81M4HHrZBlNZYWuw8bdXfCZgf7NF3q2CcgY2uYq8=.bf4b2cb4-4346-4d13-a9b0-4612eee7c9c4@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <lmT81M4HHrZBlNZYWuw8bdXfCZgf7NF3q2CcgY2uYq8=.bf4b2cb4-4346-4d13-a9b0-4612eee7c9c4@github.com>
Message-ID: <KUdbxFtD0Gi2XNW_4Iy8hmlCrpMI8v9VK8xe2kdHrGQ=.031a1da0-f29a-411c-b04f-3d6cfec3a82b@github.com>

On Fri, 25 Mar 2022 21:35:49 GMT, Phil Race <prr at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed the review comments and fixed the test using PassFailJFrame.java
>
> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 76:
> 
>> 74:             System.out.println(f.getTitle() + " is getting disposed");
>> 75:             f.dispose();
>> 76:         }
> 
> Same here for invokeAndWait ?
> You just need to document that these shouldn't be called on the EDT ..
> in fact you need to document the threading regardless.
> 
> Mind you I am not sure this code should be destroying all frames.
> It is a  non-obvious side effect ..

Added the documentation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7966


From duke at openjdk.java.net  Sat Mar 26 02:20:29 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Sat, 26 Mar 2022 02:20:29 GMT
Subject: RFR: 8283712 : Create a manual test framework class [v3]
In-Reply-To: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
Message-ID: <hdBE7KpygvUrrx52-NQ_y7Rl_aHM3NUKQOgjAq6O8LY=.69551728-b6c5-4b96-bbb0-7f963dd51310@github.com>

> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
> 1) Frame which contains test instruction .
> 2) Pass & Fail button so that user can mark the test pass or fail
> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
> 4) Disposing of all the frames.
> 
> @aivanov-jdk

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  Fixed the white space issue

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7966/files
  - new: https://git.openjdk.java.net/jdk/pull/7966/files/746ceab6..552bfad6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7966&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7966&range=01-02

  Stats: 9 lines in 1 file changed: 2 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7966.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7966/head:pull/7966

PR: https://git.openjdk.java.net/jdk/pull/7966


From duke at openjdk.java.net  Sat Mar 26 02:20:30 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Sat, 26 Mar 2022 02:20:30 GMT
Subject: RFR: 8283712 : Create a manual test framework class [v2]
In-Reply-To: <dtjZE2m9bJrH5Zqk5i5aYf0wBDa905IyM4qpa0MlqQQ=.1c5fcd75-7237-49c9-8484-a10454a99ed5@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <dtjZE2m9bJrH5Zqk5i5aYf0wBDa905IyM4qpa0MlqQQ=.1c5fcd75-7237-49c9-8484-a10454a99ed5@github.com>
Message-ID: <5xLdpB1RoC3sFDuYl8xZjOdE3WDPZGq6WrOQ-69mWT0=.cc8ccf79-39ee-4127-8a7f-1e6753be907a@github.com>

On Sat, 26 Mar 2022 02:13:24 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
>> 1) Frame which contains test instruction .
>> 2) Pass & Fail button so that user can mark the test pass or fail
>> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
>> 4) Disposing of all the frames.
>> 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the review comments and fixed the test using PassFailJFrame.java

Fixed PrintLatinCJKTest.java test and used PassFailJFrame for showing test instruction.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7966


From prr at openjdk.java.net  Sat Mar 26 02:42:47 2022
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 26 Mar 2022 02:42:47 GMT
Subject: RFR: 8283712 : Create a manual test framework class [v3]
In-Reply-To: <hdBE7KpygvUrrx52-NQ_y7Rl_aHM3NUKQOgjAq6O8LY=.69551728-b6c5-4b96-bbb0-7f963dd51310@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <hdBE7KpygvUrrx52-NQ_y7Rl_aHM3NUKQOgjAq6O8LY=.69551728-b6c5-4b96-bbb0-7f963dd51310@github.com>
Message-ID: <JTCIRMhuj6TvAit2LOcGGvIM7tzowJNlbWHg0ZkcZJY=.65f4a88c-a1d7-403e-bba0-65430c703316@github.com>

On Sat, 26 Mar 2022 02:20:29 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
>> 1) Frame which contains test instruction .
>> 2) Pass & Fail button so that user can mark the test pass or fail
>> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
>> 4) Disposing of all the frames.
>> 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the white space issue

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 103:

> 101:      * If user does not select pass or fail button then the test waits for
> 102:      * the specified timeoutMinutes period and the test gets timeout.
> 103:      * This method should not be invoke with in EDT.

This method should not be invoked on the EDT ?

Actually I wonder if we can do better  for this AND the other method.

CHECK if its the EDT and if it is invoke dispose() directly, if it isn't  then use invokeAndWait.

Also remember that SwingUtilities.invokeAndWait is just a wrapper for EventQueue.invokeAndWait

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 127:

> 125:                 System.out.println(f.getTitle() + " is getting disposed");
> 126:                 f.dispose();
> 127:             }

I am still not sure about this. I mean it doesn't include Window or Dialog .. 
I think that until you can prove otherwise it should destroy only the framework, not start being part of the test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7966


From duke at openjdk.java.net  Sat Mar 26 07:16:44 2022
From: duke at openjdk.java.net (Hiroshi Miura)
Date: Sat, 26 Mar 2022 07:16:44 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v2]
In-Reply-To: <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
Message-ID: <ZgfE0B7E80FnXjAJW0fBeDGWTXB3UhEAci0rWAFcH48=.c8376576-8386-4a21-947d-6a6e179e88f4@github.com>

On Thu, 24 Mar 2022 22:36:28 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

>> 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 incrementally with one additional commit since the last revision:
> 
>   8269806: Fix builds with old Freetype (before 2.5)

I've tested it with Font2DTest on Mint-Linux 20.3.

## test result of font2dtest with noto color emoji font

This works well when select Noto Color Emoji 
![emoticon_jdk_8269806_noto_color_emoji](https://user-images.githubusercontent.com/123720/160228910-654f5503-5046-46b8-b74d-83d28e4faebf.png)

### lsof -p <pid> |grep fonts

<details>


java    3147863 miurahr    8r   REG              259,2 20332392 24644835 /usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc
java    3147863 miurahr    9r   REG              259,2    88304 24644978 /usr/share/fonts/truetype/fonts-yrsa-rasa/Yrsa-Medium.ttf
java    3147863 miurahr   12r   REG              259,2    20876 28052242 /usr/share/fonts/truetype/lyx/wasy10.ttf
java    3147863 miurahr   13r   REG              259,2    86172 24644979 /usr/share/fonts/truetype/fonts-yrsa-rasa/Yrsa-Regular.ttf
java    3147863 miurahr   14r   REG              259,2    81228 24644977 /usr/share/fonts/truetype/fonts-yrsa-rasa/Yrsa-Light.ttf
java    3147863 miurahr   15r   REG              259,2    86568 24644980 /usr/share/fonts/truetype/fonts-yrsa-rasa/Yrsa-SemiBold.ttf
java    3147863 miurahr   16r   REG              259,2  4033420 24644943 /usr/share/fonts/truetype/droid/DroidSansFallbackFull.ttf
java    3147863 miurahr   17r   REG              259,2   584136 24649716 /usr/share/fonts/truetype/noto/NotoSansSymbols2-Regular.ttf
java    3147863 miurahr   18r   REG              259,2   197796 24645054 /usr/share/fonts/truetype/lohit-kannada/Lohit-Kannada.ttf
java    3147863 miurahr   19r   REG              259,2   757076 24642783 /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
java    3147863 miurahr   20r   REG              259,2    98396 24644867 /usr/share/fonts/opentype/urw-base35/URWBookman-Light.otf
java    3147863 miurahr   21r   REG              259,2   680264 24644068 /usr/share/fonts/truetype/dejavu/DejaVuSansCondensed.ttf
java    3147863 miurahr   22r   REG              259,2 10847156 24643878 /usr/share/fonts/truetype/noto/NotoColorEmoji.ttf
java    3147863 miurahr   24r   REG              259,2    82968 24644869 /usr/share/fonts/opentype/urw-base35/URWGothic-Book.otf
java    3147863 miurahr   25r   REG              259,2   156500 24644966 /usr/share/fonts/truetype/fonts-orya-extra/utkal.ttf
java    3147863 miurahr   26r   REG              259,2   209904 24644969 /usr/share/fonts/truetype/fonts-telu-extra/vemana2000.ttf
java    3147863 miurahr   27r   REG              259,2   139640 22207124 /usr/share/fonts/truetype/msttcorefonts/Verdana.ttf
java    3147863 miurahr   28r   REG              259,2   118752 22207125 /usr/share/fonts/truetype/msttcorefonts/Webdings.ttf
java    3147863 miurahr   29r   REG              259,2   114052 24644873 /usr/share/fonts/opentype/urw-base35/Z003-MediumItalic.otf
java    3147863 miurahr   30r   REG              259,2   418804 21919611 /usr/share/fonts/truetype/noto/NotoEmoji-Regular.ttf


</details>

## test result of font2dtest with dialog font

When selecting dialog font
![emoticon_jdk_8269806_dialog](https://user-images.githubusercontent.com/123720/160228925-26b40480-283f-4171-a87e-8fb5a5574c2e.png)

### lsof -p <pid> |grep fonts

<details>


java    3147863 miurahr    8r   REG              259,2 20332392 24644835 /usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc
java    3147863 miurahr    9r   REG              259,2    88304 24644978 /usr/share/fonts/truetype/fonts-yrsa-rasa/Yrsa-Medium.ttf
java    3147863 miurahr   12r   REG              259,2    20876 28052242 /usr/share/fonts/truetype/lyx/wasy10.ttf
java    3147863 miurahr   13r   REG              259,2    86172 24644979 /usr/share/fonts/truetype/fonts-yrsa-rasa/Yrsa-Regular.ttf
java    3147863 miurahr   14r   REG              259,2    81228 24644977 /usr/share/fonts/truetype/fonts-yrsa-rasa/Yrsa-Light.ttf
java    3147863 miurahr   15r   REG              259,2    86568 24644980 /usr/share/fonts/truetype/fonts-yrsa-rasa/Yrsa-SemiBold.ttf
java    3147863 miurahr   16r   REG              259,2  4033420 24644943 /usr/share/fonts/truetype/droid/DroidSansFallbackFull.ttf
java    3147863 miurahr   17r   REG              259,2   584136 24649716 /usr/share/fonts/truetype/noto/NotoSansSymbols2-Regular.ttf
java    3147863 miurahr   18r   REG              259,2   197796 24645054 /usr/share/fonts/truetype/lohit-kannada/Lohit-Kannada.ttf
java    3147863 miurahr   19r   REG              259,2   757076 24642783 /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
java    3147863 miurahr   20r   REG              259,2    98396 24644867 /usr/share/fonts/opentype/urw-base35/URWBookman-Light.otf
java    3147863 miurahr   22r   REG              259,2  1792900 24642883 /usr/share/fonts/truetype/unifont/unifont_upper.ttf
java    3147863 miurahr   23r   REG              259,2   167232 24645077 /usr/share/fonts/truetype/malayalam/Uroob-Regular.ttf
java    3147863 miurahr   24r   REG              259,2    82968 24644869 /usr/share/fonts/opentype/urw-base35/URWGothic-Book.otf
java    3147863 miurahr   25r   REG              259,2   156500 24644966 /usr/share/fonts/truetype/fonts-orya-extra/utkal.ttf
java    3147863 miurahr   26r   REG              259,2   209904 24644969 /usr/share/fonts/truetype/fonts-telu-extra/vemana2000.ttf
java    3147863 miurahr   27r   REG              259,2   139640 22207124 /usr/share/fonts/truetype/msttcorefonts/Verdana.ttf
java    3147863 miurahr   28r   REG              259,2   118752 22207125 /usr/share/fonts/truetype/msttcorefonts/Webdings.ttf
java    3147863 miurahr   29r   REG              259,2   114052 24644873 /usr/share/fonts/opentype/urw-base35/Z003-MediumItalic.otf
java    3147863 miurahr   30r   REG              259,2   418804 21919611 /usr/share/fonts/truetype/noto/NotoEmoji-Regular.ttf


</details>

## diff of lsof


$ diff lsof_font2dtest_dialog.log lsof_font2dtest_noto_color_emoji.log 
12,13c12,13
< java    3147863 miurahr   22r   REG              259,2  1792900 24642883 /usr/share/fonts/truetype/unifont/unifont_upper.ttf
< java    3147863 miurahr   23r   REG              259,2   167232 24645077 /usr/share/fonts/truetype/malayalam/Uroob-Regular.ttf
---
> java    3147863 miurahr   21r   REG              259,2   680264 24644068 /usr/share/fonts/truetype/dejavu/DejaVuSansCondensed.ttf
> java    3147863 miurahr   22r   REG              259,2 10847156 24643878 /usr/share/fonts/truetype/noto/NotoColorEmoji.ttf
21d20
< 


The diff tell us  when Font2DTest show emoticon with dialog, fallback font is **unifont**.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4798


From duke at openjdk.java.net  Sat Mar 26 07:20:44 2022
From: duke at openjdk.java.net (Hiroshi Miura)
Date: Sat, 26 Mar 2022 07:20:44 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v2]
In-Reply-To: <sF4H2GN2qU7Tedlp0tLbeaAKbJ2-VyKKkvrPVJxbQM0=.159a5ee7-0d0b-4a36-9f34-c6b2c39e2889@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
 <sF4H2GN2qU7Tedlp0tLbeaAKbJ2-VyKKkvrPVJxbQM0=.159a5ee7-0d0b-4a36-9f34-c6b2c39e2889@github.com>
Message-ID: <z3yqNLGOe4MNIZO-dJyonaVA0tYg46t2IrdWpu-D6Gk=.04db3fc8-af00-4c97-a51f-8bc386f0c974@github.com>

On Fri, 25 Mar 2022 22:40:01 GMT, Phil Race <prr at openjdk.org> wrote:

>> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8269806: Fix builds with old Freetype (before 2.5)
>
> The actual font they are coming from is Noto Color Emoji. The same problem occurs if I select the font directly.

@prrace could you check your Font2DTest process whether it really open a Noto Emoji Font file? I think you looks **fallback font** other than unifont in both case.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4798


From duke at openjdk.java.net  Sat Mar 26 07:27:03 2022
From: duke at openjdk.java.net (Hiroshi Miura)
Date: Sat, 26 Mar 2022 07:27:03 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v2]
In-Reply-To: <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
Message-ID: <VhgvrW60AYkTsHSjB-mFepDzPqRSkI_FcpzzYD_jEcg=.dcff6d5f-0728-47ff-b9b4-321cb1616818@github.com>

On Thu, 24 Mar 2022 22:36:28 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

>> 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 incrementally with one additional commit since the last revision:
> 
>   8269806: Fix builds with old Freetype (before 2.5)

This is a case to look with **Noto Emoji** font.
![emoticon_jdk_8269806_noto_emoji](https://user-images.githubusercontent.com/123720/160229313-554ac914-c3d0-4ac4-b10d-31ce84e2b227.png)

This tell us when we see emoticon with **dialog** logical font, most glyph come from **unifont** and some from other than **unifont**, which is **Noto Emoji** in my case.

An alternation is happened in same unicode ranges, `U1F624`, `U1F62C`, and from `U1F645` to `U1F64F`

-------------

PR: https://git.openjdk.java.net/jdk/pull/4798


From mvs at openjdk.java.net  Sat Mar 26 07:27:30 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Sat, 26 Mar 2022 07:27:30 GMT
Subject: RFR: 8283623: Create an automated regression test for JDK-4525475
Message-ID: <ovauTi1CSYZ068j2-fLVDWsy-0LMRrehH2ng_KHgtVs=.7c5b9f95-3235-42dd-81f5-678b3b91e46f@github.com>

Write a regression test for [JDK-4525475](https://bugs.openjdk.java.net/browse/JDK-4525475)

Issue:
JFileChooser allows modification to the file-system by way of the "New Folder"
button, and the ability to rename file/folder names. There is no method on
JFileChooser which indicates that this type of modification should not be
allowed within the given JFileChooser.

Testing:
1. Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.
2. Tested in original failed Java version and the fixed version;
Java 1.4.0 -> Test Failed.
$ j2sdk1.4.0/bin/java Bug4525475
LookAndFeel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
Name = Go Up, readOnly = true
Name = New Folder, readOnly = true
Its a Read Only JFileChooser and has a New Folder Button. So Test Failed.
Name = Go Up, readOnly = false
Name = New Folder, readOnly = false
Failed

Java 1.5.0 -> Test Passed.
$ jdk1.5.0/bin/java Bug4525475
LookAndFeel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
Name = Go Up, readOnly = true
Name = Go Up, readOnly = false
Name = New Folder, readOnly = false
Passed

-------------

Commit messages:
 - 8283623: Create an automated regression test for JDK-4525475

Changes: https://git.openjdk.java.net/jdk/pull/7969/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7969&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283623
  Stats: 138 lines in 1 file changed: 138 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7969.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7969/head:pull/7969

PR: https://git.openjdk.java.net/jdk/pull/7969


From mvs at openjdk.java.net  Sat Mar 26 08:33:40 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Sat, 26 Mar 2022 08:33:40 GMT
Subject: RFR: 8283621: Write a regression test for CCC4400728
In-Reply-To: <rnjTXKruqaPPPREorlsQv7c8rcSNE9BUqiAdoVPML0w=.b9c187ff-9050-4cae-9c5a-435b451213dd@github.com>
References: <rnjTXKruqaPPPREorlsQv7c8rcSNE9BUqiAdoVPML0w=.b9c187ff-9050-4cae-9c5a-435b451213dd@github.com>
Message-ID: <STyCCx8Ipy2erwccYnisVidCxdBiKJjhPgIzPrX_jZw=.9d36d8ea-c643-4c88-bfe1-6376d0c9c775@github.com>

On Thu, 24 Mar 2022 15:22:35 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Write a regression test for [JDK-4400728](https://bugs.openjdk.java.net/browse/JDK-4400728)
> 
> Issue:
> JFileChooser constructors by default set current directory to the "Desktop" value on Windows,
> but should use 'My Documents' property instead, also user.home for unix platforms.
> 
> javadoc says:
> "public JFileChooser()
> Constructs a JFileChooser pointing to the user's default directory. This default depends on the operating system. It is typically the 'My Documents' folder on Windows, and the user's home directory on Unix.
> "
> See this https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JFileChooser.html#%3Cinit%3E()
> 
> Testing:
> 1. Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.
> 2. Tested in original failed Java version and the fixed version;
> Java 1.4.0 -> Test Failed.
> $ j2sdk1.4.0/bin/java JFileChooserDefaultDirectoryTest
> java.lang.NullPointerException
>         at java.io.File.<init>(File.java:180)
>         at sun.awt.shell.Win32ShellFolder.listFiles(Win32ShellFolder.java:517)
>         at sun.awt.shell.Win32ShellFolderManager.get(Win32ShellFolderManager.java:152)
>         at sun.awt.shell.ShellFolder.get(ShellFolder.java:208)
>         at javax.swing.plaf.metal.MetalFileChooserUI.installComponents(MetalFileChooserUI.java:310)
>         at javax.swing.plaf.basic.BasicFileChooserUI.installUI(BasicFileChooserUI.java:130)
>         at javax.swing.plaf.metal.MetalFileChooserUI.installUI(MetalFileChooserUI.java:152)
>         at javax.swing.JComponent.setUI(JComponent.java:445)
>         at javax.swing.JFileChooser.updateUI(JFileChooser.java:1701)
>         at javax.swing.JFileChooser.setup(JFileChooser.java:345)
>         at javax.swing.JFileChooser.<init>(JFileChooser.java:320)
>         at javax.swing.JFileChooser.<init>(JFileChooser.java:273)
>         at JFileChooserDefaultDirectoryTest.main(JFileChooserDefaultDirectoryTest.java:15)
> Exception in thread "main"
> 
> Java 1.5.0 -> Test Passed.
> $ jdk1.5.0/bin/java JFileChooserDefaultDirectoryTest
> UserHome dir = C:\Users\jpgansible
> Test Passed
> 
> Java 1.8.0 -> Test Passed.
> $ jdk1.8.0_331/bin/java JFileChooserDefaultDirectoryTest
> UserHome dir = C:\Users\jpgansible
> Test Passed

@aivanov-jdk Can you please review this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7942


From mvs at openjdk.java.net  Sat Mar 26 08:33:41 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Sat, 26 Mar 2022 08:33:41 GMT
Subject: RFR: 8283623: Create an automated regression test for JDK-4525475
In-Reply-To: <ovauTi1CSYZ068j2-fLVDWsy-0LMRrehH2ng_KHgtVs=.7c5b9f95-3235-42dd-81f5-678b3b91e46f@github.com>
References: <ovauTi1CSYZ068j2-fLVDWsy-0LMRrehH2ng_KHgtVs=.7c5b9f95-3235-42dd-81f5-678b3b91e46f@github.com>
Message-ID: <4pYfPXzDCQQmbSjDthVTM4DKdaffOujYyFfl-5rhOz0=.ff0a8129-3d2d-45b5-b78d-487ebec7d0d6@github.com>

On Sat, 26 Mar 2022 07:19:28 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Write a regression test for [JDK-4525475](https://bugs.openjdk.java.net/browse/JDK-4525475)
> 
> Issue:
> JFileChooser allows modification to the file-system by way of the "New Folder"
> button, and the ability to rename file/folder names. There is no method on
> JFileChooser which indicates that this type of modification should not be
> allowed within the given JFileChooser.
> 
> Testing:
> 1. Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.
> 2. Tested in original failed Java version and the fixed version;
> Java 1.4.0 -> Test Failed.
> $ j2sdk1.4.0/bin/java Bug4525475
> LookAndFeel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> Name = Go Up, readOnly = true
> Name = New Folder, readOnly = true
> Its a Read Only JFileChooser and has a New Folder Button. So Test Failed.
> Name = Go Up, readOnly = false
> Name = New Folder, readOnly = false
> Failed
> 
> Java 1.5.0 -> Test Passed.
> $ jdk1.5.0/bin/java Bug4525475
> LookAndFeel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> Name = Go Up, readOnly = true
> Name = Go Up, readOnly = false
> Name = New Folder, readOnly = false
> Passed

@aivanov-jdk Can you please review this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7969


From prr at openjdk.java.net  Sat Mar 26 22:33:50 2022
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 26 Mar 2022 22:33:50 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v2]
In-Reply-To: <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
Message-ID: <1tIvR5eh0Vu5KwAbEgVuMfpDPtInqHQRRvmSz9sWKwg=.f790f5e5-7646-4717-8019-a6bf225696a2@github.com>

On Thu, 24 Mar 2022 22:36:28 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

>> 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 incrementally with one additional commit since the last revision:
> 
>   8269806: Fix builds with old Freetype (before 2.5)

See my follow up message. Same occurs when using the font directly - not Dialog.
It is opening "Noto Color Emoji" from /usr/share/fonts/truetype/noto/NotoColorEmoji.ttf

The B&W ones that render properly in MY image are beacuse Dialog uses as its main font 
Deja Vu Sans has B&W emoticons defined as normal TrueType outlines.

Ignore those - it is the garbage ones that are the problem.

Note that JDK does not use ANY of Linux's libfontconfig's fancy aliasing of fonts etc.
If we report that file, and that name, that is what is used - end of story.

If  you do that NOT A SINGLE glyph from the font renders properly with AA=OFF.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4798


From prr at openjdk.java.net  Sun Mar 27 03:05:44 2022
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 27 Mar 2022 03:05:44 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v7]
In-Reply-To: <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
Message-ID: <-Aqq6KW5o6S5kuVHiaIQFW_T9OGYEqZlZhx73mF1um4=.19672f5b-a199-451a-b90f-821b7f9b2390@github.com>

On Wed, 23 Mar 2022 18:24:05 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   scale stroke width at higher scalings

BTW the graphics is also scaled when printing.
A printer is like a super-hires monitor (ignoring dot-matrix and the like which would be rubbish at this anyway).
Clearly a 1 pixel device space line on a 1200 dpi printer would not be ideal 1200/72 = 16.667 

And the logic (proposed) about adjusting the pixel width needs to be tested.

I think that unless you want to do a lot of printing testing,
then there should be some checking about whether the graphics is a java.awt.print.PrinterGraphics and
use some code kind of like today in that case ...
But a 300 dpi printer may be about the same as a super-hires monitor ?
Even then *theoretically* there's a chance you have a lo-res 150 dpi printer .. but I'd worry about that if it happens

So perhaps, this needs real printer testing printing to a real printer. Or may be more than one.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From duke at openjdk.java.net  Mon Mar 28 04:29:24 2022
From: duke at openjdk.java.net (Dmitry Kulikov)
Date: Mon, 28 Mar 2022 04:29:24 GMT
Subject: RFR: 8282863:
 java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on
 Windows 10 with HiDPI screen [v2]
In-Reply-To: <SogRHLx2pQzRLxpE6FW6BAjwW0qaawCm-A6Ff4Z3N54=.233a4715-0ec7-491a-ba75-c7c3f16b9ee8@github.com>
References: <SogRHLx2pQzRLxpE6FW6BAjwW0qaawCm-A6Ff4Z3N54=.233a4715-0ec7-491a-ba75-c7c3f16b9ee8@github.com>
Message-ID: <p01bGSKB-1xZPQ6J3MNai2gorrAcGkSs1zmRFohyW7E=.16c08e60-0681-4b95-b721-696e5258f720@github.com>

> Hello,
> Please review this fix for JDK-8282863.
> 
> The failing `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test basically checks that full-screen window remains full-screen when a display mode change occurs. It has been introduced in JDK-8211999, which also contains numerous fixes for HiDPI displays. In particular, JDK-8211999 changed the code of `Win32GraphicsDevice.setDisplayMode()` so that it uses screen dimensions in user space instead of device space, which is correct. However, if the display mode change incurs display scaling change, as it has been observed on Windows 10 laptop with HiDPI screen, the method used for obtaining screen bounds in user space returns incorrect values under certain conditions.
> 
> The issue is reproducible on Windows 10, when resolution of the primary screen is higher than 1024x768 with scaling greater than 100%. Resolution and scaling of secondary screen(s) is irrelevant. I used a laptop with 2160x1350 display resolution and scaling set to 150%. When the `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test is run with these initial conditions, roughly the following happens:
> 
> 1. `java.awt.Frame` is created and set as full-screen.
> 2. `Win32GraphicsDevice.setDisplayMode()` is called to change screen resolution from 2160x1350 to 1024x768.
> 3. `Win32GraphicsDevice.configDisplayMode()` call immediately changes the display resolution to 1024x768, which also incurs the immediate display scaling change from 150% to 100%.
> 4. Inside the `Win32GraphicsDevice.setDisplayMode()` screen bounds in user space are obtained via `Win32GraphicsConfig.getBounds()`:
> 5. In the native code of `Win32GraphicsConfig.getBounds()` new screen bounds in device space (1024x768) are correctly obtained via `MonitorBounds()`.
> 6. Then screen bounds are converted to user space by applying **scaling factors, which are not yet updated and correspond to previous display mode**. In our case, 1024x768 is scaled down by 150% and becomes 683x512.
> 7. Back in `Win32GraphicsDevice.setDisplayMode()` full-screen window bounds are set to incorrectly scaled 683x512 instead of 1024x768.
> 8. After returning from `Win32GraphicsDevice.setDisplayMode()` the test waits 4 seconds.
> 9. `WM_DISPLAYCHANGE` message is received and processed, followed by `WM_DPICHANGED`, which updates the scaling factors used by `Win32GraphicsConfig.getBounds()` to the correct value of 100%.
> 10. After 4 seconds test wakes up and obtains screen bounds in user space by calling `Win32GraphicsConfig.getBounds()`, which now correctly returns 1024x768.
> 11. Test compares full-screen window bounds with screen bounds, and fails with `java.lang.RuntimeException: width is wrong` as 683 is not equal to 1024 ? 30 pixels.
> 
> Proposed fix adds a `Win32GraphicsDevice.initScaleFactors()` call to `Win32GraphicsDevice.setDisplayMode()` code, between calling `Win32GraphicsDevice.configDisplayMode()` and `Win32GraphicsConfig.getBounds()`. This updates the scaling factors without waiting for `WM_DISPLAYCHANGE` or `WM_DPICHANGED`, `Win32GraphicsConfig.getBounds()` returns correctly scaled screen bounds in user space, and full-screen window remains correctly sized after display mode change.
> 
> I've run tests from `jdk_awt` group on Windows 10 using a laptop with the same settings that caused the issue (primary screen with 2160x1350 resolution and 150% scaling), and applying the fix did not introduce any new test failures.

Dmitry Kulikov has updated the pull request incrementally with two additional commits since the last revision:

 - 8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen
 - Revert "8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen"
   
   This reverts commit 23b40af8de9df4db9a1cc0137c0e875cf6595190.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7835/files
  - new: https://git.openjdk.java.net/jdk/pull/7835/files/23b40af8..cab8c316

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7835&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7835&range=00-01

  Stats: 31 lines in 2 files changed: 18 ins; 9 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7835.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7835/head:pull/7835

PR: https://git.openjdk.java.net/jdk/pull/7835


From psadhukhan at openjdk.java.net  Mon Mar 28 05:30:45 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 28 Mar 2022 05:30:45 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v4]
In-Reply-To: <px566UftzNVHlLSDErQ3n9S7ZPQ_6sqMrDjNy6Z_4_Y=.e8381b27-170d-4eee-a4a2-47681573859f@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <px566UftzNVHlLSDErQ3n9S7ZPQ_6sqMrDjNy6Z_4_Y=.e8381b27-170d-4eee-a4a2-47681573859f@github.com>
Message-ID: <NxTHfG8xfSfTOglYbahi8aOukFeG6ggFgnkIImq3_mI=.02c2a0fb-cdbe-492b-98ae-164095f241c8@github.com>

On Wed, 16 Mar 2022 06:02:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   korean fallback added

As I mentioned initially,
> tested with sanserif, serif, monospaced, dialog, dialoginput with PLAIN, BOLD, ITALIC, BOLD-ITALIC style **in that order**

so 1st 4 are sansserif, next 4 are serif etc.

As I see, we have this font support in the fontconfig properties 

Serif = Batang				 batang.ttc
sansserif = Malgun Gothic	malgun.ttf
monospaced = Gulimche		gulim.ttc
dialog = Malgun Gothic		malgun.ttf
dialoginput = Gulim			gulim.ttf

Now in my WIndows 10, I have these font files irrespective of Korean font pack installed or not, 
so I guess that is why there is **no difference** in the font image with the fix with/without korean font pack



Now, without the fix, [comparing with/without the fix with Korean font pack installed https://github.com/openjdk/jdk/pull/7643#issuecomment-1070307750 and https://github.com/openjdk/jdk/pull/7643#issuecomment-1070348395 ] there is minor difference (AFICS) in bold, italic corresponds to sansserif (2-3 position), monospaced (10-11), dialog (14-15), dialoginput (18-19) which used Gulim before fix but used Malgun Gothic Bold with fix **which i guess is expected**..

Also, there is clear difference in 6-8 th position for Bold, Italic, Bold-Italic which corresponds to **serif font** which uses same Batang font before and after the fix which I guess is because of the "first form", "second form" fallback issue discusses in this thread . I think with the fix `allfont.korean-fallback` is in effect so it uses malgun (which is why 1-4 position looks same as 5.-8) and without fix, it uses Batang

-------------

PR: https://git.openjdk.java.net/jdk/pull/7643


From psadhukhan at openjdk.java.net  Mon Mar 28 06:34:42 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 28 Mar 2022 06:34:42 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v3]
In-Reply-To: <HRR-kzpsYhfv5i3XdtQokkw4cjUl9fwxTPUlfeHSvC0=.c48b8a56-0dfc-4207-bf3b-9302b5728301@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>
 <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>
 <oAZ5tpWpksvN6sfEYoblyucXf_EqcxKAIiVvkvIugjU=.a10e37ec-b8e8-4ac3-9faf-f2a8d85189af@github.com>
 <r9ujiKOC7dRsKCLNjUEt-V8mCstzXKJLFPRQ1O6kqKs=.2b96988b-85c6-45d5-9d95-2e0112b458fb@github.com>
 <AUeNFfcZNdDhRKJExOY7lT7_eG07ZQ_E124iHS_oiVI=.af2824b3-dc46-4318-92c3-27a861269339@github.com>
 <0U4ZvK_ui_ieG7pPZAdhL1AyrJYQNqT0A_HRJIE8InQ=.26f7a810-a6a0-47d0-99d9-e2ffcfebe596@github.com>
 <ML4CSxlvMzInAbk9K0LicDa--V4QlgiUzzL1u7XkJ0s=.d8c7a73c-402a-4813-8fc6-faf9fd07745a@github.com>
 <9-KCaxc5kvdWS_6nETGIRiJgbTEWTWEPxmKT5JHSphw=.0bf35082-2b55-4cfd-bc7a-636a6d7a721a@github.com>
 <fYlGXZDTHTU5qaTisZmz9LLOKG7ShMugqXOMGDmiBPY=.b43629cd-7474-48a9-9e0f-3a9729808294@github.com>
 <-k8sDdAZltd4AcDIIOeKBcKLZ4q9XuTs6sT
 5Mmg2Q9I=.025a647c-34a7-478b-912d-7bfd4a7473b4@github.com>
 <AI90_XpQ47CeM9u1p7brUJMBFddpJgfVXFfBZIYtGfw=.7489df4f-b643-4d9e-b1dd-b15ba1b6a1ad@github.com>
 <RkgzdiaxcFiGijoKtrGci5FPKKcJU7d8vDLBdt1Rftk=.88653824-bf2f-4f5b-9c69-bbb536e49ee0@github.com>
 <gWFZ-lD8CQMjC69_dKMfB7F8a_4ZxUGlWwlUeAwCYlU=.546f5569-0309-45ce-8228-000e56dbbe66@github.com>
 <iyGfHY06FwqKUuJzNQlzG7CvXV9UZtQv0l3RhWUK2RQ=.cdb558c5-1983-4678-b299-35386cb3434a@github.com>
 <K80e0S6-JthHc7DhsDV3BQePXNNEesqd_y1uF9ecLWI=.03e52bae-752b-407c-be5d-ce98c47a83c4@github.com>
 <HRR-kzpsYhfv5i3XdtQokkw4cjUl9fwxTPUlfeHSvC0=.c48b8a56-0dfc-4207-bf3b-9302b5728301@github.com>
Message-ID: <oleoSKnRqVqnMj0DEkQ6apx-h5L8QJNzc1knyecRByQ=.ee2ad7f0-f54b-4326-b297-b89dc157ed63@github.com>

On Sat, 26 Mar 2022 00:33:47 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> I guess "selectionBackground" matches the "highlight" color which seems to follow accent color, by default but we can make highlight color different from accent color, but in this case focus color should match accent color, not highlight color...please confirm if this is what is happening..
>> Also, alternateSelectedControlColor is deprecated so you should consider replacing with [selectedContentBackgroundColor](https://developer.apple.com/documentation/appkit/nscolor/2998830-selectedcontentbackgroundcolor)
>
> @prsadhuk Cell Focus ring color does not change with highlight color settings. Tested for following cases -
> 
> <img width="1060" alt="image" src="https://user-images.githubusercontent.com/95945681/160217226-7d4236c7-1d3e-4062-8fad-974a13374624.png">

In my testing in osx10.15 with your fix, I see focus ring is following highlight color and not accent color...did you modify anything in your fix?
<img width="688" alt="Screenshot 2022-03-28 at 11 52 09 AM" src="https://user-images.githubusercontent.com/43534309/160338556-117c8e9b-4e78-4368-8040-dfca1d82e1ab.png">

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From psadhukhan at openjdk.java.net  Mon Mar 28 07:41:05 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 28 Mar 2022 07:41:05 GMT
Subject: RFR: 8283642: JavaDoc of JFileChooser() need to be updated for default
 directory in Windows
Message-ID: <Uu1tjsYL_XXTPAzsoeF2Wz3zus9LEfxMH3jRkxr5I7o=.fe2b6c5c-f85d-4717-a146-681be1f0ed05@github.com>

Default directory name has changed from "My Documents" to "Documents" in recent WIndows version, so javadoc needs to be updated.

-------------

Commit messages:
 - 8283642: JavaDoc of JFileChooser() need to be updated for default directory in Windows

Changes: https://git.openjdk.java.net/jdk/pull/7983/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7983&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283642
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7983.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7983/head:pull/7983

PR: https://git.openjdk.java.net/jdk/pull/7983


From avu at openjdk.java.net  Mon Mar 28 07:47:45 2022
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 28 Mar 2022 07:47:45 GMT
Subject: RFR: 8273355: Flickering on tooltip appearance IntelliJ IDEA
 2021.2.1 [v3]
In-Reply-To: <_ot6GP1XwCF5oSXrGTJgDedUDbbhEw-UNxd6uDP4EUo=.dda400c1-e463-46c2-b0e7-ff8b556c7d99@github.com>
References: <_Q4d9YdOccAdjO6LsIlbIOt55Bn7PGAz3-NmVBF2vLU=.01b029e3-f88f-4b6b-b12b-3509f9dcd486@github.com>
 <88P-u7cRkyFDdNY_J7mxwjKA6UAd6Jqe31yuSZIYoV4=.865990c7-615b-4417-b10b-60ffe9f0d766@github.com>
 <XUJMlk1enGMJLYHkYfUDOpIuTL2X0el-mQV1_PWqK-0=.43b55792-5da3-40c7-a5af-f39c91c22210@github.com>
 <_ot6GP1XwCF5oSXrGTJgDedUDbbhEw-UNxd6uDP4EUo=.dda400c1-e463-46c2-b0e7-ff8b556c7d99@github.com>
Message-ID: <WdGiYtcre6Wq9KV2BsYMCd9yrmMsMPjkYfbAgqRRjnQ=.33d4bed9-3607-4386-94ef-459a35d92b1a@github.com>

On Thu, 24 Mar 2022 18:25:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> If it skips the texture property I guess it will break it?
>> I've not noticed it in my testing. Do you mean particular tests? But anyway your suggestion looks more elegant and it works in my scenarios, also I've run test-jdk_desktop_part1 with it. No related problem was found.
>
> The CPlatformWindow.setOpaque() changes the background of the native window only if the texture property is not set. So if the code will change the color directly somewhere then the texture property will be broken. Not sure that we have a test for that.
> Please update the copyright date.

@mrserb updated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7931


From psadhukhan at openjdk.java.net  Mon Mar 28 07:48:47 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 28 Mar 2022 07:48:47 GMT
Subject: RFR: 8283642: JavaDoc of JFileChooser() need to be updated for
 default directory in Windows
In-Reply-To: <Uu1tjsYL_XXTPAzsoeF2Wz3zus9LEfxMH3jRkxr5I7o=.fe2b6c5c-f85d-4717-a146-681be1f0ed05@github.com>
References: <Uu1tjsYL_XXTPAzsoeF2Wz3zus9LEfxMH3jRkxr5I7o=.fe2b6c5c-f85d-4717-a146-681be1f0ed05@github.com>
Message-ID: <Rlmv9DFyvW2hQ3Ge892UJT0aIfXsbGFQENSauJWuqOI=.85b54faa-16b7-4359-92f3-9045b2c1bc40@github.com>

On Mon, 28 Mar 2022 07:34:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Default directory name has changed from "My Documents" to "Documents" in recent WIndows version, so javadoc needs to be updated.

I guess it will not need a CSR

-------------

PR: https://git.openjdk.java.net/jdk/pull/7983


From serb at openjdk.java.net  Mon Mar 28 07:52:42 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 28 Mar 2022 07:52:42 GMT
Subject: RFR: 8024624: [TEST_BUG] [macosx] CTRL+RIGHT(LEFT) doesn't move
 selection on next cell in JTable on Aqua L&F [v2]
In-Reply-To: <euSIvXa4E3AN7zAwwJtcrRKViubhVvKosTMgpEJ72FY=.546f4164-50b8-4890-ab57-d59feeaf723c@github.com>
References: <LdWWDPfwqpCC-_EBaYQLX4rFIyV9FLAG5ugIJb0ruI4=.bc296640-5df9-41a1-b857-14f334c1be8e@github.com>
 <euSIvXa4E3AN7zAwwJtcrRKViubhVvKosTMgpEJ72FY=.546f4164-50b8-4890-ab57-d59feeaf723c@github.com>
Message-ID: <fbI4kcxeYJ4ItqjbmcaFd7sW1PUdMGkbhcp-VCSFGTo=.15f59fd9-2b55-46ee-be61-68dae628d898@github.com>

On Fri, 25 Mar 2022 19:20:43 GMT, DamonGuy <duke at openjdk.java.net> wrote:

>> Aqua L&F tables lacked support for `CTRL+ARROW`, `CTRL+PG_UP/DOWN`, and `CTRL+SHIFT+PG_UP/DOWN` key bindings. This allows for navigation and selection of table cells without the need of a mouse and without deselecting the current selected cell group. 
>> 
>> Those key bindings are added to Aqua's key bindings for tables. The `SPACE` key binding was also added because it allows for the selection of cells after navigating using the `CTRL+ARROW` bindings, and some of the new bindings are only useful with the `SPACE` binding added. The closed test that this bug originates from tests for both left-to-right and right-to-left functionality, so the new directional bindings are also added to the right-to-left key bindings table where needed.
>> 
>> This requires mission control shortcuts in macOS to be disabled as `CTRL+ARROW` keys are normally used for virtual desktop navigation.
>
> DamonGuy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Converted closed repo test to open repo. Removed changes to Aqua key bindings.

Marked as reviewed by serb (Reviewer).

BTW why this PR is in the draft state?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7792


From psadhukhan at openjdk.java.net  Mon Mar 28 08:51:01 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 28 Mar 2022 08:51:01 GMT
Subject: RFR: 8224977: [macos] On AquaLookAndFeel,
 Iconified JInternalFrame does not restore when Control + F5 is used.
Message-ID: <wEx7_jcEbMONzw6NGV_BjDuZ01piwdRsrrhzhKBIKbw=.5bd35640-747b-45c9-8c1d-24daa377b056@github.com>

test/jdk/javax/swing/JInternalFrame/Test6325652.java test was failing in macos in Aqua L&F due to nonsupport in macos of such shortcuts Ctrl+F5 to restore or Ctrl+F9 to iconify. Keyboard->Shortcut in macos System->Preference do not have these shortcut usage.
https://docs.oracle.com/javase/tutorial/uiswing/components/internalframe.html also does not talk of these shortcut support as standard.
So, removed this test from macos run.

-------------

Commit messages:
 - 8224977: [macos] On AquaLookAndFeel, Iconified JInternalFrame does not restore when Control + F5 is used

Changes: https://git.openjdk.java.net/jdk/pull/7985/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7985&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8224977
  Stats: 2 lines in 2 files changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7985.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7985/head:pull/7985

PR: https://git.openjdk.java.net/jdk/pull/7985


From alexsch at openjdk.java.net  Mon Mar 28 09:39:24 2022
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Mon, 28 Mar 2022 09:39:24 GMT
Subject: RFR: 8181571: printing to CUPS fails on mac sandbox app [v6]
In-Reply-To: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com>
References: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com>
Message-ID: <EM_BNKx1MeXnJWvkJ7Pi2wuzPBHSJS_S030IvP_NpoI=.2e0f89d5-64fe-4040-9be0-a1cbcbbc2263@github.com>

> The issue is reproduced on macOS Big Sur 11.0.1 with jdk 16.0.1+9.
> 
> Create a native macOS app from the Hello.java file, sign and run it in sandbox:
> 
> import javax.print.*;
> import javax.swing.*;
> 
> public class Hello {
> 
>     public static void main(String[] args) throws Exception {
>         SwingUtilities.invokeAndWait(() -> {
>             boolean isSandboxed = System.getenv("APP_SANDBOX_CONTAINER_ID") != null;
>             PrintService defaultPrinter = PrintServiceLookup.lookupDefaultPrintService();
>             PrintService[] services = PrintServiceLookup.lookupPrintServices(null, null);
> 
>             StringBuilder builder = new StringBuilder();
>             builder.append("is sandboxed: ").append(isSandboxed).append("\n");
>             builder.append("default printer: ").append(defaultPrinter).append("\n");
>             int size = services.length;
>             for (int i = 0; i < size; i++) {
>                 builder.append("printer[").append(i).append("]=").append(services[i]).append("\n");
>             }
>             JOptionPane.showMessageDialog(null, builder.toString());
>         });
>     }
> }
> 
> The signed app in sandbox shows null default printer and PrintServiceLookup.lookupPrintServices(null, null) returns "Unix Printer: lp".
> ![PrintSandboxedApp](https://bugs.openjdk.java.net/secure/attachment/95629/PrintSandboxedApp.png)
> 
> The problem has been discussed on  2d-dev mail list:
>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-June/008375.html
>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-July/008418.html
> 
> According to the discussion:
> 
>> I've submitted a DTS incident to Apple and a friend there has followed-up.
>> Their unofficial position is that java should be connecting to the cups interface returned
>> by the cupsServer() function and not changing the interface string to "localhost".
>> Security changes in 10.12.4 reject the TCP connection which they say confuses
>> network-client access with print access.  They don't seem interested in loosening that change.
> 
> 
> The proposed solution is to use the domain socket pathname in httpConnect(...) cups function and cupsGetDests(...) to get list of printers from cups  when the app is signed and is run in sandbox on MacOs.

Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:

  Remove ExceptionClear() from getCupsDefaultPrinters()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4861/files
  - new: https://git.openjdk.java.net/jdk/pull/4861/files/f6697fa2..1b14401e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4861&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4861&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4861.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4861/head:pull/4861

PR: https://git.openjdk.java.net/jdk/pull/4861


From dbatrak at openjdk.java.net  Mon Mar 28 09:39:44 2022
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Mon, 28 Mar 2022 09:39:44 GMT
Subject: RFR: 8185261: Font fallback sometimes doesn't work in Swing text
 components [v2]
In-Reply-To: <Ha2rM2oGB_blf1QlZgxBbGjJeWJS9QNbfahtnE3Rr5E=.87c3c1cc-671e-430a-a131-9c6b62692714@github.com>
References: <5qQoyooaZzlKSp4iMudwLZ16MotrGrPB7GhQ3aAVYjo=.8e97ba6f-4aab-40d7-944f-4f68dc2b7b1c@github.com>
 <4SfhJKrUWWmdo2ZioTjqiU5b3a4cZBwWhMX89auZBRg=.5bf8b903-dbb2-4e7c-adaf-59c5e8212e72@github.com>
 <Ha2rM2oGB_blf1QlZgxBbGjJeWJS9QNbfahtnE3Rr5E=.87c3c1cc-671e-430a-a131-9c6b62692714@github.com>
Message-ID: <wbrvKeifSzrLVqz9PEaFMoLjT2BvtHp5nDEGKngMG_I=.6821690b-fd3d-4144-aff3-f8ac36f6ebd1@github.com>

On Thu, 24 Mar 2022 02:49:49 GMT, Phil Race <prr at openjdk.org> wrote:

>> Dmitry Batrak has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove 'headful' requirement from test case
>
> I know .. I know .. I just (a) don't like it, and (b) don't have a good alternative.

@prrace So, how do we proceed from here? Should I just wait and ping you periodically?
I believe, the bug in question is quite important to fix. It's doesn't have a good workaround, at least in big projects where it's hard to have full control over the code base - a perfectly legitimate piece of code executed in one place will break the code in a different place. And it could be hard to investigate due to this reason.
I'm ready to re-do the fix in any acceptable way, but I'll need at least some directions about what is considered acceptable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7313


From alexsch at openjdk.java.net  Mon Mar 28 09:48:45 2022
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Mon, 28 Mar 2022 09:48:45 GMT
Subject: RFR: 8181571: printing to CUPS fails on mac sandbox app [v6]
In-Reply-To: <MHgDIa0zqSzB6bPEb7DnRIOWzOGYmOzzrt44Z9CAZCE=.542d910a-51a6-4220-a266-07b2623b9807@github.com>
References: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com>
 <GiCn7RQLCIXsjuBtqWxnW32umwyG5GkiIZnvLM1lXCo=.9c7f43cf-d55f-4538-92e0-0ad5e11e8efb@github.com>
 <Noj7YW0DvwQOOW-6mjfJzKzVCAro-5AccwCLjQ9A4ZY=.5475f0c7-82cb-4015-9a97-b8f444c1657e@github.com>
 <MHgDIa0zqSzB6bPEb7DnRIOWzOGYmOzzrt44Z9CAZCE=.542d910a-51a6-4220-a266-07b2623b9807@github.com>
Message-ID: <GD5p2R6e5YG6f86TiJat1MD_gP6ljprVp2iYfwQH4aU=.7138078b-525a-4944-a7cc-d24ef69ac7e0@github.com>

On Fri, 25 Mar 2022 17:31:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> The array creation error handling is implemented in the similar way as it is done in the getMedia() function.
>> The ExceptionClear() has been added to the getMedia() by `8031001: [Parfait] warnings from b121 for jdk/src/solaris/native/sun/awt: JNI-related warnings`
>> I would prefer to have unified error handling in these methods. If ExceptionClear is not suitable in this place it would be better to recheck JDK-8031001 and update all places accordingly in a separate fix.
>
> I can't agree with the apparent reasoning that "well that thing over there is wrong, so it's ok for me to add something here that's wrong too".
> 
> And the getMedia(..) case is different.  It doesn't re-create the same exception.
> It wants to create an OOME which is not actually thrown by GetStringUTFChars() since it needs to throw some exception and with an appropriate string reason.
> And the clear there is just prudence since it is creating a new one and can't be 100% sure there isn't one pending.
> 
> In your case the JNI spec documents OOME 
> https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#newobjectarray
> 
> So in your case it is pointless. Please just remote the Clear()

ExceptionClear(env) is removed from the `if (nameArray == NULL)` check.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4861


From mvs at openjdk.java.net  Mon Mar 28 14:24:11 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Mon, 28 Mar 2022 14:24:11 GMT
Subject: RFR: 8283624: Create an automated regression test for RFE-4390885
Message-ID: <DfOvs0ck3_ucgdZG8gdlmXPriMoEM9-RjaveRlmRZYA=.b6690b6a-4a51-4c98-b5ee-6409fe4b0f84@github.com>

Write a regression test for [JDK-4390885](https://bugs.openjdk.java.net/browse/JDK-4390885) Enhancement Request.

Issue:
Please add the ability to set the location of a JFileChooser. This might be a
bug, but JFileChooser.setLocation() has no effect when
JFileChooser.showXXXXDialog() is called. This is becoming very important as the
popularity of multiple monitors is increasing. These dialogs show up on the
wrong monitor which is really annoying. Also due to bug #4189244 I am unable to
avoid painting problems by positioning the dialog away from the menu item that
initiated it.

Fix:
Now it's possible to set the location of Dialog in JFileChooser.

Testing:
1. Tested in Mach5 10 times per platform(macos,linux,windows) and got all Pass.

-------------

Commit messages:
 - 8283624: Create an automated regression test for RFE-4390885

Changes: https://git.openjdk.java.net/jdk/pull/7996/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7996&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283624
  Stats: 279 lines in 1 file changed: 279 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7996.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7996/head:pull/7996

PR: https://git.openjdk.java.net/jdk/pull/7996


From prr at openjdk.java.net  Mon Mar 28 15:19:46 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 28 Mar 2022 15:19:46 GMT
Subject: RFR: 8181571: printing to CUPS fails on mac sandbox app [v6]
In-Reply-To: <GD5p2R6e5YG6f86TiJat1MD_gP6ljprVp2iYfwQH4aU=.7138078b-525a-4944-a7cc-d24ef69ac7e0@github.com>
References: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com>
 <GiCn7RQLCIXsjuBtqWxnW32umwyG5GkiIZnvLM1lXCo=.9c7f43cf-d55f-4538-92e0-0ad5e11e8efb@github.com>
 <Noj7YW0DvwQOOW-6mjfJzKzVCAro-5AccwCLjQ9A4ZY=.5475f0c7-82cb-4015-9a97-b8f444c1657e@github.com>
 <MHgDIa0zqSzB6bPEb7DnRIOWzOGYmOzzrt44Z9CAZCE=.542d910a-51a6-4220-a266-07b2623b9807@github.com>
 <GD5p2R6e5YG6f86TiJat1MD_gP6ljprVp2iYfwQH4aU=.7138078b-525a-4944-a7cc-d24ef69ac7e0@github.com>
Message-ID: <7L6-6wY6pZIe-gbEf3bRAOLHbYr_-Xlb8YbTUxcLOxE=.89524cec-1130-454c-93f8-ef674082b739@github.com>

On Mon, 28 Mar 2022 09:45:11 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> I can't agree with the apparent reasoning that "well that thing over there is wrong, so it's ok for me to add something here that's wrong too".
>> 
>> And the getMedia(..) case is different.  It doesn't re-create the same exception.
>> It wants to create an OOME which is not actually thrown by GetStringUTFChars() since it needs to throw some exception and with an appropriate string reason.
>> And the clear there is just prudence since it is creating a new one and can't be 100% sure there isn't one pending.
>> 
>> In your case the JNI spec documents OOME 
>> https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#newobjectarray
>> 
>> So in your case it is pointless. Please just remote the Clear()
>
> ExceptionClear(env) is removed from the `if (nameArray == NULL)` check.

I should have said (as I did in the beginning) remove the clear - and the new throw - and just return null.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4861


From aivanov at openjdk.java.net  Mon Mar 28 15:46:51 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 28 Mar 2022 15:46:51 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v7]
In-Reply-To: <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
Message-ID: <XbZWIp3wb5rCcQoxzBPYlnWW81i2TN9qmvWcUsqqmqY=.4575446e-2a48-4506-ab88-19be4f1e76b8@github.com>

On Wed, 23 Mar 2022 18:24:05 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   scale stroke width at higher scalings

It doesn't draw the border correctly when run with `-Dsun.java2d.uiScale=3`:

![Titled Border rendered at 300%](https://user-images.githubusercontent.com/70774172/160433797-df0c54b8-38e3-4902-aef3-db3daf7c7172.png)

All the four images look identically but rendering is not as expected.

On the left and the top, the shadow is 3-pixel wide, the highlight is 2-pixel wide. There's no highlight on the right and bottom side. However, there are 3 light pixels above and below the right-side shadow line, there are also 3 light pixels to the right of the bottom shadow line.

It still has the same bug but at 125% now: the third border has no shadow on the left.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From alexsch at openjdk.java.net  Mon Mar 28 16:05:34 2022
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Mon, 28 Mar 2022 16:05:34 GMT
Subject: RFR: 8181571: printing to CUPS fails on mac sandbox app [v7]
In-Reply-To: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com>
References: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com>
Message-ID: <obWQjhyQMLRwJ-MEpaw4xSE2VRGqwdPorjuF-A3UZvE=.57519009-9cab-42b8-aa90-20fd248a3196@github.com>

> The issue is reproduced on macOS Big Sur 11.0.1 with jdk 16.0.1+9.
> 
> Create a native macOS app from the Hello.java file, sign and run it in sandbox:
> 
> import javax.print.*;
> import javax.swing.*;
> 
> public class Hello {
> 
>     public static void main(String[] args) throws Exception {
>         SwingUtilities.invokeAndWait(() -> {
>             boolean isSandboxed = System.getenv("APP_SANDBOX_CONTAINER_ID") != null;
>             PrintService defaultPrinter = PrintServiceLookup.lookupDefaultPrintService();
>             PrintService[] services = PrintServiceLookup.lookupPrintServices(null, null);
> 
>             StringBuilder builder = new StringBuilder();
>             builder.append("is sandboxed: ").append(isSandboxed).append("\n");
>             builder.append("default printer: ").append(defaultPrinter).append("\n");
>             int size = services.length;
>             for (int i = 0; i < size; i++) {
>                 builder.append("printer[").append(i).append("]=").append(services[i]).append("\n");
>             }
>             JOptionPane.showMessageDialog(null, builder.toString());
>         });
>     }
> }
> 
> The signed app in sandbox shows null default printer and PrintServiceLookup.lookupPrintServices(null, null) returns "Unix Printer: lp".
> ![PrintSandboxedApp](https://bugs.openjdk.java.net/secure/attachment/95629/PrintSandboxedApp.png)
> 
> The problem has been discussed on  2d-dev mail list:
>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-June/008375.html
>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-July/008418.html
> 
> According to the discussion:
> 
>> I've submitted a DTS incident to Apple and a friend there has followed-up.
>> Their unofficial position is that java should be connecting to the cups interface returned
>> by the cupsServer() function and not changing the interface string to "localhost".
>> Security changes in 10.12.4 reject the TCP connection which they say confuses
>> network-client access with print access.  They don't seem interested in loosening that change.
> 
> 
> The proposed solution is to use the domain socket pathname in httpConnect(...) cups function and cupsGetDests(...) to get list of printers from cups  when the app is signed and is run in sandbox on MacOs.

Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:

  Remove JNU_ThrowOutOfMemoryError from getCupsDefaultPrinters()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4861/files
  - new: https://git.openjdk.java.net/jdk/pull/4861/files/1b14401e..c35a8445

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4861&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4861&range=05-06

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4861.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4861/head:pull/4861

PR: https://git.openjdk.java.net/jdk/pull/4861


From alexsch at openjdk.java.net  Mon Mar 28 16:16:45 2022
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Mon, 28 Mar 2022 16:16:45 GMT
Subject: RFR: 8181571: printing to CUPS fails on mac sandbox app [v7]
In-Reply-To: <7L6-6wY6pZIe-gbEf3bRAOLHbYr_-Xlb8YbTUxcLOxE=.89524cec-1130-454c-93f8-ef674082b739@github.com>
References: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com>
 <GiCn7RQLCIXsjuBtqWxnW32umwyG5GkiIZnvLM1lXCo=.9c7f43cf-d55f-4538-92e0-0ad5e11e8efb@github.com>
 <Noj7YW0DvwQOOW-6mjfJzKzVCAro-5AccwCLjQ9A4ZY=.5475f0c7-82cb-4015-9a97-b8f444c1657e@github.com>
 <MHgDIa0zqSzB6bPEb7DnRIOWzOGYmOzzrt44Z9CAZCE=.542d910a-51a6-4220-a266-07b2623b9807@github.com>
 <GD5p2R6e5YG6f86TiJat1MD_gP6ljprVp2iYfwQH4aU=.7138078b-525a-4944-a7cc-d24ef69ac7e0@github.com>
 <7L6-6wY6pZIe-gbEf3bRAOLHbYr_-Xlb8YbTUxcLOxE=.89524cec-1130-454c-93f8-ef674082b739@github.com>
Message-ID: <2bNMw4mKe7NKjNJUVCrFD-CcClMxh4kC57QypL15eQs=.4b819aee-f65e-40fc-ac54-5dc806d36b70@github.com>

On Mon, 28 Mar 2022 15:16:52 GMT, Phil Race <prr at openjdk.org> wrote:

>> ExceptionClear(env) is removed from the `if (nameArray == NULL)` check.
>
> I should have said (as I did in the beginning) remove the clear - and the new throw - and just return null.

JNU_ThrowOutOfMemoryError is removed from code where nameArray and utf_str are checked to NULL.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4861


From aivanov at openjdk.java.net  Mon Mar 28 16:19:51 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 28 Mar 2022 16:19:51 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v7]
In-Reply-To: <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
Message-ID: <KMPhFqkwAp0rCjmrAJalrI5fMrnj4TqKl1c2UlaSHYI=.edf6eefd-b1f7-4436-9a05-428b4c397c8d@github.com>

On Wed, 23 Mar 2022 18:24:05 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   scale stroke width at higher scalings

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 175:

> 173:                                                     : getShadowColor(c), w, h, stkWidth);
> 174:         paintBorderRect(g, (etchType == LOWERED) ? getShadowColor(c)
> 175:                                                     : getHighlightColor(c), w, h, stkWidth);

Is it possible to paint the border with the rectangles like it was before?

We know that the lines were overdrawn because of the scale and this is what the fix tries to correct to make both shadow and highlight always visible and of the same thickness.

test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 46:

> 44:  * @bug 8279614
> 45:  * @summary The left line of the TitledBorder is not painted on 150 scale factor
> 46:  * @requires (os.family == "windows")

The test is not Windows specific, is it? Yet Java supports fractional scales on Windows only at the moment, right?

I still think it makes sense to run the test on Linux and macOS for 100%, 200% and 300% which are supported.

test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 53:

> 51:   public static JFrame frame;
> 52:   public static JPanel parentPanel;
> 53:   public static JPanel childPanel;

Please correct the indentation in the test: each level is indented by four spaces.

test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 76:

> 74:     for (int i = 15; i < 25 && testFail == 0; i++) {
> 75:       for (int j = 80; j < 100; j++) {
> 76:         if (buff.getRGB(i, j) == -0x5F5F60) {

The colour should not be hardcoded.

I suggest verifying the border is drawn correctly: the shadow and highlight lines have the correct thickness. Not only left side of the border should be verified but top, right, and bottom sides too.

test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 85:

> 83: 
> 84:     for (int i = 15; i < 25 && testFail == 1; i++) {
> 85:       for (int j = 150; j < 170; j++) {

The second pair of the for-loops is the same as the first one but the start coordinates for `y` are different. It should be a method which accepts start coordinates rather than four nearly identical for-loops.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From prr at openjdk.java.net  Mon Mar 28 16:38:12 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 28 Mar 2022 16:38:12 GMT
Subject: RFR: 8283700: Add final or sealed modifier to appropriate java.awt API
 classes
Message-ID: <ACVjMBKNkkTQlSh3-PKmvc_Nlr6kIWZpuBb4D9WsNBs=.ef511416-40f1-428d-abd8-1ddf76142174@github.com>

JDK 17 delivered JEP 409: Sealed Classes : https://openjdk.java.net/jeps/409
In essence this JEP allows a class to limit which classes can subclass it.
If a class has no subclasses and cannot be subclassed outside the JDK it can also be made final.
Suitable classes across the JDK are being retro-fitted to be sealed (or made final) where it can be done compatibly.
This fix takes care of several AWT classes which were identified.
If later we need to remove sealed or make a class non-final that will also be a compatible change,
so we aren't locking ourselves into this.

All our automated regression tests - plus JCK tests have been run.

This will require a CSR

-------------

Commit messages:
 - 8283700: Add final or sealed modifier to appropriate java.awt API classes

Changes: https://git.openjdk.java.net/jdk/pull/7998/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7998&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283700
  Stats: 29 lines in 12 files changed: 17 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7998.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7998/head:pull/7998

PR: https://git.openjdk.java.net/jdk/pull/7998


From darcy at openjdk.java.net  Mon Mar 28 16:47:48 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 28 Mar 2022 16:47:48 GMT
Subject: RFR: 8283700: Add final or sealed modifier to appropriate java.awt
 API classes
In-Reply-To: <ACVjMBKNkkTQlSh3-PKmvc_Nlr6kIWZpuBb4D9WsNBs=.ef511416-40f1-428d-abd8-1ddf76142174@github.com>
References: <ACVjMBKNkkTQlSh3-PKmvc_Nlr6kIWZpuBb4D9WsNBs=.ef511416-40f1-428d-abd8-1ddf76142174@github.com>
Message-ID: <3pQb0mtS2uxPFuaVnqPbkmlQ4GqPhg2XzppH61X0cNw=.ff1085ca-9112-4986-b4a5-8312c615dba2@github.com>

On Mon, 28 Mar 2022 16:30:50 GMT, Phil Race <prr at openjdk.org> wrote:

> JDK 17 delivered JEP 409: Sealed Classes : https://openjdk.java.net/jeps/409
> In essence this JEP allows a class to limit which classes can subclass it.
> If a class has no subclasses and cannot be subclassed outside the JDK it can also be made final.
> Suitable classes across the JDK are being retro-fitted to be sealed (or made final) where it can be done compatibly.
> This fix takes care of several AWT classes which were identified.
> If later we need to remove sealed or make a class non-final that will also be a compatible change,
> so we aren't locking ourselves into this.
> 
> All our automated regression tests - plus JCK tests have been run.
> 
> This will require a CSR

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7998


From duke at openjdk.java.net  Mon Mar 28 17:00:49 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Mon, 28 Mar 2022 17:00:49 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v3]
In-Reply-To: <oleoSKnRqVqnMj0DEkQ6apx-h5L8QJNzc1knyecRByQ=.ee2ad7f0-f54b-4326-b297-b89dc157ed63@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>
 <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>
 <oAZ5tpWpksvN6sfEYoblyucXf_EqcxKAIiVvkvIugjU=.a10e37ec-b8e8-4ac3-9faf-f2a8d85189af@github.com>
 <r9ujiKOC7dRsKCLNjUEt-V8mCstzXKJLFPRQ1O6kqKs=.2b96988b-85c6-45d5-9d95-2e0112b458fb@github.com>
 <AUeNFfcZNdDhRKJExOY7lT7_eG07ZQ_E124iHS_oiVI=.af2824b3-dc46-4318-92c3-27a861269339@github.com>
 <0U4ZvK_ui_ieG7pPZAdhL1AyrJYQNqT0A_HRJIE8InQ=.26f7a810-a6a0-47d0-99d9-e2ffcfebe596@github.com>
 <ML4CSxlvMzInAbk9K0LicDa--V4QlgiUzzL1u7XkJ0s=.d8c7a73c-402a-4813-8fc6-faf9fd07745a@github.com>
 <9-KCaxc5kvdWS_6nETGIRiJgbTEWTWEPxmKT5JHSphw=.0bf35082-2b55-4cfd-bc7a-636a6d7a721a@github.com>
 <fYlGXZDTHTU5qaTisZmz9LLOKG7ShMugqXOMGDmiBPY=.b43629cd-7474-48a9-9e0f-3a9729808294@github.com>
 <-k8sDdAZltd4AcDIIOeKBcKLZ4q9XuTs6sT
 5Mmg2Q9I=.025a647c-34a7-478b-912d-7bfd4a7473b4@github.com>
 <AI90_XpQ47CeM9u1p7brUJMBFddpJgfVXFfBZIYtGfw=.7489df4f-b643-4d9e-b1dd-b15ba1b6a1ad@github.com>
 <RkgzdiaxcFiGijoKtrGci5FPKKcJU7d8vDLBdt1Rftk=.88653824-bf2f-4f5b-9c69-bbb536e49ee0@github.com>
 <gWFZ-lD8CQMjC69_dKMfB7F8a_4ZxUGlWwlUeAwCYlU=.546f5569-0309-45ce-8228-000e56dbbe66@github.com>
 <iyGfHY06FwqKUuJzNQlzG7CvXV9UZtQv0l3RhWUK2RQ=.cdb558c5-1983-4678-b299-35386cb3434a@github.com>
 <K80e0S6-JthHc7DhsDV3BQePXNNEesqd_y1uF9ecLWI=.03e52bae-752b-407c-be5d-ce98c47a83c4@github.com>
 <HRR-kzpsYhfv5i3XdtQokkw4cjUl9fwxTPUlfeHSvC0=.c48b8a56-0dfc-4207-bf3b-9302b5728301@github.com>
 <oleoSKnRqVqnMj0DEkQ6apx-h5L8QJNzc1knyecRByQ=.ee2ad7f0-f54b-4326-b297-b89dc157ed63@github.com>
Message-ID: <CHf0EKW62xlXR2lGV9GFiBNdMqlfxZZqCv7lf5SXJx8=.8e061934-6d75-42d0-ace8-c9bd3e39deb7@github.com>

On Mon, 28 Mar 2022 06:31:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> @prsadhuk Cell Focus ring color does not change with highlight color settings. Tested for following cases -
>> 
>> <img width="1060" alt="image" src="https://user-images.githubusercontent.com/95945681/160217226-7d4236c7-1d3e-4062-8fad-974a13374624.png">
>
> In my testing in osx10.15 with your fix, I see focus ring is following highlight color and not accent color...did you modify anything in your fix?
> <img width="688" alt="Screenshot 2022-03-28 at 11 52 09 AM" src="https://user-images.githubusercontent.com/43534309/160338556-117c8e9b-4e78-4368-8040-dfca1d82e1ab.png">

@prsadhuk There was a small change to deriveContrastFocusRing (AquaLookAndFeel.java) which I haven't checked in because of build issues related to [selectedContentBackgroundColor](https://developer.apple.com/documentation/appkit/nscolor/2998830-selectedcontentbackgroundcolor).

The above issue might not be related to the change in deriveContrastFocusRing. I'll test and try to replicate the above scenario and push in any latest changes to AquaLookAndFeel.java

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From duke at openjdk.java.net  Mon Mar 28 17:06:41 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Mon, 28 Mar 2022 17:06:41 GMT
Subject: RFR: 8283712 : Create a manual test framework class [v4]
In-Reply-To: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
Message-ID: <IMKOkFbDuV-4DlmfcBxxPuL8dBo2GxrGWFET0sMnPPU=.6ca91ed1-c940-4880-8487-892cb77de3e8@github.com>

> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
> 1) Frame which contains test instruction .
> 2) Pass & Fail button so that user can mark the test pass or fail
> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
> 4) Disposing of all the frames.
> 
> @aivanov-jdk

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  Dispose the Frame based in EDT

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7966/files
  - new: https://git.openjdk.java.net/jdk/pull/7966/files/552bfad6..c9e64add

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7966&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7966&range=02-03

  Stats: 18 lines in 1 file changed: 3 ins; 11 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7966.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7966/head:pull/7966

PR: https://git.openjdk.java.net/jdk/pull/7966


From duke at openjdk.java.net  Mon Mar 28 17:06:42 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Mon, 28 Mar 2022 17:06:42 GMT
Subject: RFR: 8283712 : Create a manual test framework class [v3]
In-Reply-To: <JTCIRMhuj6TvAit2LOcGGvIM7tzowJNlbWHg0ZkcZJY=.65f4a88c-a1d7-403e-bba0-65430c703316@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <hdBE7KpygvUrrx52-NQ_y7Rl_aHM3NUKQOgjAq6O8LY=.69551728-b6c5-4b96-bbb0-7f963dd51310@github.com>
 <JTCIRMhuj6TvAit2LOcGGvIM7tzowJNlbWHg0ZkcZJY=.65f4a88c-a1d7-403e-bba0-65430c703316@github.com>
Message-ID: <l_PxleQG2hqkA8N06whNjtVeTUrDp7VT9bET4EdqrKM=.6e34ce0e-3170-46fa-b9e9-94dfa2f2a63d@github.com>

On Sat, 26 Mar 2022 02:37:09 GMT, Phil Race <prr at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed the white space issue
>
> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 103:
> 
>> 101:      * If user does not select pass or fail button then the test waits for
>> 102:      * the specified timeoutMinutes period and the test gets timeout.
>> 103:      * This method should not be invoke with in EDT.
> 
> This method should not be invoked on the EDT ?
> 
> Actually I wonder if we can do better  for this AND the other method.
> 
> CHECK if its the EDT and if it is invoke dispose() directly, if it isn't  then use invokeAndWait.
> 
> Also remember that SwingUtilities.invokeAndWait is just a wrapper for EventQueue.invokeAndWait

Fixed as suggested.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7966


From duke at openjdk.java.net  Mon Mar 28 17:00:48 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Mon, 28 Mar 2022 17:00:48 GMT
Subject: RFR: 8283712 : Create a manual test framework class [v3]
In-Reply-To: <JTCIRMhuj6TvAit2LOcGGvIM7tzowJNlbWHg0ZkcZJY=.65f4a88c-a1d7-403e-bba0-65430c703316@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <hdBE7KpygvUrrx52-NQ_y7Rl_aHM3NUKQOgjAq6O8LY=.69551728-b6c5-4b96-bbb0-7f963dd51310@github.com>
 <JTCIRMhuj6TvAit2LOcGGvIM7tzowJNlbWHg0ZkcZJY=.65f4a88c-a1d7-403e-bba0-65430c703316@github.com>
Message-ID: <WmmU2ULwE25qvt0pR9n6MEqy0JgqC5JKp65wNK7lTr0=.0e76e408-08b4-41d3-90f6-51e2d30faea8@github.com>

On Sat, 26 Mar 2022 02:38:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed the white space issue
>
> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 127:
> 
>> 125:                 System.out.println(f.getTitle() + " is getting disposed");
>> 126:                 f.dispose();
>> 127:             }
> 
> I am still not sure about this. I mean it doesn't include Window or Dialog .. 
> I think that until you can prove otherwise it should destroy only the framework, not start being part of the test.

We can dispose just the instruction frame and let the user destroy the top levels that is created by the test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7966


From aivanov at openjdk.java.net  Mon Mar 28 17:50:49 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 28 Mar 2022 17:50:49 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v7]
In-Reply-To: <WiEx5Y_45gZ6T87k39sxgvneubJBZ4mCWgoFo0Iytdc=.c4b9895f-e706-4124-91e6-2d21539d5226@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
 <WiEx5Y_45gZ6T87k39sxgvneubJBZ4mCWgoFo0Iytdc=.c4b9895f-e706-4124-91e6-2d21539d5226@github.com>
Message-ID: <s9MRoDJFKKlN11Y6s9zRxqP58FHrGsPXMrUDNW8MqoI=.7126d6ef-a741-4a9b-ba25-c258bf330a6b@github.com>

On Thu, 24 Mar 2022 03:07:28 GMT, Phil Race <prr at openjdk.org> wrote:

> I also think there's at least some analogy with OpenJFX's snap-to-pixel idea that it is sometimes better to pick a pixel and stick with it rather than span pixels and be fuzzy. Not an expert on the details of that by any means @kevinrushforth might be able to point to something if it is relevant.

I wonder how it's handled in OpenJFX. There should be the same problem with borders at fractional scales.

> If we figure this out properly it might be useful to apply to other cases rather than applying inconsistent hacks.

Yes, all the borders are affected. If you replace titled border with line border:

childPanel.setBorder(BorderFactory.createLineBorder(Color.RED, 1));

Some sides are painted with 1-pixel line, some are with 2-pixel line at 125% and 150%.

So utility methods would be useful to paint all the borders consistently.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From aivanov at openjdk.java.net  Mon Mar 28 18:05:46 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 28 Mar 2022 18:05:46 GMT
Subject: RFR: 8283642: JavaDoc of JFileChooser() need to be updated for
 default directory in Windows
In-Reply-To: <Uu1tjsYL_XXTPAzsoeF2Wz3zus9LEfxMH3jRkxr5I7o=.fe2b6c5c-f85d-4717-a146-681be1f0ed05@github.com>
References: <Uu1tjsYL_XXTPAzsoeF2Wz3zus9LEfxMH3jRkxr5I7o=.fe2b6c5c-f85d-4717-a146-681be1f0ed05@github.com>
Message-ID: <mX9bJr0-JJuIrZqQ5r_sMPSAX8aa_39X30I3K3HkV88=.21015f7b-db88-4c69-989c-d14e5f053266@github.com>

On Mon, 28 Mar 2022 07:34:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Default directory name has changed from "My Documents" to "Documents" in recent WIndows version, so javadoc needs to be updated.

Looks good to me.

I think it doesn't require a CSR, it just updates the name of the default folder on Windows which changed its name.

-------------

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7983


From duke at openjdk.java.net  Mon Mar 28 18:18:43 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Mon, 28 Mar 2022 18:18:43 GMT
Subject: RFR: 8024624: [TEST_BUG] [macosx] CTRL+RIGHT(LEFT) doesn't move
 selection on next cell in JTable on Aqua L&F [v2]
In-Reply-To: <fbI4kcxeYJ4ItqjbmcaFd7sW1PUdMGkbhcp-VCSFGTo=.15f59fd9-2b55-46ee-be61-68dae628d898@github.com>
References: <LdWWDPfwqpCC-_EBaYQLX4rFIyV9FLAG5ugIJb0ruI4=.bc296640-5df9-41a1-b857-14f334c1be8e@github.com>
 <euSIvXa4E3AN7zAwwJtcrRKViubhVvKosTMgpEJ72FY=.546f4164-50b8-4890-ab57-d59feeaf723c@github.com>
 <fbI4kcxeYJ4ItqjbmcaFd7sW1PUdMGkbhcp-VCSFGTo=.15f59fd9-2b55-46ee-be61-68dae628d898@github.com>
Message-ID: <cnyMM_jj2Bb8-rvYWjuu6dqMAt54zWyNswUHQwZYjR8=.700b922b-854c-49fa-9581-879e5f74f0c8@github.com>

On Mon, 28 Mar 2022 07:49:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> BTW why this PR is in the draft state?

This PR was in draft while I was learning about the correct process to convert a test. I just made the branch ready for review again, thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7792


From achung at openjdk.java.net  Mon Mar 28 18:35:54 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 28 Mar 2022 18:35:54 GMT
Subject: Integrated: 8280400: JDK 19 L10n resource files update - msgdrop 10
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <Gltjkc_Ybexl1S5THR_ItVyUAyld7nfA_h8fTuf8qqQ=.875739c6-22bf-4338-8e20-3e6e1b090140@github.com>

On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung <achung at openjdk.org> wrote:

> msg drop for jdk19, Mar 9, 2022

This pull request has now been integrated.

Changeset: c0aecd15
Author:    Alisen Chung <achung at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c0aecd15ae8d7abf37901f785fccaff2317c3b23
Stats:     11316 lines in 139 files changed: 9124 ins; 1252 del; 940 mod

8280400: JDK 19 L10n resource files update - msgdrop 10

Reviewed-by: naoto, kizune

-------------

PR: https://git.openjdk.java.net/jdk/pull/7765


From duke at openjdk.java.net  Mon Mar 28 18:57:45 2022
From: duke at openjdk.java.net (lukeu)
Date: Mon, 28 Mar 2022 18:57:45 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v7]
In-Reply-To: <-Aqq6KW5o6S5kuVHiaIQFW_T9OGYEqZlZhx73mF1um4=.19672f5b-a199-451a-b90f-821b7f9b2390@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
 <-Aqq6KW5o6S5kuVHiaIQFW_T9OGYEqZlZhx73mF1um4=.19672f5b-a199-451a-b90f-821b7f9b2390@github.com>
Message-ID: <xjANKfl8D096zVW2ZY4eCJNKBgzPO9wowcXVhA-aZs8=.175efdfd-3bee-44e6-813e-9be349ed3e88@github.com>

On Sun, 27 Mar 2022 03:02:55 GMT, Phil Race <prr at openjdk.org> wrote:

> So perhaps, this needs real printer testing printing to a real printer. Or may be more than one.

I have an HP OfficeJet Pro, and happy to print the odd test manually if it would help increase coverage. If so, just let me know when the code in the branch is ready for testing this way.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From duke at openjdk.java.net  Mon Mar 28 19:17:43 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Mon, 28 Mar 2022 19:17:43 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v5]
In-Reply-To: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
Message-ID: <9wbkCbgcz1b-wInMKMu_ZWDSjhMuynEDmCa0YLR8-N4=.ace0dfde-01f7-4c28-a6a4-16d6edbf2ee9@github.com>

> Previously while tabbing through the JTable cell, the cell highlighter/focus ring was not visible against the selection background. 
> 
> Changes are made to Aqua LAF to derive a brighter focus ring color by changing hue, saturation and brightness of selection background color so that it is visible while tabbing through `JTable` cells. A new method is added for this purpose which takes in `selectionBackground` color, does the hue, saturation and brightness manipulation and returns a new focus ring color. There are edge cases where the HSB transformation does not yield the right focus ring color, for these cases a default color is returned that is different and can be seen against the `selectionBackground`.
> 
> **Edge Cases**
> **Selection Background**     -----       **Returned Focus Ring Color**
> - White/ Black                        ----->          Gray
> 
> - Shade of Gray 
> towards white (r=g=b >= 128)  ----->      Black
> 
> - Shade of Gray 
> towards Black (r=g=b < 128)    ------>     White
> 
> The following HSB chart was used [Chart Link](https://codepen.io/HunorMarton/details/eWvewo), to determine the best hue, saturation offsets in deriveContrastFocusRing method.
> 
> A test case is added to compare the RGB difference between the original focus ring color & selection background and the brighter focus ring color & selection background.
> 
> PS: The native L&F (Mac OS) and Swing L&F for JTable cell tabbing differs (on native tables the cell background turns white on focus with a cell focus ring). Since the background for Swing tables can be set by users and also overridden by subclassing `DefaultTableCellRenderer`, and to adhere to current implementation of Swing, the cell background changes are not incorporated. Only the Focus Ring/ Cell Highlighter is made more prominent against the selection background.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  updated deriveContrastFocusRing method

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7768/files
  - new: https://git.openjdk.java.net/jdk/pull/7768/files/d32560ce..c71358dd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7768&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7768&range=03-04

  Stats: 70 lines in 2 files changed: 7 ins; 41 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7768/head:pull/7768

PR: https://git.openjdk.java.net/jdk/pull/7768


From duke at openjdk.java.net  Mon Mar 28 19:40:46 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Mon, 28 Mar 2022 19:40:46 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v3]
In-Reply-To: <oleoSKnRqVqnMj0DEkQ6apx-h5L8QJNzc1knyecRByQ=.ee2ad7f0-f54b-4326-b297-b89dc157ed63@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>
 <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>
 <oAZ5tpWpksvN6sfEYoblyucXf_EqcxKAIiVvkvIugjU=.a10e37ec-b8e8-4ac3-9faf-f2a8d85189af@github.com>
 <r9ujiKOC7dRsKCLNjUEt-V8mCstzXKJLFPRQ1O6kqKs=.2b96988b-85c6-45d5-9d95-2e0112b458fb@github.com>
 <AUeNFfcZNdDhRKJExOY7lT7_eG07ZQ_E124iHS_oiVI=.af2824b3-dc46-4318-92c3-27a861269339@github.com>
 <0U4ZvK_ui_ieG7pPZAdhL1AyrJYQNqT0A_HRJIE8InQ=.26f7a810-a6a0-47d0-99d9-e2ffcfebe596@github.com>
 <ML4CSxlvMzInAbk9K0LicDa--V4QlgiUzzL1u7XkJ0s=.d8c7a73c-402a-4813-8fc6-faf9fd07745a@github.com>
 <9-KCaxc5kvdWS_6nETGIRiJgbTEWTWEPxmKT5JHSphw=.0bf35082-2b55-4cfd-bc7a-636a6d7a721a@github.com>
 <fYlGXZDTHTU5qaTisZmz9LLOKG7ShMugqXOMGDmiBPY=.b43629cd-7474-48a9-9e0f-3a9729808294@github.com>
 <-k8sDdAZltd4AcDIIOeKBcKLZ4q9XuTs6sT
 5Mmg2Q9I=.025a647c-34a7-478b-912d-7bfd4a7473b4@github.com>
 <AI90_XpQ47CeM9u1p7brUJMBFddpJgfVXFfBZIYtGfw=.7489df4f-b643-4d9e-b1dd-b15ba1b6a1ad@github.com>
 <RkgzdiaxcFiGijoKtrGci5FPKKcJU7d8vDLBdt1Rftk=.88653824-bf2f-4f5b-9c69-bbb536e49ee0@github.com>
 <gWFZ-lD8CQMjC69_dKMfB7F8a_4ZxUGlWwlUeAwCYlU=.546f5569-0309-45ce-8228-000e56dbbe66@github.com>
 <iyGfHY06FwqKUuJzNQlzG7CvXV9UZtQv0l3RhWUK2RQ=.cdb558c5-1983-4678-b299-35386cb3434a@github.com>
 <K80e0S6-JthHc7DhsDV3BQePXNNEesqd_y1uF9ecLWI=.03e52bae-752b-407c-be5d-ce98c47a83c4@github.com>
 <HRR-kzpsYhfv5i3XdtQokkw4cjUl9fwxTPUlfeHSvC0=.c48b8a56-0dfc-4207-bf3b-9302b5728301@github.com>
 <oleoSKnRqVqnMj0DEkQ6apx-h5L8QJNzc1knyecRByQ=.ee2ad7f0-f54b-4326-b297-b89dc157ed63@github.com>
Message-ID: <yUYvw-aUQe7ZEunFWC65Okg4Ujd4ndCHrFi2rOV971Y=.dafa0b73-9a26-4060-b38b-c80aca567cd7@github.com>

On Mon, 28 Mar 2022 06:31:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> @prsadhuk Cell Focus ring color does not change with highlight color settings. Tested for following cases -
>> 
>> <img width="1060" alt="image" src="https://user-images.githubusercontent.com/95945681/160217226-7d4236c7-1d3e-4062-8fad-974a13374624.png">
>
> In my testing in osx10.15 with your fix, I see focus ring is following highlight color and not accent color...did you modify anything in your fix?
> <img width="688" alt="Screenshot 2022-03-28 at 11 52 09 AM" src="https://user-images.githubusercontent.com/43534309/160338556-117c8e9b-4e78-4368-8040-dfca1d82e1ab.png">

@prsadhuk I have pushed latest changes related to AquaLookAndFeel.java file only. The CSystemColors.m is not checked-in because of [selectedContentBackgroundColor](https://developer.apple.com/documentation/appkit/nscolor/2998830-selectedcontentbackgroundcolor) type property build issues. 


> In my testing in osx10.15 with your fix, I see focus ring is following highlight color and not accent color...did you modify anything in your fix? <img alt="Screenshot 2022-03-28 at 11 52 09 AM" width="688" src="https://user-images.githubusercontent.com/43534309/160338556-117c8e9b-4e78-4368-8040-dfca1d82e1ab.png">

For this scenario, wanted to verify if the **selectionBackground** color in AquaLookAndFeel is explicitly set to green?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From aivanov at openjdk.java.net  Mon Mar 28 19:53:47 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 28 Mar 2022 19:53:47 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v5]
In-Reply-To: <R_1jOKb6_npdChw-ROTsoIDsO8hNSjkJGrUwKO-E9c0=.46a7974b-d23e-4873-8042-4ffe1076c91e@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <ufxC9R6S5huL3GtQJ5G2-ev-ViVOhgXGYV3OwQtI35k=.8b695e80-9d9d-4956-babc-e6be6d69b641@github.com>
 <P5QO9YcTiVM_W9Su3IgsY0cSQAxI42svDRdIwLWYSYk=.79627a3a-e218-4a4f-b7e2-f1ef1e67cfda@github.com>
 <hElMv9NoyfrWE5wX0TfcufnMZnNXprwYMlW9p05Tu4g=.ebdae3db-b911-43e1-94a8-c6bca773063d@github.com>
 <R_1jOKb6_npdChw-ROTsoIDsO8hNSjkJGrUwKO-E9c0=.46a7974b-d23e-4873-8042-4ffe1076c91e@github.com>
Message-ID: <sVSCq9-MFy6XxvwvtkGCXvE0tg18vQKVPwYrjcmnZ_Y=.1212d88e-6d35-4e3c-9a57-bf4f98b73161@github.com>

On Fri, 25 Mar 2022 06:48:22 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> It seems to me that as I mentioned there's at least a possibility that the image actually is loaded. This thread being interrupted doesn't stop the Media loading threads.
>> 
>> Since there's only one image for this id, LOADING and COMPLETE ought to be
>> mutually exclusive. In fact I'd expect only one of the flags to be set.
>> 
>> So I can I suppose see the logic that this API returning ABORTED instead of LOADING
>> makes sense, but that is because this method removes it from the tracker ..
>> 
>> So I guess I can live with it .. especially since I think this an unlikely scenario.
>> 
>> I can see both points of view on whether interrupted is needed.
>> I'd be inclined to keep it since then you can PROVE that there's a change of behaviour only if interrupted.
>
> There is a change of Behavior if its interrupted, for Not-Interrupted case the result would be ERRORED for url link and COMPLETE for local Image, but for Interrupted case the result would be LOADING for both, which we are changing to ABORTED.

> It seems to me that as I mentioned there's at least a possibility that the image actually is loaded. This thread being interrupted doesn't stop the Media loading threads.

No, it doesn't.

>Since there's only one image for this id, LOADING and COMPLETE ought to be
mutually exclusive. In fact I'd expect only one of the flags to be set.

Right. At least I came to this conclusion: only one of the status constants is used although they're treated like flags in the code.

> So I can I suppose see the logic that this API returning ABORTED instead of LOADING
makes sense, but that is because this method removes it from the tracker ..

Since the image is removed from MediaTracker, it cannot update its status even if loading completes at a later time. This is why I think the API should return `ABORTED` instead of `LOADING`.


> ?for Not-Interrupted case the result would be ERRORED for url link and COMPLETE for local Image,

Why? It could be `COMPLETE` for either. If the image from the URL is loaded successfully, its status will be `COMPLETE`.

> but for Interrupted case the result would be LOADING for both, which we are changing to ABORTED.

Again, not necessarily. In the test, the thread is interrupted before the image is added to MediaTracker. As soon as `waitForID` is called, it immediately throws `InterruptedException`. This is why the image status is likely to be `LOADING`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7754


From duke at openjdk.java.net  Mon Mar 28 20:30:18 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Mon, 28 Mar 2022 20:30:18 GMT
Subject: RFR: 8283803 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/PrintGlyphVectorTest.java and fix test
Message-ID: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>

Fixed the following issue.
1) Removed yes/no since test was failing due to "Parser error due to yesno in @run main/manual=yesno"
2) After removing yes/no test run( just shows the UI and gets dispose immediately). User cannot interact with the test UI and mark the test pass or failed. 
So added Pass and Fail button to mark the test result.
3) Added timeout if in case user does not interact with the test UI.

@shurymury 
@aivanov-jdk

-------------

Commit messages:
 - 8283803 : Remove jtreg tag manual=yesno for java/awt/print/PrinterJob/PrintGlyphVectorTest.java and fix test

Changes: https://git.openjdk.java.net/jdk/pull/8004/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8004&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283803
  Stats: 128 lines in 1 file changed: 67 ins; 5 del; 56 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8004.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8004/head:pull/8004

PR: https://git.openjdk.java.net/jdk/pull/8004


From aivanov at openjdk.java.net  Mon Mar 28 20:31:48 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 28 Mar 2022 20:31:48 GMT
Subject: RFR: 8283700: Add final or sealed modifier to appropriate java.awt
 API classes
In-Reply-To: <ACVjMBKNkkTQlSh3-PKmvc_Nlr6kIWZpuBb4D9WsNBs=.ef511416-40f1-428d-abd8-1ddf76142174@github.com>
References: <ACVjMBKNkkTQlSh3-PKmvc_Nlr6kIWZpuBb4D9WsNBs=.ef511416-40f1-428d-abd8-1ddf76142174@github.com>
Message-ID: <WFfU8uxp2XIwX0M4wQxYmrqvC2g9K1RKs7LYkYKyfBo=.e7326655-a18d-4208-8416-c2334b2fa233@github.com>

On Mon, 28 Mar 2022 16:30:50 GMT, Phil Race <prr at openjdk.org> wrote:

> JDK 17 delivered JEP 409: Sealed Classes : https://openjdk.java.net/jeps/409
> In essence this JEP allows a class to limit which classes can subclass it.
> If a class has no subclasses and cannot be subclassed outside the JDK it can also be made final.
> Suitable classes across the JDK are being retro-fitted to be sealed (or made final) where it can be done compatibly.
> This fix takes care of several AWT classes which were identified.
> If later we need to remove sealed or make a class non-final that will also be a compatible change,
> so we aren't locking ourselves into this.
> 
> All our automated regression tests - plus JCK tests have been run.
> 
> This will require a CSR

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7998


From serb at openjdk.java.net  Mon Mar 28 20:42:41 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 28 Mar 2022 20:42:41 GMT
Subject: RFR: 8283700: Add final or sealed modifier to appropriate java.awt
 API classes
In-Reply-To: <ACVjMBKNkkTQlSh3-PKmvc_Nlr6kIWZpuBb4D9WsNBs=.ef511416-40f1-428d-abd8-1ddf76142174@github.com>
References: <ACVjMBKNkkTQlSh3-PKmvc_Nlr6kIWZpuBb4D9WsNBs=.ef511416-40f1-428d-abd8-1ddf76142174@github.com>
Message-ID: <05Rv443XglP2R1T7wjozkdprfNb0QlNx_81iPQFttVs=.89d94f2a-ea93-4145-99df-1de152aae06b@github.com>

On Mon, 28 Mar 2022 16:30:50 GMT, Phil Race <prr at openjdk.org> wrote:

> JDK 17 delivered JEP 409: Sealed Classes : https://openjdk.java.net/jeps/409
> In essence this JEP allows a class to limit which classes can subclass it.
> If a class has no subclasses and cannot be subclassed outside the JDK it can also be made final.
> Suitable classes across the JDK are being retro-fitted to be sealed (or made final) where it can be done compatibly.
> This fix takes care of several AWT classes which were identified.
> If later we need to remove sealed or make a class non-final that will also be a compatible change,
> so we aren't locking ourselves into this.
> 
> All our automated regression tests - plus JCK tests have been run.
> 
> This will require a CSR

Marked as reviewed by serb (Reviewer).

I wonder do we have some javac checks which may show some warnings related to these updated classes like not all subclasses are covered by the switch/unnecessary default branch/etc?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7998


From serb at openjdk.java.net  Mon Mar 28 20:43:39 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 28 Mar 2022 20:43:39 GMT
Subject: RFR: 8224977: [macos] On AquaLookAndFeel,
 Iconified JInternalFrame does not restore when Control + F5 is used.
In-Reply-To: <wEx7_jcEbMONzw6NGV_BjDuZ01piwdRsrrhzhKBIKbw=.5bd35640-747b-45c9-8c1d-24daa377b056@github.com>
References: <wEx7_jcEbMONzw6NGV_BjDuZ01piwdRsrrhzhKBIKbw=.5bd35640-747b-45c9-8c1d-24daa377b056@github.com>
Message-ID: <iYoD5QO79ZeEqAQ5oNT-cI9Mvyo_0RTLtsg9SZnE3hA=.89af40d6-2c64-4244-abc1-357e1fc75389@github.com>

On Mon, 28 Mar 2022 08:44:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> test/jdk/javax/swing/JInternalFrame/Test6325652.java test was failing in macos in Aqua L&F due to nonsupport in macos of such shortcuts Ctrl+F5 to restore or Ctrl+F9 to iconify. Keyboard->Shortcut in macos System->Preference do not have these shortcut usage.
> https://docs.oracle.com/javase/tutorial/uiswing/components/internalframe.html also does not talk of these shortcut support as standard.
> So, removed this test from macos run.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7985


From aivanov at openjdk.java.net  Mon Mar 28 20:46:50 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 28 Mar 2022 20:46:50 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v7]
In-Reply-To: <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
Message-ID: <p97MV_wi1XUaaL_EYYIvEEshra5LLMK1YAuLHOC-kOw=.6ac58b24-f62b-4207-a725-bb464434d5c4@github.com>

On Wed, 23 Mar 2022 18:24:05 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   scale stroke width at higher scalings

What if we don't reset the scale to 1.0 and use a thicker stroke to draw rectangles/lines but set the graphics scale to `floor(getCurrentScale())` instead?

Dealing with the coordinates could be trickier though.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From forax at openjdk.java.net  Mon Mar 28 20:58:53 2022
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 28 Mar 2022 20:58:53 GMT
Subject: RFR: 8283700: Add final or sealed modifier to appropriate java.awt
 API classes
In-Reply-To: <05Rv443XglP2R1T7wjozkdprfNb0QlNx_81iPQFttVs=.89d94f2a-ea93-4145-99df-1de152aae06b@github.com>
References: <ACVjMBKNkkTQlSh3-PKmvc_Nlr6kIWZpuBb4D9WsNBs=.ef511416-40f1-428d-abd8-1ddf76142174@github.com>
 <05Rv443XglP2R1T7wjozkdprfNb0QlNx_81iPQFttVs=.89d94f2a-ea93-4145-99df-1de152aae06b@github.com>
Message-ID: <hdbGSlhfkon0Rz4CY4PNt2i1iuqEMDcLYfvk-VmWlLA=.6b53f5d1-9781-4971-b1f6-09899d99c1da@github.com>

On Mon, 28 Mar 2022 20:39:26 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> JDK 17 delivered JEP 409: Sealed Classes : https://openjdk.java.net/jeps/409
>> In essence this JEP allows a class to limit which classes can subclass it.
>> If a class has no subclasses and cannot be subclassed outside the JDK it can also be made final.
>> Suitable classes across the JDK are being retro-fitted to be sealed (or made final) where it can be done compatibly.
>> This fix takes care of several AWT classes which were identified.
>> If later we need to remove sealed or make a class non-final that will also be a compatible change,
>> so we aren't locking ourselves into this.
>> 
>> All our automated regression tests - plus JCK tests have been run.
>> 
>> This will require a CSR
>
> I wonder do we have some javac checks which may show some warnings related to these updated classes like not all subclasses are covered by the switch/unnecessary default branch/etc?

@mrserb, you mean to detect that you can not add a new subclass without breaking the source backward compatibility.
You can add a test that switch over all the cases with no "default", if a new subclass is added, the test will not compile anymore.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7998


From kcr at openjdk.java.net  Mon Mar 28 21:30:16 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 28 Mar 2022 21:30:16 GMT
Subject: RFR: 8283806: [BACKOUT] JDK 19 L10n resource files update -
 msgdrop 10
In-Reply-To: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
References: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
Message-ID: <FaqSreLXyYzhr0FYhkqcq8UW9Dn8RNNX0C7kb7-RGkA=.ba08bc41-383f-4e23-8103-7f0ef391df19@github.com>

On Mon, 28 Mar 2022 21:20:00 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23.

I confirm that this is an exact backout of [JDK-8280400](https://bugs.openjdk.java.net/browse/JDK-8280400).

-------------

Marked as reviewed by kcr (Author).

PR: https://git.openjdk.java.net/jdk/pull/8005


From achung at openjdk.java.net  Mon Mar 28 21:30:15 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 28 Mar 2022 21:30:15 GMT
Subject: RFR: 8283806: [BACKOUT] JDK 19 L10n resource files update - msgdrop 10
Message-ID: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>

This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23.

-------------

Commit messages:
 - Revert "8280400: JDK 19 L10n resource files update - msgdrop 10"

Changes: https://git.openjdk.java.net/jdk/pull/8005/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8005&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283806
  Stats: 11316 lines in 139 files changed: 1252 ins; 9124 del; 940 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8005.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8005/head:pull/8005

PR: https://git.openjdk.java.net/jdk/pull/8005


From kizune at openjdk.java.net  Mon Mar 28 22:40:04 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 28 Mar 2022 22:40:04 GMT
Subject: RFR: 8283215: [macos] Screen Magnifier: Getting
 java.awt.IllegalComponentStateException when menu item is selected
Message-ID: <MIs7PdqdCMBtdSnGBjLOp2DpFNFTqoQpMj6duGyvFSs=.ed8610da-b86d-4c57-91b8-871c29000ff7@github.com>

Check parent component visibility status before asking it for its screen coordinates.

-------------

Commit messages:
 - 8283215: [macos] Screen Magnifier: Getting java.awt.IllegalComponentStateException when menu item is selected

Changes: https://git.openjdk.java.net/jdk/pull/8008/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8008&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283215
  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8008.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8008/head:pull/8008

PR: https://git.openjdk.java.net/jdk/pull/8008


From naoto at openjdk.java.net  Mon Mar 28 22:44:36 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 28 Mar 2022 22:44:36 GMT
Subject: RFR: 8283806: [BACKOUT] JDK 19 L10n resource files update -
 msgdrop 10
In-Reply-To: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
References: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
Message-ID: <jtwpNmcgdU1P5vo-z1GqeBzGlkydOcOsamki-j7cdAA=.d2087435-7f1a-4a78-b8c5-91d4577745e5@github.com>

On Mon, 28 Mar 2022 21:20:00 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23.

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8005


From achung at openjdk.java.net  Mon Mar 28 23:40:44 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 28 Mar 2022 23:40:44 GMT
Subject: Integrated: 8283806: [BACKOUT] JDK 19 L10n resource files update -
 msgdrop 10
In-Reply-To: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
References: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
Message-ID: <zrorEpgQ5H2ZmwvH02RY-vMNitbxb4vcyk7W_pXhThw=.dd16b716-2dc8-42e6-b70e-7b58196a88de@github.com>

On Mon, 28 Mar 2022 21:20:00 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23.

This pull request has now been integrated.

Changeset: 634800a5
Author:    Alisen Chung <achung at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/634800a536e7f9d148a4caa2663a60a2c5fc4929
Stats:     11316 lines in 139 files changed: 1252 ins; 9124 del; 940 mod

8283806: [BACKOUT] JDK 19 L10n resource files update - msgdrop 10

Reviewed-by: kcr, naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/8005


From prr at openjdk.java.net  Tue Mar 29 01:24:46 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 29 Mar 2022 01:24:46 GMT
Subject: RFR: 8283700: Add final or sealed modifier to appropriate java.awt
 API classes
In-Reply-To: <ACVjMBKNkkTQlSh3-PKmvc_Nlr6kIWZpuBb4D9WsNBs=.ef511416-40f1-428d-abd8-1ddf76142174@github.com>
References: <ACVjMBKNkkTQlSh3-PKmvc_Nlr6kIWZpuBb4D9WsNBs=.ef511416-40f1-428d-abd8-1ddf76142174@github.com>
Message-ID: <niHB6JyG3cnfHIfVLFCMJ2RvaQ1jLRtK_PqRyRgUohM=.863d323a-65d2-4fa6-ba62-8156bbdf139b@github.com>

On Mon, 28 Mar 2022 16:30:50 GMT, Phil Race <prr at openjdk.org> wrote:

> JDK 17 delivered JEP 409: Sealed Classes : https://openjdk.java.net/jeps/409
> In essence this JEP allows a class to limit which classes can subclass it.
> If a class has no subclasses and cannot be subclassed outside the JDK it can also be made final.
> Suitable classes across the JDK are being retro-fitted to be sealed (or made final) where it can be done compatibly.
> This fix takes care of several AWT classes which were identified.
> If later we need to remove sealed or make a class non-final that will also be a compatible change,
> so we aren't locking ourselves into this.
> 
> All our automated regression tests - plus JCK tests have been run.
> 
> This will require a CSR

I *think* Sergey is asking how javac identifies classes that are sub-classing the sealed class but not listed in the permits clause ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7998


From darcy at openjdk.java.net  Tue Mar 29 01:40:53 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 29 Mar 2022 01:40:53 GMT
Subject: RFR: 8283700: Add final or sealed modifier to appropriate java.awt
 API classes
In-Reply-To: <ACVjMBKNkkTQlSh3-PKmvc_Nlr6kIWZpuBb4D9WsNBs=.ef511416-40f1-428d-abd8-1ddf76142174@github.com>
References: <ACVjMBKNkkTQlSh3-PKmvc_Nlr6kIWZpuBb4D9WsNBs=.ef511416-40f1-428d-abd8-1ddf76142174@github.com>
Message-ID: <F-lw9G7MXxPQxlTUcn15uBqZNp4mJFtWHcZOIm0ii9E=.cd00a549-f442-47b0-aa32-641e67dbd3b9@github.com>

On Mon, 28 Mar 2022 16:30:50 GMT, Phil Race <prr at openjdk.org> wrote:

> JDK 17 delivered JEP 409: Sealed Classes : https://openjdk.java.net/jeps/409
> In essence this JEP allows a class to limit which classes can subclass it.
> If a class has no subclasses and cannot be subclassed outside the JDK it can also be made final.
> Suitable classes across the JDK are being retro-fitted to be sealed (or made final) where it can be done compatibly.
> This fix takes care of several AWT classes which were identified.
> If later we need to remove sealed or make a class non-final that will also be a compatible change,
> so we aren't locking ourselves into this.
> 
> All our automated regression tests - plus JCK tests have been run.
> 
> This will require a CSR

> I _think_ Sergey is asking how javac identifies classes that are sub-classing the sealed class but not listed in the permits clause ?

If a sealed class does not have a permits clause, the allowed subclasses must be in the same file as the class in question, e.g. nested classes that were also subclasses or auxiliary classes. This is described in the JEP.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7998


From serb at openjdk.java.net  Tue Mar 29 02:15:36 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 29 Mar 2022 02:15:36 GMT
Subject: RFR: 8273355: Flickering on tooltip appearance IntelliJ IDEA
 2021.2.1 [v3]
In-Reply-To: <y7a-NyIztP3YHPLSjFTSk2fVEZ7jFLwFrj40hJgmZ8M=.a93db6c4-ddd6-472f-bd5d-6e2170610ad1@github.com>
References: <_Q4d9YdOccAdjO6LsIlbIOt55Bn7PGAz3-NmVBF2vLU=.01b029e3-f88f-4b6b-b12b-3509f9dcd486@github.com>
 <y7a-NyIztP3YHPLSjFTSk2fVEZ7jFLwFrj40hJgmZ8M=.a93db6c4-ddd6-472f-bd5d-6e2170610ad1@github.com>
Message-ID: <-y6lWGz7FlXOSPP1RctiKmmEbuV5s51vsSy9SYEBChc=.29b0ed17-1cbf-4b50-895c-8b0624e6476b@github.com>

On Fri, 25 Mar 2022 11:27:36 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Used setOpaque() method to set correct background of platform window
>> Extracted setting background to the particular method in PlatformWindow. Provided appropriate implementation in CPlatformWindow.
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8273355: Flickering on tooltip appearance IntelliJ IDEA 2021.2.1
>   
>   Copyright update

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7931


From serb at openjdk.java.net  Tue Mar 29 02:26:38 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 29 Mar 2022 02:26:38 GMT
Subject: RFR: 8283700: Add final or sealed modifier to appropriate java.awt
 API classes
In-Reply-To: <ACVjMBKNkkTQlSh3-PKmvc_Nlr6kIWZpuBb4D9WsNBs=.ef511416-40f1-428d-abd8-1ddf76142174@github.com>
References: <ACVjMBKNkkTQlSh3-PKmvc_Nlr6kIWZpuBb4D9WsNBs=.ef511416-40f1-428d-abd8-1ddf76142174@github.com>
Message-ID: <7olEdCJmrv6c_yBoR_fbSdvBKzJNTRxMFfMyb8dQm2g=.4693424b-9a97-4ddd-8aea-18091069dc85@github.com>

On Mon, 28 Mar 2022 16:30:50 GMT, Phil Race <prr at openjdk.org> wrote:

> JDK 17 delivered JEP 409: Sealed Classes : https://openjdk.java.net/jeps/409
> In essence this JEP allows a class to limit which classes can subclass it.
> If a class has no subclasses and cannot be subclassed outside the JDK it can also be made final.
> Suitable classes across the JDK are being retro-fitted to be sealed (or made final) where it can be done compatibly.
> This fix takes care of several AWT classes which were identified.
> If later we need to remove sealed or make a class non-final that will also be a compatible change,
> so we aren't locking ourselves into this.
> 
> All our automated regression tests - plus JCK tests have been run.
> 
> This will require a CSR

Thank you for clarification

-------------

PR: https://git.openjdk.java.net/jdk/pull/7998


From prr at openjdk.java.net  Tue Mar 29 02:36:41 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 29 Mar 2022 02:36:41 GMT
Subject: RFR: 8283700: Add final or sealed modifier to appropriate java.awt
 API classes
In-Reply-To: <ACVjMBKNkkTQlSh3-PKmvc_Nlr6kIWZpuBb4D9WsNBs=.ef511416-40f1-428d-abd8-1ddf76142174@github.com>
References: <ACVjMBKNkkTQlSh3-PKmvc_Nlr6kIWZpuBb4D9WsNBs=.ef511416-40f1-428d-abd8-1ddf76142174@github.com>
Message-ID: <NnZZDD2DcEpYqodBUKTMAuGTRYh1ndd8p2SRlxpT2S8=.620efdf7-3af3-4e4d-a110-6d13599eddf4@github.com>

On Mon, 28 Mar 2022 16:30:50 GMT, Phil Race <prr at openjdk.org> wrote:

> JDK 17 delivered JEP 409: Sealed Classes : https://openjdk.java.net/jeps/409
> In essence this JEP allows a class to limit which classes can subclass it.
> If a class has no subclasses and cannot be subclassed outside the JDK it can also be made final.
> Suitable classes across the JDK are being retro-fitted to be sealed (or made final) where it can be done compatibly.
> This fix takes care of several AWT classes which were identified.
> If later we need to remove sealed or make a class non-final that will also be a compatible change,
> so we aren't locking ourselves into this.
> 
> All our automated regression tests - plus JCK tests have been run.
> 
> This will require a CSR

The CSR is now ready for review : https://bugs.openjdk.java.net/browse/JDK-8283813

-------------

PR: https://git.openjdk.java.net/jdk/pull/7998


From serb at openjdk.java.net  Tue Mar 29 02:50:42 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 29 Mar 2022 02:50:42 GMT
Subject: RFR: 8283215: [macos] Screen Magnifier: Getting
 java.awt.IllegalComponentStateException when menu item is selected
In-Reply-To: <MIs7PdqdCMBtdSnGBjLOp2DpFNFTqoQpMj6duGyvFSs=.ed8610da-b86d-4c57-91b8-871c29000ff7@github.com>
References: <MIs7PdqdCMBtdSnGBjLOp2DpFNFTqoQpMj6duGyvFSs=.ed8610da-b86d-4c57-91b8-871c29000ff7@github.com>
Message-ID: <s3aIvh83P0HBrcXgzc_34_PzJOn1pLwchqBF5eEJIOM=.7e00abfb-5948-4a5f-ab05-10142a22b5df@github.com>

On Mon, 28 Mar 2022 22:31:31 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Check parent component visibility status before asking it for its screen coordinates.

src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 472:

> 470:         return invokeAndWait(new Callable<Accessible>() {
> 471:             public Accessible call() throws Exception {
> 472:                 if (parent == null || !parent.isVisible()) {

Should the `isShowing` be used here to check containers up to the top level? But I think it should be possible to create a test that may trigger an exception in `getLocationOnScreen()` after the check, so maybe try/catch will be a better approach.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8008


From duke at openjdk.java.net  Tue Mar 29 04:07:41 2022
From: duke at openjdk.java.net (Dmitry Kulikov)
Date: Tue, 29 Mar 2022 04:07:41 GMT
Subject: RFR: 8282863:
 java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on
 Windows 10 with HiDPI screen [v2]
In-Reply-To: <p01bGSKB-1xZPQ6J3MNai2gorrAcGkSs1zmRFohyW7E=.16c08e60-0681-4b95-b721-696e5258f720@github.com>
References: <SogRHLx2pQzRLxpE6FW6BAjwW0qaawCm-A6Ff4Z3N54=.233a4715-0ec7-491a-ba75-c7c3f16b9ee8@github.com>
 <p01bGSKB-1xZPQ6J3MNai2gorrAcGkSs1zmRFohyW7E=.16c08e60-0681-4b95-b721-696e5258f720@github.com>
Message-ID: <JoGuJEOy2Lg2r6O6DSsj84Cmh1a2U6p91uNZvZmTnQ4=.88d6882d-0fa2-4d91-885a-eb6d10c9d27d@github.com>

On Mon, 28 Mar 2022 04:29:24 GMT, Dmitry Kulikov <duke at openjdk.java.net> wrote:

>> Hello,
>> Please review this fix for JDK-8282863.
>> 
>> The failing `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test basically checks that full-screen window remains full-screen when a display mode change occurs. It has been introduced in JDK-8211999, which also contains numerous fixes for HiDPI displays. In particular, JDK-8211999 changed the code of `Win32GraphicsDevice.setDisplayMode()` so that it uses screen dimensions in user space instead of device space, which is correct. However, if the display mode change incurs display scaling change, as it has been observed on Windows 10 laptop with HiDPI screen, the method used for obtaining screen bounds in user space returns incorrect values under certain conditions.
>> 
>> The issue is reproducible on Windows 10, when resolution of the primary screen is higher than 1024x768 with scaling greater than 100%. Resolution and scaling of secondary screen(s) is irrelevant. I used a laptop with 2160x1350 display resolution and scaling set to 150%. When the `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test is run with these initial conditions, roughly the following happens:
>> 
>> 1. `java.awt.Frame` is created and set as full-screen.
>> 2. `Win32GraphicsDevice.setDisplayMode()` is called to change screen resolution from 2160x1350 to 1024x768.
>> 3. `Win32GraphicsDevice.configDisplayMode()` call immediately changes the display resolution to 1024x768, which also incurs the immediate display scaling change from 150% to 100%.
>> 4. Inside the `Win32GraphicsDevice.setDisplayMode()` screen bounds in user space are obtained via `Win32GraphicsConfig.getBounds()`:
>> 5. In the native code of `Win32GraphicsConfig.getBounds()` new screen bounds in device space (1024x768) are correctly obtained via `MonitorBounds()`.
>> 6. Then screen bounds are converted to user space by applying **scaling factors, which are not yet updated and correspond to previous display mode**. In our case, 1024x768 is scaled down by 150% and becomes 683x512.
>> 7. Back in `Win32GraphicsDevice.setDisplayMode()` full-screen window bounds are set to incorrectly scaled 683x512 instead of 1024x768.
>> 8. After returning from `Win32GraphicsDevice.setDisplayMode()` the test waits 4 seconds.
>> 9. `WM_DISPLAYCHANGE` message is received and processed, followed by `WM_DPICHANGED`, which updates the scaling factors used by `Win32GraphicsConfig.getBounds()` to the correct value of 100%.
>> 10. After 4 seconds test wakes up and obtains screen bounds in user space by calling `Win32GraphicsConfig.getBounds()`, which now correctly returns 1024x768.
>> 11. Test compares full-screen window bounds with screen bounds, and fails with `java.lang.RuntimeException: width is wrong` as 683 is not equal to 1024 ? 30 pixels.
>> 
>> Proposed fix adds a `Win32GraphicsDevice.initScaleFactors()` call to `Win32GraphicsDevice.setDisplayMode()` code, between calling `Win32GraphicsDevice.configDisplayMode()` and `Win32GraphicsConfig.getBounds()`. This updates the scaling factors without waiting for `WM_DISPLAYCHANGE` or `WM_DPICHANGED`, `Win32GraphicsConfig.getBounds()` returns correctly scaled screen bounds in user space, and full-screen window remains correctly sized after display mode change.
>> 
>> I've run tests from `jdk_awt` group on Windows 10 using a laptop with the same settings that caused the issue (primary screen with 2160x1350 resolution and 150% scaling), and applying the fix did not introduce any new test failures.
>
> Dmitry Kulikov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen
>  - Revert "8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen"
>    
>    This reverts commit 23b40af8de9df4db9a1cc0137c0e875cf6595190.

Hello!

@mrserb thank you for pointing JDK-8232200 out. A similar solution can be implemented in this case, and it covers the resolution change by the user, which I've successfully tested. It still (sort of) fails when the user changes screen scaling only, without changing the resolution. In my tests `WM_DPICHANGED` message always contained suggested window rect that does not correspond to actual screen bounds at updated scaling, which caused our full-screen window to shrink. However I believe at this point that it's not a Java bug:

* if we follow the code, the suggested new window size & position from `WM_DPICHANGED` is used exactly as per [Microsoft's documentation](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged#remarks);
* some other non-Java windows show similar behaviour when screen scaling is changed.

@prrace thank you for your feedback, could you please take a look at the updated fix? 

> causes Win32GraphicsDevice.displayChanged() to be called, which makes the update, but too late.
> Is there anything else that method does which is being done too late ?

None that I can see now...

> Do we still need the call to initScaleFactors() in Win32GraphicsDevice.displayChanged() ?

Technically we did, since `displayChanged()` could have originated from sources other than `Win32GraphicsDevice.setDisplayMode()`, and `initScaleFactors()` seemed lightweight enough to be called another time from a method that is not likely to be used repeatedly. But with the updated fix there is no such duplication any more.

> And can you reduce the line length of all these comments to <= 80 chars
> PS .. can we add this bug id to the @bug list of the test ?

Done and done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7835


From aghaisas at openjdk.java.net  Tue Mar 29 04:17:40 2022
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 29 Mar 2022 04:17:40 GMT
Subject: RFR: 8273355: Flickering on tooltip appearance IntelliJ IDEA
 2021.2.1 [v3]
In-Reply-To: <y7a-NyIztP3YHPLSjFTSk2fVEZ7jFLwFrj40hJgmZ8M=.a93db6c4-ddd6-472f-bd5d-6e2170610ad1@github.com>
References: <_Q4d9YdOccAdjO6LsIlbIOt55Bn7PGAz3-NmVBF2vLU=.01b029e3-f88f-4b6b-b12b-3509f9dcd486@github.com>
 <y7a-NyIztP3YHPLSjFTSk2fVEZ7jFLwFrj40hJgmZ8M=.a93db6c4-ddd6-472f-bd5d-6e2170610ad1@github.com>
Message-ID: <ubUX1Xplq_DLS94GheFHMYgydOC2shjNkWJnF86_v_w=.4af70868-4e8d-4c18-bcc3-36a0824e60cd@github.com>

On Fri, 25 Mar 2022 11:27:36 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Used setOpaque() method to set correct background of platform window
>> Extracted setting background to the particular method in PlatformWindow. Provided appropriate implementation in CPlatformWindow.
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8273355: Flickering on tooltip appearance IntelliJ IDEA 2021.2.1
>   
>   Copyright update

The code changes look good.
All test run with OpenGL and Metal pipelines is fine.

Please see the 'Integration blocker' in Progress section of this PR above. It is ready to be pushed once that is corrected.

-------------

Marked as reviewed by aghaisas (Committer).

PR: https://git.openjdk.java.net/jdk/pull/7931


From psadhukhan at openjdk.java.net  Tue Mar 29 04:18:47 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 29 Mar 2022 04:18:47 GMT
Subject: RFR: 8283700: Add final or sealed modifier to appropriate java.awt
 API classes
In-Reply-To: <ACVjMBKNkkTQlSh3-PKmvc_Nlr6kIWZpuBb4D9WsNBs=.ef511416-40f1-428d-abd8-1ddf76142174@github.com>
References: <ACVjMBKNkkTQlSh3-PKmvc_Nlr6kIWZpuBb4D9WsNBs=.ef511416-40f1-428d-abd8-1ddf76142174@github.com>
Message-ID: <jUZY6J8WMmQ3rc18TsW2u0i-YUtMaRu622xbzIVRpoI=.e1cc147a-2a37-4f22-939b-cf5dc7a5286e@github.com>

On Mon, 28 Mar 2022 16:30:50 GMT, Phil Race <prr at openjdk.org> wrote:

> Suitable classes across the JDK are being retro-fitted to be sealed 

How does this "suitability" check done? Are these exhaustive or more awt classes will be added?
Do we need to do the same for swing classes too?

-------------

Marked as reviewed by psadhukhan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7998


From darcy at openjdk.java.net  Tue Mar 29 04:24:43 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 29 Mar 2022 04:24:43 GMT
Subject: RFR: 8283700: Add final or sealed modifier to appropriate java.awt
 API classes
In-Reply-To: <jUZY6J8WMmQ3rc18TsW2u0i-YUtMaRu622xbzIVRpoI=.e1cc147a-2a37-4f22-939b-cf5dc7a5286e@github.com>
References: <ACVjMBKNkkTQlSh3-PKmvc_Nlr6kIWZpuBb4D9WsNBs=.ef511416-40f1-428d-abd8-1ddf76142174@github.com>
 <jUZY6J8WMmQ3rc18TsW2u0i-YUtMaRu622xbzIVRpoI=.e1cc147a-2a37-4f22-939b-cf5dc7a5286e@github.com>
Message-ID: <Dy8SNbK7jNlvs2HQkxgawufNqYFLTYl2jTRivujInyg=.cb546f6b-6980-4047-b382-926d3ea9781f@github.com>

On Tue, 29 Mar 2022 04:16:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > Suitable classes across the JDK are being retro-fitted to be sealed
> 
> How does this "suitability" check done? Are these exhaustive or more awt classes will be added? Do we need to do the same for swing classes too?

I wrote an annotation processor to look for candidates to make sealed (public classes with no public or protected constructors and at least one package access constructor). Phil has filed bugs for swing (JDK-8283706) and other client areas.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7998


From psadhukhan at openjdk.java.net  Tue Mar 29 05:47:39 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 29 Mar 2022 05:47:39 GMT
Subject: RFR: 8274082 : Wrong test case name specified in jtreg run tag for
 java/awt/print/PrinterJob/SwingUIText.java
In-Reply-To: <ZCvrnk1meFmsJa3Q5hk2onn7kUQL18cxrktRywdActc=.befc4c76-c87c-4261-8888-0cee83df9a80@github.com>
References: <ZCvrnk1meFmsJa3Q5hk2onn7kUQL18cxrktRywdActc=.befc4c76-c87c-4261-8888-0cee83df9a80@github.com>
Message-ID: <Xp4l90_yicfDGRkiIsY8ogHorxMNZS4TVR7G0jet05g=.6c573c84-1b65-43e5-9280-64a4bb1b5d87@github.com>

On Thu, 24 Mar 2022 20:24:35 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> Following issues were fixed in this test 
> 1) Fixed - Parser error due to yesno in @run main/manual=yesno
> 2) Fixed Wrong test name specified in @run jtreg
> @run main/manual=yesno PrintTextTest . It should be @run main/manual=yesno SwingUIText
> 3) Instruction frame does not have 'Pass' or 'Fail' button to mark the test as Pass or Fail after verifying Text on UI and print out. 
> 4) Fixed - Test UI ( test instruction frame, UI frame and Print Dialog) just gets disposed automatically without interacting via running the test case with jtreg. 
> 
> @shurymury

I suggest you wait for the framework in PR#7966 to be reviewed and completed and use it here instead of recreating UI in each test, to maintain consistency.

-------------

Changes requested by psadhukhan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7946


From psadhukhan at openjdk.java.net  Tue Mar 29 05:49:47 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 29 Mar 2022 05:49:47 GMT
Subject: RFR: 8283803 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/PrintGlyphVectorTest.java and fix test
In-Reply-To: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
Message-ID: <wxSrx68pkw_dCtSp4APtEl-sYrGawDd5IFACdZTROUc=.6f3d6175-84d6-4c37-90f2-6db927d33142@github.com>

On Mon, 28 Mar 2022 20:23:20 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> Fixed the following issue.
> 1) Removed yes/no since test was failing due to "Parser error due to yesno in @run main/manual=yesno"
> 2) After removing yes/no test run( just shows the UI and gets dispose immediately). User cannot interact with the test UI and mark the test pass or failed. 
> So added Pass and Fail button to mark the test result.
> 3) Added timeout if in case user does not interact with the test UI.
> 
> @shurymury 
> @aivanov-jdk

I suggest you wait for the framework in PR#7966 to be reviewed and completed and use it here instead of recreating UI in each test, to maintain consistency.

-------------

Changes requested by psadhukhan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8004


From psadhukhan at openjdk.java.net  Tue Mar 29 07:26:42 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 29 Mar 2022 07:26:42 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v3]
In-Reply-To: <yUYvw-aUQe7ZEunFWC65Okg4Ujd4ndCHrFi2rOV971Y=.dafa0b73-9a26-4060-b38b-c80aca567cd7@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>
 <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>
 <oAZ5tpWpksvN6sfEYoblyucXf_EqcxKAIiVvkvIugjU=.a10e37ec-b8e8-4ac3-9faf-f2a8d85189af@github.com>
 <r9ujiKOC7dRsKCLNjUEt-V8mCstzXKJLFPRQ1O6kqKs=.2b96988b-85c6-45d5-9d95-2e0112b458fb@github.com>
 <AUeNFfcZNdDhRKJExOY7lT7_eG07ZQ_E124iHS_oiVI=.af2824b3-dc46-4318-92c3-27a861269339@github.com>
 <0U4ZvK_ui_ieG7pPZAdhL1AyrJYQNqT0A_HRJIE8InQ=.26f7a810-a6a0-47d0-99d9-e2ffcfebe596@github.com>
 <ML4CSxlvMzInAbk9K0LicDa--V4QlgiUzzL1u7XkJ0s=.d8c7a73c-402a-4813-8fc6-faf9fd07745a@github.com>
 <9-KCaxc5kvdWS_6nETGIRiJgbTEWTWEPxmKT5JHSphw=.0bf35082-2b55-4cfd-bc7a-636a6d7a721a@github.com>
 <fYlGXZDTHTU5qaTisZmz9LLOKG7ShMugqXOMGDmiBPY=.b43629cd-7474-48a9-9e0f-3a9729808294@github.com>
 <-k8sDdAZltd4AcDIIOeKBcKLZ4q9XuTs6sT
 5Mmg2Q9I=.025a647c-34a7-478b-912d-7bfd4a7473b4@github.com>
 <AI90_XpQ47CeM9u1p7brUJMBFddpJgfVXFfBZIYtGfw=.7489df4f-b643-4d9e-b1dd-b15ba1b6a1ad@github.com>
 <RkgzdiaxcFiGijoKtrGci5FPKKcJU7d8vDLBdt1Rftk=.88653824-bf2f-4f5b-9c69-bbb536e49ee0@github.com>
 <gWFZ-lD8CQMjC69_dKMfB7F8a_4ZxUGlWwlUeAwCYlU=.546f5569-0309-45ce-8228-000e56dbbe66@github.com>
 <iyGfHY06FwqKUuJzNQlzG7CvXV9UZtQv0l3RhWUK2RQ=.cdb558c5-1983-4678-b299-35386cb3434a@github.com>
 <K80e0S6-JthHc7DhsDV3BQePXNNEesqd_y1uF9ecLWI=.03e52bae-752b-407c-be5d-ce98c47a83c4@github.com>
 <HRR-kzpsYhfv5i3XdtQokkw4cjUl9fwxTPUlfeHSvC0=.c48b8a56-0dfc-4207-bf3b-9302b5728301@github.com>
 <oleoSKnRqVqnMj0DEkQ6apx-h5L8QJNzc1knyecRByQ=.ee2ad7f0-f54b-4326-b297-b89dc157ed63@github.com>
 <yUYvw-aUQe7ZEunFWC65Okg4Ujd4ndCHrFi2rOV971Y=.dafa0b73-9a26-4060-b38b-c80aca567cd7@github.com>
Message-ID: <isFfgoZsRbN_XgzjucidTow8HYtH55xM3kv9wyVUYIE=.64039678-0a22-4438-989e-cd0aac358b17@github.com>

On Mon, 28 Mar 2022 19:37:28 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> In my testing in osx10.15 with your fix, I see focus ring is following highlight color and not accent color...did you modify anything in your fix?
>> <img width="688" alt="Screenshot 2022-03-28 at 11 52 09 AM" src="https://user-images.githubusercontent.com/43534309/160338556-117c8e9b-4e78-4368-8040-dfca1d82e1ab.png">
>
> @prsadhuk I have pushed latest changes related to AquaLookAndFeel.java file only. The CSystemColors.m is not checked-in because of [selectedContentBackgroundColor](https://developer.apple.com/documentation/appkit/nscolor/2998830-selectedcontentbackgroundcolor) type property build issues. 
> 
> 
>> In my testing in osx10.15 with your fix, I see focus ring is following highlight color and not accent color...did you modify anything in your fix? <img alt="Screenshot 2022-03-28 at 11 52 09 AM" width="688" src="https://user-images.githubusercontent.com/43534309/160338556-117c8e9b-4e78-4368-8040-dfca1d82e1ab.png">
> 
> For this scenario, wanted to verify if the **selectionBackground** explicitly set to green in AquaLookAndFeel?

With latest repo and your fix, I put a debug log in deriveContrastFocusRing() and it seems to produce this output (for scenario above)

selectedBackgroundColor com.apple.laf.AquaImageFactory$SystemColorProxy[r=54,g=128,b=34]

I see, even if I change the highlight Color to blue, it does not call deriveContrastFocusRing() again and the focus ring remains green although background Color of JTable cell changes to blue

<img width="537" alt="Screenshot 2022-03-29 at 12 49 59 PM" src="https://user-images.githubusercontent.com/43534309/160556234-cf1732f3-57bd-4530-82e6-e2080e9e1551.png">
.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From avu at openjdk.java.net  Tue Mar 29 08:00:45 2022
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Tue, 29 Mar 2022 08:00:45 GMT
Subject: Integrated: 8273355: Flickering on tooltip appearance IntelliJ IDEA
 2021.2.1
In-Reply-To: <_Q4d9YdOccAdjO6LsIlbIOt55Bn7PGAz3-NmVBF2vLU=.01b029e3-f88f-4b6b-b12b-3509f9dcd486@github.com>
References: <_Q4d9YdOccAdjO6LsIlbIOt55Bn7PGAz3-NmVBF2vLU=.01b029e3-f88f-4b6b-b12b-3509f9dcd486@github.com>
Message-ID: <J2HFsk70gyz0GBvIpnqWRjykSSTRKTj3whFbWGC9osM=.513e19d6-5379-48f8-8916-a4af5e6738d7@github.com>

On Wed, 23 Mar 2022 20:01:54 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Used setOpaque() method to set correct background of platform window
> Extracted setting background to the particular method in PlatformWindow. Provided appropriate implementation in CPlatformWindow.

This pull request has now been integrated.

Changeset: 043b0a7f
Author:    Alexey Ushakov <avu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/043b0a7ffe0ae965a9b9a798f4030a494b79a961
Stats:     12 lines in 1 file changed: 11 ins; 0 del; 1 mod

8273355: Flickering on tooltip appearance IntelliJ IDEA 2021.2.1

Reviewed-by: serb, aghaisas

-------------

PR: https://git.openjdk.java.net/jdk/pull/7931


From smandalika at openjdk.java.net  Tue Mar 29 08:13:04 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Tue, 29 Mar 2022 08:13:04 GMT
Subject: RFR: 8283245: Create a test for JDK-4670319
Message-ID: <UrqPfkc5gtakuM1_5bjMxwABKOHUxG5NwTkKpjpFvIk=.3957d27d-ddbe-4aad-aefe-0a3748aca560@github.com>

Write an automated regression test for  JDK-4670319

Issue
When a JTree node is expanded or collapsed, an Accessibility PropertyChange event is fired with the old state of "collapsed" and new state of "expanded" (or vice versa). The problem is that the source of the event is the AccessibeJTree, and not the AccessibleJTreeNode. This means that an assistive technology listening to this event is unable to report to the user what node was expanded/collapsed.

Fix
Fix for [JDK-4670319](https://bugs.openjdk.java.net/browse/JDK-4670319) addresses the above issue.  When tree node is expanded/collapsed, PropertyChangeEventSource is the Node.
This review is for a test for validating the above issue.

This review is for migrating tests from a closed test suite to open.

Testing:
The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

-------------

Commit messages:
 - 8283245: Create a test for JDK-4670319

Changes: https://git.openjdk.java.net/jdk/pull/8012/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8012&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283245
  Stats: 111 lines in 1 file changed: 111 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8012.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8012/head:pull/8012

PR: https://git.openjdk.java.net/jdk/pull/8012


From avu at openjdk.java.net  Tue Mar 29 10:51:24 2022
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Tue, 29 Mar 2022 10:51:24 GMT
Subject: RFR: 8283794: CCE in XRTextRenderer.drawGlyphList and
 XRMaskFill.MaskFill
Message-ID: <GD4NAkuLptwylcQOI8VBAXXI1rY7ycgz8O2NvPmhIOc=.f2c8334e-d2eb-4717-92a1-de2f9ed301b6@github.com>

Throwing InvalidPipeException for incompatible surfaces

-------------

Commit messages:
 - 8283794: CCE in XRTextRenderer.drawGlyphList and XRMaskFill.MaskFill

Changes: https://git.openjdk.java.net/jdk/pull/8015/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8015&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283794
  Stats: 15 lines in 2 files changed: 10 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8015.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8015/head:pull/8015

PR: https://git.openjdk.java.net/jdk/pull/8015


From aivanov at openjdk.java.net  Tue Mar 29 11:09:43 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 29 Mar 2022 11:09:43 GMT
Subject: RFR: 8282863:
 java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on
 Windows 10 with HiDPI screen [v2]
In-Reply-To: <p01bGSKB-1xZPQ6J3MNai2gorrAcGkSs1zmRFohyW7E=.16c08e60-0681-4b95-b721-696e5258f720@github.com>
References: <SogRHLx2pQzRLxpE6FW6BAjwW0qaawCm-A6Ff4Z3N54=.233a4715-0ec7-491a-ba75-c7c3f16b9ee8@github.com>
 <p01bGSKB-1xZPQ6J3MNai2gorrAcGkSs1zmRFohyW7E=.16c08e60-0681-4b95-b721-696e5258f720@github.com>
Message-ID: <dz68sDXCtsfRjcyKlLsZsNqmkjGaOVrc0oxOHaVQGpk=.b151be89-a7ff-4d9e-ade6-932bdfb092d8@github.com>

On Mon, 28 Mar 2022 04:29:24 GMT, Dmitry Kulikov <duke at openjdk.java.net> wrote:

>> Hello,
>> Please review this fix for JDK-8282863.
>> 
>> The failing `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test basically checks that full-screen window remains full-screen when a display mode change occurs. It has been introduced in JDK-8211999, which also contains numerous fixes for HiDPI displays. In particular, JDK-8211999 changed the code of `Win32GraphicsDevice.setDisplayMode()` so that it uses screen dimensions in user space instead of device space, which is correct. However, if the display mode change incurs display scaling change, as it has been observed on Windows 10 laptop with HiDPI screen, the method used for obtaining screen bounds in user space returns incorrect values under certain conditions.
>> 
>> The issue is reproducible on Windows 10, when resolution of the primary screen is higher than 1024x768 with scaling greater than 100%. Resolution and scaling of secondary screen(s) is irrelevant. I used a laptop with 2160x1350 display resolution and scaling set to 150%. When the `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test is run with these initial conditions, roughly the following happens:
>> 
>> 1. `java.awt.Frame` is created and set as full-screen.
>> 2. `Win32GraphicsDevice.setDisplayMode()` is called to change screen resolution from 2160x1350 to 1024x768.
>> 3. `Win32GraphicsDevice.configDisplayMode()` call immediately changes the display resolution to 1024x768, which also incurs the immediate display scaling change from 150% to 100%.
>> 4. Inside the `Win32GraphicsDevice.setDisplayMode()` screen bounds in user space are obtained via `Win32GraphicsConfig.getBounds()`:
>> 5. In the native code of `Win32GraphicsConfig.getBounds()` new screen bounds in device space (1024x768) are correctly obtained via `MonitorBounds()`.
>> 6. Then screen bounds are converted to user space by applying **scaling factors, which are not yet updated and correspond to previous display mode**. In our case, 1024x768 is scaled down by 150% and becomes 683x512.
>> 7. Back in `Win32GraphicsDevice.setDisplayMode()` full-screen window bounds are set to incorrectly scaled 683x512 instead of 1024x768.
>> 8. After returning from `Win32GraphicsDevice.setDisplayMode()` the test waits 4 seconds.
>> 9. `WM_DISPLAYCHANGE` message is received and processed, followed by `WM_DPICHANGED`, which updates the scaling factors used by `Win32GraphicsConfig.getBounds()` to the correct value of 100%.
>> 10. After 4 seconds test wakes up and obtains screen bounds in user space by calling `Win32GraphicsConfig.getBounds()`, which now correctly returns 1024x768.
>> 11. Test compares full-screen window bounds with screen bounds, and fails with `java.lang.RuntimeException: width is wrong` as 683 is not equal to 1024 ? 30 pixels.
>> 
>> Proposed fix adds a `Win32GraphicsDevice.initScaleFactors()` call to `Win32GraphicsDevice.setDisplayMode()` code, between calling `Win32GraphicsDevice.configDisplayMode()` and `Win32GraphicsConfig.getBounds()`. This updates the scaling factors without waiting for `WM_DISPLAYCHANGE` or `WM_DPICHANGED`, `Win32GraphicsConfig.getBounds()` returns correctly scaled screen bounds in user space, and full-screen window remains correctly sized after display mode change.
>> 
>> I've run tests from `jdk_awt` group on Windows 10 using a laptop with the same settings that caused the issue (primary screen with 2160x1350 resolution and 150% scaling), and applying the fix did not introduce any new test failures.
>
> Dmitry Kulikov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen
>  - Revert "8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen"
>    
>    This reverts commit 23b40af8de9df4db9a1cc0137c0e875cf6595190.

src/java.desktop/windows/classes/sun/awt/Win32GraphicsDevice.java line 447:

> 445: 
> 446:     /**
> 447:      * Reapplies the size of this device to the full-screen window.

What is _this device_? There's no device in the parameters of the method.

If you write javadoc, you should document the parameters too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7835


From mvs at openjdk.java.net  Tue Mar 29 11:16:57 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 29 Mar 2022 11:16:57 GMT
Subject: Integrated: 8282936: Write a regression test for JDK-4615365
In-Reply-To: <9V6N62EUXtJ_TlONZHRMlwpDU3Pqymgs7daipoaSrB4=.f9110cf2-ba95-4e23-a93d-45ba5dbfeca2@github.com>
References: <9V6N62EUXtJ_TlONZHRMlwpDU3Pqymgs7daipoaSrB4=.f9110cf2-ba95-4e23-a93d-45ba5dbfeca2@github.com>
Message-ID: <KrtAI614ZbsqXzWrswAhImppGZgJ2QLTrgCIr8KQLLg=.e0f16b08-deb2-4a49-af77-f31d6cc75b0f@github.com>

On Sun, 13 Mar 2022 13:54:47 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Write a regression test for [JDK-4615365](https://bugs.openjdk.java.net/browse/JDK-4615365) : JSplitPane current and last divider positions incorrect when realized
> 
> Issue:
> JSplitPane component with a left and right component has its current divider
> position incorrectly set to -1 once it is fully realized. For JDK 1.3.1, its
> value is set to 0. The current position of the divider should be the current
> position of the divider once layout management is complete. If the divider is
> moved one pixel, the current divider position is updated to the correct value
> but the last divider position is then set to -1 (i.e. the last value of the
> current divider position). If the divider is moved again, everything is OK.
> 
> Testing:
> Java 1.4.0 -> Test Failed.
> $ j2sdk1.4.0/bin/java bug4615365
> current= -1, last= 0
> Test Failed.
> 
> Java 1.4.1 -> Test Passed.
> $ j2sdk1.4.1/bin/java bug4615365
> current= 97, last= -1
> Test Passed.

This pull request has now been integrated.

Changeset: c3d903a5
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Abdul Kolarkunnu <akolarkunnu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c3d903a55a9f606db8604d5a8c091b0fc3c6a988
Stats:     200 lines in 1 file changed: 200 ins; 0 del; 0 mod

8282936: Write a regression test for JDK-4615365

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/7802


From azvegint at openjdk.java.net  Tue Mar 29 13:03:13 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 29 Mar 2022 13:03:13 GMT
Subject: RFR: 8282374: Java_sun_awt_X11_XlibWrapper_XSynchronize is wrong and
 unused
Message-ID: <tbxrHb9ntPIGPWVdXA08iyq3Fg_jpvK5vUO5dagVsXs=.bb42b7a7-ea14-437d-999c-15f40b61b05a@github.com>

This fix simply removes unused `XSynchronize` method.

Alternatively its return type may be changed to `long`, but I think less code is better.

Testing is green.

-------------

Commit messages:
 - remove XSynchronize

Changes: https://git.openjdk.java.net/jdk/pull/8016/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8016&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282374
  Stats: 13 lines in 2 files changed: 0 ins; 12 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8016.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8016/head:pull/8016

PR: https://git.openjdk.java.net/jdk/pull/8016


From prr at openjdk.java.net  Tue Mar 29 16:50:54 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 29 Mar 2022 16:50:54 GMT
Subject: RFR: 8181571: printing to CUPS fails on mac sandbox app [v7]
In-Reply-To: <obWQjhyQMLRwJ-MEpaw4xSE2VRGqwdPorjuF-A3UZvE=.57519009-9cab-42b8-aa90-20fd248a3196@github.com>
References: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com>
 <obWQjhyQMLRwJ-MEpaw4xSE2VRGqwdPorjuF-A3UZvE=.57519009-9cab-42b8-aa90-20fd248a3196@github.com>
Message-ID: <sfDWkUyAqx_C9zQ_BYfSL5kQr7gYHfzwxHU54xEx1DU=.1462932f-a9e2-485d-a818-e7f58ec5e683@github.com>

On Mon, 28 Mar 2022 16:05:34 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> The issue is reproduced on macOS Big Sur 11.0.1 with jdk 16.0.1+9.
>> 
>> Create a native macOS app from the Hello.java file, sign and run it in sandbox:
>> 
>> import javax.print.*;
>> import javax.swing.*;
>> 
>> public class Hello {
>> 
>>     public static void main(String[] args) throws Exception {
>>         SwingUtilities.invokeAndWait(() -> {
>>             boolean isSandboxed = System.getenv("APP_SANDBOX_CONTAINER_ID") != null;
>>             PrintService defaultPrinter = PrintServiceLookup.lookupDefaultPrintService();
>>             PrintService[] services = PrintServiceLookup.lookupPrintServices(null, null);
>> 
>>             StringBuilder builder = new StringBuilder();
>>             builder.append("is sandboxed: ").append(isSandboxed).append("\n");
>>             builder.append("default printer: ").append(defaultPrinter).append("\n");
>>             int size = services.length;
>>             for (int i = 0; i < size; i++) {
>>                 builder.append("printer[").append(i).append("]=").append(services[i]).append("\n");
>>             }
>>             JOptionPane.showMessageDialog(null, builder.toString());
>>         });
>>     }
>> }
>> 
>> The signed app in sandbox shows null default printer and PrintServiceLookup.lookupPrintServices(null, null) returns "Unix Printer: lp".
>> ![PrintSandboxedApp](https://bugs.openjdk.java.net/secure/attachment/95629/PrintSandboxedApp.png)
>> 
>> The problem has been discussed on  2d-dev mail list:
>>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-June/008375.html
>>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-July/008418.html
>> 
>> According to the discussion:
>> 
>>> I've submitted a DTS incident to Apple and a friend there has followed-up.
>>> Their unofficial position is that java should be connecting to the cups interface returned
>>> by the cupsServer() function and not changing the interface string to "localhost".
>>> Security changes in 10.12.4 reject the TCP connection which they say confuses
>>> network-client access with print access.  They don't seem interested in loosening that change.
>> 
>> 
>> The proposed solution is to use the domain socket pathname in httpConnect(...) cups function and cupsGetDests(...) to get list of printers from cups  when the app is signed and is run in sandbox on MacOs.
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove JNU_ThrowOutOfMemoryError from getCupsDefaultPrinters()

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4861


From duke at openjdk.java.net  Tue Mar 29 16:54:04 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Tue, 29 Mar 2022 16:54:04 GMT
Subject: Integrated: 8281284 : Write JSlider accessibility test
In-Reply-To: <VB8Ldq_d1uZBKpyvvDlu7t9lUtAd_WhLl4meSv46ixo=.b8b023ee-6946-407d-8e05-223fb2d95062@github.com>
References: <VB8Ldq_d1uZBKpyvvDlu7t9lUtAd_WhLl4meSv46ixo=.b8b023ee-6946-407d-8e05-223fb2d95062@github.com>
Message-ID: <GRaQU3hUHd-HZqajW6jA6E5nATBbXO91E_2bk_l0sS8=.3c921830-4a7b-4a9c-8c89-4f0fecf1fb70@github.com>

On Fri, 4 Feb 2022 18:39:52 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> This testcase covers both old and new api ( api added in jdk17  getAccessibleAction(), getAccessibleActionCount() , getAccessibleActionDescription )
> 
> @shurymury 
> @savoptik

This pull request has now been integrated.

Changeset: f074775f
Author:    lawrence.andrews <lawrence.andrews at oracle.com>
Committer: Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f074775f6cb423c76bc90082873f31cdbd82d9ca
Stats:     107 lines in 4 files changed: 107 ins; 0 del; 0 mod

8281284: Write JSlider accessibility test

Reviewed-by: prr, kizune

-------------

PR: https://git.openjdk.java.net/jdk/pull/7355


From duke at openjdk.java.net  Tue Mar 29 16:56:55 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Tue, 29 Mar 2022 16:56:55 GMT
Subject: Integrated: 8024624: [TEST_BUG] [macosx] CTRL+RIGHT(LEFT) doesn't move
 selection on next cell in JTable on Aqua L&F
In-Reply-To: <LdWWDPfwqpCC-_EBaYQLX4rFIyV9FLAG5ugIJb0ruI4=.bc296640-5df9-41a1-b857-14f334c1be8e@github.com>
References: <LdWWDPfwqpCC-_EBaYQLX4rFIyV9FLAG5ugIJb0ruI4=.bc296640-5df9-41a1-b857-14f334c1be8e@github.com>
Message-ID: <2TuyNLaqP5FQfMo7-QstAOhqLBtnPHB-ralHcqFuB28=.be9334da-97c6-4248-9e57-52dbb85d3c00@github.com>

On Fri, 11 Mar 2022 23:13:15 GMT, DamonGuy <duke at openjdk.java.net> wrote:

> Aqua L&F tables lacked support for `CTRL+ARROW`, `CTRL+PG_UP/DOWN`, and `CTRL+SHIFT+PG_UP/DOWN` key bindings. This allows for navigation and selection of table cells without the need of a mouse and without deselecting the current selected cell group. 
> 
> Those key bindings are added to Aqua's key bindings for tables. The `SPACE` key binding was also added because it allows for the selection of cells after navigating using the `CTRL+ARROW` bindings, and some of the new bindings are only useful with the `SPACE` binding added. The closed test that this bug originates from tests for both left-to-right and right-to-left functionality, so the new directional bindings are also added to the right-to-left key bindings table where needed.
> 
> This requires mission control shortcuts in macOS to be disabled as `CTRL+ARROW` keys are normally used for virtual desktop navigation.

This pull request has now been integrated.

Changeset: 53593872
Author:    Damon Nguyen <damon.nguyen at oracle.com>
Committer: Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/535938722028b86e9d77d3728190f62f42117792
Stats:     295 lines in 1 file changed: 295 ins; 0 del; 0 mod

8024624: [TEST_BUG] [macosx] CTRL+RIGHT(LEFT) doesn't move selection on next cell in JTable on Aqua L&F

Reviewed-by: kizune, prr, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/7792


From avu at openjdk.java.net  Tue Mar 29 17:15:45 2022
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Tue, 29 Mar 2022 17:15:45 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v2]
In-Reply-To: <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
Message-ID: <EkOvIjPD4AVTDTRND-BLlgVMmWOyHv1P7961DrdUVHI=.76dab331-2ca6-4a19-a841-5f58dbf3fcfd@github.com>

On Thu, 24 Mar 2022 22:36:28 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

>> 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 incrementally with one additional commit since the last revision:
> 
>   8269806: Fix builds with old Freetype (before 2.5)

I was able to reproduce the problem. I used the Xorg session instead of the default (Wayland) one and provided the option mentioned above (-Dsun.java2d.xrender=false)
![image](https://user-images.githubusercontent.com/3232337/160667606-7f3084cb-5890-4061-9e0c-d63384d849d8.png)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4798


From prr at openjdk.java.net  Tue Mar 29 17:35:47 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 29 Mar 2022 17:35:47 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v2]
In-Reply-To: <EkOvIjPD4AVTDTRND-BLlgVMmWOyHv1P7961DrdUVHI=.76dab331-2ca6-4a19-a841-5f58dbf3fcfd@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
 <EkOvIjPD4AVTDTRND-BLlgVMmWOyHv1P7961DrdUVHI=.76dab331-2ca6-4a19-a841-5f58dbf3fcfd@github.com>
Message-ID: <DyjFgxVE2jpG3Np-fzVq9wMSWMnvXy9C4JmRuCK1R8w=.c1552dbc-1660-43d6-a405-f6434d58dd0c@github.com>

On Tue, 29 Mar 2022 17:11:54 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> reproduce

Hah - this crossed my mind but I could not imagine how it could make a difference.
@YaaZ wayland mode is completely unsupported .. as in cannot pass TCK - so this needs to work with X.org

-------------

PR: https://git.openjdk.java.net/jdk/pull/4798


From kizune at openjdk.java.net  Tue Mar 29 17:45:32 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 29 Mar 2022 17:45:32 GMT
Subject: RFR: 8283215: [macos] Screen Magnifier: Getting
 java.awt.IllegalComponentStateException when menu item is selected [v2]
In-Reply-To: <MIs7PdqdCMBtdSnGBjLOp2DpFNFTqoQpMj6duGyvFSs=.ed8610da-b86d-4c57-91b8-871c29000ff7@github.com>
References: <MIs7PdqdCMBtdSnGBjLOp2DpFNFTqoQpMj6duGyvFSs=.ed8610da-b86d-4c57-91b8-871c29000ff7@github.com>
Message-ID: <UvetK91Qx1mwTwnfvCb7DevI1OSs67taH-YFYem6B5U=.f55c4501-437d-4fe5-83fc-d0737d518992@github.com>

> Check parent component visibility status before asking it for its screen coordinates.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Surrounding the entire call block with try/catch for illegal component state exception.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8008/files
  - new: https://git.openjdk.java.net/jdk/pull/8008/files/badef48d..e72d98d9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8008&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8008&range=00-01

  Stats: 26 lines in 1 file changed: 5 ins; 0 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8008.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8008/head:pull/8008

PR: https://git.openjdk.java.net/jdk/pull/8008


From kizune at openjdk.java.net  Tue Mar 29 17:45:32 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 29 Mar 2022 17:45:32 GMT
Subject: RFR: 8283215: [macos] Screen Magnifier: Getting
 java.awt.IllegalComponentStateException when menu item is selected [v2]
In-Reply-To: <s3aIvh83P0HBrcXgzc_34_PzJOn1pLwchqBF5eEJIOM=.7e00abfb-5948-4a5f-ab05-10142a22b5df@github.com>
References: <MIs7PdqdCMBtdSnGBjLOp2DpFNFTqoQpMj6duGyvFSs=.ed8610da-b86d-4c57-91b8-871c29000ff7@github.com>
 <s3aIvh83P0HBrcXgzc_34_PzJOn1pLwchqBF5eEJIOM=.7e00abfb-5948-4a5f-ab05-10142a22b5df@github.com>
Message-ID: <CRFRjmafddJdi0BLPujNABVj0pUhzK5acOD8bLdBdg0=.8cdec7e3-16b1-48a0-9ab8-c663da1bca97@github.com>

On Tue, 29 Mar 2022 02:47:05 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Surrounding the entire call block with try/catch for illegal component state exception.
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 472:
> 
>> 470:         return invokeAndWait(new Callable<Accessible>() {
>> 471:             public Accessible call() throws Exception {
>> 472:                 if (parent == null || !parent.isVisible()) {
> 
> Should the `isShowing` be used here to check containers up to the top level? But I think it should be possible to create a test that may trigger an exception in `getLocationOnScreen()` after the check, so maybe try/catch will be a better approach.

Well, if the parent is visible then it is all we need to get its screen coordinates. But i also think that surrounding the entire call in try/catch block would work better. Updating the fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8008


From prr at openjdk.java.net  Tue Mar 29 18:48:09 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 29 Mar 2022 18:48:09 GMT
Subject: RFR: 8283701: Add final or sealed modifier to appropriate
 java.awt.color ICC_Profile API classes
Message-ID: <yWe4sX3faNOqmRp-Yae2uVhZGQIGVdaZvSYkb5UUzo8=.8e4718a6-64d5-48d6-9549-16ed2072b368@github.com>

This PR is similar to https://git.openjdk.java.net/jdk/pull/7998 but addresses some Java 2D API color related classes.

ICC_Profile can be made sealed, and the two extant sub-classes can be made final.

-------------

Commit messages:
 - 8283701: Add final or sealed modifier to appropriate java.awt.color ICC_Profile API classes

Changes: https://git.openjdk.java.net/jdk/pull/8021/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8021&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283701
  Stats: 5 lines in 3 files changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8021.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8021/head:pull/8021

PR: https://git.openjdk.java.net/jdk/pull/8021


From bpb at openjdk.java.net  Tue Mar 29 19:11:46 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 29 Mar 2022 19:11:46 GMT
Subject: RFR: 8283701: Add final or sealed modifier to appropriate
 java.awt.color ICC_Profile API classes
In-Reply-To: <yWe4sX3faNOqmRp-Yae2uVhZGQIGVdaZvSYkb5UUzo8=.8e4718a6-64d5-48d6-9549-16ed2072b368@github.com>
References: <yWe4sX3faNOqmRp-Yae2uVhZGQIGVdaZvSYkb5UUzo8=.8e4718a6-64d5-48d6-9549-16ed2072b368@github.com>
Message-ID: <ysbxG9t_dWd3DsAAXQnSkPmI22rN4R-AbAvqezD4Ejc=.e399701d-fc58-4929-bfae-e7cb56146d22@github.com>

On Tue, 29 Mar 2022 18:39:49 GMT, Phil Race <prr at openjdk.org> wrote:

> This PR is similar to https://git.openjdk.java.net/jdk/pull/7998 but addresses some Java 2D API color related classes.
> 
> ICC_Profile can be made sealed, and the two extant sub-classes can be made final.
> 
> All regression and JCK tests have passed
> 
> CSR is here https://bugs.openjdk.java.net/browse/JDK-8283891

+1

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8021


From aivanov at openjdk.java.net  Tue Mar 29 20:24:50 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 29 Mar 2022 20:24:50 GMT
Subject: RFR: 8283701: Add final or sealed modifier to appropriate
 java.awt.color ICC_Profile API classes
In-Reply-To: <yWe4sX3faNOqmRp-Yae2uVhZGQIGVdaZvSYkb5UUzo8=.8e4718a6-64d5-48d6-9549-16ed2072b368@github.com>
References: <yWe4sX3faNOqmRp-Yae2uVhZGQIGVdaZvSYkb5UUzo8=.8e4718a6-64d5-48d6-9549-16ed2072b368@github.com>
Message-ID: <NH5Un0JdDZVnMb1FLzfJF3kxX2vMgUTvYGH04qI6op0=.c8bcaed8-c1b1-49ee-8eea-11b2e1d2c220@github.com>

On Tue, 29 Mar 2022 18:39:49 GMT, Phil Race <prr at openjdk.org> wrote:

> This PR is similar to https://git.openjdk.java.net/jdk/pull/7998 but addresses some Java 2D API color related classes.
> 
> ICC_Profile can be made sealed, and the two extant sub-classes can be made final.
> 
> All regression and JCK tests have passed
> 
> CSR is here https://bugs.openjdk.java.net/browse/JDK-8283891

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8021


From serb at openjdk.java.net  Tue Mar 29 20:36:46 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 29 Mar 2022 20:36:46 GMT
Subject: RFR: 8283701: Add final or sealed modifier to appropriate
 java.awt.color ICC_Profile API classes
In-Reply-To: <yWe4sX3faNOqmRp-Yae2uVhZGQIGVdaZvSYkb5UUzo8=.8e4718a6-64d5-48d6-9549-16ed2072b368@github.com>
References: <yWe4sX3faNOqmRp-Yae2uVhZGQIGVdaZvSYkb5UUzo8=.8e4718a6-64d5-48d6-9549-16ed2072b368@github.com>
Message-ID: <cglPZ9rolQNXa_nLuMiBOL_MiXA0ySXq0K6AV0nMwEs=.14af767c-79a9-4af8-a561-5d8f41bf830b@github.com>

On Tue, 29 Mar 2022 18:39:49 GMT, Phil Race <prr at openjdk.org> wrote:

> This PR is similar to https://git.openjdk.java.net/jdk/pull/7998 but addresses some Java 2D API color related classes.
> 
> ICC_Profile can be made sealed, and the two extant sub-classes can be made final.
> 
> All regression and JCK tests have passed
> 
> CSR is here https://bugs.openjdk.java.net/browse/JDK-8283891

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8021


From serb at openjdk.java.net  Tue Mar 29 20:38:49 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 29 Mar 2022 20:38:49 GMT
Subject: RFR: 8282374: Java_sun_awt_X11_XlibWrapper_XSynchronize is wrong
 and unused
In-Reply-To: <tbxrHb9ntPIGPWVdXA08iyq3Fg_jpvK5vUO5dagVsXs=.bb42b7a7-ea14-437d-999c-15f40b61b05a@github.com>
References: <tbxrHb9ntPIGPWVdXA08iyq3Fg_jpvK5vUO5dagVsXs=.bb42b7a7-ea14-437d-999c-15f40b61b05a@github.com>
Message-ID: <EASxUCqeXGsilIp_2er9trcbLFMidgifjgSnctXNg6k=.4a79ac96-b484-476a-ba52-e36371624f25@github.com>

On Tue, 29 Mar 2022 12:55:34 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This fix simply removes unused `XSynchronize` method.
> 
> Alternatively its return type may be changed to `long`, but I think less code is better.
> 
> Testing is green.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8016


From serb at openjdk.java.net  Tue Mar 29 20:52:45 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 29 Mar 2022 20:52:45 GMT
Subject: RFR: 8283621: Write a regression test for CCC4400728
In-Reply-To: <rnjTXKruqaPPPREorlsQv7c8rcSNE9BUqiAdoVPML0w=.b9c187ff-9050-4cae-9c5a-435b451213dd@github.com>
References: <rnjTXKruqaPPPREorlsQv7c8rcSNE9BUqiAdoVPML0w=.b9c187ff-9050-4cae-9c5a-435b451213dd@github.com>
Message-ID: <cKqdQezU9KUwLnEnGwtL36zuTZHa6k_Dfp32FL115Rs=.510cf7c5-bf62-48da-bfed-ec35b61e5d80@github.com>

On Thu, 24 Mar 2022 15:22:35 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Write a regression test for [JDK-4400728](https://bugs.openjdk.java.net/browse/JDK-4400728)
> 
> Issue:
> JFileChooser constructors by default set current directory to the "Desktop" value on Windows,
> but should use 'My Documents' property instead, also user.home for unix platforms.
> 
> javadoc says:
> "public JFileChooser()
> Constructs a JFileChooser pointing to the user's default directory. This default depends on the operating system. It is typically the 'My Documents' folder on Windows, and the user's home directory on Unix.
> "
> See this https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JFileChooser.html#%3Cinit%3E()
> 
> Testing:
> 1. Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.
> 2. Tested in original failed Java version and the fixed version;
> Java 1.4.0 -> Test Failed.
> $ j2sdk1.4.0/bin/java JFileChooserDefaultDirectoryTest
> java.lang.NullPointerException
>         at java.io.File.<init>(File.java:180)
>         at sun.awt.shell.Win32ShellFolder.listFiles(Win32ShellFolder.java:517)
>         at sun.awt.shell.Win32ShellFolderManager.get(Win32ShellFolderManager.java:152)
>         at sun.awt.shell.ShellFolder.get(ShellFolder.java:208)
>         at javax.swing.plaf.metal.MetalFileChooserUI.installComponents(MetalFileChooserUI.java:310)
>         at javax.swing.plaf.basic.BasicFileChooserUI.installUI(BasicFileChooserUI.java:130)
>         at javax.swing.plaf.metal.MetalFileChooserUI.installUI(MetalFileChooserUI.java:152)
>         at javax.swing.JComponent.setUI(JComponent.java:445)
>         at javax.swing.JFileChooser.updateUI(JFileChooser.java:1701)
>         at javax.swing.JFileChooser.setup(JFileChooser.java:345)
>         at javax.swing.JFileChooser.<init>(JFileChooser.java:320)
>         at javax.swing.JFileChooser.<init>(JFileChooser.java:273)
>         at JFileChooserDefaultDirectoryTest.main(JFileChooserDefaultDirectoryTest.java:15)
> Exception in thread "main"
> 
> Java 1.5.0 -> Test Passed.
> $ jdk1.5.0/bin/java JFileChooserDefaultDirectoryTest
> UserHome dir = C:\Users\jpgansible
> Test Passed
> 
> Java 1.8.0 -> Test Passed.
> $ jdk1.8.0_331/bin/java JFileChooserDefaultDirectoryTest
> UserHome dir = C:\Users\jpgansible
> Test Passed

test/jdk/javax/swing/JFileChooser/4400728/JFileChooserDefaultDirectoryTest.java line 46:

> 44:                                         .startsWith("windows");
> 45:         if (isWindows) {
> 46:             if (actualDefaultDirectory.endsWith("Documents")) {

Based on this PR https://github.com/openjdk/jdk/pull/7983 can we check just the "Documents" string?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7942


From prr at openjdk.java.net  Tue Mar 29 20:45:54 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 29 Mar 2022 20:45:54 GMT
Subject: RFR: 8282374: Java_sun_awt_X11_XlibWrapper_XSynchronize is wrong
 and unused
In-Reply-To: <tbxrHb9ntPIGPWVdXA08iyq3Fg_jpvK5vUO5dagVsXs=.bb42b7a7-ea14-437d-999c-15f40b61b05a@github.com>
References: <tbxrHb9ntPIGPWVdXA08iyq3Fg_jpvK5vUO5dagVsXs=.bb42b7a7-ea14-437d-999c-15f40b61b05a@github.com>
Message-ID: <mbS4NhiZEkAmjVML-D4H18tput8N8tbIo-C8KZ70IhU=.bd676d9b-43ff-4e8e-8090-4950ffa1eff6@github.com>

On Tue, 29 Mar 2022 12:55:34 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This fix simply removes unused `XSynchronize` method.
> 
> Alternatively its return type may be changed to `long`, but I think less code is better.
> 
> Testing is green.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8016


From prr at openjdk.java.net  Tue Mar 29 20:53:50 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 29 Mar 2022 20:53:50 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v12]
In-Reply-To: <pkujGIpXv0UwX2gxeX6kOzKXHiqoImRI9BuglmWbHbE=.a4801fee-2fc4-4a78-97b6-4ea27396492a@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <pkujGIpXv0UwX2gxeX6kOzKXHiqoImRI9BuglmWbHbE=.a4801fee-2fc4-4a78-97b6-4ea27396492a@github.com>
Message-ID: <AVNIzAuGyefM4c-lFDPSnD3nO0otBZIzeVPfhDrFgRI=.337bfef2-52e0-4324-ab03-5c8930431d77@github.com>

On Thu, 16 Dec 2021 18:33:37 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>   
>   This is a second follow-up response to prrace's code review feedback about method modifiers.
>   
>   This commit more carefully preserves the getBounds2D() method modifiers for all 3 classes: the Path2D.Double, the Path2D.Float, and the Path2D itself.
>   
>   It is possible (if unlikely) that someone previously extended the Path2D class and overrode getBounds2D(), because the Path2D#getBounds2D() method was *not* final. So with this commit: any such existing code will not break. Meanwhile the subclasses (Double and Float) preserve their previous modifiers (final, synchronized).
>   
>   This is in response to prrace's code review:
>   
>   >    You are changing the signature of public API
>   >    src/java.desktop/share/classes/java/awt/geom/Path2D.java
>   >    public final synchronized Rectangle2D getBounds2D() => public Rectangle2D getBounds2D() {
>   >
>   > So no longer final, and no longer synchronized.
>   > This means a CSR is required and we need to think about it ..
>   > the intention was that the subclass not over-ride.
>   > And why remove synchronized ? I am fairly sure it was there to
>   > make sure no one was mutating the Path whilst
>   > bounds are being calculated.
>   > And you are using getPathIterator(AffineTransform) and the docs
>   > for that say it isn't thread safe.
>   > So I think this implementation needs to be thought about very carefully.

CSR is now approved. Ready to integrate although Laurent has not yet approved and would be good if he did first.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6227


From serb at openjdk.java.net  Tue Mar 29 20:57:44 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 29 Mar 2022 20:57:44 GMT
Subject: RFR: 8283794: CCE in XRTextRenderer.drawGlyphList and
 XRMaskFill.MaskFill
In-Reply-To: <GD4NAkuLptwylcQOI8VBAXXI1rY7ycgz8O2NvPmhIOc=.f2c8334e-d2eb-4717-92a1-de2f9ed301b6@github.com>
References: <GD4NAkuLptwylcQOI8VBAXXI1rY7ycgz8O2NvPmhIOc=.f2c8334e-d2eb-4717-92a1-de2f9ed301b6@github.com>
Message-ID: <99TMzNTA3ED5PWkEFHJLco2YI4hXyxy5JIlM2Dl7Sk4=.d56ee68b-c0ea-410a-bb92-e27ddf557b72@github.com>

On Tue, 29 Mar 2022 10:44:51 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Throwing InvalidPipeException for incompatible surfaces

Since this is the third cast-related issue then probably it will be useful to create a method to convert the `surfaceData `to the (XRSurfaceData) and throw `InvalidPipeException `if needed? We have many other places where we use the same casts.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8015


From shurailine at openjdk.java.net  Tue Mar 29 21:33:48 2022
From: shurailine at openjdk.java.net (Alexandre Iline)
Date: Tue, 29 Mar 2022 21:33:48 GMT
Subject: RFR: 8274082 : Wrong test case name specified in jtreg run tag for
 java/awt/print/PrinterJob/SwingUIText.java
In-Reply-To: <ZCvrnk1meFmsJa3Q5hk2onn7kUQL18cxrktRywdActc=.befc4c76-c87c-4261-8888-0cee83df9a80@github.com>
References: <ZCvrnk1meFmsJa3Q5hk2onn7kUQL18cxrktRywdActc=.befc4c76-c87c-4261-8888-0cee83df9a80@github.com>
Message-ID: <cLsEoc2Gz-Aew_A0eYGOCA_RmjFnhOZWzobvwFRrHCw=.61391d08-a9cc-48d0-b187-a6f283ecd4ec@github.com>

On Thu, 24 Mar 2022 20:24:35 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> Following issues were fixed in this test 
> 1) Fixed - Parser error due to yesno in @run main/manual=yesno
> 2) Fixed Wrong test name specified in @run jtreg
> @run main/manual=yesno PrintTextTest . It should be @run main/manual=yesno SwingUIText
> 3) Instruction frame does not have 'Pass' or 'Fail' button to mark the test as Pass or Fail after verifying Text on UI and print out. 
> 4) Fixed - Test UI ( test instruction frame, UI frame and Print Dialog) just gets disposed automatically without interacting via running the test case with jtreg. 
> 
> @shurymury

test/jdk/java/awt/print/PrinterJob/SwingUIText.java line 96:

> 94:     private static void createTestInstructionUI() {
> 95:         testInstructionFrame = new JFrame("Test Instruction Frame");
> 96:         final String INSTRUCTION = """

Would this make more sense to use the already existing manual test support from the A11Y tests?

test/jdk/java/awt/print/PrinterJob/SwingUIText.java line 101:

> 99:                 as seen on-screen, and that the spacing of the text is of,
> 100:                 reasonable even-ness. This latter part is very subjective and,
> 101:                 the comparison has to be with JDK1.5 GA, or JDK 1.6 GA.

Are test executors really to compare to JDK 1.5? Would it be possible to come up with a comprehensive criteria of some kind? Worst case, can some reference images be used for the test executor to compare the printout to?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7946


From shurailine at openjdk.java.net  Tue Mar 29 21:34:53 2022
From: shurailine at openjdk.java.net (Alexandre Iline)
Date: Tue, 29 Mar 2022 21:34:53 GMT
Subject: RFR: 8283803 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/PrintGlyphVectorTest.java and fix test
In-Reply-To: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
Message-ID: <b-hLFcWpEU86DPC6tuo4UyihmFwp0wl5xtSDK7wZfn0=.75a0c6b4-6abb-4b7b-a64e-cd43ae9ccac3@github.com>

On Mon, 28 Mar 2022 20:23:20 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> Fixed the following issue.
> 1) Removed yes/no since test was failing due to "Parser error due to yesno in @run main/manual=yesno"
> 2) After removing yes/no test run( just shows the UI and gets dispose immediately). User cannot interact with the test UI and mark the test pass or failed. 
> So added Pass and Fail button to mark the test result.
> 3) Added timeout if in case user does not interact with the test UI.
> 
> @shurymury 
> @aivanov-jdk

test/jdk/java/awt/print/PrinterJob/PrintGlyphVectorTest.java line 133:

> 131:     private volatile boolean failed = false;
> 132:     private volatile String testFailedReason;
> 133:     static final String INSTRUCTIONS =

Would it make more sense to use the already existing support for manual tests?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8004


From serb at openjdk.java.net  Tue Mar 29 22:02:51 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 29 Mar 2022 22:02:51 GMT
Subject: RFR: 8283215: [macos] Screen Magnifier: Getting
 java.awt.IllegalComponentStateException when menu item is selected [v2]
In-Reply-To: <CRFRjmafddJdi0BLPujNABVj0pUhzK5acOD8bLdBdg0=.8cdec7e3-16b1-48a0-9ab8-c663da1bca97@github.com>
References: <MIs7PdqdCMBtdSnGBjLOp2DpFNFTqoQpMj6duGyvFSs=.ed8610da-b86d-4c57-91b8-871c29000ff7@github.com>
 <s3aIvh83P0HBrcXgzc_34_PzJOn1pLwchqBF5eEJIOM=.7e00abfb-5948-4a5f-ab05-10142a22b5df@github.com>
 <CRFRjmafddJdi0BLPujNABVj0pUhzK5acOD8bLdBdg0=.8cdec7e3-16b1-48a0-9ab8-c663da1bca97@github.com>
Message-ID: <7KUcxLWVRHW7XtygvqlVauBSAKiwqf2ZAv-86plxpGg=.e0e1ded3-d52f-40cd-aa66-2bf6f27e8101@github.com>

On Tue, 29 Mar 2022 17:39:25 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 472:
>> 
>>> 470:         return invokeAndWait(new Callable<Accessible>() {
>>> 471:             public Accessible call() throws Exception {
>>> 472:                 if (parent == null || !parent.isVisible()) {
>> 
>> Should the `isShowing` be used here to check containers up to the top level? But I think it should be possible to create a test that may trigger an exception in `getLocationOnScreen()` after the check, so maybe try/catch will be a better approach.
>
> Well, if the parent is visible then it is all we need to get its screen coordinates. But i also think that surrounding the entire call in try/catch block would work better. Updating the fix.

Why do you need to wrap the entire call, can this exception be thrown by some other methods?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8008


From serb at openjdk.java.net  Tue Mar 29 22:04:44 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 29 Mar 2022 22:04:44 GMT
Subject: RFR: 8283701: Add final or sealed modifier to appropriate
 java.awt.color ICC_Profile API classes
In-Reply-To: <yWe4sX3faNOqmRp-Yae2uVhZGQIGVdaZvSYkb5UUzo8=.8e4718a6-64d5-48d6-9549-16ed2072b368@github.com>
References: <yWe4sX3faNOqmRp-Yae2uVhZGQIGVdaZvSYkb5UUzo8=.8e4718a6-64d5-48d6-9549-16ed2072b368@github.com>
Message-ID: <7naFN4iVHudb0AvQA_hTvH5L7Mz6wDxjByNykP_3sy8=.1cf88576-8cfa-45f0-b16c-32be5c23591e@github.com>

On Tue, 29 Mar 2022 18:39:49 GMT, Phil Race <prr at openjdk.org> wrote:

>All regression and JCK tests have passed

I think the sigtests should fail after this patch?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8021


From kizune at openjdk.java.net  Tue Mar 29 22:06:46 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 29 Mar 2022 22:06:46 GMT
Subject: RFR: 8283215: [macos] Screen Magnifier: Getting
 java.awt.IllegalComponentStateException when menu item is selected [v2]
In-Reply-To: <7KUcxLWVRHW7XtygvqlVauBSAKiwqf2ZAv-86plxpGg=.e0e1ded3-d52f-40cd-aa66-2bf6f27e8101@github.com>
References: <MIs7PdqdCMBtdSnGBjLOp2DpFNFTqoQpMj6duGyvFSs=.ed8610da-b86d-4c57-91b8-871c29000ff7@github.com>
 <s3aIvh83P0HBrcXgzc_34_PzJOn1pLwchqBF5eEJIOM=.7e00abfb-5948-4a5f-ab05-10142a22b5df@github.com>
 <CRFRjmafddJdi0BLPujNABVj0pUhzK5acOD8bLdBdg0=.8cdec7e3-16b1-48a0-9ab8-c663da1bca97@github.com>
 <7KUcxLWVRHW7XtygvqlVauBSAKiwqf2ZAv-86plxpGg=.e0e1ded3-d52f-40cd-aa66-2bf6f27e8101@github.com>
Message-ID: <VQY6nohP2wKMBSjuPI923xGoE9OSnvcbbjIelTewJIo=.8631f3f7-6bcf-4802-baf3-a212362d313d@github.com>

On Tue, 29 Mar 2022 21:59:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Well, if the parent is visible then it is all we need to get its screen coordinates. But i also think that surrounding the entire call in try/catch block would work better. Updating the fix.
>
> Why do you need to wrap the entire call, can this exception be thrown by some other methods?

Just for the readability. I could just split the assignment and definition of Point p but the result is the same.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8008


From serb at openjdk.java.net  Tue Mar 29 22:07:49 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 29 Mar 2022 22:07:49 GMT
Subject: RFR: 8283245: Create a test for JDK-4670319
In-Reply-To: <UrqPfkc5gtakuM1_5bjMxwABKOHUxG5NwTkKpjpFvIk=.3957d27d-ddbe-4aad-aefe-0a3748aca560@github.com>
References: <UrqPfkc5gtakuM1_5bjMxwABKOHUxG5NwTkKpjpFvIk=.3957d27d-ddbe-4aad-aefe-0a3748aca560@github.com>
Message-ID: <SIwWBWJJpiXgP4gmRBzRUcLNmW_4n9MNRnPRLrZ0xbA=.c71b61eb-2570-40aa-8b8c-a06eb3eb35f3@github.com>

On Tue, 29 Mar 2022 08:04:42 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Write an automated regression test for  JDK-4670319
> 
> Issue
> When a JTree node is expanded or collapsed, an Accessibility PropertyChange event is fired with the old state of "collapsed" and new state of "expanded" (or vice versa). The problem is that the source of the event is the AccessibeJTree, and not the AccessibleJTreeNode. This means that an assistive technology listening to this event is unable to report to the user what node was expanded/collapsed.
> 
> Fix
> Fix for [JDK-4670319](https://bugs.openjdk.java.net/browse/JDK-4670319) addresses the above issue.  When tree node is expanded/collapsed, PropertyChangeEventSource is the Node.
> This review is for a test for validating the above issue.
> 
> This review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

test/jdk/javax/accessibility/4670319/AccessibleJTrePCESourceTest.java line 28:

> 26:  * @key headful
> 27:  * @bug 4670319
> 28:  * @summary AccessibleJTree should fire a PropertyChangeEvent using a AccessibleJTreeNode as source.

Please split the long lines, use the 80 chars per line.

test/jdk/javax/accessibility/4670319/AccessibleJTrePCESourceTest.java line 50:

> 48:             SwingUtilities.invokeAndWait(() -> createGUI());
> 49:             Robot robot = new Robot();
> 50:             robot.setAutoDelay(500);

Are you sure that the autodelay is needed here? The test does not use any method other than `waitForIdle`

-------------

PR: https://git.openjdk.java.net/jdk/pull/8012


From serb at openjdk.java.net  Tue Mar 29 22:11:42 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 29 Mar 2022 22:11:42 GMT
Subject: RFR: 8283623: Create an automated regression test for JDK-4525475
In-Reply-To: <ovauTi1CSYZ068j2-fLVDWsy-0LMRrehH2ng_KHgtVs=.7c5b9f95-3235-42dd-81f5-678b3b91e46f@github.com>
References: <ovauTi1CSYZ068j2-fLVDWsy-0LMRrehH2ng_KHgtVs=.7c5b9f95-3235-42dd-81f5-678b3b91e46f@github.com>
Message-ID: <TOQfFvM5drazhFLU-GG_SBYbQ3fy5P2LFKetn5b6Mrg=.715440f9-1de7-423a-8a05-136a0649664d@github.com>

On Sat, 26 Mar 2022 07:19:28 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Write a regression test for [JDK-4525475](https://bugs.openjdk.java.net/browse/JDK-4525475)
> 
> Issue:
> JFileChooser allows modification to the file-system by way of the "New Folder"
> button, and the ability to rename file/folder names. There is no method on
> JFileChooser which indicates that this type of modification should not be
> allowed within the given JFileChooser.
> 
> Testing:
> 1. Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.
> 2. Tested in original failed Java version and the fixed version;
> Java 1.4.0 -> Test Failed.
> $ j2sdk1.4.0/bin/java Bug4525475
> LookAndFeel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> Name = Go Up, readOnly = true
> Name = New Folder, readOnly = true
> Its a Read Only JFileChooser and has a New Folder Button. So Test Failed.
> Name = Go Up, readOnly = false
> Name = New Folder, readOnly = false
> Failed
> 
> Java 1.5.0 -> Test Passed.
> $ jdk1.5.0/bin/java Bug4525475
> LookAndFeel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> Name = Go Up, readOnly = true
> Name = Go Up, readOnly = false
> Name = New Folder, readOnly = false
> Passed

test/jdk/javax/swing/JFileChooser/4525475/JFileChooserReadOnlyTest.java line 73:

> 71: 
> 72:             // Test2, Read/Write JFileChooser
> 73:             if (!(laf.contains("Motif") || laf.contains("Aqua"))) {

Can we update the test to find the correct buttons for these L&Fs as well?

test/jdk/javax/swing/JFileChooser/4525475/JFileChooserReadOnlyTest.java line 93:

> 91:     }
> 92: 
> 93:     private static void createAndTestCustomFileChooser(boolean readOnly) {

The code for the Swing lib should be executed on EDT.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7969


From serb at openjdk.java.net  Tue Mar 29 22:22:50 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 29 Mar 2022 22:22:50 GMT
Subject: RFR: 8282863:
 java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on
 Windows 10 with HiDPI screen [v2]
In-Reply-To: <p01bGSKB-1xZPQ6J3MNai2gorrAcGkSs1zmRFohyW7E=.16c08e60-0681-4b95-b721-696e5258f720@github.com>
References: <SogRHLx2pQzRLxpE6FW6BAjwW0qaawCm-A6Ff4Z3N54=.233a4715-0ec7-491a-ba75-c7c3f16b9ee8@github.com>
 <p01bGSKB-1xZPQ6J3MNai2gorrAcGkSs1zmRFohyW7E=.16c08e60-0681-4b95-b721-696e5258f720@github.com>
Message-ID: <bQFjPqJyxcxqG-3Aw1q0NwHDTk6JEHdlsMdvU_Ha-NY=.80d2e98a-37d0-4465-ae9a-3ed18a32bd70@github.com>

On Mon, 28 Mar 2022 04:29:24 GMT, Dmitry Kulikov <duke at openjdk.java.net> wrote:

>> Hello,
>> Please review this fix for JDK-8282863.
>> 
>> The failing `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test basically checks that full-screen window remains full-screen when a display mode change occurs. It has been introduced in JDK-8211999, which also contains numerous fixes for HiDPI displays. In particular, JDK-8211999 changed the code of `Win32GraphicsDevice.setDisplayMode()` so that it uses screen dimensions in user space instead of device space, which is correct. However, if the display mode change incurs display scaling change, as it has been observed on Windows 10 laptop with HiDPI screen, the method used for obtaining screen bounds in user space returns incorrect values under certain conditions.
>> 
>> The issue is reproducible on Windows 10, when resolution of the primary screen is higher than 1024x768 with scaling greater than 100%. Resolution and scaling of secondary screen(s) is irrelevant. I used a laptop with 2160x1350 display resolution and scaling set to 150%. When the `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test is run with these initial conditions, roughly the following happens:
>> 
>> 1. `java.awt.Frame` is created and set as full-screen.
>> 2. `Win32GraphicsDevice.setDisplayMode()` is called to change screen resolution from 2160x1350 to 1024x768.
>> 3. `Win32GraphicsDevice.configDisplayMode()` call immediately changes the display resolution to 1024x768, which also incurs the immediate display scaling change from 150% to 100%.
>> 4. Inside the `Win32GraphicsDevice.setDisplayMode()` screen bounds in user space are obtained via `Win32GraphicsConfig.getBounds()`:
>> 5. In the native code of `Win32GraphicsConfig.getBounds()` new screen bounds in device space (1024x768) are correctly obtained via `MonitorBounds()`.
>> 6. Then screen bounds are converted to user space by applying **scaling factors, which are not yet updated and correspond to previous display mode**. In our case, 1024x768 is scaled down by 150% and becomes 683x512.
>> 7. Back in `Win32GraphicsDevice.setDisplayMode()` full-screen window bounds are set to incorrectly scaled 683x512 instead of 1024x768.
>> 8. After returning from `Win32GraphicsDevice.setDisplayMode()` the test waits 4 seconds.
>> 9. `WM_DISPLAYCHANGE` message is received and processed, followed by `WM_DPICHANGED`, which updates the scaling factors used by `Win32GraphicsConfig.getBounds()` to the correct value of 100%.
>> 10. After 4 seconds test wakes up and obtains screen bounds in user space by calling `Win32GraphicsConfig.getBounds()`, which now correctly returns 1024x768.
>> 11. Test compares full-screen window bounds with screen bounds, and fails with `java.lang.RuntimeException: width is wrong` as 683 is not equal to 1024 ? 30 pixels.
>> 
>> Proposed fix adds a `Win32GraphicsDevice.initScaleFactors()` call to `Win32GraphicsDevice.setDisplayMode()` code, between calling `Win32GraphicsDevice.configDisplayMode()` and `Win32GraphicsConfig.getBounds()`. This updates the scaling factors without waiting for `WM_DISPLAYCHANGE` or `WM_DPICHANGED`, `Win32GraphicsConfig.getBounds()` returns correctly scaled screen bounds in user space, and full-screen window remains correctly sized after display mode change.
>> 
>> I've run tests from `jdk_awt` group on Windows 10 using a laptop with the same settings that caused the issue (primary screen with 2160x1350 resolution and 150% scaling), and applying the fix did not introduce any new test failures.
>
> Dmitry Kulikov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen
>  - Revert "8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen"
>    
>    This reverts commit 23b40af8de9df4db9a1cc0137c0e875cf6595190.

src/java.desktop/windows/classes/sun/awt/Win32GraphicsDevice.java line 482:

> 480:             // Note: window will get resized to actual full-screen dimensions
> 481:             // in the upcoming display change event, when the DPI scales
> 482:             // would already be correctly set etc. (see JDK-8282863)

We usually do not mention the bugid in the comments, just the description of how it works is fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7835


From prr at openjdk.java.net  Tue Mar 29 22:25:50 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 29 Mar 2022 22:25:50 GMT
Subject: RFR: 8283701: Add final or sealed modifier to appropriate
 java.awt.color ICC_Profile API classes
In-Reply-To: <7naFN4iVHudb0AvQA_hTvH5L7Mz6wDxjByNykP_3sy8=.1cf88576-8cfa-45f0-b16c-32be5c23591e@github.com>
References: <yWe4sX3faNOqmRp-Yae2uVhZGQIGVdaZvSYkb5UUzo8=.8e4718a6-64d5-48d6-9549-16ed2072b368@github.com>
 <7naFN4iVHudb0AvQA_hTvH5L7Mz6wDxjByNykP_3sy8=.1cf88576-8cfa-45f0-b16c-32be5c23591e@github.com>
Message-ID: <tZoznXKACU01FKAB5UfNgngvtcAqESTxqW1qAsddadY=.52817678-553c-40b4-a60d-50ea1fc8bf94@github.com>

On Tue, 29 Mar 2022 22:01:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > All regression and JCK tests have passed
> 
> I think the sigtests should fail after this patch?

Well, true, except the signature tests are not included in the test harness runs.
They are the only ones excluded. The CSR will cover us there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8021


From serb at openjdk.java.net  Tue Mar 29 22:46:39 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 29 Mar 2022 22:46:39 GMT
Subject: RFR: 8282857: Create a regression test for JDK-4702690 [v2]
In-Reply-To: <4O-Asx5MbywARXyvbWuSaIKgwaRnJkmEuSDu_x5LJ-Y=.bca6b199-c272-4882-8645-51cd11bee03c@github.com>
References: <jklfp2oMIJWjzE4tz62KCLHfBqlaV0GlyZqk-wUiFHI=.7a721efc-e549-4058-819e-2785e64d9e8d@github.com>
 <4O-Asx5MbywARXyvbWuSaIKgwaRnJkmEuSDu_x5LJ-Y=.bca6b199-c272-4882-8645-51cd11bee03c@github.com>
Message-ID: <Daj1h1XYMiZtVg6Xds2qF5j8zNcmkPFK3-SRDOO60lY=.8db40935-697a-4209-9c58-2320bd6feb88@github.com>

On Fri, 11 Mar 2022 15:46:32 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a regression test for [JDK-4702690](https://bugs.openjdk.java.net/browse/JDK-4702690)
>> 
>> In many cases in Swing it is possible to easily programatically determine that a JScrollBar (or two) is scrolling some JPanel (the cannonical case is a JScrollPane).
>> In these cases, when accessibility support is instantiated (e.g. the AccessibleJScrollBar is created), a Controller_For and Controled_By relation should be instantiated between the AccessibleJScrollBar and the AccessibleJPanel that the JScrollBar and JPanel are associated with.
>> 
>> This allows various assistive technologies, especially voice-recognition technologies, to better interact with scrolling items.
>> 
>> The test put up validates that the target object for these properties(CONTROLLED_BY, CONTROLLED_FOR) are set appropriately for JScrollPane and JScrollBar.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added @bug keyword

test/jdk/javax/accessibility/4702690/JScrollPaneAccessibleRelationsTest.java line 63:

> 61:             SwingUtilities.invokeAndWait(() -> createGUI());
> 62: 
> 63:             Object[] jScrollPaneTarget = jScrollPane.getAccessibleContext()

The jScrollPane, horizontalScrollBar, verticalScrollBar are all Swing components so should be accessed on the EDT.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7753


From serb at openjdk.java.net  Tue Mar 29 22:46:37 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 29 Mar 2022 22:46:37 GMT
Subject: RFR: JDK-8282778: Create a regression test for JDK-4699544 [v2]
In-Reply-To: <e15b5kZEOO-Likj62PfSpWiQsFF3aioponmsDrh21EU=.f4538490-131a-4d9c-aff7-b0ce10951973@github.com>
References: <IDgBuK7aFq5DBF_2mWS-l27LMVG9XSZe-2Zl_bITg3M=.527d9ca4-e081-4ce2-b123-1f2580f5e017@github.com>
 <e15b5kZEOO-Likj62PfSpWiQsFF3aioponmsDrh21EU=.f4538490-131a-4d9c-aff7-b0ce10951973@github.com>
Message-ID: <qbXIh4dX5xaEHhKSehKjUZ2HTpezEPdWTG7mQVFn4Nc=.390ea8cd-38d1-4d5c-9e46-003a5624565a@github.com>

On Fri, 11 Mar 2022 15:39:31 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a regression test for JDK-4699544
>> 
>> The subclass of javax.swing.JRootPane (AccessibleJRootPane) that implements the accessibility interface javax.accessibility.AccessibleComponent is derived from java.awt.AccessibleAWTComponent, which returns null for getAccessibleAt() because a component does not necessarily have childs.
>> 
>> The root pane always has a content pane child, so getAccessibleAt() should be overwritten by AccessibleJRootPane appropriately.
>> The test added verifies the same.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added @bug keyword

test/jdk/javax/accessibility/4699544/JRootPaneAccessiblAtTest.java line 55:

> 53: 
> 54:     public static void main(String args[]) {
> 55:         new JRootPaneAccessiblAtTest();

This is the subclass of the JFrame, which should be accessed on the EDT.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7739


From serb at openjdk.java.net  Tue Mar 29 22:48:15 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 29 Mar 2022 22:48:15 GMT
Subject: RFR: 8283215: [macos] Screen Magnifier: Getting
 java.awt.IllegalComponentStateException when menu item is selected [v2]
In-Reply-To: <VQY6nohP2wKMBSjuPI923xGoE9OSnvcbbjIelTewJIo=.8631f3f7-6bcf-4802-baf3-a212362d313d@github.com>
References: <MIs7PdqdCMBtdSnGBjLOp2DpFNFTqoQpMj6duGyvFSs=.ed8610da-b86d-4c57-91b8-871c29000ff7@github.com>
 <s3aIvh83P0HBrcXgzc_34_PzJOn1pLwchqBF5eEJIOM=.7e00abfb-5948-4a5f-ab05-10142a22b5df@github.com>
 <CRFRjmafddJdi0BLPujNABVj0pUhzK5acOD8bLdBdg0=.8cdec7e3-16b1-48a0-9ab8-c663da1bca97@github.com>
 <7KUcxLWVRHW7XtygvqlVauBSAKiwqf2ZAv-86plxpGg=.e0e1ded3-d52f-40cd-aa66-2bf6f27e8101@github.com>
 <VQY6nohP2wKMBSjuPI923xGoE9OSnvcbbjIelTewJIo=.8631f3f7-6bcf-4802-baf3-a212362d313d@github.com>
Message-ID: <ODrcg6CDePetOAMa59IyTMqtY_cYdPB4bzfIVGmahm8=.d7051d11-96fa-4b0f-88f4-9d7d74aef1cf@github.com>

On Tue, 29 Mar 2022 22:03:02 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Why do you need to wrap the entire call, can this exception be thrown by some other methods?
>
> Just for the readability. I could just split the assignment and definition of Point p but the result is the same.

I think it is better to wrap only one method, it will be obvious where the exception can be thrown and it does not "fill the git history" of the method by all these unnecessary shifting.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8008


From serb at openjdk.java.net  Tue Mar 29 22:48:21 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 29 Mar 2022 22:48:21 GMT
Subject: RFR: JDK-8282777: Create a Regression test for JDK-4515031 [v2]
In-Reply-To: <-raG_iRydEjRXVhvPFrPPzvHJl2MvPQcBMO2elN4z84=.f81046b8-d697-4dff-a3dc-0fdd8fdb7dff@github.com>
References: <D8K1EcGCjhQQzplHsgYncKPvGmSPhrAs7RNDIl_pQlo=.e8d60f67-9cf4-4ac7-957b-ddbecffc85de@github.com>
 <-raG_iRydEjRXVhvPFrPPzvHJl2MvPQcBMO2elN4z84=.f81046b8-d697-4dff-a3dc-0fdd8fdb7dff@github.com>
Message-ID: <rLa3c67uDBGTka63-mRbcVNdmsEZ6YW3aTexIgMsXgk=.695e5779-dfaa-4b29-9a77-8e64019af674@github.com>

On Fri, 11 Mar 2022 15:36:24 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a Regression test for [JDK-4515031](https://bugs.openjdk.java.net/browse/JDK-4515031)
>> 
>> The issue indicates the need for a a getAccessibleDescription being implemented for the JFileChooser.
>> The test added verifies the same.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added @bug keyword

test/jdk/javax/accessibility/4515031/JFileChooserAccessibleDescriptionTest.java line 72:

> 70:             robot.setAutoWaitForIdle(true);
> 71: 
> 72:             robot.mouseMove(jButton.getLocationOnScreen().x + jButton.getSize().width / 2,

The jButton is a Swing component, it should be accessed on EDT.
Please split the long lines, 80<= chars.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7738


From smandalika at openjdk.java.net  Tue Mar 29 22:48:41 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Tue, 29 Mar 2022 22:48:41 GMT
Subject: Integrated: JDK-8283015: Create a test for JDK-4715496
In-Reply-To: <FZTHpImv7BXOuuYK-42rwC55GssXPQH2S8hwVIvAsfw=.1ba518e0-5c7f-4ed6-a9ce-667a859142c1@github.com>
References: <FZTHpImv7BXOuuYK-42rwC55GssXPQH2S8hwVIvAsfw=.1ba518e0-5c7f-4ed6-a9ce-667a859142c1@github.com>
Message-ID: <prS4JsNI4w3ciHqimaOadPCLA1e2BAMzmomSK1YkFCU=.3015ae9a-8ecb-497e-a5ed-475e1ee4450c@github.com>

On Fri, 11 Mar 2022 14:17:01 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Create a test for JDK-4715496
> 
> Issue observed in the above bug is that the JTable.AccessibleJTableCell.getAccessible name returns the cell instance string instead of the cell text.
> The test is being added to verify the same.
> This review is for migrating tests from a closed test suite to open.

This pull request has now been integrated.

Changeset: bfd9c2b3
Author:    Srinivas Mandalika <smandalika at openjdk.org>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bfd9c2b30f17d3341cbe7f48d13d36708e5fafbf
Stats:     90 lines in 1 file changed: 90 ins; 0 del; 0 mod

8283015: Create a test for JDK-4715496

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/7787


From serb at openjdk.java.net  Tue Mar 29 23:16:52 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 29 Mar 2022 23:16:52 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux
In-Reply-To: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
Message-ID: <STZ-wV5dpSvCLD1MyOtYk7VhJoKUxVOl4_v_bKjxoCI=.75ec4331-12c7-4a08-96bd-e700f3e59fd3@github.com>

On Fri, 21 Jan 2022 17:02:38 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

> These crashes were not reproducible, so the fix is based on a hypothesis that there are two possible reasons for them:
> 1. `makeDefaultConfig()` returning `NULL`.
> 2. A race condition when the number of screens changes.
> The race scenario: `X11GraphisDevice.makeDefaultConfiguration()` is called on EDT so the call can race with `X11GraphisDevice.invalidate()` that re-sets the screen number of the device; the latter is invoked on the `AWT-XAWT` thread from `X11GraphicsEnvironment.rebuildDevices()`. So by the time `makeDefaultConfiguration()` makes a native call with the device's current screen number, the `x11Screens` array maintained by the native code could have become shorter. And the native methods like `Java_sun_awt_X11GraphicsDevice_getConfigColormap()` assume that the number passed to them is always current and valid. The AWT lock only protects against the changes during the native methods invocation and does not protect against them being called with an outdated screen number. With a larger screen number, those methods read past the end of the `x11Screens` array.
> 
> The fix for (1) is to die gracefully instead of crashing in an attempt to de-reference a `NULL` pointer, which might happen upon returning from `makeDefaultConfig()` in `getAllConfigs()`.
> 
> The fix for (2) is to eliminate the race by protecting `X11GraphisDevice.screen` with the AWT lock such that it doesn't change when the native methods working with it are active.
> 
> We've been shipping JetBrains Runtime with this fix for a few months now and there were no crash reports with those specific patterns against the versions with the fix.

I think we can update the fix by these suggestions above:

- Can we remove the `X11GraphicsDevice.configLock` from the `X11GraphicsDevice` and use awt lock instead? I am not sure can we get a deadlock for the current code where we will have `X11GraphicsDevice.configLock` -> `awt lock` in the `X11GraphicsDevice`, and `awt lock` -> `X11GraphicsDevice.configLock` in the `XCanvasPeer. getAppropriateGraphicsConfiguration` (Or in some other similar code)

- The code in the `XCanvasPeer` most probably can be rewritten w/o using the screenNum and the internal API, by the iteration over the newDev.getConfigurations() and check the visual of each config. In this case, we will reuse the locks added to the 
`X11GraphicsDevice`

-------------

PR: https://git.openjdk.java.net/jdk/pull/7182


From serb at openjdk.java.net  Tue Mar 29 23:39:41 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 29 Mar 2022 23:39:41 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v7]
In-Reply-To: <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
Message-ID: <cP92zo9z8kzTKKrEXdcr1SRNrGwdP9u740JDtuMoAXs=.6812dfd4-c7bd-41b6-add3-a04c91bc2fb6@github.com>

On Wed, 23 Mar 2022 18:24:05 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   scale stroke width at higher scalings

I think the only way to fix such an issue is to use a raster-based API which will work as "usually expected" when the UI is scaled unlike vectors like drawLine/etc, an example of a similar bug https://mail.openjdk.java.net/pipermail/swing-dev/2014-April/003352.html
As far as I remember the best solution(used by the javafx) is to draw layers by the fillArea(shadow area->then border area->then component area), I am not sure it will be much slower.
Another solution is to draw the "lines" using the fillRect, but it might cause some issues in the corners if the line color is transparent

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From kcr at openjdk.java.net  Tue Mar 29 23:39:41 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 29 Mar 2022 23:39:41 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v7]
In-Reply-To: <s9MRoDJFKKlN11Y6s9zRxqP58FHrGsPXMrUDNW8MqoI=.7126d6ef-a741-4a9b-ba25-c258bf330a6b@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
 <WiEx5Y_45gZ6T87k39sxgvneubJBZ4mCWgoFo0Iytdc=.c4b9895f-e706-4124-91e6-2d21539d5226@github.com>
 <s9MRoDJFKKlN11Y6s9zRxqP58FHrGsPXMrUDNW8MqoI=.7126d6ef-a741-4a9b-ba25-c258bf330a6b@github.com>
Message-ID: <q7zGotgZbq4ZGp7Xen0PI5G61olW0HoAlgZCENw7NG8=.75cc370d-3243-41fc-b53f-e32df6a62101@github.com>

On Mon, 28 Mar 2022 17:47:50 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > I also think there's at least some analogy with OpenJFX's snap-to-pixel idea that it is sometimes better to pick a pixel and stick with it rather than span pixels and be fuzzy. Not an expert on the details of that by any means @kevinrushforth might be able to point to something if it is relevant.
> 
> I wonder how it's handled in OpenJFX. There should be the same problem with borders at fractional scales.
> 
> > If we figure this out properly it might be useful to apply to other cases rather than applying inconsistent hacks.

JavaFX implements snap-to-pixel by default for Region (which is the base class of all layout panes and UI controls). This is done by either doing a round, floor, or ceil operation by first scaling the user-space value (by the screen scale), rounding (or floor or ceil) in screen coords, and then dividing by the scale to get it back to user space. For region borders, we snap all four corners of each border to pixels. The stroke width is scaled, so that a border of 1 will show up as 3 pixels with a screen scale of 3.

I don't know whether you could do anything analagous in Java2D.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From serb at openjdk.java.net  Tue Mar 29 23:41:39 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 29 Mar 2022 23:41:39 GMT
Subject: RFR: 8282640: Create a test for JDK-4740761 [v2]
In-Reply-To: <MxC6iXzgDe8DbPKKvE4ZLW8Gr7VmlcgQdqD2T3zRiuo=.a1e71d71-262f-4ac7-b815-254e8045fe87@github.com>
References: <Rr2xSJSr1_1WFxavIZtwz_rlxf15Yvd5dCxZ_1dcggs=.7415074d-6beb-434e-b463-04388e50b0c8@github.com>
 <MxC6iXzgDe8DbPKKvE4ZLW8Gr7VmlcgQdqD2T3zRiuo=.a1e71d71-262f-4ac7-b815-254e8045fe87@github.com>
Message-ID: <FDaP-p9ZiIbCe06V6OT3XwLst82LXdutP1Z0RqLnCSw=.cfdfeb3d-4000-4a1f-870d-b56e20125fe0@github.com>

On Fri, 11 Mar 2022 14:44:25 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a test for [JDK-4740761](https://bugs.openjdk.java.net/browse/JDK-4740761)
>> 
>> The issue observed is in a JFrame with a JTextField and a JScrollPane which contains focused component. When the JScrollPane was
>> is removed from its parent, focus stays with the the scroller
>> of the removed JScrollPane, instead of moving to the TextField.
>> 
>> The test verifies the same - i.e. it verifies that the removal of the scrollpane moves the focus to the JTextField present in the JFrame.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added @bug keyword

test/jdk/java/awt/Focus/8282640/ScrollPaneFocusBugTest.java line 97:

> 95: 
> 96:     protected static void pressKey() {
> 97:         robot.mouseMove(scrollPane.getLocationOnScreen().x + scrollPane.getSize().width / 2,

Note that scrollPane here is a Swing component and it should be accessed on the EDT.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7686


From kcr at openjdk.java.net  Tue Mar 29 23:44:37 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 29 Mar 2022 23:44:37 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v7]
In-Reply-To: <cP92zo9z8kzTKKrEXdcr1SRNrGwdP9u740JDtuMoAXs=.6812dfd4-c7bd-41b6-add3-a04c91bc2fb6@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
 <cP92zo9z8kzTKKrEXdcr1SRNrGwdP9u740JDtuMoAXs=.6812dfd4-c7bd-41b6-add3-a04c91bc2fb6@github.com>
Message-ID: <a-lwHXDxstGWGZeJoP-YIyZUzy7kLLpGXsDqsphg1N0=.50c1dc46-79e0-4256-b5d2-d8811dc0bb93@github.com>

On Tue, 29 Mar 2022 23:33:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As far as I remember the best solution(used by the javafx) is to draw layers by the fillArea(shadow area->then border area then component area), I am not sure it will be much slower.

Yes, within a Region, that's how we do it. We render 0 or more background rects (filled), then 0 or more borders (stroked). Then the children are rendered.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From achung at openjdk.java.net  Wed Mar 30 00:54:29 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 30 Mar 2022 00:54:29 GMT
Subject: RFR: 8283805: [REDO] JDK 19 L10n resource files update - msgdrop 10
Message-ID: <YVEmLu-_cOvRQdHfANi62d5Oh6Aba_Kpy4BhXGRBFSk=.9a367c1b-aa8b-46bf-85fd-a00292cbaea0@github.com>

redo of 8280400

-------------

Commit messages:
 - 8280400: JDK 19 L10n resource files update - msgdrop 10

Changes: https://git.openjdk.java.net/jdk/pull/8026/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8026&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283805
  Stats: 11316 lines in 139 files changed: 9124 ins; 1252 del; 940 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8026.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8026/head:pull/8026

PR: https://git.openjdk.java.net/jdk/pull/8026


From mvs at openjdk.java.net  Wed Mar 30 01:36:39 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 30 Mar 2022 01:36:39 GMT
Subject: RFR: 8283621: Write a regression test for CCC4400728
In-Reply-To: <cKqdQezU9KUwLnEnGwtL36zuTZHa6k_Dfp32FL115Rs=.510cf7c5-bf62-48da-bfed-ec35b61e5d80@github.com>
References: <rnjTXKruqaPPPREorlsQv7c8rcSNE9BUqiAdoVPML0w=.b9c187ff-9050-4cae-9c5a-435b451213dd@github.com>
 <cKqdQezU9KUwLnEnGwtL36zuTZHa6k_Dfp32FL115Rs=.510cf7c5-bf62-48da-bfed-ec35b61e5d80@github.com>
Message-ID: <fbUpDu_2e56aOnizY0aGCJmgzh4MnSvtH_HylisM31s=.bce4f45d-3682-41c6-a069-2acb1d301344@github.com>

On Tue, 29 Mar 2022 20:48:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Write a regression test for [JDK-4400728](https://bugs.openjdk.java.net/browse/JDK-4400728)
>> 
>> Issue:
>> JFileChooser constructors by default set current directory to the "Desktop" value on Windows,
>> but should use 'My Documents' property instead, also user.home for unix platforms.
>> 
>> javadoc says:
>> "public JFileChooser()
>> Constructs a JFileChooser pointing to the user's default directory. This default depends on the operating system. It is typically the 'My Documents' folder on Windows, and the user's home directory on Unix.
>> "
>> See this https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JFileChooser.html#%3Cinit%3E()
>> 
>> Testing:
>> 1. Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.
>> 2. Tested in original failed Java version and the fixed version;
>> Java 1.4.0 -> Test Failed.
>> $ j2sdk1.4.0/bin/java JFileChooserDefaultDirectoryTest
>> java.lang.NullPointerException
>>         at java.io.File.<init>(File.java:180)
>>         at sun.awt.shell.Win32ShellFolder.listFiles(Win32ShellFolder.java:517)
>>         at sun.awt.shell.Win32ShellFolderManager.get(Win32ShellFolderManager.java:152)
>>         at sun.awt.shell.ShellFolder.get(ShellFolder.java:208)
>>         at javax.swing.plaf.metal.MetalFileChooserUI.installComponents(MetalFileChooserUI.java:310)
>>         at javax.swing.plaf.basic.BasicFileChooserUI.installUI(BasicFileChooserUI.java:130)
>>         at javax.swing.plaf.metal.MetalFileChooserUI.installUI(MetalFileChooserUI.java:152)
>>         at javax.swing.JComponent.setUI(JComponent.java:445)
>>         at javax.swing.JFileChooser.updateUI(JFileChooser.java:1701)
>>         at javax.swing.JFileChooser.setup(JFileChooser.java:345)
>>         at javax.swing.JFileChooser.<init>(JFileChooser.java:320)
>>         at javax.swing.JFileChooser.<init>(JFileChooser.java:273)
>>         at JFileChooserDefaultDirectoryTest.main(JFileChooserDefaultDirectoryTest.java:15)
>> Exception in thread "main"
>> 
>> Java 1.5.0 -> Test Passed.
>> $ jdk1.5.0/bin/java JFileChooserDefaultDirectoryTest
>> UserHome dir = C:\Users\jpgansible
>> Test Passed
>> 
>> Java 1.8.0 -> Test Passed.
>> $ jdk1.8.0_331/bin/java JFileChooserDefaultDirectoryTest
>> UserHome dir = C:\Users\jpgansible
>> Test Passed
>
> test/jdk/javax/swing/JFileChooser/4400728/JFileChooserDefaultDirectoryTest.java line 46:
> 
>> 44:                                         .startsWith("windows");
>> 45:         if (isWindows) {
>> 46:             if (actualDefaultDirectory.endsWith("Documents")) {
> 
> Based on this PR https://github.com/openjdk/jdk/pull/7983 can we check just the "Documents" string?

As Windows 8.x is still supported, isn't it better to do it like this, for safer side?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7942


From duke at openjdk.java.net  Wed Mar 30 02:05:46 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Wed, 30 Mar 2022 02:05:46 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v3]
In-Reply-To: <isFfgoZsRbN_XgzjucidTow8HYtH55xM3kv9wyVUYIE=.64039678-0a22-4438-989e-cd0aac358b17@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>
 <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>
 <oAZ5tpWpksvN6sfEYoblyucXf_EqcxKAIiVvkvIugjU=.a10e37ec-b8e8-4ac3-9faf-f2a8d85189af@github.com>
 <r9ujiKOC7dRsKCLNjUEt-V8mCstzXKJLFPRQ1O6kqKs=.2b96988b-85c6-45d5-9d95-2e0112b458fb@github.com>
 <AUeNFfcZNdDhRKJExOY7lT7_eG07ZQ_E124iHS_oiVI=.af2824b3-dc46-4318-92c3-27a861269339@github.com>
 <0U4ZvK_ui_ieG7pPZAdhL1AyrJYQNqT0A_HRJIE8InQ=.26f7a810-a6a0-47d0-99d9-e2ffcfebe596@github.com>
 <ML4CSxlvMzInAbk9K0LicDa--V4QlgiUzzL1u7XkJ0s=.d8c7a73c-402a-4813-8fc6-faf9fd07745a@github.com>
 <9-KCaxc5kvdWS_6nETGIRiJgbTEWTWEPxmKT5JHSphw=.0bf35082-2b55-4cfd-bc7a-636a6d7a721a@github.com>
 <fYlGXZDTHTU5qaTisZmz9LLOKG7ShMugqXOMGDmiBPY=.b43629cd-7474-48a9-9e0f-3a9729808294@github.com>
 <-k8sDdAZltd4AcDIIOeKBcKLZ4q9XuTs6sT
 5Mmg2Q9I=.025a647c-34a7-478b-912d-7bfd4a7473b4@github.com>
 <AI90_XpQ47CeM9u1p7brUJMBFddpJgfVXFfBZIYtGfw=.7489df4f-b643-4d9e-b1dd-b15ba1b6a1ad@github.com>
 <RkgzdiaxcFiGijoKtrGci5FPKKcJU7d8vDLBdt1Rftk=.88653824-bf2f-4f5b-9c69-bbb536e49ee0@github.com>
 <gWFZ-lD8CQMjC69_dKMfB7F8a_4ZxUGlWwlUeAwCYlU=.546f5569-0309-45ce-8228-000e56dbbe66@github.com>
 <iyGfHY06FwqKUuJzNQlzG7CvXV9UZtQv0l3RhWUK2RQ=.cdb558c5-1983-4678-b299-35386cb3434a@github.com>
 <K80e0S6-JthHc7DhsDV3BQePXNNEesqd_y1uF9ecLWI=.03e52bae-752b-407c-be5d-ce98c47a83c4@github.com>
 <HRR-kzpsYhfv5i3XdtQokkw4cjUl9fwxTPUlfeHSvC0=.c48b8a56-0dfc-4207-bf3b-9302b5728301@github.com>
 <oleoSKnRqVqnMj0DEkQ6apx-h5L8QJNzc1knyecRByQ=.ee2ad7f0-f54b-4326-b297-b89dc157ed63@github.com>
 <yUYvw-aUQe7ZEunFWC65Okg4Ujd4ndCHrFi2rOV971Y=.dafa0b73-9a26-4060-b38b-c80aca567cd7@github.com>
 <isFfgoZsRbN_XgzjucidTow8HYtH55xM3kv9wyVUYIE=.64039678-0a22-4438-989e-cd0aac358b17@github.com>
Message-ID: <wfpjAwg7O82LY72CrmYU_UtuDxfOtx-tsocb1bjEj5c=.8e3c82ed-3339-481b-ac09-6a1351afeb11@github.com>

On Tue, 29 Mar 2022 07:22:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> @prsadhuk I have pushed latest changes related to AquaLookAndFeel.java file only. The CSystemColors.m is not checked-in because of [selectedContentBackgroundColor](https://developer.apple.com/documentation/appkit/nscolor/2998830-selectedcontentbackgroundcolor) type property build issues. 
>> 
>> 
>>> In my testing in osx10.15 with your fix, I see focus ring is following highlight color and not accent color...did you modify anything in your fix? <img alt="Screenshot 2022-03-28 at 11 52 09 AM" width="688" src="https://user-images.githubusercontent.com/43534309/160338556-117c8e9b-4e78-4368-8040-dfca1d82e1ab.png">
>> 
>> For this scenario, wanted to verify if the **selectionBackground** explicitly set to green in AquaLookAndFeel?
>
> With latest repo and your fix, I put a debug log in deriveContrastFocusRing() and it seems to produce this output (for scenario above)
> 
> selectedBackgroundColor com.apple.laf.AquaImageFactory$SystemColorProxy[r=54,g=128,b=34]
> 
> I see, even if I change the highlight Color to blue, it does not call deriveContrastFocusRing() again and the focus ring remains green although background Color of JTable cell changes to blue [ I think deriveContrastFocusRing needs to be called every time accent color is changed in System->Preferences]
> 
> <img width="537" alt="Screenshot 2022-03-29 at 12 49 59 PM" src="https://user-images.githubusercontent.com/43534309/160556234-cf1732f3-57bd-4530-82e6-e2080e9e1551.png">
> .

I'm currently testing on mac 11.6 and observe that the background color for JTable follows accent color changes (in mac 11.6). Below are screenshots on mac 10.15 vs mac 11.6 under same settings

On Mac 10.15, JTable's background color seems to follow the highlight color changes whereas in 11.6 it follows the accent color changes. In both versions the selectionBackground is obtained from the same property - **alternateSelectedControlColor**

![image](https://user-images.githubusercontent.com/95945681/160733409-612241d0-884d-43d5-9973-4ecd747fb929.png)

The other issue which was related to on-the-fly accent/highlight color changes corresponding to following case - **deriveContrastFocusRing needs to be called every time there is change to System Preference colors** is fixed and the code will be pushed shortly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From prr at openjdk.java.net  Wed Mar 30 03:03:38 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 30 Mar 2022 03:03:38 GMT
Subject: Integrated: 8283701: Add final or sealed modifier to appropriate
 java.awt.color ICC_Profile API classes
In-Reply-To: <yWe4sX3faNOqmRp-Yae2uVhZGQIGVdaZvSYkb5UUzo8=.8e4718a6-64d5-48d6-9549-16ed2072b368@github.com>
References: <yWe4sX3faNOqmRp-Yae2uVhZGQIGVdaZvSYkb5UUzo8=.8e4718a6-64d5-48d6-9549-16ed2072b368@github.com>
Message-ID: <J0RjVqC3ztOo2SK6rJNSensIlBDi068bz9MYu_jo2h8=.943766ec-d7c6-4221-b053-c01d27b17159@github.com>

On Tue, 29 Mar 2022 18:39:49 GMT, Phil Race <prr at openjdk.org> wrote:

> This PR is similar to https://git.openjdk.java.net/jdk/pull/7998 but addresses some Java 2D API color related classes.
> 
> ICC_Profile can be made sealed, and the two extant sub-classes can be made final.
> 
> All regression and JCK tests have passed
> 
> CSR is here https://bugs.openjdk.java.net/browse/JDK-8283891

This pull request has now been integrated.

Changeset: eb5b7128
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/eb5b7128a0ff5a17fcc66cb5f81d23ebec08b415
Stats:     5 lines in 3 files changed: 2 ins; 0 del; 3 mod

8283701: Add final or sealed modifier to appropriate java.awt.color ICC_Profile API classes

Reviewed-by: bpb, aivanov, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8021


From smandalika at openjdk.java.net  Wed Mar 30 05:44:39 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 30 Mar 2022 05:44:39 GMT
Subject: RFR: JDK-8282046: Create a regression test for JDK-8000326 [v2]
In-Reply-To: <ztENpJbd1MeexbWHnCyT-tVMbVdC3-nwFlrM0iyJtAE=.073ad98d-949f-4621-9261-cf1cba3a74f9@github.com>
References: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
 <FtIv0TNvzWFJ2ou3Eiku4QfO_R0fr9kCM8a14_7EocE=.f22595e7-9a17-4389-afe5-30edb3ce2c8d@github.com>
 <Hyq78cD4ChtTJ6esAcW-jPm8SW3QmJW85w9YJ0zaw58=.b29fd74d-1441-4826-821e-5f2c3950991a@github.com>
 <ztENpJbd1MeexbWHnCyT-tVMbVdC3-nwFlrM0iyJtAE=.073ad98d-949f-4621-9261-cf1cba3a74f9@github.com>
Message-ID: <3E4Buv_I73ngEb0-Bvn4xuffwD7N2AlQnVQJrpJP38s=.3041c56d-6319-46a9-8bdf-dfbab45dcf84@github.com>

On Tue, 22 Mar 2022 13:19:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This review is for migrating tests from a closed test suite to open.
>
>> This review is for migrating tests from a closed test suite to open.
> 
> If you know when the test was first introduced, please update the copyright year to include the year when the test was originally written.

@aivanov-jdk Can you please sponsor my changes?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7512


From smandalika at openjdk.java.net  Wed Mar 30 06:34:28 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 30 Mar 2022 06:34:28 GMT
Subject: RFR: 8282640: Create a test for JDK-4740761 [v3]
In-Reply-To: <Rr2xSJSr1_1WFxavIZtwz_rlxf15Yvd5dCxZ_1dcggs=.7415074d-6beb-434e-b463-04388e50b0c8@github.com>
References: <Rr2xSJSr1_1WFxavIZtwz_rlxf15Yvd5dCxZ_1dcggs=.7415074d-6beb-434e-b463-04388e50b0c8@github.com>
Message-ID: <8QBFV040V-QKamp-HHiZS4qjt4NmrIBG_9zDB30kOIw=.f4b571e6-bc6b-4de0-b64b-b23ef846061c@github.com>

> Create a test for [JDK-4740761](https://bugs.openjdk.java.net/browse/JDK-4740761)
> 
> The issue observed is in a JFrame with a JTextField and a JScrollPane which contains focused component. When the JScrollPane was
> is removed from its parent, focus stays with the the scroller
> of the removed JScrollPane, instead of moving to the TextField.
> 
> The test verifies the same - i.e. it verifies that the removal of the scrollpane moves the focus to the JTextField present in the JFrame.
> This review is for migrating tests from a closed test suite to open.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Review comments Fixed: scrollpane accessed on EDT, Copyright Year updated, volatile focussedComponentName

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7686/files
  - new: https://git.openjdk.java.net/jdk/pull/7686/files/44016225..20128b9b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7686&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7686&range=01-02

  Stats: 21 lines in 1 file changed: 11 ins; 3 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7686.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7686/head:pull/7686

PR: https://git.openjdk.java.net/jdk/pull/7686


From duke at openjdk.java.net  Wed Mar 30 08:42:41 2022
From: duke at openjdk.java.net (Hiroshi Miura)
Date: Wed, 30 Mar 2022 08:42:41 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v2]
In-Reply-To: <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
Message-ID: <Pu80qxMUBac6IFjb1U0-Toi2F6fYM6OkSCzpHhoMVA0=.3862c805-ecaf-47aa-92b8-8f9071aaeb90@github.com>

On Thu, 24 Mar 2022 22:36:28 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

>> 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 incrementally with one additional commit since the last revision:
> 
>   8269806: Fix builds with old Freetype (before 2.5)

I can reproduce, but also cannot reproduce with same JVM option ` -Dsun.java2d.xrender=false -Dsun.java2d.opengl=false` on Mint Linux 20.03.

![repro](https://user-images.githubusercontent.com/123720/160788680-96da21f3-6436-48c4-bf48-7ea83adc0dcf.png)

Upper launched from shell, lower run from IDE. Interestingly when click broken glyph, it show a good  image.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4798


From duke at openjdk.java.net  Wed Mar 30 08:53:42 2022
From: duke at openjdk.java.net (Nikita Gubarkov)
Date: Wed, 30 Mar 2022 08:53:42 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v2]
In-Reply-To: <EkOvIjPD4AVTDTRND-BLlgVMmWOyHv1P7961DrdUVHI=.76dab331-2ca6-4a19-a841-5f58dbf3fcfd@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <EFEmi0XMpRDANnNlLvIJrOvw_n3KF0rD4W3Zx8Ks550=.e202eeb5-47d7-453b-b0a6-e658c910a153@github.com>
 <EkOvIjPD4AVTDTRND-BLlgVMmWOyHv1P7961DrdUVHI=.76dab331-2ca6-4a19-a841-5f58dbf3fcfd@github.com>
Message-ID: <nlHJFpgfFdN3PC60BWy25sSiKYqKRC5UptkqbQ57UeY=.af03036f-63d4-43bf-953f-febc321df651@github.com>

On Tue, 29 Mar 2022 17:11:54 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8269806: Fix builds with old Freetype (before 2.5)
>
> I was able to reproduce the problem. I used the Xorg session instead of the default (Wayland) one and provided the option mentioned above (-Dsun.java2d.xrender=false)
> ![image](https://user-images.githubusercontent.com/3232337/160667606-7f3084cb-5890-4061-9e0c-d63384d849d8.png)

I managed to reproduce it too on Xorg, thanks @avu!
Will fix this

-------------

PR: https://git.openjdk.java.net/jdk/pull/4798


From smandalika at openjdk.java.net  Wed Mar 30 10:05:22 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 30 Mar 2022 10:05:22 GMT
Subject: RFR: JDK-8282777: Create a Regression test for JDK-4515031 [v3]
In-Reply-To: <D8K1EcGCjhQQzplHsgYncKPvGmSPhrAs7RNDIl_pQlo=.e8d60f67-9cf4-4ac7-957b-ddbecffc85de@github.com>
References: <D8K1EcGCjhQQzplHsgYncKPvGmSPhrAs7RNDIl_pQlo=.e8d60f67-9cf4-4ac7-957b-ddbecffc85de@github.com>
Message-ID: <dQC9zgpn-bZxlGt1-tES09zUq849yPRfM_BcCW7zrqg=.ae67997b-49dc-4b67-a90c-bf7e4d0592c8@github.com>

> Create a Regression test for [JDK-4515031](https://bugs.openjdk.java.net/browse/JDK-4515031)
> 
> The issue indicates the need for a a getAccessibleDescription being implemented for the JFileChooser.
> The test added verifies the same.
> This review is for migrating tests from a closed test suite to open.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Review Comments Fixed: Button on EDT, split long lines, volatile description string

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7738/files
  - new: https://git.openjdk.java.net/jdk/pull/7738/files/c239c2c9..76db0fa6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7738&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7738&range=01-02

  Stats: 29 lines in 1 file changed: 15 ins; 7 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7738.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7738/head:pull/7738

PR: https://git.openjdk.java.net/jdk/pull/7738


From mvs at openjdk.java.net  Wed Mar 30 10:28:39 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 30 Mar 2022 10:28:39 GMT
Subject: RFR: 8283507: Create a regression test for RFE 4287690 [v2]
In-Reply-To: <WnnAS2V7S8W5YMMCMbzOqtSYkhFbVrsakrGPFRRklYg=.4b504ee1-564d-44c1-be0a-07d90a93d288@github.com>
References: <SMPz0WRpMUC4SuuVSmlG6rsG_QudZ-1hCbjUzeMIdqk=.8318c1a4-4db6-4c0b-b24c-0b25b3d932a2@github.com>
 <WnnAS2V7S8W5YMMCMbzOqtSYkhFbVrsakrGPFRRklYg=.4b504ee1-564d-44c1-be0a-07d90a93d288@github.com>
Message-ID: <Uf6lVwkGdth48pq8_1oEgcfJ1ug0Vzyiu9cUxbGayV8=.ec1bf26b-e20f-49b6-9d4f-20bf1e7c8f79@github.com>

On Wed, 23 Mar 2022 05:31:10 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Create a regression test for [JDK-4287690](https://bugs.openjdk.java.net/browse/JDK-4287690)
>> Issue description:
>> I want JComboBox to send an event just before the popup (drop down) list is displayed.
>> 
>> Fix:
>> This requires some additional API targeted for major release of the JDK (1.4).The PopupMenuEvent will from the JPopupMenu will be forwarded to the JComboBox. A client of the JComboBox can register itself as a PopupMenuListener to receive the notification.
>> So JComboBox should send drop down events when the drop down popup is visible as well as invisible. JComboBox.addPopupMenuListener(PopupMenuListener) can be used to register for pop up events.
>> 
>> Testing:
>> Tested using Mach5 in all platforms available(macos,linux and windows) and got all pass.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added one more related bug id 4331058 to @bug tag

Any volunteers ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7906


From mvs at openjdk.java.net  Wed Mar 30 10:32:40 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 30 Mar 2022 10:32:40 GMT
Subject: RFR: 8283623: Create an automated regression test for JDK-4525475
In-Reply-To: <TOQfFvM5drazhFLU-GG_SBYbQ3fy5P2LFKetn5b6Mrg=.715440f9-1de7-423a-8a05-136a0649664d@github.com>
References: <ovauTi1CSYZ068j2-fLVDWsy-0LMRrehH2ng_KHgtVs=.7c5b9f95-3235-42dd-81f5-678b3b91e46f@github.com>
 <TOQfFvM5drazhFLU-GG_SBYbQ3fy5P2LFKetn5b6Mrg=.715440f9-1de7-423a-8a05-136a0649664d@github.com>
Message-ID: <TOwt2wYs_ho51Dyt0hB6MRMi7nXBK6yctcAP-xs7X5g=.2839f5b4-9df7-4fb4-8c8d-21e33866c302@github.com>

On Tue, 29 Mar 2022 22:08:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Write a regression test for [JDK-4525475](https://bugs.openjdk.java.net/browse/JDK-4525475)
>> 
>> Issue:
>> JFileChooser allows modification to the file-system by way of the "New Folder"
>> button, and the ability to rename file/folder names. There is no method on
>> JFileChooser which indicates that this type of modification should not be
>> allowed within the given JFileChooser.
>> 
>> Testing:
>> 1. Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.
>> 2. Tested in original failed Java version and the fixed version;
>> Java 1.4.0 -> Test Failed.
>> $ j2sdk1.4.0/bin/java Bug4525475
>> LookAndFeel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>> Name = Go Up, readOnly = true
>> Name = New Folder, readOnly = true
>> Its a Read Only JFileChooser and has a New Folder Button. So Test Failed.
>> Name = Go Up, readOnly = false
>> Name = New Folder, readOnly = false
>> Failed
>> 
>> Java 1.5.0 -> Test Passed.
>> $ jdk1.5.0/bin/java Bug4525475
>> LookAndFeel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>> Name = Go Up, readOnly = true
>> Name = Go Up, readOnly = false
>> Name = New Folder, readOnly = false
>> Passed
>
> test/jdk/javax/swing/JFileChooser/4525475/JFileChooserReadOnlyTest.java line 73:
> 
>> 71: 
>> 72:             // Test2, Read/Write JFileChooser
>> 73:             if (!(laf.contains("Motif") || laf.contains("Aqua"))) {
> 
> Can we update the test to find the correct buttons for these L&Fs as well?

For Motif L&F, the 'New Folder' button is not shown anywhere irrespective of what we set in UI defaults, for any platform. But Aqua L&F behaves similar to the native FileChooser, like for 'Open' dialog it will not show 'New Folder' button, but it will show 'New Folder' button for 'Save' dialog.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7969


From smandalika at openjdk.java.net  Wed Mar 30 10:33:32 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 30 Mar 2022 10:33:32 GMT
Subject: RFR: 8282640: Create a test for JDK-4740761 [v4]
In-Reply-To: <Rr2xSJSr1_1WFxavIZtwz_rlxf15Yvd5dCxZ_1dcggs=.7415074d-6beb-434e-b463-04388e50b0c8@github.com>
References: <Rr2xSJSr1_1WFxavIZtwz_rlxf15Yvd5dCxZ_1dcggs=.7415074d-6beb-434e-b463-04388e50b0c8@github.com>
Message-ID: <MDUSF5nh9DXsJ9Xy3eLx5QL1jlOks-BYrwQGBYHQbUY=.91f30164-3661-46d3-a3d6-26d15b4e324c@github.com>

> Create a test for [JDK-4740761](https://bugs.openjdk.java.net/browse/JDK-4740761)
> 
> The issue observed is in a JFrame with a JTextField and a JScrollPane which contains focused component. When the JScrollPane was
> is removed from its parent, focus stays with the the scroller
> of the removed JScrollPane, instead of moving to the TextField.
> 
> The test verifies the same - i.e. it verifies that the removal of the scrollpane moves the focus to the JTextField present in the JFrame.
> This review is for migrating tests from a closed test suite to open.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Review Comment Fixed: Line Length fixed to < 80 characters.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7686/files
  - new: https://git.openjdk.java.net/jdk/pull/7686/files/20128b9b..141cd856

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7686&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7686&range=02-03

  Stats: 14 lines in 1 file changed: 5 ins; 1 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7686.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7686/head:pull/7686

PR: https://git.openjdk.java.net/jdk/pull/7686


From mvs at openjdk.java.net  Wed Mar 30 10:45:26 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 30 Mar 2022 10:45:26 GMT
Subject: RFR: 8283623: Create an automated regression test for JDK-4525475
 [v2]
In-Reply-To: <ovauTi1CSYZ068j2-fLVDWsy-0LMRrehH2ng_KHgtVs=.7c5b9f95-3235-42dd-81f5-678b3b91e46f@github.com>
References: <ovauTi1CSYZ068j2-fLVDWsy-0LMRrehH2ng_KHgtVs=.7c5b9f95-3235-42dd-81f5-678b3b91e46f@github.com>
Message-ID: <w5bzPq4v_jBEpufL6xEeqPJOnMDwNmsJWMWNh8tSWFY=.35a68744-74a9-4840-81e3-56567611e974@github.com>

> Write a regression test for [JDK-4525475](https://bugs.openjdk.java.net/browse/JDK-4525475)
> 
> Issue:
> JFileChooser allows modification to the file-system by way of the "New Folder"
> button, and the ability to rename file/folder names. There is no method on
> JFileChooser which indicates that this type of modification should not be
> allowed within the given JFileChooser.
> 
> Testing:
> 1. Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.
> 2. Tested in original failed Java version and the fixed version;
> Java 1.4.0 -> Test Failed.
> $ j2sdk1.4.0/bin/java Bug4525475
> LookAndFeel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> Name = Go Up, readOnly = true
> Name = New Folder, readOnly = true
> Its a Read Only JFileChooser and has a New Folder Button. So Test Failed.
> Name = Go Up, readOnly = false
> Name = New Folder, readOnly = false
> Failed
> 
> Java 1.5.0 -> Test Passed.
> $ jdk1.5.0/bin/java Bug4525475
> LookAndFeel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> Name = Go Up, readOnly = true
> Name = Go Up, readOnly = false
> Name = New Folder, readOnly = false
> Passed

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed: code for the Swing lib executed on EDT

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7969/files
  - new: https://git.openjdk.java.net/jdk/pull/7969/files/1880311e..ba85beed

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7969&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7969&range=00-01

  Stats: 11 lines in 1 file changed: 5 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7969.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7969/head:pull/7969

PR: https://git.openjdk.java.net/jdk/pull/7969


From mvs at openjdk.java.net  Wed Mar 30 10:45:26 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 30 Mar 2022 10:45:26 GMT
Subject: RFR: 8283623: Create an automated regression test for JDK-4525475
 [v2]
In-Reply-To: <TOQfFvM5drazhFLU-GG_SBYbQ3fy5P2LFKetn5b6Mrg=.715440f9-1de7-423a-8a05-136a0649664d@github.com>
References: <ovauTi1CSYZ068j2-fLVDWsy-0LMRrehH2ng_KHgtVs=.7c5b9f95-3235-42dd-81f5-678b3b91e46f@github.com>
 <TOQfFvM5drazhFLU-GG_SBYbQ3fy5P2LFKetn5b6Mrg=.715440f9-1de7-423a-8a05-136a0649664d@github.com>
Message-ID: <ip_Xg4_z1UY7pbGZp1Y9kNFSmjXAjrnNvt5UF2777FY=.167feab2-d1b0-41e1-9a32-beb78e3ee842@github.com>

On Tue, 29 Mar 2022 22:06:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments fixed: code for the Swing lib executed on EDT
>
> test/jdk/javax/swing/JFileChooser/4525475/JFileChooserReadOnlyTest.java line 93:
> 
>> 91:     }
>> 92: 
>> 93:     private static void createAndTestCustomFileChooser(boolean readOnly) {
> 
> The code for the Swing lib should be executed on EDT.

Done

-------------

PR: https://git.openjdk.java.net/jdk/pull/7969


From mvs at openjdk.java.net  Wed Mar 30 10:45:43 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 30 Mar 2022 10:45:43 GMT
Subject: RFR: 8283624: Create an automated regression test for RFE-4390885
In-Reply-To: <DfOvs0ck3_ucgdZG8gdlmXPriMoEM9-RjaveRlmRZYA=.b6690b6a-4a51-4c98-b5ee-6409fe4b0f84@github.com>
References: <DfOvs0ck3_ucgdZG8gdlmXPriMoEM9-RjaveRlmRZYA=.b6690b6a-4a51-4c98-b5ee-6409fe4b0f84@github.com>
Message-ID: <bzA3wek_EZMDk_A6jlZmhWhCKxJuxlUHDVZT5Sn_PwY=.f03116fa-a7b8-4a90-8769-cfc55c089349@github.com>

On Mon, 28 Mar 2022 14:17:17 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Write a regression test for [JDK-4390885](https://bugs.openjdk.java.net/browse/JDK-4390885) Enhancement Request.
> 
> Issue:
> Please add the ability to set the location of a JFileChooser. This might be a
> bug, but JFileChooser.setLocation() has no effect when
> JFileChooser.showXXXXDialog() is called. This is becoming very important as the
> popularity of multiple monitors is increasing. These dialogs show up on the
> wrong monitor which is really annoying. Also due to bug #4189244 I am unable to
> avoid painting problems by positioning the dialog away from the menu item that
> initiated it.
> 
> Fix:
> Now it's possible to set the location of Dialog in JFileChooser.
> 
> Testing:
> 1. Tested in Mach5 10 times per platform(macos,linux,windows) and got all Pass.

Any volunteers ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7996


From smandalika at openjdk.java.net  Wed Mar 30 10:54:32 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 30 Mar 2022 10:54:32 GMT
Subject: RFR: JDK-8282778: Create a regression test for JDK-4699544 [v3]
In-Reply-To: <IDgBuK7aFq5DBF_2mWS-l27LMVG9XSZe-2Zl_bITg3M=.527d9ca4-e081-4ce2-b123-1f2580f5e017@github.com>
References: <IDgBuK7aFq5DBF_2mWS-l27LMVG9XSZe-2Zl_bITg3M=.527d9ca4-e081-4ce2-b123-1f2580f5e017@github.com>
Message-ID: <i_w9f3i_ZuPJCjoTOdQJwr0ImQ46n59CHiUi4GjJWHw=.15d13232-c70f-49a6-9315-d5bf1e902a9c@github.com>

> Create a regression test for JDK-4699544
> 
> The subclass of javax.swing.JRootPane (AccessibleJRootPane) that implements the accessibility interface javax.accessibility.AccessibleComponent is derived from java.awt.AccessibleAWTComponent, which returns null for getAccessibleAt() because a component does not necessarily have childs.
> 
> The root pane always has a content pane child, so getAccessibleAt() should be overwritten by AccessibleJRootPane appropriately.
> The test added verifies the same.
> This review is for migrating tests from a closed test suite to open.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Review Comments Fixed: Frame on EDT, Line length <= 80 characters

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7739/files
  - new: https://git.openjdk.java.net/jdk/pull/7739/files/9ecb27e8..bcc3bd6c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7739&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7739&range=01-02

  Stats: 12 lines in 1 file changed: 2 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7739.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7739/head:pull/7739

PR: https://git.openjdk.java.net/jdk/pull/7739


From kcr at openjdk.java.net  Wed Mar 30 11:35:38 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 30 Mar 2022 11:35:38 GMT
Subject: RFR: 8283805: [REDO] JDK 19 L10n resource files update - msgdrop
 10
In-Reply-To: <YVEmLu-_cOvRQdHfANi62d5Oh6Aba_Kpy4BhXGRBFSk=.9a367c1b-aa8b-46bf-85fd-a00292cbaea0@github.com>
References: <YVEmLu-_cOvRQdHfANi62d5Oh6Aba_Kpy4BhXGRBFSk=.9a367c1b-aa8b-46bf-85fd-a00292cbaea0@github.com>
Message-ID: <EnIpfAYY92S_YJGTVXtEYAlGCdqtzUcbzEmSV1_Zduo=.eb6608f2-1158-474a-80bb-118baf99af89@github.com>

On Wed, 30 Mar 2022 00:43:49 GMT, Alisen Chung <achung at openjdk.org> wrote:

> redo of 8280400

Since this is identical to the original fix, I would expect the same Tier2 test failure as reported in [JDK-8283804](https://bugs.openjdk.java.net/browse/JDK-8283804).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8026


From asemenov at openjdk.java.net  Wed Mar 30 15:31:12 2022
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Wed, 30 Mar 2022 15:31:12 GMT
Subject: RFR: 8284014 Menu items with submenus in JPopupMEnu are not spoken on
 macOS
Message-ID: <uoV0A08vCi-i0yZ-gbdQaqk_huKTX1ohMqwViBID0xA=.5624eac6-1ba9-4c30-affa-34cdd15e73fb@github.com>

If the JPopupMenu has menu items with submenus, those items are not spoken by VoiceOver.

@forantar @azuev-java please review.

-------------

Commit messages:
 - 8284014 Menu items with submenus in JPopupMEnu are not spoken on macOS

Changes: https://git.openjdk.java.net/jdk/pull/8043/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8043&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284014
  Stats: 111 lines in 3 files changed: 106 ins; 2 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8043.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8043/head:pull/8043

PR: https://git.openjdk.java.net/jdk/pull/8043


From naoto at openjdk.java.net  Wed Mar 30 15:48:38 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 30 Mar 2022 15:48:38 GMT
Subject: RFR: 8283805: [REDO] JDK 19 L10n resource files update - msgdrop
 10
In-Reply-To: <YVEmLu-_cOvRQdHfANi62d5Oh6Aba_Kpy4BhXGRBFSk=.9a367c1b-aa8b-46bf-85fd-a00292cbaea0@github.com>
References: <YVEmLu-_cOvRQdHfANi62d5Oh6Aba_Kpy4BhXGRBFSk=.9a367c1b-aa8b-46bf-85fd-a00292cbaea0@github.com>
Message-ID: <a41NNQJWMB7s3ZKC9Oc0wOR6djcVyJwClVqybrBHmto=.7cabbe09-19b7-414f-8843-c2490eab98ea@github.com>

On Wed, 30 Mar 2022 00:43:49 GMT, Alisen Chung <achung at openjdk.org> wrote:

> redo of 8280400

I believe `src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties` and `test/jdk/sun/text/resources/LocaleData` have to be adjusted according to the l10n changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8026


From smandalika at openjdk.java.net  Wed Mar 30 16:05:40 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 30 Mar 2022 16:05:40 GMT
Subject: RFR: JDK-8282778: Create a regression test for JDK-4699544 [v2]
In-Reply-To: <qbXIh4dX5xaEHhKSehKjUZ2HTpezEPdWTG7mQVFn4Nc=.390ea8cd-38d1-4d5c-9e46-003a5624565a@github.com>
References: <IDgBuK7aFq5DBF_2mWS-l27LMVG9XSZe-2Zl_bITg3M=.527d9ca4-e081-4ce2-b123-1f2580f5e017@github.com>
 <e15b5kZEOO-Likj62PfSpWiQsFF3aioponmsDrh21EU=.f4538490-131a-4d9c-aff7-b0ce10951973@github.com>
 <qbXIh4dX5xaEHhKSehKjUZ2HTpezEPdWTG7mQVFn4Nc=.390ea8cd-38d1-4d5c-9e46-003a5624565a@github.com>
Message-ID: <1xVgck16hOrOypl5e68QD1hZArdvern4zS21jbGI3_w=.16f137a0-e4fa-40fa-a542-9e9d2849e352@github.com>

On Tue, 29 Mar 2022 22:37:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added @bug keyword
>
> test/jdk/javax/accessibility/4699544/JRootPaneAccessiblAtTest.java line 55:
> 
>> 53: 
>> 54:     public static void main(String args[]) {
>> 55:         new JRootPaneAccessiblAtTest();
> 
> This is the subclass of the JFrame, which should be accessed on the EDT.

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7739


From smandalika at openjdk.java.net  Wed Mar 30 16:09:46 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 30 Mar 2022 16:09:46 GMT
Subject: Integrated: JDK-8282046: Create a regression test for JDK-8000326
In-Reply-To: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
References: <XxcdEmeJXrxpqq2RMyrDP80jrQ4gCWpX9_0ep-99VWg=.06478449-d3d4-4275-ae52-a56418fe37ec@github.com>
Message-ID: <kyM2h_mCbJmF1F9h1zi2y3VSEFl9twnnVyFuCzOZ7FA=.a68aabba-c64e-4b65-a812-75c5cf03f46d@github.com>

On Thu, 17 Feb 2022 09:56:45 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Create a regression test for CCC8000326
> 
> Issue is identified by [JDK-8000326](https://bugs.openjdk.java.net/browse/JDK-8000326), which identifies that after focus moves into JMenuBar, whose focus traversal key is disabled by default, it never moves to other focusable component.
>  
> By default, pressing the Tab key does not transfer focus from a JMenuBar which is added to a container together with other Swing components, because the focusTraversalKeysEnabled property of JMenuBar is set to false. To resolve this, you should call the JMenuBar.setFocusTraversalKeysEnabled(true) method.
>  
> The test verifies focus traversal for the above described scenario.
> This review is for migrating tests from a closed test suite to open.

This pull request has now been integrated.

Changeset: 97c7298a
Author:    Srinivas Mandalika <smandalika at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/97c7298a39cdd683508617d904c83cc3261da15b
Stats:     105 lines in 1 file changed: 105 ins; 0 del; 0 mod

8282046: Create a regression test for JDK-8000326

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/7512


From prr at openjdk.java.net  Wed Mar 30 17:02:39 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 30 Mar 2022 17:02:39 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v7]
In-Reply-To: <KMPhFqkwAp0rCjmrAJalrI5fMrnj4TqKl1c2UlaSHYI=.edf6eefd-b1f7-4436-9a05-428b4c397c8d@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
 <KMPhFqkwAp0rCjmrAJalrI5fMrnj4TqKl1c2UlaSHYI=.edf6eefd-b1f7-4436-9a05-428b4c397c8d@github.com>
Message-ID: <Ulvn_7XNFmqmZi2k-RHoYpRjuUZWSOZb3L8-sfRSxhI=.6f191b33-b232-4703-aaff-69d7f70ce528@github.com>

On Mon, 28 Mar 2022 15:53:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   scale stroke width at higher scalings
>
> test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 46:
> 
>> 44:  * @bug 8279614
>> 45:  * @summary The left line of the TitledBorder is not painted on 150 scale factor
>> 46:  * @requires (os.family == "windows")
> 
> The test is not Windows specific, is it? Yet Java supports fractional scales on Windows only at the moment, right?
> 
> I still think it makes sense to run the test on Linux and macOS for 100%, 200% and 300% which are supported.

Well the test is setting the Windows L&F, and evaluating its rendering.
Which seems to me to make it windows-specific, as written.
The test would would need to run through all the L&Fs if it is actually valid to do so.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From duke at openjdk.java.net  Wed Mar 30 17:08:37 2022
From: duke at openjdk.java.net (Nikita Gubarkov)
Date: Wed, 30 Mar 2022 17:08:37 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v3]
In-Reply-To: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
Message-ID: <OcvupXGyRpq-jvVetEJfUNZh5SOvFpDfnU3lVetXQAM=.9e335175-b56d-42d9-b8ab-a487716f0c8b@github.com>

> 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 incrementally with one additional commit since the last revision:

  8269806: Fix emoji rendering with -Dsun.java2d.xrender=false and AA=OFF

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4798/files
  - new: https://git.openjdk.java.net/jdk/pull/4798/files/5d99aee6..9dbed75f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4798&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4798&range=01-02

  Stats: 37 lines in 3 files changed: 23 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4798.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4798/head:pull/4798

PR: https://git.openjdk.java.net/jdk/pull/4798


From azvegint at openjdk.java.net  Wed Mar 30 17:12:42 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 30 Mar 2022 17:12:42 GMT
Subject: Integrated: 8282374: Java_sun_awt_X11_XlibWrapper_XSynchronize is
 wrong and unused
In-Reply-To: <tbxrHb9ntPIGPWVdXA08iyq3Fg_jpvK5vUO5dagVsXs=.bb42b7a7-ea14-437d-999c-15f40b61b05a@github.com>
References: <tbxrHb9ntPIGPWVdXA08iyq3Fg_jpvK5vUO5dagVsXs=.bb42b7a7-ea14-437d-999c-15f40b61b05a@github.com>
Message-ID: <12A1vRV6cOo0DUaa8qG0sZEWyoTozVSsYb_V-5g6MaQ=.ccab28e5-140c-4688-b4cd-0b9dbcbb5ca7@github.com>

On Tue, 29 Mar 2022 12:55:34 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This fix simply removes unused `XSynchronize` method.
> 
> Alternatively its return type may be changed to `long`, but I think less code is better.
> 
> Testing is green.

This pull request has now been integrated.

Changeset: ec9ab558
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ec9ab558a393992d9188fd22d1e831649bd434aa
Stats:     13 lines in 2 files changed: 0 ins; 12 del; 1 mod

8282374: Java_sun_awt_X11_XlibWrapper_XSynchronize is wrong and unused

Reviewed-by: serb, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/8016


From prr at openjdk.java.net  Wed Mar 30 17:30:42 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 30 Mar 2022 17:30:42 GMT
Subject: Integrated: 8283700: Add final or sealed modifier to appropriate
 java.awt API classes
In-Reply-To: <ACVjMBKNkkTQlSh3-PKmvc_Nlr6kIWZpuBb4D9WsNBs=.ef511416-40f1-428d-abd8-1ddf76142174@github.com>
References: <ACVjMBKNkkTQlSh3-PKmvc_Nlr6kIWZpuBb4D9WsNBs=.ef511416-40f1-428d-abd8-1ddf76142174@github.com>
Message-ID: <2rVoNf1zk-e6GTb66mtJpOaya7b186RdBhkZSF1_Eqs=.97136ff1-1eb9-4419-909d-e4210cb0e08b@github.com>

On Mon, 28 Mar 2022 16:30:50 GMT, Phil Race <prr at openjdk.org> wrote:

> JDK 17 delivered JEP 409: Sealed Classes : https://openjdk.java.net/jeps/409
> In essence this JEP allows a class to limit which classes can subclass it.
> If a class has no subclasses and cannot be subclassed outside the JDK it can also be made final.
> Suitable classes across the JDK are being retro-fitted to be sealed (or made final) where it can be done compatibly.
> This fix takes care of several AWT classes which were identified.
> If later we need to remove sealed or make a class non-final that will also be a compatible change,
> so we aren't locking ourselves into this.
> 
> All our automated regression tests - plus JCK tests have been run.
> 
> This will require a CSR

This pull request has now been integrated.

Changeset: e85fa2f0
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e85fa2f04b17531862c2469597674d60ad25a19f
Stats:     29 lines in 12 files changed: 17 ins; 0 del; 12 mod

8283700: Add final or sealed modifier to appropriate java.awt API classes

Reviewed-by: darcy, aivanov, serb, psadhukhan

-------------

PR: https://git.openjdk.java.net/jdk/pull/7998


From aivanov at openjdk.java.net  Wed Mar 30 18:17:42 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 30 Mar 2022 18:17:42 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v7]
In-Reply-To: <Ulvn_7XNFmqmZi2k-RHoYpRjuUZWSOZb3L8-sfRSxhI=.6f191b33-b232-4703-aaff-69d7f70ce528@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
 <KMPhFqkwAp0rCjmrAJalrI5fMrnj4TqKl1c2UlaSHYI=.edf6eefd-b1f7-4436-9a05-428b4c397c8d@github.com>
 <Ulvn_7XNFmqmZi2k-RHoYpRjuUZWSOZb3L8-sfRSxhI=.6f191b33-b232-4703-aaff-69d7f70ce528@github.com>
Message-ID: <TK6qR3v443PynS9CgRV_XlXGtO-9m9xSYtJzdy0jsQ8=.d9f7b3a1-0cb2-4662-9e7d-f3e7bf992e9c@github.com>

On Wed, 30 Mar 2022 16:59:50 GMT, Phil Race <prr at openjdk.org> wrote:

> Well the test is setting the Windows L&F, and evaluating its rendering. Which seems to me to make it windows-specific, as written. The test would would need to run through all the L&Fs if it is actually valid to do so.

Right, the bug was reported on Windows. The Windows L&F uses `EtchedBorder` for `TitledBorder` whereas other L&F don't. From this point of view, the bug is Windows-specific.

Yet the fix is in the shared code, in the `javax.swing.border.EtchedBorder` class which is not Look-and-Feel specific. I'm sure the problem can be reproduced if `EtchedBorder` is used directly rather than via `TitledBorder`. Yet you wouldn't see the bug on Linux and macOS because these two platforms support only integer scales, but the issue occurs with fractional scales only.

If the test uses `EtchedBorder` directly, there'll be no need to iterate L&Fs. The test sets `EtchedBorder` border to a panel, the panel renders the border.

* In fact, Windows 10 renders titled border flat: one grey line instead of etched border that was used in previous versions. Shall we update Swing's Windows L&F?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From duke at openjdk.java.net  Wed Mar 30 19:10:18 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Wed, 30 Mar 2022 19:10:18 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v6]
In-Reply-To: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
Message-ID: <aZ-FXV3qBSy_Nlg3DmUpgbjaKhs12PvlwYhF4JX9fGE=.1a19c132-1088-4f30-b3a9-00022ede313d@github.com>

> Previously while tabbing through the JTable cell, the cell highlighter/focus ring was not visible against the selection background. 
> 
> Changes are made to Aqua LAF to derive a lighter focus ring color by changing saturation and setting brightness component to 100% of selection background color so that it is visible while tabbing through `JTable` cells. A new method is added for this purpose which takes in `selectionBackground` color, does adjustment to saturation and brightness manipulation and returns a new focus ring color. There are edge cases where the HSB transformation does not yield the right focus ring color, for these cases a default color is returned that can be seen against the `selectionBackground`.
> 
> **Edge Cases**
> **Selection Background**     -----       **Returned Focus Ring Color**
> - White/ Black/Gray                        ----->          Light Gray
> 
> The following HSB chart was used [Chart Link](https://codepen.io/HunorMarton/details/eWvewo), to determine the best saturation offsets used in deriveContrastFocusRing method.
> 
> A test case is added to compare the RGB difference between the original focus ring color & selection background and the brighter focus ring color & selection background.
> 
> PS: The native L&F (Mac OS) and Swing L&F for JTable cell tabbing differs (on native tables the cell background turns white on focus with a cell focus ring). Since the background for Swing tables can be set by users and also overridden by subclassing `DefaultTableCellRenderer`, and to adhere to current implementation of Swing, the white cell background changes are not incorporated. Only the Focus Ring/ Cell Highlighter is made more prominent against the selection background.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  on-the-fly focus ring color changes added

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7768/files
  - new: https://git.openjdk.java.net/jdk/pull/7768/files/c71358dd..f6c9b6c0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7768&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7768&range=04-05

  Stats: 61 lines in 3 files changed: 31 ins; 1 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7768/head:pull/7768

PR: https://git.openjdk.java.net/jdk/pull/7768


From zgu at openjdk.java.net  Wed Mar 30 19:20:54 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 30 Mar 2022 19:20:54 GMT
Subject: RFR: 8284023: java.sun.awt.X11GraphicsDevice.getDoubleBufferVisuals()
 leaks XdbeScreenVisualInfo
Message-ID: <6vPxcf3BllwA1Di0WXKrNF9TFKjPnLnfIAuSO8PyV3s=.34ac5f51-a610-4809-9a1e-f822d955340b@github.com>

Please review this small patch that fixes memory leak of `XdbeScreenVisualInfo` obtained from `XdbeGetVisualInfo()` method call.

Test:
- [x] jdk_awt

-------------

Commit messages:
 - 8284023: java.sun.awt.X11GraphicsDevice.getDoubleBufferVisuals() leaks XdbeScreenVisualInfo

Changes: https://git.openjdk.java.net/jdk/pull/8047/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8047&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284023
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8047.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8047/head:pull/8047

PR: https://git.openjdk.java.net/jdk/pull/8047


From ebakke at ultorg.com  Wed Mar 30 19:22:33 2022
From: ebakke at ultorg.com (Eirik Bakke)
Date: Wed, 30 Mar 2022 19:22:33 +0000
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v7]
In-Reply-To: <TK6qR3v443PynS9CgRV_XlXGtO-9m9xSYtJzdy0jsQ8=.d9f7b3a1-0cb2-4662-9e7d-f3e7bf992e9c@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
 <KMPhFqkwAp0rCjmrAJalrI5fMrnj4TqKl1c2UlaSHYI=.edf6eefd-b1f7-4436-9a05-428b4c397c8d@github.com>
 <Ulvn_7XNFmqmZi2k-RHoYpRjuUZWSOZb3L8-sfRSxhI=.6f191b33-b232-4703-aaff-69d7f70ce528@github.com>
 <TK6qR3v443PynS9CgRV_XlXGtO-9m9xSYtJzdy0jsQ8=.d9f7b3a1-0cb2-4662-9e7d-f3e7bf992e9c@github.com>
Message-ID: <BL0PR20MB2098F50C04ACFFEC67B24599A11F9@BL0PR20MB2098.namprd20.prod.outlook.com>

> In fact, Windows 10 renders titled border flat: one grey line instead of etched border that was used in previous versions. Shall we update Swing's Windows L&F?

In the Windows L&F, the following borders all display badly on 150% HiDPI scaling, and would benefit from a fix:

TextField.border, PasswordField.border, FormattedTextField.border, ScrollPane.border, PopupMenu.border, Menu.border, ToolTip.border, as well as the borders for JSpinner and JComboBox.

I once did some work to fix these 150% HiDPI scaling border issues on the NetBeans IDE; see https://github.com/apache/netbeans/pull/1777 and https://github.com/apache/netbeans/pull/2965 and https://github.com/apache/netbeans/blob/master/platform/o.n.swing.plaf/src/org/netbeans/swing/plaf/windows8/Windows8LFCustoms.java

The issue https://bugs.openjdk.java.net/browse/JDK-8241561 is also similar.

Just passing by... thanks for your work on maintaining Swing!

-- Eirik Bakke
(Committer on the Apache NetBeans project.)

-----Original Message-----
From: client-libs-dev <client-libs-dev-retn at openjdk.java.net> On Behalf Of Alexey Ivanov
Sent: Wednesday, March 30, 2022 2:18 PM
To: client-libs-dev at openjdk.java.net
Subject: Re: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v7]

On Wed, 30 Mar 2022 16:59:50 GMT, Phil Race <prr at openjdk.org> wrote:

> Well the test is setting the Windows L&F, and evaluating its rendering. Which seems to me to make it windows-specific, as written. The test would would need to run through all the L&Fs if it is actually valid to do so.

Right, the bug was reported on Windows. The Windows L&F uses `EtchedBorder` for `TitledBorder` whereas other L&F don't. From this point of view, the bug is Windows-specific.

Yet the fix is in the shared code, in the `javax.swing.border.EtchedBorder` class which is not Look-and-Feel specific. I'm sure the problem can be reproduced if `EtchedBorder` is used directly rather than via `TitledBorder`. Yet you wouldn't see the bug on Linux and macOS because these two platforms support only integer scales, but the issue occurs with fractional scales only.

If the test uses `EtchedBorder` directly, there'll be no need to iterate L&Fs. The test sets `EtchedBorder` border to a panel, the panel renders the border.

* In fact, Windows 10 renders titled border flat: one grey line instead of etched border that was used in previous versions. Shall we update Swing's Windows L&F?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449

From duke at openjdk.java.net  Wed Mar 30 19:23:40 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Wed, 30 Mar 2022 19:23:40 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v3]
In-Reply-To: <isFfgoZsRbN_XgzjucidTow8HYtH55xM3kv9wyVUYIE=.64039678-0a22-4438-989e-cd0aac358b17@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <2OoG2FYkhgWq33h3JgxSkRPriOEqrr-Bj6cxCgMTG40=.be6e1aa5-49d9-4ab9-b840-c66cabaae5db@github.com>
 <NNBXDt8tp8B6vpZTwlgyyevgNpCu4JSUuZH5dhPDpGE=.bed68752-4976-4881-b021-dc9b939d4965@github.com>
 <oAZ5tpWpksvN6sfEYoblyucXf_EqcxKAIiVvkvIugjU=.a10e37ec-b8e8-4ac3-9faf-f2a8d85189af@github.com>
 <r9ujiKOC7dRsKCLNjUEt-V8mCstzXKJLFPRQ1O6kqKs=.2b96988b-85c6-45d5-9d95-2e0112b458fb@github.com>
 <AUeNFfcZNdDhRKJExOY7lT7_eG07ZQ_E124iHS_oiVI=.af2824b3-dc46-4318-92c3-27a861269339@github.com>
 <0U4ZvK_ui_ieG7pPZAdhL1AyrJYQNqT0A_HRJIE8InQ=.26f7a810-a6a0-47d0-99d9-e2ffcfebe596@github.com>
 <ML4CSxlvMzInAbk9K0LicDa--V4QlgiUzzL1u7XkJ0s=.d8c7a73c-402a-4813-8fc6-faf9fd07745a@github.com>
 <9-KCaxc5kvdWS_6nETGIRiJgbTEWTWEPxmKT5JHSphw=.0bf35082-2b55-4cfd-bc7a-636a6d7a721a@github.com>
 <fYlGXZDTHTU5qaTisZmz9LLOKG7ShMugqXOMGDmiBPY=.b43629cd-7474-48a9-9e0f-3a9729808294@github.com>
 <-k8sDdAZltd4AcDIIOeKBcKLZ4q9XuTs6sT
 5Mmg2Q9I=.025a647c-34a7-478b-912d-7bfd4a7473b4@github.com>
 <AI90_XpQ47CeM9u1p7brUJMBFddpJgfVXFfBZIYtGfw=.7489df4f-b643-4d9e-b1dd-b15ba1b6a1ad@github.com>
 <RkgzdiaxcFiGijoKtrGci5FPKKcJU7d8vDLBdt1Rftk=.88653824-bf2f-4f5b-9c69-bbb536e49ee0@github.com>
 <gWFZ-lD8CQMjC69_dKMfB7F8a_4ZxUGlWwlUeAwCYlU=.546f5569-0309-45ce-8228-000e56dbbe66@github.com>
 <iyGfHY06FwqKUuJzNQlzG7CvXV9UZtQv0l3RhWUK2RQ=.cdb558c5-1983-4678-b299-35386cb3434a@github.com>
 <K80e0S6-JthHc7DhsDV3BQePXNNEesqd_y1uF9ecLWI=.03e52bae-752b-407c-be5d-ce98c47a83c4@github.com>
 <HRR-kzpsYhfv5i3XdtQokkw4cjUl9fwxTPUlfeHSvC0=.c48b8a56-0dfc-4207-bf3b-9302b5728301@github.com>
 <oleoSKnRqVqnMj0DEkQ6apx-h5L8QJNzc1knyecRByQ=.ee2ad7f0-f54b-4326-b297-b89dc157ed63@github.com>
 <yUYvw-aUQe7ZEunFWC65Okg4Ujd4ndCHrFi2rOV971Y=.dafa0b73-9a26-4060-b38b-c80aca567cd7@github.com>
 <isFfgoZsRbN_XgzjucidTow8HYtH55xM3kv9wyVUYIE=.64039678-0a22-4438-989e-cd0aac358b17@github.com>
Message-ID: <VYy3q9_3cR2lHQtRS7CnHEQsEIDk4CimIyPCSUtqP50=.607c2342-4558-44d9-bd95-d159ab785ded@github.com>

On Tue, 29 Mar 2022 07:22:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> @prsadhuk I have pushed latest changes related to AquaLookAndFeel.java file only. The CSystemColors.m is not checked-in because of [selectedContentBackgroundColor](https://developer.apple.com/documentation/appkit/nscolor/2998830-selectedcontentbackgroundcolor) type property build issues. 
>> 
>> 
>>> In my testing in osx10.15 with your fix, I see focus ring is following highlight color and not accent color...did you modify anything in your fix? <img alt="Screenshot 2022-03-28 at 11 52 09 AM" width="688" src="https://user-images.githubusercontent.com/43534309/160338556-117c8e9b-4e78-4368-8040-dfca1d82e1ab.png">
>> 
>> For this scenario, wanted to verify if the **selectionBackground** explicitly set to green in AquaLookAndFeel?
>
> With latest repo and your fix, I put a debug log in deriveContrastFocusRing() and it seems to produce this output (for scenario above)
> 
> selectedBackgroundColor com.apple.laf.AquaImageFactory$SystemColorProxy[r=54,g=128,b=34]
> 
> I see, even if I change the highlight Color to blue, it does not call deriveContrastFocusRing() again and the focus ring remains green although background Color of JTable cell changes to blue [ I think deriveContrastFocusRing needs to be called every time accent color is changed in System->Preferences]
> 
> <img width="537" alt="Screenshot 2022-03-29 at 12 49 59 PM" src="https://user-images.githubusercontent.com/43534309/160556234-cf1732f3-57bd-4530-82e6-e2080e9e1551.png">
> .

@prsadhuk Pushed new changes related to -

- On-the-fly focus ring changes
- Since **selectionBackground** was following highlight color changes in mac 10.15 and accent color changes in mac 11.6, I have updated **deriveContrastFocusRing**() to use original **focusRingColor** (which follows accent color changes in both versions) to obtain the lighter version.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From avu at openjdk.java.net  Wed Mar 30 19:24:42 2022
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Wed, 30 Mar 2022 19:24:42 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v3]
In-Reply-To: <OcvupXGyRpq-jvVetEJfUNZh5SOvFpDfnU3lVetXQAM=.9e335175-b56d-42d9-b8ab-a487716f0c8b@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <OcvupXGyRpq-jvVetEJfUNZh5SOvFpDfnU3lVetXQAM=.9e335175-b56d-42d9-b8ab-a487716f0c8b@github.com>
Message-ID: <dU9-wdVLYcKsqvkRErR5Gztzl1g6PG5Y-ved1vl0ViQ=.5faa5559-af9c-4473-818e-6909a8a7009a@github.com>

On Wed, 30 Mar 2022 17:08:37 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

>> 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 incrementally with one additional commit since the last revision:
> 
>   8269806: Fix emoji rendering with -Dsun.java2d.xrender=false and AA=OFF

The latest version is working on Xorg
![image](https://user-images.githubusercontent.com/3232337/160914125-eb22c6c0-146e-4938-938d-b688683dd11d.png)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4798


From avu at openjdk.java.net  Wed Mar 30 20:04:33 2022
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Wed, 30 Mar 2022 20:04:33 GMT
Subject: RFR: 8283794: CCE in XRTextRenderer.drawGlyphList and
 XRMaskFill.MaskFill
In-Reply-To: <99TMzNTA3ED5PWkEFHJLco2YI4hXyxy5JIlM2Dl7Sk4=.d56ee68b-c0ea-410a-bb92-e27ddf557b72@github.com>
References: <GD4NAkuLptwylcQOI8VBAXXI1rY7ycgz8O2NvPmhIOc=.f2c8334e-d2eb-4717-92a1-de2f9ed301b6@github.com>
 <99TMzNTA3ED5PWkEFHJLco2YI4hXyxy5JIlM2Dl7Sk4=.d56ee68b-c0ea-410a-bb92-e27ddf557b72@github.com>
Message-ID: <2tpatQTgb8B1tuco4dedi1IDl2yem6W7xKsl_-QuKh4=.3401e965-b176-42bc-87f7-301dd0959653@github.com>

On Tue, 29 Mar 2022 20:54:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Since this is the third cast-related issue then probably it will be useful to create a method to convert the `surfaceData `to the (XRSurfaceData) and throw `InvalidPipeException `if needed? We have many other places where we use the same casts.

Yes, agree. Also, I think we need to update similar cases in MTLRenderer, MTLMaskFill, OGLMaskFill, OGLRenderer, XRPMBlitLoops, D3DMaskFill, D3DRenderer, GDIRenderer.

The conversion can be done using generics in SurfaceData:
SurfaceData.convertTo(XRSurfaceData.class, sg2d.surfaceData);

or by providing separate conversion methods for each  SurfaceData subclass
XRSurfaceData x11sd = XRSurfaceData.toXRSurfaceData(sData);

-------------

PR: https://git.openjdk.java.net/jdk/pull/8015


From prr at openjdk.java.net  Wed Mar 30 20:11:53 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 30 Mar 2022 20:11:53 GMT
Subject: RFR: 8283703: Add sealed modifier to java.awt.geom.Path2D
Message-ID: <rXAWASH0Hh59u7B2GPbsA_CWmUlYXKPs4m5HUSp6qJs=.23177364-3cf9-4c46-b868-d30406026b0b@github.com>

JDK 17 delivered JEP 409: Sealed Classes : https://openjdk.java.net/jeps/409
In essence this JEP allows a class to limit which classes can subclass it.

Path2D can be sealed because no code outside the package can sub-class it directly.

However the extant subclasses need to be made non-sealed as they can be sub-classed.

jtreg tests and JCK API tests pass.

CSR here : https://bugs.openjdk.java.net/browse/JDK-8284031

-------------

Commit messages:
 - 8283703: Add sealed modifier to java.awt.geom.Path2D

Changes: https://git.openjdk.java.net/jdk/pull/8048/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8048&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283703
  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8048.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8048/head:pull/8048

PR: https://git.openjdk.java.net/jdk/pull/8048


From kizune at openjdk.java.net  Wed Mar 30 20:20:17 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 30 Mar 2022 20:20:17 GMT
Subject: RFR: 8283215: [macos] Screen Magnifier: Getting
 java.awt.IllegalComponentStateException when menu item is selected [v3]
In-Reply-To: <MIs7PdqdCMBtdSnGBjLOp2DpFNFTqoQpMj6duGyvFSs=.ed8610da-b86d-4c57-91b8-871c29000ff7@github.com>
References: <MIs7PdqdCMBtdSnGBjLOp2DpFNFTqoQpMj6duGyvFSs=.ed8610da-b86d-4c57-91b8-871c29000ff7@github.com>
Message-ID: <SAjMDAcvGc1vqNCmnJjoqJCgglqQaOGPhAthjTfNAeY=.2d97b4d2-ae6c-40c2-b8dd-5496268a5921@github.com>

> Check parent component visibility status before asking it for its screen coordinates.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Change try/catch to only surround the problematic call instead of the entire method body.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8008/files
  - new: https://git.openjdk.java.net/jdk/pull/8008/files/e72d98d9..f70486d4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8008&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8008&range=01-02

  Stats: 33 lines in 1 file changed: 9 ins; 7 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8008.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8008/head:pull/8008

PR: https://git.openjdk.java.net/jdk/pull/8008


From kizune at openjdk.java.net  Wed Mar 30 20:20:18 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 30 Mar 2022 20:20:18 GMT
Subject: RFR: 8283215: [macos] Screen Magnifier: Getting
 java.awt.IllegalComponentStateException when menu item is selected [v3]
In-Reply-To: <ODrcg6CDePetOAMa59IyTMqtY_cYdPB4bzfIVGmahm8=.d7051d11-96fa-4b0f-88f4-9d7d74aef1cf@github.com>
References: <MIs7PdqdCMBtdSnGBjLOp2DpFNFTqoQpMj6duGyvFSs=.ed8610da-b86d-4c57-91b8-871c29000ff7@github.com>
 <s3aIvh83P0HBrcXgzc_34_PzJOn1pLwchqBF5eEJIOM=.7e00abfb-5948-4a5f-ab05-10142a22b5df@github.com>
 <CRFRjmafddJdi0BLPujNABVj0pUhzK5acOD8bLdBdg0=.8cdec7e3-16b1-48a0-9ab8-c663da1bca97@github.com>
 <7KUcxLWVRHW7XtygvqlVauBSAKiwqf2ZAv-86plxpGg=.e0e1ded3-d52f-40cd-aa66-2bf6f27e8101@github.com>
 <VQY6nohP2wKMBSjuPI923xGoE9OSnvcbbjIelTewJIo=.8631f3f7-6bcf-4802-baf3-a212362d313d@github.com>
 <ODrcg6CDePetOAMa59IyTMqtY_cYdPB4bzfIVGmahm8=.d7051d11-96fa-4b0f-88f4-9d7d74aef1cf@github.com>
Message-ID: <T4igwN4R5ps2cNEii6OxWaOBAI3eiPtPFK2la7gn3Gg=.8ea68c4b-294c-4212-9a69-3b217efd7091@github.com>

On Tue, 29 Mar 2022 22:45:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Just for the readability. I could just split the assignment and definition of Point p but the result is the same.
>
> I think it is better to wrap only one method, it will be obvious where the exception can be thrown and it does not "fill the git history" of the method by all these unnecessary shifting.

Ok, reverting to only do that one call.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8008


From duke at openjdk.java.net  Wed Mar 30 20:42:27 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Wed, 30 Mar 2022 20:42:27 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v7]
In-Reply-To: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
Message-ID: <hJb3Z_2PXmpLTTyPOxdRWVI6vkDuv06XrNk8cRl_Hms=.20bc91e3-cdbf-4894-b783-bc8b8623346f@github.com>

> Previously while tabbing through the JTable cell, the cell highlighter/focus ring was not visible against the selection background. 
> 
> Changes are made to Aqua LAF to derive a lighter focus ring color by changing saturation and setting brightness component to 100% of original focus ring color so that it is visible while tabbing through `JTable` cells. A new method is added for this purpose which takes in `focusRingColor`, does adjustment to saturation and brightness and returns a new focus ring color. There are edge cases where the HSB transformation does not yield the right focus ring color, for these cases a default color is returned.
> 
> **Edge Cases**
> **Selection Background**     -----       **Returned Focus Ring Color**
> - White/ Black/Gray                        ----->          Light Gray
> 
> The following HSB chart was used [Chart Link](https://codepen.io/HunorMarton/details/eWvewo), to determine the best saturation offsets used in deriveContrastFocusRing method.
> 
> A test case is added to compare the RGB difference between the original focus ring color & selection background and the brighter focus ring color & selection background.
> 
> PS: The native L&F (Mac OS) and Swing L&F for JTable cell tabbing differs (on native tables the cell background turns white on focus with a cell focus ring). Since the background for Swing tables can be set by users and also overridden by subclassing `DefaultTableCellRenderer`, and to adhere to current implementation of Swing, the white cell background changes are not incorporated. Only the Focus Ring/ Cell Highlighter is made more prominent.

Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'openjdk:master' into focusRing_7124282
 - on-the-fly focus ring color changes added
 - updated deriveContrastFocusRing method
 - changed javadocs for the new method and expanded imports
 - formatting changes to test case
 - formatted line lengths, added method-level comments
 - Cell Focus Ring Changes for Aqua LAF

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7768/files
  - new: https://git.openjdk.java.net/jdk/pull/7768/files/f6c9b6c0..ec872c82

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7768&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7768&range=05-06

  Stats: 129377 lines in 1823 files changed: 95559 ins; 28740 del; 5078 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7768/head:pull/7768

PR: https://git.openjdk.java.net/jdk/pull/7768


From bpb at openjdk.java.net  Wed Mar 30 20:55:36 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 30 Mar 2022 20:55:36 GMT
Subject: RFR: 8283703: Add sealed modifier to java.awt.geom.Path2D
In-Reply-To: <rXAWASH0Hh59u7B2GPbsA_CWmUlYXKPs4m5HUSp6qJs=.23177364-3cf9-4c46-b868-d30406026b0b@github.com>
References: <rXAWASH0Hh59u7B2GPbsA_CWmUlYXKPs4m5HUSp6qJs=.23177364-3cf9-4c46-b868-d30406026b0b@github.com>
Message-ID: <nUo4Kcya89M3L0Qro4I0P5XtrdqAinL303s9QKG82PI=.9ff66cd5-54ae-4e9a-974d-aee64f07123b@github.com>

On Wed, 30 Mar 2022 20:05:31 GMT, Phil Race <prr at openjdk.org> wrote:

> JDK 17 delivered JEP 409: Sealed Classes : https://openjdk.java.net/jeps/409
> In essence this JEP allows a class to limit which classes can subclass it.
> 
> Path2D can be sealed because no code outside the package can sub-class it directly.
> 
> However the extant subclasses need to be made non-sealed as they can be sub-classed.
> 
> jtreg tests and JCK API tests pass.
> 
> CSR here : https://bugs.openjdk.java.net/browse/JDK-8284031

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8048


From kizune at openjdk.java.net  Wed Mar 30 22:30:05 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 30 Mar 2022 22:30:05 GMT
Subject: RFR: 8283387: [macos] a11y : Screen magnifier does not show selected
 Tab
Message-ID: <V86gocGhD1-irIawpZi-UUzuCuqqbftWbZjVZsYiKZs=.31613701-b994-4d19-a407-dde398f72e61@github.com>

It is impossible right now to manipulate state of the accessible children of the JTabbedPane via their AccessibleValue and because of that some of the assistive technologies are unable to interact with the parts of the JTabbedPane - namely, buttons, representing the JTabbedPane panel navigation buttons. Magnified is just one of the examples that can be engaging without connecting the hardware such as eye movement tracker.

By adding AccessibleValue to the JTabbedPane children containers we eliminate is problem. And since this inner class is private the standard review should be sufficient, no CSR is required.

-------------

Commit messages:
 - Fix the wildcard imports
 - Make value settable via a11y API when it is logically sound
 - 8283387: [macos] a11y : Screen magnifier does not show selected Tab

Changes: https://git.openjdk.java.net/jdk/pull/8049/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8049&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283387
  Stats: 113 lines in 2 files changed: 110 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8049.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8049/head:pull/8049

PR: https://git.openjdk.java.net/jdk/pull/8049


From kizune at openjdk.java.net  Wed Mar 30 23:10:37 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 30 Mar 2022 23:10:37 GMT
Subject: RFR: 8283703: Add sealed modifier to java.awt.geom.Path2D
In-Reply-To: <rXAWASH0Hh59u7B2GPbsA_CWmUlYXKPs4m5HUSp6qJs=.23177364-3cf9-4c46-b868-d30406026b0b@github.com>
References: <rXAWASH0Hh59u7B2GPbsA_CWmUlYXKPs4m5HUSp6qJs=.23177364-3cf9-4c46-b868-d30406026b0b@github.com>
Message-ID: <n_r0YOESijKFsV1WF19s3ode8nriNHKC8TORr_JvNMA=.d0961324-0fdb-40bb-808d-73c6ebb171fa@github.com>

On Wed, 30 Mar 2022 20:05:31 GMT, Phil Race <prr at openjdk.org> wrote:

> JDK 17 delivered JEP 409: Sealed Classes : https://openjdk.java.net/jeps/409
> In essence this JEP allows a class to limit which classes can subclass it.
> 
> Path2D can be sealed because no code outside the package can sub-class it directly.
> 
> However the extant subclasses need to be made non-sealed as they can be sub-classed.
> 
> jtreg tests and JCK API tests pass.
> 
> CSR here : https://bugs.openjdk.java.net/browse/JDK-8284031

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8048


From Alan.Bateman at oracle.com  Wed Mar 16 06:31:41 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 16 Mar 2022 06:31:41 -0000
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v6]
In-Reply-To: <qZZeW4Wwn9Rj_m5O9Cc6BKPn5k-6UHcuS1_1vd4ojPY=.b53ec8c1-cb6e-4b6c-ae9e-276ffcd9fd29@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
 <qZZeW4Wwn9Rj_m5O9Cc6BKPn5k-6UHcuS1_1vd4ojPY=.b53ec8c1-cb6e-4b6c-ae9e-276ffcd9fd29@github.com>
Message-ID: <4dd8052d-b376-ef82-0dfd-ccaf0297a27c@oracle.com>

Magnus,

This proposal does not address the previous concerns. As before, you are 
proposing to put the data files used to generate the classes for 
jdk.localedata and jdk.charsets into src/java.base and I don't think we 
should do that. I really think this PR needs to be withdraw n or closed 
until there is at least some agreement on placement. I know you want to 
get the files moved out of the make tree but there are many issues to 
work through before that can happen.

-Alan

On 15/03/2022 23:59, Magnus Ihse Bursie wrote:
> On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:
>
>>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.)
>>>
>>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.)
>>>
>>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>>>
>>> ### Modules reviewed
>>>
>>> - [x] java.base
>>> - [x] java.desktop
>>> - [x] jdk.compiler
>>> - [x] java.se
>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>>
>>   - Merge branch 'master' into shuffle-data-reborn
>>   - Fix merge
>>   - Merge tag 'jdk-19+13' into shuffle-data-reborn
>>     
>>     Added tag jdk-19+13 for changeset 5df2a057
>>   - Move characterdata templates to share/classes/java/lang.
>>   - Update comment refering to "make" dir
>>   - Move new symbols to jdk.compiler
>>   - Merge branch 'master' into shuffle-data
>>   - Move macosxicons from share to macosx
>>   - Move to share/data, and move jdwp.spec to java.se
>>   - Update references in test
>>   - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f
> I have carefully reviewed all PR comments, and the changes I made in response to them. I believe I have resolved all requests from reviewers. What remained to do was to create an informational JEP about the new source structure, and file some follow-up issues.
>
> I have now created and submitted a new informational JEP ("JDK Source Structure"), available at https://bugs.openjdk.java.net/browse/JDK-8283227. When creating this JEP, it felt increasingly silly to just copy and extend the part about src/$MODULE from JEP 201, so I extended it to cover a relevant overview of the entire JDK source base structure. I actually think this JEP has a good merit on its own, notwithstanding it being a reviewer requirement for this PR.
>
> I have also filed follow up issues for the non-standard jdk.hotspot.agent `doc` and `test` directories (https://bugs.openjdk.java.net/browse/JDK-8283197 and https://bugs.openjdk.java.net/browse/JDK-8283198, respectively).
>
> I have filed a follow up issue for continued efforts to clean up charsetmapping, https://bugs.openjdk.java.net/browse/JDK-8283228.
>
> There were two open questions:
>
>   * should jdwp.spec belong to specs directory instead of data
>   * should bin/idea.sh be changed to exclude data
>
> but they sounded so exploratory that I decided not to open JBS issues for them.
>
> @wangweij  @naotoj  @prrace  @erikj79 @jonathan-gibbons  You have all approved this PR at an older revision. Can you please reconfirm that your approval stands for the latest revision? (Sorry for the mass ping)
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/1611



From Alan.Bateman at oracle.com  Wed Mar 16 19:53:30 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 16 Mar 2022 19:53:30 -0000
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v6]
In-Reply-To: <47cf38cc-2a72-0e2e-f626-707dd8cd4434@oracle.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
 <qZZeW4Wwn9Rj_m5O9Cc6BKPn5k-6UHcuS1_1vd4ojPY=.b53ec8c1-cb6e-4b6c-ae9e-276ffcd9fd29@github.com>
 <4dd8052d-b376-ef82-0dfd-ccaf0297a27c@oracle.com>
 <47cf38cc-2a72-0e2e-f626-707dd8cd4434@oracle.com>
Message-ID: <1ffca295-1c99-300e-1ac5-f81c51d8ef9b@oracle.com>

On 16/03/2022 08:44, Magnus Ihse Bursie wrote:
> :
>
> If you have such strong opinions on the data files shared between 
> java.base and jdk.charsets/jdk.localedata, I propose we leave them in 
> make/data for the time being, clean up the associated mess, and then 
> work out where they actually should be. Does that sound okay to you?

The concern, as before, is that it puts data files into src/java.base 
that are used by the build to generate classes/resources for the service 
provider modules.? We also have the complication that the charsets to 
include in java.base varies by platform so the module/package for each 
charset is decided at build time. It's always been low-priority to 
re-visit that and not clear if we could even get to an agreement easily 
because there are IBM platforms that want EBCDIC and other double byte 
charsets whereas other platforms don't want these in java.base. So yes, 
if you can drop the move of the charset data and CLDR data from the 
patch then it will make it easier to discuss.

You asked about the JDWP spec. This is the protocol spec that is used to 
generate the spec in HTML, and source files for the debugger front-end 
and backend (jdk.jdi and jdk.jdwp.agent modules). The "specs" directory 
might be right. There is another source file (jdwp-spec.md) that isn't 
in the src tree right now and they probably go together.

-Alan