> 26:  * Exception in thread "main" java.awt.image.RasterFormatException: (parentX + width) is outside raster

No point in HTML here ... nothing runs on this javadoc.

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

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

From prasanta.sadhukhan at oracle.com  Thu Feb 10 04:17:50 2022
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 10 Feb 2022 09:47:50 +0530
Subject: CFV: New Client Libraries Group Member : Alexey Ivanov (aivanov)
In-Reply-To: 
References: 
Message-ID: <94193836-dbf3-2790-1fd5-004248458a05@oracle.com>

Vote: yes

Regards
Prasanta
On 10-Feb-22 1:36 AM, Philip Race wrote:
> I hereby nominate Alexey Ivanov (aivanov) to Membership in the Client 
> Libraries Group.
>
> Alexey has worked in the client libraries sustaining team at Oracle 
> since 2014 and in that time
> has contributed 60 client fixes [1], [2].
> He has been active on the old client lists, awt-dev [3], swing-dev[4] 
> and 2d-dev [5] mailing list over that time,
> as well as on client-libs-dev [6]. He is also a JDK committer and 
> reviewer [7].
>
> Votes are due by 1pm PST Wednesday 23rd February 2022
>
> //Only current Members of the Client Libraries Group [8] are eligible 
> to vote on this nomination. ||
> Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [9].
>
> -phil.
>
>
> [1] git log --author aivanov --format='%h %s'
> [2] 
> https://github.com/openjdk/jdk/search?p=2&q=author-name%3A%22Alexey+Ivanov%22&type=commits
> [3] https://mail.openjdk.java.net/mailman/listinfo/awt-dev
> [4] https://mail.openjdk.java.net/mailman/listinfo/swing-dev
> [5] https://mail.openjdk.java.net/mailman/listinfo/2d-dev
> [6] https://mail.openjdk.java.net/mailman/listinfo/client-libs-dev
> [7] https://openjdk.java.net/census#aivanov
> [8] https://openjdk.java.net/census#client-libs
> [9] http://openjdk.java.net/groups/#member-vote 
> 

From prasanta.sadhukhan at oracle.com  Thu Feb 10 04:18:24 2022
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 10 Feb 2022 09:48:24 +0530
Subject: CFV: New Client Libraries Group Member : Dmitry Markov (dmarkov)
In-Reply-To: 
References: 
Message-ID: <096b248d-4759-e0fe-bf3f-cb793d587bba@oracle.com>

Vote: yes

Regards
Prasanta
On 10-Feb-22 1:36 AM, Philip Race wrote:
> I hereby nominate Dmitry Markov (dmarkov) to Membership in the Client 
> Libraries Group.
>
> Dmitry has worked in the client libraries sustaining team at Oracle 
> since 2013 and in that time
> has contributed 61 client fixes [1], [2].
> He has been active on the old client lists, awt-dev [3], swing-dev[4] 
> and 2d-dev [5] mailing list over that time,
> as well as on client-libs-dev [6]. He is also a JDK committer and 
> reviewer [7].
>
> Votes are due by 1pm PST Wednesday 23rd February 2022
>
> //Only current Members of the Client Libraries Group [8] are eligible 
> to vote on this nomination. ||
> Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [9].
>
> -phil.
>
>
> [1] git log --author dmarkov --format='%h %s'
> [2] 
> https://github.com/openjdk/jdk/search?p=2&q=author-name%3A%22Dmitry+Markov%22&type=commits
> [3] https://mail.openjdk.java.net/mailman/listinfo/awt-dev
> [4] https://mail.openjdk.java.net/mailman/listinfo/swing-dev
> [5] https://mail.openjdk.java.net/mailman/listinfo/2d-dev
> [6] https://mail.openjdk.java.net/mailman/listinfo/client-libs-dev
> [7] https://openjdk.java.net/census#dmarkov
> [8] https://openjdk.java.net/census#client-libs
> [9] http://openjdk.java.net/groups/#member-vote 
> 

From psadhukhan at openjdk.java.net  Thu Feb 10 04:40:34 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 10 Feb 2022 04:40:34 GMT
Subject: RFR: 8054449: Incompatible type in example code in TreePath
Message-ID: 

The example code in TreePath throws
error: incompatible types: Object cannot be converted to DefaultMutableTreeNode
           getUserObject();
Fixed the example code

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

Commit messages:
 - 8054449: Incompatible type in example code in TreePath

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

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

From alitvinov at openjdk.java.net  Thu Feb 10 05:05:37 2022
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Thu, 10 Feb 2022 05:05:37 GMT
Subject: RFR: 8277922: Unable to click JCheckBox in JTable through Java Access
 Bridge
Message-ID: <68JPxsadS5K_WkQgEkMdD_qCt1DWBpBVHV23b0oQKGU=.0b4e520a-205d-4cf1-b506-dd48616ebece@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

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

Commit messages:
 - 8277922: Unable to click JCheckBox in JTable through Java Access Bridge

Changes: https://git.openjdk.java.net/jdk/pull/7416/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7416&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277922
  Stats: 264 lines in 2 files changed: 263 ins; 0 del; 1 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 duke at openjdk.java.net  Thu Feb 10 05:36:40 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 10 Feb 2022 05:36:40 GMT
Subject: RFR: 8202836 : [macosx] test
 java/awt/Graphics/TextAAHintsTest.java fails [v4]
In-Reply-To: 
References: 
Message-ID: <30iOzkwefS6EJE8VLj9-NJ7oysi9WLq3cAOvPug4Wn8=.37f381a6-455a-42d9-982b-84cc1d290722@github.com>

> 1) Removed =yesno that was causing the test to fail with following exception
> test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno
> After removing =yesno, test was just passing without user interaction so fixed the following
> 
> Add the following so that user can user interact with the test
> a) Added pass/fail button and instruction for the user to know what he/she is going to test and what is expected.
> b) Added Dialog with textarea to enter the reason for the testcase failure. This will help the user to understanding the reason why the test was failed while analyzing the results. 
> 
> @shurymury

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

  Removed RenderingHints.VALUE_TEXT_ANTIALIAS_GASP and fixed the review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7275/files
  - new: https://git.openjdk.java.net/jdk/pull/7275/files/5b667fa6..f42940cd

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

  Stats: 84 lines in 1 file changed: 25 ins; 36 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7275.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7275/head:pull/7275

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

From duke at openjdk.java.net  Thu Feb 10 05:36:46 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 10 Feb 2022 05:36:46 GMT
Subject: RFR: 8202836 : [macosx] test
 java/awt/Graphics/TextAAHintsTest.java fails [v3]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 8 Feb 2022 19:59:57 GMT, Alexey Ivanov  wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Dispose the frame via EDT
>
> test/jdk/java/awt/Graphics/TextAAHintsTest.java line 2:
> 
>> 1: package awt;
>> 2: 
> 
> Usually tests are not part of any package.

removed package

> test/jdk/java/awt/Graphics/TextAAHintsTest.java line 52:
> 
>> 50: import javax.swing.SwingUtilities;
>> 51: 
>> 52: public class TextAAHintsTest  extends Component {
> 
> There's an extra space before `extends`.

Fixed

> test/jdk/java/awt/Graphics/TextAAHintsTest.java line 177:
> 
>> 175:                 1. Verify that first set of text are rendered correctly.
>> 176:                 2. Second set of text are created using BufferedImage of the first text.
>> 177:                 3. Third set of text are created using VolatileImage of the first text.
> 
> ?are? ? ?is?: the _set_ is singular.

Corrected

> test/jdk/java/awt/Graphics/TextAAHintsTest.java line 180:
> 
>> 178:                 """;
>> 179:         TextArea instructionTextArea = new TextArea(instructions, 8, 50);
>> 180:         instructionTextArea.setEnabled(false);
> 
> Please leave it enabled but make it read-only (`setEditable(false)`). This way the text will be black and easier to read.

Done

> test/jdk/java/awt/Graphics/TextAAHintsTest.java line 191:
> 
>> 189:         });
>> 190:         Button failButton = new Button("Fail");
>> 191:         failButton.addActionListener(e->{
> 
> Usually, there are spaces around `->` in lambda expressions.
> 
> This particular event handler isn't short. I suggest making it a static method or at least moving showing the dialog into a separate method. It'll make the code easier to read.

Fixed

> test/jdk/java/awt/Graphics/TextAAHintsTest.java line 228:
> 
>> 226:         mainThread = Thread.currentThread();
>> 227:         try {
>> 228:             mainThread.sleep(testTimeOut);
> 
> Suggestion:
> 
>             Thread.sleep(testTimeOut);
> 
> `sleep` is a static method, it's better to call it via the class name rather than an instance variable. This will resolve the IDE warning.

Replaced Thread with CountDownLatch

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

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

From psadhukhan at openjdk.java.net  Thu Feb 10 06:34:07 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 10 Feb 2022 06:34:07 GMT
Subject: RFR: 8241192: [macosx] Wrong letter typed after =?UTF-8?B?wrQ=?=
 symbol when using Finnish layout
In-Reply-To: 
References: 
Message-ID: <6FCyOiQWf9f1OJb7E7ebu5Sjhr2oEmjblT8aJdo8FGU=.a0d52947-fb0d-40f9-a36c-3019cb5049d6@github.com>

On Fri, 28 Jan 2022 09:38:35 GMT, Prasanta Sadhukhan  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.

@dmarkov20 @alitvinv Since you have touched this file and fixed similar issue earlier, can you please review?

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

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

From bourges.laurent at gmail.com  Thu Feb 10 06:50:38 2022
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 10 Feb 2022 07:50:38 +0100
Subject: CFV: New Client Libraries Group Member : Alexey Ivanov (aivanov)
In-Reply-To: 
References: 
Message-ID: 

Vote: yes

Laurent

Le mer. 9 f?vr. 2022, 21:07, Philip Race  a ?crit :

> I hereby nominate Alexey Ivanov (aivanov) to Membership in the Client
> Libraries Group.
>
> Alexey has worked in the client libraries sustaining team at Oracle
> since 2014 and in that time
> has contributed 60 client fixes [1], [2].
> He has been active on the old client lists, awt-dev [3], swing-dev[4]
> and 2d-dev [5] mailing list over that time,
> as well as on client-libs-dev [6]. He is also a JDK committer and
> reviewer [7].
>
> Votes are due by 1pm PST Wednesday 23rd February 2022
>
> //Only current Members of the Client Libraries Group [8] are eligible to
> vote on this nomination. ||
> Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [9].
>
> -phil.
>
>
> [1] git log --author aivanov --format='%h %s'
> [2]
>
> https://github.com/openjdk/jdk/search?p=2&q=author-name%3A%22Alexey+Ivanov%22&type=commits
> [3] https://mail.openjdk.java.net/mailman/listinfo/awt-dev
> [4] https://mail.openjdk.java.net/mailman/listinfo/swing-dev
> [5] https://mail.openjdk.java.net/mailman/listinfo/2d-dev
> [6] https://mail.openjdk.java.net/mailman/listinfo/client-libs-dev
> [7] https://openjdk.java.net/census#aivanov
> [8] https://openjdk.java.net/census#client-libs
> [9] http://openjdk.java.net/groups/#member-vote
> 
>

From myano at openjdk.java.net  Thu Feb 10 07:42:09 2022
From: myano at openjdk.java.net (Masanori Yano)
Date: Thu, 10 Feb 2022 07:42:09 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <_lT1ihu773QLjjWmUOI5XYg0-j1xFrqz8WZSNJ56auc=.b9be5bda-0d47-450b-9523-e4fac6bbf243@github.com>
References: 

 <_lT1ihu773QLjjWmUOI5XYg0-j1xFrqz8WZSNJ56auc=.b9be5bda-0d47-450b-9523-e4fac6bbf243@github.com>
Message-ID: 

On Sun, 6 Feb 2022 21:46:37 GMT, Phil Race  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
>
> The problem I have with this is that this being in createGraphics() isn't obviously relevant to me.
> The repaintPeerTarget() is called only if the surface is lost which means it needs repainting.
> Or does surface lost here perhaps mean "surface has not yet been created", because we aren't
> yet showing the window contents at all and we really should wait for the first paint event ?

@prrace createGraphics() is called to create surface during "the first paint event" processing. And validate() posts new PaintEvent with repaintPeerTarget() when creates surface.

Current stack trace is here:

  [1] java.awt.event.PaintEvent. (PaintEvent.java:106)
  [2] sun.awt.PaintEventDispatcher.createPaintEvent (PaintEventDispatcher.java:80)
  [3] sun.awt.windows.WComponentPeer.postPaintIfNecessary (WComponentPeer.java:892)
  [4] sun.awt.windows.WComponentPeer.handlePaint (WComponentPeer.java:886)
  [5] sun.java2d.d3d.D3DScreenUpdateManager.repaintPeerTarget (D3DScreenUpdateManager.java:283)
  [6] sun.java2d.d3d.D3DScreenUpdateManager.validate (D3DScreenUpdateManager.java:492)
  [7] sun.java2d.d3d.D3DScreenUpdateManager.createGraphics (D3DScreenUpdateManager.java:260)
  [8] sun.awt.windows.WComponentPeer.getGraphics (WComponentPeer.java:646)
  [9] java.awt.Component.getGraphics (Component.java:3,128)
  [10] sun.awt.RepaintArea.paint (RepaintArea.java:227)
  [11] sun.awt.windows.WComponentPeer.handleEvent (WComponentPeer.java:371)
  [12] java.awt.Component.dispatchEventImpl (Component.java:5,056)
  [13] java.awt.Container.dispatchEventImpl (Container.java:2,325)
  [14] java.awt.Window.dispatchEventImpl (Window.java:2,775)
  [15] java.awt.Component.dispatchEvent (Component.java:4,827)
  [16] java.awt.EventQueue.dispatchEventImpl (EventQueue.java:772)

Created surface is normally handled in this processing PaintEvent, so I think there is no need to call repaintPeerTarget(). Also ScreenUpdateManager class which is used for GDI rendering (and parent class of D3DScreenUpdateManager) does not post new PaintEvent at createGraphics(). This validate() is called from createGraphics(), so I hope to reduce to create another PaintEvent at this route only.

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

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

From alexey.ushakov at jetbrains.com  Thu Feb 10 07:59:13 2022
From: alexey.ushakov at jetbrains.com (Alexey Ushakov)
Date: Thu, 10 Feb 2022 08:59:13 +0100
Subject: CFV: New Client Libraries Group Member : Alexey Ivanov (aivanov)
In-Reply-To: 
References: 
Message-ID: 

Vote: Yes

> On 9 Feb 2022, at 21:06, Philip Race  wrote:
> 
> I hereby nominate Alexey Ivanov (aivanov) to Membership in the Client Libraries Group.
> 
> Alexey has worked in the client libraries sustaining team at Oracle since 2014 and in that time
> has contributed 60 client fixes [1], [2].
> He has been active on the old client lists, awt-dev [3], swing-dev[4] and 2d-dev [5] mailing list over that time,
> as well as on client-libs-dev [6]. He is also a JDK committer and reviewer [7].
> 
> Votes are due by 1pm PST Wednesday 23rd February 2022
> 
> //Only current Members of the Client Libraries Group [8] are eligible to vote on this nomination. ||
> Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [9].
> 
> -phil.
> 
> 
> [1] git log --author aivanov --format='%h %s'
> [2] https://github.com/openjdk/jdk/search?p=2&q=author-name%3A%22Alexey+Ivanov%22&type=commits
> [3] https://mail.openjdk.java.net/mailman/listinfo/awt-dev
> [4] https://mail.openjdk.java.net/mailman/listinfo/swing-dev
> [5] https://mail.openjdk.java.net/mailman/listinfo/2d-dev
> [6] https://mail.openjdk.java.net/mailman/listinfo/client-libs-dev
> [7] https://openjdk.java.net/census#aivanov
> [8] https://openjdk.java.net/census#client-libs
> [9] http://openjdk.java.net/groups/#member-vote 

From alexey.ushakov at jetbrains.com  Thu Feb 10 08:08:13 2022
From: alexey.ushakov at jetbrains.com (Alexey Ushakov)
Date: Thu, 10 Feb 2022 09:08:13 +0100
Subject: CFV: New Client Libraries Group Member : Dmitry Markov (dmarkov)
In-Reply-To: 
References: 
Message-ID: 

Vote: yes

> On 9 Feb 2022, at 21:06, Philip Race  wrote:
> 
> I hereby nominate Dmitry Markov (dmarkov) to Membership in the Client Libraries Group.
> 
> Dmitry has worked in the client libraries sustaining team at Oracle since 2013 and in that time
> has contributed 61 client fixes [1], [2].
> He has been active on the old client lists, awt-dev [3], swing-dev[4] and 2d-dev [5] mailing list over that time,
> as well as on client-libs-dev [6]. He is also a JDK committer and reviewer [7].
> 
> Votes are due by 1pm PST Wednesday 23rd February 2022
> 
> //Only current Members of the Client Libraries Group [8] are eligible to vote on this nomination. ||
> Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [9].
> 
> -phil.
> 
> 
> [1] git log --author dmarkov --format='%h %s'
> [2] https://github.com/openjdk/jdk/search?p=2&q=author-name%3A%22Dmitry+Markov%22&type=commits
> [3] https://mail.openjdk.java.net/mailman/listinfo/awt-dev
> [4] https://mail.openjdk.java.net/mailman/listinfo/swing-dev
> [5] https://mail.openjdk.java.net/mailman/listinfo/2d-dev
> [6] https://mail.openjdk.java.net/mailman/listinfo/client-libs-dev
> [7] https://openjdk.java.net/census#dmarkov
> [8] https://openjdk.java.net/census#client-libs
> [9] http://openjdk.java.net/groups/#member-vote 

From psadhukhan at openjdk.java.net  Thu Feb 10 08:17:29 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 10 Feb 2022 08:17:29 GMT
Subject: RFR: 8047749: javadoc for getPathBounds() in TreeUI and BasicTreeUI is
 incorrect
Message-ID: 

The javadoc descriptions for javax.swing.plaf.TreeUI.getPathBounds() and javax.swing.plaf.basic.BasicTreeUI.getPathBounds() have stated it returns null if any component in path is currently "valid", which is wrong.
The getPathBounds() in BasicTreeUI returns null if tree or treeState is null. 
Fixed the javadoc.

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

Commit messages:
 - 8047749: javadoc for getPathBounds() in TreeUI and BasicTreeUI is incorrect

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

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

From aivanov at openjdk.java.net  Thu Feb 10 09:10:06 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 10 Feb 2022 09:10:06 GMT
Subject: RFR: 8202836 : [macosx] test
 java/awt/Graphics/TextAAHintsTest.java fails [v4]
In-Reply-To: <30iOzkwefS6EJE8VLj9-NJ7oysi9WLq3cAOvPug4Wn8=.37f381a6-455a-42d9-982b-84cc1d290722@github.com>
References: 
 <30iOzkwefS6EJE8VLj9-NJ7oysi9WLq3cAOvPug4Wn8=.37f381a6-455a-42d9-982b-84cc1d290722@github.com>
Message-ID: 

On Thu, 10 Feb 2022 05:36:40 GMT, lawrence.andrews  wrote:

>> 1) Removed =yesno that was causing the test to fail with following exception
>> test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno
>> After removing =yesno, test was just passing without user interaction so fixed the following
>> 
>> Add the following so that user can user interact with the test
>> a) Added pass/fail button and instruction for the user to know what he/she is going to test and what is expected.
>> b) Added Dialog with textarea to enter the reason for the testcase failure. This will help the user to understanding the reason why the test was failed while analyzing the results. 
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed RenderingHints.VALUE_TEXT_ANTIALIAS_GASP and fixed the review comments

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/Graphics/TextAAHintsTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2007, 2022 Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2007, 2022, Oracle and/or its affiliates. All rights reserved.

One more comma.

test/jdk/java/awt/Graphics/TextAAHintsTest.java line 59:

> 57:     public static final CountDownLatch countDownLatch = new CountDownLatch(1);
> 58:     private static Frame frame;
> 59:     public static String failureReason;

`failureReason` should also be `volatile`.

All the fields can be `private`. You access them from this class only; nested classes, including the static ones, have access to private members of the surrounding class.

test/jdk/java/awt/Graphics/TextAAHintsTest.java line 199:

> 197:     }
> 198: 
> 199:     public static void readFailedReason() {

`readFailureReason` or `getFailureReason`?

test/jdk/java/awt/Graphics/TextAAHintsTest.java line 221:

> 219: 
> 220:     public static void main(String[] args) throws InterruptedException, InvocationTargetException {
> 221:         java.awt.EventQueue.invokeAndWait(TextAAHintsTest::createTestUI);

I wonder why `EventQueue` uses fully qualified class name instead of being imported as other classes. That's fine, I'm just wondering.

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

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

From aivanov at openjdk.java.net  Thu Feb 10 09:10:07 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 10 Feb 2022 09:10:07 GMT
Subject: RFR: 8202836 : [macosx] test
 java/awt/Graphics/TextAAHintsTest.java fails [v3]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 10 Feb 2022 05:31:58 GMT, lawrence.andrews  wrote:

>> test/jdk/java/awt/Graphics/TextAAHintsTest.java line 177:
>> 
>>> 175:                 1. Verify that first set of text are rendered correctly.
>>> 176:                 2. Second set of text are created using BufferedImage of the first text.
>>> 177:                 3. Third set of text are created using VolatileImage of the first text.
>> 
>> ?are? ? ?is?: the _set_ is singular.
>
> Corrected

I can't see it. The instructions aren't modified.

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

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

From aivanov at openjdk.java.net  Thu Feb 10 09:28:02 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 10 Feb 2022 09:28:02 GMT
Subject: RFR: 8054449: Incompatible type in example code in TreePath
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Feb 2022 04:33:50 GMT, Prasanta Sadhukhan  wrote:

> The example code in TreePath throws
> error: incompatible types: Object cannot be converted to DefaultMutableTreeNode
>            getUserObject();
> Fixed the example code

Marked as reviewed by aivanov (Reviewer).

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

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

From duke at openjdk.java.net  Thu Feb 10 10:22:43 2022
From: duke at openjdk.java.net (Martin Desruisseaux)
Date: Thu, 10 Feb 2022 10:22:43 GMT
Subject: RFR: 8275345: RasterFormatException when drawing a tiled image
 made of non-writable rasters [v2]
In-Reply-To: 
References: 
Message-ID: 

> This commit fixes a `RasterFormatException` thrown when `Graphics2D.drawRenderedImage(?)` is invoked with an image containing tiles that are instances of `Raster` but not `WritableRaster`.
> 
> https://bugs.openjdk.java.net/browse/JDK-8275345

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

  Add jtreg @test, @bug and @summary tags. Remove HTML  tags. Edit comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7337/files
  - new: https://git.openjdk.java.net/jdk/pull/7337/files/c3db2978..fea2f9c0

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

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

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

From dmarkov at openjdk.java.net  Thu Feb 10 10:46:10 2022
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Thu, 10 Feb 2022 10:46:10 GMT
Subject: RFR: 8054449: Incompatible type in example code in TreePath
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Feb 2022 04:33:50 GMT, Prasanta Sadhukhan  wrote:

> The example code in TreePath throws
> error: incompatible types: Object cannot be converted to DefaultMutableTreeNode
>            getUserObject();
> Fixed the example code

Marked as reviewed by dmarkov (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Thu Feb 10 12:06:09 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 10 Feb 2022 12:06:09 GMT
Subject: Integrated: 8054449: Incompatible type in example code in TreePath
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Feb 2022 04:33:50 GMT, Prasanta Sadhukhan  wrote:

> The example code in TreePath throws
> error: incompatible types: Object cannot be converted to DefaultMutableTreeNode
>            getUserObject();
> Fixed the example code

This pull request has now been integrated.

Changeset: 039313d6
Author:    Prasanta Sadhukhan 
URL:       https://git.openjdk.java.net/jdk/commit/039313d65d47dc85cb8c91d3e1d2752d365f70f9
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8054449: Incompatible type in example code in TreePath

Reviewed-by: aivanov, dmarkov

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

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

From duke at openjdk.java.net  Thu Feb 10 12:48:04 2022
From: duke at openjdk.java.net (Nikita Provotorov)
Date: Thu, 10 Feb 2022 12:48:04 GMT
Subject: RFR: 8241192: [macosx] Wrong letter typed after =?UTF-8?B?wrQ=?=
 symbol when using Finnish layout
In-Reply-To: 
References: 
Message-ID: 

On Fri, 28 Jan 2022 09:38:35 GMT, Prasanta Sadhukhan  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.

Hey, folks! With my environment the patch fixes only the `?` + `s` combination, but does nothing with all other broken keys, i.e. all except `e`, `u`, `i`, `o`, `a`.

Can you please verify you are reproducing this behavior too?

My environment:
* macOS 11.6.1;
* Xcode 13.2.1;
* Boot JDK 17.0.1 (for building);
* Finnish layout for testing.

Reproducer:

package com.company;

import javax.swing.*;
import java.awt.event.InputMethodEvent;
import java.awt.event.InputMethodListener;
import java.awt.event.KeyAdapter;
import java.awt.event.KeyEvent;
import java.text.AttributedCharacterIterator;

public class KeyboardWindow {
    final JFrame frame;
    final JTextArea textArea;

    KeyboardWindow() {
        frame = new JFrame();
        frame.setSize(300, 200);
        frame.setVisible(true);
        frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
        frame.setTitle("Keyboard Window");

        textArea = new JTextArea();

        textArea.addKeyListener(new KeyAdapter() {
            @Override
            public void keyTyped(KeyEvent e) {
                //System.out.println("keyTyped 0x" + Integer.toHexString(e.getKeyChar()) + ": " + e + "\n");
            }

            @Override
            public void keyPressed(KeyEvent e) {
                //System.out.println("keyPressed: " + e + "\n");
            }

            @Override
            public void keyReleased(KeyEvent e) {
                //System.out.println("keyReleased: " + e + "\n");
            }
        });

        textArea.addInputMethodListener(new InputMethodListener() {
            @Override
            public void inputMethodTextChanged(InputMethodEvent event) {
                //System.out.println("inputMethodTextChanged: " + event + "\n");
            }

            @Override
            public void caretPositionChanged(InputMethodEvent event) {
                //System.out.println("caretPositionChanged: " + event + "\n");
            }
        });

        frame.add(textArea);

        frame.pack();
        frame.setSize(300, 300);
    }

    public static void main(String[] args) {
        SwingUtilities.invokeLater(KeyboardWindow::new);
    }
}

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

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

From aivanov at openjdk.java.net  Thu Feb 10 14:06:03 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 10 Feb 2022 14:06:03 GMT
Subject: RFR: 8047749: javadoc for getPathBounds() in TreeUI and
 BasicTreeUI is incorrect
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Feb 2022 08:11:04 GMT, Prasanta Sadhukhan  wrote:

> The javadoc descriptions for javax.swing.plaf.TreeUI.getPathBounds() and javax.swing.plaf.basic.BasicTreeUI.getPathBounds() have stated it returns null if any component in path is currently "valid", which is wrong.
> The getPathBounds() in BasicTreeUI returns null if tree or treeState is null. 
> Fixed the javadoc.

Marked as reviewed by aivanov (Reviewer).

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

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

From duke at openjdk.java.net  Thu Feb 10 14:15:25 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Thu, 10 Feb 2022 14:15:25 GMT
Subject: RFR: 8280861: Robot color picker broken on Linux with scaling above
 100%
Message-ID: <7WQIrQr1kH9q7zlM2wZcrF7r-LX1uiQwYjN1TMovRds=.17e06f8b-1d83-42c4-8d38-6ccaeaacdc9e@github.com>

The primary API for image capture on modern Linuxes is `gdk_pixbuf_get_from_window()` that expects both coordinates and the size unscaled (i.e. not multiplied by the current desktop scale). At the same time, `gtk3_interface.c:gtk3_get_drawable_data()` gets the coordinates from `Robot` that pre-scales them (multiplying by the scale known to Java, however, not necessarily the current desktop scale). The problem with the size had been partly taken care of in [JDK-8225118](https://bugs.openjdk.java.net/browse/JDK-8225118), but coordinates are still passed to `gdk_pixbuf_get_from_window()` pre-scaled.

The idea of the fix is to capture a possibly larger area that is guaranteed to contain the one that is interesting to the caller and then only copy the interesting pixels to the output image. As a positive side effect, the size of the captured area cannot be less than 1x1 (provided the correct input, of course). This solves the problem of zero size passed to  `(*fp_gdk_pixbuf_get_from_drawable)` when the desktop scale is 3 and we're asked to capture just one pixel. In that case, the previous formula (`width / (float) win_scale + 0.5`) would have yielded `0`. 

A related issue would be that tests written specifically for this general area (`java/awt/Robot`) didn't catch this problem and only somewhat unrelated tests (`javax/swing/...`) were affected.

This one is solved by adding pixel-sized areas to the test image in `HiDPIRobotScreenCaptureTest.java`, which precise colors are then verified to match the expected ones. In addition to that, instead of verifying just the color of the center of a large area, 4 more pixels close to the area's border are checked. This helps to make sure that captured area coordinates aren't way off.

The tests under `javax/swing/...` that originally helped to identify this problem were modified to provide more screen space for painting their components as extreme desktop scaling (300%) on Ubuntu doesn't leave much room due to a humongous title bar.

The fix was tested by running all the modified tests on Ubuntu with desktop scaling set to 100%, 200%, and 300%. The `Robot` tests were also executed on Windows (300% scaling) and MacOS.

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

Commit messages:
 - 8280861: Robot color picker broken on Linux with scaling above 100%

Changes: https://git.openjdk.java.net/jdk/pull/7425/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7425&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280861
  Stats: 121 lines in 8 files changed: 91 ins; 3 del; 27 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7425.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7425/head:pull/7425

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

From dmarkov at openjdk.java.net  Thu Feb 10 15:43:10 2022
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Thu, 10 Feb 2022 15:43:10 GMT
Subject: RFR: 8241192: [macosx] Wrong letter typed after =?UTF-8?B?wrQ=?=
 symbol when using Finnish layout
In-Reply-To: 
References: 
Message-ID: 

On Fri, 28 Jan 2022 09:38:35 GMT, Prasanta Sadhukhan  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.

It seems we fail to detect accented symbols at least for ?Finish? keyboard layout (other layouts might be affected too). 
I would expect that the function `keyDown()` will set `fProcessingKeystroke` flag to `NO` and then `insertText()` will do the rest but it does not work and requires investigation.

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

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

From serb at openjdk.java.net  Thu Feb 10 18:08:07 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 10 Feb 2022 18:08:07 GMT
Subject: RFR: 8280861: Robot color picker broken on Linux with scaling
 above 100%
In-Reply-To: <7WQIrQr1kH9q7zlM2wZcrF7r-LX1uiQwYjN1TMovRds=.17e06f8b-1d83-42c4-8d38-6ccaeaacdc9e@github.com>
References: <7WQIrQr1kH9q7zlM2wZcrF7r-LX1uiQwYjN1TMovRds=.17e06f8b-1d83-42c4-8d38-6ccaeaacdc9e@github.com>
Message-ID: 

On Thu, 10 Feb 2022 14:08:48 GMT, Maxim Kartashev  wrote:

> The primary API for image capture on modern Linuxes is `gdk_pixbuf_get_from_window()` that expects both coordinates and the size unscaled (i.e. not multiplied by the current desktop scale). At the same time, `gtk3_interface.c:gtk3_get_drawable_data()` gets the coordinates from `Robot` that pre-scales them (multiplying by the scale known to Java, however, not necessarily the current desktop scale). The problem with the size had been partly taken care of in [JDK-8225118](https://bugs.openjdk.java.net/browse/JDK-8225118), but coordinates are still passed to `gdk_pixbuf_get_from_window()` pre-scaled.
> 
> The idea of the fix is to capture a possibly larger area that is guaranteed to contain the one that is interesting to the caller and then only copy the interesting pixels to the output image. As a positive side effect, the size of the captured area cannot be less than 1x1 (provided the correct input, of course). This solves the problem of zero size passed to  `(*fp_gdk_pixbuf_get_from_drawable)` when the desktop scale is 3 and we're asked to capture just one pixel. In that case, the previous formula (`width / (float) win_scale + 0.5`) would have yielded `0`. 
> 
> A related issue would be that tests written specifically for this general area (`java/awt/Robot`) didn't catch this problem and only somewhat unrelated tests (`javax/swing/...`) were affected.
> 
> This one is solved by adding pixel-sized areas to the test image in `HiDPIRobotScreenCaptureTest.java`, which precise colors are then verified to match the expected ones. In addition to that, instead of verifying just the color of the center of a large area, 4 more pixels close to the area's border are checked. This helps to make sure that captured area coordinates aren't way off.
> 
> The tests under `javax/swing/...` that originally helped to identify this problem were modified to provide more screen space for painting their components as extreme desktop scaling (300%) on Ubuntu doesn't leave much room due to a humongous title bar.
> 
> The fix was tested by running all the modified tests on Ubuntu with desktop scaling set to 100%, 200%, and 300%. The `Robot` tests were also executed on Windows (300% scaling) and MacOS.

src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c line 2874:

> 2872: }
> 2873: 
> 2874: static gboolean gtk3_get_drawable_data(JNIEnv *env, jintArray pixelArray,

Don't we need to do the same for the gtk2? I suggest to update one of the test below to cover gtk_robot on/off for both gtk2/gtk3.

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

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

From duke at openjdk.java.net  Thu Feb 10 18:20:05 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Thu, 10 Feb 2022 18:20:05 GMT
Subject: RFR: 8280861: Robot color picker broken on Linux with scaling
 above 100%
In-Reply-To: 
References: <7WQIrQr1kH9q7zlM2wZcrF7r-LX1uiQwYjN1TMovRds=.17e06f8b-1d83-42c4-8d38-6ccaeaacdc9e@github.com>

Message-ID: 

On Thu, 10 Feb 2022 18:04:37 GMT, Sergey Bylokhov  wrote:

>> The primary API for image capture on modern Linuxes is `gdk_pixbuf_get_from_window()` that expects both coordinates and the size unscaled (i.e. not multiplied by the current desktop scale). At the same time, `gtk3_interface.c:gtk3_get_drawable_data()` gets the coordinates from `Robot` that pre-scales them (multiplying by the scale known to Java, however, not necessarily the current desktop scale). The problem with the size had been partly taken care of in [JDK-8225118](https://bugs.openjdk.java.net/browse/JDK-8225118), but coordinates are still passed to `gdk_pixbuf_get_from_window()` pre-scaled.
>> 
>> The idea of the fix is to capture a possibly larger area that is guaranteed to contain the one that is interesting to the caller and then only copy the interesting pixels to the output image. As a positive side effect, the size of the captured area cannot be less than 1x1 (provided the correct input, of course). This solves the problem of zero size passed to  `(*fp_gdk_pixbuf_get_from_drawable)` when the desktop scale is 3 and we're asked to capture just one pixel. In that case, the previous formula (`width / (float) win_scale + 0.5`) would have yielded `0`. 
>> 
>> A related issue would be that tests written specifically for this general area (`java/awt/Robot`) didn't catch this problem and only somewhat unrelated tests (`javax/swing/...`) were affected.
>> 
>> This one is solved by adding pixel-sized areas to the test image in `HiDPIRobotScreenCaptureTest.java`, which precise colors are then verified to match the expected ones. In addition to that, instead of verifying just the color of the center of a large area, 4 more pixels close to the area's border are checked. This helps to make sure that captured area coordinates aren't way off.
>> 
>> The tests under `javax/swing/...` that originally helped to identify this problem were modified to provide more screen space for painting their components as extreme desktop scaling (300%) on Ubuntu doesn't leave much room due to a humongous title bar.
>> 
>> The fix was tested by running all the modified tests on Ubuntu with desktop scaling set to 100%, 200%, and 300%. The `Robot` tests were also executed on Windows (300% scaling) and MacOS.
>
> src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c line 2874:
> 
>> 2872: }
>> 2873: 
>> 2874: static gboolean gtk3_get_drawable_data(JNIEnv *env, jintArray pixelArray,
> 
> Don't we need to do the same for the gtk2? I suggest to update one of the test below to cover gtk_robot on/off for both gtk2/gtk3.

Maybe not as the previous fix was mode for gtk3 only, but I can double-check. Do you know if MATE desktop environment  is a good candidate for finding gtk2 or are there easier options on Ubuntu?

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

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

From serb at openjdk.java.net  Thu Feb 10 18:25:02 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 10 Feb 2022 18:25:02 GMT
Subject: RFR: 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: 

On Thu, 10 Feb 2022 04:59:33 GMT, Anton Litvinov  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

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?

src/java.desktop/share/classes/javax/swing/JTable.java line 5508:

> 5506:                     (table != null) && table.isEnabled() &&
> 5507:                     table.isCellEditable(row, column)) {
> 5508:                     table.setValueAt(Boolean.valueOf(newSelectedState),

Where this code is triggered if the user click on the checkbox by the mouse?

test/jdk/javax/accessibility/JTable/JCheckBoxInJTableCannotBeClickedTest.java line 92:

> 90: 
> 91:     private void createGUI() {
> 92:         if (!(UIManager.getLookAndFeel() instanceof MetalLookAndFeel)) {

Why the metal L&F is tested, should at least any default L&F works(like Aqua)?

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

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

From prr at openjdk.java.net  Thu Feb 10 22:32:08 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 10 Feb 2022 22:32:08 GMT
Subject: RFR: 8280861: Robot color picker broken on Linux with scaling
 above 100%
In-Reply-To: 
References: <7WQIrQr1kH9q7zlM2wZcrF7r-LX1uiQwYjN1TMovRds=.17e06f8b-1d83-42c4-8d38-6ccaeaacdc9e@github.com>

Message-ID: 

On Thu, 10 Feb 2022 18:16:29 GMT, Maxim Kartashev  wrote:

>> src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c line 2874:
>> 
>>> 2872: }
>>> 2873: 
>>> 2874: static gboolean gtk3_get_drawable_data(JNIEnv *env, jintArray pixelArray,
>> 
>> Don't we need to do the same for the gtk2? I suggest to update one of the test below to cover gtk_robot on/off for both gtk2/gtk3.
>
> Maybe not as the previous fix was mode for gtk3 only, but I can double-check. Do you know if MATE desktop environment  is a good candidate for finding gtk2 or are there easier options on Ubuntu?

I have no idea what MATE is but if you are saying you have a recent Ubuntu and you don't have GTK2, I am at least 95% sure GTK2 is still available from Ubuntu package manager for all current releases.

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

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

From duke at openjdk.java.net  Thu Feb 10 22:45:58 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Thu, 10 Feb 2022 22:45:58 GMT
Subject: RFR: JDK-8016524: [macosx] Bottom line is not visible for
 JTableHeader [v6]
In-Reply-To: 
References: 
Message-ID: 

> Previously, the JTableHeader Bottom line wasn't visible on MacOS LAF (Aqua). With the fix the bottom line (light grey) is visible. 
> 
> Changes were made to AquaTableHeaderBorder.paintBorder method and the height of the component+border was adjusted in paint method.
> 
> A new test case (JTHeaderBorderTest.java) was added to test the fix as there was no corresponding test case present for this issue previously. The test checks if the border is visible by checking the color at the border location with the background color of the table and table-header, if both are different test case passes and it fails if the pixel color at border location matches either the table-header or table background color.

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

  Changed test case to use BufferedImage to prevent retina-pixel scaling issues

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7219/files
  - new: https://git.openjdk.java.net/jdk/pull/7219/files/552d4099..52374b86

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

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

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

From serb at openjdk.java.net  Thu Feb 10 23:01:10 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 10 Feb 2022 23:01:10 GMT
Subject: RFR: 8281555: [macos] Get rid of deprecated Style Masks constants
In-Reply-To: 
References: 
Message-ID: 

On Wed, 9 Feb 2022 17:50:48 GMT, Dmitry Markov  wrote:

> The Style Masks constants [1], which are utilised by AWT, were deprecated starting from macOS 10.12 Sierra. It is high time to replace them with new constants introduced by NSWindowStyleMask enumeration [2].
> 
> [1] - https://developer.apple.com/documentation/appkit/nspanel/style_masks
> [2] - https://developer.apple.com/documentation/appkit/nswindowstylemask

DId you check that all new constants are work the same way as the old one? For example the doc for the new "[NSWindowStyleMaskUnifiedTitleAndToolbar](https://developer.apple.com/documentation/appkit/nswindowstylemask/nswindowstylemaskunifiedtitleandtoolbar)" "said it has no effect".

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

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

From serb at openjdk.java.net  Thu Feb 10 23:04:10 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 10 Feb 2022 23:04:10 GMT
Subject: RFR: 8277369: Strange behavior of JMenuBar with RIGHT_TO_LEFT
 orientation, arrow keys behaves opposite traversing through keyboard
In-Reply-To: 
References: 
Message-ID: 

On Wed, 9 Feb 2022 05:39:52 GMT, Prasanta Sadhukhan  wrote:

> After applying setComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) to the JMenuBar the arrow keys started to behave the opposite of what expected. Right arrow goes left and Left arrow goes right when trying to traverse through keyboard.
> 
> Fixed to reverse the direction traversal for RTL orientation.

test/jdk/javax/swing/JMenuBar/MenuBarRTLBug.java line 70:

> 68:     static volatile boolean passed = false;
> 69: 
> 70:     public static void main(String[] args) throws  Exception {

The submitter said that he use the native L&F should not we check it in the test?

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

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

From prr at openjdk.java.net  Thu Feb 10 23:38:09 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 10 Feb 2022 23:38:09 GMT
Subject: RFR: 8275345: RasterFormatException when drawing a tiled image
 made of non-writable rasters [v2]
In-Reply-To: 
References: 

Message-ID: <1cuXpSh6COBJPM5zkFzZUXqPj_a-KE-7zZOnlk5rRwE=.72f96193-37e6-4fad-8c61-953197d2545c@github.com>

On Thu, 10 Feb 2022 10:22:43 GMT, Martin Desruisseaux  wrote:

>> This commit fixes a `RasterFormatException` thrown when `Graphics2D.drawRenderedImage(?)` is invoked with an image containing tiles that are instances of `Raster` but not `WritableRaster`.
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8275345
>
> Martin Desruisseaux has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add jtreg @test, @bug and @summary tags. Remove HTML  tags. Edit comments.

test/jdk/java/awt/image/DrawImage/TiledImage.java line 98:

> 96:  */
> 97: final class TiledImage implements RenderedImage {
> 98:     /**

Still not right. Now you added the tags I ran under jtreg and it errored out.
result: Error. java.lang.IllegalAccessException: class com.sun.javatest.regtest.agent.MainWrapper$MainThread cannot access a member of class TiledImage with modifiers "public static

Basically change "final" to "public" - or at least add public. 

Might be prudent to try this for yourself - and useful for the future.
jtreg instructions for building it can be found here : https://openjdk.java.net/jtreg/build.html
Very possibly there's someone that provides a pre-built binary. There's none on OpenJDK.

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

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

From prr at openjdk.java.net  Fri Feb 11 00:04:26 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 11 Feb 2022 00:04:26 GMT
Subject: RFR: 8269091: javax/sound/sampled/Clip/SetPositionHang.java failed
 with ArrayIndexOutOfBoundsException: Array index out of range: -4
Message-ID: 

This test has started failing since we got M1 macs to test on. I don't think we've ever seen this failure elsewhere.
I don't know what it is about that architecture that makes it more likely but I can see how it can happen when multiple threads are using the same instance. 

                    if (newFramePosition >= 0) { 
                        clipBytePosition = newFramePosition * frameSize; 
                        newFramePosition = -1; 
                    } 

newFramePosition is declared volatile which does make it quite possible that after the read and before the use it will have changed.

The fix just synchronizes this block to prevent it.

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

Commit messages:
 - 8269091: javax/sound/sampled/Clip/SetPositionHang.java failed with ArrayIndexOutOfBoundsException: Array index out of range: -4

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

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

From duke at openjdk.java.net  Fri Feb 11 01:21:09 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Fri, 11 Feb 2022 01:21:09 GMT
Subject: RFR: JDK-8016524: [macosx] Bottom line is not visible for
 JTableHeader [v6]
In-Reply-To: <-R3bNESejIAwk69oyF_PrVq7d6W5V_GSzXT7ipoF8lY=.0bc69e39-c6cc-485f-ab95-98b6b0439078@github.com>
References: 
 <5wjVB_FL_GYsLbqr_FEpBsFX3twlM9cXbrN8a3r2rDY=.e42f518a-dc26-49cb-9949-32426cf85fa8@github.com>

 <-R3bNESejIAwk69oyF_PrVq7d6W5V_GSzXT7ipoF8lY=.0bc69e39-c6cc-485f-ab95-98b6b0439078@github.com>
Message-ID: 

On Mon, 7 Feb 2022 09:06:06 GMT, Prasanta Sadhukhan  wrote:

>> I see it fails for me in mac 10.15..DId you see it pass locally for you and in CI systems? Also, it should show 3 rows including row showing "A""B""C" as it is shown in windows/ubuntu, why it is showing only 1 row here?
>> 
>> 
>
> I got the 2nd part of the question myself which is because of white gridlines used in AquaLookAndFeel so invisible..

@prsadhuk Ready for review. Changed the test case to paint JFrame to BufferedImage. The test case is marked headful though robot calls are not used, as the JFrame rendering requires it to be headful.

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

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

From duke at openjdk.java.net  Fri Feb 11 01:55:53 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Fri, 11 Feb 2022 01:55:53 GMT
Subject: RFR: 8202836 : [macosx] test
 java/awt/Graphics/TextAAHintsTest.java fails [v5]
In-Reply-To: 
References: 
Message-ID: 

> 1) Removed =yesno that was causing the test to fail with following exception
> test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno
> After removing =yesno, test was just passing without user interaction so fixed the following
> 
> Add the following so that user can user interact with the test
> a) Added pass/fail button and instruction for the user to know what he/she is going to test and what is expected.
> b) Added Dialog with textarea to enter the reason for the testcase failure. This will help the user to understanding the reason why the test was failed while analyzing the results. 
> 
> @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/7275/files
  - new: https://git.openjdk.java.net/jdk/pull/7275/files/f42940cd..ea2f6373

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

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

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

From duke at openjdk.java.net  Fri Feb 11 01:55:56 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Fri, 11 Feb 2022 01:55:56 GMT
Subject: RFR: 8202836 : [macosx] test
 java/awt/Graphics/TextAAHintsTest.java fails [v4]
In-Reply-To: 
References: 
 <30iOzkwefS6EJE8VLj9-NJ7oysi9WLq3cAOvPug4Wn8=.37f381a6-455a-42d9-982b-84cc1d290722@github.com>

Message-ID: 

On Thu, 10 Feb 2022 08:47:51 GMT, Alexey Ivanov  wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed RenderingHints.VALUE_TEXT_ANTIALIAS_GASP and fixed the review comments
>
> test/jdk/java/awt/Graphics/TextAAHintsTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2007, 2022 Oracle and/or its affiliates. All rights reserved.
> 
> Suggestion:
> 
>  * Copyright (c) 2007, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> One more comma.

Done

> test/jdk/java/awt/Graphics/TextAAHintsTest.java line 59:
> 
>> 57:     public static final CountDownLatch countDownLatch = new CountDownLatch(1);
>> 58:     private static Frame frame;
>> 59:     public static String failureReason;
> 
> `failureReason` should also be `volatile`.
> 
> All the fields can be `private`. You access them from this class only; nested classes, including the static ones, have access to private members of the surrounding class.

Fixed

> test/jdk/java/awt/Graphics/TextAAHintsTest.java line 199:
> 
>> 197:     }
>> 198: 
>> 199:     public static void readFailedReason() {
> 
> `readFailureReason` or `getFailureReason`?

Fixed the method name to getFailureReason

> test/jdk/java/awt/Graphics/TextAAHintsTest.java line 221:
> 
>> 219: 
>> 220:     public static void main(String[] args) throws InterruptedException, InvocationTargetException {
>> 221:         java.awt.EventQueue.invokeAndWait(TextAAHintsTest::createTestUI);
> 
> I wonder why `EventQueue` uses fully qualified class name instead of being imported as other classes. That's fine, I'm just wondering.

Fixed

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

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

From serb at openjdk.java.net  Fri Feb 11 05:20:09 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 11 Feb 2022 05:20:09 GMT
Subject: RFR: 8269091: javax/sound/sampled/Clip/SetPositionHang.java failed
 with ArrayIndexOutOfBoundsException: Array index out of range: -4
In-Reply-To: 
References: 
Message-ID: <_E4C4Jtr6DF11jbV8eYj1i5c790Ag-mbeavrXGuE918=.efca4380-6b0e-4247-9348-e8e0c5b7274b@github.com>

On Thu, 10 Feb 2022 23:57:29 GMT, Phil Race  wrote:

> This test has started failing since we got M1 macs to test on. I don't think we've ever seen this failure elsewhere.
> I don't know what it is about that architecture that makes it more likely but I can see how it can happen when multiple threads are using the same instance. 
> 
>                     if (newFramePosition >= 0) { 
>                         clipBytePosition = newFramePosition * frameSize; 
>                         newFramePosition = -1; 
>                     } 
> 
> newFramePosition is declared volatile which does make it quite possible that after the read and before the use it will have changed.
> 
> The fix just synchronizes this block to prevent it.

src/java.desktop/share/classes/com/sun/media/sound/DirectAudioDevice.java line 1300:

> 1298:                 }
> 1299:                 while (doIO && thread == curThread) {
> 1300:                     synchronized (this) {

Maybe instead of synchronization we can read it to the local variable,then use, then reset to -1? This class already has many different locks used for synchronization and this one add another one for "this".

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

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

From duke at openjdk.java.net  Fri Feb 11 06:18:09 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Fri, 11 Feb 2022 06:18:09 GMT
Subject: RFR: 8280861: Robot color picker broken on Linux with scaling
 above 100%
In-Reply-To: 
References: <7WQIrQr1kH9q7zlM2wZcrF7r-LX1uiQwYjN1TMovRds=.17e06f8b-1d83-42c4-8d38-6ccaeaacdc9e@github.com>

Message-ID: 

On Thu, 10 Feb 2022 22:28:56 GMT, Phil Race  wrote:

>> Maybe not as the previous fix was mode for gtk3 only, but I can double-check. Do you know if MATE desktop environment  is a good candidate for finding gtk2 or are there easier options on Ubuntu?
>
> I have no idea what MATE is but if you are saying you have a recent Ubuntu and you don't have GTK2, I am at least 95% sure GTK2 is still available from Ubuntu package manager for all current releases.

MATE desktop continues the "traditional" Gnome2 desktop development, so I thought it would be a good test for Gtk2 interfaces. FWIW, I ran the tests on such a system with DPI set to 200 (there's no other way to scale the interface under MATE AFAIK) and they all pass. However, the test executes the same code path as before going by `if (gtk3_version_3_10)` branch.

@prrace 
> GTK2 is still available from Ubuntu package manager for all current releases.

Right, but as long as gtk3 is *also* available, that's what we are going to use as AWT backend, see the code in [gtk_interface.c](https://github.com/openjdk/jdk/blob/eee6a5622dca683d4d6a701daa48e09e8d17b54e/src/java.desktop/unix/native/libawt_xawt/awt/gtk_interface.c#L109).
I hacked around to forbid gtk3 from loading and the tests still passed (this time, without executing my changes).
I think gtk2 has no real notion of scale so the coordinates and size are always in screen pixels. See, for example, the documentation for [gdk_pixbuf_get_from_drawable()](https://www.manpagez.com/html/gdk2/gdk2-2.24.29/gdk2-Pixbufs.php#gdk-pixbuf-get-from-drawable).

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

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

From serb at openjdk.java.net  Fri Feb 11 07:13:09 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 11 Feb 2022 07:13:09 GMT
Subject: RFR: 8280861: Robot color picker broken on Linux with scaling
 above 100%
In-Reply-To: 
References: <7WQIrQr1kH9q7zlM2wZcrF7r-LX1uiQwYjN1TMovRds=.17e06f8b-1d83-42c4-8d38-6ccaeaacdc9e@github.com>

Message-ID: 

On Fri, 11 Feb 2022 06:14:27 GMT, Maxim Kartashev  wrote:

>> I have no idea what MATE is but if you are saying you have a recent Ubuntu and you don't have GTK2, I am at least 95% sure GTK2 is still available from Ubuntu package manager for all current releases.
>
> MATE desktop continues the "traditional" Gnome2 desktop development, so I thought it would be a good test for Gtk2 interfaces. FWIW, I ran the tests on such a system with DPI set to 200 (there's no other way to scale the interface under MATE AFAIK) and they all pass. However, the test executes the same code path as before going by `if (gtk3_version_3_10)` branch.
> 
> @prrace 
>> GTK2 is still available from Ubuntu package manager for all current releases.
> 
> Right, but as long as gtk3 is *also* available, that's what we are going to use as AWT backend, see the code in [gtk_interface.c](https://github.com/openjdk/jdk/blob/eee6a5622dca683d4d6a701daa48e09e8d17b54e/src/java.desktop/unix/native/libawt_xawt/awt/gtk_interface.c#L109).
> I hacked around to forbid gtk3 from loading and the tests still passed (this time, without executing my changes).
> I think gtk2 has no real notion of scale so the coordinates and size are always in screen pixels. See, for example, the documentation for [gdk_pixbuf_get_from_drawable()](https://www.manpagez.com/html/gdk2/gdk2-2.24.29/gdk2-Pixbufs.php#gdk-pixbuf-get-from-drawable).

You do not need to hack the code, just add a "jdk.gtk.version" option to enable specific gtk version, this is what I suggested above. to disable the gtk usage in the robot the "awt.robot.gtk" can be used. So you can add that to some test to check that code paths works.

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

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

From serb at openjdk.java.net  Fri Feb 11 07:32:12 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 11 Feb 2022 07:32:12 GMT
Subject: RFR: 8280861: Robot color picker broken on Linux with scaling
 above 100%
In-Reply-To: <7WQIrQr1kH9q7zlM2wZcrF7r-LX1uiQwYjN1TMovRds=.17e06f8b-1d83-42c4-8d38-6ccaeaacdc9e@github.com>
References: <7WQIrQr1kH9q7zlM2wZcrF7r-LX1uiQwYjN1TMovRds=.17e06f8b-1d83-42c4-8d38-6ccaeaacdc9e@github.com>
Message-ID: 

On Thu, 10 Feb 2022 14:08:48 GMT, Maxim Kartashev  wrote:

> The primary API for image capture on modern Linuxes is `gdk_pixbuf_get_from_window()` that expects both coordinates and the size unscaled (i.e. not multiplied by the current desktop scale). At the same time, `gtk3_interface.c:gtk3_get_drawable_data()` gets the coordinates from `Robot` that pre-scales them (multiplying by the scale known to Java, however, not necessarily the current desktop scale). The problem with the size had been partly taken care of in [JDK-8225118](https://bugs.openjdk.java.net/browse/JDK-8225118), but coordinates are still passed to `gdk_pixbuf_get_from_window()` pre-scaled.
> 
> The idea of the fix is to capture a possibly larger area that is guaranteed to contain the one that is interesting to the caller and then only copy the interesting pixels to the output image. As a positive side effect, the size of the captured area cannot be less than 1x1 (provided the correct input, of course). This solves the problem of zero size passed to  `(*fp_gdk_pixbuf_get_from_drawable)` when the desktop scale is 3 and we're asked to capture just one pixel. In that case, the previous formula (`width / (float) win_scale + 0.5`) would have yielded `0`. 
> 
> A related issue would be that tests written specifically for this general area (`java/awt/Robot`) didn't catch this problem and only somewhat unrelated tests (`javax/swing/...`) were affected.
> 
> This one is solved by adding pixel-sized areas to the test image in `HiDPIRobotScreenCaptureTest.java`, which precise colors are then verified to match the expected ones. In addition to that, instead of verifying just the color of the center of a large area, 4 more pixels close to the area's border are checked. This helps to make sure that captured area coordinates aren't way off.
> 
> The tests under `javax/swing/...` that originally helped to identify this problem were modified to provide more screen space for painting their components as extreme desktop scaling (300%) on Ubuntu doesn't leave much room due to a humongous title bar.
> 
> The fix was tested by running all the modified tests on Ubuntu with desktop scaling set to 100%, 200%, and 300%. The `Robot` tests were also executed on Windows (300% scaling) and MacOS.

src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c line 2876:

> 2874: static gboolean gtk3_get_drawable_data(JNIEnv *env, jintArray pixelArray,
> 2875:      int x, jint y, jint width, jint height, jint jwidth, int dx, int dy,
> 2876:                                                                    jint scale) {

Is this scale parameter is simply ignored? If the passed parameters are always in the device space and the array is allocated properly then we should not care about this scale(especially in case of gtk2)?

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

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

From serb at openjdk.java.net  Fri Feb 11 07:45:11 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 11 Feb 2022 07:45:11 GMT
Subject: Integrated: 8281419: The source data for the color conversion can be
 discarded
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Feb 2022 05:42:47 GMT, Sergey Bylokhov  wrote:

> When we convert the image from one color profile to another one we copy data to the temp array, and after conversion, we commit both(src and dst). But the source array could be discarded since we do not(should not) change it. 
> 
> Tested on windows (fastest result after a few runs). ThreadsMAX is 32 threads. The test is just a "ColorConvertOp.filter()" for the opaque buffered image.
> 
> ![images](https://user-images.githubusercontent.com/14138494/152925400-cf248f88-e2ba-47ec-8d58-71784026ff8a.png)
> 
> https://jmh.morethan.io/?gists=541569ac2fe6173d471455d282680fa2,d3b91e1fba067c71fc73a6df8d47773f

This pull request has now been integrated.

Changeset: 8441d51e
Author:    Sergey Bylokhov 
URL:       https://git.openjdk.java.net/jdk/commit/8441d51e71e143250b44eea74114a624cf00cc3e
Stats:     10 lines in 1 file changed: 1 ins; 0 del; 9 mod

8281419: The source data for the color conversion can be discarded

Reviewed-by: prr, aivanov

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

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

From psadhukhan at openjdk.java.net  Fri Feb 11 08:08:52 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 11 Feb 2022 08:08:52 GMT
Subject: RFR: 8277369: Strange behavior of JMenuBar with RIGHT_TO_LEFT
 orientation, arrow keys behaves opposite traversing through keyboard [v2]
In-Reply-To: 
References: 
Message-ID: <28F_t6q1Y2OOYS1M_reXGPUSmwy7T4_GugF4oahk554=.df6b69bb-715a-4d42-8987-1bd0ee7863ae@github.com>

> After applying setComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) to the JMenuBar the arrow keys started to behave the opposite of what expected. Right arrow goes left and Left arrow goes right when trying to traverse through keyboard.
> 
> Fixed to reverse the direction traversal for RTL orientation.

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

  Added L&F iteration

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7396/files
  - new: https://git.openjdk.java.net/jdk/pull/7396/files/8afcf220..19b72d40

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

  Stats: 173 lines in 1 file changed: 88 ins; 71 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7396.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7396/head:pull/7396

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

From psadhukhan at openjdk.java.net  Fri Feb 11 08:08:53 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 11 Feb 2022 08:08:53 GMT
Subject: RFR: 8277369: Strange behavior of JMenuBar with RIGHT_TO_LEFT
 orientation, arrow keys behaves opposite traversing through keyboard [v2]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 10 Feb 2022 23:00:50 GMT, Sergey Bylokhov  wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added L&F iteration
>
> test/jdk/javax/swing/JMenuBar/MenuBarRTLBug.java line 70:
> 
>> 68:     static volatile boolean passed = false;
>> 69: 
>> 70:     public static void main(String[] args) throws  Exception {
> 
> The submitter said that he use the native L&F should not we check it in the test?

Might as well. Added L&F iteration in the test.

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

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

From psadhukhan at openjdk.java.net  Fri Feb 11 08:09:13 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 11 Feb 2022 08:09:13 GMT
Subject: RFR: JDK-8016524: [macosx] Bottom line is not visible for
 JTableHeader [v6]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 10 Feb 2022 22:45:58 GMT, Harshitha Onkar  wrote:

>> Previously, the JTableHeader Bottom line wasn't visible on MacOS LAF (Aqua). With the fix the bottom line (light grey) is visible. 
>> 
>> Changes were made to AquaTableHeaderBorder.paintBorder method and the height of the component+border was adjusted in paint method.
>> 
>> A new test case (JTHeaderBorderTest.java) was added to test the fix as there was no corresponding test case present for this issue previously. The test checks if the border is visible by checking the color at the border location with the background color of the table and table-header, if both are different test case passes and it fails if the pixel color at border location matches either the table-header or table background color.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed test case to use BufferedImage to prevent retina-pixel scaling issues

test/jdk/javax/swing/JTableHeader/8016524/JTHeaderBorderTest.java line 33:

> 31:  */
> 32: 
> 33: import java.awt.*;

please expand this wildcard import

test/jdk/javax/swing/JTableHeader/8016524/JTHeaderBorderTest.java line 90:

> 88:                 String headerColor = Integer.toHexString(table.getTableHeader().getBackground().getRGB());
> 89:                 String pixelColor = tableColor;
> 90:                 boolean isBottomLineVisible = false;

To nitpick, I will much rather use Color instead of converting to String as we are trying to check and compare for Color but it's not a dealbreaker.

test/jdk/javax/swing/JTableHeader/8016524/JTHeaderBorderTest.java line 93:

> 91: 
> 92:                 // scan table header region to check if bottom border of JTableHeader is visible
> 93:                 for (int y = Y_OFFSET; y <= Y_OFFSET+25; y++) {

Can't we use X_OFFSET for hardcoded 25 here?

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

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

From duke at openjdk.java.net  Fri Feb 11 08:12:17 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Fri, 11 Feb 2022 08:12:17 GMT
Subject: RFR: 8280861: Robot color picker broken on Linux with scaling
 above 100%
In-Reply-To: 
References: <7WQIrQr1kH9q7zlM2wZcrF7r-LX1uiQwYjN1TMovRds=.17e06f8b-1d83-42c4-8d38-6ccaeaacdc9e@github.com>

Message-ID: 

On Fri, 11 Feb 2022 07:28:28 GMT, Sergey Bylokhov  wrote:

> Is this scale parameter is simply ignored?

Looks like it. I can only find one call site of `get_drawable_data()` (in [Java_sun_awt_X11_XRobotPeer_getRGBPixelsImpl()](https://github.com/openjdk/jdk/blob/8441d51e71e143250b44eea74114a624cf00cc3e/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c#L336)) and the `scale` parameter is always 1. I think I can drop it from the interface if you prefer.

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

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

From psadhukhan at openjdk.java.net  Fri Feb 11 08:13:07 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 11 Feb 2022 08:13:07 GMT
Subject: RFR: 8241192: [macosx] Wrong letter typed after =?UTF-8?B?wrQ=?=
 symbol when using Finnish layout
In-Reply-To: 
References: 
Message-ID: 

On Fri, 28 Jan 2022 09:38:35 GMT, Prasanta Sadhukhan  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.

The usecase in JBS mention about ` ? + s` combination so the fix was done for that..But now that the scope of issue is expanded to consonants too, the fix needs to be expanded too

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

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

From duke at openjdk.java.net  Fri Feb 11 09:28:31 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Fri, 11 Feb 2022 09:28:31 GMT
Subject: RFR: 8236907: JTable added to nested panels does not paint last
 visible row
Message-ID: 

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.

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

Commit messages:
 - 8236907: JTable added to nested panels does not paint last
 - Merge branch 'branch_8236907' of github.com:TejeshR13/jdk into branch_8236907
 - 8236907: JTable added to nested panels does not paint last
 - 8236907: JTable added to nested panels does not paint last
 - 8236907: JTable added to nested panels does not paint last
 - 8236907: JTable added to nested panels does not paint last
 - Merge branch 'master' of github.com:TejeshR13/jdk
 - Initial Commit.

Changes: https://git.openjdk.java.net/jdk/pull/7422/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7422&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8236907
  Stats: 279 lines in 3 files changed: 258 ins; 17 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7422.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7422/head:pull/7422

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

From psadhukhan at openjdk.java.net  Fri Feb 11 09:43:11 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 11 Feb 2022 09:43:11 GMT
Subject: Integrated: 8047749: javadoc for getPathBounds() in TreeUI and
 BasicTreeUI is incorrect
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Feb 2022 08:11:04 GMT, Prasanta Sadhukhan  wrote:

> The javadoc descriptions for javax.swing.plaf.TreeUI.getPathBounds() and javax.swing.plaf.basic.BasicTreeUI.getPathBounds() have stated it returns null if any component in path is currently "valid", which is wrong.
> The getPathBounds() in BasicTreeUI returns null if tree or treeState is null. 
> Fixed the javadoc.

This pull request has now been integrated.

Changeset: 4d640760
Author:    Prasanta Sadhukhan 
URL:       https://git.openjdk.java.net/jdk/commit/4d64076058a4ec5df101b06572195ed5fdee6f64
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8047749: javadoc for getPathBounds() in TreeUI and BasicTreeUI is incorrect

Reviewed-by: aivanov

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

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

From duke at openjdk.java.net  Fri Feb 11 10:43:11 2022
From: duke at openjdk.java.net (Martin Desruisseaux)
Date: Fri, 11 Feb 2022 10:43:11 GMT
Subject: RFR: 8275345: RasterFormatException when drawing a tiled image
 made of non-writable rasters [v2]
In-Reply-To: <1cuXpSh6COBJPM5zkFzZUXqPj_a-KE-7zZOnlk5rRwE=.72f96193-37e6-4fad-8c61-953197d2545c@github.com>
References: 

 <1cuXpSh6COBJPM5zkFzZUXqPj_a-KE-7zZOnlk5rRwE=.72f96193-37e6-4fad-8c61-953197d2545c@github.com>
Message-ID: 

On Thu, 10 Feb 2022 23:34:58 GMT, Phil Race  wrote:

>> Martin Desruisseaux has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add jtreg @test, @bug and @summary tags. Remove HTML  tags. Edit comments.
>
> test/jdk/java/awt/image/DrawImage/TiledImage.java line 98:
> 
>> 96:  */
>> 97: final class TiledImage implements RenderedImage {
>> 98:     /**
> 
> Still not right. Now you added the tags I ran under jtreg and it errored out.
> result: Error. java.lang.IllegalAccessException: class com.sun.javatest.regtest.agent.MainWrapper$MainThread cannot access a member of class TiledImage with modifiers "public static
> 
> Basically change "final" to "public" - or at least add public. 
> 
> Might be prudent to try this for yourself - and useful for the future.
> jtreg instructions for building it can be found here : https://openjdk.java.net/jtreg/build.html
> Very possibly there's someone that provides a pre-built binary. There's none on OpenJDK.

Thanks for the tips and your patience. Actually I tried to run jtreg yesterday before to commit the change, but got the following error (I wanted to try on Java 17 first in order to verify that the test failed):

jtreg -jdk:$JAVA_HOME test/jdk/java/awt/image/DrawImage/TiledImage.java

failed to get value for vm.cds.write.archived.java.heap
java.lang.UnsatisfiedLinkError: 'boolean jdk.test.whitebox.WhiteBox.canWriteJavaHeapArchive()'
	at jdk.test.whitebox.WhiteBox.canWriteJavaHeapArchive(Native Method)
	at requires.VMProps.vmCDSCanWriteArchivedJavaHeap(VMProps.java:413)
	at requires.VMProps$SafeMap.put(VMProps.java:72)
	at requires.VMProps.call(VMProps.java:113)
	at requires.VMProps.call(VMProps.java:60)
	at com.sun.javatest.regtest.agent.GetJDKProperties.run(GetJDKProperties.java:80)
	at com.sun.javatest.regtest.agent.GetJDKProperties.main(GetJDKProperties.java:54)

I'm sure I did something wrong with my configuration?

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

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

From kizune at openjdk.java.net  Fri Feb 11 10:54:29 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 11 Feb 2022 10:54:29 GMT
Subject: RFR: 8281033: Improve ImageCheckboxTest to test all available LaF
Message-ID: 

Test modified to perform test on all available LaF's
During test development bug similar to JDK-8216358 was found in Nimbus and GTK+ LaFs
so exceptions were added and separate bugs were created to track these LaFs.

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

Commit messages:
 - 8281033: Improve ImageCheckboxTest to test all available LaF

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

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

From duke at openjdk.java.net  Fri Feb 11 11:22:15 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Fri, 11 Feb 2022 11:22:15 GMT
Subject: RFR: 8280861: Robot color picker broken on Linux with scaling
 above 100%
In-Reply-To: 
References: <7WQIrQr1kH9q7zlM2wZcrF7r-LX1uiQwYjN1TMovRds=.17e06f8b-1d83-42c4-8d38-6ccaeaacdc9e@github.com>

Message-ID: 

On Fri, 11 Feb 2022 07:09:39 GMT, Sergey Bylokhov  wrote:

>> MATE desktop continues the "traditional" Gnome2 desktop development, so I thought it would be a good test for Gtk2 interfaces. FWIW, I ran the tests on such a system with DPI set to 200 (there's no other way to scale the interface under MATE AFAIK) and they all pass. However, the test executes the same code path as before going by `if (gtk3_version_3_10)` branch.
>> 
>> @prrace 
>>> GTK2 is still available from Ubuntu package manager for all current releases.
>> 
>> Right, but as long as gtk3 is *also* available, that's what we are going to use as AWT backend, see the code in [gtk_interface.c](https://github.com/openjdk/jdk/blob/eee6a5622dca683d4d6a701daa48e09e8d17b54e/src/java.desktop/unix/native/libawt_xawt/awt/gtk_interface.c#L109).
>> I hacked around to forbid gtk3 from loading and the tests still passed (this time, without executing my changes).
>> I think gtk2 has no real notion of scale so the coordinates and size are always in screen pixels. See, for example, the documentation for [gdk_pixbuf_get_from_drawable()](https://www.manpagez.com/html/gdk2/gdk2-2.24.29/gdk2-Pixbufs.php#gdk-pixbuf-get-from-drawable).
>
> You do not need to hack the code, just add a "jdk.gtk.version" option to enable specific gtk version, this is what I suggested above. to disable the gtk usage in the robot the "awt.robot.gtk" can be used. So you can add that to some test to check that code paths works.

Thanks for the pointers, I'll set up a separate test for that.

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

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

From aivanov at openjdk.java.net  Fri Feb 11 11:50:13 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 11 Feb 2022 11:50:13 GMT
Subject: RFR: 8202836 : [macosx] test
 java/awt/Graphics/TextAAHintsTest.java fails [v5]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 11 Feb 2022 01:55:53 GMT, lawrence.andrews  wrote:

>> 1) Removed =yesno that was causing the test to fail with following exception
>> test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno
>> After removing =yesno, test was just passing without user interaction so fixed the following
>> 
>> Add the following so that user can user interact with the test
>> a) Added pass/fail button and instruction for the user to know what he/she is going to test and what is expected.
>> b) Added Dialog with textarea to enter the reason for the testcase failure. This will help the user to understanding the reason why the test was failed while analyzing the results. 
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed review comments

Marked as reviewed by aivanov (Reviewer).

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

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

From aivanov at openjdk.java.net  Fri Feb 11 12:59:18 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 11 Feb 2022 12:59:18 GMT
Subject: RFR: 8281535: Create a regression test for JDK-4670051
In-Reply-To: 
References: 
Message-ID: 

On Wed, 9 Feb 2022 14:58:10 GMT, Manukumar V S  wrote:

> Create a regression test for [JDK-4670051](https://bugs.openjdk.java.net/browse/JDK-4670051) which checks whether JSpinner with a SpinnerDateModel exactly spins the field where cursor is there.
> I have updated the testing details in the comment section of JDK-8281535.

test/jdk/javax/swing/JSpinner/4670051/JSpinnerFieldUnderCursorTest.java line 49:

> 47:  * @bug 4670051
> 48:  * @summary Checks whether JSpinner with a SpinnerDateModel
> 49:  * exactly spins the field where cursor is there.

Suggestion:

 * @summary Checks whether JSpinner with a SpinnerDateModel
 *          spins the field where cursor is located.

test/jdk/javax/swing/JSpinner/4670051/JSpinnerFieldUnderCursorTest.java line 124:

> 122:                 updateSpinnerValue();
> 123:                 // Increment Day
> 124:                 initValue = spinnerValue;

May I suggest modifying `updateSpinnerValue` so that it returns the updated value? I think this code will be clearer:

                initValue = getSpinnerValue();
                // Increment Day

test/jdk/javax/swing/JSpinner/4670051/JSpinnerFieldUnderCursorTest.java line 184:

> 182:     private static void updateSpinnerValue() throws Exception {
> 183:         SwingUtilities.invokeAndWait(() -> spinnerValue = (Date) spinner.getValue());
> 184:     }

Suggestion:

    private static Date getSpinnerValue() throws Exception {
        SwingUtilities.invokeAndWait(() -> spinnerValue = (Date) spinner.getValue());
        return spinnerValue;
    }

test/jdk/javax/swing/JSpinner/4670051/JSpinnerFieldUnderCursorTest.java line 214:

> 212:                 (d1.get(Calendar.DAY_OF_YEAR) == d2.get(Calendar.DAY_OF_YEAR)) &&
> 213:                 (d1.get(Calendar.DAY_OF_MONTH) == d2.get(Calendar.DAY_OF_MONTH));
> 214:     }

`DATE` and `DAY_OF_MONTH` return the same value.

Does it make sense to compare `MONTH` and `YEAR`? You never compare that the months or years are equal, the former, however, should be covered by `DAY_OF_YEAR`.

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

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

From aivanov at openjdk.java.net  Fri Feb 11 13:22:04 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 11 Feb 2022 13:22:04 GMT
Subject: RFR: 8281535: Create a regression test for JDK-4670051
In-Reply-To: 
References: 
Message-ID: 

On Wed, 9 Feb 2022 14:58:10 GMT, Manukumar V S  wrote:

> Create a regression test for [JDK-4670051](https://bugs.openjdk.java.net/browse/JDK-4670051) which checks whether JSpinner with a SpinnerDateModel exactly spins the field where cursor is there.
> I have updated the testing details in the comment section of JDK-8281535.

Does the new test reproduce the problem reported [JDK-4670051](https://bugs.openjdk.java.net/browse/JDK-4670051) with 1.4.0 vs 1.4.1?

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

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

From duke at openjdk.java.net  Fri Feb 11 14:01:58 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Fri, 11 Feb 2022 14:01:58 GMT
Subject: RFR: 8280861: Robot color picker broken on Linux with scaling
 above 100% [v2]
In-Reply-To: <7WQIrQr1kH9q7zlM2wZcrF7r-LX1uiQwYjN1TMovRds=.17e06f8b-1d83-42c4-8d38-6ccaeaacdc9e@github.com>
References: <7WQIrQr1kH9q7zlM2wZcrF7r-LX1uiQwYjN1TMovRds=.17e06f8b-1d83-42c4-8d38-6ccaeaacdc9e@github.com>
Message-ID: <02sN_VHXMu5T9cOtTl0lQQ0HzJ89oqOcf5SZxJ7-5xc=.b31be3e2-5510-4e45-8078-556fde93756c@github.com>

> The primary API for image capture on modern Linuxes is `gdk_pixbuf_get_from_window()` that expects both coordinates and the size unscaled (i.e. not multiplied by the current desktop scale). At the same time, `gtk3_interface.c:gtk3_get_drawable_data()` gets the coordinates from `Robot` that pre-scales them (multiplying by the scale known to Java, however, not necessarily the current desktop scale). The problem with the size had been partly taken care of in [JDK-8225118](https://bugs.openjdk.java.net/browse/JDK-8225118), but coordinates are still passed to `gdk_pixbuf_get_from_window()` pre-scaled.
> 
> The idea of the fix is to capture a possibly larger area that is guaranteed to contain the one that is interesting to the caller and then only copy the interesting pixels to the output image. As a positive side effect, the size of the captured area cannot be less than 1x1 (provided the correct input, of course). This solves the problem of zero size passed to  `(*fp_gdk_pixbuf_get_from_drawable)` when the desktop scale is 3 and we're asked to capture just one pixel. In that case, the previous formula (`width / (float) win_scale + 0.5`) would have yielded `0`. 
> 
> A related issue would be that tests written specifically for this general area (`java/awt/Robot`) didn't catch this problem and only somewhat unrelated tests (`javax/swing/...`) were affected.
> 
> This one is solved by adding pixel-sized areas to the test image in `HiDPIRobotScreenCaptureTest.java`, which precise colors are then verified to match the expected ones. In addition to that, instead of verifying just the color of the center of a large area, 4 more pixels close to the area's border are checked. This helps to make sure that captured area coordinates aren't way off.
> 
> The tests under `javax/swing/...` that originally helped to identify this problem were modified to provide more screen space for painting their components as extreme desktop scaling (300%) on Ubuntu doesn't leave much room due to a humongous title bar.
> 
> The fix was tested by running all the modified tests on Ubuntu with desktop scaling set to 100%, 200%, and 300%. The `Robot` tests were also executed on Windows (300% scaling) and MacOS.

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

 - Added a separate test with different GTK versions
 - Dropped the 'scale' parameter from gtk*_get_drawable_data() as it was
   effectively unused.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7425/files
  - new: https://git.openjdk.java.net/jdk/pull/7425/files/acb5637d..a00cdc4a

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

  Stats: 168 lines in 6 files changed: 111 ins; 53 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7425.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7425/head:pull/7425

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

From duke at openjdk.java.net  Fri Feb 11 14:05:39 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Fri, 11 Feb 2022 14:05:39 GMT
Subject: RFR: 8280861: Robot color picker broken on Linux with scaling
 above 100% [v3]
In-Reply-To: <7WQIrQr1kH9q7zlM2wZcrF7r-LX1uiQwYjN1TMovRds=.17e06f8b-1d83-42c4-8d38-6ccaeaacdc9e@github.com>
References: <7WQIrQr1kH9q7zlM2wZcrF7r-LX1uiQwYjN1TMovRds=.17e06f8b-1d83-42c4-8d38-6ccaeaacdc9e@github.com>
Message-ID: 

> The primary API for image capture on modern Linuxes is `gdk_pixbuf_get_from_window()` that expects both coordinates and the size unscaled (i.e. not multiplied by the current desktop scale). At the same time, `gtk3_interface.c:gtk3_get_drawable_data()` gets the coordinates from `Robot` that pre-scales them (multiplying by the scale known to Java, however, not necessarily the current desktop scale). The problem with the size had been partly taken care of in [JDK-8225118](https://bugs.openjdk.java.net/browse/JDK-8225118), but coordinates are still passed to `gdk_pixbuf_get_from_window()` pre-scaled.
> 
> The idea of the fix is to capture a possibly larger area that is guaranteed to contain the one that is interesting to the caller and then only copy the interesting pixels to the output image. As a positive side effect, the size of the captured area cannot be less than 1x1 (provided the correct input, of course). This solves the problem of zero size passed to  `(*fp_gdk_pixbuf_get_from_drawable)` when the desktop scale is 3 and we're asked to capture just one pixel. In that case, the previous formula (`width / (float) win_scale + 0.5`) would have yielded `0`. 
> 
> A related issue would be that tests written specifically for this general area (`java/awt/Robot`) didn't catch this problem and only somewhat unrelated tests (`javax/swing/...`) were affected.
> 
> This one is solved by adding pixel-sized areas to the test image in `HiDPIRobotScreenCaptureTest.java`, which precise colors are then verified to match the expected ones. In addition to that, instead of verifying just the color of the center of a large area, 4 more pixels close to the area's border are checked. This helps to make sure that captured area coordinates aren't way off.
> 
> The tests under `javax/swing/...` that originally helped to identify this problem were modified to provide more screen space for painting their components as extreme desktop scaling (300%) on Ubuntu doesn't leave much room due to a humongous title bar.
> 
> The fix was tested by running all the modified tests on Ubuntu with desktop scaling set to 100%, 200%, and 300%. The `Robot` tests were also executed on Windows (300% scaling) and MacOS.

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

  Updated copyright date in TestJProgressBarHighlightColor.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7425/files
  - new: https://git.openjdk.java.net/jdk/pull/7425/files/a00cdc4a..fc651add

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

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

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

From mvs at openjdk.java.net  Fri Feb 11 15:14:51 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Fri, 11 Feb 2022 15:14:51 GMT
Subject: RFR: 8281535: Create a regression test for JDK-4670051 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Create a regression test for [JDK-4670051](https://bugs.openjdk.java.net/browse/JDK-4670051) which checks whether JSpinner with a SpinnerDateModel exactly spins the field where cursor is there.
> I have updated the testing details in the comment section of JDK-8281535.

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

  Review comments fixed: Updated copyright, formatting changes, changed compareDates(), renamed some variables and methods.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7404/files
  - new: https://git.openjdk.java.net/jdk/pull/7404/files/de5ef09d..887f3158

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

  Stats: 123 lines in 1 file changed: 34 ins; 55 del; 34 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7404.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7404/head:pull/7404

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

From mvs at openjdk.java.net  Fri Feb 11 15:17:11 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Fri, 11 Feb 2022 15:17:11 GMT
Subject: RFR: 8281535: Create a regression test for JDK-4670051
In-Reply-To: 
References: 

Message-ID: 

On Fri, 11 Feb 2022 13:19:25 GMT, Alexey Ivanov  wrote:

> Does the new test reproduce the problem reported [JDK-4670051](https://bugs.openjdk.java.net/browse/JDK-4670051) with 1.4.0 vs 1.4.1?

Yes it was reproducible using JDK 1.4.0 and fixed in JDK 1.7.0 in Solaris Sparcv9 platform, where the bug [JDK-4670051](https://bugs.openjdk.java.net/browse/JDK-4670051) was originally reported

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

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

From aivanov at openjdk.java.net  Fri Feb 11 15:24:06 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 11 Feb 2022 15:24:06 GMT
Subject: RFR: 8281535: Create a regression test for JDK-4670051
In-Reply-To: 
References: 

Message-ID: 

On Fri, 11 Feb 2022 15:14:11 GMT, Manukumar V S  wrote:

> > Does the new test reproduce the problem reported [JDK-4670051](https://bugs.openjdk.java.net/browse/JDK-4670051) with 1.4.0 vs 1.4.1?
> 
> Yes it was reproducible using JDK 1.4.0 and fixed in JDK 1.7.0 in Solaris Sparcv9 platform, where the bug [JDK-4670051](https://bugs.openjdk.java.net/browse/JDK-4670051) was originally reported

I think it's incorrect to compare 1.4.0 and 1.7.0 directly. JDK-4670051 was fixed in 1.4.1, according to the records in JBS, so the test should pass in 1.4.1. Since that time, the test should pass in every release.

Anyway it's good to know the test fails in 1.4.0, which means it reproduces the original problem. Thank you for confirming.

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

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

From duke at openjdk.java.net  Fri Feb 11 15:37:13 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Fri, 11 Feb 2022 15:37:13 GMT
Subject: Integrated: 8202836 : [macosx] test
 java/awt/Graphics/TextAAHintsTest.java fails
In-Reply-To: 
References: 
Message-ID: 

On Fri, 28 Jan 2022 21:03:48 GMT, lawrence.andrews  wrote:

> 1) Removed =yesno that was causing the test to fail with following exception
> test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno
> After removing =yesno, test was just passing without user interaction so fixed the following
> 
> Add the following so that user can user interact with the test
> a) Added pass/fail button and instruction for the user to know what he/she is going to test and what is expected.
> b) Added Dialog with textarea to enter the reason for the testcase failure. This will help the user to understanding the reason why the test was failed while analyzing the results. 
> 
> @shurymury

This pull request has now been integrated.

Changeset: f399ae55
Author:    lawrence.andrews 
Committer: Alexey Ivanov 
URL:       https://git.openjdk.java.net/jdk/commit/f399ae558eabdce8960d339ef0758c023aeb89cc
Stats:     115 lines in 1 file changed: 93 ins; 5 del; 17 mod

8202836: [macosx] test java/awt/Graphics/TextAAHintsTest.java fails

Reviewed-by: prr, aivanov

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

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

From aivanov at openjdk.java.net  Fri Feb 11 15:37:12 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 11 Feb 2022 15:37:12 GMT
Subject: RFR: 8202836 : [macosx] test
 java/awt/Graphics/TextAAHintsTest.java fails [v5]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 11 Feb 2022 01:55:53 GMT, lawrence.andrews  wrote:

>> 1) Removed =yesno that was causing the test to fail with following exception
>> test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno
>> After removing =yesno, test was just passing without user interaction so fixed the following
>> 
>> Add the following so that user can user interact with the test
>> a) Added pass/fail button and instruction for the user to know what he/she is going to test and what is expected.
>> b) Added Dialog with textarea to enter the reason for the testcase failure. This will help the user to understanding the reason why the test was failed while analyzing the results. 
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed review comments

I have a suggestion which may make the test semi-automatic or at least help the tester to verify.

If the area with the rendered text can be magnified, starting from the first line of text and so on, it would help verify that the text is rendered as expected.

The black text can be verified automatically. The gray and LCD-subpixel may also be automated, yet it requires more work to make the detection stable.

This is out of scope for this issue but it could be another issue. What do you think?

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

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

From dmarkov at openjdk.java.net  Fri Feb 11 15:47:11 2022
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Fri, 11 Feb 2022 15:47:11 GMT
Subject: RFR: 8281555: [macos] Get rid of deprecated Style Masks constants
In-Reply-To: 
References: 

Message-ID: 

On Thu, 10 Feb 2022 22:57:41 GMT, Sergey Bylokhov  wrote:

> DId you check that all new constants are work the same way as the old one? For example the doc for the new "[NSWindowStyleMaskUnifiedTitleAndToolbar](https://developer.apple.com/documentation/appkit/nswindowstylemask/nswindowstylemaskunifiedtitleandtoolbar)" "said it has no effect".

I tested it a bit and didn?t notice any changes in the behaviour. The client-libs tests on mach5 are green too.

Actually the replacement of legacy style mask constants is recommended by Apple, see the following section in NSWindow.h file https://github.com/phracker/MacOSX-SDKs/blob/master/MacOSX10.12.sdk/System/Library/Frameworks/AppKit.framework/Versions/C/Headers/NSWindow.h#L958

As for "[NSWindowStyleMaskUnifiedTitleAndToolbar](https://developer.apple.com/documentation/appkit/nswindowstylemask/nswindowstylemaskunifiedtitleandtoolbar)" the full doc statement:
?This constant has no effect, because all windows that include a toolbar use the unified style.? It looks like a feature introduced recently.

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

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

From aivanov at openjdk.java.net  Fri Feb 11 15:50:12 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 11 Feb 2022 15:50:12 GMT
Subject: RFR: 8281535: Create a regression test for JDK-4670051 [v2]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 11 Feb 2022 15:14:51 GMT, Manukumar V S  wrote:

>> Create a regression test for [JDK-4670051](https://bugs.openjdk.java.net/browse/JDK-4670051) which checks whether JSpinner with a SpinnerDateModel exactly spins the field where cursor is there.
>> I have updated the testing details in the comment section of JDK-8281535.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: Updated copyright, formatting changes, changed compareDates(), renamed some variables and methods.

test/jdk/javax/swing/JSpinner/4670051/JSpinnerFieldUnderCursorTest.java line 40:

> 38: import javax.swing.SwingUtilities;
> 39: import javax.swing.UIManager;
> 40: import static javax.swing.UIManager.getInstalledLookAndFeels;

Suggestion:

import javax.swing.UIManager;

import static javax.swing.UIManager.getInstalledLookAndFeels;

There should always be a blank between regular imports and static imports.

test/jdk/javax/swing/JSpinner/4670051/JSpinnerFieldUnderCursorTest.java line 50:

> 48:  * @run main JSpinnerFieldUnderCursorTest
> 49:  */
> 50: public class JSpinnerFieldUnderCursorTest {

Is `DateFieldUnderCursorTest` a more descriptive name name?

test/jdk/javax/swing/JSpinner/4670051/JSpinnerFieldUnderCursorTest.java line 170:

> 168:         return (expected.get(Calendar.DATE) == actual.get(Calendar.DATE)) &&
> 169:                 (expected.get(Calendar.MONTH) == actual.get(Calendar.MONTH)) &&
> 170:                 (expected.get(Calendar.YEAR) == actual.get(Calendar.YEAR));

Suggestion:

        return (expected.get(Calendar.DATE) == actual.get(Calendar.DATE))
               && (expected.get(Calendar.MONTH) == actual.get(Calendar.MONTH))
               && (expected.get(Calendar.YEAR) == actual.get(Calendar.YEAR));

Otherwise, this looks inconsistently to other places where you put the operator on the wrapped line.

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

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

From mvs at openjdk.java.net  Fri Feb 11 16:53:53 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Fri, 11 Feb 2022 16:53:53 GMT
Subject: RFR: 8281535: Create a regression test for JDK-4670051 [v3]
In-Reply-To: 
References: 
Message-ID: 

> Create a regression test for [JDK-4670051](https://bugs.openjdk.java.net/browse/JDK-4670051) which checks whether JSpinner with a SpinnerDateModel exactly spins the field where cursor is there.
> I have updated the testing details in the comment section of JDK-8281535.

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

  Review comments fixed: Renamed file, formatting changes.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7404/files
  - new: https://git.openjdk.java.net/jdk/pull/7404/files/887f3158..1d446b11

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

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

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

From aivanov at openjdk.java.net  Fri Feb 11 17:36:20 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 11 Feb 2022 17:36:20 GMT
Subject: RFR: 8281535: Create a regression test for JDK-4670051 [v3]
In-Reply-To: 
References: 

Message-ID: <41PNrbjl10H3tGg8CXvDdfkS34P6w2RDw5JZooGhNoY=.ae5b8b32-30db-46e3-937e-b5c1e428f0c3@github.com>

On Fri, 11 Feb 2022 16:53:53 GMT, Manukumar V S  wrote:

>> Create a regression test for [JDK-4670051](https://bugs.openjdk.java.net/browse/JDK-4670051) which checks whether JSpinner with a SpinnerDateModel exactly spins the field where cursor is there.
>> I have updated the testing details in the comment section of JDK-8281535.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: Renamed file, formatting changes.

Marked as reviewed by aivanov (Reviewer).

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

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

From mvs at openjdk.java.net  Fri Feb 11 17:44:16 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Fri, 11 Feb 2022 17:44:16 GMT
Subject: Integrated: 8281535: Create a regression test for JDK-4670051
In-Reply-To: 
References: 
Message-ID: 

On Wed, 9 Feb 2022 14:58:10 GMT, Manukumar V S  wrote:

> Create a regression test for [JDK-4670051](https://bugs.openjdk.java.net/browse/JDK-4670051) which checks whether JSpinner with a SpinnerDateModel exactly spins the field where cursor is there.
> I have updated the testing details in the comment section of JDK-8281535.

This pull request has now been integrated.

Changeset: 0786ddb4
Author:    Manukumar V S 
Committer: Alexey Ivanov 
URL:       https://git.openjdk.java.net/jdk/commit/0786ddb4712296c90df2c9e97c76c203a4de4612
Stats:     282 lines in 1 file changed: 282 ins; 0 del; 0 mod

8281535: Create a regression test for JDK-4670051

Reviewed-by: aivanov

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

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

From smandalika at openjdk.java.net  Fri Feb 11 17:50:33 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Fri, 11 Feb 2022 17:50:33 GMT
Subject: RFR: 8281569: Create tests for Frame.setMinimumSize() method
Message-ID: 

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.

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

Commit messages:
 - 8281569: Create tests for Frame.setMinimumSize() method
 - 8281569: Create tests for Frame.setMinimumSize() method

Changes: https://git.openjdk.java.net/jdk/pull/7444/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7444&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281569
  Stats: 180 lines in 2 files changed: 180 ins; 0 del; 0 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 duke at openjdk.java.net  Fri Feb 11 18:31:56 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Fri, 11 Feb 2022 18:31:56 GMT
Subject: RFR: JDK-8016524: [macosx] Bottom line is not visible for
 JTableHeader [v7]
In-Reply-To: 
References: 
Message-ID: <0QOAo2SFeqRgFF9YJQhlYwjvXsJsI48xGrf69E3bJVI=.85d81390-caa8-4721-a737-063fbe4f772d@github.com>

> Previously, the JTableHeader Bottom line wasn't visible on MacOS LAF (Aqua). With the fix the bottom line (light grey) is visible. 
> 
> Changes were made to AquaTableHeaderBorder.paintBorder method and the height of the component+border was adjusted in paint method.
> 
> A new test case (JTHeaderBorderTest.java) was added to test the fix as there was no corresponding test case present for this issue previously. The test checks if the border is visible by checking the color at the border location with the background color of the table and table-header, if both are different test case passes and it fails if the pixel color at border location matches either the table-header or table background color.

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

  Revised test case - changed string to int comparison, expanded imports

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7219/files
  - new: https://git.openjdk.java.net/jdk/pull/7219/files/52374b86..9d1bc7aa

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

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

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

From duke at openjdk.java.net  Fri Feb 11 18:56:11 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Fri, 11 Feb 2022 18:56:11 GMT
Subject: RFR: JDK-8016524: [macosx] Bottom line is not visible for
 JTableHeader [v6]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 11 Feb 2022 07:30:28 GMT, Prasanta Sadhukhan  wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed test case to use BufferedImage to prevent retina-pixel scaling issues
>
> test/jdk/javax/swing/JTableHeader/8016524/JTHeaderBorderTest.java line 90:
> 
>> 88:                 String headerColor = Integer.toHexString(table.getTableHeader().getBackground().getRGB());
>> 89:                 String pixelColor = tableColor;
>> 90:                 boolean isBottomLineVisible = false;
> 
> To nitpick, I will much rather use Color instead of converting to String as we are trying to check and compare for Color but it's not a dealbreaker.

@prsadhuk  BufferedImage's getRGB() method returns a int value and does not have equivalent method that returns a Color object (at specified coordinates), I was able to change string comparisons to int. Please let me know if this should be okay?

> test/jdk/javax/swing/JTableHeader/8016524/JTHeaderBorderTest.java line 93:
> 
>> 91: 
>> 92:                 // scan table header region to check if bottom border of JTableHeader is visible
>> 93:                 for (int y = Y_OFFSET; y <= Y_OFFSET+25; y++) {
> 
> Can't we use X_OFFSET for hardcoded 25 here?

The X_OFFSET is different from the 25 specified in the loop, this specifies the vertical scan range. To avoid confusion I have changed it as Y_OFFSET_START and Y_OFFSET_END.

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

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

From duke at openjdk.java.net  Fri Feb 11 19:27:39 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Fri, 11 Feb 2022 19:27:39 GMT
Subject: RFR: 8012675: Updated Parser class doc to include info regarding lack
 of support for html script tags.
Message-ID: 

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.

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

Commit messages:
 - Updated Parser class doc to include info regarding lack of support for html script tags.

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

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

From serb at openjdk.java.net  Fri Feb 11 21:12:03 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 11 Feb 2022 21:12:03 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Feb 2022 19:20:16 GMT, DamonGuy  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.

Don't we need to have the bug somewhere that this tag is not supported? Is it the only tag that is unsupported?

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

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

From serb at openjdk.java.net  Fri Feb 11 21:14:02 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 11 Feb 2022 21:14:02 GMT
Subject: RFR: 8281033: Improve ImageCheckboxTest to test all available LaF
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Feb 2022 10:47:41 GMT, Alexander Zuev  wrote:

> Test modified to perform test on all available LaF's
> During test development bug similar to JDK-8216358 was found in Nimbus and GTK+ LaFs
> so exceptions were added and separate bugs were created to track these LaFs.

Marked as reviewed by serb (Reviewer).

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

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

From serb at openjdk.java.net  Fri Feb 11 21:17:10 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 11 Feb 2022 21:17:10 GMT
Subject: RFR: 8281555: [macos] Get rid of deprecated Style Masks constants
In-Reply-To: 
References: 
Message-ID: 

On Wed, 9 Feb 2022 17:50:48 GMT, Dmitry Markov  wrote:

> The Style Masks constants [1], which are utilised by AWT, were deprecated starting from macOS 10.12 Sierra. It is high time to replace them with new constants introduced by NSWindowStyleMask enumeration [2].
> 
> [1] - https://developer.apple.com/documentation/appkit/nspanel/style_masks
> [2] - https://developer.apple.com/documentation/appkit/nswindowstylemask

Marked as reviewed by serb (Reviewer).

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

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

From prr at openjdk.java.net  Fri Feb 11 23:15:06 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 11 Feb 2022 23:15:06 GMT
Subject: RFR: 8275345: RasterFormatException when drawing a tiled image
 made of non-writable rasters [v2]
In-Reply-To: 
References: 

 <1cuXpSh6COBJPM5zkFzZUXqPj_a-KE-7zZOnlk5rRwE=.72f96193-37e6-4fad-8c61-953197d2545c@github.com>

Message-ID: <6pSr7-g5iqKws3PBQB3br1qCq1XZrRlxxWuZMT58VdY=.db052109-00d6-4b84-bc6b-5e697da4ad50@github.com>

On Fri, 11 Feb 2022 10:40:20 GMT, Martin Desruisseaux  wrote:

>> test/jdk/java/awt/image/DrawImage/TiledImage.java line 98:
>> 
>>> 96:  */
>>> 97: final class TiledImage implements RenderedImage {
>>> 98:     /**
>> 
>> Still not right. Now you added the tags I ran under jtreg and it errored out.
>> result: Error. java.lang.IllegalAccessException: class com.sun.javatest.regtest.agent.MainWrapper$MainThread cannot access a member of class TiledImage with modifiers "public static
>> 
>> Basically change "final" to "public" - or at least add public. 
>> 
>> Might be prudent to try this for yourself - and useful for the future.
>> jtreg instructions for building it can be found here : https://openjdk.java.net/jtreg/build.html
>> Very possibly there's someone that provides a pre-built binary. There's none on OpenJDK.
>
> Thanks for the tips and your patience. Actually I tried to run jtreg yesterday before to commit the change, but got the following error (I wanted to try on Java 17 first in order to verify that the test failed):
> 
> 
> jtreg -jdk:$JAVA_HOME test/jdk/java/awt/image/DrawImage/TiledImage.java
> 
> 
> failed to get value for vm.cds.write.archived.java.heap
> java.lang.UnsatisfiedLinkError: 'boolean jdk.test.whitebox.WhiteBox.canWriteJavaHeapArchive()'
> 	at jdk.test.whitebox.WhiteBox.canWriteJavaHeapArchive(Native Method)
> 	at requires.VMProps.vmCDSCanWriteArchivedJavaHeap(VMProps.java:413)
> 	at requires.VMProps$SafeMap.put(VMProps.java:72)
> 	at requires.VMProps.call(VMProps.java:113)
> 	at requires.VMProps.call(VMProps.java:60)
> 	at com.sun.javatest.regtest.agent.GetJDKProperties.run(GetJDKProperties.java:80)
> 	at com.sun.javatest.regtest.agent.GetJDKProperties.main(GetJDKProperties.java:54)
> 
> I'm sure I did something wrong with my configuration?

Alas, I'm purely a user as far as jtreg goes. I've had odd looking errors myself and in those cases the eventual answer was often that I was running the wrong (too old) version of jtreg.
I hunt jtreg down from an internal build archive so I can't point you at what I use (nor provide it) but all the external contributors must have some favoured place to get their copy. I just don't know what it is. the code-tools list might be able to help.

But if you want to expedite this, just make the one change - I already tested it.

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

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

From prr at openjdk.java.net  Fri Feb 11 23:28:43 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 11 Feb 2022 23:28:43 GMT
Subject: RFR: 8269091: javax/sound/sampled/Clip/SetPositionHang.java failed
 with ArrayIndexOutOfBoundsException: Array index out of range: -4 [v2]
In-Reply-To: 
References: 
Message-ID: 

> This test has started failing since we got M1 macs to test on. I don't think we've ever seen this failure elsewhere.
> I don't know what it is about that architecture that makes it more likely but I can see how it can happen when multiple threads are using the same instance. 
> 
>                     if (newFramePosition >= 0) { 
>                         clipBytePosition = newFramePosition * frameSize; 
>                         newFramePosition = -1; 
>                     } 
> 
> newFramePosition is declared volatile which does make it quite possible that after the read and before the use it will have changed.
> 
> The fix just synchronizes this block to prevent it.

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

  8269091: javax/sound/sampled/Clip/SetPositionHang.java failed with ArrayIndexOutOfBoundsException: Array index out of range: -4

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7436/files
  - new: https://git.openjdk.java.net/jdk/pull/7436/files/141be4e7..3700e1db

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

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

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

From prr at openjdk.java.net  Fri Feb 11 23:28:45 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 11 Feb 2022 23:28:45 GMT
Subject: RFR: 8269091: javax/sound/sampled/Clip/SetPositionHang.java failed
 with ArrayIndexOutOfBoundsException: Array index out of range: -4 [v2]
In-Reply-To: <_E4C4Jtr6DF11jbV8eYj1i5c790Ag-mbeavrXGuE918=.efca4380-6b0e-4247-9348-e8e0c5b7274b@github.com>
References: 
 <_E4C4Jtr6DF11jbV8eYj1i5c790Ag-mbeavrXGuE918=.efca4380-6b0e-4247-9348-e8e0c5b7274b@github.com>
Message-ID: 

On Fri, 11 Feb 2022 05:17:17 GMT, Sergey Bylokhov  wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8269091: javax/sound/sampled/Clip/SetPositionHang.java failed with ArrayIndexOutOfBoundsException: Array index out of range: -4
>
> src/java.desktop/share/classes/com/sun/media/sound/DirectAudioDevice.java line 1300:
> 
>> 1298:                 }
>> 1299:                 while (doIO && thread == curThread) {
>> 1300:                     synchronized (this) {
> 
> Maybe instead of synchronization we can read it to the local variable,then use, then reset to -1? This class already has many different locks used for synchronization and this one add another one for "this".

I suppose both should avoid this specific problem. But yes, there's a lot of synchronization in this class.
FIx updated.

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

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

From mickleness at gmail.com  Fri Feb 11 23:51:02 2022
From: mickleness at gmail.com (Jeremy Wood)
Date: Fri, 11 Feb 2022 23:51:02 +0000
Subject: Area#add(Area) Optimization
Message-ID: 

I?m working a lot with the Area class lately. Is there any interest in 
the following optimization?

Area#add(Area) currently resembles:

public void add(Area rhs) {
   curves = new AreaOp.AddOp().calculate(this.curves, rhs.curves);
   invalidateBounds();
}

I propose replacing it with:

public void add(Area rhs) {
   if (isEmpty()) {
     curves = rhs.curves;
   } else if (rhs.isEmpty()) {
     return;
   } else {
     curves = new AreaOp.AddOp().calculate(this.curves, rhs.curves);
   }
   invalidateBounds();
}

If either operand is empty then this is effectively a null op. But the 
current implementation may still take several seconds to return 
depending on the complexity of the non-empty operand.

For example the following two snippets of code may have significantly 
different execution times:

Area sum = new Area();
for(Shape shape : incomingShapes) {
   sum.add(new Area(shape));
}

vs

Area sum = new Area(shapes.get(0));
for(int a = 1; a < incomingShapes.size(); a++) {
   Shape shape = incomingShapes.get(a);
   sum.add(new Area(shape));
}

And similarly we could review the other operations 
(subtract/intersect/exclusiveOr/transform) for obvious potential null 
ops.

If I understand openjdk rules correctly: I'm not authorized to submit an 
openJDK ticket. Does this interest anyone else on this list enough to 
submit this as an openJDK ticket? (I'm happy to work on it if I can 
help.)

Regards,
  - Jeremy

From alitvinov at openjdk.java.net  Sat Feb 12 00:56:09 2022
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Sat, 12 Feb 2022 00:56:09 GMT
Subject: RFR: 8277922: Unable to click JCheckBox in JTable through Java
 Access Bridge
In-Reply-To: 
References: <68JPxsadS5K_WkQgEkMdD_qCt1DWBpBVHV23b0oQKGU=.0b4e520a-205d-4cf1-b506-dd48616ebece@github.com>

Message-ID: 

On Thu, 10 Feb 2022 18:20:40 GMT, Sergey Bylokhov  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
>
> 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".

> src/java.desktop/share/classes/javax/swing/JTable.java line 5508:
> 
>> 5506:                     (table != null) && table.isEnabled() &&
>> 5507:                     table.isCellEditable(row, column)) {
>> 5508:                     table.setValueAt(Boolean.valueOf(newSelectedState),
> 
> Where this code is triggered if the user click on the checkbox by the mouse?

Mouse click on JCheckBox is handled differently from execution of "click" accessible action on this JCheckBox, because behind mouse click different AWT mouse events stand which are processed properly, while "doAccessibleAction()" does not involve these mouse events and all their code. So if you are worrying about focus or selection as a result of "doAccessibleAction()", then 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 suppose that this code should be invoked only by calling "doAccessibleAction(int)" on object of "AccessibleAction" interface either through Java Accessibility API like it is in this regression test or through Java Access Bridge API from the native assistive software application like it is in the manual test attached to the bug and in that case it is called from the method "private boolean doAccessibleActions(final AccessibleContext ac, final String name)" in the file "src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java".

> test/jdk/javax/accessibility/JTable/JCheckBoxInJTableCannotBeClickedTest.java line 92:
> 
>> 90: 
>> 91:     private void createGUI() {
>> 92:         if (!(UIManager.getLookAndFeel() instanceof MetalLookAndFeel)) {
> 
> Why the metal L&F is tested, should at least any default L&F works(like Aqua)?

Hi Sergey! Thank you for review of this fix, I am glad to hear from you. Metal L&F is not related anyhow to the bug or the tested scenarios, it is not required for the test at all. I used Metal L&F just to make sure that UI of the test will be shown in generic way on all OS families on which it will be run, what will decrease possibility that it may fail because of other unrelated bug connected to some not very well supported L&F. Yes, of course, the test should work with any other L&F including Aqua, but I would like to emphasize that this bug is about MS Windows OS and requires assistive software native application to call "AccessibleAction" of "JTable" cell through Java Access Bridge API. If you insist I can remove this code which sets Metal L&F from the test.

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

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

From philip.race at oracle.com  Sat Feb 12 02:15:26 2022
From: philip.race at oracle.com (Philip Race)
Date: Fri, 11 Feb 2022 18:15:26 -0800
Subject: Integrated: 8047749: javadoc for getPathBounds() in TreeUI and
 BasicTreeUI is incorrect
In-Reply-To: 
References: 

Message-ID: 

This should have had a CSR.
Valid -> Invalid is fixing a typo for sure but a very significant one in 
the context.

Please retroactively submit the CSR.

-phil.

On 2/11/22 1:43 AM, Prasanta Sadhukhan wrote:
> On Thu, 10 Feb 2022 08:11:04 GMT, Prasanta Sadhukhan  wrote:
>
>> The javadoc descriptions for javax.swing.plaf.TreeUI.getPathBounds() and javax.swing.plaf.basic.BasicTreeUI.getPathBounds() have stated it returns null if any component in path is currently "valid", which is wrong.
>> The getPathBounds() in BasicTreeUI returns null if tree or treeState is null.
>> Fixed the javadoc.
> This pull request has now been integrated.
>
> Changeset: 4d640760
> Author:    Prasanta Sadhukhan 
> URL:       https://git.openjdk.java.net/jdk/commit/4d64076058a4ec5df101b06572195ed5fdee6f64
> Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod
>
> 8047749: javadoc for getPathBounds() in TreeUI and BasicTreeUI is incorrect
>
> Reviewed-by: aivanov
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/7421

From duke at openjdk.java.net  Sat Feb 12 03:07:09 2022
From: duke at openjdk.java.net (duke)
Date: Sat, 12 Feb 2022 03:07:09 GMT
Subject: Withdrawn: JDK-8275923: Override the LPR path using a system property
In-Reply-To: 
References: 
Message-ID: 

On Wed, 20 Oct 2021 20:38:17 GMT, Rolf van Kleef  wrote:

> On some select systems, the LPR binary may be placed elsewhere (for example at `/app/bin/lpr`). For that reason, we need to be able to override this value. This proposal also allows overriding the LP's path, as it could experience similar difficulties.

This pull request has been closed without being integrated.

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

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

From kizune at openjdk.java.net  Sat Feb 12 09:30:05 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sat, 12 Feb 2022 09:30:05 GMT
Subject: Integrated: 8281033: Improve ImageCheckboxTest to test all available
 LaF
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Feb 2022 10:47:41 GMT, Alexander Zuev  wrote:

> Test modified to perform test on all available LaF's
> During test development bug similar to JDK-8216358 was found in Nimbus and GTK+ LaFs
> so exceptions were added and separate bugs were created to track these LaFs.

This pull request has now been integrated.

Changeset: aa918a6e
Author:    Alexander Zuev 
URL:       https://git.openjdk.java.net/jdk/commit/aa918a6ec4cd1356efd481c6f6fa94959f94f7b3
Stats:     49 lines in 1 file changed: 38 ins; 1 del; 10 mod

8281033: Improve ImageCheckboxTest to test all available LaF

Reviewed-by: serb

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

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

From serb at openjdk.java.net  Sat Feb 12 22:13:06 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 12 Feb 2022 22:13:06 GMT
Subject: Integrated: 8274939: Incorrect size of the pixel storage is used by
 the robot on macOS
In-Reply-To: 
References: 
Message-ID: 

On Fri, 8 Oct 2021 10:23:13 GMT, Sergey Bylokhov  wrote:

> In JDK 9 the native code for the robot class was reworked to get an access to the HiDPI quality screenshots. So we allocate the data storage for the HiDPI quality and then request the best quality from the macOS.
> 
> It works fine if the user request the screenshot of some area, since we properly scale this area. Unfortunately it does not work well if the user request only one pixel, in this case we allocate the array of one element and does not multiply the size by the scale, so if the system scale is 2 then the macOS returns the 2x2 pixels, which does not fit properly to the array of one element. This can be checked by the Xcheck:jni option which produce fatal error in this case.
> 
> Solution is to allocate the storage of the proper size 1 * scale * 1 * scale

This pull request has now been integrated.

Changeset: eff5dafb
Author:    Sergey Bylokhov 
URL:       https://git.openjdk.java.net/jdk/commit/eff5dafba9f72bd0612357712ffa472ce1c9166a
Stats:     12 lines in 3 files changed: 7 ins; 0 del; 5 mod

8274939: Incorrect size of the pixel storage is used by the robot on macOS

Reviewed-by: aivanov, prr

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

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

From philip.race at oracle.com  Sat Feb 12 22:26:37 2022
From: philip.race at oracle.com (Philip Race)
Date: Sat, 12 Feb 2022 14:26:37 -0800
Subject: Area#add(Area) Optimization
In-Reply-To: 
References: 
Message-ID: <6a791257-0ebb-e6be-fb8d-4891b6b87921@oracle.com>

I suppose this could be added but it is something an application also 
can easily do for itself.

 > ??? curves = rhs.curves;

The straight reference, rather than a copy surprised me, but I suppose 
(I am not familiar
with the working of the Area class) that all mutations must create a new 
Vector ...

-phil.

On 2/11/22 3:51 PM, Jeremy Wood wrote:
> I?m working a lot with the Area class lately. Is there any interest in 
> the following optimization?
>
> Area#add(Area) currently resembles:
>
> public void add(Area rhs) {
> ? curves = new AreaOp.AddOp().calculate(this.curves, rhs.curves);
> ? invalidateBounds();
> }
>
> I propose replacing it with:
>
> public void add(Area rhs) {
> ? if (isEmpty()) {
> ??? curves = rhs.curves;
> ? } else if (rhs.isEmpty()) {
> ??? return;
> ? } else {
> ??? curves = new AreaOp.AddOp().calculate(this.curves, rhs.curves);
> ? }
> ? invalidateBounds();
> }
>
> If either operand is empty then this is effectively a null op. But the 
> current implementation may still take several seconds to return 
> depending on the complexity of the non-empty operand.
>
> For example the following two snippets of code may have significantly 
> different execution times:
>
> Area sum = new Area();
> for(Shape shape : incomingShapes) {
> ? sum.add(new Area(shape));
> }
>
> vs
>
> Area sum = new Area(shapes.get(0));
> for(int a = 1; a < incomingShapes.size(); a++) {
> ? Shape shape = incomingShapes.get(a);
> ? sum.add(new Area(shape));
> }
>
> And similarly we could review the other operations 
> (subtract/intersect/exclusiveOr/transform) for obvious potential null 
> ops.
>
> If I understand openjdk rules correctly: I'm not authorized to submit 
> an openJDK ticket. Does this interest anyone else on this list enough 
> to submit this as an openJDK ticket? (I'm happy to work on it if I can 
> help.)
>
> Regards,
> ?- Jeremy

From psadhukhan at openjdk.java.net  Mon Feb 14 04:40:09 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 14 Feb 2022 04:40:09 GMT
Subject: RFR: 8047749: javadoc for getPathBounds() in TreeUI and
 BasicTreeUI is incorrect
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Feb 2022 08:11:04 GMT, Prasanta Sadhukhan  wrote:

> The javadoc descriptions for javax.swing.plaf.TreeUI.getPathBounds() and javax.swing.plaf.basic.BasicTreeUI.getPathBounds() have stated it returns null if any component in path is currently "valid", which is wrong.
> The getPathBounds() in BasicTreeUI returns null if tree or treeState is null. 
> Fixed the javadoc.

> _Mailing list message from [Philip Race](mailto:philip.race at oracle.com) on [client-libs-dev](mailto:client-libs-dev at mail.openjdk.java.net):_
> 
> This should have had a CSR. Valid -> Invalid is fixing a typo for sure but a very significant one in the context.
> 
> Please retroactively submit the CSR.
> 
> -phil.
> 
> On 2/11/22 1:43 AM, Prasanta Sadhukhan wrote:

CSR raised [JDK-8281692](https://bugs.openjdk.java.net/browse/JDK-8281692)

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

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

From psadhukhan at openjdk.java.net  Mon Feb 14 04:51:12 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 14 Feb 2022 04:51:12 GMT
Subject: RFR: JDK-8016524: [macosx] Bottom line is not visible for
 JTableHeader [v7]
In-Reply-To: <0QOAo2SFeqRgFF9YJQhlYwjvXsJsI48xGrf69E3bJVI=.85d81390-caa8-4721-a737-063fbe4f772d@github.com>
References: 
 <0QOAo2SFeqRgFF9YJQhlYwjvXsJsI48xGrf69E3bJVI=.85d81390-caa8-4721-a737-063fbe4f772d@github.com>
Message-ID: 

On Fri, 11 Feb 2022 18:31:56 GMT, Harshitha Onkar  wrote:

>> Previously, the JTableHeader Bottom line wasn't visible on MacOS LAF (Aqua). With the fix the bottom line (light grey) is visible. 
>> 
>> Changes were made to AquaTableHeaderBorder.paintBorder method and the height of the component+border was adjusted in paint method.
>> 
>> A new test case (JTHeaderBorderTest.java) was added to test the fix as there was no corresponding test case present for this issue previously. The test checks if the border is visible by checking the color at the border location with the background color of the table and table-header, if both are different test case passes and it fails if the pixel color at border location matches either the table-header or table background color.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revised test case - changed string to int comparison, expanded imports

Marked as reviewed by psadhukhan (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Mon Feb 14 04:51:12 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 14 Feb 2022 04:51:12 GMT
Subject: RFR: JDK-8016524: [macosx] Bottom line is not visible for
 JTableHeader [v6]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 11 Feb 2022 18:53:11 GMT, Harshitha Onkar  wrote:

>> test/jdk/javax/swing/JTableHeader/8016524/JTHeaderBorderTest.java line 90:
>> 
>>> 88:                 String headerColor = Integer.toHexString(table.getTableHeader().getBackground().getRGB());
>>> 89:                 String pixelColor = tableColor;
>>> 90:                 boolean isBottomLineVisible = false;
>> 
>> To nitpick, I will much rather use Color instead of converting to String as we are trying to check and compare for Color but it's not a dealbreaker.
>
> @prsadhuk  BufferedImage's getRGB() method returns a int value and does not have equivalent method that returns a Color object (at specified coordinates), I was able to change string comparisons to int. Please let me know if this should be okay?

You could have used getBackground() itself to get a Color object but amnot finicky about it, its upto you.

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

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

From psadhukhan at openjdk.java.net  Mon Feb 14 06:56:10 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 14 Feb 2022 06:56:10 GMT
Subject: RFR: 8236907: JTable added to nested panels does not paint last
 visible row
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Feb 2022 09:49:41 GMT, Tejesh R  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.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java line 1903:

> 1901:     private void paintDropLines(Graphics g) {
> 1902:         JTable.DropLocation loc = table.getDropLocation();
> 1903:         if (loc == null) {

Deleting this seems to have regressed JDK-8081491 where 1 extra row is printed per page..
jdk/test/java/awt/print/PageFormat/ImageableAreaTest.java is supposed to print 35 rows which was visible in console but it prints 36 rows..

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

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

From psadhukhan at openjdk.java.net  Mon Feb 14 07:37:47 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 14 Feb 2022 07:37:47 GMT
Subject: RFR: 8277369: Strange behavior of JMenuBar with RIGHT_TO_LEFT
 orientation, arrow keys behaves opposite traversing through keyboard [v3]
In-Reply-To: 
References: 
Message-ID: 

> After applying setComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) to the JMenuBar the arrow keys started to behave the opposite of what expected. Right arrow goes left and Left arrow goes right when trying to traverse through keyboard.
> 
> Fixed to reverse the direction traversal for RTL orientation.

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

  fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7396/files
  - new: https://git.openjdk.java.net/jdk/pull/7396/files/19b72d40..5ffb721d

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

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

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

From duke at openjdk.java.net  Mon Feb 14 09:40:49 2022
From: duke at openjdk.java.net (Martin Desruisseaux)
Date: Mon, 14 Feb 2022 09:40:49 GMT
Subject: RFR: 8275345: RasterFormatException when drawing a tiled image
 made of non-writable rasters [v3]
In-Reply-To: 
References: 
Message-ID: 

> This commit fixes a `RasterFormatException` thrown when `Graphics2D.drawRenderedImage(?)` is invoked with an image containing tiles that are instances of `Raster` but not `WritableRaster`.
> 
> https://bugs.openjdk.java.net/browse/JDK-8275345

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

  Make the test class public for allowing execution by jtreg.
  Fix a compiler warning about raw type.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7337/files
  - new: https://git.openjdk.java.net/jdk/pull/7337/files/fea2f9c0..8b4e6f57

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

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

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

From duke at openjdk.java.net  Mon Feb 14 09:56:11 2022
From: duke at openjdk.java.net (Martin Desruisseaux)
Date: Mon, 14 Feb 2022 09:56:11 GMT
Subject: RFR: 8275345: RasterFormatException when drawing a tiled image
 made of non-writable rasters [v3]
In-Reply-To: 
References: 

Message-ID: 

On Mon, 14 Feb 2022 09:40:49 GMT, Martin Desruisseaux  wrote:

>> This commit fixes a `RasterFormatException` thrown when `Graphics2D.drawRenderedImage(?)` is invoked with an image containing tiles that are instances of `Raster` but not `WritableRaster`.
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8275345
>
> Martin Desruisseaux has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make the test class public for allowing execution by jtreg.
>   Fix a compiler warning about raw type.

Change applied. Should I squash and/or rebase commits?

Regarding jtreg, I cloned the [master](https://github.com/openjdk/jtreg) (maybe I should have used a tag instead). But the [documentation](https://openjdk.java.net/jtreg/build.html) seems slightly outdated (script names changed). The `README.md` file on GitHub seems more up-to-date.

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

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

From djelinski at openjdk.java.net  Mon Feb 14 13:09:10 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 14 Feb 2022 13:09:10 GMT
Subject: RFR: 8281523: Accessibility: Conversion from string literal loses
 const qualifier
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Feb 2022 11:41:16 GMT, Daniel Jeli?ski  wrote:

> This patch fixes jdk.accessibility compilation under VisualStudio 2019 with /Zc:strictStrings enabled.
> 
> Strict string handling is already enabled in GCC and Clang. With some effort we should be able to enable it in MSVC as well.

Hi, can I get a review for this change? 
This is similar to #7379, but in a different subcomponent (Accessibility vs. AWT). I added `const` qualifier to a bunch of function parameters.

Additionally I removed one (unused) function and one (mismatching) function declaration; build passed, tier1 and tier2 green. Verified with both vs2019 and vs2017.

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

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

From mvs at openjdk.java.net  Mon Feb 14 14:14:32 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Mon, 14 Feb 2022 14:14:32 GMT
Subject: RFR: 8281738: Create a regression test for checking the 'Space' key
 activation of focused Button
Message-ID: 

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

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

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

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

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

From mvs at openjdk.java.net  Mon Feb 14 14:14:33 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Mon, 14 Feb 2022 14:14:33 GMT
Subject: RFR: 8281738: Create a regression test for checking the 'Space'
 key activation of focused Button
In-Reply-To: 
References: 
Message-ID: 

On Mon, 14 Feb 2022 14:04:33 GMT, Manukumar V S  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.

@aivanov-jdk Can you please review this.

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

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

From smandalika at openjdk.java.net  Mon Feb 14 15:57:09 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Mon, 14 Feb 2022 15:57:09 GMT
Subject: RFR: 8281569: Create tests for Frame.setMinimumSize() method
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Feb 2022 17:28:09 GMT, Srinivas Mandalika  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.

Can someone review this PR?

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

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

From achung at openjdk.java.net  Mon Feb 14 17:13:33 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 14 Feb 2022 17:13:33 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150
 scale factor
Message-ID: 

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

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

Commit messages:
 - trailing whitespace, add extra newline at eof
 - changed carriage return
 - changed carriage return
 - 8279614: The left line of the TitledBorder is not painted on 150 scale factor
 - finished test
 - initial commit

Changes: https://git.openjdk.java.net/jdk/pull/7449/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279614
  Stats: 102 lines in 2 files changed: 98 ins; 0 del; 4 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 serb at openjdk.java.net  Mon Feb 14 17:13:37 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 14 Feb 2022 17:13:37 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Feb 2022 23:44:22 GMT, Alisen Chung  wrote:

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

src/java.desktop/share/classes/javax/swing/border/TitledBorder.java line 354:

> 352:                         Graphics2D g2d = (Graphics2D) g2;
> 353:                         Path2D path = new Path2D.Float();
> 354:                         path.append(new Rectangle2D.Float((float) borderX, borderY, borderW, labelY - borderY), false);

Why the current coordinates do not work, is it because we calculate them in the wrong way or probably the insets are wrong?

test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 1:

> 1: import java.awt.BorderLayout;

To prevent all this jcheck issue you can install the jcheck hook locally.

test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 51:

> 49:       saveImage(buff, "test.png");
> 50:       throw new RuntimeException("Border was clipped or overdrawn.");
> 51:     }

Can we draw directly to the buffered image using the scaled graphics to reproduce the bug?

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

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

From achung at openjdk.java.net  Mon Feb 14 17:13:38 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 14 Feb 2022 17:13:38 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor
In-Reply-To: 
References: 

Message-ID: 

On Sat, 12 Feb 2022 01:10:49 GMT, Sergey Bylokhov  wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> src/java.desktop/share/classes/javax/swing/border/TitledBorder.java line 354:
> 
>> 352:                         Graphics2D g2d = (Graphics2D) g2;
>> 353:                         Path2D path = new Path2D.Float();
>> 354:                         path.append(new Rectangle2D.Float((float) borderX, borderY, borderW, labelY - borderY), false);
> 
> Why the current coordinates do not work, is it because we calculate them in the wrong way or probably the insets are wrong?

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

> test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 51:
> 
>> 49:       saveImage(buff, "test.png");
>> 50:       throw new RuntimeException("Border was clipped or overdrawn.");
>> 51:     }
> 
> Can we draw directly to the buffered image using the scaled graphics to reproduce the bug?

Yea, the test fails before the fix, and when inspecting the saved image it looks identical to the actual frame.

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

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

From duke at openjdk.java.net  Mon Feb 14 18:13:12 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Mon, 14 Feb 2022 18:13:12 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Feb 2022 19:20:16 GMT, DamonGuy  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.

The script tag is a special case and has its own check in the 'parseTag' function. It specifically looks for the "script" element and logs an error if this is reached. I assume this code has existed since at least 2017 when the 'parseTag' function was brought up as the cause on the JBS report, but the issue has existed since 2013.

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

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

From serb at openjdk.java.net  Mon Feb 14 18:27:11 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 14 Feb 2022 18:27:11 GMT
Subject: RFR: 8280861: Robot color picker broken on Linux with scaling
 above 100% [v3]
In-Reply-To: 
References: <7WQIrQr1kH9q7zlM2wZcrF7r-LX1uiQwYjN1TMovRds=.17e06f8b-1d83-42c4-8d38-6ccaeaacdc9e@github.com>

Message-ID: 

On Fri, 11 Feb 2022 08:09:06 GMT, Maxim Kartashev  wrote:

>> src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c line 2876:
>> 
>>> 2874: static gboolean gtk3_get_drawable_data(JNIEnv *env, jintArray pixelArray,
>>> 2875:      int x, jint y, jint width, jint height, jint jwidth, int dx, int dy,
>>> 2876:                                                                    jint scale) {
>> 
>> Is this scale parameter is simply ignored? If the passed parameters are always in the device space and the array is allocated properly then we should not care about this scale(especially in case of gtk2)?
>
>> Is this scale parameter is simply ignored?
> 
> Looks like it. I can only find one call site of `get_drawable_data()` (in [Java_sun_awt_X11_XRobotPeer_getRGBPixelsImpl()](https://github.com/openjdk/jdk/blob/8441d51e71e143250b44eea74114a624cf00cc3e/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c#L336)) and the `scale` parameter is always 1. I think I can drop it from the interface if you prefer.

Yes please, this "scale" just make the code complicated w/o reason.

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

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

From prr at openjdk.java.net  Mon Feb 14 18:45:09 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 14 Feb 2022 18:45:09 GMT
Subject: RFR: 8275345: RasterFormatException when drawing a tiled image
 made of non-writable rasters [v3]
In-Reply-To: 
References: 

Message-ID: 

On Mon, 14 Feb 2022 09:40:49 GMT, Martin Desruisseaux  wrote:

>> This commit fixes a `RasterFormatException` thrown when `Graphics2D.drawRenderedImage(?)` is invoked with an image containing tiles that are instances of `Raster` but not `WritableRaster`.
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8275345
>
> Martin Desruisseaux has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make the test class public for allowing execution by jtreg.
>   Fix a compiler warning about raw type.

Marked as reviewed by prr (Reviewer).

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

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

From duke at openjdk.java.net  Mon Feb 14 18:56:14 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Mon, 14 Feb 2022 18:56:14 GMT
Subject: Withdrawn: JDK-6998249: Wrong behavior/Javadoc of
 JTable.tableChanged(TableModelEvent e)
In-Reply-To: 
References: 
Message-ID: <8b9h0Tm4R2TpJIwR5KZ2oTmyKI6wZ8JwN63Ijn4UlwY=.adc1b48c-6c74-4b32-a199-61147a333700@github.com>

On Thu, 27 Jan 2022 22:11:27 GMT, Harshitha Onkar  wrote:

> Updated JTable's tableChanged() method docs to explicitly mention the coordinate system of the rows and columns.

This pull request has been closed without being integrated.

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

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

From prr at openjdk.java.net  Mon Feb 14 20:11:19 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 14 Feb 2022 20:11:19 GMT
Subject: RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese
 characters were garbled [v4]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 6 Jan 2022 02:49:17 GMT, Toshio Nakamura  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 ten additional commits since the last revision:
> 
>  - 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
>  - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled

Marked as reviewed by prr (Reviewer).

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

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

From prr at openjdk.java.net  Mon Feb 14 20:16:13 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 14 Feb 2022 20:16:13 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: 
References: 

Message-ID: <1xgNYge02zcX-kfQ343p2YT4v2MIbym5SHL_fDnqMPI=.ab03d946-c8ec-4a2f-871a-8d58e6a30f43@github.com>

On Thu, 28 Oct 2021 08:27:44 GMT, Masanori Yano  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

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 ?

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

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

From prr at openjdk.java.net  Mon Feb 14 20:46:11 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 14 Feb 2022 20:46:11 GMT
Subject: RFR: 8281523: Accessibility: Conversion from string literal loses
 const qualifier
In-Reply-To: 
References: 
Message-ID: <6VxLBE8N65L47E6Ydt7o5AQAciKaskdxm7o5eiaifCA=.bf546555-23fc-499c-a5ad-11b707ca4458@github.com>

On Tue, 8 Feb 2022 11:41:16 GMT, Daniel Jeli?ski  wrote:

> This patch fixes jdk.accessibility compilation under VisualStudio 2019 with /Zc:strictStrings enabled.
> 
> Strict string handling is already enabled in GCC and Clang. With some effort we should be able to enable it in MSVC as well.

src/jdk.accessibility/windows/native/common/AccessBridgeDebug.cpp line 149:

> 147:     /**
> 148:      * Send Java debugging info to the appropriate place
> 149:      */

Deleting this function - without comment !  - seems to be somewhat out of scope here.

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

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

From prr at openjdk.java.net  Mon Feb 14 20:59:08 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 14 Feb 2022 20:59:08 GMT
Subject: RFR: 8277369: Strange behavior of JMenuBar with RIGHT_TO_LEFT
 orientation, arrow keys behaves opposite traversing through keyboard [v3]
In-Reply-To: 
References: 

Message-ID: 

On Mon, 14 Feb 2022 07:37:47 GMT, Prasanta Sadhukhan  wrote:

>> After applying setComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) to the JMenuBar the arrow keys started to behave the opposite of what expected. Right arrow goes left and Left arrow goes right when trying to traverse through keyboard.
>> 
>> Fixed to reverse the direction traversal for RTL orientation.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix

Seems to me right should move right and left move left, so OK by me but
I'd like to make sure this is seen by @naotoj too.

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

Marked as reviewed by prr (Reviewer).

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

From naoto at openjdk.java.net  Mon Feb 14 21:11:12 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 14 Feb 2022 21:11:12 GMT
Subject: RFR: 8277369: Strange behavior of JMenuBar with RIGHT_TO_LEFT
 orientation, arrow keys behaves opposite traversing through keyboard [v3]
In-Reply-To: 
References: 

Message-ID: 

On Mon, 14 Feb 2022 07:37:47 GMT, Prasanta Sadhukhan  wrote:

>> After applying setComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) to the JMenuBar the arrow keys started to behave the opposite of what expected. Right arrow goes left and Left arrow goes right when trying to traverse through keyboard.
>> 
>> Fixed to reverse the direction traversal for RTL orientation.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix

Marked as reviewed by naoto (Reviewer).

Caret should move visually, so VK_RIGHT should move it to the right. Fine by me.

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

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

From aivanov at openjdk.java.net  Mon Feb 14 21:15:11 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 14 Feb 2022 21:15:11 GMT
Subject: RFR: 8275345: RasterFormatException when drawing a tiled image
 made of non-writable rasters [v2]
In-Reply-To: 
References: 

 <1cuXpSh6COBJPM5zkFzZUXqPj_a-KE-7zZOnlk5rRwE=.72f96193-37e6-4fad-8c61-953197d2545c@github.com>

Message-ID: 

On Fri, 11 Feb 2022 10:40:20 GMT, Martin Desruisseaux  wrote:

>> test/jdk/java/awt/image/DrawImage/TiledImage.java line 98:
>> 
>>> 96:  */
>>> 97: final class TiledImage implements RenderedImage {
>>> 98:     /**
>> 
>> Still not right. Now you added the tags I ran under jtreg and it errored out.
>> result: Error. java.lang.IllegalAccessException: class com.sun.javatest.regtest.agent.MainWrapper$MainThread cannot access a member of class TiledImage with modifiers "public static
>> 
>> Basically change "final" to "public" - or at least add public. 
>> 
>> Might be prudent to try this for yourself - and useful for the future.
>> jtreg instructions for building it can be found here : https://openjdk.java.net/jtreg/build.html
>> Very possibly there's someone that provides a pre-built binary. There's none on OpenJDK.
>
> Thanks for the tips and your patience. Actually I tried to run jtreg yesterday before to commit the change, but got the following error (I wanted to try on Java 17 first in order to verify that the test failed):
> 
> 
> jtreg -jdk:$JAVA_HOME test/jdk/java/awt/image/DrawImage/TiledImage.java
> 
> 
> failed to get value for vm.cds.write.archived.java.heap
> java.lang.UnsatisfiedLinkError: 'boolean jdk.test.whitebox.WhiteBox.canWriteJavaHeapArchive()'
> 	at jdk.test.whitebox.WhiteBox.canWriteJavaHeapArchive(Native Method)
> 	at requires.VMProps.vmCDSCanWriteArchivedJavaHeap(VMProps.java:413)
> 	at requires.VMProps$SafeMap.put(VMProps.java:72)
> 	at requires.VMProps.call(VMProps.java:113)
> 	at requires.VMProps.call(VMProps.java:60)
> 	at com.sun.javatest.regtest.agent.GetJDKProperties.run(GetJDKProperties.java:80)
> 	at com.sun.javatest.regtest.agent.GetJDKProperties.main(GetJDKProperties.java:54)
> 
> I'm sure I did something wrong with my configuration?

@desruisseaux You can take the jtreg builds from @shipilev: https://builds.shipilev.net/jtreg/

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

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

From djelinski at openjdk.java.net  Mon Feb 14 21:25:42 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 14 Feb 2022 21:25:42 GMT
Subject: RFR: 8281523: Accessibility: Conversion from string literal loses
 const qualifier [v2]
In-Reply-To: 
References: 
Message-ID: 

> This patch fixes jdk.accessibility compilation under VisualStudio 2019 with /Zc:strictStrings enabled.
> 
> Strict string handling is already enabled in GCC and Clang. With some effort we should be able to enable it in MSVC as well.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Remove dead code"

  This reverts commit 8576f911d5389695fbe3c6462db2c36939ede54f.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7380/files
  - new: https://git.openjdk.java.net/jdk/pull/7380/files/8576f911..fc67bf6e

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

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

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

From djelinski at openjdk.java.net  Mon Feb 14 21:25:44 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 14 Feb 2022 21:25:44 GMT
Subject: RFR: 8281523: Accessibility: Conversion from string literal loses
 const qualifier [v2]
In-Reply-To: <6VxLBE8N65L47E6Ydt7o5AQAciKaskdxm7o5eiaifCA=.bf546555-23fc-499c-a5ad-11b707ca4458@github.com>
References: 
 <6VxLBE8N65L47E6Ydt7o5AQAciKaskdxm7o5eiaifCA=.bf546555-23fc-499c-a5ad-11b707ca4458@github.com>
Message-ID: <2KOhEky7boAehUzdcHITlwp73o6m0Ld3ULjujM416NQ=.aa2646fa-37c1-4088-af01-c98c95bd47f8@github.com>

On Mon, 14 Feb 2022 20:42:48 GMT, Phil Race  wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "Remove dead code"
>>   
>>   This reverts commit 8576f911d5389695fbe3c6462db2c36939ede54f.
>
> src/jdk.accessibility/windows/native/common/AccessBridgeDebug.cpp line 149:
> 
>> 147:     /**
>> 148:      * Send Java debugging info to the appropriate place
>> 149:      */
> 
> Deleting this function - without comment !  - seems to be somewhat out of scope here.

Reverted.

I removed this function because its definition (`PrintJavaDebugString2`) did not match the declaration (`PrintJavaDebugString`), so the function wasn't really usable. I'm fine with leaving it as is, or cleaning up separately.

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

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

From aivanov at openjdk.java.net  Mon Feb 14 21:49:03 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 14 Feb 2022 21:49:03 GMT
Subject: RFR: 8281555: [macos] Get rid of deprecated Style Masks constants
In-Reply-To: 
References: 
Message-ID: 

On Wed, 9 Feb 2022 17:50:48 GMT, Dmitry Markov  wrote:

> The Style Masks constants [1], which are utilised by AWT, were deprecated starting from macOS 10.12 Sierra. It is high time to replace them with new constants introduced by NSWindowStyleMask enumeration [2].
> 
> [1] - https://developer.apple.com/documentation/appkit/nspanel/style_masks
> [2] - https://developer.apple.com/documentation/appkit/nswindowstylemask

Marked as reviewed by aivanov (Reviewer).

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

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

From serb at openjdk.java.net  Mon Feb 14 23:19:09 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 14 Feb 2022 23:19:09 GMT
Subject: RFR: 8269091: javax/sound/sampled/Clip/SetPositionHang.java failed
 with ArrayIndexOutOfBoundsException: Array index out of range: -4 [v2]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 11 Feb 2022 23:28:43 GMT, Phil Race  wrote:

>> This test has started failing since we got M1 macs to test on. I don't think we've ever seen this failure elsewhere.
>> I don't know what it is about that architecture that makes it more likely but I can see how it can happen when multiple threads are using the same instance. 
>> 
>>                     if (newFramePosition >= 0) { 
>>                         clipBytePosition = newFramePosition * frameSize; 
>>                         newFramePosition = -1; 
>>                     } 
>> 
>> newFramePosition is declared volatile which does make it quite possible that after the read and before the use it will have changed.
>> 
>> The fix just synchronizes this block to prevent it.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269091: javax/sound/sampled/Clip/SetPositionHang.java failed with ArrayIndexOutOfBoundsException: Array index out of range: -4

Marked as reviewed by serb (Reviewer).

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

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

From serb at openjdk.java.net  Mon Feb 14 23:20:11 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 14 Feb 2022 23:20:11 GMT
Subject: RFR: 8277369: Strange behavior of JMenuBar with RIGHT_TO_LEFT
 orientation, arrow keys behaves opposite traversing through keyboard [v3]
In-Reply-To: 
References: 

Message-ID: <_sYIaWnrkzAIkblsV-NWZbdp-Q_N0qhWP5f3uzbujNM=.d26881d4-8f19-4bec-878b-116f6c449992@github.com>

On Mon, 14 Feb 2022 07:37:47 GMT, Prasanta Sadhukhan  wrote:

>> After applying setComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) to the JMenuBar the arrow keys started to behave the opposite of what expected. Right arrow goes left and Left arrow goes right when trying to traverse through keyboard.
>> 
>> Fixed to reverse the direction traversal for RTL orientation.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix

Marked as reviewed by serb (Reviewer).

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

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

From serb at openjdk.java.net  Mon Feb 14 23:27:17 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 14 Feb 2022 23:27:17 GMT
Subject: RFR: 8281738: Create a regression test for checking the 'Space'
 key activation of focused Button
In-Reply-To: 
References: 
Message-ID: <8RrJ1npXH7WIbx_4f6CKmNMb-kLGItFWEmyWELDtJyw=.02443c61-7916-4c15-b5dc-80c9527830be@github.com>

On Mon, 14 Feb 2022 14:04:33 GMT, Manukumar V S  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.

test/jdk/javax/swing/JButton/SpaceKeyActivatesButton.java line 67:

> 65:                     createUI();
> 66:                 });
> 67: 

I think you should add robot.waitForIdle() after the frame creation, and also wait until the button will get a focus, since the "requestFocusInWindow" might be ignored.

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

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

From serb at openjdk.java.net  Mon Feb 14 23:29:10 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 14 Feb 2022 23:29:10 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor
In-Reply-To: 
References: 

Message-ID: 

On Mon, 14 Feb 2022 16:45:09 GMT, Alisen Chung  wrote:

>> src/java.desktop/share/classes/javax/swing/border/TitledBorder.java line 354:
>> 
>>> 352:                         Graphics2D g2d = (Graphics2D) g2;
>>> 353:                         Path2D path = new Path2D.Float();
>>> 354:                         path.append(new Rectangle2D.Float((float) borderX, borderY, borderW, labelY - borderY), false);
>> 
>> Why the current coordinates do not work, is it because we calculate them in the wrong way or probably the insets are wrong?
>
> 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.

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

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

From prr at openjdk.java.net  Mon Feb 14 23:35:14 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 14 Feb 2022 23:35:14 GMT
Subject: Integrated: 8269091: javax/sound/sampled/Clip/SetPositionHang.java
 failed with ArrayIndexOutOfBoundsException: Array index out of range: -4
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Feb 2022 23:57:29 GMT, Phil Race  wrote:

> This test has started failing since we got M1 macs to test on. I don't think we've ever seen this failure elsewhere.
> I don't know what it is about that architecture that makes it more likely but I can see how it can happen when multiple threads are using the same instance. 
> 
>                     if (newFramePosition >= 0) { 
>                         clipBytePosition = newFramePosition * frameSize; 
>                         newFramePosition = -1; 
>                     } 
> 
> newFramePosition is declared volatile which does make it quite possible that after the read and before the use it will have changed.
> 
> The fix just synchronizes this block to prevent it.

This pull request has now been integrated.

Changeset: 1a7b70a8
Author:    Phil Race 
URL:       https://git.openjdk.java.net/jdk/commit/1a7b70a8be0a236b98925a8320d25d88a405d595
Stats:     4 lines in 2 files changed: 1 ins; 0 del; 3 mod

8269091: javax/sound/sampled/Clip/SetPositionHang.java failed with ArrayIndexOutOfBoundsException: Array index out of range: -4

Reviewed-by: serb

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

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

From prr at openjdk.java.net  Tue Feb 15 00:53:17 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 15 Feb 2022 00:53:17 GMT
Subject: RFR: 8277369: Strange behavior of JMenuBar with RIGHT_TO_LEFT
 orientation, arrow keys behaves opposite traversing through keyboard [v3]
In-Reply-To: 
References: 

Message-ID: <3cXDnguRwZYVyDSoA4_7aDaqkUckQpgKOe5bETIPNHI=.304a3871-ff70-4b23-9f21-3a4a6033417f@github.com>

On Mon, 14 Feb 2022 07:37:47 GMT, Prasanta Sadhukhan  wrote:

>> After applying setComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) to the JMenuBar the arrow keys started to behave the opposite of what expected. Right arrow goes left and Left arrow goes right when trying to traverse through keyboard.
>> 
>> Fixed to reverse the direction traversal for RTL orientation.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix

BTW I was just looking around and if you do a google search on "rtl arrow key backward" it looks to me as if multiple unrelated open source projects happen to have had the same issue (not SFAICT Java based) and came to the same conclusion.

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

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

From prr at openjdk.java.net  Tue Feb 15 00:48:10 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 15 Feb 2022 00:48:10 GMT
Subject: RFR: 8280861: Robot color picker broken on Linux with scaling
 above 100% [v3]
In-Reply-To: 
References: <7WQIrQr1kH9q7zlM2wZcrF7r-LX1uiQwYjN1TMovRds=.17e06f8b-1d83-42c4-8d38-6ccaeaacdc9e@github.com>

Message-ID: <0yMXWGYN_p2SQbk8Yqer8hKkjNXRnxyzx-v1AsoeuOo=.92a7afdf-6f62-4216-9052-971fc3d896fc@github.com>

On Fri, 11 Feb 2022 14:05:39 GMT, Maxim Kartashev  wrote:

>> The primary API for image capture on modern Linuxes is `gdk_pixbuf_get_from_window()` that expects both coordinates and the size unscaled (i.e. not multiplied by the current desktop scale). At the same time, `gtk3_interface.c:gtk3_get_drawable_data()` gets the coordinates from `Robot` that pre-scales them (multiplying by the scale known to Java, however, not necessarily the current desktop scale). The problem with the size had been partly taken care of in [JDK-8225118](https://bugs.openjdk.java.net/browse/JDK-8225118), but coordinates are still passed to `gdk_pixbuf_get_from_window()` pre-scaled.
>> 
>> The idea of the fix is to capture a possibly larger area that is guaranteed to contain the one that is interesting to the caller and then only copy the interesting pixels to the output image. As a positive side effect, the size of the captured area cannot be less than 1x1 (provided the correct input, of course). This solves the problem of zero size passed to  `(*fp_gdk_pixbuf_get_from_drawable)` when the desktop scale is 3 and we're asked to capture just one pixel. In that case, the previous formula (`width / (float) win_scale + 0.5`) would have yielded `0`. 
>> 
>> A related issue would be that tests written specifically for this general area (`java/awt/Robot`) didn't catch this problem and only somewhat unrelated tests (`javax/swing/...`) were affected.
>> 
>> This one is solved by adding pixel-sized areas to the test image in `HiDPIRobotScreenCaptureTest.java`, which precise colors are then verified to match the expected ones. In addition to that, instead of verifying just the color of the center of a large area, 4 more pixels close to the area's border are checked. This helps to make sure that captured area coordinates aren't way off.
>> 
>> The tests under `javax/swing/...` that originally helped to identify this problem were modified to provide more screen space for painting their components as extreme desktop scaling (300%) on Ubuntu doesn't leave much room due to a humongous title bar.
>> 
>> The fix was tested by running all the modified tests on Ubuntu with desktop scaling set to 100%, 200%, and 300%. The `Robot` tests were also executed on Windows (300% scaling) and MacOS.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright date in TestJProgressBarHighlightColor.java

src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c line 2867:

> 2865: 
> 2866: inline static int scale_down_to_plus_inf(int what, int scale) {
> 2867:     return (int)ceilf(what / (float)scale);

I find the name of this and the companion function confusing.
what is "inf" short for ? I see that and I think plus_infinity.
scaled_ceiling and scaled_floor might be better names based on what I see.

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

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

From prr at openjdk.java.net  Tue Feb 15 00:56:07 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 15 Feb 2022 00:56:07 GMT
Subject: RFR: JDK-8016524: [macosx] Bottom line is not visible for
 JTableHeader [v7]
In-Reply-To: <0QOAo2SFeqRgFF9YJQhlYwjvXsJsI48xGrf69E3bJVI=.85d81390-caa8-4721-a737-063fbe4f772d@github.com>
References: 
 <0QOAo2SFeqRgFF9YJQhlYwjvXsJsI48xGrf69E3bJVI=.85d81390-caa8-4721-a737-063fbe4f772d@github.com>
Message-ID: <8v-9hZAJ6J8j1-kNgHgkCXeFHVr5Nco5A2Z7uc1jjwI=.66ed4047-9f3e-40fc-b9ce-1dca621fa41e@github.com>

On Fri, 11 Feb 2022 18:31:56 GMT, Harshitha Onkar  wrote:

>> Previously, the JTableHeader Bottom line wasn't visible on MacOS LAF (Aqua). With the fix the bottom line (light grey) is visible. 
>> 
>> Changes were made to AquaTableHeaderBorder.paintBorder method and the height of the component+border was adjusted in paint method.
>> 
>> A new test case (JTHeaderBorderTest.java) was added to test the fix as there was no corresponding test case present for this issue previously. The test checks if the border is visible by checking the color at the border location with the background color of the table and table-header, if both are different test case passes and it fails if the pixel color at border location matches either the table-header or table background color.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revised test case - changed string to int comparison, expanded imports

Marked as reviewed by prr (Reviewer).

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

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

From philip.race at oracle.com  Tue Feb 15 01:00:03 2022
From: philip.race at oracle.com (Philip Race)
Date: Mon, 14 Feb 2022 17:00:03 -0800
Subject: RFR: 8047749: javadoc for getPathBounds() in TreeUI and
 BasicTreeUI is incorrect
In-Reply-To: 
References: 

Message-ID: <8a3bda03-3166-da4c-9132-74079422b261@oracle.com>

CSR reviewed.

-phil

On 2/13/22 8:40 PM, Prasanta Sadhukhan wrote:
> On Thu, 10 Feb 2022 08:11:04 GMT, Prasanta Sadhukhan  wrote:
>
>> The javadoc descriptions for javax.swing.plaf.TreeUI.getPathBounds() and javax.swing.plaf.basic.BasicTreeUI.getPathBounds() have stated it returns null if any component in path is currently "valid", which is wrong.
>> The getPathBounds() in BasicTreeUI returns null if tree or treeState is null.
>> Fixed the javadoc.
>> _Mailing list message from [Philip Race](mailto:philip.race at oracle.com) on [client-libs-dev](mailto:client-libs-dev at mail.openjdk.java.net):_
>>
>> This should have had a CSR. Valid -> Invalid is fixing a typo for sure but a very significant one in the context.
>>
>> Please retroactively submit the CSR.
>>
>> -phil.
>>
>> On 2/11/22 1:43 AM, Prasanta Sadhukhan wrote:
> CSR raised [JDK-8281692](https://bugs.openjdk.java.net/browse/JDK-8281692)
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/7421

From tnakamura at openjdk.java.net  Tue Feb 15 01:47:12 2022
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Tue, 15 Feb 2022 01:47:12 GMT
Subject: RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese
 characters were garbled [v4]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 6 Jan 2022 02:49:17 GMT, Toshio Nakamura  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 ten additional commits since the last revision:
> 
>  - 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
>  - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled

Thank you for your approval, Phil.

May I have a second reviewer?

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

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

From mvs at openjdk.java.net  Tue Feb 15 03:12:38 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 15 Feb 2022 03:12:38 GMT
Subject: RFR: 8281745: Create a regression test for JDK-4514331
Message-ID: <7N5tuie0JMzT334ltsuqmHi4XFXG_uWX9HJSGON4bJk=.6f41cb4e-331b-46f5-ab8c-550edb51a99a@github.com>

Create a regression test for JDK-4514331.
It checks whether pressing 'Tab' key always shift focus to next component, even though the current focus is in JTextArea and some text is already selected.

Testing:
I have verified this test with JDK 1.3.1 and JDK 1.4.1 .
The issue is reproducible with JDK 1.3.1 and the test failed there, where the bug was originally reported and the test passed in JDK 1.4.1 where the issue was fixed.
I have tested it in Linux, Mac and Windows platforms and it passed everywhere.

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

Commit messages:
 - Create a regression test for JDK-4514331

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

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

From psadhukhan at openjdk.java.net  Tue Feb 15 05:07:13 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 15 Feb 2022 05:07:13 GMT
Subject: RFR: JDK-8016524: [macosx] Bottom line is not visible for
 JTableHeader [v7]
In-Reply-To: 
References: 
 <5wjVB_FL_GYsLbqr_FEpBsFX3twlM9cXbrN8a3r2rDY=.e42f518a-dc26-49cb-9949-32426cf85fa8@github.com>

 <-R3bNESejIAwk69oyF_PrVq7d6W5V_GSzXT7ipoF8lY=.0bc69e39-c6cc-485f-ab95-98b6b0439078@github.com>

Message-ID: 

On Fri, 11 Feb 2022 01:17:38 GMT, Harshitha Onkar  wrote:

>> I got the 2nd part of the question myself which is because of white gridlines used in AquaLookAndFeel so invisible..
>
> @prsadhuk Ready for review. Changed the test case to paint JFrame to BufferedImage. The test case is marked headful though robot calls are not used, as the JFrame rendering requires it to be headful.

I believe you could raise a awt Robot issue for not getting correct pixel color via getPixelColor(x,y) on retina display (if you are sure [JDK-8274939](https://bugs.openjdk.java.net/browse/JDK-8274939) patch didn't help)

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

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

From duke at openjdk.java.net  Tue Feb 15 05:07:14 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Tue, 15 Feb 2022 05:07:14 GMT
Subject: Integrated: JDK-8016524: [macosx] Bottom line is not visible for
 JTableHeader
In-Reply-To: 
References: 
Message-ID: 

On Wed, 26 Jan 2022 00:12:17 GMT, Harshitha Onkar  wrote:

> Previously, the JTableHeader Bottom line wasn't visible on MacOS LAF (Aqua). With the fix the bottom line (light grey) is visible. 
> 
> Changes were made to AquaTableHeaderBorder.paintBorder method and the height of the component+border was adjusted in paint method.
> 
> A new test case (JTHeaderBorderTest.java) was added to test the fix as there was no corresponding test case present for this issue previously. The test checks if the border is visible by checking the color at the border location with the background color of the table and table-header, if both are different test case passes and it fails if the pixel color at border location matches either the table-header or table background color.

This pull request has now been integrated.

Changeset: f33329eb
Author:    Harshitha Onkar 
Committer: Prasanta Sadhukhan 
URL:       https://git.openjdk.java.net/jdk/commit/f33329eb7f7a1a541d8f30ba8952b0b922ac5257
Stats:     125 lines in 2 files changed: 123 ins; 0 del; 2 mod

8016524: [macosx] Bottom line is not visible for JTableHeader

Reviewed-by: psadhukhan, prr

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

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

From duke at openjdk.java.net  Tue Feb 15 05:28:14 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Tue, 15 Feb 2022 05:28:14 GMT
Subject: RFR: 8280861: Robot color picker broken on Linux with scaling
 above 100% [v3]
In-Reply-To: 
References: <7WQIrQr1kH9q7zlM2wZcrF7r-LX1uiQwYjN1TMovRds=.17e06f8b-1d83-42c4-8d38-6ccaeaacdc9e@github.com>

Message-ID: 

On Mon, 14 Feb 2022 18:24:15 GMT, Sergey Bylokhov  wrote:

>>> Is this scale parameter is simply ignored?
>> 
>> Looks like it. I can only find one call site of `get_drawable_data()` (in [Java_sun_awt_X11_XRobotPeer_getRGBPixelsImpl()](https://github.com/openjdk/jdk/blob/8441d51e71e143250b44eea74114a624cf00cc3e/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c#L336)) and the `scale` parameter is always 1. I think I can drop it from the interface if you prefer.
>
> Yes please, this "scale" just make the code complicated w/o reason.

That's done; please, take a look at the updated code.

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

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

From duke at openjdk.java.net  Tue Feb 15 05:28:14 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Tue, 15 Feb 2022 05:28:14 GMT
Subject: RFR: 8280861: Robot color picker broken on Linux with scaling
 above 100% [v3]
In-Reply-To: <0yMXWGYN_p2SQbk8Yqer8hKkjNXRnxyzx-v1AsoeuOo=.92a7afdf-6f62-4216-9052-971fc3d896fc@github.com>
References: <7WQIrQr1kH9q7zlM2wZcrF7r-LX1uiQwYjN1TMovRds=.17e06f8b-1d83-42c4-8d38-6ccaeaacdc9e@github.com>

 <0yMXWGYN_p2SQbk8Yqer8hKkjNXRnxyzx-v1AsoeuOo=.92a7afdf-6f62-4216-9052-971fc3d896fc@github.com>
Message-ID: 

On Tue, 15 Feb 2022 00:43:42 GMT, Phil Race  wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated copyright date in TestJProgressBarHighlightColor.java
>
> src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c line 2867:
> 
>> 2865: 
>> 2866: inline static int scale_down_to_plus_inf(int what, int scale) {
>> 2867:     return (int)ceilf(what / (float)scale);
> 
> I find the name of this and the companion function confusing.
> what is "inf" short for ? I see that and I think plus_infinity.
> scaled_ceiling and scaled_floor might be better names based on what I see.

Right, "inf" is for infinity; this is sort of how the rounding modes are described in the IEEE754 standard. But since full length words make the function name too long and short versions are confusing, I will rename as you suggested.

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

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

From serb at openjdk.java.net  Tue Feb 15 05:44:10 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 15 Feb 2022 05:44:10 GMT
Subject: RFR: 8281745: Create a regression test for JDK-4514331
In-Reply-To: <7N5tuie0JMzT334ltsuqmHi4XFXG_uWX9HJSGON4bJk=.6f41cb4e-331b-46f5-ab8c-550edb51a99a@github.com>
References: <7N5tuie0JMzT334ltsuqmHi4XFXG_uWX9HJSGON4bJk=.6f41cb4e-331b-46f5-ab8c-550edb51a99a@github.com>
Message-ID: 

On Tue, 15 Feb 2022 02:48:54 GMT, Manukumar V S  wrote:

> Create a regression test for JDK-4514331.
> It checks whether pressing 'Tab' key always shift focus to next component, even though the current focus is in JTextArea and some text is already selected.
> 
> Testing:
> I have verified this test with JDK 1.3.1 and JDK 1.4.1 .
> The issue is reproducible with JDK 1.3.1 and the test failed there, where the bug was originally reported and the test passed in JDK 1.4.1 where the issue was fixed.
> I have tested it in Linux, Mac and Windows platforms and it passed everywhere.

test/jdk/javax/swing/JTextArea/4514331/TabShiftsFocusToNextComponent.java line 72:

> 70:                 SwingUtilities.invokeAndWait(() -> {
> 71:                     setLookAndFeel(laf);
> 72:                     createUI();

I suggest calling waitForIdle after the window creation and before editor.getLocationOnScreen();

test/jdk/javax/swing/JTextArea/4514331/TabShiftsFocusToNextComponent.java line 75:

> 73:                 });
> 74:                 passed = false;
> 75:                 Point editorLoc = editor.getLocationOnScreen();

The editor is a Swing component, should be accessed on EDT.

test/jdk/javax/swing/JTextArea/4514331/TabShiftsFocusToNextComponent.java line 100:

> 98:         editor.setEditable(false);
> 99:         editor.requestFocusInWindow();
> 100:         panel.add(editor);

I am not sure that this will work all the time, the requestFocusInWindow(), see part of the spec:
>  * This component must be displayable, focusable, visible
    * and all of its ancestors (with the exception of the top-level
    * Window) must be visible for the request to be granted

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

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

From duke at openjdk.java.net  Tue Feb 15 06:01:46 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Tue, 15 Feb 2022 06:01:46 GMT
Subject: RFR: 8280861: Robot color picker broken on Linux with scaling
 above 100% [v4]
In-Reply-To: <7WQIrQr1kH9q7zlM2wZcrF7r-LX1uiQwYjN1TMovRds=.17e06f8b-1d83-42c4-8d38-6ccaeaacdc9e@github.com>
References: <7WQIrQr1kH9q7zlM2wZcrF7r-LX1uiQwYjN1TMovRds=.17e06f8b-1d83-42c4-8d38-6ccaeaacdc9e@github.com>
Message-ID: 

> The primary API for image capture on modern Linuxes is `gdk_pixbuf_get_from_window()` that expects both coordinates and the size unscaled (i.e. not multiplied by the current desktop scale). At the same time, `gtk3_interface.c:gtk3_get_drawable_data()` gets the coordinates from `Robot` that pre-scales them (multiplying by the scale known to Java, however, not necessarily the current desktop scale). The problem with the size had been partly taken care of in [JDK-8225118](https://bugs.openjdk.java.net/browse/JDK-8225118), but coordinates are still passed to `gdk_pixbuf_get_from_window()` pre-scaled.
> 
> The idea of the fix is to capture a possibly larger area that is guaranteed to contain the one that is interesting to the caller and then only copy the interesting pixels to the output image. As a positive side effect, the size of the captured area cannot be less than 1x1 (provided the correct input, of course). This solves the problem of zero size passed to  `(*fp_gdk_pixbuf_get_from_drawable)` when the desktop scale is 3 and we're asked to capture just one pixel. In that case, the previous formula (`width / (float) win_scale + 0.5`) would have yielded `0`. 
> 
> A related issue would be that tests written specifically for this general area (`java/awt/Robot`) didn't catch this problem and only somewhat unrelated tests (`javax/swing/...`) were affected.
> 
> This one is solved by adding pixel-sized areas to the test image in `HiDPIRobotScreenCaptureTest.java`, which precise colors are then verified to match the expected ones. In addition to that, instead of verifying just the color of the center of a large area, 4 more pixels close to the area's border are checked. This helps to make sure that captured area coordinates aren't way off.
> 
> The tests under `javax/swing/...` that originally helped to identify this problem were modified to provide more screen space for painting their components as extreme desktop scaling (300%) on Ubuntu doesn't leave much room due to a humongous title bar.
> 
> The fix was tested by running all the modified tests on Ubuntu with desktop scaling set to 100%, 200%, and 300%. The `Robot` tests were also executed on Windows (300% scaling) and MacOS.

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

  Renamed scaling functions and updated copyright.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7425/files
  - new: https://git.openjdk.java.net/jdk/pull/7425/files/fc651add..4a8c20af

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

  Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7425.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7425/head:pull/7425

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

From duke at openjdk.java.net  Tue Feb 15 06:01:49 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Tue, 15 Feb 2022 06:01:49 GMT
Subject: RFR: 8280861: Robot color picker broken on Linux with scaling
 above 100% [v3]
In-Reply-To: <0yMXWGYN_p2SQbk8Yqer8hKkjNXRnxyzx-v1AsoeuOo=.92a7afdf-6f62-4216-9052-971fc3d896fc@github.com>
References: <7WQIrQr1kH9q7zlM2wZcrF7r-LX1uiQwYjN1TMovRds=.17e06f8b-1d83-42c4-8d38-6ccaeaacdc9e@github.com>

 <0yMXWGYN_p2SQbk8Yqer8hKkjNXRnxyzx-v1AsoeuOo=.92a7afdf-6f62-4216-9052-971fc3d896fc@github.com>
Message-ID: 

On Tue, 15 Feb 2022 00:43:42 GMT, Phil Race  wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated copyright date in TestJProgressBarHighlightColor.java
>
> src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c line 2867:
> 
>> 2865: 
>> 2866: inline static int scale_down_to_plus_inf(int what, int scale) {
>> 2867:     return (int)ceilf(what / (float)scale);
> 
> I find the name of this and the companion function confusing.
> what is "inf" short for ? I see that and I think plus_infinity.
> scaled_ceiling and scaled_floor might be better names based on what I see.

@prrace The change has been made, please, take a look.

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

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

From mvs at openjdk.java.net  Tue Feb 15 08:06:46 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 15 Feb 2022 08:06:46 GMT
Subject: RFR: 8281738: Create a regression test for checking the 'Space'
 key activation of focused Button [v2]
In-Reply-To: 
References: 
Message-ID: 

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

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

  Fixed review comments: waitForIdle() added after frame creation and waits until button gains focus

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7460/files
  - new: https://git.openjdk.java.net/jdk/pull/7460/files/539b0eb8..eb6adc3d

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

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

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

From duke at openjdk.java.net  Tue Feb 15 08:32:10 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Tue, 15 Feb 2022 08:32:10 GMT
Subject: RFR: 8236907: JTable added to nested panels does not paint last
 visible row
In-Reply-To: 
References: 

Message-ID: 

On Mon, 14 Feb 2022 06:53:18 GMT, Prasanta Sadhukhan  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.
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java line 1903:
> 
>> 1901:     private void paintDropLines(Graphics g) {
>> 1902:         JTable.DropLocation loc = table.getDropLocation();
>> 1903:         if (loc == null) {
> 
> Deleting this seems to have regressed JDK-8081491 where 1 extra row is printed per page..
> jdk/test/java/awt/print/PageFormat/ImageableAreaTest.java is supposed to print 35 rows which was visible in console but it prints 36 rows..

The mentioned test computes 36 rows for frame height of 600 units. The 36th row is 18% visible in console and in printing its 100% visible. I have done the testing for the bug fix with an automated test case LastRowVisible.java and with the below test cases.
1. jdk/test/java/awt/print/PageFormat/ImageableAreaTest.java
2. jdk/test/javax/swing/JTable/LostTextTest.java
3. test/jdk/javax/swing/JTable/TestClearSel.java
The maxRow computations are just fine for console and printable views, the only thing is visibility of the same when setSize of frame is not a multiple of rowHeight of a table......

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

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

From mvs at openjdk.java.net  Tue Feb 15 08:49:54 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 15 Feb 2022 08:49:54 GMT
Subject: RFR: 8281745: Create a regression test for JDK-4514331 [v2]
In-Reply-To: 
References: <7N5tuie0JMzT334ltsuqmHi4XFXG_uWX9HJSGON4bJk=.6f41cb4e-331b-46f5-ab8c-550edb51a99a@github.com>

Message-ID: 

On Tue, 15 Feb 2022 05:38:38 GMT, Sergey Bylokhov  wrote:

>> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed review comments: frame created in EDT, waitForIdle() added after frame creation, editor access in EDT
>
> test/jdk/javax/swing/JTextArea/4514331/TabShiftsFocusToNextComponent.java line 100:
> 
>> 98:         editor.setEditable(false);
>> 99:         editor.requestFocusInWindow();
>> 100:         panel.add(editor);
> 
> I am not sure that this will work all the time, the requestFocusInWindow(), see part of the spec:
>>  * This component must be displayable, focusable, visible
>     * and all of its ancestors (with the exception of the top-level
>     * Window) must be visible for the request to be granted

I have moved the editor.requestFocusInWindow() call after frame.setVisible(true) and also even if this call is not honoured, the editor will get the focus as we are clicking on the editor (robot.mousePress) in runTest().

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

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

From mvs at openjdk.java.net  Tue Feb 15 08:49:54 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 15 Feb 2022 08:49:54 GMT
Subject: RFR: 8281745: Create a regression test for JDK-4514331 [v2]
In-Reply-To: <7N5tuie0JMzT334ltsuqmHi4XFXG_uWX9HJSGON4bJk=.6f41cb4e-331b-46f5-ab8c-550edb51a99a@github.com>
References: <7N5tuie0JMzT334ltsuqmHi4XFXG_uWX9HJSGON4bJk=.6f41cb4e-331b-46f5-ab8c-550edb51a99a@github.com>
Message-ID: 

> Create a regression test for JDK-4514331.
> It checks whether pressing 'Tab' key always shift focus to next component, even though the current focus is in JTextArea and some text is already selected.
> 
> Testing:
> I have verified this test with JDK 1.3.1 and JDK 1.4.1 .
> The issue is reproducible with JDK 1.3.1 and the test failed there, where the bug was originally reported and the test passed in JDK 1.4.1 where the issue was fixed.
> I have tested it in Linux, Mac and Windows platforms and it passed everywhere.

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

  Fixed review comments: frame created in EDT, waitForIdle() added after frame creation, editor access in EDT

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7469/files
  - new: https://git.openjdk.java.net/jdk/pull/7469/files/8ad19878..bc9bc1e9

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

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

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

From mvs at openjdk.java.net  Tue Feb 15 08:53:09 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 15 Feb 2022 08:53:09 GMT
Subject: RFR: 8281738: Create a regression test for checking the 'Space'
 key activation of focused Button [v2]
In-Reply-To: <8RrJ1npXH7WIbx_4f6CKmNMb-kLGItFWEmyWELDtJyw=.02443c61-7916-4c15-b5dc-80c9527830be@github.com>
References: 
 <8RrJ1npXH7WIbx_4f6CKmNMb-kLGItFWEmyWELDtJyw=.02443c61-7916-4c15-b5dc-80c9527830be@github.com>
Message-ID: <9DLDva2eTEzTGRsrXfEtbAyk1uTKGh1PiPE57R5vSyQ=.6c6aa368-616e-495e-abda-18beb57c3a2a@github.com>

On Mon, 14 Feb 2022 23:24:23 GMT, Sergey Bylokhov  wrote:

>> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed review comments: waitForIdle() added after frame creation and waits until button gains focus
>
> test/jdk/javax/swing/JButton/SpaceKeyActivatesButton.java line 67:
> 
>> 65:                     createUI();
>> 66:                 });
>> 67: 
> 
> I think you should add robot.waitForIdle() after the frame creation, and also wait until the button will get a focus, since the "requestFocusInWindow" might be ignored.

Fixed it.

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

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

From dmarkov at openjdk.java.net  Tue Feb 15 09:30:12 2022
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Tue, 15 Feb 2022 09:30:12 GMT
Subject: Integrated: 8281555: [macos] Get rid of deprecated Style Masks
 constants
In-Reply-To: 
References: 
Message-ID: 

On Wed, 9 Feb 2022 17:50:48 GMT, Dmitry Markov  wrote:

> The Style Masks constants [1], which are utilised by AWT, were deprecated starting from macOS 10.12 Sierra. It is high time to replace them with new constants introduced by NSWindowStyleMask enumeration [2].
> 
> [1] - https://developer.apple.com/documentation/appkit/nspanel/style_masks
> [2] - https://developer.apple.com/documentation/appkit/nswindowstylemask

This pull request has now been integrated.

Changeset: f82866bc
Author:    Dmitry Markov 
URL:       https://git.openjdk.java.net/jdk/commit/f82866bc79cbeeac23716fa6fadd4877f5d0a462
Stats:     22 lines in 5 files changed: 0 ins; 0 del; 22 mod

8281555: [macos] Get rid of deprecated Style Masks constants

Reviewed-by: serb, aivanov

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

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

From prr at openjdk.java.net  Tue Feb 15 17:47:06 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 15 Feb 2022 17:47:06 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Feb 2022 19:20:16 GMT, DamonGuy  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.

Do we have a test that proves what happens ?
I see the code you mention that logs an error but when I trace that it ends up in
handleError() which has an entirely commented out body. Whereas the bug report says that
the content of the script tag is displayed .. perhaps that latter part is true  ?

But I am also confused because I see :-

            if (recent == dtd.script) { // means: if after starting 