From duke at openjdk.java.net  Tue Apr  5 20:16:28 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Tue, 5 Apr 2022 20:16:28 GMT
Subject: RFR: 8283712 : Create a manual test framework class [v5]
In-Reply-To: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
Message-ID: <qbKJqZO3IlieY4GAIW20LjtNYxE3LriYV9yqv6OSyPQ=.f43caf22-7bea-4604-9813-71a4d35f4635@github.com>

> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
> 1) Frame which contains test instruction .
> 2) Pass & Fail button so that user can mark the test pass or fail
> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
> 4) Disposing of all the frames.
> 
> @aivanov-jdk

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

  Fixed review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7966/files
  - new: https://git.openjdk.java.net/jdk/pull/7966/files/c9e64add..8e8feff5

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

  Stats: 87 lines in 2 files changed: 40 ins; 9 del; 38 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7966.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7966/head:pull/7966

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


From duke at openjdk.java.net  Tue Apr  5 20:19:42 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Tue, 5 Apr 2022 20:19:42 GMT
Subject: RFR: 8283712 : Create a manual test framework class [v4]
In-Reply-To: <wTK3ig7SHL3tyhqevUuA7W0Fk21yx3y0F8z2UHDCIdI=.1efc23f0-1a73-4f7a-be6e-e958e59f570c@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <IMKOkFbDuV-4DlmfcBxxPuL8dBo2GxrGWFET0sMnPPU=.6ca91ed1-c940-4880-8487-892cb77de3e8@github.com>
 <wTK3ig7SHL3tyhqevUuA7W0Fk21yx3y0F8z2UHDCIdI=.1efc23f0-1a73-4f7a-be6e-e958e59f570c@github.com>
Message-ID: <wSVzHeNsXrS4KqOlYGj2nwOBtte_TdCI-yNmMPB_DUY=.2bcaf422-ab99-43d5-a2b8-57c83daa802d@github.com>

On Mon, 4 Apr 2022 18:59:39 GMT, Phil Race <prr at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Dispose the Frame based in EDT
>
> test/jdk/java/awt/print/PrinterJob/PrintLatinCJKTest.java line 74:
> 
>> 72:             f.setLocationRelativeTo(null);
>> 73:             f.setVisible(true);
>> 74:         });
> 
> I don't see where/how this frame is disposed.

Added code to dispose the test UI.

> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 76:
> 
>> 74:         this.timeoutMinutes = timeoutMinutes;
>> 75: 
>> 76:         invokeAndWait(() -> {
> 
> This should also be preceded by a check as to whether it is EDT - I thought I suggested something along those lines already - make it so it works either way and the test itself doesn't have to care to make sure it is on or off EDT, and also even it if uses invokeAndWait when it didn't need to it is harmless.

Added a check whether the method is called with in EDT else invoke the UI with in EDT.

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

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


From prr at openjdk.java.net  Tue Apr  5 20:38:37 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 5 Apr 2022 20:38:37 GMT
Subject: RFR: 8283712 : Create a manual test framework class [v5]
In-Reply-To: <qbKJqZO3IlieY4GAIW20LjtNYxE3LriYV9yqv6OSyPQ=.f43caf22-7bea-4604-9813-71a4d35f4635@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <qbKJqZO3IlieY4GAIW20LjtNYxE3LriYV9yqv6OSyPQ=.f43caf22-7bea-4604-9813-71a4d35f4635@github.com>
Message-ID: <ixE8HKEE_WVGdnbU0uep5LSwT2thtslBW0Sv7r1qNTg=.6734d833-8029-493a-83ac-366f2c3c9613@github.com>

On Tue, 5 Apr 2022 20:16:28 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
>> 1) Frame which contains test instruction .
>> 2) Pass & Fail button so that user can mark the test pass or fail
>> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
>> 4) Disposing of all the frames.
>> 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed review comments

Marked as reviewed by prr (Reviewer).

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

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


From aivanov at openjdk.java.net  Tue Apr  5 21:01:45 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 5 Apr 2022 21:01:45 GMT
Subject: RFR: 8283712 : Create a manual test framework class [v4]
In-Reply-To: <IMKOkFbDuV-4DlmfcBxxPuL8dBo2GxrGWFET0sMnPPU=.6ca91ed1-c940-4880-8487-892cb77de3e8@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <IMKOkFbDuV-4DlmfcBxxPuL8dBo2GxrGWFET0sMnPPU=.6ca91ed1-c940-4880-8487-892cb77de3e8@github.com>
Message-ID: <h7QOpvrWuaiHPdWgZ0nJ1kd_9Ccpp25XBgeLdVc995Q=.4f12d6ad-bb09-4395-9cbf-89f439e76bac@github.com>

On Mon, 28 Mar 2022 17:06:41 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
>> 1) Frame which contains test instruction .
>> 2) Pass & Fail button so that user can mark the test pass or fail
>> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
>> 4) Disposing of all the frames.
>> 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dispose the Frame based in EDT

The ability to have instructions as HTML text (hosted in `JEditorPane`) would make the solution more flexible. Obviously, we shouldn't implement everything we can think of. Yet we should still think about possible advanced features.

test/jdk/java/awt/print/PrinterJob/PrintLatinCJKTest.java line 48:

> 46:     static PrintLatinCJKTest testInstance = new PrintLatinCJKTest();
> 47:     static String info =
> 48:        "To test 8022536, if a remote printer is the system default, \n"+

It's unclear to me whether a remote printer is required for the test.

We should probably clarify the test instructions. Yet I haven't looked into the bug for which the test was written.

test/jdk/java/awt/print/PrinterJob/PrintLatinCJKTest.java line 91:

> 89:     public static void main(String[] args) throws InterruptedException, InvocationTargetException {
> 90:         PassFailJFrame passFailJFrame = new PassFailJFrame("Test Instruction" +
> 91:                 "Frame", info, 7, 30, 3);

This already breaks the threading rules of Swing: every access to Swing components must be done on EDT.

The thing is `PassFailJFrame` extends `JFrame`, thus super constructor (the inherited one from `JFrame`) will be called on main thread. It's not what we want, isn't it?

I'd suggest not to extend `JFrame` at all. We're not developing new functionality to `JFrame` but build UI using Swing components.

As a benefit, you'll be able to initialise GUI on EDT if the constructor is called on another thread.

I support Phil that the framework should document threading and mark methods which are allowed to be called on any thread. Probably all the methods should allow for it.

test/jdk/java/awt/print/PrinterJob/PrintLatinCJKTest.java line 93:

> 91:                 "Frame", info, 7, 30, 3);
> 92:         PrintLatinCJKTest.showFrame();
> 93:         passFailJFrame.awaitAndCheck();

I believe `awaitAndCheck()` is the method that must be called from the main thread. It waits until the test is completed.

If it was called on EDT, it would block the event queue.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 42:

> 40:     private final CountDownLatch latch = new CountDownLatch(1);
> 41:     private boolean failed = false;
> 42:     private String testFailedReason;

These two are accessed by EDT and main thread. The boolean field should be declared `volatile` or use `AtomicBoolean`. The same applies for `testFailedReason`.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 45:

> 43:     private JTextArea instructionsText;
> 44:     private final int maxRowLength;
> 45:     private final int maxStringLength;

These aren't needed as fields, they're used only to create instruction text.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 65:

> 63:      * @throws HeadlessException
> 64:      * @throws InterruptedException
> 65:      * @throws InvocationTargetException

I suggest adding generic descriptions of exceptions to avoid IDE warnings.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 78:

> 76:         invokeAndWait(() -> {
> 77:             setLayout(new BorderLayout());
> 78:             instructionsText = new JTextArea(instructions, maxRowLength, maxStringLength);

You could use line wrap functionality of JTextArea to avoid adding `\n` to the instructions.

Consider placing it into JScrollPane for flexibility, though not required.

`maxRowLength` is actually the number of rows (lines), and `maxStringLength` is the number of columns. These parameters are used to calculate the preferred size of the text area, they don't limit the text the component can store.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 80:

> 78:             instructionsText = new JTextArea(instructions, maxRowLength, maxStringLength);
> 79:             instructionsText.setEditable(false);
> 80:             instructionsText.setFocusable(false);

I think leaving the instructions focusable won't hurt. It would allow selecting text (and copying it) if the tester needs it for whatever reason.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 95:

> 93:             add(buttonsPanel, BorderLayout.SOUTH);
> 94:             pack();
> 95:             setLocation(10, 10);

The instruction window should probably be placed around the centre of the screen.

The class should provide a method to position a secondary frame near the instruction frame so that both frames don't overlap.

A possibility to include test UI to the instructions could be beneficial in some cases: dealing with one window is easier than with several ones. It's just a suggestion for further improvement though.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 96:

> 94:             pack();
> 95:             setLocation(10, 10);
> 96:             setVisible(true);

Closing the window with Close button should also fail the test, now it doesn't.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 125:

> 123:     public void getFailureReason() {
> 124:         final JDialog dialog = new JDialog();
> 125:         dialog.setTitle("Failure reason");

I suggest making the dialog Toolkit-modal so that only the dialog can be interacted with.


        final JDialog dialog = new JDialog(this, "Failure reason", TOOLKIT_MODAL);


At this time, I can click Fail again several times and I'll have several dialogs open. I can also click Pass which completes the test and disposes of the dialogs.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 135:

> 133:             dialog.dispose();
> 134:             latch.countDown();
> 135:         });

This doesn't handle closing the dialog via Close button or Esc. I believe it should also do everything but copying the entered text.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 144:

> 142:         jPanel.add(okayBtnPanel, BorderLayout.SOUTH);
> 143:         dialog.add(jPanel);
> 144:         dialog.setLocationRelativeTo(null);

We should probably position the dialog relatively to the frame or the Fail button.

Now the frame is displayed on the left edge of the screen but the dialog is in the centre of the screen as if they're unrelated.

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

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


From aivanov at openjdk.java.net  Tue Apr  5 21:01:45 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 5 Apr 2022 21:01:45 GMT
Subject: RFR: 8283712 : Create a manual test framework class [v4]
In-Reply-To: <wTK3ig7SHL3tyhqevUuA7W0Fk21yx3y0F8z2UHDCIdI=.1efc23f0-1a73-4f7a-be6e-e958e59f570c@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <IMKOkFbDuV-4DlmfcBxxPuL8dBo2GxrGWFET0sMnPPU=.6ca91ed1-c940-4880-8487-892cb77de3e8@github.com>
 <wTK3ig7SHL3tyhqevUuA7W0Fk21yx3y0F8z2UHDCIdI=.1efc23f0-1a73-4f7a-be6e-e958e59f570c@github.com>
Message-ID: <mC-7MGRUhZ1m9jpxMbDD2xR7W5tMhw6wdLWqGiDP-1o=.16886adb-2d05-4b02-91dc-428358924aa6@github.com>

On Mon, 4 Apr 2022 18:59:39 GMT, Phil Race <prr at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Dispose the Frame based in EDT
>
> test/jdk/java/awt/print/PrinterJob/PrintLatinCJKTest.java line 74:
> 
>> 72:             f.setLocationRelativeTo(null);
>> 73:             f.setVisible(true);
>> 74:         });
> 
> I don't see where/how this frame is disposed.

It isn't disposed of.

When run with jtreg, it disposed of by jtreg when it shuts down the VM because main thread existed. If it's run outside of jtreg, the frame remains open after clicking Pass (or Fail).

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

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


From aivanov at openjdk.java.net  Tue Apr  5 21:04:40 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 5 Apr 2022 21:04:40 GMT
Subject: RFR: 8283712 : Create a manual test framework class [v5]
In-Reply-To: <qbKJqZO3IlieY4GAIW20LjtNYxE3LriYV9yqv6OSyPQ=.f43caf22-7bea-4604-9813-71a4d35f4635@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <qbKJqZO3IlieY4GAIW20LjtNYxE3LriYV9yqv6OSyPQ=.f43caf22-7bea-4604-9813-71a4d35f4635@github.com>
Message-ID: <R2HGSplu9iVNODMzpA9ikE5HYG4Fe6iVmIhETNhXnKo=.d8f4cf32-1120-4d43-9a55-38f8bff65816@github.com>

On Tue, 5 Apr 2022 20:16:28 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
>> 1) Frame which contains test instruction .
>> 2) Pass & Fail button so that user can mark the test pass or fail
>> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
>> 4) Disposing of all the frames.
>> 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed review comments

test/jdk/java/awt/print/PrinterJob/PrintLatinCJKTest.java line 105:

> 103:         PrintLatinCJKTest.showFrame();
> 104:         passFailJFrame.awaitAndCheck();
> 105:         PrintLatinCJKTest.disposeTestFrame();

It won't be disposed of if the test fails, that is throws an exception, so this should be in try-finally block.

The class name isn't required to call a static method which is in this class.

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

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


From aivanov at openjdk.java.net  Tue Apr  5 21:11:41 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 5 Apr 2022 21:11:41 GMT
Subject: RFR: 8283712 : Create a manual test framework class [v4]
In-Reply-To: <h7QOpvrWuaiHPdWgZ0nJ1kd_9Ccpp25XBgeLdVc995Q=.4f12d6ad-bb09-4395-9cbf-89f439e76bac@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <IMKOkFbDuV-4DlmfcBxxPuL8dBo2GxrGWFET0sMnPPU=.6ca91ed1-c940-4880-8487-892cb77de3e8@github.com>
 <h7QOpvrWuaiHPdWgZ0nJ1kd_9Ccpp25XBgeLdVc995Q=.4f12d6ad-bb09-4395-9cbf-89f439e76bac@github.com>
Message-ID: <eFBuQUML7TfiOHXKk0nDdCMbZaC34af_5fTDBOse0q4=.7845cf17-6fe5-4b69-83a7-64e8fe8768db@github.com>

On Tue, 5 Apr 2022 20:57:58 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The ability to have instructions as HTML text (hosted in JEditorPane) would make the solution more flexible. Obviously, we shouldn't implement everything we can think of. Yet we should still think about possible advanced features.

Although I had the above in mind, I wanted to suggest _adding a timer_ until the timeout. It could give the tester an idea how much time left.

Shall the timeout be increased to at least 5 minutes? Or more?

A document is to be printed, the printer could be located not close to the tester. There should be enough time to fetch a printed sheet of paper.

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

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


From aivanov at openjdk.java.net  Tue Apr  5 21:11:42 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 5 Apr 2022 21:11:42 GMT
Subject: RFR: 8283712 : Create a manual test framework class [v5]
In-Reply-To: <qbKJqZO3IlieY4GAIW20LjtNYxE3LriYV9yqv6OSyPQ=.f43caf22-7bea-4604-9813-71a4d35f4635@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <qbKJqZO3IlieY4GAIW20LjtNYxE3LriYV9yqv6OSyPQ=.f43caf22-7bea-4604-9813-71a4d35f4635@github.com>
Message-ID: <iLbCWWpwAir1tJ68pnIyUd33WvnT7NE53jSdongJkJo=.fa82e465-1cee-4934-883f-fc01944716e8@github.com>

On Tue, 5 Apr 2022 20:16:28 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
>> 1) Frame which contains test instruction .
>> 2) Pass & Fail button so that user can mark the test pass or fail
>> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
>> 4) Disposing of all the frames.
>> 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed review comments

This PR includes a test fix. Should the test fix bugid be the main bugid under which the PR is integrated? The bugid for the framework class could be added as an additional resolved bug.

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

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


From aivanov at openjdk.java.net  Tue Apr  5 21:17:40 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 5 Apr 2022 21:17:40 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v11]
In-Reply-To: <Q9Rzoht-EKO-lEy-xyFOEVkSLY42UclCWsh-31dZdwg=.e986a229-14ec-4f54-bf5c-07546b66dac7@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <YEi-Ge2_proOlxBQ_qGD4b4u_17FGTmHgPhXAZ-OH14=.b92e4259-eeeb-4fbc-a105-8235572a9d78@github.com>
 <Q9Rzoht-EKO-lEy-xyFOEVkSLY42UclCWsh-31dZdwg=.e986a229-14ec-4f54-bf5c-07546b66dac7@github.com>
Message-ID: <tUPMueSai2hpm6UO6lbgq-nE8NPB94ypgvDmtMsRtg4=.093b8f21-36fc-400b-b4eb-dede5685c46a@github.com>

On Tue, 5 Apr 2022 17:01:13 GMT, Phil Race <prr at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on Reiview comments
>
> test/jdk/javax/swing/ImageIcon/LoadInterruptTest.java line 73:
> 
>> 71:         setUpOutput();
>> 72: 
>> 73:         Thread.currentThread().interrupt();
> 
> really I am unclear if calling interrupt() even before creating the ImageIcon is guaranteed to do what you want .. how are you sure there will be no unexpected consequences.

It's specified by [`Object.wait`](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Object.html#wait(long)):

> @throws InterruptedException if any thread interrupted the current thread _before or
> while_ the current thread was waiting. The <em>interrupted status</em> of the
> current thread is cleared when this exception is thrown.

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

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


From serb at openjdk.java.net  Wed Apr  6 05:21:06 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 6 Apr 2022 05:21:06 GMT
Subject: RFR: 8284288: Use SVG images for FocusSpec.html and Modality.html
In-Reply-To: <o43HoV5no2fr1X-HBHBkcWS_pGl8WNW4XElrllL_kTI=.1fe4166b-4fa1-4865-817d-52912f811950@github.com>
References: <o43HoV5no2fr1X-HBHBkcWS_pGl8WNW4XElrllL_kTI=.1fe4166b-4fa1-4865-817d-52912f811950@github.com>
Message-ID: <qO8G8Yt6q3E-ZWk3AfdD9xe5JyGReYSDxAWwzyGFiIQ=.58298b32-b65a-49b3-a29e-d9d38ea94081@github.com>

On Mon, 4 Apr 2022 11:17:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Both `FocusSpec.html` and `Modality.html` use GIF images for diagrams. The images look jagged, especially on High DPI screens which are common now. The images in `Modality.html` use dithered colours which don't look sharp even on regular displays.
> 
> All the modern browsers support SVG which is a vector format and therefore it always looks sharp.
> 
> You can view how the files look after being processed by javadoc:
> 
> - **side-by-side** allows comparing the current and the new images:
>   - [FocusSpec.html](http://cr.openjdk.java.net/~aivanov/8284288/side-by-side/api/java.desktop/java/awt/doc-files/FocusSpec.html)
>   - [Modality.html](http://cr.openjdk.java.net/~aivanov/8284288/side-by-side/api/java.desktop/java/awt/doc-files/Modality.html)
> - **clean** is the final version:
>   - [FocusSpec.html](http://cr.openjdk.java.net/~aivanov/8284288/clean/api/java.desktop/java/awt/doc-files/FocusSpec.html)
>   - [Modality.html](http://cr.openjdk.java.net/~aivanov/8284288/clean/api/java.desktop/java/awt/doc-files/Modality.html)

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Wed Apr  6 05:22:42 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 6 Apr 2022 05:22:42 GMT
Subject: RFR: 8283704: Add sealed modifier to
 java.awt.MultipleGradientPaint
In-Reply-To: <lF7oZR5JgTFhOkiNkOKDNg4u_bxta0Tf-F1KlgJxrzo=.84cead53-1457-4f15-a012-6cfc9f51975c@github.com>
References: <lF7oZR5JgTFhOkiNkOKDNg4u_bxta0Tf-F1KlgJxrzo=.84cead53-1457-4f15-a012-6cfc9f51975c@github.com>
Message-ID: <adwPY3cmvSMlY79y8ZoFrOeeI8S5KCdW_l1sWsmzRLA=.7386132a-a28f-479b-afcc-dbae524be462@github.com>

On Fri, 1 Apr 2022 19:18:39 GMT, Phil Race <prr at openjdk.org> wrote:

> Along the same lines as other recent additions of the sealed modifier but this one is quite simple.
> Only MultiGradientPaint is touched. The two extant sub-classes it permits are already final
> 
> CSR for review : https://bugs.openjdk.java.net/browse/JDK-8284188
> 
> jtreg and JCK API tests pass

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Wed Apr  6 05:23:39 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 6 Apr 2022 05:23:39 GMT
Subject: RFR: 8284023:
 java.sun.awt.X11GraphicsDevice.getDoubleBufferVisuals() leaks
 XdbeScreenVisualInfo [v2]
In-Reply-To: <CCn5skshbowp6nFXfQ834A6QPTUXcJHB5RMhmUggpc0=.c5366326-710e-40b7-b0d2-a7da763eb18d@github.com>
References: <6vPxcf3BllwA1Di0WXKrNF9TFKjPnLnfIAuSO8PyV3s=.34ac5f51-a610-4809-9a1e-f822d955340b@github.com>
 <CCn5skshbowp6nFXfQ834A6QPTUXcJHB5RMhmUggpc0=.c5366326-710e-40b7-b0d2-a7da763eb18d@github.com>
Message-ID: <4MuA8cH3vrM7CU9fYFzouNf1Wr34zpnSIUNMKL-d2IM=.758d7d53-9bd9-4343-8451-03b3f278ad50@github.com>

On Thu, 31 Mar 2022 12:37:13 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review this small patch that fixes memory leak of `XdbeScreenVisualInfo` obtained from `XdbeGetVisualInfo()` method call.
>> 
>> Test:
>> - [x] jdk_awt
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @mrserb's comment

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Wed Apr  6 05:24:46 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 6 Apr 2022 05:24:46 GMT
Subject: RFR: 8284014 Menu items with submenus in JPopupMEnu are not spoken
 on macOS [v2]
In-Reply-To: <GPi4Yanvsvx9FyO-od2-IfQIff310OmdBuOrtYfSCGk=.3299f4d0-bf80-4a13-88e9-2c89d79e45fa@github.com>
References: <uoV0A08vCi-i0yZ-gbdQaqk_huKTX1ohMqwViBID0xA=.5624eac6-1ba9-4c30-affa-34cdd15e73fb@github.com>
 <GPi4Yanvsvx9FyO-od2-IfQIff310OmdBuOrtYfSCGk=.3299f4d0-bf80-4a13-88e9-2c89d79e45fa@github.com>
Message-ID: <CeC_8tbHDZHuo0M564N6tT4fytU73v6aCSifLskMSRk=.1baebbb6-1ee3-48e3-bfa3-f0dcc4c68c5b@github.com>

On Thu, 31 Mar 2022 10:19:26 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> If the JPopupMenu has menu items with submenus, those items are not spoken by VoiceOver.
>> 
>> @forantar @azuev-java please review.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Is the check for the AccessibleRole.POPUP_MENU is needed here? How it will work if the Menu is added to some container other than POPUP_MENU?

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Wed Apr  6 05:28:59 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 6 Apr 2022 05:28:59 GMT
Subject: RFR: 8283706: Add final or sealed modifier to appropriate
 javax.swing API classes
In-Reply-To: <PfDlBvA6XZ18qqLp21-ZAioRrPXgHeqJ2yUflkmEnK8=.35b6121b-405b-4e80-b933-9ef99a53e084@github.com>
References: <PfDlBvA6XZ18qqLp21-ZAioRrPXgHeqJ2yUflkmEnK8=.35b6121b-405b-4e80-b933-9ef99a53e084@github.com>
Message-ID: <WFCnNVLDVUs39mzqFPx9Vt7n9nKwtiGkd3NQxcMvvhc=.e9021d66-6a4c-472c-a531-c16d685d32e0@github.com>

On Sat, 2 Apr 2022 23:21:03 GMT, Phil Race <prr at openjdk.org> wrote:

> Update Swing classes to use JEP 409 sealed and non-sealed modifiers and add the final modifier where appropriate.
> 
> jtreg tests and JCK API tests pass
> 
> CSR for review here : https://bugs.openjdk.java.net/browse/JDK-8284214

src/java.desktop/share/classes/javax/swing/GroupLayout.java line 2461:

> 2459:      */
> 2460:     public sealed class ParallelGroup extends Group
> 2461:          permits BaselineGroup {

The BaselineGroup class is private so not part of the public API, is it fine to mention the non-public class in the permits block for the public class?

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

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


From serb at openjdk.java.net  Wed Apr  6 05:33:40 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 6 Apr 2022 05:33:40 GMT
Subject: RFR: 8284294: Create an automated regression test for RFE 4138746
In-Reply-To: <eT3ptA1jEm8wqypnXNY7E94o23Xb63Q3zOJ3FuJv_t8=.37ac3282-d533-427d-833a-4e796947fa8f@github.com>
References: <eT3ptA1jEm8wqypnXNY7E94o23Xb63Q3zOJ3FuJv_t8=.37ac3282-d533-427d-833a-4e796947fa8f@github.com>
Message-ID: <zOgNgOdtJGVq6Ty1nNWe-Xm31d2E2CeNalFJlURbTEE=.ce9e7349-f320-40c2-82ff-3b9c4f6c01ac@github.com>

On Mon, 4 Apr 2022 14:05:14 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Create an automated regression test for [JDK-4138746](https://bugs.openjdk.java.net/browse/JDK-4138746)
> 
> Issue:
> In the following example (and similarly with other components) you cannot specify the correct character to underline:
> 
> JLabel label = new JLabel ("Save As...");
> label.setDisplayedMnemonic ('A');
> 
> The 'A' in 'As' should be underlined (that's the intention at least), but the 'a' in 'Save' is what gets underlined.
> 
> The problem (aside from the lack of an API to specify exactly what should be underlined) is in the javax.swing.plaf.basic.BasicGraphicUtils drawString method which underlines the first character (upper OR lowercase) that matches the mnemonic character.
> 
> Fix:
> A new property "displayedMnemonicIndex" is introduced
> in classes AbstractButton and JLabel. It tells which
> character to underline. So for example to underline
> the capital 'A' in 'Save As', one should call:
>     setMnemonic('A');
>     setDisplayedMnemonicIndex(5);
> 
> Testing:
> Tested in Mach5 10 times per platform and got all Pass.

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Wed Apr  6 05:36:44 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 6 Apr 2022 05:36:44 GMT
Subject: RFR: 8283794: CCE in XRTextRenderer.drawGlyphList and
 XRMaskFill.MaskFill [v2]
In-Reply-To: <VE3eRPzRlyCMFgLc0XrQrvy2pgqszE6ZC3TG7fcDvz8=.5facf5d5-668b-4190-acbc-bb481524d1ac@github.com>
References: <GD4NAkuLptwylcQOI8VBAXXI1rY7ycgz8O2NvPmhIOc=.f2c8334e-d2eb-4717-92a1-de2f9ed301b6@github.com>
 <VE3eRPzRlyCMFgLc0XrQrvy2pgqszE6ZC3TG7fcDvz8=.5facf5d5-668b-4190-acbc-bb481524d1ac@github.com>
Message-ID: <YTh8n_XsTVAne0JIdM_2DsoOmlNebdmTBXw7M_OjeHA=.a974737e-a5ca-49d3-b2da-4e05f48f744f@github.com>

On Fri, 1 Apr 2022 15:43:29 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Throwing InvalidPipeException for incompatible surfaces
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8283794: CCE in XRTextRenderer.drawGlyphList and XRMaskFill.MaskFill
>   
>   Extracted try/catch logic of SurfaceData cast to particular SurfaceData subclass into convenience method SurfaceData.convertTo(). Applied the method to XRTextRenderer.drawGlyphList() and XRMaskFill.MaskFill(). Refactored try/catch blocks handling similar cases.

Looks fine, I suggest checking the fix via mach5. @aghaisas please take a look.

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

Marked as reviewed by serb (Reviewer).

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


From darcy at openjdk.java.net  Wed Apr  6 05:45:40 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 6 Apr 2022 05:45:40 GMT
Subject: RFR: 8283706: Add final or sealed modifier to appropriate
 javax.swing API classes
In-Reply-To: <WFCnNVLDVUs39mzqFPx9Vt7n9nKwtiGkd3NQxcMvvhc=.e9021d66-6a4c-472c-a531-c16d685d32e0@github.com>
References: <PfDlBvA6XZ18qqLp21-ZAioRrPXgHeqJ2yUflkmEnK8=.35b6121b-405b-4e80-b933-9ef99a53e084@github.com>
 <WFCnNVLDVUs39mzqFPx9Vt7n9nKwtiGkd3NQxcMvvhc=.e9021d66-6a4c-472c-a531-c16d685d32e0@github.com>
Message-ID: <V6L04fMUKgHOu82Sm8KHJFARu0hB0EF5my4-emPDnWw=.e2cd697d-1cd8-4642-b8ea-2075dd7e0197@github.com>

On Wed, 6 Apr 2022 05:25:43 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Update Swing classes to use JEP 409 sealed and non-sealed modifiers and add the final modifier where appropriate.
>> 
>> jtreg tests and JCK API tests pass
>> 
>> CSR for review here : https://bugs.openjdk.java.net/browse/JDK-8284214
>
> src/java.desktop/share/classes/javax/swing/GroupLayout.java line 2461:
> 
>> 2459:      */
>> 2460:     public sealed class ParallelGroup extends Group
>> 2461:          permits BaselineGroup {
> 
> The BaselineGroup class is private so not part of the public API, is it fine to mention the non-public class in the permits block for the public class?

Yes, that is fine; javadoc will filter out displaying non-public classes in a permits clause.

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

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


From mvs at openjdk.java.net  Wed Apr  6 06:31:38 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 6 Apr 2022 06:31:38 GMT
Subject: RFR: 8284294: Create an automated regression test for RFE 4138746
 [v2]
In-Reply-To: <eT3ptA1jEm8wqypnXNY7E94o23Xb63Q3zOJ3FuJv_t8=.37ac3282-d533-427d-833a-4e796947fa8f@github.com>
References: <eT3ptA1jEm8wqypnXNY7E94o23Xb63Q3zOJ3FuJv_t8=.37ac3282-d533-427d-833a-4e796947fa8f@github.com>
Message-ID: <wC0wbFFDZfFkdEfDruZ-1xU8yltKE6q47tMPOEX8CMg=.5bdac633-4a53-4d5f-bdde-568aa2667510@github.com>

> Create an automated regression test for [JDK-4138746](https://bugs.openjdk.java.net/browse/JDK-4138746)
> 
> Issue:
> In the following example (and similarly with other components) you cannot specify the correct character to underline:
> 
> JLabel label = new JLabel ("Save As...");
> label.setDisplayedMnemonic ('A');
> 
> The 'A' in 'As' should be underlined (that's the intention at least), but the 'a' in 'Save' is what gets underlined.
> 
> The problem (aside from the lack of an API to specify exactly what should be underlined) is in the javax.swing.plaf.basic.BasicGraphicUtils drawString method which underlines the first character (upper OR lowercase) that matches the mnemonic character.
> 
> Fix:
> A new property "displayedMnemonicIndex" is introduced
> in classes AbstractButton and JLabel. It tells which
> character to underline. So for example to underline
> the capital 'A' in 'Save As', one should call:
>     setMnemonic('A');
>     setDisplayedMnemonicIndex(5);
> 
> Testing:
> Tested in Mach5 10 times per platform and got all Pass.

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

  Fixed one wrong conditional check: removed ! operator from 'if (focusGainedLatch.await(3, TimeUnit.SECONDS))'

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8093/files
  - new: https://git.openjdk.java.net/jdk/pull/8093/files/9c951603..40bbfaac

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

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

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


From smandalika at openjdk.java.net  Wed Apr  6 07:02:25 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 6 Apr 2022 07:02:25 GMT
Subject: RFR: 8282857: Create a regression test for JDK-4702690 [v3]
In-Reply-To: <jklfp2oMIJWjzE4tz62KCLHfBqlaV0GlyZqk-wUiFHI=.7a721efc-e549-4058-819e-2785e64d9e8d@github.com>
References: <jklfp2oMIJWjzE4tz62KCLHfBqlaV0GlyZqk-wUiFHI=.7a721efc-e549-4058-819e-2785e64d9e8d@github.com>
Message-ID: <1MCuz4h2_IMc9oR2q-DP_O5xoiS_7j1cQ8DTHaQxDlU=.a5b07c51-39fa-4c39-aa2d-74643c22cf0f@github.com>

> Create a regression test for [JDK-4702690](https://bugs.openjdk.java.net/browse/JDK-4702690)
> 
> In many cases in Swing it is possible to easily programatically determine that a JScrollBar (or two) is scrolling some JPanel (the cannonical case is a JScrollPane).
> In these cases, when accessibility support is instantiated (e.g. the AccessibleJScrollBar is created), a Controller_For and Controled_By relation should be instantiated between the AccessibleJScrollBar and the AccessibleJPanel that the JScrollBar and JPanel are associated with.
> 
> This allows various assistive technologies, especially voice-recognition technologies, to better interact with scrolling items.
> 
> The test put up validates that the target object for these properties(CONTROLLED_BY, CONTROLLED_FOR) are set appropriately for JScrollPane and JScrollBar.
> This review is for migrating tests from a closed test suite to open.

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

 - Review Comments Fixed: Swing Components on EDT, 80 chars lines
 - Review Comments Fixed: Swing Components on EDT, 80 chars lines

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7753/files
  - new: https://git.openjdk.java.net/jdk/pull/7753/files/f712f33f..01f8c430

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

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

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


From mvs at openjdk.java.net  Wed Apr  6 07:25:42 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 6 Apr 2022 07:25:42 GMT
Subject: Integrated: 8284294: Create an automated regression test for RFE
 4138746
In-Reply-To: <eT3ptA1jEm8wqypnXNY7E94o23Xb63Q3zOJ3FuJv_t8=.37ac3282-d533-427d-833a-4e796947fa8f@github.com>
References: <eT3ptA1jEm8wqypnXNY7E94o23Xb63Q3zOJ3FuJv_t8=.37ac3282-d533-427d-833a-4e796947fa8f@github.com>
Message-ID: <ZlhzxABbaxkEzT-YG4RFhwPRmM8jtAypONSLH4Ak-vk=.9f729640-75e9-406c-8cee-1fa3d3b48911@github.com>

On Mon, 4 Apr 2022 14:05:14 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Create an automated regression test for [JDK-4138746](https://bugs.openjdk.java.net/browse/JDK-4138746)
> 
> Issue:
> In the following example (and similarly with other components) you cannot specify the correct character to underline:
> 
> JLabel label = new JLabel ("Save As...");
> label.setDisplayedMnemonic ('A');
> 
> The 'A' in 'As' should be underlined (that's the intention at least), but the 'a' in 'Save' is what gets underlined.
> 
> The problem (aside from the lack of an API to specify exactly what should be underlined) is in the javax.swing.plaf.basic.BasicGraphicUtils drawString method which underlines the first character (upper OR lowercase) that matches the mnemonic character.
> 
> Fix:
> A new property "displayedMnemonicIndex" is introduced
> in classes AbstractButton and JLabel. It tells which
> character to underline. So for example to underline
> the capital 'A' in 'Save As', one should call:
>     setMnemonic('A');
>     setDisplayedMnemonicIndex(5);
> 
> Testing:
> Tested in Mach5 10 times per platform and got all Pass.

This pull request has now been integrated.

Changeset: 0a67d686
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Abdul Kolarkunnu <akolarkunnu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0a67d686709000581e29440ef13324d1f2eba9ff
Stats:     233 lines in 1 file changed: 233 ins; 0 del; 0 mod

8284294: Create an automated regression test for RFE 4138746

Reviewed-by: serb

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

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


From ant at openjdk.java.net  Wed Apr  6 07:29:40 2022
From: ant at openjdk.java.net (Anton Tarasov)
Date: Wed, 6 Apr 2022 07:29:40 GMT
Subject: RFR: 8284014 Menu items with submenus in JPopupMEnu are not spoken
 on macOS [v2]
In-Reply-To: <GPi4Yanvsvx9FyO-od2-IfQIff310OmdBuOrtYfSCGk=.3299f4d0-bf80-4a13-88e9-2c89d79e45fa@github.com>
References: <uoV0A08vCi-i0yZ-gbdQaqk_huKTX1ohMqwViBID0xA=.5624eac6-1ba9-4c30-affa-34cdd15e73fb@github.com>
 <GPi4Yanvsvx9FyO-od2-IfQIff310OmdBuOrtYfSCGk=.3299f4d0-bf80-4a13-88e9-2c89d79e45fa@github.com>
Message-ID: <7ZcLAku-fVfZ8j7R5HWpK-WJkcY2GsiSwDmWhmxxsYM=.1f94e8b7-7166-4073-ba21-17ed89a415f1@github.com>

On Thu, 31 Mar 2022 10:19:26 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> If the JPopupMenu has menu items with submenus, those items are not spoken by VoiceOver.
>> 
>> @forantar @azuev-java please review.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Is the check for the AccessibleRole.POPUP_MENU is needed here? How it will work if the Menu is added to some container other than POPUP_MENU?

Marked as reviewed by ant (Reviewer).

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

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


From asemenov at openjdk.java.net  Wed Apr  6 09:33:48 2022
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Wed, 6 Apr 2022 09:33:48 GMT
Subject: RFR: 8284014 Menu items with submenus in JPopupMEnu are not spoken
 on macOS [v2]
In-Reply-To: <C7Pa7Tg6acVQKwcBy1bQ1kLT1b4sSWALYSto4VuHV8g=.feb4b813-9594-4f98-a367-fa4b07ba4637@github.com>
References: <uoV0A08vCi-i0yZ-gbdQaqk_huKTX1ohMqwViBID0xA=.5624eac6-1ba9-4c30-affa-34cdd15e73fb@github.com>
 <GPi4Yanvsvx9FyO-od2-IfQIff310OmdBuOrtYfSCGk=.3299f4d0-bf80-4a13-88e9-2c89d79e45fa@github.com>
 <C7Pa7Tg6acVQKwcBy1bQ1kLT1b4sSWALYSto4VuHV8g=.feb4b813-9594-4f98-a367-fa4b07ba4637@github.com>
Message-ID: <QCJuvauTBNNdLaxJvjJelfWl2KT-QeoaRYRIoKVEjlE=.8774ea2d-fc40-4e63-8e0c-aa2d8d00186a@github.com>

On Mon, 4 Apr 2022 18:13:28 GMT, Phil Race <prr at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Is the check for the AccessibleRole.POPUP_MENU is needed here? How it will work if the Menu is added to some container other than POPUP_MENU?
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m line 129:
> 
>> 127:      * Here we should keep all the mapping between the accessibility roles and implementing classes
>> 128:      */
>> 129:     rolesMap = [[NSMutableDictionary alloc] initWithCapacity:51];
> 
> I suppose 51 just seemed like a strange number ?

I removed one position from this dictionary, and therefore reduced the capacity.

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

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


From asemenov at openjdk.java.net  Wed Apr  6 09:33:50 2022
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Wed, 6 Apr 2022 09:33:50 GMT
Subject: Integrated: 8284014 Menu items with submenus in JPopupMEnu are not
 spoken on macOS
In-Reply-To: <uoV0A08vCi-i0yZ-gbdQaqk_huKTX1ohMqwViBID0xA=.5624eac6-1ba9-4c30-affa-34cdd15e73fb@github.com>
References: <uoV0A08vCi-i0yZ-gbdQaqk_huKTX1ohMqwViBID0xA=.5624eac6-1ba9-4c30-affa-34cdd15e73fb@github.com>
Message-ID: <7WzlM6iCIHltO_QzT2w0o8KbSazPrca3pRLXwbMVEOE=.3c18bfb1-e61d-4541-b121-695f1d61d259@github.com>

On Wed, 30 Mar 2022 15:24:17 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> If the JPopupMenu has menu items with submenus, those items are not spoken by VoiceOver.
> 
> @forantar @azuev-java please review.

This pull request has now been integrated.

Changeset: e18414a3
Author:    Artem Semenov <asemenov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e18414a322f0814c120bcdd415ebd7bd34949633
Stats:     111 lines in 3 files changed: 106 ins; 2 del; 3 mod

8284014: Menu items with submenus in JPopupMEnu are not spoken on macOS

Reviewed-by: prr, serb, ant

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

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


From duke at openjdk.java.net  Wed Apr  6 09:52:47 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 6 Apr 2022 09:52:47 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v12]
In-Reply-To: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
Message-ID: <0D26zlffXAuaF09r9vyh1idn2Afg7M-CT7zUN1PQCSs=.862da463-2a6b-4176-a5ab-43bd55531567@github.com>

> Removed the println() line from the Interrupted catch block. Since waitForID() Interrupt indicates completion of Image Loading, println as Interrupt handling was not required.

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

  Updated based on Reiview comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7754/files
  - new: https://git.openjdk.java.net/jdk/pull/7754/files/f366bc9f..0c37e6a7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7754&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7754&range=10-11

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

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


From aghaisas at openjdk.java.net  Wed Apr  6 09:57:10 2022
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Wed, 6 Apr 2022 09:57:10 GMT
Subject: RFR: 8284378: Make Metal the default Java 2D rendering pipeline for
 macOS
Message-ID: <Z45KY6DtqGZlf_r5X_CKM_YFP2IZzg48a2s4gI08Kzo=.5e58870d-cd23-4d5f-98c7-f581117a1a4e@github.com>

This PR makes Metal rendering pipeline as the default Java 2D rendering pipeline for macOS.

Please refer "JBS Description" for more details.

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

Commit messages:
 - Make Metal the default 2D pipeline

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

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


From duke at openjdk.java.net  Wed Apr  6 10:09:01 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 6 Apr 2022 10:09:01 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with methods
 of Document
Message-ID: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>

getText function returned extra endOfLine when appended. The reason was in `EditorEditorKit` class, `write(Writer out, Document doc, int pos, int len)` method, where translation happens from buffer to Out(Writer Object) if endOfLine is other than '\n' ( which is '\r\n' in windows). In order to write each line till End of line, the string till '\n' is written including '\r' and again endOfLine is written which results in extra Carriage Return. To solve this issue, a Condition is added which checks if previous character to '\n' is '\r', if true then whole string except Carriage Return ('\r') is written, else whole string till before '\n' is written.

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

Commit messages:
 - Fix for the Bug - Checking Condition added for \r
 - Merge branch 'master' of github.com:TejeshR13/jdk
 - Merge branch 'openjdk:master' into master
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge branch 'master' of github.com:TejeshR13/jdk
 - Initial Commit.

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

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


From aivanov at openjdk.java.net  Wed Apr  6 10:12:41 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 6 Apr 2022 10:12:41 GMT
Subject: RFR: 8283706: Add final or sealed modifier to appropriate
 javax.swing API classes
In-Reply-To: <PfDlBvA6XZ18qqLp21-ZAioRrPXgHeqJ2yUflkmEnK8=.35b6121b-405b-4e80-b933-9ef99a53e084@github.com>
References: <PfDlBvA6XZ18qqLp21-ZAioRrPXgHeqJ2yUflkmEnK8=.35b6121b-405b-4e80-b933-9ef99a53e084@github.com>
Message-ID: <qb9zBIs5mX89iBaCARxC7z2vtMKZdfWk3JXx27N0KhY=.09008a93-3051-4431-9161-2e5b5470ab7a@github.com>

On Sat, 2 Apr 2022 23:21:03 GMT, Phil Race <prr at openjdk.org> wrote:

> Update Swing classes to use JEP 409 sealed and non-sealed modifiers and add the final modifier where appropriate.
> 
> jtreg tests and JCK API tests pass
> 
> CSR for review here : https://bugs.openjdk.java.net/browse/JDK-8284214

Marked as reviewed by aivanov (Reviewer).

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

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


From aivanov at openjdk.java.net  Wed Apr  6 10:15:43 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 6 Apr 2022 10:15:43 GMT
Subject: RFR: 8283704: Add sealed modifier to
 java.awt.MultipleGradientPaint
In-Reply-To: <lF7oZR5JgTFhOkiNkOKDNg4u_bxta0Tf-F1KlgJxrzo=.84cead53-1457-4f15-a012-6cfc9f51975c@github.com>
References: <lF7oZR5JgTFhOkiNkOKDNg4u_bxta0Tf-F1KlgJxrzo=.84cead53-1457-4f15-a012-6cfc9f51975c@github.com>
Message-ID: <aFP0F4RDTDDO6dt3nFfsVLVOYQsOES48_EWGYpsiMfI=.80b42da2-35b4-4904-9f2c-c9ef025da0c6@github.com>

On Fri, 1 Apr 2022 19:18:39 GMT, Phil Race <prr at openjdk.org> wrote:

> Along the same lines as other recent additions of the sealed modifier but this one is quite simple.
> Only MultiGradientPaint is touched. The two extant sub-classes it permits are already final
> 
> CSR for review : https://bugs.openjdk.java.net/browse/JDK-8284188
> 
> jtreg and JCK API tests pass

Marked as reviewed by aivanov (Reviewer).

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

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


From psadhukhan at openjdk.java.net  Wed Apr  6 10:20:08 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 6 Apr 2022 10:20:08 GMT
Subject: RFR: 8282716: [macos] Enable
 javax/swing/JScrollPane/TestMouseWheelScroll.java on macos
Message-ID: <-tuJ1M1iwo7tJ_hOHvrEylZmUdS3DPOSbySVFnJGrBI=.212c7ea6-e12a-48af-a4fa-ee3a586e4a38@github.com>

The test was failing on macos and was excluded in macos because the viewposition was not changed after mouse wheel scroll. Seems like mouse wheel scroll direction is opposite in macos compared to windows etc so if we try to down-wheel scroll in macos when view position is at center of viewport (say element 3 is selected out of visible 7 elements), it cannot change viewposition as it cannot "scroll up" (since we are already at topmost viewport) whereas in windows, when we do down-wheel scroll in mouse wheel, it "scroll down" the viewport so viewposition is changed.

Fix is to use opposite scrolling motion in macos to check mouse wheel scroll is happening, which is what the testcase is meant for. CI testing of this test on all platform is ok.

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

Commit messages:
 - 8282716: [macos] Enable javax/swing/JScrollPane/TestMouseWheelScroll.java on macos

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

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


From aivanov at openjdk.java.net  Wed Apr  6 10:22:40 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 6 Apr 2022 10:22:40 GMT
Subject: RFR: 8283387: [macos] a11y : Screen magnifier does not show
 selected Tab
In-Reply-To: <V86gocGhD1-irIawpZi-UUzuCuqqbftWbZjVZsYiKZs=.31613701-b994-4d19-a407-dde398f72e61@github.com>
References: <V86gocGhD1-irIawpZi-UUzuCuqqbftWbZjVZsYiKZs=.31613701-b994-4d19-a407-dde398f72e61@github.com>
Message-ID: <y7Iww920jkklvaraNyRjqImdqLwBoG2XmKP0RKZLQWc=.337e3b81-e7b3-4254-afe1-df5ec649c868@github.com>

On Wed, 30 Mar 2022 22:21:51 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> It is impossible right now to manipulate state of the accessible children of the JTabbedPane via their AccessibleValue and because of that some of the assistive technologies are unable to interact with the parts of the JTabbedPane - namely, buttons, representing the JTabbedPane panel navigation buttons. Magnified is just one of the examples that can be engaging without connecting the hardware such as eye movement tracker.
> 
> By adding AccessibleValue to the JTabbedPane children containers we eliminate is problem. And since this inner class is private the standard review should be sufficient, no CSR is required.

test/jdk/javax/accessibility/JTabbedPane/AccessibleTabbedPaneTest.java line 39:

> 37: public class AccessibleTabbedPaneTest {
> 38:     public static void main(String[] args) {
> 39:         JTabbedPane pane = new JTabbedPane();

Shouldn't this be run on EDT?

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

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


From duke at openjdk.java.net  Wed Apr  6 10:27:12 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 6 Apr 2022 10:27:12 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v13]
In-Reply-To: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
Message-ID: <CVS-7oiZefVrDpgYDXgHGMoBQfhciocgrUs9LArYvek=.d3d93632-8124-41b7-850a-3efe9d9d4f14@github.com>

> Removed the println() line from the Interrupted catch block. Since waitForID() Interrupt indicates completion of Image Loading, println as Interrupt handling was not required.

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

  Updated based on Reiview comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7754/files
  - new: https://git.openjdk.java.net/jdk/pull/7754/files/0c37e6a7..2b5f5927

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7754&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7754&range=11-12

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

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


From aivanov at openjdk.java.net  Wed Apr  6 10:27:13 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 6 Apr 2022 10:27:13 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v13]
In-Reply-To: <CVS-7oiZefVrDpgYDXgHGMoBQfhciocgrUs9LArYvek=.d3d93632-8124-41b7-850a-3efe9d9d4f14@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <CVS-7oiZefVrDpgYDXgHGMoBQfhciocgrUs9LArYvek=.d3d93632-8124-41b7-850a-3efe9d9d4f14@github.com>
Message-ID: <QPr8wWwUv2KuPprIQ_JIbOSPabyFPYqI2CQpiD9kA6k=.ba3320a4-e1fd-4dd9-83b6-d411d459cf62@github.com>

On Wed, 6 Apr 2022 10:24:15 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> Removed the println() line from the Interrupted catch block. Since waitForID() Interrupt indicates completion of Image Loading, println as Interrupt handling was not required.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on Reiview comments

Marked as reviewed by aivanov (Reviewer).

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

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


From aivanov at openjdk.java.net  Wed Apr  6 10:27:15 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 6 Apr 2022 10:27:15 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v12]
In-Reply-To: <0D26zlffXAuaF09r9vyh1idn2Afg7M-CT7zUN1PQCSs=.862da463-2a6b-4176-a5ab-43bd55531567@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <0D26zlffXAuaF09r9vyh1idn2Afg7M-CT7zUN1PQCSs=.862da463-2a6b-4176-a5ab-43bd55531567@github.com>
Message-ID: <L40Ll-c-Ta9mH0v90RjkSOlT91lEDFh8tU-7gPXqmLM=.956096da-2621-4d13-bce3-3dc259c2ba2f@github.com>

On Wed, 6 Apr 2022 09:52:47 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> Removed the println() line from the Interrupted catch block. Since waitForID() Interrupt indicates completion of Image Loading, println as Interrupt handling was not required.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on Reiview comments

test/jdk/javax/swing/ImageIcon/LoadInterruptTest.java line 37:

> 35:  * @bug 8236987
> 36:  * @summary Verifies ImageIcon constructor produces no output when the
> 37:  * thread is interrupted

Suggestion:

 * @summary Verifies ImageIcon constructor produces no output when the
 *          thread is interrupted

I believe this improves the readability of the summary and it's usually formatted like this.

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

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


From aivanov at openjdk.java.net  Wed Apr  6 10:30:42 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 6 Apr 2022 10:30:42 GMT
Subject: Integrated: 8284288: Use SVG images for FocusSpec.html and
 Modality.html
In-Reply-To: <o43HoV5no2fr1X-HBHBkcWS_pGl8WNW4XElrllL_kTI=.1fe4166b-4fa1-4865-817d-52912f811950@github.com>
References: <o43HoV5no2fr1X-HBHBkcWS_pGl8WNW4XElrllL_kTI=.1fe4166b-4fa1-4865-817d-52912f811950@github.com>
Message-ID: <ApUDvfqVDE7DRtaXOwLUL_pisHGGSPJJTPeYaPWBnI8=.ca779ebc-78da-476f-bc58-e691968251f9@github.com>

On Mon, 4 Apr 2022 11:17:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Both `FocusSpec.html` and `Modality.html` use GIF images for diagrams. The images look jagged, especially on High DPI screens which are common now. The images in `Modality.html` use dithered colours which don't look sharp even on regular displays.
> 
> All the modern browsers support SVG which is a vector format and therefore it always looks sharp.
> 
> You can view how the files look after being processed by javadoc:
> 
> - **side-by-side** allows comparing the current and the new images:
>   - [FocusSpec.html](http://cr.openjdk.java.net/~aivanov/8284288/side-by-side/api/java.desktop/java/awt/doc-files/FocusSpec.html)
>   - [Modality.html](http://cr.openjdk.java.net/~aivanov/8284288/side-by-side/api/java.desktop/java/awt/doc-files/Modality.html)
> - **clean** is the final version:
>   - [FocusSpec.html](http://cr.openjdk.java.net/~aivanov/8284288/clean/api/java.desktop/java/awt/doc-files/FocusSpec.html)
>   - [Modality.html](http://cr.openjdk.java.net/~aivanov/8284288/clean/api/java.desktop/java/awt/doc-files/Modality.html)

This pull request has now been integrated.

Changeset: bbe894fc
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bbe894fc815aae9f505b988faaef6b60c8cb8d11
Stats:     946 lines in 15 files changed: 935 ins; 0 del; 11 mod

8284288: Use SVG images for FocusSpec.html and Modality.html

Reviewed-by: prr, serb

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

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


From aivanov at openjdk.java.net  Wed Apr  6 10:42:42 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 6 Apr 2022 10:42:42 GMT
Subject: RFR: 8283712 : Create a manual test framework class [v5]
In-Reply-To: <qbKJqZO3IlieY4GAIW20LjtNYxE3LriYV9yqv6OSyPQ=.f43caf22-7bea-4604-9813-71a4d35f4635@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <qbKJqZO3IlieY4GAIW20LjtNYxE3LriYV9yqv6OSyPQ=.f43caf22-7bea-4604-9813-71a4d35f4635@github.com>
Message-ID: <pFqi_8Dlb0WryGIxBFf0V8BMXe2n54CiFcDkE-GA7qI=.4de19210-b028-4e6a-ae13-26bf7bd0ad5f@github.com>

On Tue, 5 Apr 2022 20:16:28 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
>> 1) Frame which contains test instruction .
>> 2) Pass & Fail button so that user can mark the test pass or fail
>> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
>> 4) Disposing of all the frames.
>> 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed review comments

test/jdk/java/awt/print/PrinterJob/PrintLatinCJKTest.java line 85:

> 83:                 frame.dispose();
> 84:             }
> 85:         });

I just thought whether it's feasible to keep a list of frames / windows to be disposed of inside the `PassFailJFrame` class. It disposes of its instruction frame when the wait is over, it can handle disposing of other frames too.

If I remember correctly, the first version disposed of of all windows. If we make it an explicit list, it shouldn't cause issues.

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

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


From alexey.ivanov at oracle.com  Wed Apr  6 11:11:11 2022
From: alexey.ivanov at oracle.com (Aleksei Ivanov)
Date: Wed, 6 Apr 2022 12:11:11 +0100
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v7]
In-Reply-To: <BL0PR20MB2098F50C04ACFFEC67B24599A11F9@BL0PR20MB2098.namprd20.prod.outlook.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
 <KMPhFqkwAp0rCjmrAJalrI5fMrnj4TqKl1c2UlaSHYI=.edf6eefd-b1f7-4436-9a05-428b4c397c8d@github.com>
 <Ulvn_7XNFmqmZi2k-RHoYpRjuUZWSOZb3L8-sfRSxhI=.6f191b33-b232-4703-aaff-69d7f70ce528@github.com>
 <TK6qR3v443PynS9CgRV_XlXGtO-9m9xSYtJzdy0jsQ8=.d9f7b3a1-0cb2-4662-9e7d-f3e7bf992e9c@github.com>
 <BL0PR20MB2098F50C04ACFFEC67B24599A11F9@BL0PR20MB2098.namprd20.prod.outlook.com>
Message-ID: <4be3ad97-0d6e-357a-ee17-49cd60ae179b@oracle.com>

Hi Eirik,

Thank you for bringing this up.

On 30/03/2022 20:22, Eirik Bakke wrote:
>> In fact, Windows 10 renders titled border flat: one grey line instead of etched border that was used in previous versions. Shall we update Swing's Windows L&F?

Here my point was that the rendering of GroupBox control in Windows has 
changed. Windows used to use an etched border that TitledBorder in Swing 
continues to use. Yet Windows 8.1 and 10 use a single grey line for 
GroupBox control which differs from what Swing uses. As such Windows 
Look and Feel in Swing does not represent native Windows rendering for 
the same kind of thing.

> In the Windows L&F, the following borders all display badly on 150% HiDPI scaling, and would benefit from a fix:
>
> TextField.border, PasswordField.border, FormattedTextField.border, ScrollPane.border, PopupMenu.border, Menu.border, ToolTip.border, as well as the borders for JSpinner and JComboBox.

You're right all the borders are affected. I hope we'll think out a 
common approach to rendering borders which ensures all the edges are of 
the same thickness. Once it's done here for the EtchedBorder, painting 
other borders should be updated as well.

> I once did some work to fix these 150% HiDPI scaling border issues on the NetBeans IDE; see https://github.com/apache/netbeans/pull/1777 and https://github.com/apache/netbeans/pull/2965 and https://github.com/apache/netbeans/blob/master/platform/o.n.swing.plaf/src/org/netbeans/swing/plaf/windows8/Windows8LFCustoms.java

I'll take a closer look at your approach. It could be useful.

> The issue https://bugs.openjdk.java.net/browse/JDK-8241561 is also similar.
>
> Just passing by... thanks for your work on maintaining Swing!
>
> -- Eirik Bakke
> (Committer on the Apache NetBeans project.)

-- 
Regards,
Alexey


From aivanov at openjdk.java.net  Wed Apr  6 11:32:39 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 6 Apr 2022 11:32:39 GMT
Subject: RFR: 8282526: Default icon is not painted properly
In-Reply-To: <ob6enjzx9DmO98H5XHP0w2ND4ZYZEQpJuJoBtr2yrFI=.6466a37d-4cb2-4777-a3ad-dfc71cc01d9e@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <ob6enjzx9DmO98H5XHP0w2ND4ZYZEQpJuJoBtr2yrFI=.6466a37d-4cb2-4777-a3ad-dfc71cc01d9e@github.com>
Message-ID: <KRdvM-ba4dXcGsSjVlH5nLYBzaBI0xVIKfHbpqx-7i0=.bc1eeddc-ed8e-4273-8226-c56f2f2f606d@github.com>

On Thu, 17 Mar 2022 21:55:05 GMT, Phil Race <prr at openjdk.org> wrote:

>> Detect the situation where we do need to perform interpolation during ImageIcon
>> painting and set a hint to the rendering to perform bicubic approximation so
>> image details are preserved during transition.
>
> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 463:
> 
>> 461:         if (hintChanged) {
>> 462:             ((Graphics2D) g).setRenderingHint(RenderingHints.KEY_INTERPOLATION,
>> 463:                     oldHint == null ? RenderingHints.VALUE_INTERPOLATION_NEAREST_NEIGHBOR : oldHint);
> 
> So this is one of only two hints which do not have an "_DEFAULT" value. I don't know why it doesn't.
> 
> Not authoritative but the only place where we currently set this hint and then restore it is here
> share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java
>                 Object oldScaleingHints = g.getRenderingHint(RenderingHints.KEY_INTERPOLATION);
>                 g.setRenderingHint(RenderingHints.KEY_INTERPOLATION,RenderingHints.VALUE_INTERPOLATION_BILINEAR);
>                 ImageScalingHelper.paint(g, 0, 0, w, h, img, insets, dstInsets,
>                         ImageScalingHelper.PaintType.PAINT9_STRETCH, ImageScalingHelper.PAINT_ALL);
>                 g.setRenderingHint(RenderingHints.KEY_INTERPOLATION,
>                     oldScaleingHints!=null?oldScaleingHints:RenderingHints.VALUE_INTERPOLATION_NEAREST_NEIGHBOR);
> 
> if the get() returns null and you aren't happy with that then creating a new Graphics is the only alternative I see.
> 
> 
> But it seems to me there are bigger problems to resolve first
> 
>> Image variant = ((MultiResolutionImage) image).getResolutionVariant(this.width, this.height);
> 
> So getResolutionVariant wants image pixels, but I expect ImageIcon is sized in user-space, isn't it ?
> 
> Don't you need to apply the scale from the Graphics ?
> 
> Next, if we have an exact match for what we want, why  do we need the hint ?
> 
> Next, as Sergey mentions, BICUBIC is expensive.
> Probably how  that should be used is to redraw the image into a cached image that
> is dw= iw*sx and dh= iwh*sy where sx and sy are the graphics scale
> and that is the graphics on which you apply the hint and the graphics is disposed and the restore issue vanishes
> 
> then you can just blit that resulting image so long as the cached dw x dy isn't changed.
> 
> The MR is still useful for finding the best starting image

If I understand correctly, the problem occurs only when the image is scaled down. The test case renders 32?32 icon into 16?16 image.

So is the usage of bicubic interpolation need only when the image is scaled down?

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

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


From djelinski at openjdk.java.net  Wed Apr  6 12:14:11 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 6 Apr 2022 12:14:11 GMT
Subject: RFR: 8284444: Sting typo
Message-ID: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>

This patch adds missing `r` in `string`s

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

Commit messages:
 - Fix sting typo

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

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


From kcr at openjdk.java.net  Wed Apr  6 12:26:40 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 6 Apr 2022 12:26:40 GMT
Subject: RFR: 8284444: Sting typo
In-Reply-To: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
Message-ID: <ATUf-x5e0Zgta3UWTO3VSkrxzr172v0Z-tPAfcP2KNY=.5cb73b01-bbcd-4ab0-a28b-53aad2fb12c1@github.com>

On Wed, 6 Apr 2022 12:07:30 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch adds missing `r` in `string`s

This PR cuts across many areas, so will need multiple reviewers. Regarding the LCMS file, we typically don't make these kind of changes in third-party code, since it will cause our code to diverge from the upstream code, which can lead to merge conflicts down the road. @prrace will need to approve this or else you will need to revert that file.

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

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


From zgu at openjdk.java.net  Wed Apr  6 12:54:42 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 6 Apr 2022 12:54:42 GMT
Subject: RFR: 8284023:
 java.sun.awt.X11GraphicsDevice.getDoubleBufferVisuals() leaks
 XdbeScreenVisualInfo [v2]
In-Reply-To: <4MuA8cH3vrM7CU9fYFzouNf1Wr34zpnSIUNMKL-d2IM=.758d7d53-9bd9-4343-8451-03b3f278ad50@github.com>
References: <6vPxcf3BllwA1Di0WXKrNF9TFKjPnLnfIAuSO8PyV3s=.34ac5f51-a610-4809-9a1e-f822d955340b@github.com>
 <CCn5skshbowp6nFXfQ834A6QPTUXcJHB5RMhmUggpc0=.c5366326-710e-40b7-b0d2-a7da763eb18d@github.com>
 <4MuA8cH3vrM7CU9fYFzouNf1Wr34zpnSIUNMKL-d2IM=.758d7d53-9bd9-4343-8451-03b3f278ad50@github.com>
Message-ID: <Z5SSoZSM45cRrbsz4AzweCIftg0ZzVLjzDWU32dBKYk=.014833ac-5260-4ca8-9eb7-5a482ac37d5d@github.com>

On Wed, 6 Apr 2022 05:20:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @mrserb's comment
>
> Marked as reviewed by serb (Reviewer).

Thanks, @mrserb

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

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


From zgu at openjdk.java.net  Wed Apr  6 12:54:43 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 6 Apr 2022 12:54:43 GMT
Subject: Integrated: 8284023:
 java.sun.awt.X11GraphicsDevice.getDoubleBufferVisuals() leaks
 XdbeScreenVisualInfo
In-Reply-To: <6vPxcf3BllwA1Di0WXKrNF9TFKjPnLnfIAuSO8PyV3s=.34ac5f51-a610-4809-9a1e-f822d955340b@github.com>
References: <6vPxcf3BllwA1Di0WXKrNF9TFKjPnLnfIAuSO8PyV3s=.34ac5f51-a610-4809-9a1e-f822d955340b@github.com>
Message-ID: <Awqdu5T-DEb_N3MQwvael548RvEVHmNnaNs2WyRVQHo=.17fc7c74-58e9-4b6d-b5d0-783e8f24820f@github.com>

On Wed, 30 Mar 2022 19:13:24 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this small patch that fixes memory leak of `XdbeScreenVisualInfo` obtained from `XdbeGetVisualInfo()` method call.
> 
> Test:
> - [x] jdk_awt

This pull request has now been integrated.

Changeset: ec205f68
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ec205f68a883cef6b98f26a06baf675f7da26928
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8284023: java.sun.awt.X11GraphicsDevice.getDoubleBufferVisuals() leaks XdbeScreenVisualInfo

Reviewed-by: prr, serb

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

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


From kcr at openjdk.java.net  Wed Apr  6 13:38:40 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 6 Apr 2022 13:38:40 GMT
Subject: RFR: 8284378: Make Metal the default Java 2D rendering pipeline
 for macOS
In-Reply-To: <Z45KY6DtqGZlf_r5X_CKM_YFP2IZzg48a2s4gI08Kzo=.5e58870d-cd23-4d5f-98c7-f581117a1a4e@github.com>
References: <Z45KY6DtqGZlf_r5X_CKM_YFP2IZzg48a2s4gI08Kzo=.5e58870d-cd23-4d5f-98c7-f581117a1a4e@github.com>
Message-ID: <UidSGmxBK72JUi4ca6Gh0dn04XSRJbJjI9yJjBQsv-4=.888cd801-2d1f-4c05-82b1-b32333b95bac@github.com>

On Wed, 6 Apr 2022 09:48:13 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> This PR makes Metal rendering pipeline as the default Java 2D rendering pipeline for macOS.
> 
> Please refer "JBS Description" for more details.

Marked as reviewed by kcr (Author).

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

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


From aivanov at openjdk.java.net  Wed Apr  6 13:42:41 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 6 Apr 2022 13:42:41 GMT
Subject: RFR: 8284444: Sting typo
In-Reply-To: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
Message-ID: <Ho9UNSLp0gPu5BLKn83SNpGxcoN_MzElX1QabMbNr2o=.e30cd1d0-3cef-438e-87b0-c112956715f6@github.com>

On Wed, 6 Apr 2022 12:07:30 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch adds missing `r` in `string`s

src/java.desktop/share/native/liblcms/cmstypes.c line 3668:

> 3666: // Auxiliary, read an string specified as count + string
> 3667: static
> 3668: cmsBool  ReadCountAndString(struct _cms_typehandler_struct* self, cmsIOHANDLER* io, cmsMLU* mlu, cmsUInt32Number* SizeOfTag, const char* Section)

As @kevinrushforth mentioned, we usually don't modify the source from external libraries. You should report and fix the problem upstream.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties line 63:

> 61: message.creating-association-with-null-extension=Creating association with null extension.
> 62: message.wrong-tool-version=Detected [{0}] version {1} but version {2} is required.
> 63: message.version-string-too-many-components=Version string may have up to 3 components - major.minor.build .

I wonder whether the space before the period is required at the end of the sentence. Perhaps, it's to separate a property name from the end of the sentence.

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

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


From djelinski at openjdk.java.net  Wed Apr  6 14:08:39 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 6 Apr 2022 14:08:39 GMT
Subject: RFR: 8284444: Sting typo
In-Reply-To: <Ho9UNSLp0gPu5BLKn83SNpGxcoN_MzElX1QabMbNr2o=.e30cd1d0-3cef-438e-87b0-c112956715f6@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
 <Ho9UNSLp0gPu5BLKn83SNpGxcoN_MzElX1QabMbNr2o=.e30cd1d0-3cef-438e-87b0-c112956715f6@github.com>
Message-ID: <yFmkSoJ470Lz1n84rWjS-EplRmZeYoZmlLWhJ9dP-E8=.7515de3b-2959-4707-8bfa-6b69976ba51a@github.com>

On Wed, 6 Apr 2022 13:38:03 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This patch adds missing `r` in `string`s
>
> src/java.desktop/share/native/liblcms/cmstypes.c line 3668:
> 
>> 3666: // Auxiliary, read an string specified as count + string
>> 3667: static
>> 3668: cmsBool  ReadCountAndString(struct _cms_typehandler_struct* self, cmsIOHANDLER* io, cmsMLU* mlu, cmsUInt32Number* SizeOfTag, const char* Section)
> 
> As @kevinrushforth mentioned, we usually don't modify the source from external libraries. You should report and fix the problem upstream.

Filed https://github.com/mm2/Little-CMS/pull/313 for this

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

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


From djelinski at openjdk.java.net  Wed Apr  6 14:12:17 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 6 Apr 2022 14:12:17 GMT
Subject: RFR: 8284444: Sting typo [v2]
In-Reply-To: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
Message-ID: <J0QE92iWWFtqKNwRTUDsGrrsHbNFuPlrxx6sPlocVzk=.72a2acc8-02c6-4b0f-b15b-5faf35b904a5@github.com>

> This patch adds missing `r` in `string`s

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

  Revert liblcms changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8125/files
  - new: https://git.openjdk.java.net/jdk/pull/8125/files/755c7084..68ce6ebd

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

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

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


From djelinski at openjdk.java.net  Wed Apr  6 14:15:36 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 6 Apr 2022 14:15:36 GMT
Subject: RFR: 8284444: Sting typo [v2]
In-Reply-To: <Ho9UNSLp0gPu5BLKn83SNpGxcoN_MzElX1QabMbNr2o=.e30cd1d0-3cef-438e-87b0-c112956715f6@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
 <Ho9UNSLp0gPu5BLKn83SNpGxcoN_MzElX1QabMbNr2o=.e30cd1d0-3cef-438e-87b0-c112956715f6@github.com>
Message-ID: <u0NwJ909A2q1TQ2iLb_AsdhkHxEhjloPlxzgywlSV-Y=.b80b77b7-37a8-491a-83b7-7cc85c683f83@github.com>

On Wed, 6 Apr 2022 13:36:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert liblcms changes
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties line 63:
> 
>> 61: message.creating-association-with-null-extension=Creating association with null extension.
>> 62: message.wrong-tool-version=Detected [{0}] version {1} but version {2} is required.
>> 63: message.version-string-too-many-components=Version string may have up to 3 components - major.minor.build .
> 
> I wonder whether the space before the period is required at the end of the sentence. Perhaps, it's to separate a property name from the end of the sentence.

right; without the space the period would appear to be part of the version pattern.

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

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


From avu at openjdk.java.net  Wed Apr  6 14:48:39 2022
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Wed, 6 Apr 2022 14:48:39 GMT
Subject: RFR: 8284378: Make Metal the default Java 2D rendering pipeline
 for macOS
In-Reply-To: <Z45KY6DtqGZlf_r5X_CKM_YFP2IZzg48a2s4gI08Kzo=.5e58870d-cd23-4d5f-98c7-f581117a1a4e@github.com>
References: <Z45KY6DtqGZlf_r5X_CKM_YFP2IZzg48a2s4gI08Kzo=.5e58870d-cd23-4d5f-98c7-f581117a1a4e@github.com>
Message-ID: <qG6tFjDFZF0rBOa7RHhqWTalR96ehdH7T3VDDXqb3RU=.680327d5-43a3-4f53-9ee6-e034561fde47@github.com>

On Wed, 6 Apr 2022 09:48:13 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> This PR makes Metal rendering pipeline as the default Java 2D rendering pipeline for macOS.
> 
> Please refer "JBS Description" for more details.

Reviewed (committer)

Marked as reviewed by avu (Committer).

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

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


From naoto at openjdk.java.net  Wed Apr  6 15:52:37 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 6 Apr 2022 15:52:37 GMT
Subject: RFR: 8284444: Sting typo [v2]
In-Reply-To: <J0QE92iWWFtqKNwRTUDsGrrsHbNFuPlrxx6sPlocVzk=.72a2acc8-02c6-4b0f-b15b-5faf35b904a5@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
 <J0QE92iWWFtqKNwRTUDsGrrsHbNFuPlrxx6sPlocVzk=.72a2acc8-02c6-4b0f-b15b-5faf35b904a5@github.com>
Message-ID: <rWGMDXuXoinhsJTtNT4cXHGxF0fFsxv7KotnVSN0C8g=.3ec7fb35-1b67-4131-8f03-bb89c94a9bfb@github.com>

On Wed, 6 Apr 2022 14:12:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch adds missing `r` in `string`s
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert liblcms changes

src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java line 63:

> 61:  * <a href="http://www.ietf.org/rfc/rfc3454.txt">RFC 3454</a>.
> 62:  * StringPrep prepares Unicode strings for use in network protocols.
> 63:  * Profiles of StringPrep are set of rules and data according to which the

These also come from the upstream ICU4J project and should be corrected there.
https://github.com/unicode-org/icu/blob/4833cc89b2fae2e8863b46bf1dc785964847e882/icu4j/main/classes/core/src/com/ibm/icu/text/StringPrep.java#L27

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

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


From djelinski at openjdk.java.net  Wed Apr  6 16:47:17 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 6 Apr 2022 16:47:17 GMT
Subject: RFR: 8284444: Sting typo [v3]
In-Reply-To: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
Message-ID: <mfXduGQhYNQiQcPkmH3RPK-LCdooqDqxFhmrpCRkpOk=.85876ee8-4321-4b69-9aa0-43375541466c@github.com>

> This patch adds missing `r` in `string`s

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

 - revert xalan changes
 - revert icu changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8125/files
  - new: https://git.openjdk.java.net/jdk/pull/8125/files/68ce6ebd..1ec0314e

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

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

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


From djelinski at openjdk.java.net  Wed Apr  6 16:51:43 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 6 Apr 2022 16:51:43 GMT
Subject: RFR: 8284444: Sting typo [v2]
In-Reply-To: <rWGMDXuXoinhsJTtNT4cXHGxF0fFsxv7KotnVSN0C8g=.3ec7fb35-1b67-4131-8f03-bb89c94a9bfb@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
 <J0QE92iWWFtqKNwRTUDsGrrsHbNFuPlrxx6sPlocVzk=.72a2acc8-02c6-4b0f-b15b-5faf35b904a5@github.com>
 <rWGMDXuXoinhsJTtNT4cXHGxF0fFsxv7KotnVSN0C8g=.3ec7fb35-1b67-4131-8f03-bb89c94a9bfb@github.com>
Message-ID: <To4hp-0Cdlgrk2nc06w2mJbYJiV1wZZmvEEA-upixTs=.a559e0eb-f487-442c-a82b-80c43f481a2b@github.com>

On Wed, 6 Apr 2022 15:49:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert liblcms changes
>
> src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java line 63:
> 
>> 61:  * <a href="http://www.ietf.org/rfc/rfc3454.txt">RFC 3454</a>.
>> 62:  * StringPrep prepares Unicode strings for use in network protocols.
>> 63:  * Profiles of StringPrep are set of rules and data according to which the
> 
> These also come from the upstream ICU4J project and should be corrected there.
> https://github.com/unicode-org/icu/blob/4833cc89b2fae2e8863b46bf1dc785964847e882/icu4j/main/classes/core/src/com/ibm/icu/text/StringPrep.java#L27

Thanks, reverted. Also reverted Xalan changes.

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

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


From naoto at openjdk.java.net  Wed Apr  6 16:55:35 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 6 Apr 2022 16:55:35 GMT
Subject: RFR: 8284444: Sting typo [v2]
In-Reply-To: <To4hp-0Cdlgrk2nc06w2mJbYJiV1wZZmvEEA-upixTs=.a559e0eb-f487-442c-a82b-80c43f481a2b@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
 <J0QE92iWWFtqKNwRTUDsGrrsHbNFuPlrxx6sPlocVzk=.72a2acc8-02c6-4b0f-b15b-5faf35b904a5@github.com>
 <rWGMDXuXoinhsJTtNT4cXHGxF0fFsxv7KotnVSN0C8g=.3ec7fb35-1b67-4131-8f03-bb89c94a9bfb@github.com>
 <To4hp-0Cdlgrk2nc06w2mJbYJiV1wZZmvEEA-upixTs=.a559e0eb-f487-442c-a82b-80c43f481a2b@github.com>
Message-ID: <GNiL7wT_8egSbprPKOkslemEty8HyQP0xthAyCfzRcU=.03f97c53-9fb3-4fa3-9bb2-4ffaec95ad83@github.com>

On Wed, 6 Apr 2022 16:48:38 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java line 63:
>> 
>>> 61:  * <a href="http://www.ietf.org/rfc/rfc3454.txt">RFC 3454</a>.
>>> 62:  * StringPrep prepares Unicode strings for use in network protocols.
>>> 63:  * Profiles of StringPrep are set of rules and data according to which the
>> 
>> These also come from the upstream ICU4J project and should be corrected there.
>> https://github.com/unicode-org/icu/blob/4833cc89b2fae2e8863b46bf1dc785964847e882/icu4j/main/classes/core/src/com/ibm/icu/text/StringPrep.java#L27
>
> Thanks, reverted. Also reverted Xalan changes.

Good. Thanks for reverting it.

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

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


From duke at openjdk.java.net  Wed Apr  6 17:33:37 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Wed, 6 Apr 2022 17:33:37 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v8]
In-Reply-To: <wrQgwI3XG2G9_X8n5n4Q_AzDnMElxB92075XY3bkJMQ=.f5fb8350-489d-44a1-935a-e752b78347cd@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <afJ29wQf2smgANBt5YTQC4oODoch8zxa0YqdtUZDfW8=.f4d0de4d-5245-4491-a8e8-05aaf2a4797a@github.com>
 <gzymK8AsH16kj6YIbJoMuRVGTDkKwLd_O3rbbDZCWIQ=.1f491527-2bac-4e6d-a5cc-f8443bf4f352@github.com>
 <MENhs6_2RTKjMOcWkh1CzumSIwQOy75T_wLac37Vkl8=.0da493e3-d91d-4b48-bd58-f69cefce3a9b@github.com>
 <wrQgwI3XG2G9_X8n5n4Q_AzDnMElxB92075XY3bkJMQ=.f5fb8350-489d-44a1-935a-e752b78347cd@github.com>
Message-ID: <fR3AZPwa0kAz6SJDa5ns4eyyjCIAY_s25IlS2SL2xSw=.c8689931-ded8-448f-8caa-a17b47f7631a@github.com>

On Tue, 5 Apr 2022 16:15:48 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> Also, I see if we start off with "Graphite" accent color then the focus ring is "Graphite" but then even if we change to any other accent color, the focus ring remains "Graphite"
>
> @prsadhuk I was able to replicate the above scenario and as mentioned it oddly happens only when we start with Graphite as accent color. Looking into it further.

The following type properties where checked for cellFocusRing color

- [alternateSelectedControlColor](https://developer.apple.com/documentation/appkit/nscolor/1533135-alternateselectedcontrolcolor) 
**Issue:** Doesn't follow accent color in macos 10.15 and deprecated property.

-  [controlAccentColor](https://developer.apple.com/documentation/appkit/nscolor/3000782-controlaccentcolor) 
**Issue:** Causes build issues due to version compatibility, property supported on only macOS 10.14+

- [accentColor](https://developer.apple.com/documentation/swiftui/color/accentcolor) 
**Issue:** Property supported on only macOS 10.15+, compatibility and run time issues.

- [keyboardfocusindicatorcolor](https://developer.apple.com/documentation/appkit/nscolor/1532031-keyboardfocusindicatorcolor) 
**Issue:** Works well for most of the scenarios (including on-the-fly changes) and follows the accent color changes except when we start the application with accent color set to Graphite and then change accent color on-the-fly (as mentioned above). The cell focus ring remains gray. The issue seems to be with the system color returned by the type-property "**keyboardfocusindicatorcolor**" under this setting.

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

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


From naoto at openjdk.java.net  Wed Apr  6 17:52:08 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 6 Apr 2022 17:52:08 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
Message-ID: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>

This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

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

Commit messages:
 - 8283698: Refactor Locale constructors used in src/test

Changes: https://git.openjdk.java.net/jdk/pull/8130/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8130&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283698
  Stats: 750 lines in 182 files changed: 3 ins; 3 del; 744 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8130.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8130/head:pull/8130

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


From kcr at openjdk.java.net  Wed Apr  6 17:56:40 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 6 Apr 2022 17:56:40 GMT
Subject: RFR: 8284444: Sting typo [v3]
In-Reply-To: <mfXduGQhYNQiQcPkmH3RPK-LCdooqDqxFhmrpCRkpOk=.85876ee8-4321-4b69-9aa0-43375541466c@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
 <mfXduGQhYNQiQcPkmH3RPK-LCdooqDqxFhmrpCRkpOk=.85876ee8-4321-4b69-9aa0-43375541466c@github.com>
Message-ID: <XTfw5IxI7gZ_idvpU_JUUjBvNOgzCnCkSZ6vpIvzdu4=.3a718107-69db-4221-9284-e46196268599@github.com>

On Wed, 6 Apr 2022 16:47:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch adds missing `r` in `string`s
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - revert xalan changes
>  - revert icu changes

The `jpackage` part of the fix looks good.  Btw, there are translated files for 3 other languages (German, Japanese, Simplified Chinese), so I double-checked the translation for each, and they already say "string" (I guess whoever translated it just assumed it was meant to be "string" when they took the English phrase).

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

Marked as reviewed by kcr (Author).

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


From kcr at openjdk.java.net  Wed Apr  6 17:56:40 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 6 Apr 2022 17:56:40 GMT
Subject: RFR: 8284444: Sting typo [v3]
In-Reply-To: <u0NwJ909A2q1TQ2iLb_AsdhkHxEhjloPlxzgywlSV-Y=.b80b77b7-37a8-491a-83b7-7cc85c683f83@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
 <Ho9UNSLp0gPu5BLKn83SNpGxcoN_MzElX1QabMbNr2o=.e30cd1d0-3cef-438e-87b0-c112956715f6@github.com>
 <u0NwJ909A2q1TQ2iLb_AsdhkHxEhjloPlxzgywlSV-Y=.b80b77b7-37a8-491a-83b7-7cc85c683f83@github.com>
Message-ID: <fFvzPNxrHfSm81K92eb6oiGMeOIM3Avzc5tJiQlatd4=.fe9ce9a8-2591-42dd-ba40-657e36635f2d@github.com>

On Wed, 6 Apr 2022 14:12:49 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties line 63:
>> 
>>> 61: message.creating-association-with-null-extension=Creating association with null extension.
>>> 62: message.wrong-tool-version=Detected [{0}] version {1} but version {2} is required.
>>> 63: message.version-string-too-many-components=Version string may have up to 3 components - major.minor.build .
>> 
>> I wonder whether the space before the period is required at the end of the sentence. Perhaps, it's to separate a property name from the end of the sentence.
>
> right; without the space the period would appear to be part of the version pattern.

Yes, I believe this is why it was done.

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

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


From aivanov at openjdk.java.net  Wed Apr  6 18:10:40 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 6 Apr 2022 18:10:40 GMT
Subject: RFR: 8284444: Sting typo [v3]
In-Reply-To: <mfXduGQhYNQiQcPkmH3RPK-LCdooqDqxFhmrpCRkpOk=.85876ee8-4321-4b69-9aa0-43375541466c@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
 <mfXduGQhYNQiQcPkmH3RPK-LCdooqDqxFhmrpCRkpOk=.85876ee8-4321-4b69-9aa0-43375541466c@github.com>
Message-ID: <LRbz8zj9WLGW6iNa-3G2yJpwPlioeVypcdNtbOfD8ow=.48a92624-29ec-4f29-94c9-2688a3c53ce1@github.com>

On Wed, 6 Apr 2022 16:47:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch adds missing `r` in `string`s
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - revert xalan changes
>  - revert icu changes

The changes look fine to me now.  
Yet there are no changes in the client area any more. So you'll have to get additional approvals.

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

Marked as reviewed by aivanov (Reviewer).

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


From kizune at openjdk.java.net  Wed Apr  6 18:18:44 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 6 Apr 2022 18:18:44 GMT
Subject: RFR: 8283387: [macos] a11y : Screen magnifier does not show
 selected Tab
In-Reply-To: <y7Iww920jkklvaraNyRjqImdqLwBoG2XmKP0RKZLQWc=.337e3b81-e7b3-4254-afe1-df5ec649c868@github.com>
References: <V86gocGhD1-irIawpZi-UUzuCuqqbftWbZjVZsYiKZs=.31613701-b994-4d19-a407-dde398f72e61@github.com>
 <y7Iww920jkklvaraNyRjqImdqLwBoG2XmKP0RKZLQWc=.337e3b81-e7b3-4254-afe1-df5ec649c868@github.com>
Message-ID: <aElQ9QWsqpqORk3la_pggWgFumCYCcjdHgCe_4NrbY8=.537cf06e-dc9f-453d-8857-b5787fa71add@github.com>

On Wed, 6 Apr 2022 10:18:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> It is impossible right now to manipulate state of the accessible children of the JTabbedPane via their AccessibleValue and because of that some of the assistive technologies are unable to interact with the parts of the JTabbedPane - namely, buttons, representing the JTabbedPane panel navigation buttons. Magnified is just one of the examples that can be engaging without connecting the hardware such as eye movement tracker.
>> 
>> By adding AccessibleValue to the JTabbedPane children containers we eliminate is problem. And since this inner class is private the standard review should be sufficient, no CSR is required.
>
> test/jdk/javax/accessibility/JTabbedPane/AccessibleTabbedPaneTest.java line 39:
> 
>> 37: public class AccessibleTabbedPaneTest {
>> 38:     public static void main(String[] args) {
>> 39:         JTabbedPane pane = new JTabbedPane();
> 
> Shouldn't this be run on EDT?

I do not see why. I am only working with the data model and only set the data model state trough the appropriate calls, they do not rely on any asynchronous processing or external events.

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

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


From iris at openjdk.java.net  Wed Apr  6 19:36:40 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 6 Apr 2022 19:36:40 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <r5RSuZEt-YT0EOWQmAH1kV7c1apKvBn-ss866xTyF5E=.903a7419-865c-472e-9e20-632d882293e7@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

Marked as reviewed by iris (Reviewer).

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

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


From serb at openjdk.java.net  Wed Apr  6 20:17:40 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 6 Apr 2022 20:17:40 GMT
Subject: RFR: 8283706: Add final or sealed modifier to appropriate
 javax.swing API classes
In-Reply-To: <V6L04fMUKgHOu82Sm8KHJFARu0hB0EF5my4-emPDnWw=.e2cd697d-1cd8-4642-b8ea-2075dd7e0197@github.com>
References: <PfDlBvA6XZ18qqLp21-ZAioRrPXgHeqJ2yUflkmEnK8=.35b6121b-405b-4e80-b933-9ef99a53e084@github.com>
 <WFCnNVLDVUs39mzqFPx9Vt7n9nKwtiGkd3NQxcMvvhc=.e9021d66-6a4c-472c-a531-c16d685d32e0@github.com>
 <V6L04fMUKgHOu82Sm8KHJFARu0hB0EF5my4-emPDnWw=.e2cd697d-1cd8-4642-b8ea-2075dd7e0197@github.com>
Message-ID: <6vGKFgUuy-PH7-CGtxJanp1JaqHlPO-JxX0DmjGJlSA=.c9524b6d-d1e7-44b5-b282-6ff8c4fda1e3@github.com>

On Wed, 6 Apr 2022 05:42:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/GroupLayout.java line 2461:
>> 
>>> 2459:      */
>>> 2460:     public sealed class ParallelGroup extends Group
>>> 2461:          permits BaselineGroup {
>> 
>> The BaselineGroup class is private so not part of the public API, is it fine to mention the non-public class in the permits block for the public class?
>
> Yes, that is fine; javadoc will filter out displaying non-public classes in a permits clause.

Just to double-check, it is fine to have it in the output of the getPermittedSubclasses for the public class as well?

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

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


From mgronlun at openjdk.java.net  Wed Apr  6 20:49:48 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 6 Apr 2022 20:49:48 GMT
Subject: RFR: 8284444: Sting typo [v3]
In-Reply-To: <mfXduGQhYNQiQcPkmH3RPK-LCdooqDqxFhmrpCRkpOk=.85876ee8-4321-4b69-9aa0-43375541466c@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
 <mfXduGQhYNQiQcPkmH3RPK-LCdooqDqxFhmrpCRkpOk=.85876ee8-4321-4b69-9aa0-43375541466c@github.com>
Message-ID: <ladM4OI12K08dMW-meDSPHtyYvpTYyqPG5utW4SW2Cs=.0e568ec8-2b7a-4d26-af34-7baa0808c1f4@github.com>

On Wed, 6 Apr 2022 16:47:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch adds missing `r` in `string`s
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - revert xalan changes
>  - revert icu changes

JFR changes look fine, thank you.

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

Marked as reviewed by mgronlun (Reviewer).

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


From serb at openjdk.java.net  Wed Apr  6 21:19:46 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 6 Apr 2022 21:19:46 GMT
Subject: RFR: 8264666: Reuse Math.multiplyExact/addExact in the
 LCMSImageLayout class
In-Reply-To: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
References: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
Message-ID: <CKwA-J3HlbpW5wQPyE49cgugmOCX6RiH2xFQa9SGJvs=.bab6d6e3-70a1-402c-8454-c93f673c86a8@github.com>

On Fri, 2 Apr 2021 23:02:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> - The hand-crafted methods for addition and multiplication are replaced by the "Math" versions.
> - Cleanup: the usage of do/while(false) is removed

I think the usage of these methods in this class is wrong. Both allow negative values which should not be accepted.

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

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


From aivanov at openjdk.java.net  Wed Apr  6 21:22:47 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 6 Apr 2022 21:22:47 GMT
Subject: RFR: 8283387: [macos] a11y : Screen magnifier does not show
 selected Tab
In-Reply-To: <V86gocGhD1-irIawpZi-UUzuCuqqbftWbZjVZsYiKZs=.31613701-b994-4d19-a407-dde398f72e61@github.com>
References: <V86gocGhD1-irIawpZi-UUzuCuqqbftWbZjVZsYiKZs=.31613701-b994-4d19-a407-dde398f72e61@github.com>
Message-ID: <dXLthppV1XXKosm7csEd9byNMpiRaWLN2_NZ4miXHI0=.90f67786-57fd-4d8f-9373-1c2c438d388c@github.com>

On Wed, 30 Mar 2022 22:21:51 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> It is impossible right now to manipulate state of the accessible children of the JTabbedPane via their AccessibleValue and because of that some of the assistive technologies are unable to interact with the parts of the JTabbedPane - namely, buttons, representing the JTabbedPane panel navigation buttons. Magnified is just one of the examples that can be engaging without connecting the hardware such as eye movement tracker.
> 
> By adding AccessibleValue to the JTabbedPane children containers we eliminate is problem. And since this inner class is private the standard review should be sufficient, no CSR is required.

Marked as reviewed by aivanov (Reviewer).

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

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


From aivanov at openjdk.java.net  Wed Apr  6 21:22:47 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 6 Apr 2022 21:22:47 GMT
Subject: RFR: 8283387: [macos] a11y : Screen magnifier does not show
 selected Tab
In-Reply-To: <aElQ9QWsqpqORk3la_pggWgFumCYCcjdHgCe_4NrbY8=.537cf06e-dc9f-453d-8857-b5787fa71add@github.com>
References: <V86gocGhD1-irIawpZi-UUzuCuqqbftWbZjVZsYiKZs=.31613701-b994-4d19-a407-dde398f72e61@github.com>
 <y7Iww920jkklvaraNyRjqImdqLwBoG2XmKP0RKZLQWc=.337e3b81-e7b3-4254-afe1-df5ec649c868@github.com>
 <aElQ9QWsqpqORk3la_pggWgFumCYCcjdHgCe_4NrbY8=.537cf06e-dc9f-453d-8857-b5787fa71add@github.com>
Message-ID: <zP8XZNkxQ3JI3m0sPmbR0PJSZs46MrtjHoPMEpnm_cg=.db468c59-2093-470b-b8c8-b2d5d1c97ffb@github.com>

On Wed, 6 Apr 2022 18:15:09 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> test/jdk/javax/accessibility/JTabbedPane/AccessibleTabbedPaneTest.java line 39:
>> 
>>> 37: public class AccessibleTabbedPaneTest {
>>> 38:     public static void main(String[] args) {
>>> 39:         JTabbedPane pane = new JTabbedPane();
>> 
>> Shouldn't this be run on EDT?
>
> I do not see why. I am only working with the data model and only set the data model state trough the appropriate calls, they do not rely on any asynchronous processing or external events.

Sounds reasonable.

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

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


From joehw at openjdk.java.net  Thu Apr  7 00:13:45 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 00:13:45 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <O1Wg_OPzPP2kpIzubVLsSjItgPu8tCWg-MuTq4xE_lI=.3b70f0c7-9ba4-4994-9c49-7b45dd8552bf@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81:

> 79: 
> 80:     /**
> 81:      * Parse a name like "fr_FR" into Locale.of("fr", "FR", "");

Locale.France?

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

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


From joehw at openjdk.java.net  Thu Apr  7 00:20:31 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 00:20:31 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <oWowG5ZF6uQhqEOWoDSp17TbGHZqZjmcaxL_5_yGxuU=.b7e9daaf-b3eb-4620-a0a6-01635f37e8ec@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

test/jdk/java/text/Format/DateFormat/NonGregorianFormatTest.java line 131:

> 129: 
> 130:         // Tests with the Japanese imperial calendar
> 131:         Locale calendarLocale = Locale.of("ja", "JP", "JP");

Locale.JAPAN?

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

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


From joehw at openjdk.java.net  Thu Apr  7 00:31:55 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 00:31:55 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <UYhQLIeSUDpGNeR1pFuD9ll9SIPZFAnzvRiX-rft8f8=.bdb3a956-ca7a-4523-87d6-71e9a12e5a76@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63:

> 61:             Locale.of("it", "IT", "EURO"),
> 62:             Locale.forLanguageTag("de-AT"),
> 63:             Locale.forLanguageTag("fr-CH"),

Use the new factory? Ok not to change as these are tests and there are too many of them. It's not deprecated anyways.

test/jdk/java/text/Format/common/Bug6215962.java line 58:

> 56:         check(mf1, mf2, false);
> 57: 
> 58:         mf1 = new MessageFormat("{0}", Locale.of("ja", "JP"));

Locale.JAPAN?

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

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


From naoto at openjdk.java.net  Thu Apr  7 01:19:35 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 7 Apr 2022 01:19:35 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <O1Wg_OPzPP2kpIzubVLsSjItgPu8tCWg-MuTq4xE_lI=.3b70f0c7-9ba4-4994-9c49-7b45dd8552bf@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
 <O1Wg_OPzPP2kpIzubVLsSjItgPu8tCWg-MuTq4xE_lI=.3b70f0c7-9ba4-4994-9c49-7b45dd8552bf@github.com>
Message-ID: <aku2mIBBVnzFO3xr6BEuEc0Q1_Ad1X2sM3-vTOb0xbI=.4ea9ba22-e75d-4bcb-8942-96767c384f9f@github.com>

On Thu, 7 Apr 2022 00:09:58 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.
>
> test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81:
> 
>> 79: 
>> 80:     /**
>> 81:      * Parse a name like "fr_FR" into Locale.of("fr", "FR", "");
> 
> Locale.France?

The test code parses the input string (eg. "fr_FR") into 3 elements, `name`, `country`, and `variant`, then create a `Locale` using those 3 elements. Changing it to `Locale.FRANCE` does not seem right here.

> test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63:
> 
>> 61:             Locale.of("it", "IT", "EURO"),
>> 62:             Locale.forLanguageTag("de-AT"),
>> 63:             Locale.forLanguageTag("fr-CH"),
> 
> Use the new factory? Ok not to change as these are tests and there are too many of them. It's not deprecated anyways.

`Locale.forLanguageTag()` is a preferred way to create a `Locale`, as it validates the input language tag, while `Locale.of()` doesn't as well as Locale constructors.

> test/jdk/java/text/Format/common/Bug6215962.java line 58:
> 
>> 56:         check(mf1, mf2, false);
>> 57: 
>> 58:         mf1 = new MessageFormat("{0}", Locale.of("ja", "JP"));
> 
> Locale.JAPAN?

The test intends to compare the generated `MessageFormat` objects (`mf2` & `mf1`) from using a constant `Locale.JAPAN` and the factory method. So I believe leaving it as `Locale.of()` makes sense.

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

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


From kizune at openjdk.java.net  Thu Apr  7 04:04:47 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 7 Apr 2022 04:04:47 GMT
Subject: Integrated: 8283387: [macos] a11y : Screen magnifier does not show
 selected Tab
In-Reply-To: <V86gocGhD1-irIawpZi-UUzuCuqqbftWbZjVZsYiKZs=.31613701-b994-4d19-a407-dde398f72e61@github.com>
References: <V86gocGhD1-irIawpZi-UUzuCuqqbftWbZjVZsYiKZs=.31613701-b994-4d19-a407-dde398f72e61@github.com>
Message-ID: <gf3W_H1KwbSO_8VHqi5Q-A0P_EedZ0ISxGYYHHEtl1M=.569f635b-31e8-4453-9047-ccf901e5a4b2@github.com>

On Wed, 30 Mar 2022 22:21:51 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> It is impossible right now to manipulate state of the accessible children of the JTabbedPane via their AccessibleValue and because of that some of the assistive technologies are unable to interact with the parts of the JTabbedPane - namely, buttons, representing the JTabbedPane panel navigation buttons. Magnified is just one of the examples that can be engaging without connecting the hardware such as eye movement tracker.
> 
> By adding AccessibleValue to the JTabbedPane children containers we eliminate is problem. And since this inner class is private the standard review should be sufficient, no CSR is required.

This pull request has now been integrated.

Changeset: d5cd4a3a
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d5cd4a3a28a85bbcaa3c0c7f2e74e0684b5efcab
Stats:     113 lines in 2 files changed: 110 ins; 1 del; 2 mod

8283387: [macos] a11y : Screen magnifier does not show selected Tab

Reviewed-by: prr, aivanov

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

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


From darcy at openjdk.java.net  Thu Apr  7 04:46:40 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 7 Apr 2022 04:46:40 GMT
Subject: RFR: 8283706: Add final or sealed modifier to appropriate
 javax.swing API classes
In-Reply-To: <6vGKFgUuy-PH7-CGtxJanp1JaqHlPO-JxX0DmjGJlSA=.c9524b6d-d1e7-44b5-b282-6ff8c4fda1e3@github.com>
References: <PfDlBvA6XZ18qqLp21-ZAioRrPXgHeqJ2yUflkmEnK8=.35b6121b-405b-4e80-b933-9ef99a53e084@github.com>
 <WFCnNVLDVUs39mzqFPx9Vt7n9nKwtiGkd3NQxcMvvhc=.e9021d66-6a4c-472c-a531-c16d685d32e0@github.com>
 <V6L04fMUKgHOu82Sm8KHJFARu0hB0EF5my4-emPDnWw=.e2cd697d-1cd8-4642-b8ea-2075dd7e0197@github.com>
 <6vGKFgUuy-PH7-CGtxJanp1JaqHlPO-JxX0DmjGJlSA=.c9524b6d-d1e7-44b5-b282-6ff8c4fda1e3@github.com>
Message-ID: <7HmnDkG_EwJnoRtTXJL38rK5a5UGFmedVjXfF8L3HZM=.588aa464-fb18-4a77-82e6-9307693e7058@github.com>

On Wed, 6 Apr 2022 20:14:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Yes, that is fine; javadoc will filter out displaying non-public classes in a permits clause.
>
> Just to double-check, it is fine to have it in the output of the getPermittedSubclasses for the public class as well?

I'm not certain what question you are asking. If the question is, is it fine for core reflection to return non-public information about the class, in general sure. For example, in jshell evaluating
StringBuilder.class.getSuperclass()
will yield
 class java.lang.AbstractStringBuilder
which is the non-public superclass of StringBuffer and StringBuilder.

If the question is, do the compatibility expectations of the platform include such visible non-public implementation artifacts? The answer is no; it is fine for those details to evolve and users shouldn't rely on them.

Is there another aspect of the change that was a concern?

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

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


From joehw at openjdk.java.net  Thu Apr  7 04:51:38 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 04:51:38 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <aku2mIBBVnzFO3xr6BEuEc0Q1_Ad1X2sM3-vTOb0xbI=.4ea9ba22-e75d-4bcb-8942-96767c384f9f@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
 <O1Wg_OPzPP2kpIzubVLsSjItgPu8tCWg-MuTq4xE_lI=.3b70f0c7-9ba4-4994-9c49-7b45dd8552bf@github.com>
 <aku2mIBBVnzFO3xr6BEuEc0Q1_Ad1X2sM3-vTOb0xbI=.4ea9ba22-e75d-4bcb-8942-96767c384f9f@github.com>
Message-ID: <0Zxp9nACKCy12wn8Viwd5lYHz3KXojuy02cZLiz8Wiw=.f1a9f3b3-8cfb-4845-87e7-bef9b69ada8a@github.com>

On Thu, 7 Apr 2022 01:16:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81:
>> 
>>> 79: 
>>> 80:     /**
>>> 81:      * Parse a name like "fr_FR" into Locale.of("fr", "FR", "");
>> 
>> Locale.France?
>
> The test code parses the input string (eg. "fr_FR") into 3 elements, `name`, `country`, and `variant`, then create a `Locale` using those 3 elements. Changing it to `Locale.FRANCE` does not seem right here.

I see.

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

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


From joehw at openjdk.java.net  Thu Apr  7 04:59:40 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 04:59:40 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <aku2mIBBVnzFO3xr6BEuEc0Q1_Ad1X2sM3-vTOb0xbI=.4ea9ba22-e75d-4bcb-8942-96767c384f9f@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
 <O1Wg_OPzPP2kpIzubVLsSjItgPu8tCWg-MuTq4xE_lI=.3b70f0c7-9ba4-4994-9c49-7b45dd8552bf@github.com>
 <aku2mIBBVnzFO3xr6BEuEc0Q1_Ad1X2sM3-vTOb0xbI=.4ea9ba22-e75d-4bcb-8942-96767c384f9f@github.com>
Message-ID: <VhDD3losQJHv-SpTfyDeEG5Jb3lX9kYSQ9CoOMD2YIU=.47de2cb7-1289-4f2d-8648-c75320e44ac9@github.com>

On Thu, 7 Apr 2022 01:16:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63:
>> 
>>> 61:             Locale.of("it", "IT", "EURO"),
>>> 62:             Locale.forLanguageTag("de-AT"),
>>> 63:             Locale.forLanguageTag("fr-CH"),
>> 
>> Use the new factory? Ok not to change as these are tests and there are too many of them. It's not deprecated anyways.
>
> `Locale.forLanguageTag()` is a preferred way to create a `Locale`, as it validates the input language tag, while `Locale.of()` doesn't as well as Locale constructors.

Ok, I didn't realize the existing method is preferred over the new method in creating a Locale. The javadoc does state that it does not make any syntactic checks. That's good to know.

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

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


From joehw at openjdk.java.net  Thu Apr  7 04:59:39 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 04:59:39 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <c7WnJL_FTC92jBi5LhA8s1EA-5LMgBW7ucldQb0GQVk=.aa5aa4d7-07a4-4f44-ab61-e89f54adb1ec@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

Marked as reviewed by joehw (Reviewer).

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

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


From smandalika at openjdk.java.net  Thu Apr  7 06:48:29 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Thu, 7 Apr 2022 06:48:29 GMT
Subject: RFR: JDK-8282933: Create a test for JDK-4529616 [v3]
In-Reply-To: <3d_szd4R6oyDqof-g7sLsV_wkAzuEuma-aXiiUZ03Zw=.6579f560-f11e-4bea-a292-dfcee111a246@github.com>
References: <3d_szd4R6oyDqof-g7sLsV_wkAzuEuma-aXiiUZ03Zw=.6579f560-f11e-4bea-a292-dfcee111a246@github.com>
Message-ID: <yjb3PlA7c3vnfHpTTg3Y6kJBRc1ax7Vii_3aaGomiHQ=.1b0d395c-768d-40cc-9881-04d17d13bb36@github.com>

> JDK-8282933: Create a test for JDK-4529616 
> AccessibleJTableCell.isShowing() returns false when the cell is actually on
> the screen.
> The test validates the fix for the above issue by verifying that the isShowing call returns true when invoked via the  accessiblity context.
> This review is for migrating tests from a closed test suite to open.

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

  JTable access on EDT, 80 chars line

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7783/files
  - new: https://git.openjdk.java.net/jdk/pull/7783/files/787ad251..83fefbdf

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

  Stats: 26 lines in 1 file changed: 14 ins; 4 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7783.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7783/head:pull/7783

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


From smandalika at openjdk.java.net  Thu Apr  7 07:02:18 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Thu, 7 Apr 2022 07:02:18 GMT
Subject: RFR: JDK-8282933: Create a test for JDK-4529616 [v4]
In-Reply-To: <3d_szd4R6oyDqof-g7sLsV_wkAzuEuma-aXiiUZ03Zw=.6579f560-f11e-4bea-a292-dfcee111a246@github.com>
References: <3d_szd4R6oyDqof-g7sLsV_wkAzuEuma-aXiiUZ03Zw=.6579f560-f11e-4bea-a292-dfcee111a246@github.com>
Message-ID: <H2pSp3zG5j_dE6MBWYMTfLlKdBxJBhlaq3rmlwptvdY=.5f6096c0-efd9-465f-b69a-0de8dc6333d8@github.com>

> JDK-8282933: Create a test for JDK-4529616 
> AccessibleJTableCell.isShowing() returns false when the cell is actually on
> the screen.
> The test validates the fix for the above issue by verifying that the isShowing call returns true when invoked via the  accessiblity context.
> This review is for migrating tests from a closed test suite to open.

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

  8282933: Whitespace issue fixed

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7783/files
  - new: https://git.openjdk.java.net/jdk/pull/7783/files/83fefbdf..97d12e9e

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

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

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


From smandalika at openjdk.java.net  Thu Apr  7 07:52:11 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Thu, 7 Apr 2022 07:52:11 GMT
Subject: RFR: 8284077: Create an automated test for JDK-4170173
Message-ID: <8iul_waSMDD6G1oVVmwPtW89ihAc6YoMFrTR1-XFmmw=.7802104e-60cb-4b90-9ef5-cc479d3f5a78@github.com>

Create an automated test for [JDK-4170173](https://bugs.openjdk.java.net/browse/JDK-4170173)

Issue
JTextComponent.AccessibleJTextComponent.getAfterIndex(int part, int index) works incorrectly, when 'part' parameter is AccessibleText.WORD.
It returns a space (" ") instead of the correct word.

The test verifies the fix for this behavior by checking the getAfterIndex for AccessibleText.CHARACTER,AccessibleText.WORD,AccessibleText.SENTENCE for the components JTextField, JTextArea, JEditorPane.

While working on this test case there was a related bug relevant to this [JDK-4170174](https://bugs.openjdk.java.net/browse/JDK-4170174) 
This is marked as duplicate, addressess a similar issue.
It indicates that JTextComponent.AccessibleJTextComponent.getBeforeIndex(int part, int index) works incorrectly, when part parameter is AccessibleText.WORD.
It returns a space (" ") instead of correct word.

Hence an additional test was added for this, for verifying the behavior of getBeforeIndex.
AccessibleText.CHARACTER,AccessibleText.WORD,AccessibleText.SENTENCE for the components JTextField, JTextArea, JEditorPane.

The two tests have multiple distinct assertions. For this reason, as well as for maintainability, the two were not clubbed into a single test.
However, the two tests are still similar in the functional flow of the code and the functionality they are testing as well - hence they have been clubbed into a single review.
This review is for migrating tests from a closed test suite to open.

Testing:
The tests ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

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

Commit messages:
 - 8284077: Create an automated test for JDK-4170173
 - 8284077: Create an automated test for JDK-4170173

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

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


From smandalika at openjdk.java.net  Thu Apr  7 08:18:21 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Thu, 7 Apr 2022 08:18:21 GMT
Subject: RFR: 8283245: Create a test for JDK-4670319 [v2]
In-Reply-To: <UrqPfkc5gtakuM1_5bjMxwABKOHUxG5NwTkKpjpFvIk=.3957d27d-ddbe-4aad-aefe-0a3748aca560@github.com>
References: <UrqPfkc5gtakuM1_5bjMxwABKOHUxG5NwTkKpjpFvIk=.3957d27d-ddbe-4aad-aefe-0a3748aca560@github.com>
Message-ID: <_N3uh9GNNdLPg-kiacOdc2fEJJeeBdhRM644g_CsV0s=.90175acf-34bf-4db7-a107-469a8611cbdf@github.com>

> Write an automated regression test for  JDK-4670319
> 
> Issue
> When a JTree node is expanded or collapsed, an Accessibility PropertyChange event is fired with the old state of "collapsed" and new state of "expanded" (or vice versa). The problem is that the source of the event is the AccessibeJTree, and not the AccessibleJTreeNode. This means that an assistive technology listening to this event is unable to report to the user what node was expanded/collapsed.
> 
> Fix
> Fix for [JDK-4670319](https://bugs.openjdk.java.net/browse/JDK-4670319) addresses the above issue.  When tree node is expanded/collapsed, PropertyChangeEventSource is the Node.
> This review is for a test for validating the above issue.
> 
> This review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

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

 - Review Comments Fixed: 80 characters line fixed, typo in File Name fixed
 - Review Comments Fixed: 80 characters line fixed, typo in File Name fixed

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8012/files
  - new: https://git.openjdk.java.net/jdk/pull/8012/files/9e8c392c..75ed8f6a

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

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

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


From psadhukhan at openjdk.java.net  Thu Apr  7 09:16:43 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 7 Apr 2022 09:16:43 GMT
Subject: Integrated: 8284166: [macos] Replace deprecated
 alternateSelectedControlColor with selectedContentBackgroundColor
In-Reply-To: <eOwA9OZLbmDeS0uHc4bN8PHWzfgbZekadT4x9Zw1-b4=.55253c3e-2011-4523-ae2d-bdb757af0c2e@github.com>
References: <eOwA9OZLbmDeS0uHc4bN8PHWzfgbZekadT4x9Zw1-b4=.55253c3e-2011-4523-ae2d-bdb757af0c2e@github.com>
Message-ID: <i6p-kDt7oBFsgEps3fqirPEX78NLmIFDmAUG6SRHujM=.e85c3fe4-2b3a-4eba-bcda-a573bd7b858c@github.com>

On Fri, 1 Apr 2022 09:39:05 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> [alternateSelectedControlColor](https://developer.apple.com/documentation/appkit/nscolor/1533135-alternateselectedcontrolcolor?language=objc) is deprecated since osx10.14 so we need to replace with its alternative "[selectedContentBackgroundColor](https://developer.apple.com/documentation/appkit/nscolor/2998830-selectedcontentbackgroundcolor?language=objc)"
> Since our minimum supported deployment target is still [10.12](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags.m4#L139)
> we need to use "@available" check to use the deprecated property on older targets
> Background color check is ok and also open,closed jtreg run is green

This pull request has now been integrated.

Changeset: 19288654
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/192886546bf86c9a577b2dfaa4b33cb94799659b
Stats:     6 lines in 1 file changed: 4 ins; 0 del; 2 mod

8284166: [macos] Replace deprecated alternateSelectedControlColor with selectedContentBackgroundColor

Reviewed-by: prr

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

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


From psadhukhan at openjdk.java.net  Thu Apr  7 09:45:08 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 7 Apr 2022 09:45:08 GMT
Subject: RFR: 8257810: Only First page are printed in
 JTable.scrollRectToVisible
Message-ID: <HpEmX1DI9Q4PvHQIntUEknVW8jlIWQFXHuB1XgJlh40=.f7726194-7aad-4422-a8db-c02bbad0d110@github.com>

Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. 
This is because when the table is scrolled down to last page, the bounds.y becomes -ve 
[x=0,y=-15260,width=968,height=16000]
so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296]
but subsequent pages clip 
[[x=0,y=1296,width=968,height=1296], 
[x=0,y=2592,width=968,height=1296], 
[x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed

This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI
We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907

Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS)

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

Commit messages:
 - Fix
 - Fix
 - 8257810: Only First page are printed in JTable.scrollRectToVisible

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

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


From duke at openjdk.java.net  Thu Apr  7 10:26:20 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Thu, 7 Apr 2022 10:26:20 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v2]
In-Reply-To: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
Message-ID: <_UplvB0h9bWCInEGLRAN4bN3_sMypgu0hf0nU57pJgI=.8eef0557-500c-4939-b00f-ae9c0dd5a5b8@github.com>

> getText function returned extra endOfLine when appended. The reason was in `EditorEditorKit` class, `write(Writer out, Document doc, int pos, int len)` method, where translation happens from buffer to Out(Writer Object) if endOfLine is other than '\n' ( which is '\r\n' in windows). In order to write each line till End of line, the string till '\n' is written including '\r' and again endOfLine is written which results in extra Carriage Return. To solve this issue, a Condition is added which checks if previous character to '\n' is '\r', if true then whole string except Carriage Return ('\r') is written, else whole string till before '\n' is written.

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

  Added Test Case - ChangeStyleAndAppend.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8122/files
  - new: https://git.openjdk.java.net/jdk/pull/8122/files/89935491..953fec43

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

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

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


From aivanov at openjdk.java.net  Thu Apr  7 11:22:55 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 7 Apr 2022 11:22:55 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v2]
In-Reply-To: <_UplvB0h9bWCInEGLRAN4bN3_sMypgu0hf0nU57pJgI=.8eef0557-500c-4939-b00f-ae9c0dd5a5b8@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <_UplvB0h9bWCInEGLRAN4bN3_sMypgu0hf0nU57pJgI=.8eef0557-500c-4939-b00f-ae9c0dd5a5b8@github.com>
Message-ID: <p1lJJBIqQpVg6kwYcdWaFsZbLIfE0AkN3Tyl3gXmakE=.98fff17e-812b-4f8b-97b6-4bc61e45ce03@github.com>

On Thu, 7 Apr 2022 10:26:20 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> getText function returned extra endOfLine when appended. The reason was in `EditorEditorKit` class, `write(Writer out, Document doc, int pos, int len)` method, where translation happens from buffer to Out(Writer Object) if endOfLine is other than '\n' ( which is '\r\n' in windows). In order to write each line till End of line, the string till '\n' is written including '\r' and again endOfLine is written which results in extra Carriage Return. To solve this issue, a Condition is added which checks if previous character to '\n' is '\r', if true then whole string except Carriage Return ('\r') is written, else whole string till before '\n' is written.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added Test Case - ChangeStyleAndAppend.java

Why can't the test be automatic?

You're modifying the contents of a `JTextPane` via `Document`. You can easily get the text from it and verify it has no unexpected new lines.

Please follow Java Coding Style in the product code where the added lines don't fit well into the surrounding code style as well as in the test code.

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

Changes requested by aivanov (Reviewer).

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


From mvs at openjdk.java.net  Thu Apr  7 11:42:12 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Thu, 7 Apr 2022 11:42:12 GMT
Subject: RFR: 8284521: Write an automated regression test for RFE 4371575
Message-ID: <FgW8JkNC98cWCRNm8Tpsu75-EYCzO2wP4X-sM9rDkZs=.f66039d3-903b-42b3-b2f4-3af624d6fd4b@github.com>

Write an automated regression test for [JDK-4371575](https://bugs.openjdk.java.net/browse/JDK-4371575)

Issue:
As part of the Merlin focus project, JComponent.setRequestFocusEnabled was
deprecated and its implementation was changed to map exactly to the new
method Component.setFocusable. Scott believes that the old behavior may be
preferable. He would like to be able to specify that a Component is focusable,
and should receive focus during keyboard traversal, but that it should not
automatically take focus when the user clicks on it with the mouse.

We are concerned that the accessibility team would be against this behavior,
and this also seems like more of a PLAF issue. Nevertheless, we should look
into it before beta ships.

Fix:
After some discussion we decided that the best balance of the old and new would be to make this an advisory property. This property will not be synonymous with focusable. Instead our mouse listeners will check this property before requesting focus. This provides as closely as possible the old behavior, while allowing people to use the new focusable property if they don't want a component focusable at all.

Testing:
Tested in mach5, 10 times with all the 3 available platform like macosx, windows and linux and got all Pass.

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

Commit messages:
 - 8284521: Write an automated regression test for RFE 4371575

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

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


From aivanov at openjdk.java.net  Thu Apr  7 11:51:39 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 7 Apr 2022 11:51:39 GMT
Subject: RFR: 8257810: Only First page are printed in
 JTable.scrollRectToVisible
In-Reply-To: <HpEmX1DI9Q4PvHQIntUEknVW8jlIWQFXHuB1XgJlh40=.f7726194-7aad-4422-a8db-c02bbad0d110@github.com>
References: <HpEmX1DI9Q4PvHQIntUEknVW8jlIWQFXHuB1XgJlh40=.f7726194-7aad-4422-a8db-c02bbad0d110@github.com>
Message-ID: <cciqFiVdOHgDVEW43twiGDxzahKU5eM7NUfzgUvDjKg=.f5531d78-e691-47d2-8693-0278c38965b4@github.com>

On Thu, 7 Apr 2022 09:17:02 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. 
> This is because when the table is scrolled down to last page, the bounds.y becomes -ve 
> [x=0,y=-15260,width=968,height=16000]
> so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296]
> but subsequent pages clip 
> [[x=0,y=1296,width=968,height=1296], 
> [x=0,y=2592,width=968,height=1296], 
> [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed
> 
> This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI
> We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907
> 
> Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS)

test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 53:

> 51:         PrintAllPages test = new PrintAllPages(latch);
> 52:         Thread T1 = new Thread(test);
> 53:         T1.start();

I wonder why you need another thread to create UI. You can create UI from calling `invokeAndWait` from main thread as it's usually done and then start to wait on the latch.

The two classes can be merged into one.

test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 61:

> 59:         } catch (InterruptedException ie) {
> 60:             throw ie;
> 61:         }

The catch block does nothing but re-throws the exception. Thus, it can be removed.

test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 63:

> 61:         }
> 62:         if (!ret) {
> 63:             test.dispose();

Why isn't `test.dispose()` called when the test pass?

If `latch.await` is interrupted, the test isn't disposed.

And UI should be disposed of on EDT.

test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 126:

> 124:                     Rectangle bounds = super.getBounds();
> 125:                     return bounds;
> 126:                 }

Is this overridden method used by any means?

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

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


From psadhukhan at openjdk.java.net  Thu Apr  7 13:35:26 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 7 Apr 2022 13:35:26 GMT
Subject: RFR: 8257810: Only First page are printed in
 JTable.scrollRectToVisible [v2]
In-Reply-To: <HpEmX1DI9Q4PvHQIntUEknVW8jlIWQFXHuB1XgJlh40=.f7726194-7aad-4422-a8db-c02bbad0d110@github.com>
References: <HpEmX1DI9Q4PvHQIntUEknVW8jlIWQFXHuB1XgJlh40=.f7726194-7aad-4422-a8db-c02bbad0d110@github.com>
Message-ID: <_Iv-nTdzxxYLQ-Ef82BJ69ZhTIHcmSvNYYruixg93KU=.2629e3a8-1b53-4a8a-9f91-369c82f17129@github.com>

> Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. 
> This is because when the table is scrolled down to last page, the bounds.y becomes -ve 
> [x=0,y=-15260,width=968,height=16000]
> so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296]
> but subsequent pages clip 
> [[x=0,y=1296,width=968,height=1296], 
> [x=0,y=2592,width=968,height=1296], 
> [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed
> 
> This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI
> We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907
> 
> Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS)

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

 - Test updated
 - Test updated

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8141/files
  - new: https://git.openjdk.java.net/jdk/pull/8141/files/7a3bd740..f1c8082d

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

  Stats: 171 lines in 1 file changed: 55 ins; 85 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8141.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8141/head:pull/8141

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


From psadhukhan at openjdk.java.net  Thu Apr  7 13:35:27 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 7 Apr 2022 13:35:27 GMT
Subject: RFR: 8257810: Only First page are printed in
 JTable.scrollRectToVisible [v2]
In-Reply-To: <cciqFiVdOHgDVEW43twiGDxzahKU5eM7NUfzgUvDjKg=.f5531d78-e691-47d2-8693-0278c38965b4@github.com>
References: <HpEmX1DI9Q4PvHQIntUEknVW8jlIWQFXHuB1XgJlh40=.f7726194-7aad-4422-a8db-c02bbad0d110@github.com>
 <cciqFiVdOHgDVEW43twiGDxzahKU5eM7NUfzgUvDjKg=.f5531d78-e691-47d2-8693-0278c38965b4@github.com>
Message-ID: <XeVwRoVy9gjWlKM5g6xf7rRS0VbZ_E4w1XSuJRE9wBE=.311ecf9f-6670-4e0e-91c5-f6728a9ebc01@github.com>

On Thu, 7 Apr 2022 11:48:19 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Test updated
>>  - Test updated
>
> test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 53:
> 
>> 51:         PrintAllPages test = new PrintAllPages(latch);
>> 52:         Thread T1 = new Thread(test);
>> 53:         T1.start();
> 
> I wonder why you need another thread to create UI. You can create UI from calling `invokeAndWait` from main thread as it's usually done and then start to wait on the latch.
> 
> The two classes can be merged into one.

I followed the manual test I created for other printing related tests but anyways I have updated as per suggestions.

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

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


From djelinski at openjdk.java.net  Thu Apr  7 14:58:43 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 7 Apr 2022 14:58:43 GMT
Subject: Integrated: 8284444: Sting typo
In-Reply-To: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
Message-ID: <DLTDZ2b9bR7P6zsb0sW9B66BYoCBNu2PLj9iQ7k9Igc=.ec1a801a-c6f8-44f4-9706-44954c74e0fa@github.com>

On Wed, 6 Apr 2022 12:07:30 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch adds missing `r` in `string`s

This pull request has now been integrated.

Changeset: 5bafcfdc
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5bafcfdc171b5a514ecf620703e77fa2f4a49c58
Stats:     10 lines in 5 files changed: 0 ins; 0 del; 10 mod

8284444: Sting typo

Reviewed-by: kcr, aivanov, mgronlun

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

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


From psadhukhan at openjdk.java.net  Thu Apr  7 14:59:38 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 7 Apr 2022 14:59:38 GMT
Subject: RFR: 8257810: Only First page are printed in
 JTable.scrollRectToVisible [v3]
In-Reply-To: <HpEmX1DI9Q4PvHQIntUEknVW8jlIWQFXHuB1XgJlh40=.f7726194-7aad-4422-a8db-c02bbad0d110@github.com>
References: <HpEmX1DI9Q4PvHQIntUEknVW8jlIWQFXHuB1XgJlh40=.f7726194-7aad-4422-a8db-c02bbad0d110@github.com>
Message-ID: <uWPCjkGRnWtTamjvYAZctXEN7deGgcVOfox-cELdY_Y=.8f79a1e1-3ce5-405a-9693-625dc9705335@github.com>

> Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. 
> This is because when the table is scrolled down to last page, the bounds.y becomes -ve 
> [x=0,y=-15260,width=968,height=16000]
> so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296]
> but subsequent pages clip 
> [[x=0,y=1296,width=968,height=1296], 
> [x=0,y=2592,width=968,height=1296], 
> [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed
> 
> This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI
> We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907
> 
> Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS)

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

  Test updated

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8141/files
  - new: https://git.openjdk.java.net/jdk/pull/8141/files/f1c8082d..635b90aa

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

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

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


From duke at openjdk.java.net  Thu Apr  7 15:09:27 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 7 Apr 2022 15:09:27 GMT
Subject: RFR: 8284535 : Fix PrintLatinCJKTest.java test that is failing
 with Parse Exception [v6]
In-Reply-To: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
Message-ID: <jRQUt_Gl2j40pMIM7-8I-t65tojV2xvsfqUE3Bszsx0=.bd28654a-b226-4a48-985b-a3d2187ba75d@github.com>

> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
> 1) Frame which contains test instruction .
> 2) Pass & Fail button so that user can mark the test pass or fail
> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
> 4) Disposing of all the frames.
> 
> @aivanov-jdk

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

  8284535 : Fix PrintLatinCJKTest.java test that is failing with Parse Exception

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7966/files
  - new: https://git.openjdk.java.net/jdk/pull/7966/files/8e8feff5..a10ac21b

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

  Stats: 192 lines in 2 files changed: 129 ins; 13 del; 50 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7966.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7966/head:pull/7966

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


From duke at openjdk.java.net  Thu Apr  7 15:09:27 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 7 Apr 2022 15:09:27 GMT
Subject: RFR: 8284535 : Fix PrintLatinCJKTest.java test that is failing
 with Parse Exception [v5]
In-Reply-To: <qbKJqZO3IlieY4GAIW20LjtNYxE3LriYV9yqv6OSyPQ=.f43caf22-7bea-4604-9813-71a4d35f4635@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <qbKJqZO3IlieY4GAIW20LjtNYxE3LriYV9yqv6OSyPQ=.f43caf22-7bea-4604-9813-71a4d35f4635@github.com>
Message-ID: <7a2E0wVs_CG6Y2PEFxjDauZRE_Jhf8EO_wOfL2CYu34=.bec5a255-b7ac-4e64-b2e1-435b55c8d838@github.com>

On Tue, 5 Apr 2022 20:16:28 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
>> 1) Frame which contains test instruction .
>> 2) Pass & Fail button so that user can mark the test pass or fail
>> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
>> 4) Disposing of all the frames.
>> 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed review comments

Add a fix where the Test Instruction frame and the test frame can be placed either side by side or up and down.

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

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


From duke at openjdk.java.net  Thu Apr  7 15:09:28 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 7 Apr 2022 15:09:28 GMT
Subject: RFR: 8284535 : Fix PrintLatinCJKTest.java test that is failing
 with Parse Exception [v5]
In-Reply-To: <pFqi_8Dlb0WryGIxBFf0V8BMXe2n54CiFcDkE-GA7qI=.4de19210-b028-4e6a-ae13-26bf7bd0ad5f@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <qbKJqZO3IlieY4GAIW20LjtNYxE3LriYV9yqv6OSyPQ=.f43caf22-7bea-4604-9813-71a4d35f4635@github.com>
 <pFqi_8Dlb0WryGIxBFf0V8BMXe2n54CiFcDkE-GA7qI=.4de19210-b028-4e6a-ae13-26bf7bd0ad5f@github.com>
Message-ID: <jpQG_JVhHVppQOk2phO3dC7w4K8tYUZnFe69puy8vc4=.28206a23-08ba-4cea-a218-4e5ed83e15cb@github.com>

On Wed, 6 Apr 2022 10:39:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed review comments
>
> test/jdk/java/awt/print/PrinterJob/PrintLatinCJKTest.java line 85:
> 
>> 83:                 frame.dispose();
>> 84:             }
>> 85:         });
> 
> I just thought whether it's feasible to keep a list of frames / windows to be disposed of inside the `PassFailJFrame` class. It disposes of its instruction frame when the wait is over, it can handle disposing of other frames too.
> 
> If I remember correctly, the first version disposed of of all windows. If we make it an explicit list, it shouldn't cause issues.

Fixed

> test/jdk/java/awt/print/PrinterJob/PrintLatinCJKTest.java line 105:
> 
>> 103:         PrintLatinCJKTest.showFrame();
>> 104:         passFailJFrame.awaitAndCheck();
>> 105:         PrintLatinCJKTest.disposeTestFrame();
> 
> It won't be disposed of if the test fails, that is throws an exception, so this should be in try-finally block.
> 
> The class name isn't required to call a static method which is in this class.

Fixed

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

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


From duke at openjdk.java.net  Thu Apr  7 15:09:32 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 7 Apr 2022 15:09:32 GMT
Subject: RFR: 8284535 : Fix PrintLatinCJKTest.java test that is failing
 with Parse Exception [v4]
In-Reply-To: <h7QOpvrWuaiHPdWgZ0nJ1kd_9Ccpp25XBgeLdVc995Q=.4f12d6ad-bb09-4395-9cbf-89f439e76bac@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <IMKOkFbDuV-4DlmfcBxxPuL8dBo2GxrGWFET0sMnPPU=.6ca91ed1-c940-4880-8487-892cb77de3e8@github.com>
 <h7QOpvrWuaiHPdWgZ0nJ1kd_9Ccpp25XBgeLdVc995Q=.4f12d6ad-bb09-4395-9cbf-89f439e76bac@github.com>
Message-ID: <dSNXqlezmU92s0ifg3DyGz5zlreJ6kwWraYK9_UNg0I=.d37f46a3-f02e-406b-a6fe-7bf020e2ff4f@github.com>

On Tue, 5 Apr 2022 18:58:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Dispose the Frame based in EDT
>
> test/jdk/java/awt/print/PrinterJob/PrintLatinCJKTest.java line 91:
> 
>> 89:     public static void main(String[] args) throws InterruptedException, InvocationTargetException {
>> 90:         PassFailJFrame passFailJFrame = new PassFailJFrame("Test Instruction" +
>> 91:                 "Frame", info, 7, 30, 3);
> 
> This already breaks the threading rules of Swing: every access to Swing components must be done on EDT.
> 
> The thing is `PassFailJFrame` extends `JFrame`, thus super constructor (the inherited one from `JFrame`) will be called on main thread. It's not what we want, isn't it?
> 
> I'd suggest not to extend `JFrame` at all. We're not developing new functionality to `JFrame` but build UI using Swing components.
> 
> As a benefit, you'll be able to initialise GUI on EDT if the constructor is called on another thread.
> 
> I support Phil that the framework should document threading and mark methods which are allowed to be called on any thread. Probably all the methods should allow for it.

Fixed, while the comment was added

> test/jdk/java/awt/print/PrinterJob/PrintLatinCJKTest.java line 93:
> 
>> 91:                 "Frame", info, 7, 30, 3);
>> 92:         PrintLatinCJKTest.showFrame();
>> 93:         passFailJFrame.awaitAndCheck();
> 
> I believe `awaitAndCheck()` is the method that must be called from the main thread. It waits until the test is completed.
> 
> If it was called on EDT, it would block the event queue.

Added the Note as part of the method description

> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 42:
> 
>> 40:     private final CountDownLatch latch = new CountDownLatch(1);
>> 41:     private boolean failed = false;
>> 42:     private String testFailedReason;
> 
> These two are accessed by EDT and main thread. The boolean field should be declared `volatile` or use `AtomicBoolean`. The same applies for `testFailedReason`.

Fixed

> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 45:
> 
>> 43:     private JTextArea instructionsText;
>> 44:     private final int maxRowLength;
>> 45:     private final int maxStringLength;
> 
> These aren't needed as fields, they're used only to create instruction text.

Removed

> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 65:
> 
>> 63:      * @throws HeadlessException
>> 64:      * @throws InterruptedException
>> 65:      * @throws InvocationTargetException
> 
> I suggest adding generic descriptions of exceptions to avoid IDE warnings.

Added the description

> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 78:
> 
>> 76:         invokeAndWait(() -> {
>> 77:             setLayout(new BorderLayout());
>> 78:             instructionsText = new JTextArea(instructions, maxRowLength, maxStringLength);
> 
> You could use line wrap functionality of JTextArea to avoid adding `\n` to the instructions.
> 
> Consider placing it into JScrollPane for flexibility, though not required.
> 
> `maxRowLength` is actually the number of rows (lines), and `maxStringLength` is the number of columns. These parameters are used to calculate the preferred size of the text area, they don't limit the text the component can store.

Added JScrollPane & used wrap function on JTextArea

> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 80:
> 
>> 78:             instructionsText = new JTextArea(instructions, maxRowLength, maxStringLength);
>> 79:             instructionsText.setEditable(false);
>> 80:             instructionsText.setFocusable(false);
> 
> I think leaving the instructions focusable won't hurt. It would allow selecting text (and copying it) if the tester needs it for whatever reason.

Done

> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 95:
> 
>> 93:             add(buttonsPanel, BorderLayout.SOUTH);
>> 94:             pack();
>> 95:             setLocation(10, 10);
> 
> The instruction window should probably be placed around the centre of the screen.
> 
> The class should provide a method to position a secondary frame near the instruction frame so that both frames don't overlap.
> 
> A possibility to include test UI to the instructions could be beneficial in some cases: dealing with one window is easier than with several ones. It's just a suggestion for further improvement though.

Fixed

> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 96:
> 
>> 94:             pack();
>> 95:             setLocation(10, 10);
>> 96:             setVisible(true);
> 
> Closing the window with Close button should also fail the test, now it doesn't.

Fixed

> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 125:
> 
>> 123:     public void getFailureReason() {
>> 124:         final JDialog dialog = new JDialog();
>> 125:         dialog.setTitle("Failure reason");
> 
> I suggest making the dialog Toolkit-modal so that only the dialog can be interacted with.
> 
> 
>         final JDialog dialog = new JDialog(this, "Failure reason", TOOLKIT_MODAL);
> 
> 
> At this time, I can click Fail again several times and I'll have several dialogs open. I can also click Pass which completes the test and disposes of the dialogs.

Yes, I made the JDialog to be Modal dialog

> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 144:
> 
>> 142:         jPanel.add(okayBtnPanel, BorderLayout.SOUTH);
>> 143:         dialog.add(jPanel);
>> 144:         dialog.setLocationRelativeTo(null);
> 
> We should probably position the dialog relatively to the frame or the Fail button.
> 
> Now the frame is displayed on the left edge of the screen but the dialog is in the centre of the screen as if they're unrelated.

Fixed.

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

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


From duke at openjdk.java.net  Thu Apr  7 16:07:41 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Thu, 7 Apr 2022 16:07:41 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v2]
In-Reply-To: <p1lJJBIqQpVg6kwYcdWaFsZbLIfE0AkN3Tyl3gXmakE=.98fff17e-812b-4f8b-97b6-4bc61e45ce03@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <_UplvB0h9bWCInEGLRAN4bN3_sMypgu0hf0nU57pJgI=.8eef0557-500c-4939-b00f-ae9c0dd5a5b8@github.com>
 <p1lJJBIqQpVg6kwYcdWaFsZbLIfE0AkN3Tyl3gXmakE=.98fff17e-812b-4f8b-97b6-4bc61e45ce03@github.com>
Message-ID: <j97LbflNBQ6fh8KsWHH1YIaXVM6wjCZUOHVrvqzIfLY=.06847a3d-73bd-4102-90eb-06212ceb4f85@github.com>

On Thu, 7 Apr 2022 11:19:53 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> 



> Why can't the test be automatic?

Actually had thought about automating the test case, but since endOfLine(Win - '\r\n', linux - '\n') is different for different OS, have made it manual.

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

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


From prr at openjdk.java.net  Thu Apr  7 17:04:41 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 7 Apr 2022 17:04:41 GMT
Subject: RFR: 8284378: Make Metal the default Java 2D rendering pipeline
 for macOS
In-Reply-To: <Z45KY6DtqGZlf_r5X_CKM_YFP2IZzg48a2s4gI08Kzo=.5e58870d-cd23-4d5f-98c7-f581117a1a4e@github.com>
References: <Z45KY6DtqGZlf_r5X_CKM_YFP2IZzg48a2s4gI08Kzo=.5e58870d-cd23-4d5f-98c7-f581117a1a4e@github.com>
Message-ID: <PGHPzyXYa0FAEqwG86rLEV57TLaNFqeQesgiAjhoxuM=.1bce741e-6fd1-49ac-8c30-a11b1819ad74@github.com>

On Wed, 6 Apr 2022 09:48:13 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> This PR makes Metal rendering pipeline as the default Java 2D rendering pipeline for macOS.
> 
> Please refer "JBS Description" for more details.

Marked as reviewed by prr (Reviewer).

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

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


From jdv at openjdk.java.net  Thu Apr  7 18:05:44 2022
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 7 Apr 2022 18:05:44 GMT
Subject: RFR: 8284378: Make Metal the default Java 2D rendering pipeline
 for macOS
In-Reply-To: <Z45KY6DtqGZlf_r5X_CKM_YFP2IZzg48a2s4gI08Kzo=.5e58870d-cd23-4d5f-98c7-f581117a1a4e@github.com>
References: <Z45KY6DtqGZlf_r5X_CKM_YFP2IZzg48a2s4gI08Kzo=.5e58870d-cd23-4d5f-98c7-f581117a1a4e@github.com>
Message-ID: <UeBAKZalluB4NAQumWQeUZOw-oMxkR2POn7R7ytSUUY=.65c866eb-5cbe-41e0-b05f-ca0c929d921e@github.com>

On Wed, 6 Apr 2022 09:48:13 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> This PR makes Metal rendering pipeline as the default Java 2D rendering pipeline for macOS.
> 
> Please refer "JBS Description" for more details.

Marked as reviewed by jdv (Reviewer).

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

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


From serb at openjdk.java.net  Thu Apr  7 18:40:35 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 7 Apr 2022 18:40:35 GMT
Subject: RFR: 8283706: Add final or sealed modifier to appropriate
 javax.swing API classes
In-Reply-To: <PfDlBvA6XZ18qqLp21-ZAioRrPXgHeqJ2yUflkmEnK8=.35b6121b-405b-4e80-b933-9ef99a53e084@github.com>
References: <PfDlBvA6XZ18qqLp21-ZAioRrPXgHeqJ2yUflkmEnK8=.35b6121b-405b-4e80-b933-9ef99a53e084@github.com>
Message-ID: <iY6ObogfDD0tvLzyfrdU96gZClXC-9JAD_AEiqeiwRA=.2963ef12-d2bf-4b71-a4c1-5fb2db3c1994@github.com>

On Sat, 2 Apr 2022 23:21:03 GMT, Phil Race <prr at openjdk.org> wrote:

> Update Swing classes to use JEP 409 sealed and non-sealed modifiers and add the final modifier where appropriate.
> 
> jtreg tests and JCK API tests pass
> 
> CSR for review here : https://bugs.openjdk.java.net/browse/JDK-8284214

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Thu Apr  7 18:40:35 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 7 Apr 2022 18:40:35 GMT
Subject: RFR: 8283706: Add final or sealed modifier to appropriate
 javax.swing API classes
In-Reply-To: <7HmnDkG_EwJnoRtTXJL38rK5a5UGFmedVjXfF8L3HZM=.588aa464-fb18-4a77-82e6-9307693e7058@github.com>
References: <PfDlBvA6XZ18qqLp21-ZAioRrPXgHeqJ2yUflkmEnK8=.35b6121b-405b-4e80-b933-9ef99a53e084@github.com>
 <WFCnNVLDVUs39mzqFPx9Vt7n9nKwtiGkd3NQxcMvvhc=.e9021d66-6a4c-472c-a531-c16d685d32e0@github.com>
 <V6L04fMUKgHOu82Sm8KHJFARu0hB0EF5my4-emPDnWw=.e2cd697d-1cd8-4642-b8ea-2075dd7e0197@github.com>
 <6vGKFgUuy-PH7-CGtxJanp1JaqHlPO-JxX0DmjGJlSA=.c9524b6d-d1e7-44b5-b282-6ff8c4fda1e3@github.com>
 <7HmnDkG_EwJnoRtTXJL38rK5a5UGFmedVjXfF8L3HZM=.588aa464-fb18-4a77-82e6-9307693e7058@github.com>
Message-ID: <iymHFB787c6_TXY6o3QKS-FLa5WWkL2vXlnMfElSk3M=.852cdae2-40fd-4da7-a5dc-dac6fe37fbe5@github.com>

On Thu, 7 Apr 2022 04:43:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Just to double-check, it is fine to have it in the output of the getPermittedSubclasses for the public class as well?
>
> I'm not certain what question you are asking. If the question is, is it fine for core reflection to return non-public information about the class, in general sure. For example, in jshell evaluating
> StringBuilder.class.getSuperclass()
> will yield
>  class java.lang.AbstractStringBuilder
> which is the non-public superclass of StringBuffer and StringBuilder.
> 
> If the question is, do the compatibility expectations of the platform include such visible non-public implementation artifacts? The answer is no; it is fine for those details to evolve and users shouldn't rely on them.
> 
> Is there another aspect of the change that was a concern?

Thank you for your clarification.

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

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


From prr at openjdk.java.net  Thu Apr  7 19:36:41 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 7 Apr 2022 19:36:41 GMT
Subject: RFR: 8283706: Add final or sealed modifier to appropriate
 javax.swing API classes
In-Reply-To: <iymHFB787c6_TXY6o3QKS-FLa5WWkL2vXlnMfElSk3M=.852cdae2-40fd-4da7-a5dc-dac6fe37fbe5@github.com>
References: <PfDlBvA6XZ18qqLp21-ZAioRrPXgHeqJ2yUflkmEnK8=.35b6121b-405b-4e80-b933-9ef99a53e084@github.com>
 <WFCnNVLDVUs39mzqFPx9Vt7n9nKwtiGkd3NQxcMvvhc=.e9021d66-6a4c-472c-a531-c16d685d32e0@github.com>
 <V6L04fMUKgHOu82Sm8KHJFARu0hB0EF5my4-emPDnWw=.e2cd697d-1cd8-4642-b8ea-2075dd7e0197@github.com>
 <6vGKFgUuy-PH7-CGtxJanp1JaqHlPO-JxX0DmjGJlSA=.c9524b6d-d1e7-44b5-b282-6ff8c4fda1e3@github.com>
 <7HmnDkG_EwJnoRtTXJL38rK5a5UGFmedVjXfF8L3HZM=.588aa464-fb18-4a77-82e6-9307693e7058@github.com>
 <iymHFB787c6_TXY6o3QKS-FLa5WWkL2vXlnMfElSk3M=.852cdae2-40fd-4da7-a5dc-dac6fe37fbe5@github.com>
Message-ID: <0YxWiHfWo-liuAdqmtziq9AkAgMNqGBFhliqDUvmbXI=.441769f7-1cc4-4543-9002-e83e4a8d96d2@github.com>

On Thu, 7 Apr 2022 18:36:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I'm not certain what question you are asking. If the question is, is it fine for core reflection to return non-public information about the class, in general sure. For example, in jshell evaluating
>> StringBuilder.class.getSuperclass()
>> will yield
>>  class java.lang.AbstractStringBuilder
>> which is the non-public superclass of StringBuffer and StringBuilder.
>> 
>> If the question is, do the compatibility expectations of the platform include such visible non-public implementation artifacts? The answer is no; it is fine for those details to evolve and users shouldn't rely on them.
>> 
>> Is there another aspect of the change that was a concern?
>
> Thank you for your clarification.

You have to include it in the list, else it would not be a permitted sub-class, and then you couldn't use the new syntax at all.

the javadoc doesn't mention it - it still just says
public sealed class GroupLayout.ParallelGroup
extends [GroupLayout.Group]

My recollection is that if there are also public classes the generated javadocs cites the public one and appends the text "and others" ,,  to mean the private ones .. I don't know why it does that but it still doesn't expose the internal class

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

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


From achung at openjdk.java.net  Thu Apr  7 20:24:29 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Thu, 7 Apr 2022 20:24:29 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v8]
In-Reply-To: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
Message-ID: <oLAtmZ-nvXcaycSBywshKYbkuZimPBTKoD77xSauDQU=.2d6243ce-8651-428c-87ac-2a1ba82a7505@github.com>

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

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

  fixed 1.25 scaling overdraw, fixed calcs for right and bottom side borders

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7449/files
  - new: https://git.openjdk.java.net/jdk/pull/7449/files/9109b84b..5d4854df

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

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

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


From achung at openjdk.java.net  Thu Apr  7 20:24:30 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Thu, 7 Apr 2022 20:24:30 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v7]
In-Reply-To: <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oWsGQHYMF3MHYkJRn6lPx0qW1Bx79DMS9Wl-zf8hsrM=.337c53c2-5ef3-45df-9429-4a6d27ff571f@github.com>
Message-ID: <Edl2TOMRxbbFjyAKrcRzR79IXbnmzWHuH-chCn3CKuY=.63ed7bf3-7598-4282-9ace-5561bbd4e262@github.com>

On Wed, 23 Mar 2022 18:24:05 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   scale stroke width at higher scalings

I checked 1.25, 1.5, 2, 3x scalings for latest change

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

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


From kizune at openjdk.java.net  Thu Apr  7 20:39:44 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 7 Apr 2022 20:39:44 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v2]
In-Reply-To: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
Message-ID: <rRQpoUXVGHMZbp47Gs7NF9d7TUjAlf2ITd211u198-I=.18f213a5-a5c6-47e6-a4bb-36b5e80500bb@github.com>

> Detect the situation where we do need to perform interpolation during ImageIcon
> painting and set a hint to the rendering to perform bicubic approximation so
> image details are preserved during transition.

Alexander Zuev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge pull request #35 from azuev-java/master
   
   Merge
 - 8282526: Default icon is not painted properly
   
   Detect the situation when icon image painting requires interpolation and set the interpolation to bicubic to
   preserve the icon details as much as possible.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7805/files
  - new: https://git.openjdk.java.net/jdk/pull/7805/files/2f5b31ab..6967cc18

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

  Stats: 157285 lines in 2490 files changed: 116162 ins; 31452 del; 9671 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7805.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7805/head:pull/7805

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


From prr at openjdk.java.net  Thu Apr  7 21:04:34 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 7 Apr 2022 21:04:34 GMT
Subject: RFR: 8284521: Write an automated regression test for RFE 4371575
In-Reply-To: <FgW8JkNC98cWCRNm8Tpsu75-EYCzO2wP4X-sM9rDkZs=.f66039d3-903b-42b3-b2f4-3af624d6fd4b@github.com>
References: <FgW8JkNC98cWCRNm8Tpsu75-EYCzO2wP4X-sM9rDkZs=.f66039d3-903b-42b3-b2f4-3af624d6fd4b@github.com>
Message-ID: <TIYu5o-Rn-M9gD9LXG4_dnDrvMm9_zrYbwyhGsyN3Go=.a59a0d07-ebf1-46c6-8728-a423fc9a1998@github.com>

On Thu, 7 Apr 2022 11:08:38 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Write an automated regression test for [JDK-4371575](https://bugs.openjdk.java.net/browse/JDK-4371575)
> 
> Issue:
> As part of the Merlin focus project, JComponent.setRequestFocusEnabled was
> deprecated and its implementation was changed to map exactly to the new
> method Component.setFocusable. Scott believes that the old behavior may be
> preferable. He would like to be able to specify that a Component is focusable,
> and should receive focus during keyboard traversal, but that it should not
> automatically take focus when the user clicks on it with the mouse.
> 
> We are concerned that the accessibility team would be against this behavior,
> and this also seems like more of a PLAF issue. Nevertheless, we should look
> into it before beta ships.
> 
> Fix:
> After some discussion we decided that the best balance of the old and new would be to make this an advisory property. This property will not be synonymous with focusable. Instead our mouse listeners will check this property before requesting focus. This provides as closely as possible the old behavior, while allowing people to use the new focusable property if they don't want a component focusable at all.
> 
> Testing:
> Tested in mach5, 10 times with all the 3 available platform like macosx, windows and linux and got all Pass.

Before I look at the test, can you get rid of the pointless directory 4371575
A directory might be needed if you had a lot of files for the test - but you don't !
And I really don't like naming directories OR tests with the bugid. Someone can find
that out from the @bug tag.

I know you've pushed a bunch of bugs already that follow this pattern but update all the "in progress" ones to NOT create pointless extra folders.

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

Changes requested by prr (Reviewer).

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


From darcy at openjdk.java.net  Thu Apr  7 22:22:02 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 7 Apr 2022 22:22:02 GMT
Subject: RFR: 8283706: Add final or sealed modifier to appropriate
 javax.swing API classes
In-Reply-To: <0YxWiHfWo-liuAdqmtziq9AkAgMNqGBFhliqDUvmbXI=.441769f7-1cc4-4543-9002-e83e4a8d96d2@github.com>
References: <PfDlBvA6XZ18qqLp21-ZAioRrPXgHeqJ2yUflkmEnK8=.35b6121b-405b-4e80-b933-9ef99a53e084@github.com>
 <WFCnNVLDVUs39mzqFPx9Vt7n9nKwtiGkd3NQxcMvvhc=.e9021d66-6a4c-472c-a531-c16d685d32e0@github.com>
 <V6L04fMUKgHOu82Sm8KHJFARu0hB0EF5my4-emPDnWw=.e2cd697d-1cd8-4642-b8ea-2075dd7e0197@github.com>
 <6vGKFgUuy-PH7-CGtxJanp1JaqHlPO-JxX0DmjGJlSA=.c9524b6d-d1e7-44b5-b282-6ff8c4fda1e3@github.com>
 <7HmnDkG_EwJnoRtTXJL38rK5a5UGFmedVjXfF8L3HZM=.588aa464-fb18-4a77-82e6-9307693e7058@github.com>
 <iymHFB787c6_TXY6o3QKS-FLa5WWkL2vXlnMfElSk3M=.852cdae2-40fd-4da7-a5dc-dac6fe37fbe5@github.com>
 <0YxWiHfWo-liuAdqmtziq9AkAgMNqGBFhliqDUvmbXI=.441769f7-1cc4-4543-9002-e83e4a8d96d2@github.com>
Message-ID: <hal-ZK4bRbeKuwNByf6TXvQhsgh-Ajj_t56B4Gb-nvU=.8c67090d-cd2f-4fd3-b45e-bdc1bf36b154@github.com>

On Thu, 7 Apr 2022 19:33:28 GMT, Phil Race <prr at openjdk.org> wrote:

>> Thank you for your clarification.
>
> You have to include it in the list, else it would not be a permitted sub-class, and then you couldn't use the new syntax at all.
> 
> the javadoc doesn't mention it - it still just says
> public sealed class GroupLayout.ParallelGroup
> extends [GroupLayout.Group]
> 
> My recollection is that if there are also public classes the generated javadocs cites the public one and appends the text "and others" ,,  to mean the private ones .. I don't know why it does that but it still doesn't expose the internal class

The motivation for that wording is discussed in JEP 409; it indicates the public list of classes is not exhaustive. So for pattern matching (JEP 406), if the pattern matching cases for the switch expressoin are not exhaustive, a default clause on the switch is required. HTH

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

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


From duke at openjdk.java.net  Thu Apr  7 22:59:33 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 7 Apr 2022 22:59:33 GMT
Subject: RFR: 8284316 : Support accessibility ManualTestFrame.java for non
 SwingSet tests [v2]
In-Reply-To: <Y0twm8U_WwlVo91p-VA5abXTnu6qvQep3fDqyLOBsyk=.19550bf3-616b-4a53-9985-131a4b624af0@github.com>
References: <Y0twm8U_WwlVo91p-VA5abXTnu6qvQep3fDqyLOBsyk=.19550bf3-616b-4a53-9985-131a4b624af0@github.com>
Message-ID: <_3KQsjqFELr9Pn_bUlpNkqUoFEfzFXrXDpjqSx6wKLE=.362fb0dc-c796-4748-9123-bf08e3ec51a2@github.com>

> 1) Modified  ManualTestFrame.java to support non SwingSet2 and this include modification of SwingSetTest.java
> 2) Added new TestJProgressBarAccessibility.java testcase that uses ManualTestFrame
> 3) Added timeout support in case user does not interact with the ManualTestFrame 
> 
> @shurymury

lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision:

 - minor change
 - Set Default timeout value as well as read as parameter

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8100/files
  - new: https://git.openjdk.java.net/jdk/pull/8100/files/c1f886b0..9d49e5b4

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

  Stats: 18 lines in 3 files changed: 4 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8100.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8100/head:pull/8100

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


From serb at openjdk.java.net  Thu Apr  7 23:08:11 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 7 Apr 2022 23:08:11 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux [v3]
In-Reply-To: <1s3rujPqPuQFiA9xp2Rq4UoXMfP5fSpzQX_CNfl-UXw=.4b2a2871-1647-4c2f-a368-44ef8c7896c4@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
 <1s3rujPqPuQFiA9xp2Rq4UoXMfP5fSpzQX_CNfl-UXw=.4b2a2871-1647-4c2f-a368-44ef8c7896c4@github.com>
Message-ID: <6bK-iNlPfRxkowIW1_7WYUulcJ9qpcvCBgcG44Q0mHs=.e04e5fc2-d532-4684-bab1-3fd94ba58048@github.com>

On Tue, 5 Apr 2022 05:42:53 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> These crashes were not reproducible, so the fix is based on a hypothesis that there are two possible reasons for them:
>> 1. `makeDefaultConfig()` returning `NULL`.
>> 2. A race condition when the number of screens changes.
>> The race scenario: `X11GraphisDevice.makeDefaultConfiguration()` is called on EDT so the call can race with `X11GraphisDevice.invalidate()` that re-sets the screen number of the device; the latter is invoked on the `AWT-XAWT` thread from `X11GraphicsEnvironment.rebuildDevices()`. So by the time `makeDefaultConfiguration()` makes a native call with the device's current screen number, the `x11Screens` array maintained by the native code could have become shorter. And the native methods like `Java_sun_awt_X11GraphicsDevice_getConfigColormap()` assume that the number passed to them is always current and valid. The AWT lock only protects against the changes during the native methods invocation and does not protect against them being called with an outdated screen number. With a larger screen number, those methods read past the end of the `x11Screens` array.
>> 
>> The fix for (1) is to die gracefully instead of crashing in an attempt to de-reference a `NULL` pointer, which might happen upon returning from `makeDefaultConfig()` in `getAllConfigs()`.
>> 
>> The fix for (2) is to eliminate the race by protecting `X11GraphisDevice.screen` with the AWT lock such that it doesn't change when the native methods working with it are active.
>> 
>> We've been shipping JetBrains Runtime with this fix for a few months now and there were no crash reports with those specific patterns against the versions with the fix.
>
> Maxim Kartashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into JDK-8280468
>  - Addressed PR comments
>    
>    1. Got rid of X11GraphicsDevice.configLock in favour of the AWT lock.
>    2. Reduced the use of the screen number (and, consequently, AWT lock
>    contention) in XCanvasPeer.
>  - 8280468: Crashes in getConfigColormap, getConfigVisualId, XVisualIDFromVisual on Linux
>    
>    This fix addresses two possible causes of crashes:
>    1. makeDefaultConfig() returning NULL. The fix is to die gracefully
>    instead of crashing in an attempt to de-reference a NULL pointer.
>    
>    2. A race condition when the number of screens change (this is only an
>    issue with the number of xinerama screens; the number of X11 screens is
>    static for the duration of the X session).
>    
>    The race scenario: X11GraphisDevice.makeDefaultConfiguration() is called
>    on EDT so the call can race with X11GraphisDevice.invalidate() that
>    re-sets the screen number of the device; the latter is invoked on the
>    "AWT-XAWT" thread from X11GraphicsEnvironment.rebuildDevices(). So by
>    the time makeDefaultConfiguration() makes a native call with the
>    device's current screen number, the x11Screens array maintained by the
>    native code could have become shorter. And the native methods like
>    Java_sun_awt_X11GraphicsDevice_getConfigColormap() assume that the
>    screen number passed to them is always current and valid. The AWT lock
>    only protects against the changes during the native methods invocation,
>    but does not protect against them being called with an outdated screen
>    number.
>    
>    The fix is to eliminate the race by protecting X11GraphisDevice.screen
>    with the AWT lock.

src/java.desktop/unix/classes/sun/awt/X11/XCanvasPeer.java line 90:

> 88:             XToolkit.awtUnlock();
> 89:         }
> 90:     }

I am not sure I understand the purpose of this method, it requests the current device for the GC, then requests the screen index of the device, and then request device by the screen index, what is the reason to do that? Why we cannot just use the device from the GC?

src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java line 161:

> 159: 
> 160:     private void makeConfigurations() {
> 161:         if (configs == null) {

To make the diff less distruptive you can move the ssyncronisation to the getConfigurations and getDefaultConfiguration where we have kind of DCL.

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

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


From duke at openjdk.java.net  Fri Apr  8 00:40:42 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Fri, 8 Apr 2022 00:40:42 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v8]
In-Reply-To: <fR3AZPwa0kAz6SJDa5ns4eyyjCIAY_s25IlS2SL2xSw=.c8689931-ded8-448f-8caa-a17b47f7631a@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <afJ29wQf2smgANBt5YTQC4oODoch8zxa0YqdtUZDfW8=.f4d0de4d-5245-4491-a8e8-05aaf2a4797a@github.com>
 <gzymK8AsH16kj6YIbJoMuRVGTDkKwLd_O3rbbDZCWIQ=.1f491527-2bac-4e6d-a5cc-f8443bf4f352@github.com>
 <MENhs6_2RTKjMOcWkh1CzumSIwQOy75T_wLac37Vkl8=.0da493e3-d91d-4b48-bd58-f69cefce3a9b@github.com>
 <wrQgwI3XG2G9_X8n5n4Q_AzDnMElxB92075XY3bkJMQ=.f5fb8350-489d-44a1-935a-e752b78347cd@github.com>
 <fR3AZPwa0kAz6SJDa5ns4eyyjCIAY_s25IlS2SL2xSw=.c8689931-ded8-448f-8caa-a17b47f7631a@github.com>
Message-ID: <7ot0fBLQsvKiNsxLdrbnv4R_MNr6qdLN_GBwNPjU-rY=.dcad59a1-d0d6-42b9-bdf4-6290f31a88e0@github.com>

On Wed, 6 Apr 2022 17:29:27 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> @prsadhuk I was able to replicate the above scenario and as mentioned it oddly happens only when we start with Graphite as accent color. Looking into it further.
>
> Following type properties where checked for cellFocusRing color
> 
> - [alternateSelectedControlColor](https://developer.apple.com/documentation/appkit/nscolor/1533135-alternateselectedcontrolcolor) 
> **Issue:** Doesn't follow accent color in macos 10.15 and deprecated property.
> 
> - [selectedContentBackgroundColor](https://developer.apple.com/documentation/appkit/nscolor/2998830-selectedcontentbackgroundcolor)
> **Issue:** New property corresponding to **alternateSelectedControlColor** (deprecated). Causes build issues as the property is supported on macOS 10.14+ and the macOS deployment target version is 10.12 for jdk.
> 
> -  [controlAccentColor](https://developer.apple.com/documentation/appkit/nscolor/3000782-controlaccentcolor) 
> **Issue:** Causes build issues due to version compatibility, property supported on only macOS 10.14+
> 
> - [accentColor](https://developer.apple.com/documentation/swiftui/color/accentcolor) 
> **Issue:** Property supported on only macOS 10.15+, compatibility and run time issues.
> 
> - [keyboardfocusindicatorcolor](https://developer.apple.com/documentation/appkit/nscolor/1532031-keyboardfocusindicatorcolor) 
> **Issue:** Works well for most of the scenarios (including on-the-fly changes) and follows the accent color changes except when we start the application with accent color set to Graphite and then change accent color on-the-fly (as mentioned above). The cell focus ring remains gray. The issue seems to be with the system color returned by the type-property "**keyboardfocusindicatorcolor**" under this setting.

@prrace @prsadhuk 
The issue with the system color returned by **keyboardFocusIndicatorColor** mentioned above, persists on macOS 12.3 as well.

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

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


From duke at openjdk.java.net  Fri Apr  8 06:36:24 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Fri, 8 Apr 2022 06:36:24 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux [v4]
In-Reply-To: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
Message-ID: <nBpHJK8h0qWsn8vUZKZ0Wuux_J7FkAX5yRM1sRgmvpo=.fbcf0a4c-4bce-440f-a50b-e7daa9496404@github.com>

> These crashes were not reproducible, so the fix is based on a hypothesis that there are two possible reasons for them:
> 1. `makeDefaultConfig()` returning `NULL`.
> 2. A race condition when the number of screens changes.
> The race scenario: `X11GraphisDevice.makeDefaultConfiguration()` is called on EDT so the call can race with `X11GraphisDevice.invalidate()` that re-sets the screen number of the device; the latter is invoked on the `AWT-XAWT` thread from `X11GraphicsEnvironment.rebuildDevices()`. So by the time `makeDefaultConfiguration()` makes a native call with the device's current screen number, the `x11Screens` array maintained by the native code could have become shorter. And the native methods like `Java_sun_awt_X11GraphicsDevice_getConfigColormap()` assume that the number passed to them is always current and valid. The AWT lock only protects against the changes during the native methods invocation and does not protect against them being called with an outdated screen number. With a larger screen number, those methods read past the end of the `x11Screens` array.
> 
> The fix for (1) is to die gracefully instead of crashing in an attempt to de-reference a `NULL` pointer, which might happen upon returning from `makeDefaultConfig()` in `getAllConfigs()`.
> 
> The fix for (2) is to eliminate the race by protecting `X11GraphisDevice.screen` with the AWT lock such that it doesn't change when the native methods working with it are active.
> 
> We've been shipping JetBrains Runtime with this fix for a few months now and there were no crash reports with those specific patterns against the versions with the fix.

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

  Made the diff of X11GraphicsDevice.java less disruptive

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7182/files
  - new: https://git.openjdk.java.net/jdk/pull/7182/files/37017309..1c5ad928

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

  Stats: 111 lines in 1 file changed: 35 ins; 35 del; 41 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7182/head:pull/7182

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


From duke at openjdk.java.net  Fri Apr  8 06:49:09 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Fri, 8 Apr 2022 06:49:09 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux [v5]
In-Reply-To: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
Message-ID: <l8h3eiPB9RcX38ktddI1hgx1RL1ZaCZz0DlXdU-Hgjk=.d5380014-4dff-4334-8be9-fb537221f546@github.com>

> These crashes were not reproducible, so the fix is based on a hypothesis that there are two possible reasons for them:
> 1. `makeDefaultConfig()` returning `NULL`.
> 2. A race condition when the number of screens changes.
> The race scenario: `X11GraphisDevice.makeDefaultConfiguration()` is called on EDT so the call can race with `X11GraphisDevice.invalidate()` that re-sets the screen number of the device; the latter is invoked on the `AWT-XAWT` thread from `X11GraphicsEnvironment.rebuildDevices()`. So by the time `makeDefaultConfiguration()` makes a native call with the device's current screen number, the `x11Screens` array maintained by the native code could have become shorter. And the native methods like `Java_sun_awt_X11GraphicsDevice_getConfigColormap()` assume that the number passed to them is always current and valid. The AWT lock only protects against the changes during the native methods invocation and does not protect against them being called with an outdated screen number. With a larger screen number, those methods read past the end of the `x11Screens` array.
> 
> The fix for (1) is to die gracefully instead of crashing in an attempt to de-reference a `NULL` pointer, which might happen upon returning from `makeDefaultConfig()` in `getAllConfigs()`.
> 
> The fix for (2) is to eliminate the race by protecting `X11GraphisDevice.screen` with the AWT lock such that it doesn't change when the native methods working with it are active.
> 
> We've been shipping JetBrains Runtime with this fix for a few months now and there were no crash reports with those specific patterns against the versions with the fix.

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

  Restored the original code in X11GraphicsDevice.java that got auto-formatted

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7182/files
  - new: https://git.openjdk.java.net/jdk/pull/7182/files/1c5ad928..422397eb

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

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

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


From duke at openjdk.java.net  Fri Apr  8 06:49:12 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Fri, 8 Apr 2022 06:49:12 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux [v2]
In-Reply-To: <6bK-iNlPfRxkowIW1_7WYUulcJ9qpcvCBgcG44Q0mHs=.e04e5fc2-d532-4684-bab1-3fd94ba58048@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
 <1s3rujPqPuQFiA9xp2Rq4UoXMfP5fSpzQX_CNfl-UXw=.4b2a2871-1647-4c2f-a368-44ef8c7896c4@github.com>
 <6bK-iNlPfRxkowIW1_7WYUulcJ9qpcvCBgcG44Q0mHs=.e04e5fc2-d532-4684-bab1-3fd94ba58048@github.com>
Message-ID: <7iVp3ugJfRapjCze-mAQKfRdx-KEjk6KE09U1jY0l2w=.c6554758-7ea7-4b63-80f0-6f138a9b8732@github.com>

On Thu, 7 Apr 2022 23:05:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed PR comments
>>   
>>   1. Got rid of X11GraphicsDevice.configLock in favour of the AWT lock.
>>   2. Reduced the use of the screen number (and, consequently, AWT lock
>>   contention) in XCanvasPeer.
>
> src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java line 161:
> 
>> 159:         XToolkit.awtLock();
>> 160:         try {
>> 161:             if (configs == null) {
> 
> To make the diff less distruptive you can move the ssyncronisation to the getConfigurations and getDefaultConfiguration where we have kind of DCL.

Sure thing. Done.

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

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


From duke at openjdk.java.net  Fri Apr  8 06:51:36 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Fri, 8 Apr 2022 06:51:36 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux [v3]
In-Reply-To: <6bK-iNlPfRxkowIW1_7WYUulcJ9qpcvCBgcG44Q0mHs=.e04e5fc2-d532-4684-bab1-3fd94ba58048@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
 <1s3rujPqPuQFiA9xp2Rq4UoXMfP5fSpzQX_CNfl-UXw=.4b2a2871-1647-4c2f-a368-44ef8c7896c4@github.com>
 <6bK-iNlPfRxkowIW1_7WYUulcJ9qpcvCBgcG44Q0mHs=.e04e5fc2-d532-4684-bab1-3fd94ba58048@github.com>
Message-ID: <fvSzRbXWlxfgE4uwbkgtTa3O7kuFozKJHg_17HMspp0=.ee143b6f-b325-4820-a67f-67a2e849b746@github.com>

On Thu, 7 Apr 2022 23:03:26 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Maxim Kartashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Merge branch 'master' into JDK-8280468
>>  - Addressed PR comments
>>    
>>    1. Got rid of X11GraphicsDevice.configLock in favour of the AWT lock.
>>    2. Reduced the use of the screen number (and, consequently, AWT lock
>>    contention) in XCanvasPeer.
>>  - 8280468: Crashes in getConfigColormap, getConfigVisualId, XVisualIDFromVisual on Linux
>>    
>>    This fix addresses two possible causes of crashes:
>>    1. makeDefaultConfig() returning NULL. The fix is to die gracefully
>>    instead of crashing in an attempt to de-reference a NULL pointer.
>>    
>>    2. A race condition when the number of screens change (this is only an
>>    issue with the number of xinerama screens; the number of X11 screens is
>>    static for the duration of the X session).
>>    
>>    The race scenario: X11GraphisDevice.makeDefaultConfiguration() is called
>>    on EDT so the call can race with X11GraphisDevice.invalidate() that
>>    re-sets the screen number of the device; the latter is invoked on the
>>    "AWT-XAWT" thread from X11GraphicsEnvironment.rebuildDevices(). So by
>>    the time makeDefaultConfiguration() makes a native call with the
>>    device's current screen number, the x11Screens array maintained by the
>>    native code could have become shorter. And the native methods like
>>    Java_sun_awt_X11GraphicsDevice_getConfigColormap() assume that the
>>    screen number passed to them is always current and valid. The AWT lock
>>    only protects against the changes during the native methods invocation,
>>    but does not protect against them being called with an outdated screen
>>    number.
>>    
>>    The fix is to eliminate the race by protecting X11GraphisDevice.screen
>>    with the AWT lock.
>
> src/java.desktop/unix/classes/sun/awt/X11/XCanvasPeer.java line 90:
> 
>> 88:             XToolkit.awtUnlock();
>> 89:         }
>> 90:     }
> 
> I am not sure I understand the purpose of this method, it requests the current device for the GC, then requests the screen index of the device, and then request device by the screen index, what is the reason to do that? Why we cannot just use the device from the GC?

This is just a named copy of lines 67 to 75. Since now this is the only piece of code that needs to work holding the AWT lock, I thought it best to isolate it.
As I understand, the purpose of the piece is to find the "new" `X11GraphicsDevice` with the screen number same to the given "old" `GraphicsConfiguration`.

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

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


From duke at openjdk.java.net  Fri Apr  8 06:55:34 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Fri, 8 Apr 2022 06:55:34 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v3]
In-Reply-To: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
Message-ID: <OUpXL2W_N30tcp2aQjYtJccJGG763tSeDxsF3VSIkSk=.5c69e270-2ab8-4562-a28d-9cc500028e55@github.com>

> getText function returned extra endOfLine when appended. The reason was in `EditorEditorKit` class, `write(Writer out, Document doc, int pos, int len)` method, where translation happens from buffer to Out(Writer Object) if endOfLine is other than '\n' ( which is '\r\n' in windows). In order to write each line till End of line, the string till '\n' is written including '\r' and again endOfLine is written which results in extra Carriage Return. To solve this issue, a Condition is added which checks if previous character to '\n' is '\r', if true then whole string except Carriage Return ('\r') is written, else whole string till before '\n' is written.

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

  Java coding style fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8122/files
  - new: https://git.openjdk.java.net/jdk/pull/8122/files/953fec43..f1b6e3ea

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

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

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


From mvs at openjdk.java.net  Fri Apr  8 07:08:25 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Fri, 8 Apr 2022 07:08:25 GMT
Subject: RFR: 8284521: Write an automated regression test for RFE 4371575
 [v2]
In-Reply-To: <FgW8JkNC98cWCRNm8Tpsu75-EYCzO2wP4X-sM9rDkZs=.f66039d3-903b-42b3-b2f4-3af624d6fd4b@github.com>
References: <FgW8JkNC98cWCRNm8Tpsu75-EYCzO2wP4X-sM9rDkZs=.f66039d3-903b-42b3-b2f4-3af624d6fd4b@github.com>
Message-ID: <Qv2iYnccQRtvScBKqUy6djNmBu0x2Ldpqg3AgVc3W8E=.0b8277a2-6447-4943-867d-f606358ad598@github.com>

> Write an automated regression test for [JDK-4371575](https://bugs.openjdk.java.net/browse/JDK-4371575)
> 
> Issue:
> As part of the Merlin focus project, JComponent.setRequestFocusEnabled was
> deprecated and its implementation was changed to map exactly to the new
> method Component.setFocusable. Scott believes that the old behavior may be
> preferable. He would like to be able to specify that a Component is focusable,
> and should receive focus during keyboard traversal, but that it should not
> automatically take focus when the user clicks on it with the mouse.
> 
> We are concerned that the accessibility team would be against this behavior,
> and this also seems like more of a PLAF issue. Nevertheless, we should look
> into it before beta ships.
> 
> Fix:
> After some discussion we decided that the best balance of the old and new would be to make this an advisory property. This property will not be synonymous with focusable. Instead our mouse listeners will check this property before requesting focus. This provides as closely as possible the old behavior, while allowing people to use the new focusable property if they don't want a component focusable at all.
> 
> Testing:
> Tested in mach5, 10 times with all the 3 available platform like macosx, windows and linux and got all Pass.

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

  Review comment fixed: Removed unwanted directory

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8143/files
  - new: https://git.openjdk.java.net/jdk/pull/8143/files/79dd4c74..1f0e102f

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

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

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


From mvs at openjdk.java.net  Fri Apr  8 07:12:21 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Fri, 8 Apr 2022 07:12:21 GMT
Subject: RFR: 8283507: Create a regression test for RFE 4287690 [v3]
In-Reply-To: <SMPz0WRpMUC4SuuVSmlG6rsG_QudZ-1hCbjUzeMIdqk=.8318c1a4-4db6-4c0b-b24c-0b25b3d932a2@github.com>
References: <SMPz0WRpMUC4SuuVSmlG6rsG_QudZ-1hCbjUzeMIdqk=.8318c1a4-4db6-4c0b-b24c-0b25b3d932a2@github.com>
Message-ID: <8I-5r07BeDPRL2uLjrILbcFMQAYszp2c5xpI8v_ZM0c=.c0d2f711-1281-435b-9c83-b31d94d4a3eb@github.com>

> Create a regression test for [JDK-4287690](https://bugs.openjdk.java.net/browse/JDK-4287690)
> Issue description:
> I want JComboBox to send an event just before the popup (drop down) list is displayed.
> 
> Fix:
> This requires some additional API targeted for major release of the JDK (1.4).The PopupMenuEvent will from the JPopupMenu will be forwarded to the JComboBox. A client of the JComboBox can register itself as a PopupMenuListener to receive the notification.
> So JComboBox should send drop down events when the drop down popup is visible as well as invisible. JComboBox.addPopupMenuListener(PopupMenuListener) can be used to register for pop up events.
> 
> Testing:
> Tested using Mach5 in all platforms available(macos,linux and windows) and got all pass.

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

  Review comment fixed: Removed unwanted directory

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7906/files
  - new: https://git.openjdk.java.net/jdk/pull/7906/files/38a5e19e..cba696d7

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

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

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


From mvs at openjdk.java.net  Fri Apr  8 07:14:28 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Fri, 8 Apr 2022 07:14:28 GMT
Subject: RFR: 8283624: Create an automated regression test for RFE-4390885
 [v2]
In-Reply-To: <DfOvs0ck3_ucgdZG8gdlmXPriMoEM9-RjaveRlmRZYA=.b6690b6a-4a51-4c98-b5ee-6409fe4b0f84@github.com>
References: <DfOvs0ck3_ucgdZG8gdlmXPriMoEM9-RjaveRlmRZYA=.b6690b6a-4a51-4c98-b5ee-6409fe4b0f84@github.com>
Message-ID: <eQHQrJiEwEu6-kwABzL-6y9ejTW3GG1ST1nKi9lDus4=.b3f954b0-8616-4fda-8df7-a395a9a3c18f@github.com>

> Write a regression test for [JDK-4390885](https://bugs.openjdk.java.net/browse/JDK-4390885) Enhancement Request.
> 
> Issue:
> Please add the ability to set the location of a JFileChooser. This might be a
> bug, but JFileChooser.setLocation() has no effect when
> JFileChooser.showXXXXDialog() is called. This is becoming very important as the
> popularity of multiple monitors is increasing. These dialogs show up on the
> wrong monitor which is really annoying. Also due to bug #4189244 I am unable to
> avoid painting problems by positioning the dialog away from the menu item that
> initiated it.
> 
> Fix:
> Now it's possible to set the location of Dialog in JFileChooser.
> 
> Testing:
> 1. Tested in Mach5 10 times per platform(macos,linux,windows) and got all Pass.

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

  Review comment fixed: Removed unwanted directory

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7996/files
  - new: https://git.openjdk.java.net/jdk/pull/7996/files/a30b69ba..76337e2f

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

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

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


From mvs at openjdk.java.net  Fri Apr  8 07:15:42 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Fri, 8 Apr 2022 07:15:42 GMT
Subject: RFR: 8284521: Write an automated regression test for RFE 4371575
 [v2]
In-Reply-To: <TIYu5o-Rn-M9gD9LXG4_dnDrvMm9_zrYbwyhGsyN3Go=.a59a0d07-ebf1-46c6-8728-a423fc9a1998@github.com>
References: <FgW8JkNC98cWCRNm8Tpsu75-EYCzO2wP4X-sM9rDkZs=.f66039d3-903b-42b3-b2f4-3af624d6fd4b@github.com>
 <TIYu5o-Rn-M9gD9LXG4_dnDrvMm9_zrYbwyhGsyN3Go=.a59a0d07-ebf1-46c6-8728-a423fc9a1998@github.com>
Message-ID: <Ffn11LLmsmiTh2EO2RYKYLvZJ9T6Pi6MZyj8FEo2_4s=.01abc7cd-1f1d-437e-a5ac-8eeb33c2ac56@github.com>

On Thu, 7 Apr 2022 21:01:30 GMT, Phil Race <prr at openjdk.org> wrote:

> Before I look at the test, can you get rid of the pointless directory 4371575 A directory might be needed if you had a lot of files for the test - but you don't ! And I really don't like naming directories OR tests with the bugid. Someone can find that out from the @bug tag.
> 
> I know you've pushed a bunch of bugs already that follow this pattern but update all the "in progress" ones to NOT create pointless extra folders.

I have removed those directories from this PR and from my other open PRs https://github.com/openjdk/jdk/pull/7906 and https://github.com/openjdk/jdk/pull/7996

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

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


From psadhukhan at openjdk.java.net  Fri Apr  8 07:59:43 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 8 Apr 2022 07:59:43 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v8]
In-Reply-To: <7ot0fBLQsvKiNsxLdrbnv4R_MNr6qdLN_GBwNPjU-rY=.dcad59a1-d0d6-42b9-bdf4-6290f31a88e0@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <afJ29wQf2smgANBt5YTQC4oODoch8zxa0YqdtUZDfW8=.f4d0de4d-5245-4491-a8e8-05aaf2a4797a@github.com>
 <gzymK8AsH16kj6YIbJoMuRVGTDkKwLd_O3rbbDZCWIQ=.1f491527-2bac-4e6d-a5cc-f8443bf4f352@github.com>
 <MENhs6_2RTKjMOcWkh1CzumSIwQOy75T_wLac37Vkl8=.0da493e3-d91d-4b48-bd58-f69cefce3a9b@github.com>
 <wrQgwI3XG2G9_X8n5n4Q_AzDnMElxB92075XY3bkJMQ=.f5fb8350-489d-44a1-935a-e752b78347cd@github.com>
 <fR3AZPwa0kAz6SJDa5ns4eyyjCIAY_s25IlS2SL2xSw=.c8689931-ded8-448f-8caa-a17b47f7631a@github.com>
 <7ot0fBLQsvKiNsxLdrbnv4R_MNr6qdLN_GBwNPjU-rY=.dcad59a1-d0d6-42b9-bdf4-6290f31a88e0@github.com>
Message-ID: <aKWrOQ_B3iWzXECCc6lUYE3ii6MOT3uBflVM4oSs7Ck=.07eb26cc-a502-494e-9dfc-b46b2d2dd6b5@github.com>

On Fri, 8 Apr 2022 00:36:54 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> Following type properties where checked for cellFocusRing color
>> 
>> - [alternateSelectedControlColor](https://developer.apple.com/documentation/appkit/nscolor/1533135-alternateselectedcontrolcolor) 
>> **Issue:** Doesn't follow accent color in macos 10.15 and deprecated property.
>> 
>> - [selectedContentBackgroundColor](https://developer.apple.com/documentation/appkit/nscolor/2998830-selectedcontentbackgroundcolor)
>> **Issue:** New property corresponding to **alternateSelectedControlColor** (deprecated). Causes build issues as the property is supported on macOS 10.14+ and the macOS deployment target version is 10.12 for jdk.
>> 
>> -  [controlAccentColor](https://developer.apple.com/documentation/appkit/nscolor/3000782-controlaccentcolor) 
>> **Issue:** Causes build issues due to version compatibility, property supported on only macOS 10.14+
>> 
>> - [accentColor](https://developer.apple.com/documentation/swiftui/color/accentcolor) 
>> **Issue:** Property supported on only macOS 10.15+, compatibility and run time issues.
>> 
>> - [keyboardfocusindicatorcolor](https://developer.apple.com/documentation/appkit/nscolor/1532031-keyboardfocusindicatorcolor) 
>> **Issue:** Works well for most of the scenarios (including on-the-fly changes) and follows the accent color changes except when we start the application with accent color set to Graphite and then change accent color on-the-fly (as mentioned above). The cell focus ring remains gray. The issue seems to be with the system color returned by the type-property "**keyboardfocusindicatorcolor**" under this setting.
>
> @prrace @prsadhuk 
> The issue with the system color returned by **keyboardFocusIndicatorColor** mentioned above, persists on macOS 12.3 as well.

"accentColor" is swift property so not usable for jdk but you can use "controlAccentColor" which seems to work with 10.15 and 12.1 as per my limited testing.
You need to use @available check though..
Even though it may not work for version lesser than 10.14, I guess it's ok as those versions are more or less obsolete..
While you are it, please consider renaming this function as told.

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

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


From psadhukhan at openjdk.java.net  Fri Apr  8 08:27:46 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 8 Apr 2022 08:27:46 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v13]
In-Reply-To: <CVS-7oiZefVrDpgYDXgHGMoBQfhciocgrUs9LArYvek=.d3d93632-8124-41b7-850a-3efe9d9d4f14@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <CVS-7oiZefVrDpgYDXgHGMoBQfhciocgrUs9LArYvek=.d3d93632-8124-41b7-850a-3efe9d9d4f14@github.com>
Message-ID: <_Vz970Es41a13LjV4BiYJNUXCwmctYXGzbTuCBw6DG0=.baf5d309-8697-44c1-9235-ac79e88ff3d0@github.com>

On Wed, 6 Apr 2022 10:27:12 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> Removed the println() line from the Interrupted catch block. Since waitForID() Interrupt indicates completion of Image Loading, println as Interrupt handling was not required.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on Reiview comments

if (interrupted && ((loadStatus & MediaTracker.LOADING )!= 0)) {

if (interrupted && ((loadStatus & MediaTracker.LOADING) != 0)) {

space at correct position

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

Changes requested by psadhukhan (Reviewer).

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


From psadhukhan at openjdk.java.net  Fri Apr  8 08:41:30 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 8 Apr 2022 08:41:30 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v3]
In-Reply-To: <OUpXL2W_N30tcp2aQjYtJccJGG763tSeDxsF3VSIkSk=.5c69e270-2ab8-4562-a28d-9cc500028e55@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <OUpXL2W_N30tcp2aQjYtJccJGG763tSeDxsF3VSIkSk=.5c69e270-2ab8-4562-a28d-9cc500028e55@github.com>
Message-ID: <EqmNNNCmIM8bCV7-zlbTfV0HzepRDgsCeTpMbnh1dd4=.9c56785d-bb8a-438b-80f0-92751053eedb@github.com>

On Fri, 8 Apr 2022 06:55:34 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> getText function returned extra endOfLine when appended. The reason was in `EditorEditorKit` class, `write(Writer out, Document doc, int pos, int len)` method, where translation happens from buffer to Out(Writer Object) if endOfLine is other than '\n' ( which is '\r\n' in windows). In order to write each line till End of line, the string till '\n' is written including '\r' and again endOfLine is written which results in extra Carriage Return. To solve this issue, a Condition is added which checks if previous character to '\n' is '\r', if true then whole string except Carriage Return ('\r') is written, else whole string till before '\n' is written.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Java coding style fix

src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java line 350:

> 348:                             }
> 349:                         }
> 350:                         out.write(endOfLine);

It seems in windows, we use EndOfLineStringProperty property as
[CRLF](https://github.com/openjdk/jdk/blob/f1b6e3ea16f06bc57e8e905fb115650e6c4ad98f/src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java#L286)
and `endOfLine ` is using the above property `EndOfLineStringProperty` so 
when you write out.write(endOfLine) will it not write \r\n again?

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

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


From duke at openjdk.java.net  Fri Apr  8 08:51:30 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Fri, 8 Apr 2022 08:51:30 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v14]
In-Reply-To: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
Message-ID: <UU_cYUuzKhHCbxtgfgxpLdjG1jGNVtm-miTiMYN4Zb0=.87dd0163-a1ec-4d16-978e-7d583018107f@github.com>

> Removed the println() line from the Interrupted catch block. Since waitForID() Interrupt indicates completion of Image Loading, println as Interrupt handling was not required.

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

  Updated based on Review Comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7754/files
  - new: https://git.openjdk.java.net/jdk/pull/7754/files/2b5f5927..2066e000

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7754&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7754&range=12-13

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

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


From duke at openjdk.java.net  Fri Apr  8 08:52:56 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Fri, 8 Apr 2022 08:52:56 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v3]
In-Reply-To: <EqmNNNCmIM8bCV7-zlbTfV0HzepRDgsCeTpMbnh1dd4=.9c56785d-bb8a-438b-80f0-92751053eedb@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <OUpXL2W_N30tcp2aQjYtJccJGG763tSeDxsF3VSIkSk=.5c69e270-2ab8-4562-a28d-9cc500028e55@github.com>
 <EqmNNNCmIM8bCV7-zlbTfV0HzepRDgsCeTpMbnh1dd4=.9c56785d-bb8a-438b-80f0-92751053eedb@github.com>
Message-ID: <IXfFE_UZd27T819kcYHpa_FTa8n2K8YqgLSctQULALk=.e778e8cc-d6fc-403f-a37d-983b85db48a6@github.com>

On Fri, 8 Apr 2022 08:38:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Java coding style fix
>
> src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java line 350:
> 
>> 348:                             }
>> 349:                         }
>> 350:                         out.write(endOfLine);
> 
> It seems in windows, we use EndOfLineStringProperty property as
> [CRLF](https://github.com/openjdk/jdk/blob/f1b6e3ea16f06bc57e8e905fb115650e6c4ad98f/src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java#L286)
> and `endOfLine ` is using the above property `EndOfLineStringProperty` so 
> when you write out.write(endOfLine) will it not write \r\n again?

Yes, Write function copies string without endOfLine, and endOfLine is appended to it after the whole string is copied. 
Before also it was copying string without endOfLine which included '\r', now this logic copies string characters before '\r' and then appends endOfLine.

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

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


From psadhukhan at openjdk.java.net  Fri Apr  8 09:04:16 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 8 Apr 2022 09:04:16 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v14]
In-Reply-To: <UU_cYUuzKhHCbxtgfgxpLdjG1jGNVtm-miTiMYN4Zb0=.87dd0163-a1ec-4d16-978e-7d583018107f@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <UU_cYUuzKhHCbxtgfgxpLdjG1jGNVtm-miTiMYN4Zb0=.87dd0163-a1ec-4d16-978e-7d583018107f@github.com>
Message-ID: <sp9W6T2KwDvb9-gNOHOmSaxv8g_Q2V5Rr2TJDwh2YCU=.0a350bd7-717c-4535-98b1-d95d4e0af234@github.com>

On Fri, 8 Apr 2022 08:51:30 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> Removed the println() line from the Interrupted catch block. Since waitForID() Interrupt indicates completion of Image Loading, println as Interrupt handling was not required.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on Review Comments

test/jdk/javax/swing/ImageIcon/LoadInterruptTest.java line 61:

> 59:         prevSysOut = System.out;
> 60:         testOut = new ByteArrayOutputStream();
> 61:         System.setOut(new PrintStream(testOut, true, StandardCharsets.UTF_8));

The spec says "First, if there is a security manager, its checkPermission method is called with a RuntimePermission("setIO") permission to see if it's ok to reassign the "standard" output stream."

Since security manager is removed, I guess either this doc needs updation or we still need to follow this checkPermission step...

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

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


From psadhukhan at openjdk.java.net  Fri Apr  8 09:06:36 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 8 Apr 2022 09:06:36 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v3]
In-Reply-To: <IXfFE_UZd27T819kcYHpa_FTa8n2K8YqgLSctQULALk=.e778e8cc-d6fc-403f-a37d-983b85db48a6@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <OUpXL2W_N30tcp2aQjYtJccJGG763tSeDxsF3VSIkSk=.5c69e270-2ab8-4562-a28d-9cc500028e55@github.com>
 <EqmNNNCmIM8bCV7-zlbTfV0HzepRDgsCeTpMbnh1dd4=.9c56785d-bb8a-438b-80f0-92751053eedb@github.com>
 <IXfFE_UZd27T819kcYHpa_FTa8n2K8YqgLSctQULALk=.e778e8cc-d6fc-403f-a37d-983b85db48a6@github.com>
Message-ID: <GMtmoL_K_XLl96SWCT4fidmhFFtqDENfVBYOSp0U-c8=.d2e739db-27aa-4f16-8e1e-2a7222618fd5@github.com>

On Fri, 8 Apr 2022 08:49:36 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java line 350:
>> 
>>> 348:                             }
>>> 349:                         }
>>> 350:                         out.write(endOfLine);
>> 
>> It seems in windows, we use EndOfLineStringProperty property as
>> [CRLF](https://github.com/openjdk/jdk/blob/f1b6e3ea16f06bc57e8e905fb115650e6c4ad98f/src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java#L286)
>> and `endOfLine ` is using the above property `EndOfLineStringProperty` so 
>> when you write out.write(endOfLine) will it not write \r\n again?
>
> Yes, Write function copies string without endOfLine, and endOfLine is appended to it after the whole string is copied. 
> Before also it was copying string without endOfLine which included '\r', now this logic copies string characters before '\r' and then appends endOfLine.

ok, so you are telling out.write(array, last, counter - last - 1) will write till \r\n and out.write(endOfLine) will write \r\n, is it?
ANyway, you need to modify this change as per coding style which is 

else {
}

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

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


From smandalika at openjdk.java.net  Fri Apr  8 09:51:14 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Fri, 8 Apr 2022 09:51:14 GMT
Subject: RFR: 8284524: Create an automated test for JDK-4422362
Message-ID: <Zc6TLIeUCxotLqICjVkZF4g1hUTkdB7mANhMull6Qzc=.14959182-424c-42f6-979f-7d6eeb266dfb@github.com>

Create an automated test for [JDK-4422362](https://bugs.openjdk.java.net/browse/JDK-4422362)

The BoundedRangeModel components (JScrollBar, JSlider, JProgressBar) return
BoundedRangeModel.getMaximum() from getMaximumAccessibleValue() in their
AccessibleValue implementation.
The real maximum value (due to the constraints on BoundedRangeModel) is
model.getMaximum() - model.getExtent().

The test verifies that the above is adhered to as expected.

This review is for migrating tests from a closed test suite to open.

Testing:
The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

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

Commit messages:
 - 8284524: Create an automated test for JDK-4422362

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

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


From aivanov at openjdk.java.net  Fri Apr  8 10:13:51 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 8 Apr 2022 10:13:51 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v14]
In-Reply-To: <sp9W6T2KwDvb9-gNOHOmSaxv8g_Q2V5Rr2TJDwh2YCU=.0a350bd7-717c-4535-98b1-d95d4e0af234@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <UU_cYUuzKhHCbxtgfgxpLdjG1jGNVtm-miTiMYN4Zb0=.87dd0163-a1ec-4d16-978e-7d583018107f@github.com>
 <sp9W6T2KwDvb9-gNOHOmSaxv8g_Q2V5Rr2TJDwh2YCU=.0a350bd7-717c-4535-98b1-d95d4e0af234@github.com>
Message-ID: <kTElzP7UqyHdErfECvMmUY5SL6ljdF_M0q7EK_gScpA=.6b823a1b-3bed-4fde-badf-40cf393f5692@github.com>

On Fri, 8 Apr 2022 09:00:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on Review Comments
>
> test/jdk/javax/swing/ImageIcon/LoadInterruptTest.java line 61:
> 
>> 59:         prevSysOut = System.out;
>> 60:         testOut = new ByteArrayOutputStream();
>> 61:         System.setOut(new PrintStream(testOut, true, StandardCharsets.UTF_8));
> 
> The spec says "First, if there is a security manager, its checkPermission method is called with a RuntimePermission("setIO") permission to see if it's ok to reassign the "standard" output stream."
> 
> Since security manager is removed, I guess either this doc needs updation or we still need to follow this checkPermission step...

What are you referring to?

The javadoc to [`System.setOut`](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/System.html#setOut(java.io.PrintStream)) does indeed state this. [The implementation](https://github.com/openjdk/jdk/blob/4dbebb62aa264adda8d96a06f608ef9d13155a26/src/java.base/share/classes/java/lang/System.java#L244) does exactly what it says: it calls `checkIO` method which verifies whether `"setIO"` permission is granted if `SecurityManager` is installed.

I can't see what we should do about it. `SecurityManager` hasn't been removed yet.

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

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


From duke at openjdk.java.net  Fri Apr  8 10:21:22 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Fri, 8 Apr 2022 10:21:22 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v4]
In-Reply-To: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
Message-ID: <kBSX-LXH1_2r3o2k7QRoZNbV7b3z0nSDPBlCvXKyMTo=.3e32b286-87cc-4778-a299-958aa5b7a51f@github.com>

> getText function returned extra endOfLine when appended. The reason was in `EditorEditorKit` class, `write(Writer out, Document doc, int pos, int len)` method, where translation happens from buffer to Out(Writer Object) if endOfLine is other than '\n' ( which is '\r\n' in windows). In order to write each line till End of line, the string till '\n' is written including '\r' and again endOfLine is written which results in extra Carriage Return. To solve this issue, a Condition is added which checks if previous character to '\n' is '\r', if true then whole string except Carriage Return ('\r') is written, else whole string till before '\n' is written.

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

  Updated based on Review Comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8122/files
  - new: https://git.openjdk.java.net/jdk/pull/8122/files/f1b6e3ea..2369b965

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

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

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


From duke at openjdk.java.net  Fri Apr  8 10:21:22 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Fri, 8 Apr 2022 10:21:22 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v3]
In-Reply-To: <GMtmoL_K_XLl96SWCT4fidmhFFtqDENfVBYOSp0U-c8=.d2e739db-27aa-4f16-8e1e-2a7222618fd5@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <OUpXL2W_N30tcp2aQjYtJccJGG763tSeDxsF3VSIkSk=.5c69e270-2ab8-4562-a28d-9cc500028e55@github.com>
 <EqmNNNCmIM8bCV7-zlbTfV0HzepRDgsCeTpMbnh1dd4=.9c56785d-bb8a-438b-80f0-92751053eedb@github.com>
 <IXfFE_UZd27T819kcYHpa_FTa8n2K8YqgLSctQULALk=.e778e8cc-d6fc-403f-a37d-983b85db48a6@github.com>
 <GMtmoL_K_XLl96SWCT4fidmhFFtqDENfVBYOSp0U-c8=.d2e739db-27aa-4f16-8e1e-2a7222618fd5@github.com>
Message-ID: <jXaJAVSTRmEDX_Y7jBLVKJ9TUr8tfBZauhputSXtwVY=.b8c4ef18-087d-4837-abd2-1677ae9ed0db@github.com>

On Fri, 8 Apr 2022 09:02:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> ok, so you are telling out.write(array, last, counter - last - 1) will write till \r\n and out.write(endOfLine) will write \r\n, is it?

Yes.

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

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


From psadhukhan at openjdk.java.net  Fri Apr  8 11:22:39 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 8 Apr 2022 11:22:39 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v14]
In-Reply-To: <kTElzP7UqyHdErfECvMmUY5SL6ljdF_M0q7EK_gScpA=.6b823a1b-3bed-4fde-badf-40cf393f5692@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <UU_cYUuzKhHCbxtgfgxpLdjG1jGNVtm-miTiMYN4Zb0=.87dd0163-a1ec-4d16-978e-7d583018107f@github.com>
 <sp9W6T2KwDvb9-gNOHOmSaxv8g_Q2V5Rr2TJDwh2YCU=.0a350bd7-717c-4535-98b1-d95d4e0af234@github.com>
 <kTElzP7UqyHdErfECvMmUY5SL6ljdF_M0q7EK_gScpA=.6b823a1b-3bed-4fde-badf-40cf393f5692@github.com>
Message-ID: <aYFQ8Hla1LTqguUC0efo3nGkqKONxcuYM7xn9PPDZdk=.d14d7efd-ebad-436b-b93d-4347dce76969@github.com>

On Fri, 8 Apr 2022 10:10:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/ImageIcon/LoadInterruptTest.java line 61:
>> 
>>> 59:         prevSysOut = System.out;
>>> 60:         testOut = new ByteArrayOutputStream();
>>> 61:         System.setOut(new PrintStream(testOut, true, StandardCharsets.UTF_8));
>> 
>> The spec says "First, if there is a security manager, its checkPermission method is called with a RuntimePermission("setIO") permission to see if it's ok to reassign the "standard" output stream."
>> 
>> Since security manager is removed, I guess either this doc needs updation or we still need to follow this checkPermission step...
>
> What are you referring to?
> 
> The javadoc to [`System.setOut`](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/System.html#setOut(java.io.PrintStream)) does indeed state this. [The implementation](https://github.com/openjdk/jdk/blob/4dbebb62aa264adda8d96a06f608ef9d13155a26/src/java.base/share/classes/java/lang/System.java#L244) does exactly what it says: it calls `checkIO` method which verifies whether `"setIO"` permission is granted if `SecurityManager` is installed.
> 
> I can't see what we should do about it. `SecurityManager` hasn't been removed yet.

Yeah, right..I was thinking something else..

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

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


From psadhukhan at openjdk.java.net  Fri Apr  8 11:22:38 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 8 Apr 2022 11:22:38 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v14]
In-Reply-To: <UU_cYUuzKhHCbxtgfgxpLdjG1jGNVtm-miTiMYN4Zb0=.87dd0163-a1ec-4d16-978e-7d583018107f@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <UU_cYUuzKhHCbxtgfgxpLdjG1jGNVtm-miTiMYN4Zb0=.87dd0163-a1ec-4d16-978e-7d583018107f@github.com>
Message-ID: <tZHaFYEr9mHfY4nNc2RTiGIFnu8iF1xf4Lxzw55Xs74=.496c8b59-299c-4b29-9120-3f1ed67ee154@github.com>

On Fri, 8 Apr 2022 08:51:30 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> Removed the println() line from the Interrupted catch block. Since waitForID() Interrupt indicates completion of Image Loading, println as Interrupt handling was not required.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on Review Comments

Marked as reviewed by psadhukhan (Reviewer).

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

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


From psadhukhan at openjdk.java.net  Fri Apr  8 11:34:42 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 8 Apr 2022 11:34:42 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v3]
In-Reply-To: <jXaJAVSTRmEDX_Y7jBLVKJ9TUr8tfBZauhputSXtwVY=.b8c4ef18-087d-4837-abd2-1677ae9ed0db@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <OUpXL2W_N30tcp2aQjYtJccJGG763tSeDxsF3VSIkSk=.5c69e270-2ab8-4562-a28d-9cc500028e55@github.com>
 <EqmNNNCmIM8bCV7-zlbTfV0HzepRDgsCeTpMbnh1dd4=.9c56785d-bb8a-438b-80f0-92751053eedb@github.com>
 <IXfFE_UZd27T819kcYHpa_FTa8n2K8YqgLSctQULALk=.e778e8cc-d6fc-403f-a37d-983b85db48a6@github.com>
 <GMtmoL_K_XLl96SWCT4fidmhFFtqDENfVBYOSp0U-c8=.d2e739db-27aa-4f16-8e1e-2a7222618fd5@github.com>
 <jXaJAVSTRmEDX_Y7jBLVKJ9TUr8tfBZauhputSXtwVY=.b8c4ef18-087d-4837-abd2-1677ae9ed0db@github.com>
Message-ID: <BFarBNnmxvPBOc1wVuNemz3bxj3_T3ZzCgLjRquG8o0=.aeab0c75-fd25-421c-914f-5ef737e29d8a@github.com>

On Fri, 8 Apr 2022 10:14:58 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> ok, so you are telling out.write(array, last, counter - last - 1) will write till \r\n and out.write(endOfLine) will write \r\n, is it?
>> ANyway, you need to modify this change as per coding style which is 
>> 
>> else {
>> }
>
>> ok, so you are telling out.write(array, last, counter - last - 1) will write till \r\n and out.write(endOfLine) will write \r\n, is it?
> 
> Yes.

So, presently it was writing <String>/r/n/r/n and with fix, it will write <String>/r/n, right?

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

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


From duke at openjdk.java.net  Fri Apr  8 11:34:42 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Fri, 8 Apr 2022 11:34:42 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v3]
In-Reply-To: <BFarBNnmxvPBOc1wVuNemz3bxj3_T3ZzCgLjRquG8o0=.aeab0c75-fd25-421c-914f-5ef737e29d8a@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <OUpXL2W_N30tcp2aQjYtJccJGG763tSeDxsF3VSIkSk=.5c69e270-2ab8-4562-a28d-9cc500028e55@github.com>
 <EqmNNNCmIM8bCV7-zlbTfV0HzepRDgsCeTpMbnh1dd4=.9c56785d-bb8a-438b-80f0-92751053eedb@github.com>
 <IXfFE_UZd27T819kcYHpa_FTa8n2K8YqgLSctQULALk=.e778e8cc-d6fc-403f-a37d-983b85db48a6@github.com>
 <GMtmoL_K_XLl96SWCT4fidmhFFtqDENfVBYOSp0U-c8=.d2e739db-27aa-4f16-8e1e-2a7222618fd5@github.com>
 <jXaJAVSTRmEDX_Y7jBLVKJ9TUr8tfBZauhputSXtwVY=.b8c4ef18-087d-4837-abd2-1677ae9ed0db@github.com>
 <BFarBNnmxvPBOc1wVuNemz3bxj3_T3ZzCgLjRquG8o0=.aeab0c75-fd25-421c-914f-5ef737e29d8a@github.com>
Message-ID: <2ZRkMEq3rdKsQhuXPBOn7SDol6WonbSOL0eKTZiymps=.1bc7e7b5-2a51-45f1-a308-add92e8d5dd6@github.com>

On Fri, 8 Apr 2022 11:25:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> ok, so you are telling out.write(array, last, counter - last - 1) will write till \r\n and out.write(endOfLine) will write \r\n, is it?
>> 
>> Yes.
>
> So, presently it was writing <String>/r/n/r/n and with fix, it will write <String>/r/n, right?

No, presently it was writing /r/r/n and with fix it will write /r/n for every line ending...... /r was causing for carriage return and /r/n for an extra empty line on Text pane.......

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

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


From psadhukhan at openjdk.java.net  Fri Apr  8 11:34:42 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 8 Apr 2022 11:34:42 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v3]
In-Reply-To: <2ZRkMEq3rdKsQhuXPBOn7SDol6WonbSOL0eKTZiymps=.1bc7e7b5-2a51-45f1-a308-add92e8d5dd6@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <OUpXL2W_N30tcp2aQjYtJccJGG763tSeDxsF3VSIkSk=.5c69e270-2ab8-4562-a28d-9cc500028e55@github.com>
 <EqmNNNCmIM8bCV7-zlbTfV0HzepRDgsCeTpMbnh1dd4=.9c56785d-bb8a-438b-80f0-92751053eedb@github.com>
 <IXfFE_UZd27T819kcYHpa_FTa8n2K8YqgLSctQULALk=.e778e8cc-d6fc-403f-a37d-983b85db48a6@github.com>
 <GMtmoL_K_XLl96SWCT4fidmhFFtqDENfVBYOSp0U-c8=.d2e739db-27aa-4f16-8e1e-2a7222618fd5@github.com>
 <jXaJAVSTRmEDX_Y7jBLVKJ9TUr8tfBZauhputSXtwVY=.b8c4ef18-087d-4837-abd2-1677ae9ed0db@github.com>
 <BFarBNnmxvPBOc1wVuNemz3bxj3_T3ZzCgLjRquG8o0=.aeab0c75-fd25-421c-914f-5ef737e29d8a@github.com>
 <2ZRkMEq3rdKsQhuXPBOn7SDol6WonbSOL0eKTZiymps=.1bc7e7b5-2a51-45f1-a308-add92e8d5dd6@github.com>
Message-ID: <ZT_U1qu3zXFGavpWGxSqIYwrHVv_BHS41BCAa-vA4jI=.34cea0f4-071c-4cf8-998f-5fa6b65a2876@github.com>

On Fri, 8 Apr 2022 11:28:26 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> So, presently it was writing <String>/r/n/r/n and with fix, it will write <String>/r/n, right?
>
> No, presently it was writing /r/r/n and with fix it will write /r/n for every line ending...... /r was causing for carriage return and /r/n for an extra empty line on Text pane.......

But should /r/r/n cause 2 line feeds? /r should be just carriage return to cause caret to move from last column to first, why it is inserting new line?

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

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


From aivanov at openjdk.java.net  Fri Apr  8 11:36:41 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 8 Apr 2022 11:36:41 GMT
Subject: RFR: 8257810: Only First page are printed in
 JTable.scrollRectToVisible [v3]
In-Reply-To: <uWPCjkGRnWtTamjvYAZctXEN7deGgcVOfox-cELdY_Y=.8f79a1e1-3ce5-405a-9693-625dc9705335@github.com>
References: <HpEmX1DI9Q4PvHQIntUEknVW8jlIWQFXHuB1XgJlh40=.f7726194-7aad-4422-a8db-c02bbad0d110@github.com>
 <uWPCjkGRnWtTamjvYAZctXEN7deGgcVOfox-cELdY_Y=.8f79a1e1-3ce5-405a-9693-625dc9705335@github.com>
Message-ID: <PAOXKyAX6d7m3GxJXlHjBoEMkfP6ZUCr-tDoN0I-DkA=.53f2ec75-2114-4d6a-85b8-bbe10a5bc5da@github.com>

On Thu, 7 Apr 2022 14:59:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. 
>> This is because when the table is scrolled down to last page, the bounds.y becomes -ve 
>> [x=0,y=-15260,width=968,height=16000]
>> so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296]
>> but subsequent pages clip 
>> [[x=0,y=1296,width=968,height=1296], 
>> [x=0,y=2592,width=968,height=1296], 
>> [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed
>> 
>> This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI
>> We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907
>> 
>> Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS)
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test updated

Closing the dialog or the frame should fail the test as well.

test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 31:

> 29: import java.awt.BorderLayout;
> 30: import java.awt.FlowLayout;
> 31: import java.awt.Rectangle;

This is an unused import.

test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 75:

> 73:             ret = latch.await(5, TimeUnit.MINUTES);
> 74: 
> 75:             if (!ret) {

Suggestion:

            if (!latch.await(5, TimeUnit.MINUTES)) {

The variable is redundant now.

test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 79:

> 77:             }
> 78: 
> 79:             if (testResult == false) {

Suggestion:

            if (!testResult) {

Looks cleaner, doesn't it? And produces no warning in the IDE.

test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 85:

> 83:             SwingUtilities.invokeAndWait(() -> {
> 84:                 dispose();
> 85:             });

I prefer method references in this case yet I don't insist.

However, this fits perfectly with the usages above.

test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 147:

> 145:         failButton.addActionListener((e) -> {
> 146:             testResult = false;
> 147:             dispose();

Now that the UI is always dispose of in a finally block, the button handlers can skip the call to `dispose()`.

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

Changes requested by aivanov (Reviewer).

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


From aivanov at openjdk.java.net  Fri Apr  8 11:43:39 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 8 Apr 2022 11:43:39 GMT
Subject: RFR: 8257810: Only First page are printed in
 JTable.scrollRectToVisible [v3]
In-Reply-To: <uWPCjkGRnWtTamjvYAZctXEN7deGgcVOfox-cELdY_Y=.8f79a1e1-3ce5-405a-9693-625dc9705335@github.com>
References: <HpEmX1DI9Q4PvHQIntUEknVW8jlIWQFXHuB1XgJlh40=.f7726194-7aad-4422-a8db-c02bbad0d110@github.com>
 <uWPCjkGRnWtTamjvYAZctXEN7deGgcVOfox-cELdY_Y=.8f79a1e1-3ce5-405a-9693-625dc9705335@github.com>
Message-ID: <SNWQp2ifmNiEuqp7YObXaCmjvAWKOQ__kJ_pgZsto74=.f435e8b1-f5ae-43cc-a74e-30dbdada8d29@github.com>

On Thu, 7 Apr 2022 14:59:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. 
>> This is because when the table is scrolled down to last page, the bounds.y becomes -ve 
>> [x=0,y=-15260,width=968,height=16000]
>> so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296]
>> but subsequent pages clip 
>> [[x=0,y=1296,width=968,height=1296], 
>> [x=0,y=2592,width=968,height=1296], 
>> [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed
>> 
>> This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI
>> We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907
>> 
>> Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS)
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test updated

You should consider adding the evaluation from this PR description to JBS.

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

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


From aivanov at openjdk.java.net  Fri Apr  8 11:46:41 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 8 Apr 2022 11:46:41 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v3]
In-Reply-To: <ZT_U1qu3zXFGavpWGxSqIYwrHVv_BHS41BCAa-vA4jI=.34cea0f4-071c-4cf8-998f-5fa6b65a2876@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <OUpXL2W_N30tcp2aQjYtJccJGG763tSeDxsF3VSIkSk=.5c69e270-2ab8-4562-a28d-9cc500028e55@github.com>
 <EqmNNNCmIM8bCV7-zlbTfV0HzepRDgsCeTpMbnh1dd4=.9c56785d-bb8a-438b-80f0-92751053eedb@github.com>
 <IXfFE_UZd27T819kcYHpa_FTa8n2K8YqgLSctQULALk=.e778e8cc-d6fc-403f-a37d-983b85db48a6@github.com>
 <GMtmoL_K_XLl96SWCT4fidmhFFtqDENfVBYOSp0U-c8=.d2e739db-27aa-4f16-8e1e-2a7222618fd5@github.com>
 <jXaJAVSTRmEDX_Y7jBLVKJ9TUr8tfBZauhputSXtwVY=.b8c4ef18-087d-4837-abd2-1677ae9ed0db@github.com>
 <BFarBNnmxvPBOc1wVuNemz3bxj3_T3ZzCgLjRquG8o0=.aeab0c75-fd25-421c-914f-5ef737e29d8a@github.com>
 <2ZRkMEq3rdKsQhuXPBOn7SDol6WonbSOL0eKTZiymps=.1bc7e7b5-2a51-45f1-a308-add92e8d5dd6@github.com>
 <ZT_U1qu3zXFGavpWGxSqIYwrHVv_BHS41BCAa-vA4jI=.34cea0f4-071c-4cf8-998f-5fa6b65a2876@github.com>
Message-ID: <-FpNep3YcVVj4Ks6j0DwT9JFOvoDjvtKlkiDTnzgPBM=.33b32aa5-f23c-4593-9bf9-d965e5b43859@github.com>

On Fri, 8 Apr 2022 11:31:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> No, presently it was writing /r/r/n and with fix it will write /r/n for every line ending...... /r was causing for carriage return and /r/n for an extra empty line on Text pane.......
>
> But should /r/r/n cause 2 line feeds? /r should be just carriage return to cause caret to move from last column to first, why it is inserting new line?

It is common to treat `\r` as new line if it's not followed by `\n`. In a visual editor `\r` doesn't do anything.

Yet it's an interesting detail that wasn't covered in the initial evaluation.

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

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


From aivanov at openjdk.java.net  Fri Apr  8 11:49:52 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 8 Apr 2022 11:49:52 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v14]
In-Reply-To: <UU_cYUuzKhHCbxtgfgxpLdjG1jGNVtm-miTiMYN4Zb0=.87dd0163-a1ec-4d16-978e-7d583018107f@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <UU_cYUuzKhHCbxtgfgxpLdjG1jGNVtm-miTiMYN4Zb0=.87dd0163-a1ec-4d16-978e-7d583018107f@github.com>
Message-ID: <5Uq9hA-i67ieaWfqL4n4KBQBCqQ9hoM2zg9WEOT2JJM=.57da27fa-f141-4ff1-9b4f-00c3fc36215b@github.com>

On Fri, 8 Apr 2022 08:51:30 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> Removed the println() line from the Interrupted catch block. Since waitForID() Interrupt indicates completion of Image Loading, println as Interrupt handling was not required.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on Review Comments

Marked as reviewed by aivanov (Reviewer).

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

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


From aivanov at openjdk.java.net  Fri Apr  8 11:51:41 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 8 Apr 2022 11:51:41 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v2]
In-Reply-To: <j97LbflNBQ6fh8KsWHH1YIaXVM6wjCZUOHVrvqzIfLY=.06847a3d-73bd-4102-90eb-06212ceb4f85@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <_UplvB0h9bWCInEGLRAN4bN3_sMypgu0hf0nU57pJgI=.8eef0557-500c-4939-b00f-ae9c0dd5a5b8@github.com>
 <p1lJJBIqQpVg6kwYcdWaFsZbLIfE0AkN3Tyl3gXmakE=.98fff17e-812b-4f8b-97b6-4bc61e45ce03@github.com>
 <j97LbflNBQ6fh8KsWHH1YIaXVM6wjCZUOHVrvqzIfLY=.06847a3d-73bd-4102-90eb-06212ceb4f85@github.com>
Message-ID: <ZdRINoL3gR4NKDSIii_LU0HA_r5dwjgZKhcGO6ZpC9g=.7ff404d4-59ab-4f65-8e35-4b54db4f7531@github.com>

On Thu, 7 Apr 2022 16:04:35 GMT, Tejesh R <duke at openjdk.java.net> wrote:

> > 
> 
> > Why can't the test be automatic?
> 
> Actually had thought about automating the test case, but since endOfLine(Win - '\r\n', linux - '\n') is different for different OS, have made it manual.

It just means the original issue is observed on Windows only.

Does it make sense to require Windows to run this test?

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

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


From psadhukhan at openjdk.java.net  Fri Apr  8 11:54:41 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 8 Apr 2022 11:54:41 GMT
Subject: RFR: 8257810: Only First page are printed in
 JTable.scrollRectToVisible [v4]
In-Reply-To: <HpEmX1DI9Q4PvHQIntUEknVW8jlIWQFXHuB1XgJlh40=.f7726194-7aad-4422-a8db-c02bbad0d110@github.com>
References: <HpEmX1DI9Q4PvHQIntUEknVW8jlIWQFXHuB1XgJlh40=.f7726194-7aad-4422-a8db-c02bbad0d110@github.com>
Message-ID: <gnuDmna2omWAGrG1tG13mlQHyO1t1keUH_4cGo7FiG4=.565f59da-1a9d-4dfa-a461-b65d5667f087@github.com>

> Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. 
> This is because when the table is scrolled down to last page, the bounds.y becomes -ve 
> [x=0,y=-15260,width=968,height=16000]
> so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296]
> but subsequent pages clip 
> [[x=0,y=1296,width=968,height=1296], 
> [x=0,y=2592,width=968,height=1296], 
> [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed
> 
> This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI
> We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907
> 
> Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS)

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

  Test fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8141/files
  - new: https://git.openjdk.java.net/jdk/pull/8141/files/635b90aa..46edf56f

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

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

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


From psadhukhan at openjdk.java.net  Fri Apr  8 11:58:03 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 8 Apr 2022 11:58:03 GMT
Subject: RFR: 8257810: Only First page are printed in
 JTable.scrollRectToVisible [v5]
In-Reply-To: <HpEmX1DI9Q4PvHQIntUEknVW8jlIWQFXHuB1XgJlh40=.f7726194-7aad-4422-a8db-c02bbad0d110@github.com>
References: <HpEmX1DI9Q4PvHQIntUEknVW8jlIWQFXHuB1XgJlh40=.f7726194-7aad-4422-a8db-c02bbad0d110@github.com>
Message-ID: <2aOfA0_sisjZW3Ahw_yLLf0MyEereMcL1Jra0AoofPE=.83e4ed58-96b1-4c0e-b41c-7ed93cb371cf@github.com>

> Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. 
> This is because when the table is scrolled down to last page, the bounds.y becomes -ve 
> [x=0,y=-15260,width=968,height=16000]
> so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296]
> but subsequent pages clip 
> [[x=0,y=1296,width=968,height=1296], 
> [x=0,y=2592,width=968,height=1296], 
> [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed
> 
> This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI
> We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907
> 
> Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS)

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

  Test fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8141/files
  - new: https://git.openjdk.java.net/jdk/pull/8141/files/46edf56f..c8cffba7

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

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

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


From psadhukhan at openjdk.java.net  Fri Apr  8 12:01:45 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 8 Apr 2022 12:01:45 GMT
Subject: RFR: 8257810: Only First page are printed in
 JTable.scrollRectToVisible [v3]
In-Reply-To: <SNWQp2ifmNiEuqp7YObXaCmjvAWKOQ__kJ_pgZsto74=.f435e8b1-f5ae-43cc-a74e-30dbdada8d29@github.com>
References: <HpEmX1DI9Q4PvHQIntUEknVW8jlIWQFXHuB1XgJlh40=.f7726194-7aad-4422-a8db-c02bbad0d110@github.com>
 <uWPCjkGRnWtTamjvYAZctXEN7deGgcVOfox-cELdY_Y=.8f79a1e1-3ce5-405a-9693-625dc9705335@github.com>
 <SNWQp2ifmNiEuqp7YObXaCmjvAWKOQ__kJ_pgZsto74=.f435e8b1-f5ae-43cc-a74e-30dbdada8d29@github.com>
Message-ID: <OGzTGs-aOWrHokmsqqljODrpf0HJbDV5QO0-Gs-fFOA=.4de8e3aa-c289-469a-8db3-be9e8f3a05c9@github.com>

On Fri, 8 Apr 2022 11:40:47 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> You should consider adding the evaluation from this PR description to JBS.

yeah sure.

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

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


From aivanov at openjdk.java.net  Fri Apr  8 12:02:41 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 8 Apr 2022 12:02:41 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v4]
In-Reply-To: <kBSX-LXH1_2r3o2k7QRoZNbV7b3z0nSDPBlCvXKyMTo=.3e32b286-87cc-4778-a299-958aa5b7a51f@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <kBSX-LXH1_2r3o2k7QRoZNbV7b3z0nSDPBlCvXKyMTo=.3e32b286-87cc-4778-a299-958aa5b7a51f@github.com>
Message-ID: <ZflEaZvqcrSgV31kAbgsmVCwKKJ0evWHTx8W45Vfl10=.d16ffd11-4c7e-45d8-a8c0-bd6d178cc7ab@github.com>

On Fri, 8 Apr 2022 10:21:22 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> getText function returned extra endOfLine when appended. The reason was in `EditorEditorKit` class, `write(Writer out, Document doc, int pos, int len)` method, where translation happens from buffer to Out(Writer Object) if endOfLine is other than '\n' ( which is '\r\n' in windows). In order to write each line till End of line, the string till '\n' is written including '\r' and again endOfLine is written which results in extra Carriage Return. To solve this issue, a Condition is added which checks if previous character to '\n' is '\r', if true then whole string except Carriage Return ('\r') is written, else whole string till before '\n' is written.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on Review Comments

I am still for automating the test.

It may even be headless, I think.

src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java line 342:

> 340:                     if (array[counter] == '\n') {
> 341:                         if (counter > last) {
> 342:                             if(array[counter-1] == '\r') {

The space between if and the opening parenthesis is still missing.

The spaces around `-` are also missing.

src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java line 345:

> 343:                                 out.write(array, last, counter - last - 1);
> 344:                             }
> 345:                             else {

else should be on the same line as the previous closing brace.

test/jdk/javax/swing/JTextPane/8180276/ChangeStyleAndAppend.java line 60:

> 58:                 Document doc = this.getDocument();
> 59:                 doc.insertString(doc.getLength(), s + System.lineSeparator(), null);
> 60:             } catch(BadLocationException e) {

Suggestion:

            } catch (BadLocationException e) {

The should be space between `catch` keyword and the opening parenthesis.

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

Changes requested by aivanov (Reviewer).

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


From duke at openjdk.java.net  Fri Apr  8 12:02:41 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Fri, 8 Apr 2022 12:02:41 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v3]
In-Reply-To: <-FpNep3YcVVj4Ks6j0DwT9JFOvoDjvtKlkiDTnzgPBM=.33b32aa5-f23c-4593-9bf9-d965e5b43859@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <OUpXL2W_N30tcp2aQjYtJccJGG763tSeDxsF3VSIkSk=.5c69e270-2ab8-4562-a28d-9cc500028e55@github.com>
 <EqmNNNCmIM8bCV7-zlbTfV0HzepRDgsCeTpMbnh1dd4=.9c56785d-bb8a-438b-80f0-92751053eedb@github.com>
 <IXfFE_UZd27T819kcYHpa_FTa8n2K8YqgLSctQULALk=.e778e8cc-d6fc-403f-a37d-983b85db48a6@github.com>
 <GMtmoL_K_XLl96SWCT4fidmhFFtqDENfVBYOSp0U-c8=.d2e739db-27aa-4f16-8e1e-2a7222618fd5@github.com>
 <jXaJAVSTRmEDX_Y7jBLVKJ9TUr8tfBZauhputSXtwVY=.b8c4ef18-087d-4837-abd2-1677ae9ed0db@github.com>
 <BFarBNnmxvPBOc1wVuNemz3bxj3_T3ZzCgLjRquG8o0=.aeab0c75-fd25-421c-914f-5ef737e29d8a@github.com>
 <2ZRkMEq3rdKsQhuXPBOn7SDol6WonbSOL0eKTZiymps=.1bc7e7b5-2a51-45f1-a308-add92e8d5dd6@github.com>
 <ZT_U1qu3zXFGavpWGxSqIYwrHVv_BHS41BCAa-vA4jI=.34cea0f4-071c-4cf8-998f-5fa6b65a2876@github.com>
 <-FpNep3YcVVj4Ks6j0DwT9JFOvoDjvtKlkiDTnzgPBM=.33b32aa5-f23c-4593-9bf9-d965e5b43859@github.com>
Message-ID: <EVNKDEf6BdnmuoToSB3DN1yWtJNm332J_rKrWFmxN3Q=.c50e8e39-3ebb-4592-93a8-9453d54f23b1@github.com>

On Fri, 8 Apr 2022 11:43:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> But should /r/r/n cause 2 line feeds? /r should be just carriage return to cause caret to move from last column to first, why it is inserting new line?
>
> It is common to treat `\r` as new line if it's not followed by `\n`. In a visual editor `\r` doesn't do anything.
> 
> Yet it's an interesting detail that wasn't covered in the initial evaluation.

> But should /r/r/n cause 2 line feeds? /r should be just carriage return to cause caret to move from last column to first, why it is inserting new line?

\r is converted to \n in setText method....... To be specific, in `read(Reader in, Document doc, int pos)` method of DefaultEditorKit class......

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

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


From psadhukhan at openjdk.java.net  Fri Apr  8 12:02:41 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 8 Apr 2022 12:02:41 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v3]
In-Reply-To: <EVNKDEf6BdnmuoToSB3DN1yWtJNm332J_rKrWFmxN3Q=.c50e8e39-3ebb-4592-93a8-9453d54f23b1@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <OUpXL2W_N30tcp2aQjYtJccJGG763tSeDxsF3VSIkSk=.5c69e270-2ab8-4562-a28d-9cc500028e55@github.com>
 <EqmNNNCmIM8bCV7-zlbTfV0HzepRDgsCeTpMbnh1dd4=.9c56785d-bb8a-438b-80f0-92751053eedb@github.com>
 <IXfFE_UZd27T819kcYHpa_FTa8n2K8YqgLSctQULALk=.e778e8cc-d6fc-403f-a37d-983b85db48a6@github.com>
 <GMtmoL_K_XLl96SWCT4fidmhFFtqDENfVBYOSp0U-c8=.d2e739db-27aa-4f16-8e1e-2a7222618fd5@github.com>
 <jXaJAVSTRmEDX_Y7jBLVKJ9TUr8tfBZauhputSXtwVY=.b8c4ef18-087d-4837-abd2-1677ae9ed0db@github.com>
 <BFarBNnmxvPBOc1wVuNemz3bxj3_T3ZzCgLjRquG8o0=.aeab0c75-fd25-421c-914f-5ef737e29d8a@github.com>
 <2ZRkMEq3rdKsQhuXPBOn7SDol6WonbSOL0eKTZiymps=.1bc7e7b5-2a51-45f1-a308-add92e8d5dd6@github.com>
 <ZT_U1qu3zXFGavpWGxSqIYwrHVv_BHS41BCAa-vA4jI=.34cea0f4-071c-4cf8-998f-5fa6b65a2876@github.com>
 <-FpNep3YcVVj4Ks6j0DwT9JFOvoDjvtKlkiDTnzgPBM=.33b32aa5-f23c-4593-9bf9-d965e5b43859@github.com>
 <EVNKDEf6BdnmuoToSB3DN1yWtJNm332J_rK
 rWFmxN3Q=.c50e8e39-3ebb-4592-93a8-9453d54f23b1@github.com>
Message-ID: <3CuKW76cyPjXhXxLQDfs59Yf48zWds3hE6ScCkJtrW4=.0a7c4662-3d04-480e-ae05-fff5b6e01246@github.com>

On Fri, 8 Apr 2022 11:54:02 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> It is common to treat `\r` as new line if it's not followed by `\n`. In a visual editor `\r` doesn't do anything.
>> 
>> Yet it's an interesting detail that wasn't covered in the initial evaluation.
>
>> But should /r/r/n cause 2 line feeds? /r should be just carriage return to cause caret to move from last column to first, why it is inserting new line?
> 
> \r is converted to \n in setText method....... To be specific, in `read(Reader in, Document doc, int pos)` method of DefaultEditorKit class......

So, that means presently it is writing /n/r/n not /r/r/n, right?

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

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


From duke at openjdk.java.net  Fri Apr  8 12:02:42 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Fri, 8 Apr 2022 12:02:42 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v3]
In-Reply-To: <3CuKW76cyPjXhXxLQDfs59Yf48zWds3hE6ScCkJtrW4=.0a7c4662-3d04-480e-ae05-fff5b6e01246@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <OUpXL2W_N30tcp2aQjYtJccJGG763tSeDxsF3VSIkSk=.5c69e270-2ab8-4562-a28d-9cc500028e55@github.com>
 <EqmNNNCmIM8bCV7-zlbTfV0HzepRDgsCeTpMbnh1dd4=.9c56785d-bb8a-438b-80f0-92751053eedb@github.com>
 <IXfFE_UZd27T819kcYHpa_FTa8n2K8YqgLSctQULALk=.e778e8cc-d6fc-403f-a37d-983b85db48a6@github.com>
 <GMtmoL_K_XLl96SWCT4fidmhFFtqDENfVBYOSp0U-c8=.d2e739db-27aa-4f16-8e1e-2a7222618fd5@github.com>
 <jXaJAVSTRmEDX_Y7jBLVKJ9TUr8tfBZauhputSXtwVY=.b8c4ef18-087d-4837-abd2-1677ae9ed0db@github.com>
 <BFarBNnmxvPBOc1wVuNemz3bxj3_T3ZzCgLjRquG8o0=.aeab0c75-fd25-421c-914f-5ef737e29d8a@github.com>
 <2ZRkMEq3rdKsQhuXPBOn7SDol6WonbSOL0eKTZiymps=.1bc7e7b5-2a51-45f1-a308-add92e8d5dd6@github.com>
 <ZT_U1qu3zXFGavpWGxSqIYwrHVv_BHS41BCAa-vA4jI=.34cea0f4-071c-4cf8-998f-5fa6b65a2876@github.com>
 <-FpNep3YcVVj4Ks6j0DwT9JFOvoDjvtKlkiDTnzgPBM=.33b32aa5-f23c-4593-9bf9-d965e5b43859@github.com>
 <EVNKDEf6BdnmuoToSB3DN1yWtJNm332J_rK
 rWFmxN3Q=.c50e8e39-3ebb-4592-93a8-9453d54f23b1@github.com>
 <3CuKW76cyPjXhXxLQDfs59Yf48zWds3hE6ScCkJtrW4=.0a7c4662-3d04-480e-ae05-fff5b6e01246@github.com>
Message-ID: <I-kHkkQbXxMHCVvPd57DUMhlIUmF97UQU55JWXIcT88=.7b70c740-5fd8-4d2f-b84b-89ad959a9b74@github.com>

On Fri, 8 Apr 2022 11:56:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> But should /r/r/n cause 2 line feeds? /r should be just carriage return to cause caret to move from last column to first, why it is inserting new line?
>> 
>> \r is converted to \n in setText method....... To be specific, in `read(Reader in, Document doc, int pos)` method of DefaultEditorKit class......
>
> So, that means presently it is writing /n/r/n not /r/r/n, right?

Initially it is /r/r/n from `getText()` of pane0, later it is /n/r/n from `setText()`....

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

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


From duke at openjdk.java.net  Fri Apr  8 12:17:37 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Fri, 8 Apr 2022 12:17:37 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v5]
In-Reply-To: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
Message-ID: <bFJoKiD6n9BimxrGVu8lNW-m3RswKRF_hGhfU905VMs=.94c9f727-2afc-4dde-ab57-f5737d9a034b@github.com>

> getText function returned extra endOfLine when appended. The reason was in `EditorEditorKit` class, `write(Writer out, Document doc, int pos, int len)` method, where translation happens from buffer to Out(Writer Object) if endOfLine is other than '\n' ( which is '\r\n' in windows). In order to write each line till End of line, the string till '\n' is written including '\r' and again endOfLine is written which results in extra Carriage Return. To solve this issue, a Condition is added which checks if previous character to '\n' is '\r', if true then whole string except Carriage Return ('\r') is written, else whole string till before '\n' is written.

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

  Updated based on Review Comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8122/files
  - new: https://git.openjdk.java.net/jdk/pull/8122/files/2369b965..b4b9a0f3

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

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

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


From duke at openjdk.java.net  Fri Apr  8 12:17:38 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Fri, 8 Apr 2022 12:17:38 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v2]
In-Reply-To: <ZdRINoL3gR4NKDSIii_LU0HA_r5dwjgZKhcGO6ZpC9g=.7ff404d4-59ab-4f65-8e35-4b54db4f7531@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <_UplvB0h9bWCInEGLRAN4bN3_sMypgu0hf0nU57pJgI=.8eef0557-500c-4939-b00f-ae9c0dd5a5b8@github.com>
 <p1lJJBIqQpVg6kwYcdWaFsZbLIfE0AkN3Tyl3gXmakE=.98fff17e-812b-4f8b-97b6-4bc61e45ce03@github.com>
 <j97LbflNBQ6fh8KsWHH1YIaXVM6wjCZUOHVrvqzIfLY=.06847a3d-73bd-4102-90eb-06212ceb4f85@github.com>
 <ZdRINoL3gR4NKDSIii_LU0HA_r5dwjgZKhcGO6ZpC9g=.7ff404d4-59ab-4f65-8e35-4b54db4f7531@github.com>
Message-ID: <e0DdIsh6yVwGbBaitK1dU_AKyAAdAKiqNDlLR8HZXhc=.df123d34-2d06-4faf-8919-4b5a61fca9bb@github.com>

On Fri, 8 Apr 2022 11:48:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > 
> > 
> > 
> > > Why can't the test be automatic?
> > 
> > 
> > Actually had thought about automating the test case, but since endOfLine(Win - '\r\n', linux - '\n') is different for different OS, have made it manual.
> 
> It just means the original issue is observed on Windows only.
> 
> Does it make sense to require Windows to run this test?

Yes, the original issue was observed and raised in Windows alone...... In Mac and Linux the control wont even enters this logic -

  if (endOfLineProperty != null && !endOfLine.equals("\n")) {
            // There is an end of line string that isn't \n, have to iterate
            // through and find all \n's and translate to end of line string.

Hence no issue in Mac and Linux..... The issue is observed only in Windows......

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

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


From psadhukhan at openjdk.java.net  Fri Apr  8 12:17:38 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 8 Apr 2022 12:17:38 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v3]
In-Reply-To: <I-kHkkQbXxMHCVvPd57DUMhlIUmF97UQU55JWXIcT88=.7b70c740-5fd8-4d2f-b84b-89ad959a9b74@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <OUpXL2W_N30tcp2aQjYtJccJGG763tSeDxsF3VSIkSk=.5c69e270-2ab8-4562-a28d-9cc500028e55@github.com>
 <EqmNNNCmIM8bCV7-zlbTfV0HzepRDgsCeTpMbnh1dd4=.9c56785d-bb8a-438b-80f0-92751053eedb@github.com>
 <IXfFE_UZd27T819kcYHpa_FTa8n2K8YqgLSctQULALk=.e778e8cc-d6fc-403f-a37d-983b85db48a6@github.com>
 <GMtmoL_K_XLl96SWCT4fidmhFFtqDENfVBYOSp0U-c8=.d2e739db-27aa-4f16-8e1e-2a7222618fd5@github.com>
 <jXaJAVSTRmEDX_Y7jBLVKJ9TUr8tfBZauhputSXtwVY=.b8c4ef18-087d-4837-abd2-1677ae9ed0db@github.com>
 <BFarBNnmxvPBOc1wVuNemz3bxj3_T3ZzCgLjRquG8o0=.aeab0c75-fd25-421c-914f-5ef737e29d8a@github.com>
 <2ZRkMEq3rdKsQhuXPBOn7SDol6WonbSOL0eKTZiymps=.1bc7e7b5-2a51-45f1-a308-add92e8d5dd6@github.com>
 <ZT_U1qu3zXFGavpWGxSqIYwrHVv_BHS41BCAa-vA4jI=.34cea0f4-071c-4cf8-998f-5fa6b65a2876@github.com>
 <-FpNep3YcVVj4Ks6j0DwT9JFOvoDjvtKlkiDTnzgPBM=.33b32aa5-f23c-4593-9bf9-d965e5b43859@github.com>
 <EVNKDEf6BdnmuoToSB3DN1yWtJNm332J_rK
 rWFmxN3Q=.c50e8e39-3ebb-4592-93a8-9453d54f23b1@github.com>
 <3CuKW76cyPjXhXxLQDfs59Yf48zWds3hE6ScCkJtrW4=.0a7c4662-3d04-480e-ae05-fff5b6e01246@github.com>
 <I-kHkkQbXxMHCVvPd57DUMhlIUmF97UQU55JWXIcT88=.7b70c740-5fd8-4d2f-b84b-89ad959a9b74@github.com>
Message-ID: <BQ7nIQjOl8gwdhLP-LbKCNBtoibAJjFJvCwHtsOoPcg=.3b837d40-5ab8-41e1-b1d5-2187008903b7@github.com>

On Fri, 8 Apr 2022 11:59:19 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> So, that means presently it is writing /n/r/n not /r/r/n, right?
>
> Initially it is /r/r/n from `getText()` of pane0, later it is /n/r/n from `setText()`....

When you do out.write(array, last, counter - last); in write(Writer out, Document doc, int pos, int len) method, what is being written? Is it /r/r/n or /n/r/n presently?

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

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


From duke at openjdk.java.net  Fri Apr  8 12:17:38 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Fri, 8 Apr 2022 12:17:38 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v3]
In-Reply-To: <BQ7nIQjOl8gwdhLP-LbKCNBtoibAJjFJvCwHtsOoPcg=.3b837d40-5ab8-41e1-b1d5-2187008903b7@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <OUpXL2W_N30tcp2aQjYtJccJGG763tSeDxsF3VSIkSk=.5c69e270-2ab8-4562-a28d-9cc500028e55@github.com>
 <EqmNNNCmIM8bCV7-zlbTfV0HzepRDgsCeTpMbnh1dd4=.9c56785d-bb8a-438b-80f0-92751053eedb@github.com>
 <IXfFE_UZd27T819kcYHpa_FTa8n2K8YqgLSctQULALk=.e778e8cc-d6fc-403f-a37d-983b85db48a6@github.com>
 <GMtmoL_K_XLl96SWCT4fidmhFFtqDENfVBYOSp0U-c8=.d2e739db-27aa-4f16-8e1e-2a7222618fd5@github.com>
 <jXaJAVSTRmEDX_Y7jBLVKJ9TUr8tfBZauhputSXtwVY=.b8c4ef18-087d-4837-abd2-1677ae9ed0db@github.com>
 <BFarBNnmxvPBOc1wVuNemz3bxj3_T3ZzCgLjRquG8o0=.aeab0c75-fd25-421c-914f-5ef737e29d8a@github.com>
 <2ZRkMEq3rdKsQhuXPBOn7SDol6WonbSOL0eKTZiymps=.1bc7e7b5-2a51-45f1-a308-add92e8d5dd6@github.com>
 <ZT_U1qu3zXFGavpWGxSqIYwrHVv_BHS41BCAa-vA4jI=.34cea0f4-071c-4cf8-998f-5fa6b65a2876@github.com>
 <-FpNep3YcVVj4Ks6j0DwT9JFOvoDjvtKlkiDTnzgPBM=.33b32aa5-f23c-4593-9bf9-d965e5b43859@github.com>
 <EVNKDEf6BdnmuoToSB3DN1yWtJNm332J_rK
 rWFmxN3Q=.c50e8e39-3ebb-4592-93a8-9453d54f23b1@github.com>
 <3CuKW76cyPjXhXxLQDfs59Yf48zWds3hE6ScCkJtrW4=.0a7c4662-3d04-480e-ae05-fff5b6e01246@github.com>
 <I-kHkkQbXxMHCVvPd57DUMhlIUmF97UQU55JWXIcT88=.7b70c740-5fd8-4d2f-b84b-89ad959a9b74@github.com>
 <BQ7nIQjOl8gwdhLP-LbKCNBtoibAJjFJvCwHtsOoPcg=.3b837d40-5ab8-41e1-b1d5-2187008903b7@github.com>
Message-ID: <284j1Ufc8yZ-aZh9x1_2tbpmHu5PQJNm3YRFbBtH7cs=.be3de3a8-ed97-4036-9d30-1f1d0c6e9a60@github.com>

On Fri, 8 Apr 2022 12:08:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Initially it is /r/r/n from `getText()` of pane0, later it is /n/r/n from `setText()`....
>
> When you do out.write(array, last, counter - last); in write(Writer out, Document doc, int pos, int len) method, what is being written? Is it /r/r/n or /n/r/n presently?

Finally its /n/r/n....... I mentioned /r/r/n because that was the output string from `getText()` method to `setText()` method......

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

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


From aivanov at openjdk.java.net  Fri Apr  8 12:27:45 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 8 Apr 2022 12:27:45 GMT
Subject: RFR: 8257810: Only First page are printed in
 JTable.scrollRectToVisible [v5]
In-Reply-To: <2aOfA0_sisjZW3Ahw_yLLf0MyEereMcL1Jra0AoofPE=.83e4ed58-96b1-4c0e-b41c-7ed93cb371cf@github.com>
References: <HpEmX1DI9Q4PvHQIntUEknVW8jlIWQFXHuB1XgJlh40=.f7726194-7aad-4422-a8db-c02bbad0d110@github.com>
 <2aOfA0_sisjZW3Ahw_yLLf0MyEereMcL1Jra0AoofPE=.83e4ed58-96b1-4c0e-b41c-7ed93cb371cf@github.com>
Message-ID: <hHez-nefJmxIqu3Lr_9mEaK348RQjKgj_JEeD6sUZ8k=.e0cdf0e8-a8ad-487a-a7fa-e5da6742ba0a@github.com>

On Fri, 8 Apr 2022 11:58:03 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. 
>> This is because when the table is scrolled down to last page, the bounds.y becomes -ve 
>> [x=0,y=-15260,width=968,height=16000]
>> so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296]
>> but subsequent pages clip 
>> [[x=0,y=1296,width=968,height=1296], 
>> [x=0,y=2592,width=968,height=1296], 
>> [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed
>> 
>> This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI
>> We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907
>> 
>> Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS)
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 51:

> 49:     static JTable table;
> 50:     static boolean testResult = false;
> 51:     static CountDownLatch latch = new CountDownLatch(1);

`testResult` should be `volatile`.

`latch` should rather be `final`.

test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 64:

> 62:             SwingUtilities.invokeAndWait(() -> {
> 63:                 try {
> 64:                     table.print();

If user click Cancel in the print dialog, the `print` method returns `false`. The test should fail in this case.

test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 72:

> 70:             // wait for latch to complete
> 71:             if (!latch.await(5, TimeUnit.MINUTES)) {
> 72:                 throw new RuntimeException(" User has not executed the test");

Wouldn't the message "The test timed out" be clearer?

test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 152:

> 150:         mainPanel.add(buttonPanel, BorderLayout.SOUTH);
> 151:         dialog.add(mainPanel);
> 152:         dialog.setUndecorated(true);

It doesn't prevent you from using Alt+F4 to close the window but makes experience worse.

Is it possible to use JFrame instead of JDialog to display instructions?

If I accidentally switch to another window which overlaps the dialog, there's no way to bring it to the top other than minimizing all the windows that might overlap the dialog. If it's a frame, it's displayed in the Taskbar.

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

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


From aivanov at openjdk.java.net  Fri Apr  8 12:33:44 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 8 Apr 2022 12:33:44 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v3]
In-Reply-To: <284j1Ufc8yZ-aZh9x1_2tbpmHu5PQJNm3YRFbBtH7cs=.be3de3a8-ed97-4036-9d30-1f1d0c6e9a60@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <OUpXL2W_N30tcp2aQjYtJccJGG763tSeDxsF3VSIkSk=.5c69e270-2ab8-4562-a28d-9cc500028e55@github.com>
 <EqmNNNCmIM8bCV7-zlbTfV0HzepRDgsCeTpMbnh1dd4=.9c56785d-bb8a-438b-80f0-92751053eedb@github.com>
 <IXfFE_UZd27T819kcYHpa_FTa8n2K8YqgLSctQULALk=.e778e8cc-d6fc-403f-a37d-983b85db48a6@github.com>
 <GMtmoL_K_XLl96SWCT4fidmhFFtqDENfVBYOSp0U-c8=.d2e739db-27aa-4f16-8e1e-2a7222618fd5@github.com>
 <jXaJAVSTRmEDX_Y7jBLVKJ9TUr8tfBZauhputSXtwVY=.b8c4ef18-087d-4837-abd2-1677ae9ed0db@github.com>
 <BFarBNnmxvPBOc1wVuNemz3bxj3_T3ZzCgLjRquG8o0=.aeab0c75-fd25-421c-914f-5ef737e29d8a@github.com>
 <2ZRkMEq3rdKsQhuXPBOn7SDol6WonbSOL0eKTZiymps=.1bc7e7b5-2a51-45f1-a308-add92e8d5dd6@github.com>
 <ZT_U1qu3zXFGavpWGxSqIYwrHVv_BHS41BCAa-vA4jI=.34cea0f4-071c-4cf8-998f-5fa6b65a2876@github.com>
 <-FpNep3YcVVj4Ks6j0DwT9JFOvoDjvtKlkiDTnzgPBM=.33b32aa5-f23c-4593-9bf9-d965e5b43859@github.com>
 <EVNKDEf6BdnmuoToSB3DN1yWtJNm332J_rK
 rWFmxN3Q=.c50e8e39-3ebb-4592-93a8-9453d54f23b1@github.com>
 <3CuKW76cyPjXhXxLQDfs59Yf48zWds3hE6ScCkJtrW4=.0a7c4662-3d04-480e-ae05-fff5b6e01246@github.com>
 <I-kHkkQbXxMHCVvPd57DUMhlIUmF97UQU55JWXIcT88=.7b70c740-5fd8-4d2f-b84b-89ad959a9b74@github.com>
 <BQ7nIQjOl8gwdhLP-LbKCNBtoibAJjFJvCwHtsOoPcg=.3b837d40-5ab8-41e1-b1d5-2187008903b7@github.com>
 <284j1Ufc8yZ-aZh9x1_2tbpmHu5PQJNm3YRFbBtH7cs=.be3de3a8-ed97-4036-9d30-1f1d0c6e9a60@github.com>
Message-ID: <B8H02wfmOkc7jlSGO1Vv1NKEVz00zQJ21K3CanWZMPM=.42b24a01-a7b5-4695-9c21-8565b00174a2@github.com>

On Fri, 8 Apr 2022 12:13:03 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> When you do out.write(array, last, counter - last); in write(Writer out, Document doc, int pos, int len) method, what is being written? Is it /r/r/n or /n/r/n presently?
>
> Finally its /n/r/n....... I mentioned /r/r/n because that was the output string from `getText()` method to `setText()` method......

Let me summarise:

Initially, `getText()` wrote out `\r\r\n` for the sequence of `\r\n` in the document.

Then `setText()` converted `\r\r\n` to `\n\r\n` or rather `\n\n` which resulted in the additional blank line in the editor.

The updated code makes sure the additional `\r` isn't added when the text already contains `\r` as part of new line sequence.

Is it correct?

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

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


From aivanov at openjdk.java.net  Fri Apr  8 12:40:45 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 8 Apr 2022 12:40:45 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v5]
In-Reply-To: <bFJoKiD6n9BimxrGVu8lNW-m3RswKRF_hGhfU905VMs=.94c9f727-2afc-4dde-ab57-f5737d9a034b@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <bFJoKiD6n9BimxrGVu8lNW-m3RswKRF_hGhfU905VMs=.94c9f727-2afc-4dde-ab57-f5737d9a034b@github.com>
Message-ID: <QZjXmHvLwwFYgc4_vh6Y5ku4VCuMxtelkX12tAIyuk4=.fcf0c020-a266-422c-b12b-f790119ebae7@github.com>

On Fri, 8 Apr 2022 12:17:37 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> getText function returned extra endOfLine when appended. The reason was in `EditorEditorKit` class, `write(Writer out, Document doc, int pos, int len)` method, where translation happens from buffer to Out(Writer Object) if endOfLine is other than '\n' ( which is '\r\n' in windows). In order to write each line till End of line, the string till '\n' is written including '\r' and again endOfLine is written which results in extra Carriage Return. To solve this issue, a Condition is added which checks if previous character to '\n' is '\r', if true then whole string except Carriage Return ('\r') is written, else whole string till before '\n' is written.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on Review Comments

What happens if you add `\r` to an arbitrary location in text?

What happens if you read in such a text?

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

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


From psadhukhan at openjdk.java.net  Fri Apr  8 12:41:30 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 8 Apr 2022 12:41:30 GMT
Subject: RFR: 8257810: Only First page are printed in
 JTable.scrollRectToVisible [v5]
In-Reply-To: <hHez-nefJmxIqu3Lr_9mEaK348RQjKgj_JEeD6sUZ8k=.e0cdf0e8-a8ad-487a-a7fa-e5da6742ba0a@github.com>
References: <HpEmX1DI9Q4PvHQIntUEknVW8jlIWQFXHuB1XgJlh40=.f7726194-7aad-4422-a8db-c02bbad0d110@github.com>
 <2aOfA0_sisjZW3Ahw_yLLf0MyEereMcL1Jra0AoofPE=.83e4ed58-96b1-4c0e-b41c-7ed93cb371cf@github.com>
 <hHez-nefJmxIqu3Lr_9mEaK348RQjKgj_JEeD6sUZ8k=.e0cdf0e8-a8ad-487a-a7fa-e5da6742ba0a@github.com>
Message-ID: <VUS247tpHEFTf9gEPtpCsLXfdFe3LiPYD1lC7WbhvkE=.73a7b021-3308-4eab-8f9f-09eaf696bcb5@github.com>

On Fri, 8 Apr 2022 12:18:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test fix
>
> test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 152:
> 
>> 150:         mainPanel.add(buttonPanel, BorderLayout.SOUTH);
>> 151:         dialog.add(mainPanel);
>> 152:         dialog.setUndecorated(true);
> 
> It doesn't prevent you from using Alt+F4 to close the window but makes experience worse.
> 
> Is it possible to use JFrame instead of JDialog to display instructions?
> 
> If I accidentally switch to another window which overlaps the dialog, there's no way to bring it to the top other than minimizing all the windows that might overlap the dialog. If it's a frame, it's displayed in the Taskbar.

I will rather not make the test more complicated...it's not a test fix..it just to verify the product fix..
I am not able to close in windows using ALT+F4 anyway...
Other suggestions accepted...

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

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


From psadhukhan at openjdk.java.net  Fri Apr  8 12:41:29 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 8 Apr 2022 12:41:29 GMT
Subject: RFR: 8257810: Only First page are printed in
 JTable.scrollRectToVisible [v6]
In-Reply-To: <HpEmX1DI9Q4PvHQIntUEknVW8jlIWQFXHuB1XgJlh40=.f7726194-7aad-4422-a8db-c02bbad0d110@github.com>
References: <HpEmX1DI9Q4PvHQIntUEknVW8jlIWQFXHuB1XgJlh40=.f7726194-7aad-4422-a8db-c02bbad0d110@github.com>
Message-ID: <90HJ1IkePEPjEC_84YWQEBhdiPg45Fhdk8bl8opy1Yg=.0e82edc6-20d3-4cf3-97b7-c06145fd0572@github.com>

> Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. 
> This is because when the table is scrolled down to last page, the bounds.y becomes -ve 
> [x=0,y=-15260,width=968,height=16000]
> so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296]
> but subsequent pages clip 
> [[x=0,y=1296,width=968,height=1296], 
> [x=0,y=2592,width=968,height=1296], 
> [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed
> 
> This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI
> We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907
> 
> Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS)

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

  Test fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8141/files
  - new: https://git.openjdk.java.net/jdk/pull/8141/files/c8cffba7..3cee561e

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

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

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


From zgu at openjdk.java.net  Fri Apr  8 13:29:39 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 8 Apr 2022 13:29:39 GMT
Subject: RFR: 8284093: Memory leak: X11SD_DisposeXImage should also free
 obdata
In-Reply-To: <1X0DLnuKgL-jVip5RrGZZcxQof6Z0njfXDrymX1lojs=.35d58243-f34c-4737-a217-6118ebead825@github.com>
References: <1X0DLnuKgL-jVip5RrGZZcxQof6Z0njfXDrymX1lojs=.35d58243-f34c-4737-a217-6118ebead825@github.com>
Message-ID: <MCpk7dMDZBEgJxxmardGfzbCDJGJ_vQqaPtELlt7yA8=.a0b28554-42e4-426e-9e1b-ad50ed64f965@github.com>

On Thu, 31 Mar 2022 13:30:40 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this small patch to fix leaking `XShmSegmentInfo` that is attached to `XImage`. 
> 
> Test:
> 
> - [x] jdk_2d

Friendly ping!

May I have a second review?

Thanks

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

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


From aivanov at openjdk.java.net  Fri Apr  8 14:43:43 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 8 Apr 2022 14:43:43 GMT
Subject: RFR: 8257810: Only First page are printed in
 JTable.scrollRectToVisible [v6]
In-Reply-To: <90HJ1IkePEPjEC_84YWQEBhdiPg45Fhdk8bl8opy1Yg=.0e82edc6-20d3-4cf3-97b7-c06145fd0572@github.com>
References: <HpEmX1DI9Q4PvHQIntUEknVW8jlIWQFXHuB1XgJlh40=.f7726194-7aad-4422-a8db-c02bbad0d110@github.com>
 <90HJ1IkePEPjEC_84YWQEBhdiPg45Fhdk8bl8opy1Yg=.0e82edc6-20d3-4cf3-97b7-c06145fd0572@github.com>
Message-ID: <mpr1s6FAYX99tdRtznOpZ0C9rMkLLZRZM7yk4mHqneM=.e6fc9de8-903e-4e44-9a5b-57b23e1974ff@github.com>

On Fri, 8 Apr 2022 12:41:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. 
>> This is because when the table is scrolled down to last page, the bounds.y becomes -ve 
>> [x=0,y=-15260,width=968,height=16000]
>> so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296]
>> but subsequent pages clip 
>> [[x=0,y=1296,width=968,height=1296], 
>> [x=0,y=2592,width=968,height=1296], 
>> [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed
>> 
>> This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI
>> We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907
>> 
>> Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS)
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

Changes requested by aivanov (Reviewer).

> I will rather not make the test more complicated...it's not a test fix..it just to verify the product fix..
> I am not able to close in windows using ALT+F4 anyway...
> Other suggestions accepted...

It doesn't make the code *too* complicated. And it makes it complete so that it can be used as the start for other tests.

Would you be able to apply the following patch?


diff --git a/test/jdk/javax/swing/JTable/PrintAllPagesTest.java b/test/jdk/javax/swing/JTable/PrintAllPagesTest.java
index ec0066088bd..8c61639d03d 100644
--- a/test/jdk/javax/swing/JTable/PrintAllPagesTest.java
+++ b/test/jdk/javax/swing/JTable/PrintAllPagesTest.java
@@ -28,6 +28,8 @@
  */
 import java.awt.BorderLayout;
 import java.awt.FlowLayout;
+import java.awt.event.WindowAdapter;
+import java.awt.event.WindowEvent;
 import java.awt.print.PrinterException;
 import java.util.concurrent.CountDownLatch;
 import java.util.concurrent.TimeUnit;
@@ -43,35 +45,32 @@ import javax.swing.table.AbstractTableModel;
 import javax.swing.table.TableModel;
 import javax.swing.WindowConstants;
 
-public class PrintAllPagesTest {
+public class PrintAllPagesTest extends WindowAdapter {
     static JFrame f;
     static JDialog dialog;
     static JTable table;
     static volatile boolean testResult = false;
-    final static CountDownLatch latch = new CountDownLatch(1);
-    static  boolean ret = false;
+    static final CountDownLatch latch = new CountDownLatch(1);
 
     public static void main(String[] args) throws Exception {
 
         try {
             SwingUtilities.invokeAndWait(() -> {
-                createUI();
                 printAllPagesTest();
+                createUI();
             });
 
             Thread.sleep(1000);
             SwingUtilities.invokeAndWait(() -> {
                 try {
-                    ret = table.print();
+                    if (!table.print()) {
+                        throw new RuntimeException("Printing cancelled");
+                    }
                 } catch (PrinterException e) {
                     throw new RuntimeException("Printing failed: " + e);
                 }
             });
 
-            if (!testResult) {
-                throw new RuntimeException("Only 1st page is printed out of multiple pages");
-            }
-
             // wait for latch to complete
             if (!latch.await(5, TimeUnit.MINUTES)) {
                 throw new RuntimeException("Test timed out");
@@ -120,10 +119,10 @@ public class PrintAllPagesTest {
         f = new JFrame("Table test");
         f.add(scrollpane);
         f.setSize(1000, 800);
-        f.setUndecorated(true);
         f.setLocationRelativeTo(null);
         f.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
         f.setVisible(true);
+        f.addWindowListener(new PrintAllPagesTest());
     }
 
     private static void createUI() {
@@ -133,8 +132,7 @@ public class PrintAllPagesTest {
                 + " If only 1 page is printed,\n "
                 + " then press fail else press pass";
 
-        dialog = new JDialog();
-        dialog.setTitle("textselectionTest");
+        dialog = new JDialog(f, "Instructions for Table Print Test");
         JTextArea textArea = new JTextArea(description);
         textArea.setEditable(false);
         final JButton passButton = new JButton("PASS");
@@ -154,8 +152,13 @@ public class PrintAllPagesTest {
         buttonPanel.add(failButton);
         mainPanel.add(buttonPanel, BorderLayout.SOUTH);
         dialog.add(mainPanel);
-        dialog.setUndecorated(true);
         dialog.pack();
         dialog.setVisible(true);
+        dialog.addWindowListener(new PrintAllPagesTest());
+    }
+
+    @Override
+    public void windowClosing(WindowEvent e) {
+        latch.countDown();
     }
 }


The reason why I changed the order and call `printAllPagesTest()` before `createUI()` is to make sure `f` is not `null` when the dialog is created. The owned dialog is always displayed above its owner, this addresses two issues together: it will be brought up whenever the frame is activated; if the screen resolution is low, the dialog could become hidden below the frame leaving the tester with no instructions visible.

I used the blessed order of modifiers: `static final`.

Closing either the dialog or the frame fails the test. Yet I didn't bother to provide a more detailed message; the test fails because `testResult` remains `false`.

test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 73:

> 71:             if (!testResult) {
> 72:                 throw new RuntimeException("Only 1st page is printed out of multiple pages");
> 73:             }

Now the test always fails whether printing is called or not.

I handled this situation in the patch I proposed.

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

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


From aghaisas at openjdk.java.net  Fri Apr  8 15:15:43 2022
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 8 Apr 2022 15:15:43 GMT
Subject: Integrated: 8284378: Make Metal the default Java 2D rendering pipeline
 for macOS
In-Reply-To: <Z45KY6DtqGZlf_r5X_CKM_YFP2IZzg48a2s4gI08Kzo=.5e58870d-cd23-4d5f-98c7-f581117a1a4e@github.com>
References: <Z45KY6DtqGZlf_r5X_CKM_YFP2IZzg48a2s4gI08Kzo=.5e58870d-cd23-4d5f-98c7-f581117a1a4e@github.com>
Message-ID: <kK2qQTBlYbHKW2c3QeZQkah54x0GzNybQmeTGVJwMZ0=.c5f1b064-c7db-4d37-96c2-c5f80d891906@github.com>

On Wed, 6 Apr 2022 09:48:13 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> This PR makes Metal rendering pipeline as the default Java 2D rendering pipeline for macOS.
> 
> Please refer "JBS Description" for more details.

This pull request has now been integrated.

Changeset: 3a0ddeba
Author:    Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3a0ddeba52bbb67901335146f93791629c846e21
Stats:     5 lines in 1 file changed: 0 ins; 1 del; 4 mod

8284378: Make Metal the default Java 2D rendering pipeline for macOS

Reviewed-by: kcr, avu, prr, jdv

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

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


From naoto at openjdk.java.net  Fri Apr  8 15:26:35 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 8 Apr 2022 15:26:35 GMT
Subject: Integrated: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <r6its8TfgpC32jQ7YIdERQEA2ElBz-DOEd9zkKv5vGY=.38b6000b-7b2b-4180-8981-19fc570c322a@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

This pull request has now been integrated.

Changeset: d6b4693c
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d6b4693c0527385f8999089b3f8b2120548efecb
Stats:     750 lines in 182 files changed: 3 ins; 3 del; 744 mod

8283698: Refactor Locale constructors used in src/test

Reviewed-by: iris, joehw

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

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


From duke at openjdk.java.net  Fri Apr  8 16:11:43 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Fri, 8 Apr 2022 16:11:43 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v8]
In-Reply-To: <aKWrOQ_B3iWzXECCc6lUYE3ii6MOT3uBflVM4oSs7Ck=.07eb26cc-a502-494e-9dfc-b46b2d2dd6b5@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <afJ29wQf2smgANBt5YTQC4oODoch8zxa0YqdtUZDfW8=.f4d0de4d-5245-4491-a8e8-05aaf2a4797a@github.com>
 <gzymK8AsH16kj6YIbJoMuRVGTDkKwLd_O3rbbDZCWIQ=.1f491527-2bac-4e6d-a5cc-f8443bf4f352@github.com>
 <MENhs6_2RTKjMOcWkh1CzumSIwQOy75T_wLac37Vkl8=.0da493e3-d91d-4b48-bd58-f69cefce3a9b@github.com>
 <wrQgwI3XG2G9_X8n5n4Q_AzDnMElxB92075XY3bkJMQ=.f5fb8350-489d-44a1-935a-e752b78347cd@github.com>
 <fR3AZPwa0kAz6SJDa5ns4eyyjCIAY_s25IlS2SL2xSw=.c8689931-ded8-448f-8caa-a17b47f7631a@github.com>
 <7ot0fBLQsvKiNsxLdrbnv4R_MNr6qdLN_GBwNPjU-rY=.dcad59a1-d0d6-42b9-bdf4-6290f31a88e0@github.com>
 <aKWrOQ_B3iWzXECCc6lUYE3ii6MOT3uBflVM4oSs7Ck=.07eb26cc-a502-494e-9dfc-b46b2d2dd6b5@github.com>
Message-ID: <vDiWy9AYqPAhXvrGO3XabkDjvOjdPbpEYqjse7nAXO4=.beba5543-3bde-4bf2-9f4e-037a840345df@github.com>

On Fri, 8 Apr 2022 07:55:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> @prrace @prsadhuk 
>> The issue with the system color returned by **keyboardFocusIndicatorColor** mentioned above, persists on macOS 12.3 as well.
>
> "accentColor" is swift property so not usable for jdk but you can use "controlAccentColor" which seems to work with 10.15 and 12.1 as per my limited testing.
> You need to use @available check though..
> Even though it may not work for version lesser than 10.14, I guess it's ok as those versions are more or less obsolete and we will not be worse off than where we are now...
> While you are at it, please consider renaming this function as told.

@prsadhuk Thank you for the suggestion. I will add in the required changes , test it and update the PR.

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

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


From prr at openjdk.java.net  Fri Apr  8 16:22:29 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 8 Apr 2022 16:22:29 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux [v3]
In-Reply-To: <fvSzRbXWlxfgE4uwbkgtTa3O7kuFozKJHg_17HMspp0=.ee143b6f-b325-4820-a67f-67a2e849b746@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
 <1s3rujPqPuQFiA9xp2Rq4UoXMfP5fSpzQX_CNfl-UXw=.4b2a2871-1647-4c2f-a368-44ef8c7896c4@github.com>
 <6bK-iNlPfRxkowIW1_7WYUulcJ9qpcvCBgcG44Q0mHs=.e04e5fc2-d532-4684-bab1-3fd94ba58048@github.com>
 <fvSzRbXWlxfgE4uwbkgtTa3O7kuFozKJHg_17HMspp0=.ee143b6f-b325-4820-a67f-67a2e849b746@github.com>
Message-ID: <VTPzL0KG3zq5hWuJIPQSFbuYN0zQrKZ1TUQbRC15NFw=.674f7a4f-006d-49c6-835d-3f1aa415e073@github.com>

On Fri, 8 Apr 2022 06:49:16 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> src/java.desktop/unix/classes/sun/awt/X11/XCanvasPeer.java line 90:
>> 
>>> 88:             XToolkit.awtUnlock();
>>> 89:         }
>>> 90:     }
>> 
>> I am not sure I understand the purpose of this method, it requests the current device for the GC, then requests the screen index of the device, and then request device by the screen index, what is the reason to do that? Why we cannot just use the device from the GC?
>
> This is just a named copy of lines 67 to 75. Since now this is the only piece of code that needs to work holding the AWT lock, I thought it best to isolate it.
> As I understand, the purpose of the piece is to find the "new" `X11GraphicsDevice` with the screen number same to the given "old" `GraphicsConfiguration`.

I don't understand why this was extracted out. It isn't called anywhere else and again makes the diff harder to understand.

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

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


From prr at openjdk.java.net  Fri Apr  8 16:22:31 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 8 Apr 2022 16:22:31 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux [v5]
In-Reply-To: <l8h3eiPB9RcX38ktddI1hgx1RL1ZaCZz0DlXdU-Hgjk=.d5380014-4dff-4334-8be9-fb537221f546@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
 <l8h3eiPB9RcX38ktddI1hgx1RL1ZaCZz0DlXdU-Hgjk=.d5380014-4dff-4334-8be9-fb537221f546@github.com>
Message-ID: <6dun2ppw1GHei7MlyCfLlnQ27NsNRSZ5F3Y1kSWrA7E=.08fadf9c-73f4-499e-8b45-f5e3c147bd91@github.com>

On Fri, 8 Apr 2022 06:49:09 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> These crashes were not reproducible, so the fix is based on a hypothesis that there are two possible reasons for them:
>> 1. `makeDefaultConfig()` returning `NULL`.
>> 2. A race condition when the number of screens changes.
>> The race scenario: `X11GraphisDevice.makeDefaultConfiguration()` is called on EDT so the call can race with `X11GraphisDevice.invalidate()` that re-sets the screen number of the device; the latter is invoked on the `AWT-XAWT` thread from `X11GraphicsEnvironment.rebuildDevices()`. So by the time `makeDefaultConfiguration()` makes a native call with the device's current screen number, the `x11Screens` array maintained by the native code could have become shorter. And the native methods like `Java_sun_awt_X11GraphicsDevice_getConfigColormap()` assume that the number passed to them is always current and valid. The AWT lock only protects against the changes during the native methods invocation and does not protect against them being called with an outdated screen number. With a larger screen number, those methods read past the end of the `x11Screens` array.
>> 
>> The fix for (1) is to die gracefully instead of crashing in an attempt to de-reference a `NULL` pointer, which might happen upon returning from `makeDefaultConfig()` in `getAllConfigs()`.
>> 
>> The fix for (2) is to eliminate the race by protecting `X11GraphisDevice.screen` with the AWT lock such that it doesn't change when the native methods working with it are active.
>> 
>> We've been shipping JetBrains Runtime with this fix for a few months now and there were no crash reports with those specific patterns against the versions with the fix.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restored the original code in X11GraphicsDevice.java that got auto-formatted

src/java.desktop/unix/classes/sun/awt/X11/XCanvasPeer.java line 90:

> 88:                 getScreenDevices()[screenNum].
> 89:                 getDefaultConfiguration();
> 90:         }

why did you get rid of the just in case ?
Actually why is this method being modified at all ? 
I mean besides adding locking ..

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

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


From avu at openjdk.java.net  Fri Apr  8 17:00:43 2022
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Fri, 8 Apr 2022 17:00:43 GMT
Subject: RFR: 8283794: CCE in XRTextRenderer.drawGlyphList and
 XRMaskFill.MaskFill [v2]
In-Reply-To: <VE3eRPzRlyCMFgLc0XrQrvy2pgqszE6ZC3TG7fcDvz8=.5facf5d5-668b-4190-acbc-bb481524d1ac@github.com>
References: <GD4NAkuLptwylcQOI8VBAXXI1rY7ycgz8O2NvPmhIOc=.f2c8334e-d2eb-4717-92a1-de2f9ed301b6@github.com>
 <VE3eRPzRlyCMFgLc0XrQrvy2pgqszE6ZC3TG7fcDvz8=.5facf5d5-668b-4190-acbc-bb481524d1ac@github.com>
Message-ID: <Q946mA2rCivg-LGR8WypnoVPUuzRaWN_GFQM1fTyFAM=.0f4bafb8-f89f-456d-af02-cf96f7aefb47@github.com>

On Fri, 1 Apr 2022 15:43:29 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Throwing InvalidPipeException for incompatible surfaces
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8283794: CCE in XRTextRenderer.drawGlyphList and XRMaskFill.MaskFill
>   
>   Extracted try/catch logic of SurfaceData cast to particular SurfaceData subclass into convenience method SurfaceData.convertTo(). Applied the method to XRTextRenderer.drawGlyphList() and XRMaskFill.MaskFill(). Refactored try/catch blocks handling similar cases.

@aghaisas could you please help with running the necessary tests.

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

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


From prr at openjdk.java.net  Fri Apr  8 18:00:45 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 8 Apr 2022 18:00:45 GMT
Subject: RFR: 8284521: Write an automated regression test for RFE 4371575
 [v2]
In-Reply-To: <Qv2iYnccQRtvScBKqUy6djNmBu0x2Ldpqg3AgVc3W8E=.0b8277a2-6447-4943-867d-f606358ad598@github.com>
References: <FgW8JkNC98cWCRNm8Tpsu75-EYCzO2wP4X-sM9rDkZs=.f66039d3-903b-42b3-b2f4-3af624d6fd4b@github.com>
 <Qv2iYnccQRtvScBKqUy6djNmBu0x2Ldpqg3AgVc3W8E=.0b8277a2-6447-4943-867d-f606358ad598@github.com>
Message-ID: <1UClEcAOD__BqjYbWR5fbG6fe_sopD9EgEPJCNMM-UA=.9c77864c-714c-403b-bc9f-3a2ca1dedc84@github.com>

On Fri, 8 Apr 2022 07:08:25 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Write an automated regression test for [JDK-4371575](https://bugs.openjdk.java.net/browse/JDK-4371575)
>> 
>> Issue:
>> As part of the Merlin focus project, JComponent.setRequestFocusEnabled was
>> deprecated and its implementation was changed to map exactly to the new
>> method Component.setFocusable. Scott believes that the old behavior may be
>> preferable. He would like to be able to specify that a Component is focusable,
>> and should receive focus during keyboard traversal, but that it should not
>> automatically take focus when the user clicks on it with the mouse.
>> 
>> We are concerned that the accessibility team would be against this behavior,
>> and this also seems like more of a PLAF issue. Nevertheless, we should look
>> into it before beta ships.
>> 
>> Fix:
>> After some discussion we decided that the best balance of the old and new would be to make this an advisory property. This property will not be synonymous with focusable. Instead our mouse listeners will check this property before requesting focus. This provides as closely as possible the old behavior, while allowing people to use the new focusable property if they don't want a component focusable at all.
>> 
>> Testing:
>> Tested in mach5, 10 times with all the 3 available platform like macosx, windows and linux and got all Pass.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fixed: Removed unwanted directory

Marked as reviewed by prr (Reviewer).

test/jdk/javax/swing/JComponent/JComponentSetRequestFocusEnabledTest.java line 76:

> 74:                 }
> 75:                 robot.waitForIdle();
> 76: 

Since you specified robot.setAutoWaitForIdle(true) I wonder if this is needed ? Shouldn't do any harm though.

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

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


From duke at openjdk.java.net  Fri Apr  8 18:22:48 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Fri, 8 Apr 2022 18:22:48 GMT
Subject: RFR: 8284535 : Fix PrintLatinCJKTest.java test that is failing
 with Parse Exception [v4]
In-Reply-To: <h7QOpvrWuaiHPdWgZ0nJ1kd_9Ccpp25XBgeLdVc995Q=.4f12d6ad-bb09-4395-9cbf-89f439e76bac@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <IMKOkFbDuV-4DlmfcBxxPuL8dBo2GxrGWFET0sMnPPU=.6ca91ed1-c940-4880-8487-892cb77de3e8@github.com>
 <h7QOpvrWuaiHPdWgZ0nJ1kd_9Ccpp25XBgeLdVc995Q=.4f12d6ad-bb09-4395-9cbf-89f439e76bac@github.com>
Message-ID: <OOxWYStclXWWn1ufAQ4eABk5Y9UVV6kcRHj9AOYV4Ts=.721076e2-de11-4e23-97f0-03d991354407@github.com>

On Tue, 5 Apr 2022 20:38:58 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Dispose the Frame based in EDT
>
> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 135:
> 
>> 133:             dialog.dispose();
>> 134:             latch.countDown();
>> 135:         });
> 
> This doesn't handle closing the dialog via Close button or Esc. I believe it should also do everything but copying the entered text.

fixed

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

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


From duke at openjdk.java.net  Fri Apr  8 19:11:56 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Fri, 8 Apr 2022 19:11:56 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux [v5]
In-Reply-To: <6dun2ppw1GHei7MlyCfLlnQ27NsNRSZ5F3Y1kSWrA7E=.08fadf9c-73f4-499e-8b45-f5e3c147bd91@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
 <l8h3eiPB9RcX38ktddI1hgx1RL1ZaCZz0DlXdU-Hgjk=.d5380014-4dff-4334-8be9-fb537221f546@github.com>
 <6dun2ppw1GHei7MlyCfLlnQ27NsNRSZ5F3Y1kSWrA7E=.08fadf9c-73f4-499e-8b45-f5e3c147bd91@github.com>
Message-ID: <3tjuew5ReAg3lSfc8a4-6NNITEgNTeDOnMPtkqPPMYg=.339c003e-e21c-4866-a892-3a8b5f4a64d7@github.com>

On Fri, 8 Apr 2022 16:20:10 GMT, Phil Race <prr at openjdk.org> wrote:

> why did you get rid of the just in case ?

I honestly couldn't find any way for this code to get executed. I can keep it there, but then I would have to explain why it is needed.

> Actually why is this method being modified at all ?
The changes are really semantically null. All I did was shorten a 30 lines method to 15 and gave a name to a piece of it (but that's in the next comment).

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

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


From duke at openjdk.java.net  Fri Apr  8 19:18:02 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Fri, 8 Apr 2022 19:18:02 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux [v3]
In-Reply-To: <VTPzL0KG3zq5hWuJIPQSFbuYN0zQrKZ1TUQbRC15NFw=.674f7a4f-006d-49c6-835d-3f1aa415e073@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
 <1s3rujPqPuQFiA9xp2Rq4UoXMfP5fSpzQX_CNfl-UXw=.4b2a2871-1647-4c2f-a368-44ef8c7896c4@github.com>
 <6bK-iNlPfRxkowIW1_7WYUulcJ9qpcvCBgcG44Q0mHs=.e04e5fc2-d532-4684-bab1-3fd94ba58048@github.com>
 <fvSzRbXWlxfgE4uwbkgtTa3O7kuFozKJHg_17HMspp0=.ee143b6f-b325-4820-a67f-67a2e849b746@github.com>
 <VTPzL0KG3zq5hWuJIPQSFbuYN0zQrKZ1TUQbRC15NFw=.674f7a4f-006d-49c6-835d-3f1aa415e073@github.com>
Message-ID: <uzy1Y8BY6CPGA6P8v8trMNI_WQVQ2yB2F-A4ZSzKKKw=.f7cd7620-8af8-4838-9543-b4360eed0716@github.com>

On Fri, 8 Apr 2022 16:19:30 GMT, Phil Race <prr at openjdk.org> wrote:

> I don't understand why this was extracted out. It isn't called anywhere else and again makes the diff harder to understand.

This AWT lock should be held for a very small portion of the original method. Initially, I left the code guarded by it in place and it looked weird and out of place. I understand that this is a judgement call, though.

As for the diffs, they are not very significant (essentially, 4 lines of code were re-grouped and moved around) and we only have to look at them here for a few days. The (refactored) code itself will be looked at by (presumably) a greater number of people over a far greater period of time. Less of a judgement call.

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

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


From prr at openjdk.java.net  Fri Apr  8 21:33:34 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 8 Apr 2022 21:33:34 GMT
Subject: Integrated: 8283706: Add final or sealed modifier to appropriate
 javax.swing API classes
In-Reply-To: <PfDlBvA6XZ18qqLp21-ZAioRrPXgHeqJ2yUflkmEnK8=.35b6121b-405b-4e80-b933-9ef99a53e084@github.com>
References: <PfDlBvA6XZ18qqLp21-ZAioRrPXgHeqJ2yUflkmEnK8=.35b6121b-405b-4e80-b933-9ef99a53e084@github.com>
Message-ID: <i9NnB0DozGi8IpHjRRNCZIqvDH691dqq7dIDKyVTcKU=.12fd439f-3b04-430a-8d83-74e72b05d8b6@github.com>

On Sat, 2 Apr 2022 23:21:03 GMT, Phil Race <prr at openjdk.org> wrote:

> Update Swing classes to use JEP 409 sealed and non-sealed modifiers and add the final modifier where appropriate.
> 
> jtreg tests and JCK API tests pass
> 
> CSR for review here : https://bugs.openjdk.java.net/browse/JDK-8284214

This pull request has now been integrated.

Changeset: eab4c0c4
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/eab4c0c49934bd6f37a0b6174ca10e5c8708d13b
Stats:     25 lines in 6 files changed: 10 ins; 0 del; 15 mod

8283706: Add final or sealed modifier to appropriate javax.swing API classes

Reviewed-by: darcy, psadhukhan, aivanov, serb

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

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


From serb at openjdk.java.net  Sat Apr  9 05:30:38 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 9 Apr 2022 05:30:38 GMT
Subject: RFR: 8284521: Write an automated regression test for RFE 4371575
 [v2]
In-Reply-To: <Qv2iYnccQRtvScBKqUy6djNmBu0x2Ldpqg3AgVc3W8E=.0b8277a2-6447-4943-867d-f606358ad598@github.com>
References: <FgW8JkNC98cWCRNm8Tpsu75-EYCzO2wP4X-sM9rDkZs=.f66039d3-903b-42b3-b2f4-3af624d6fd4b@github.com>
 <Qv2iYnccQRtvScBKqUy6djNmBu0x2Ldpqg3AgVc3W8E=.0b8277a2-6447-4943-867d-f606358ad598@github.com>
Message-ID: <Fg5vKwm4MxPKYJfHGrLMPhWhkQ81VBc25cpCpwneXEA=.ac2b7e8e-1cdb-48d2-a171-112d7bec6fc0@github.com>

On Fri, 8 Apr 2022 07:08:25 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Write an automated regression test for [JDK-4371575](https://bugs.openjdk.java.net/browse/JDK-4371575)
>> 
>> Issue:
>> As part of the Merlin focus project, JComponent.setRequestFocusEnabled was
>> deprecated and its implementation was changed to map exactly to the new
>> method Component.setFocusable. Scott believes that the old behavior may be
>> preferable. He would like to be able to specify that a Component is focusable,
>> and should receive focus during keyboard traversal, but that it should not
>> automatically take focus when the user clicks on it with the mouse.
>> 
>> We are concerned that the accessibility team would be against this behavior,
>> and this also seems like more of a PLAF issue. Nevertheless, we should look
>> into it before beta ships.
>> 
>> Fix:
>> After some discussion we decided that the best balance of the old and new would be to make this an advisory property. This property will not be synonymous with focusable. Instead our mouse listeners will check this property before requesting focus. This provides as closely as possible the old behavior, while allowing people to use the new focusable property if they don't want a component focusable at all.
>> 
>> Testing:
>> Tested in mach5, 10 times with all the 3 available platform like macosx, windows and linux and got all Pass.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fixed: Removed unwanted directory

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Sat Apr  9 05:37:35 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 9 Apr 2022 05:37:35 GMT
Subject: RFR: 8284077: Create an automated test for JDK-4170173
In-Reply-To: <8iul_waSMDD6G1oVVmwPtW89ihAc6YoMFrTR1-XFmmw=.7802104e-60cb-4b90-9ef5-cc479d3f5a78@github.com>
References: <8iul_waSMDD6G1oVVmwPtW89ihAc6YoMFrTR1-XFmmw=.7802104e-60cb-4b90-9ef5-cc479d3f5a78@github.com>
Message-ID: <JdIu2uEh7kpBQgU4rxLI-_olZ9WVLawWmsDk3oio2Ng=.dfd5a7e7-f62f-49e4-9961-e3017e568435@github.com>

On Thu, 7 Apr 2022 07:40:18 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Create an automated test for [JDK-4170173](https://bugs.openjdk.java.net/browse/JDK-4170173)
> 
> Issue
> JTextComponent.AccessibleJTextComponent.getAfterIndex(int part, int index) works incorrectly, when 'part' parameter is AccessibleText.WORD.
> It returns a space (" ") instead of the correct word.
> 
> The test verifies the fix for this behavior by checking the getAfterIndex for AccessibleText.CHARACTER,AccessibleText.WORD,AccessibleText.SENTENCE for the components JTextField, JTextArea, JEditorPane.
> 
> While working on this test case there was a related bug relevant to this [JDK-4170174](https://bugs.openjdk.java.net/browse/JDK-4170174) 
> This is marked as duplicate, addressess a similar issue.
> It indicates that JTextComponent.AccessibleJTextComponent.getBeforeIndex(int part, int index) works incorrectly, when part parameter is AccessibleText.WORD.
> It returns a space (" ") instead of correct word.
> 
> Hence an additional test was added for this, for verifying the behavior of getBeforeIndex.
> AccessibleText.CHARACTER,AccessibleText.WORD,AccessibleText.SENTENCE for the components JTextField, JTextArea, JEditorPane.
> 
> The two tests have multiple distinct assertions. For this reason, as well as for maintainability, the two were not clubbed into a single test.
> However, the two tests are still similar in the functional flow of the code and the functionality they are testing as well - hence they have been clubbed into a single review.
> This review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The tests ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

test/jdk/javax/accessibility/4170173/AccessibleJTextAfterIndexTest.java line 114:

> 112:             jTextComponent.getAccessibleContext().getAccessibleText()
> 113:             .getAfterIndex(character, characterPosition));
> 114: 

It feels that the code above is too smart=) Can we simplify/reformat it a little bit. I do not think that you need to jump from the main thread to the EDT and back for each testcase, just wrap the "doTest" by the invokeAndWait

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

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


From serb at openjdk.java.net  Sat Apr  9 05:39:02 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 9 Apr 2022 05:39:02 GMT
Subject: RFR: 8282716: [macos] Enable
 javax/swing/JScrollPane/TestMouseWheelScroll.java on macos
In-Reply-To: <-tuJ1M1iwo7tJ_hOHvrEylZmUdS3DPOSbySVFnJGrBI=.212c7ea6-e12a-48af-a4fa-ee3a586e4a38@github.com>
References: <-tuJ1M1iwo7tJ_hOHvrEylZmUdS3DPOSbySVFnJGrBI=.212c7ea6-e12a-48af-a4fa-ee3a586e4a38@github.com>
Message-ID: <F0CzPHWEzAuSAyCUAiu3-JJ_Ue7SIyJWFzBwc70Zi6Q=.2734a6fa-2c72-4f5d-81df-32708a47edcd@github.com>

On Wed, 6 Apr 2022 10:11:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The test was failing on macos and was excluded in macos because the viewposition was not changed after mouse wheel scroll. Seems like mouse wheel scroll direction is opposite in macos compared to windows etc so if we try to down-wheel scroll in macos when view position is at center of viewport (say element 3 is selected out of visible 7 elements), it cannot change viewposition as it cannot "scroll up" (since we are already at topmost viewport) whereas in windows, when we do down-wheel scroll in mouse wheel, it "scroll down" the viewport so viewposition is changed.
> 
> Fix is to use opposite scrolling motion in macos to check mouse wheel scroll is happening, which is what the testcase is meant for. CI testing of this test on all platform is ok.

The scroll direction on macOS can be configured, can the test check what type of scroll is used on the current system and then use that to verify the old fix?

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

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


From serb at openjdk.java.net  Sat Apr  9 05:43:41 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 9 Apr 2022 05:43:41 GMT
Subject: RFR: 8283507: Create a regression test for RFE 4287690 [v3]
In-Reply-To: <8I-5r07BeDPRL2uLjrILbcFMQAYszp2c5xpI8v_ZM0c=.c0d2f711-1281-435b-9c83-b31d94d4a3eb@github.com>
References: <SMPz0WRpMUC4SuuVSmlG6rsG_QudZ-1hCbjUzeMIdqk=.8318c1a4-4db6-4c0b-b24c-0b25b3d932a2@github.com>
 <8I-5r07BeDPRL2uLjrILbcFMQAYszp2c5xpI8v_ZM0c=.c0d2f711-1281-435b-9c83-b31d94d4a3eb@github.com>
Message-ID: <goqx7-S5U6BMsigLq_-ha9wQFuAfVxVWRUttew442ck=.cc5c1bec-110d-4c8f-801a-d15d27500677@github.com>

On Fri, 8 Apr 2022 07:12:21 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Create a regression test for [JDK-4287690](https://bugs.openjdk.java.net/browse/JDK-4287690)
>> Issue description:
>> I want JComboBox to send an event just before the popup (drop down) list is displayed.
>> 
>> Fix:
>> This requires some additional API targeted for major release of the JDK (1.4).The PopupMenuEvent will from the JPopupMenu will be forwarded to the JComboBox. A client of the JComboBox can register itself as a PopupMenuListener to receive the notification.
>> So JComboBox should send drop down events when the drop down popup is visible as well as invisible. JComboBox.addPopupMenuListener(PopupMenuListener) can be used to register for pop up events.
>> 
>> Testing:
>> Tested using Mach5 in all platforms available(macos,linux and windows) and got all pass.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fixed: Removed unwanted directory

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Sat Apr  9 05:44:42 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 9 Apr 2022 05:44:42 GMT
Subject: RFR: 8283245: Create a test for JDK-4670319 [v2]
In-Reply-To: <_N3uh9GNNdLPg-kiacOdc2fEJJeeBdhRM644g_CsV0s=.90175acf-34bf-4db7-a107-469a8611cbdf@github.com>
References: <UrqPfkc5gtakuM1_5bjMxwABKOHUxG5NwTkKpjpFvIk=.3957d27d-ddbe-4aad-aefe-0a3748aca560@github.com>
 <_N3uh9GNNdLPg-kiacOdc2fEJJeeBdhRM644g_CsV0s=.90175acf-34bf-4db7-a107-469a8611cbdf@github.com>
Message-ID: <gOXx5boQUvQn3UkOH_TUu6Tp2d_KhXwOCJ50oAoF5_Y=.a0290689-50b9-4e4b-a840-7df125ddaa9c@github.com>

On Thu, 7 Apr 2022 08:18:21 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Write an automated regression test for  JDK-4670319
>> 
>> Issue
>> When a JTree node is expanded or collapsed, an Accessibility PropertyChange event is fired with the old state of "collapsed" and new state of "expanded" (or vice versa). The problem is that the source of the event is the AccessibeJTree, and not the AccessibleJTreeNode. This means that an assistive technology listening to this event is unable to report to the user what node was expanded/collapsed.
>> 
>> Fix
>> Fix for [JDK-4670319](https://bugs.openjdk.java.net/browse/JDK-4670319) addresses the above issue.  When tree node is expanded/collapsed, PropertyChangeEventSource is the Node.
>> This review is for a test for validating the above issue.
>> 
>> This review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review Comments Fixed: 80 characters line fixed, typo in File Name fixed
>  - Review Comments Fixed: 80 characters line fixed, typo in File Name fixed

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Sat Apr  9 05:46:33 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 9 Apr 2022 05:46:33 GMT
Subject: RFR: 8282640: Create a test for JDK-4740761 [v4]
In-Reply-To: <MDUSF5nh9DXsJ9Xy3eLx5QL1jlOks-BYrwQGBYHQbUY=.91f30164-3661-46d3-a3d6-26d15b4e324c@github.com>
References: <Rr2xSJSr1_1WFxavIZtwz_rlxf15Yvd5dCxZ_1dcggs=.7415074d-6beb-434e-b463-04388e50b0c8@github.com>
 <MDUSF5nh9DXsJ9Xy3eLx5QL1jlOks-BYrwQGBYHQbUY=.91f30164-3661-46d3-a3d6-26d15b4e324c@github.com>
Message-ID: <6uEz3V4PKVcSz23k26xYuTm2z-QjcX4Ihcvkj-Dzfds=.b8421bfe-cd1b-4408-9c42-531c8e33ea83@github.com>

On Wed, 30 Mar 2022 10:33:32 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a test for [JDK-4740761](https://bugs.openjdk.java.net/browse/JDK-4740761)
>> 
>> The issue observed is in a JFrame with a JTextField and a JScrollPane which contains focused component. When the JScrollPane was
>> is removed from its parent, focus stays with the the scroller
>> of the removed JScrollPane, instead of moving to the TextField.
>> 
>> The test verifies the same - i.e. it verifies that the removal of the scrollpane moves the focus to the JTextField present in the JFrame.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comment Fixed: Line Length fixed to < 80 characters.

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Sat Apr  9 06:05:45 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 9 Apr 2022 06:05:45 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux [v3]
In-Reply-To: <uzy1Y8BY6CPGA6P8v8trMNI_WQVQ2yB2F-A4ZSzKKKw=.f7cd7620-8af8-4838-9543-b4360eed0716@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
 <1s3rujPqPuQFiA9xp2Rq4UoXMfP5fSpzQX_CNfl-UXw=.4b2a2871-1647-4c2f-a368-44ef8c7896c4@github.com>
 <6bK-iNlPfRxkowIW1_7WYUulcJ9qpcvCBgcG44Q0mHs=.e04e5fc2-d532-4684-bab1-3fd94ba58048@github.com>
 <fvSzRbXWlxfgE4uwbkgtTa3O7kuFozKJHg_17HMspp0=.ee143b6f-b325-4820-a67f-67a2e849b746@github.com>
 <VTPzL0KG3zq5hWuJIPQSFbuYN0zQrKZ1TUQbRC15NFw=.674f7a4f-006d-49c6-835d-3f1aa415e073@github.com>
 <uzy1Y8BY6CPGA6P8v8trMNI_WQVQ2yB2F-A4ZSzKKKw=.f7cd7620-8af8-4838-9543-b4360eed0716@github.com>
Message-ID: <FMgkU_KLTjUHkuxa9-U7xI30t8B_IHHaszREoUO8Ehg=.aed7fd39-f15f-4195-b4bb-f5c568b890b3@github.com>

On Fri, 8 Apr 2022 19:14:38 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> I don't understand why this was extracted out. It isn't called anywhere else and again makes the diff harder to understand.
>
>> I don't understand why this was extracted out. It isn't called anywhere else and again makes the diff harder to understand.
> 
> This AWT lock should be held for a very small portion of the original method. Initially, I left the code guarded by it in place and it looked weird and out of place. I understand that this is a judgement call, though.
> 
> As for the diffs, they are not very significant (essentially, 4 lines of code were re-grouped and moved around) and we only have to look at them here for a few days. The (refactored) code itself will be looked at by (presumably) a greater number of people over a far greater period of time. Less of a judgement call.

>This is just a named copy of lines 67 to 75. Since now this is the only piece of code that needs to work holding the AWT lock, I thought it best to isolate it.
As I understand, the purpose of the piece is to find the "new" X11GraphicsDevice with the screen number same to the given "old" GraphicsConfiguration.

I am not sure that we can have some "old" and "new" devices which have the same screen id.
 * If the list of devices was not changed then the "screenid" for old device is the index of that "old" device in the device array. So the new and old devices are the same.
 * If the list of devices was changed, then the "screenid" for the old device was invalidated, and it is again an index of that "old" device in the device array.

Please take a look to the fix for JDK-6804747, initially that method get the screen index as a parameter, and then replaced by the GC. The code of the method did not changed but the index just requested from the GC.

Probably the code is just buggies?

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

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


From serb at openjdk.java.net  Sat Apr  9 06:34:33 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 9 Apr 2022 06:34:33 GMT
Subject: RFR: 8284535 : Fix PrintLatinCJKTest.java test that is failing
 with Parse Exception [v6]
In-Reply-To: <jRQUt_Gl2j40pMIM7-8I-t65tojV2xvsfqUE3Bszsx0=.bd28654a-b226-4a48-985b-a3d2187ba75d@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <jRQUt_Gl2j40pMIM7-8I-t65tojV2xvsfqUE3Bszsx0=.bd28654a-b226-4a48-985b-a3d2187ba75d@github.com>
Message-ID: <yl672byV2wQNNcC_01QVttbStT208RYNPpvBYJrBd9I=.ff8bba6d-a726-4bcd-96de-54c552f2489a@github.com>

On Thu, 7 Apr 2022 15:09:27 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
>> 1) Frame which contains test instruction .
>> 2) Pass & Fail button so that user can mark the test pass or fail
>> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
>> 4) Disposing of all the frames.
>> 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284535 : Fix PrintLatinCJKTest.java test that is failing with Parse Exception

Just an idea can we replace the builtin in the jtreg "manual" tests machinery by something like this?
Also would like to raise a question: should we show the test instructions in the same VM where the test executed or we can shoiw it in a separate VM?

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

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


From smandalika at openjdk.java.net  Sat Apr  9 08:18:33 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Sat, 9 Apr 2022 08:18:33 GMT
Subject: RFR: 8282640: Create a test for JDK-4740761 [v4]
In-Reply-To: <6uEz3V4PKVcSz23k26xYuTm2z-QjcX4Ihcvkj-Dzfds=.b8421bfe-cd1b-4408-9c42-531c8e33ea83@github.com>
References: <Rr2xSJSr1_1WFxavIZtwz_rlxf15Yvd5dCxZ_1dcggs=.7415074d-6beb-434e-b463-04388e50b0c8@github.com>
 <MDUSF5nh9DXsJ9Xy3eLx5QL1jlOks-BYrwQGBYHQbUY=.91f30164-3661-46d3-a3d6-26d15b4e324c@github.com>
 <6uEz3V4PKVcSz23k26xYuTm2z-QjcX4Ihcvkj-Dzfds=.b8421bfe-cd1b-4408-9c42-531c8e33ea83@github.com>
Message-ID: <k7Q4pa5BOzd26KarF7fwM8FcjlsOGZ2IK2UArOu0NGo=.2ff49047-24d4-4b13-8301-74878053e6d7@github.com>

On Sat, 9 Apr 2022 05:43:26 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review Comment Fixed: Line Length fixed to < 80 characters.
>
> Marked as reviewed by serb (Reviewer).

@mrserb Can you please sponsor this PR?

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

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


From smandalika at openjdk.java.net  Sat Apr  9 08:18:31 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Sat, 9 Apr 2022 08:18:31 GMT
Subject: RFR: 8283245: Create a test for JDK-4670319 [v2]
In-Reply-To: <gOXx5boQUvQn3UkOH_TUu6Tp2d_KhXwOCJ50oAoF5_Y=.a0290689-50b9-4e4b-a840-7df125ddaa9c@github.com>
References: <UrqPfkc5gtakuM1_5bjMxwABKOHUxG5NwTkKpjpFvIk=.3957d27d-ddbe-4aad-aefe-0a3748aca560@github.com>
 <_N3uh9GNNdLPg-kiacOdc2fEJJeeBdhRM644g_CsV0s=.90175acf-34bf-4db7-a107-469a8611cbdf@github.com>
 <gOXx5boQUvQn3UkOH_TUu6Tp2d_KhXwOCJ50oAoF5_Y=.a0290689-50b9-4e4b-a840-7df125ddaa9c@github.com>
Message-ID: <hukXWHx0QCmmK9dgP4MNAvlpPHBMZkPOJXSjiYZZemg=.3af0e7fe-1919-40da-a2d8-c96e42a5847e@github.com>

On Sat, 9 Apr 2022 05:41:26 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Srinivas Mandalika has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Review Comments Fixed: 80 characters line fixed, typo in File Name fixed
>>  - Review Comments Fixed: 80 characters line fixed, typo in File Name fixed
>
> Marked as reviewed by serb (Reviewer).

@mrserb Can you please sponsor this PR?

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

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


From duke at openjdk.java.net  Sat Apr  9 09:38:40 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Sat, 9 Apr 2022 09:38:40 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux [v3]
In-Reply-To: <FMgkU_KLTjUHkuxa9-U7xI30t8B_IHHaszREoUO8Ehg=.aed7fd39-f15f-4195-b4bb-f5c568b890b3@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
 <1s3rujPqPuQFiA9xp2Rq4UoXMfP5fSpzQX_CNfl-UXw=.4b2a2871-1647-4c2f-a368-44ef8c7896c4@github.com>
 <6bK-iNlPfRxkowIW1_7WYUulcJ9qpcvCBgcG44Q0mHs=.e04e5fc2-d532-4684-bab1-3fd94ba58048@github.com>
 <fvSzRbXWlxfgE4uwbkgtTa3O7kuFozKJHg_17HMspp0=.ee143b6f-b325-4820-a67f-67a2e849b746@github.com>
 <VTPzL0KG3zq5hWuJIPQSFbuYN0zQrKZ1TUQbRC15NFw=.674f7a4f-006d-49c6-835d-3f1aa415e073@github.com>
 <uzy1Y8BY6CPGA6P8v8trMNI_WQVQ2yB2F-A4ZSzKKKw=.f7cd7620-8af8-4838-9543-b4360eed0716@github.com>
 <FMgkU_KLTjUHkuxa9-U7xI30t8B_IHHaszREoUO8Ehg=.aed7fd39-f15f-4195-b4bb-f5c568b890b3@github.com>
Message-ID: <Y-uxICqIcG5sRL0zvduHoh5nauC2hyOiMkkLDG4PTvo=.dc9ad869-933c-407b-8897-ad05160a2a23@github.com>

On Sat, 9 Apr 2022 06:02:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> I don't understand why this was extracted out. It isn't called anywhere else and again makes the diff harder to understand.
>> 
>> This AWT lock should be held for a very small portion of the original method. Initially, I left the code guarded by it in place and it looked weird and out of place. I understand that this is a judgement call, though.
>> 
>> As for the diffs, they are not very significant (essentially, 4 lines of code were re-grouped and moved around) and we only have to look at them here for a few days. The (refactored) code itself will be looked at by (presumably) a greater number of people over a far greater period of time. Less of a judgement call.
>
>>This is just a named copy of lines 67 to 75. Since now this is the only piece of code that needs to work holding the AWT lock, I thought it best to isolate it.
> As I understand, the purpose of the piece is to find the "new" X11GraphicsDevice with the screen number same to the given "old" GraphicsConfiguration.
> 
> I am not sure that we can have some "old" and "new" devices which have the same screen id.
>  * If the list of devices was not changed then the "screenid" for old device is the index of that "old" device in the device array. So the new and old devices are the same.
>  * If the list of devices was changed, then the "screenid" for the old device was invalidated, and it is again an index of that "old" device in the device array. Also I do not think that we can change the "requested device" in this method, The purpose of this method is to request the best "GC" from the device passed as a parameter(via another GC).
> 
> Please take a look to the fix for JDK-6804747, initially that method get the screen index as a parameter, and then replaced by the GC. The code of the method did not changed but the index just requested from the GC.
> 
> Probably the code is just buggies?

@mrserb I agree with your logic, but fixing this now would certainly be not a semantically null change and would complicate the fix that has already been under review for over two months. I'd be happy to file a bug for this separate issue.

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

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


From duke at openjdk.java.net  Sat Apr  9 19:46:37 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Sat, 9 Apr 2022 19:46:37 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v9]
In-Reply-To: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
Message-ID: <Xi_FamdpgndEELpgOGq-e_S3feyW_kzRPLs7niA0yAw=.b1e8a96e-9a26-4c39-8b74-2cc2f4d750a1@github.com>

> Previously while tabbing through the JTable cell, the cell highlighter/focus ring was not visible against the selection background. 
> 
> Changes are made to Aqua LAF to derive a lighter focus ring color by changing saturation and setting brightness component to 100% of original focus ring color so that it is visible while tabbing through `JTable` cells. A new method is added for this purpose which takes in `focusRingColor`, does adjustment to saturation and brightness and returns a new focus ring color. There are edge cases where the HSB transformation does not yield the right focus ring color, for these cases a default color is returned.
> 
> **Edge Cases**
> ![image](https://user-images.githubusercontent.com/95945681/161360456-3929acf1-282b-4c2b-95d1-1d5707c1e238.png)
> 
> The edge case condition consists of two parts ?
> To handle white/black colors - (hsbValues[0] == 0 && hsbValues[1] == 0) - representing hue and saturation of zero obtained for black, white or exactly grey (red=green=color) conditions
> To handle grayish colors - hsbValues[1] <= satGrayScale where satGrayScale <= 0.10 . For any given hue and brightness, a saturation of less than or equal to 10% represents grayish tint colors.
> (The second case was added to accommodate grayish focus ring color returned by system when Accent color = Graphite.  The returned color is not exactly gray but grayish (r=135, g=135, b=140)). 
> To accommodate a more generic case of grayish colors, the satGrayScale has a threshold or buffer of 0.10 or 10%. 
> 
> Used the following resources to test out different grayish colors and optimal saturation offsets used in  `deriveLighterFocusRing()`.
> 
> - [RapidTables](https://www.rapidtables.com/convert/color/rgb-to-hsl.html) 
> - [Colorizer](http://colorizer.org/).
> - [Chart Link](https://codepen.io/HunorMarton/details/eWvewo)
> 
> A test case is added to compare the RGB difference between the original focus ring color & selection background and the new focus ring color & selection background.
> 
> PS: The native L&F (Mac OS) and Swing L&F for JTable cell tabbing differs (on native tables the cell background turns white on focus with a cell focus ring). Since the background for Swing tables can be set by users and also overridden by subclassing `DefaultTableCellRenderer`, and to adhere to current implementation of Swing, the white cell background changes are not incorporated. Only the Focus Ring/ Cell Highlighter is made more prominent.

Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - added new type property and changed method name
 - Merge branch 'master' into focusRing_7124282
 - added more generic condition for edge case and formatted line lengths
 - Merge branch 'openjdk:master' into focusRing_7124282
 - on-the-fly focus ring color changes added
 - updated deriveContrastFocusRing method
 - changed javadocs for the new method and expanded imports
 - formatting changes to test case
 - formatted line lengths, added method-level comments
 - Cell Focus Ring Changes for Aqua LAF

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7768/files
  - new: https://git.openjdk.java.net/jdk/pull/7768/files/6f1359e4..3e7afcdb

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

  Stats: 33413 lines in 1107 files changed: 22513 ins; 4710 del; 6190 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7768/head:pull/7768

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


From serb at openjdk.java.net  Sat Apr  9 22:18:12 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 9 Apr 2022 22:18:12 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux [v3]
In-Reply-To: <Y-uxICqIcG5sRL0zvduHoh5nauC2hyOiMkkLDG4PTvo=.dc9ad869-933c-407b-8897-ad05160a2a23@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
 <1s3rujPqPuQFiA9xp2Rq4UoXMfP5fSpzQX_CNfl-UXw=.4b2a2871-1647-4c2f-a368-44ef8c7896c4@github.com>
 <6bK-iNlPfRxkowIW1_7WYUulcJ9qpcvCBgcG44Q0mHs=.e04e5fc2-d532-4684-bab1-3fd94ba58048@github.com>
 <fvSzRbXWlxfgE4uwbkgtTa3O7kuFozKJHg_17HMspp0=.ee143b6f-b325-4820-a67f-67a2e849b746@github.com>
 <VTPzL0KG3zq5hWuJIPQSFbuYN0zQrKZ1TUQbRC15NFw=.674f7a4f-006d-49c6-835d-3f1aa415e073@github.com>
 <uzy1Y8BY6CPGA6P8v8trMNI_WQVQ2yB2F-A4ZSzKKKw=.f7cd7620-8af8-4838-9543-b4360eed0716@github.com>
 <FMgkU_KLTjUHkuxa9-U7xI30t8B_IHHaszREoUO8Ehg=.aed7fd39-f15f-4195-b4bb-f5c568b890b3@github.com>
 <Y-uxICqIcG5sRL0zvduHoh5nauC2hyOiMkkLDG4PTvo=.dc9ad869-933c-407b-8897-ad05160a2a23@github.com>
Message-ID: <UMiKAzpVPAwNxlsIVJr3E48ULLs2yPZjbSxyMDPUat4=.02689a69-92e1-46a1-960e-613dd9f88077@github.com>

On Sat, 9 Apr 2022 09:35:39 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>>>This is just a named copy of lines 67 to 75. Since now this is the only piece of code that needs to work holding the AWT lock, I thought it best to isolate it.
>> As I understand, the purpose of the piece is to find the "new" X11GraphicsDevice with the screen number same to the given "old" GraphicsConfiguration.
>> 
>> I am not sure that we can have some "old" and "new" devices which have the same screen id.
>>  * If the list of devices was not changed then the "screenid" for old device is the index of that "old" device in the device array. So the new and old devices are the same.
>>  * If the list of devices was changed, then the "screenid" for the old device was invalidated, and it is again an index of that "old" device in the device array. Also I do not think that we can change the "requested device" in this method, The purpose of this method is to request the best "GC" from the device passed as a parameter(via another GC).
>> 
>> Please take a look to the fix for JDK-6804747, initially that method get the screen index as a parameter, and then replaced by the GC. The code of the method did not changed but the index just requested from the GC.
>> 
>> Probably the code is just buggies?
>
> @mrserb I agree with your logic, but fixing this now would certainly be not a semantically null change and would complicate the fix that has already been under review for over two months. I'd be happy to file a bug for this separate issue.

The separate CR would be fine.

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

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


From psadhukhan at openjdk.java.net  Sun Apr 10 04:56:42 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Sun, 10 Apr 2022 04:56:42 GMT
Subject: RFR: 8282716: [macos] Enable
 javax/swing/JScrollPane/TestMouseWheelScroll.java on macos
In-Reply-To: <F0CzPHWEzAuSAyCUAiu3-JJ_Ue7SIyJWFzBwc70Zi6Q=.2734a6fa-2c72-4f5d-81df-32708a47edcd@github.com>
References: <-tuJ1M1iwo7tJ_hOHvrEylZmUdS3DPOSbySVFnJGrBI=.212c7ea6-e12a-48af-a4fa-ee3a586e4a38@github.com>
 <F0CzPHWEzAuSAyCUAiu3-JJ_Ue7SIyJWFzBwc70Zi6Q=.2734a6fa-2c72-4f5d-81df-32708a47edcd@github.com>
Message-ID: <5u81VPNyWXQD1LpDm7Vblfq4mwvKJHHkhsJjhvIipL4=.417639ac-b2f2-477c-8733-ec694919f360@github.com>

On Sat, 9 Apr 2022 05:35:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The scroll direction on macOS can be configured, can the test check what type of scroll is used on the current system and then use that to verify the old fix?

I see "Scroll direction: Natural" check in mouse in SystemPreference which is by default checked, 
which causes down-wheel scroll to "move up" and up-wheel scroll to "move down" and if unchecked, then it causes reverse.
But I could not find anyway to find in Java in Robot how to get scroll type of macos or for other platforms. 
If you are aware, let me know..
I guess we always test with default settings..

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

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


From psadhukhan at openjdk.java.net  Sun Apr 10 06:12:26 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Sun, 10 Apr 2022 06:12:26 GMT
Subject: RFR: 8282716: [macos] Enable
 javax/swing/JScrollPane/TestMouseWheelScroll.java on macos [v2]
In-Reply-To: <-tuJ1M1iwo7tJ_hOHvrEylZmUdS3DPOSbySVFnJGrBI=.212c7ea6-e12a-48af-a4fa-ee3a586e4a38@github.com>
References: <-tuJ1M1iwo7tJ_hOHvrEylZmUdS3DPOSbySVFnJGrBI=.212c7ea6-e12a-48af-a4fa-ee3a586e4a38@github.com>
Message-ID: <tc-YY_pb7eQtzEZW0RzMG5EPYtGJ2T0Yx71DtVojF5s=.de59bda4-9e66-47ee-a588-489c5ab4ecaa@github.com>

> The test was failing on macos and was excluded in macos because the viewposition was not changed after mouse wheel scroll. Seems like mouse wheel scroll direction is opposite in macos compared to windows etc so if we try to down-wheel scroll in macos when view position is at center of viewport (say element 3 is selected out of visible 7 elements), it cannot change viewposition as it cannot "scroll up" (since we are already at topmost viewport) whereas in windows, when we do down-wheel scroll in mouse wheel, it "scroll down" the viewport so viewposition is changed.
> 
> Fix is to use opposite scrolling motion in macos to check mouse wheel scroll is happening, which is what the testcase is meant for. CI testing of this test on all platform is ok.

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

  Check mousewheel rotation direction at runtime

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8123/files
  - new: https://git.openjdk.java.net/jdk/pull/8123/files/6494c339..61d23995

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

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

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


From psadhukhan at openjdk.java.net  Sun Apr 10 06:14:15 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Sun, 10 Apr 2022 06:14:15 GMT
Subject: RFR: 8282716: [macos] Enable
 javax/swing/JScrollPane/TestMouseWheelScroll.java on macos
In-Reply-To: <5u81VPNyWXQD1LpDm7Vblfq4mwvKJHHkhsJjhvIipL4=.417639ac-b2f2-477c-8733-ec694919f360@github.com>
References: <-tuJ1M1iwo7tJ_hOHvrEylZmUdS3DPOSbySVFnJGrBI=.212c7ea6-e12a-48af-a4fa-ee3a586e4a38@github.com>
 <F0CzPHWEzAuSAyCUAiu3-JJ_Ue7SIyJWFzBwc70Zi6Q=.2734a6fa-2c72-4f5d-81df-32708a47edcd@github.com>
 <5u81VPNyWXQD1LpDm7Vblfq4mwvKJHHkhsJjhvIipL4=.417639ac-b2f2-477c-8733-ec694919f360@github.com>
Message-ID: <6skAe2ei9eFYxhoi4cLuxjny85bnh9kYQqwZ8R5NRfs=.060f5526-dbf0-4eb7-b7bb-186205202a0a@github.com>

On Sun, 10 Apr 2022 04:53:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > The scroll direction on macOS can be configured, can the test check what type of scroll is used on the current system and then use that to verify the old fix?
> 
> I see "Scroll direction: Natural" check in mouse in SystemPreference which is by default checked, which causes down-wheel scroll to "move up" and up-wheel scroll to "move down" and if unchecked, then it causes reverse. But I could not find anyway to find in Java in Robot how to get scroll type of macos or for other platforms. If you are aware, let me know.. I guess we always test with default settings..

I have updated test to check wheel scroll type at runtime

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

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


From mvs at openjdk.java.net  Sun Apr 10 10:44:43 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Sun, 10 Apr 2022 10:44:43 GMT
Subject: RFR: 8284521: Write an automated regression test for RFE 4371575
 [v2]
In-Reply-To: <1UClEcAOD__BqjYbWR5fbG6fe_sopD9EgEPJCNMM-UA=.9c77864c-714c-403b-bc9f-3a2ca1dedc84@github.com>
References: <FgW8JkNC98cWCRNm8Tpsu75-EYCzO2wP4X-sM9rDkZs=.f66039d3-903b-42b3-b2f4-3af624d6fd4b@github.com>
 <Qv2iYnccQRtvScBKqUy6djNmBu0x2Ldpqg3AgVc3W8E=.0b8277a2-6447-4943-867d-f606358ad598@github.com>
 <1UClEcAOD__BqjYbWR5fbG6fe_sopD9EgEPJCNMM-UA=.9c77864c-714c-403b-bc9f-3a2ca1dedc84@github.com>
Message-ID: <ClimccUUDmP3e561wFLKSJnDvFM5WvoCGUbkg6bv-jQ=.f47b47e4-2dab-4ba1-aafc-93cebb16981e@github.com>

On Fri, 8 Apr 2022 17:57:42 GMT, Phil Race <prr at openjdk.org> wrote:

>> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment fixed: Removed unwanted directory
>
> test/jdk/javax/swing/JComponent/JComponentSetRequestFocusEnabledTest.java line 76:
> 
>> 74:                 }
>> 75:                 robot.waitForIdle();
>> 76: 
> 
> Since you specified robot.setAutoWaitForIdle(true) I wonder if this is needed ? Shouldn't do any harm though.

I thought robot.setAutoWaitForIdle(true) works only when some robot events like 'Mouse Press' or 'Key Events' got generated and it will call for robot.waitForIdle() for each of these generated event. But in this case we want to make sure the UI creation is completed and all the corresponding events are flushed, thats why its used here specifically. Please correct me if I'm wrong.

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

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


From psadhukhan at openjdk.java.net  Mon Apr 11 04:54:37 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 11 Apr 2022 04:54:37 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v2]
In-Reply-To: <e0DdIsh6yVwGbBaitK1dU_AKyAAdAKiqNDlLR8HZXhc=.df123d34-2d06-4faf-8919-4b5a61fca9bb@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <_UplvB0h9bWCInEGLRAN4bN3_sMypgu0hf0nU57pJgI=.8eef0557-500c-4939-b00f-ae9c0dd5a5b8@github.com>
 <p1lJJBIqQpVg6kwYcdWaFsZbLIfE0AkN3Tyl3gXmakE=.98fff17e-812b-4f8b-97b6-4bc61e45ce03@github.com>
 <j97LbflNBQ6fh8KsWHH1YIaXVM6wjCZUOHVrvqzIfLY=.06847a3d-73bd-4102-90eb-06212ceb4f85@github.com>
 <ZdRINoL3gR4NKDSIii_LU0HA_r5dwjgZKhcGO6ZpC9g=.7ff404d4-59ab-4f65-8e35-4b54db4f7531@github.com>
 <e0DdIsh6yVwGbBaitK1dU_AKyAAdAKiqNDlLR8HZXhc=.df123d34-2d06-4faf-8919-4b5a61fca9bb@github.com>
Message-ID: <LW8Ay6O_3F__4iXZ-bNGhQK4G4QdEEeAWx6hUmAk2EQ=.30cb6646-6360-4e9d-b882-53cb98b8195d@github.com>

On Fri, 8 Apr 2022 12:06:06 GMT, Tejesh R <duke at openjdk.java.net> wrote:

> Yes, the original issue was observed and raised in Windows alone...... In Mac and Linux the control wont even enters this logic -
> 
> ```
>   if (endOfLineProperty != null && !endOfLine.equals("\n")) {
>             // There is an end of line string that isn't \n, have to iterate
>             // through and find all \n's and translate to end of line string.
> ```

Since you mentioned in mac/linux it wont even enter the above path, then I guess in below code

if (array[counter - 1] == '\r') {
                                out.write(array, last, counter - last - 1);
                            } else {
                                out.write(array, last, counter - last);
                            }

the else part is a no-op as in windows \r\n is present so I think always the check `if (array[counter - 1] == '\r')` will be satisfied

If this is true, then I guess we can remove `if (array[counter - 1] == '\r')` check too as it is always true in windows..

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

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


From duke at openjdk.java.net  Mon Apr 11 04:59:58 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Mon, 11 Apr 2022 04:59:58 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v5]
In-Reply-To: <QZjXmHvLwwFYgc4_vh6Y5ku4VCuMxtelkX12tAIyuk4=.fcf0c020-a266-422c-b12b-f790119ebae7@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <bFJoKiD6n9BimxrGVu8lNW-m3RswKRF_hGhfU905VMs=.94c9f727-2afc-4dde-ab57-f5737d9a034b@github.com>
 <QZjXmHvLwwFYgc4_vh6Y5ku4VCuMxtelkX12tAIyuk4=.fcf0c020-a266-422c-b12b-f790119ebae7@github.com>
Message-ID: <Eqo6tqg-hfnGx_EgGCFIvnM2MX1UQeoR8srjpRp8u-k=.8752cea5-6475-439f-99df-ae67a3953cf0@github.com>

On Fri, 8 Apr 2022 12:37:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> What happens if you add `\r` to an arbitrary location in text?
> 
> What happens if you read in such a text?

It doesn't matter, since the data is appended only if '\n' is present when EndofLine is '\r\n'......

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

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


From duke at openjdk.java.net  Mon Apr 11 05:18:46 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Mon, 11 Apr 2022 05:18:46 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v2]
In-Reply-To: <LW8Ay6O_3F__4iXZ-bNGhQK4G4QdEEeAWx6hUmAk2EQ=.30cb6646-6360-4e9d-b882-53cb98b8195d@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <_UplvB0h9bWCInEGLRAN4bN3_sMypgu0hf0nU57pJgI=.8eef0557-500c-4939-b00f-ae9c0dd5a5b8@github.com>
 <p1lJJBIqQpVg6kwYcdWaFsZbLIfE0AkN3Tyl3gXmakE=.98fff17e-812b-4f8b-97b6-4bc61e45ce03@github.com>
 <j97LbflNBQ6fh8KsWHH1YIaXVM6wjCZUOHVrvqzIfLY=.06847a3d-73bd-4102-90eb-06212ceb4f85@github.com>
 <ZdRINoL3gR4NKDSIii_LU0HA_r5dwjgZKhcGO6ZpC9g=.7ff404d4-59ab-4f65-8e35-4b54db4f7531@github.com>
 <e0DdIsh6yVwGbBaitK1dU_AKyAAdAKiqNDlLR8HZXhc=.df123d34-2d06-4faf-8919-4b5a61fca9bb@github.com>
 <LW8Ay6O_3F__4iXZ-bNGhQK4G4QdEEeAWx6hUmAk2EQ=.30cb6646-6360-4e9d-b882-53cb98b8195d@github.com>
Message-ID: <ahuWklIBkv5MeVYv0RWYCRk0p7E-GoVW6FdKj-0mlnY=.0a42a3d1-f5e1-4444-98b6-3e465724500d@github.com>

On Mon, 11 Apr 2022 04:51:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> If this is true, then I guess we can remove `if (array[counter - 1] == '\r')` check too as it is always true in windows.

If user uses system line separator then it vll be '\r\n' and it vll enter this loop, but if user manually enters \n in the string (unusual case) then it vll enter the else part....... To handle those unusual scenarios else case is required I guess.......

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

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


From psadhukhan at openjdk.java.net  Mon Apr 11 05:24:36 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 11 Apr 2022 05:24:36 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v2]
In-Reply-To: <ahuWklIBkv5MeVYv0RWYCRk0p7E-GoVW6FdKj-0mlnY=.0a42a3d1-f5e1-4444-98b6-3e465724500d@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <_UplvB0h9bWCInEGLRAN4bN3_sMypgu0hf0nU57pJgI=.8eef0557-500c-4939-b00f-ae9c0dd5a5b8@github.com>
 <p1lJJBIqQpVg6kwYcdWaFsZbLIfE0AkN3Tyl3gXmakE=.98fff17e-812b-4f8b-97b6-4bc61e45ce03@github.com>
 <j97LbflNBQ6fh8KsWHH1YIaXVM6wjCZUOHVrvqzIfLY=.06847a3d-73bd-4102-90eb-06212ceb4f85@github.com>
 <ZdRINoL3gR4NKDSIii_LU0HA_r5dwjgZKhcGO6ZpC9g=.7ff404d4-59ab-4f65-8e35-4b54db4f7531@github.com>
 <e0DdIsh6yVwGbBaitK1dU_AKyAAdAKiqNDlLR8HZXhc=.df123d34-2d06-4faf-8919-4b5a61fca9bb@github.com>
 <LW8Ay6O_3F__4iXZ-bNGhQK4G4QdEEeAWx6hUmAk2EQ=.30cb6646-6360-4e9d-b882-53cb98b8195d@github.com>
 <ahuWklIBkv5MeVYv0RWYCRk0p7E-GoVW6FdKj-0mlnY=.0a42a3d1-f5e1-4444-98b6-3e465724500d@github.com>
Message-ID: <xuHJmhsfOpUg1PzK66k5m4WrS4wwqRmaLn7UZRInsgE=.4b3e503f-9269-47bd-afa6-618155c67d27@github.com>

On Mon, 11 Apr 2022 05:15:22 GMT, Tejesh R <duke at openjdk.java.net> wrote:

> > If this is true, then I guess we can remove `if (array[counter - 1] == '\r')` check too as it is always true in windows.
> 
> If user uses system line separator then it vll be '\r\n' and it vll enter this loop, but if user manually enters \n in the string (unusual case) then it vll enter the else part....... To handle those unusual scenarios else case is required I guess.......

I guess in that case "else" part in l359 will be executed...I was talking about requirement of "else" part in l345

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

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


From duke at openjdk.java.net  Mon Apr 11 05:29:45 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Mon, 11 Apr 2022 05:29:45 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v2]
In-Reply-To: <xuHJmhsfOpUg1PzK66k5m4WrS4wwqRmaLn7UZRInsgE=.4b3e503f-9269-47bd-afa6-618155c67d27@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <_UplvB0h9bWCInEGLRAN4bN3_sMypgu0hf0nU57pJgI=.8eef0557-500c-4939-b00f-ae9c0dd5a5b8@github.com>
 <p1lJJBIqQpVg6kwYcdWaFsZbLIfE0AkN3Tyl3gXmakE=.98fff17e-812b-4f8b-97b6-4bc61e45ce03@github.com>
 <j97LbflNBQ6fh8KsWHH1YIaXVM6wjCZUOHVrvqzIfLY=.06847a3d-73bd-4102-90eb-06212ceb4f85@github.com>
 <ZdRINoL3gR4NKDSIii_LU0HA_r5dwjgZKhcGO6ZpC9g=.7ff404d4-59ab-4f65-8e35-4b54db4f7531@github.com>
 <e0DdIsh6yVwGbBaitK1dU_AKyAAdAKiqNDlLR8HZXhc=.df123d34-2d06-4faf-8919-4b5a61fca9bb@github.com>
 <LW8Ay6O_3F__4iXZ-bNGhQK4G4QdEEeAWx6hUmAk2EQ=.30cb6646-6360-4e9d-b882-53cb98b8195d@github.com>
 <ahuWklIBkv5MeVYv0RWYCRk0p7E-GoVW6FdKj-0mlnY=.0a42a3d1-f5e1-4444-98b6-3e465724500d@github.com>
 <xuHJmhsfOpUg1PzK66k5m4WrS4wwqRmaLn7UZRInsgE=.4b3e503f-9269-47bd-afa6-618155c67d27@github.com>
Message-ID: <-BtJH5mB_rQX1P5oar_9Sf0aZRf9tKfJ8Hf1YA34P4M=.8b74bdce-0ace-4e43-8713-af4916b3a831@github.com>

On Mon, 11 Apr 2022 05:21:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I guess in that case "else" part in l359 will be executed...I was talking about requirement of "else" part in l345

I did a sample test for this case, it did entered l345, I added \n manually at the end of string, since it passes `if (array[counter] == '\n') {` (l340) condition and fails `if (array[counter - 1] == '\r')` (l342), it executes the else part in l345.....

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

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


From duke at openjdk.java.net  Mon Apr 11 05:53:57 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Mon, 11 Apr 2022 05:53:57 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux [v3]
In-Reply-To: <UMiKAzpVPAwNxlsIVJr3E48ULLs2yPZjbSxyMDPUat4=.02689a69-92e1-46a1-960e-613dd9f88077@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
 <1s3rujPqPuQFiA9xp2Rq4UoXMfP5fSpzQX_CNfl-UXw=.4b2a2871-1647-4c2f-a368-44ef8c7896c4@github.com>
 <6bK-iNlPfRxkowIW1_7WYUulcJ9qpcvCBgcG44Q0mHs=.e04e5fc2-d532-4684-bab1-3fd94ba58048@github.com>
 <fvSzRbXWlxfgE4uwbkgtTa3O7kuFozKJHg_17HMspp0=.ee143b6f-b325-4820-a67f-67a2e849b746@github.com>
 <VTPzL0KG3zq5hWuJIPQSFbuYN0zQrKZ1TUQbRC15NFw=.674f7a4f-006d-49c6-835d-3f1aa415e073@github.com>
 <uzy1Y8BY6CPGA6P8v8trMNI_WQVQ2yB2F-A4ZSzKKKw=.f7cd7620-8af8-4838-9543-b4360eed0716@github.com>
 <FMgkU_KLTjUHkuxa9-U7xI30t8B_IHHaszREoUO8Ehg=.aed7fd39-f15f-4195-b4bb-f5c568b890b3@github.com>
 <Y-uxICqIcG5sRL0zvduHoh5nauC2hyOiMkkLDG4PTvo=.dc9ad869-933c-407b-8897-ad05160a2a23@github.com>
 <UMiKAzpVPAwNxlsIVJr3E48ULLs2yPZjbSxyMDPUat4=.02689a69-92e1-46a1-960e-613dd9f88077@github.com>
Message-ID: <HErb2ksd-zgvBX3NGwEYXxuF0RUWqWRTuOAA1homw60=.20a31855-9519-4550-9917-4b4576b7140e@github.com>

On Sat, 9 Apr 2022 22:13:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> @mrserb I agree with your logic, but fixing this now would certainly be not a semantically null change and would complicate the fix that has already been under review for over two months. I'd be happy to file a bug for this separate issue.
>
> The separate CR would be fine.

@mrserb  I filed [JDK-8284645](https://bugs.openjdk.java.net/browse/JDK-8284645). Please, add more info there if necessary.

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

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


From duke at openjdk.java.net  Mon Apr 11 06:27:44 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Mon, 11 Apr 2022 06:27:44 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v8]
In-Reply-To: <aKWrOQ_B3iWzXECCc6lUYE3ii6MOT3uBflVM4oSs7Ck=.07eb26cc-a502-494e-9dfc-b46b2d2dd6b5@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <afJ29wQf2smgANBt5YTQC4oODoch8zxa0YqdtUZDfW8=.f4d0de4d-5245-4491-a8e8-05aaf2a4797a@github.com>
 <gzymK8AsH16kj6YIbJoMuRVGTDkKwLd_O3rbbDZCWIQ=.1f491527-2bac-4e6d-a5cc-f8443bf4f352@github.com>
 <MENhs6_2RTKjMOcWkh1CzumSIwQOy75T_wLac37Vkl8=.0da493e3-d91d-4b48-bd58-f69cefce3a9b@github.com>
 <wrQgwI3XG2G9_X8n5n4Q_AzDnMElxB92075XY3bkJMQ=.f5fb8350-489d-44a1-935a-e752b78347cd@github.com>
 <fR3AZPwa0kAz6SJDa5ns4eyyjCIAY_s25IlS2SL2xSw=.c8689931-ded8-448f-8caa-a17b47f7631a@github.com>
 <7ot0fBLQsvKiNsxLdrbnv4R_MNr6qdLN_GBwNPjU-rY=.dcad59a1-d0d6-42b9-bdf4-6290f31a88e0@github.com>
 <aKWrOQ_B3iWzXECCc6lUYE3ii6MOT3uBflVM4oSs7Ck=.07eb26cc-a502-494e-9dfc-b46b2d2dd6b5@github.com>
Message-ID: <O0CcYkSID4VbXni4_hNoQKMK2TbCon7iW2IWgND1T4A=.3741a949-2397-4958-826d-bbef72e03031@github.com>

On Fri, 8 Apr 2022 07:55:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> @prrace @prsadhuk 
>> The issue with the system color returned by **keyboardFocusIndicatorColor** mentioned above, persists on macOS 12.3 as well.
>
> "accentColor" is swift property so not usable for jdk but you can use "controlAccentColor" which seems to work with 10.15 and 12.1 as per my limited testing.
> You need to use @available check though..
> Even though it may not work for version lesser than 10.14, I guess it's ok as those versions are more or less obsolete and we will not be worse off than where we are now...
> While you are at it, please consider renaming this function as told.

@prsadhuk Update PR with the recommended changes. The "controlAccentColor" changes works as expected in Mac 12.3 as well. 
One thing that I wanted to clarify with the fix is - the focus ring color ("Focus.ring") is used at two other places AquaButtonUI and AquaFocus (for focused icon). With the current fix I'm setting **KEYBOARD_FOCUS_COLOR** as below - 

<img width="1092" alt="image" src="https://user-images.githubusercontent.com/95945681/162673487-26006ca1-9373-4fe7-8f0b-f99cd47b2eb7.png">

Before and After images of focused icon -

**Before**

<img width="185" alt="image" src="https://user-images.githubusercontent.com/95945681/162674337-ebbfea9f-e753-4b4c-a624-7cef5b8d8c1b.png">

**After (focus around icon slightly darker - focus ring color obtained from controlAccentColor property)**

<img width="198" alt="image" src="https://user-images.githubusercontent.com/95945681/162674444-b917de71-8e91-472e-a8f0-da48df0a43a5.png">

Please let me know in case I need to add a NEW color (as shown below) instead of reusing the KEYBOARD_FOCUS_COLOR if the color effects on focused icon/ button doesn't look correct.

<img width="1099" alt="image" src="https://user-images.githubusercontent.com/95945681/162675955-efd9c77f-6d7b-41e7-803a-50f49154fba5.png">

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

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


From psadhukhan at openjdk.java.net  Mon Apr 11 07:10:43 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 11 Apr 2022 07:10:43 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v8]
In-Reply-To: <O0CcYkSID4VbXni4_hNoQKMK2TbCon7iW2IWgND1T4A=.3741a949-2397-4958-826d-bbef72e03031@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <afJ29wQf2smgANBt5YTQC4oODoch8zxa0YqdtUZDfW8=.f4d0de4d-5245-4491-a8e8-05aaf2a4797a@github.com>
 <gzymK8AsH16kj6YIbJoMuRVGTDkKwLd_O3rbbDZCWIQ=.1f491527-2bac-4e6d-a5cc-f8443bf4f352@github.com>
 <MENhs6_2RTKjMOcWkh1CzumSIwQOy75T_wLac37Vkl8=.0da493e3-d91d-4b48-bd58-f69cefce3a9b@github.com>
 <wrQgwI3XG2G9_X8n5n4Q_AzDnMElxB92075XY3bkJMQ=.f5fb8350-489d-44a1-935a-e752b78347cd@github.com>
 <fR3AZPwa0kAz6SJDa5ns4eyyjCIAY_s25IlS2SL2xSw=.c8689931-ded8-448f-8caa-a17b47f7631a@github.com>
 <7ot0fBLQsvKiNsxLdrbnv4R_MNr6qdLN_GBwNPjU-rY=.dcad59a1-d0d6-42b9-bdf4-6290f31a88e0@github.com>
 <aKWrOQ_B3iWzXECCc6lUYE3ii6MOT3uBflVM4oSs7Ck=.07eb26cc-a502-494e-9dfc-b46b2d2dd6b5@github.com>
 <O0CcYkSID4VbXni4_hNoQKMK2TbCon7iW2IWgND1T4A=.3741a949-2397-4958-826d-bbef72e03031@github.com>
Message-ID: <Qa-HnVCda_3_Z38W4_XLpTg3Q37WDsXhiPSVl7D-AWA=.b6852efc-c828-47bb-ad88-0abead85509b@github.com>

On Mon, 11 Apr 2022 06:24:46 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> "accentColor" is swift property so not usable for jdk but you can use "controlAccentColor" which seems to work with 10.15 and 12.1 as per my limited testing.
>> You need to use @available check though..
>> Even though it may not work for version lesser than 10.14, I guess it's ok as those versions are more or less obsolete and we will not be worse off than where we are now...
>> While you are at it, please consider renaming this function as told.
>
> @prsadhuk Update PR with the recommended changes. The "controlAccentColor" changes works as expected in Mac 12.3 as well. 
> One thing that I wanted to clarify with the fix is - the focus ring color ("Focus.ring") is used at two other places AquaButtonUI and AquaFocus (for focused icon). With the current fix I'm setting **KEYBOARD_FOCUS_COLOR** as below - 
> 
> <img width="1092" alt="image" src="https://user-images.githubusercontent.com/95945681/162673487-26006ca1-9373-4fe7-8f0b-f99cd47b2eb7.png">
> 
> Before and After images of focused icon -
> 
> **Before**
> 
> <img width="185" alt="image" src="https://user-images.githubusercontent.com/95945681/162674337-ebbfea9f-e753-4b4c-a624-7cef5b8d8c1b.png">
> 
> **After (focus around icon slightly darker - focus ring color obtained from controlAccentColor property)**
> 
> <img width="198" alt="image" src="https://user-images.githubusercontent.com/95945681/162674444-b917de71-8e91-472e-a8f0-da48df0a43a5.png">
> 
> Please let me know in case I need to add a NEW color (as shown below) instead of reusing the KEYBOARD_FOCUS_COLOR if the color effects on focused icon/ button doesn't look correct.
> 
> <img width="1099" alt="image" src="https://user-images.githubusercontent.com/95945681/162675955-efd9c77f-6d7b-41e7-803a-50f49154fba5.png">

It seems KEYBOARD_FOCUS_COLOR via `focusRingColor` is also used for menuSelectedBackgroundColor which is used for 

CheckBoxMenuItem.selectionBackground
ComboBox.selectionBackground
Menu.selectionBackground
MenuBar.selectionBackground
MenuItem.selectionBackground
"PopupMenu.selectionBackground", menuSelectedBackgroundColor,
RadioButtonMenuItem.selectionBackground

which might also get affected if you use new property, so you need to test all those widgets if you intend to use reuse KEYBOARD_FOCUS_COLOR  so I guess safe bet is to use new color as you mentioned to limit the change to highlight color.

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

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


From psadhukhan at openjdk.java.net  Mon Apr 11 08:45:25 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 11 Apr 2022 08:45:25 GMT
Subject: RFR: 8284646: Some swing test fail in macos12-aarch64 host
Message-ID: <MelCohsH9Jfezuli0QR2aWK6I78c5c09IT9aSWIWXys=.536ada73-ee97-4191-92d6-b29c73c4e956@github.com>

Few tests  are seen to be failing in macos12 M1 system due to slight difference in color as mentioned in [JDK-8277816](https://bugs.openjdk.java.net/browse/JDK-8277816)

It seems the color difference was around 6-7 for swing tests, so these tests are extracted out in this issue and fixed by adding tolerance.
I could not find, in M1 osx12.3 SystemPreferences, any way to set Color Profile to sRGB IEC61966-2.1 Profile so it seems osx12.x M1 use default setting.

Several runs in CI system in all platforms including 12.x M1 pass with this change (test job link in JBS)

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

Commit messages:
 - 8284646: Some swing test fail in macos12-aarch64 host

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

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


From psadhukhan at openjdk.java.net  Mon Apr 11 09:54:40 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 11 Apr 2022 09:54:40 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v2]
In-Reply-To: <-BtJH5mB_rQX1P5oar_9Sf0aZRf9tKfJ8Hf1YA34P4M=.8b74bdce-0ace-4e43-8713-af4916b3a831@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <_UplvB0h9bWCInEGLRAN4bN3_sMypgu0hf0nU57pJgI=.8eef0557-500c-4939-b00f-ae9c0dd5a5b8@github.com>
 <p1lJJBIqQpVg6kwYcdWaFsZbLIfE0AkN3Tyl3gXmakE=.98fff17e-812b-4f8b-97b6-4bc61e45ce03@github.com>
 <j97LbflNBQ6fh8KsWHH1YIaXVM6wjCZUOHVrvqzIfLY=.06847a3d-73bd-4102-90eb-06212ceb4f85@github.com>
 <ZdRINoL3gR4NKDSIii_LU0HA_r5dwjgZKhcGO6ZpC9g=.7ff404d4-59ab-4f65-8e35-4b54db4f7531@github.com>
 <e0DdIsh6yVwGbBaitK1dU_AKyAAdAKiqNDlLR8HZXhc=.df123d34-2d06-4faf-8919-4b5a61fca9bb@github.com>
 <LW8Ay6O_3F__4iXZ-bNGhQK4G4QdEEeAWx6hUmAk2EQ=.30cb6646-6360-4e9d-b882-53cb98b8195d@github.com>
 <ahuWklIBkv5MeVYv0RWYCRk0p7E-GoVW6FdKj-0mlnY=.0a42a3d1-f5e1-4444-98b6-3e465724500d@github.com>
 <xuHJmhsfOpUg1PzK66k5m4WrS4wwqRmaLn7UZRInsgE=.4b3e503f-9269-47bd-afa6-618155c67d27@github.com>
 <-BtJH5mB_rQX1P5oar_9Sf0aZRf9tKfJ8Hf1YA34P4M=.8b74bdce-0ace-4e43-8713-af4916b3a831@github.com>
Message-ID: <2iwYbrtwatppiRFOhkdbKlHnx8Yzy_pspg8M66vb7Gc=.0311637d-9422-4685-b734-b28f5b0759f3@github.com>

On Mon, 11 Apr 2022 05:26:29 GMT, Tejesh R <duke at openjdk.java.net> wrote:

> > I guess in that case "else" part in l359 will be executed...I was talking about requirement of "else" part in l345
> 
> I did a sample test for this case, it did entered l345, I added \n manually at the end of string, since it passes `if (array[counter] == '\n') {` (l340) condition and fails `if (array[counter - 1] == '\r')` (l342), it executes the else part in l345.....

If you manually add \n to end of string, then as per your previous statements, this code block should have `\n\r\n` and then `\n` , right?
Then, I guess user would expect one new line because he manually added \n, 
but as per your observation, the "else" part is executed so wouldn't `out.write(array, last, counter - last);`
write the full \n\r\n\n again, ie 3 new lines?

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

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


From aivanov at openjdk.java.net  Mon Apr 11 10:13:42 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 11 Apr 2022 10:13:42 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v2]
In-Reply-To: <2iwYbrtwatppiRFOhkdbKlHnx8Yzy_pspg8M66vb7Gc=.0311637d-9422-4685-b734-b28f5b0759f3@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <_UplvB0h9bWCInEGLRAN4bN3_sMypgu0hf0nU57pJgI=.8eef0557-500c-4939-b00f-ae9c0dd5a5b8@github.com>
 <p1lJJBIqQpVg6kwYcdWaFsZbLIfE0AkN3Tyl3gXmakE=.98fff17e-812b-4f8b-97b6-4bc61e45ce03@github.com>
 <j97LbflNBQ6fh8KsWHH1YIaXVM6wjCZUOHVrvqzIfLY=.06847a3d-73bd-4102-90eb-06212ceb4f85@github.com>
 <ZdRINoL3gR4NKDSIii_LU0HA_r5dwjgZKhcGO6ZpC9g=.7ff404d4-59ab-4f65-8e35-4b54db4f7531@github.com>
 <e0DdIsh6yVwGbBaitK1dU_AKyAAdAKiqNDlLR8HZXhc=.df123d34-2d06-4faf-8919-4b5a61fca9bb@github.com>
 <LW8Ay6O_3F__4iXZ-bNGhQK4G4QdEEeAWx6hUmAk2EQ=.30cb6646-6360-4e9d-b882-53cb98b8195d@github.com>
 <ahuWklIBkv5MeVYv0RWYCRk0p7E-GoVW6FdKj-0mlnY=.0a42a3d1-f5e1-4444-98b6-3e465724500d@github.com>
 <xuHJmhsfOpUg1PzK66k5m4WrS4wwqRmaLn7UZRInsgE=.4b3e503f-9269-47bd-afa6-618155c67d27@github.com>
 <-BtJH5mB_rQX1P5oar_9Sf0aZRf9tKfJ8Hf1YA34P4M=.8b74bdce-0ace-4e43-8713-af4916b3a831@github.com>
 <2iwYbrtwatppiRFOhkdbKlHnx8Yzy_pspg8
 M66vb7Gc=.0311637d-9422-4685-b734-b28f5b0759f3@github.com>
Message-ID: <cl-UT7swoqkttPna-pY31fwU1UfozNEpJLLYQpOolsw=.609f200d-fbce-4785-b45a-b5b03a54d50d@github.com>

On Mon, 11 Apr 2022 09:51:12 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > > I guess in that case "else" part in l359 will be executed...I was talking about requirement of "else" part in l345
> > 
> > 
> > I did a sample test for this case, it did entered l345, I added \n manually at the end of string, since it passes `if (array[counter] == '\n') {` (l340) condition and fails `if (array[counter - 1] == '\r')` (l342), it executes the else part in l345.....
> 
> If you manually add \n to end of string, then as per your previous statements, this code block should have `\n\r\n` and then `\n` , right? Then, I guess user would expect one new line because he manually added \n, but as per your observation, the "else" part is executed so wouldn't `out.write(array, last, counter - last);` write the full \n\r\n\n again, ie 3 new lines?

I admit I got lost in the discussion.

If I understand correctly, the text model removes `\r` from `\r\n` when reading text files. In the `Document` model, `\n` represents the end of the line.

The user explicitly added a text with Windows line end into the text model. When such a text is written out on Windows, an extra `\r` gets added. Then when this text is read in, the `\r` which is not followed by `\n` gets converted to `\n` which results in a new line break.

The `else` block is needed, and it's the most common branch. The text model doesn't contain `\r` (should not contain). When the text is written out on Windows, line ends of `\n` are converted to `\r\n`.

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

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


From duke at openjdk.java.net  Mon Apr 11 10:13:44 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Mon, 11 Apr 2022 10:13:44 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v5]
In-Reply-To: <bFJoKiD6n9BimxrGVu8lNW-m3RswKRF_hGhfU905VMs=.94c9f727-2afc-4dde-ab57-f5737d9a034b@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <bFJoKiD6n9BimxrGVu8lNW-m3RswKRF_hGhfU905VMs=.94c9f727-2afc-4dde-ab57-f5737d9a034b@github.com>
Message-ID: <bicTGv-nNKW60RMNB1CTOUJ-GFCc77yv5wtFCf3zCko=.70d680f4-e9a1-4322-bb72-24661ddee0d3@github.com>

On Fri, 8 Apr 2022 12:17:37 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> getText function returned extra endOfLine when appended. The reason was in `EditorEditorKit` class, `write(Writer out, Document doc, int pos, int len)` method, where translation happens from buffer to Out(Writer Object) if endOfLine is other than '\n' ( which is '\r\n' in windows). In order to write each line till End of line, the string till '\n' is written including '\r' and again endOfLine is written which results in extra Carriage Return. To solve this issue, a Condition is added which checks if previous character to '\n' is '\r', if true then whole string except Carriage Return ('\r') is written, else whole string till before '\n' is written.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on Review Comments

> 

If I add '\n' after the string then it would be "\n\r\n" which would be mapped to "\r\n\r\n" resulting in extra space......

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

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


From aivanov at openjdk.java.net  Mon Apr 11 10:13:45 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 11 Apr 2022 10:13:45 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v5]
In-Reply-To: <Eqo6tqg-hfnGx_EgGCFIvnM2MX1UQeoR8srjpRp8u-k=.8752cea5-6475-439f-99df-ae67a3953cf0@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <bFJoKiD6n9BimxrGVu8lNW-m3RswKRF_hGhfU905VMs=.94c9f727-2afc-4dde-ab57-f5737d9a034b@github.com>
 <QZjXmHvLwwFYgc4_vh6Y5ku4VCuMxtelkX12tAIyuk4=.fcf0c020-a266-422c-b12b-f790119ebae7@github.com>
 <Eqo6tqg-hfnGx_EgGCFIvnM2MX1UQeoR8srjpRp8u-k=.8752cea5-6475-439f-99df-ae67a3953cf0@github.com>
Message-ID: <n3n3wunKekJMExaqv37loE1yy4jPSwbirtyiUo7mFEk=.0c16d2c8-3501-430c-b927-4c2cc78da5d4@github.com>

On Mon, 11 Apr 2022 04:56:08 GMT, Tejesh R <duke at openjdk.java.net> wrote:

> > What happens if you add `\r` to an arbitrary location in text?
> > What happens if you read in such a text?
> 
> It doesn't matter, since the data is appended only if '\n' is present when EndofLine is '\r\n'......

I'm not as sure? Well, yes, the text will be written out like expected and `\r` character will be preserved. Yet when such a text will be read in, the stranded `\r` will be converted to `\n` which will create an unexpected line break. Or am I wrong?

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

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


From duke at openjdk.java.net  Mon Apr 11 10:13:46 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Mon, 11 Apr 2022 10:13:46 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v2]
In-Reply-To: <cl-UT7swoqkttPna-pY31fwU1UfozNEpJLLYQpOolsw=.609f200d-fbce-4785-b45a-b5b03a54d50d@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <_UplvB0h9bWCInEGLRAN4bN3_sMypgu0hf0nU57pJgI=.8eef0557-500c-4939-b00f-ae9c0dd5a5b8@github.com>
 <p1lJJBIqQpVg6kwYcdWaFsZbLIfE0AkN3Tyl3gXmakE=.98fff17e-812b-4f8b-97b6-4bc61e45ce03@github.com>
 <j97LbflNBQ6fh8KsWHH1YIaXVM6wjCZUOHVrvqzIfLY=.06847a3d-73bd-4102-90eb-06212ceb4f85@github.com>
 <ZdRINoL3gR4NKDSIii_LU0HA_r5dwjgZKhcGO6ZpC9g=.7ff404d4-59ab-4f65-8e35-4b54db4f7531@github.com>
 <e0DdIsh6yVwGbBaitK1dU_AKyAAdAKiqNDlLR8HZXhc=.df123d34-2d06-4faf-8919-4b5a61fca9bb@github.com>
 <LW8Ay6O_3F__4iXZ-bNGhQK4G4QdEEeAWx6hUmAk2EQ=.30cb6646-6360-4e9d-b882-53cb98b8195d@github.com>
 <ahuWklIBkv5MeVYv0RWYCRk0p7E-GoVW6FdKj-0mlnY=.0a42a3d1-f5e1-4444-98b6-3e465724500d@github.com>
 <xuHJmhsfOpUg1PzK66k5m4WrS4wwqRmaLn7UZRInsgE=.4b3e503f-9269-47bd-afa6-618155c67d27@github.com>
 <-BtJH5mB_rQX1P5oar_9Sf0aZRf9tKfJ8Hf1YA34P4M=.8b74bdce-0ace-4e43-8713-af4916b3a831@github.com>
 <2iwYbrtwatppiRFOhkdbKlHnx8Yzy_pspg8
 M66vb7Gc=.0311637d-9422-4685-b734-b28f5b0759f3@github.com>
 <cl-UT7swoqkttPna-pY31fwU1UfozNEpJLLYQpOolsw=.609f200d-fbce-4785-b45a-b5b03a54d50d@github.com>
Message-ID: <neduMFSyvQ0AQpma1ci7KG1pmLuYZ7TkbRC8O94pVRI=.c7a3b158-b86f-48c9-a0e8-153338902f26@github.com>

On Mon, 11 Apr 2022 10:07:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The user explicitly added a text with Windows line end into the text model. When such a text is written out on Windows, an extra `\r` gets added. Then when this text is read in, the `\r` which is not followed by `\n` gets converted to `\n` which results in a new line break.
> 
> The `else` block is needed, and it's the most common branch. The text model doesn't contain `\r` (should not contain). When the text is written out on Windows, line ends of `\n` are converted to `\r\n`.

Yes, exactly......

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

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


From duke at openjdk.java.net  Mon Apr 11 10:28:59 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Mon, 11 Apr 2022 10:28:59 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v5]
In-Reply-To: <n3n3wunKekJMExaqv37loE1yy4jPSwbirtyiUo7mFEk=.0c16d2c8-3501-430c-b927-4c2cc78da5d4@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <bFJoKiD6n9BimxrGVu8lNW-m3RswKRF_hGhfU905VMs=.94c9f727-2afc-4dde-ab57-f5737d9a034b@github.com>
 <QZjXmHvLwwFYgc4_vh6Y5ku4VCuMxtelkX12tAIyuk4=.fcf0c020-a266-422c-b12b-f790119ebae7@github.com>
 <Eqo6tqg-hfnGx_EgGCFIvnM2MX1UQeoR8srjpRp8u-k=.8752cea5-6475-439f-99df-ae67a3953cf0@github.com>
 <n3n3wunKekJMExaqv37loE1yy4jPSwbirtyiUo7mFEk=.0c16d2c8-3501-430c-b927-4c2cc78da5d4@github.com>
Message-ID: <7jWZ42U57HbI58cze_Z9FxJA-O_19gQBpojKQzJx_1s=.e29e4f45-5925-4c01-9449-1c7a06186d66@github.com>

On Mon, 11 Apr 2022 10:10:07 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > What happens if you add `\r` to an arbitrary location in text?
> > > What happens if you read in such a text?
> > 
> > 
> > It doesn't matter, since the data is appended only if '\n' is present when EndofLine is '\r\n'......
> 
> I'm not as sure? Well, yes, the text will be written out like expected and `\r` character will be preserved. Yet when such a text will be read in, the stranded `\r` will be converted to `\n` which will create an unexpected line break. Or am I wrong?

In `read(Reader in, Document doc, int pos)`, of DefaultEditorKit class, the logic states this 
`
        // Read in a block at a time, mapping \r\n to \n, as well as single
        // \r's to \n's. If a \r\n is encountered, \r\n will be set as the
        // newline string for the document, if \r is encountered it will
        // be set as the newline character, otherwise the newline property
        // for the document will be removed.
`

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

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


From aivanov at openjdk.java.net  Mon Apr 11 10:29:00 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 11 Apr 2022 10:29:00 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v5]
In-Reply-To: <7jWZ42U57HbI58cze_Z9FxJA-O_19gQBpojKQzJx_1s=.e29e4f45-5925-4c01-9449-1c7a06186d66@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <bFJoKiD6n9BimxrGVu8lNW-m3RswKRF_hGhfU905VMs=.94c9f727-2afc-4dde-ab57-f5737d9a034b@github.com>
 <QZjXmHvLwwFYgc4_vh6Y5ku4VCuMxtelkX12tAIyuk4=.fcf0c020-a266-422c-b12b-f790119ebae7@github.com>
 <Eqo6tqg-hfnGx_EgGCFIvnM2MX1UQeoR8srjpRp8u-k=.8752cea5-6475-439f-99df-ae67a3953cf0@github.com>
 <n3n3wunKekJMExaqv37loE1yy4jPSwbirtyiUo7mFEk=.0c16d2c8-3501-430c-b927-4c2cc78da5d4@github.com>
 <7jWZ42U57HbI58cze_Z9FxJA-O_19gQBpojKQzJx_1s=.e29e4f45-5925-4c01-9449-1c7a06186d66@github.com>
Message-ID: <dB5acntaAu91yElN4M7d-ny4NoX_5Jv0aqyTbxtMmUM=.070b2bdf-1e4b-4c20-b2e9-174b3d8e6f04@github.com>

On Mon, 11 Apr 2022 10:15:43 GMT, Tejesh R <duke at openjdk.java.net> wrote:

> > > What happens if you add `\r` to an arbitrary location in text?
> > > What happens if you read in such a text?
> > 
> > 
> > It doesn't matter, since the data is appended only if '\n' is present when EndofLine is '\r\n'......
> 
> I'm not as sure? Well, yes, the text will be written out like expected and `\r` character will be preserved. Yet when such a text will be read in, the stranded `\r` will be converted to `\n` which will create an unexpected line break. Or am I wrong?

I edited your test case at line 119:

        pane0.appendLine("MyJTextPane using append()\r and then calling setText()");

And it creates a new line break after `append()` in the first `JTextPane`.

> > > > What happens if you add `\r` to an arbitrary location in text?
> > > > What happens if you read in such a text?
> > > 
> > > 
> > > It doesn't matter, since the data is appended only if '\n' is present when EndofLine is '\r\n'......
> > 
> > 
> > I'm not as sure? Well, yes, the text will be written out like expected and `\r` character will be preserved. Yet when such a text will be read in, the stranded `\r` will be converted to `\n` which will create an unexpected line break. Or am I wrong?
> 
> In `read(Reader in, Document doc, int pos)`, of DefaultEditorKit class, the logic states this `// Read in a block at a time, mapping \r\n to \n, as well as single // \r's to \n's. If a \r\n is encountered, \r\n will be set as the // newline string for the document, if \r is encountered it will // be set as the newline character, otherwise the newline property // for the document will be removed.`

Is it a bug then?

The test case in the bug description behaves according to the spec too: `\r` gets converted to `\n`.

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

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


From duke at openjdk.java.net  Mon Apr 11 10:29:03 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Mon, 11 Apr 2022 10:29:03 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v5]
In-Reply-To: <bFJoKiD6n9BimxrGVu8lNW-m3RswKRF_hGhfU905VMs=.94c9f727-2afc-4dde-ab57-f5737d9a034b@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <bFJoKiD6n9BimxrGVu8lNW-m3RswKRF_hGhfU905VMs=.94c9f727-2afc-4dde-ab57-f5737d9a034b@github.com>
Message-ID: <HzbnPQJoq2zufxQguJWOTBcPC5IJIwer_Ca97LfmvJM=.ab000448-d7b2-4628-97ea-58db70b3d1ba@github.com>

On Fri, 8 Apr 2022 12:17:37 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> getText function returned extra endOfLine when appended. The reason was in `EditorEditorKit` class, `write(Writer out, Document doc, int pos, int len)` method, where translation happens from buffer to Out(Writer Object) if endOfLine is other than '\n' ( which is '\r\n' in windows). In order to write each line till End of line, the string till '\n' is written including '\r' and again endOfLine is written which results in extra Carriage Return. To solve this issue, a Condition is added which checks if previous character to '\n' is '\r', if true then whole string except Carriage Return ('\r') is written, else whole string till before '\n' is written.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on Review Comments

> > > > What happens if you add `\r` to an arbitrary location in text?
> > > > What happens if you read in such a text?
> > > 
> > > 
> > > It doesn't matter, since the data is appended only if '\n' is present when EndofLine is '\r\n'......
> > 
> > 
> > I'm not as sure? Well, yes, the text will be written out like expected and `\r` character will be preserved. Yet when such a text will be read in, the stranded `\r` will be converted to `\n` which will create an unexpected line break. Or am I wrong?
> 
> I edited your test case at line 119:
> 
> ```java
>         pane0.appendLine("MyJTextPane using append()\r and then calling setText()");
> ```
> 
> And it creates a new line break after `append()` in the first `JTextPane`.

Yeah, \r converted to newline character......

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

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


From aivanov at openjdk.java.net  Mon Apr 11 10:29:05 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 11 Apr 2022 10:29:05 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v5]
In-Reply-To: <bicTGv-nNKW60RMNB1CTOUJ-GFCc77yv5wtFCf3zCko=.70d680f4-e9a1-4322-bb72-24661ddee0d3@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <bFJoKiD6n9BimxrGVu8lNW-m3RswKRF_hGhfU905VMs=.94c9f727-2afc-4dde-ab57-f5737d9a034b@github.com>
 <bicTGv-nNKW60RMNB1CTOUJ-GFCc77yv5wtFCf3zCko=.70d680f4-e9a1-4322-bb72-24661ddee0d3@github.com>
Message-ID: <pRBZzb5UEs4yr8GO-xPrqOmtcGhmMe92CJm_kEuJQV8=.30533dbb-fa85-4e3b-8ce7-4417520072e0@github.com>

On Mon, 11 Apr 2022 10:08:24 GMT, Tejesh R <duke at openjdk.java.net> wrote:

> > 
> 
> If I add '\n' after the string then it would be "\n\r\n" which would be mapped to "\r\n\r\n" resulting in extra space......

Resulting in extra space?

As far as I can see, both samples have two line breaks and they're preserved. *With the updated code*, right?

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

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


From duke at openjdk.java.net  Mon Apr 11 10:29:07 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Mon, 11 Apr 2022 10:29:07 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v5]
In-Reply-To: <dB5acntaAu91yElN4M7d-ny4NoX_5Jv0aqyTbxtMmUM=.070b2bdf-1e4b-4c20-b2e9-174b3d8e6f04@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <bFJoKiD6n9BimxrGVu8lNW-m3RswKRF_hGhfU905VMs=.94c9f727-2afc-4dde-ab57-f5737d9a034b@github.com>
 <QZjXmHvLwwFYgc4_vh6Y5ku4VCuMxtelkX12tAIyuk4=.fcf0c020-a266-422c-b12b-f790119ebae7@github.com>
 <Eqo6tqg-hfnGx_EgGCFIvnM2MX1UQeoR8srjpRp8u-k=.8752cea5-6475-439f-99df-ae67a3953cf0@github.com>
 <n3n3wunKekJMExaqv37loE1yy4jPSwbirtyiUo7mFEk=.0c16d2c8-3501-430c-b927-4c2cc78da5d4@github.com>
 <7jWZ42U57HbI58cze_Z9FxJA-O_19gQBpojKQzJx_1s=.e29e4f45-5925-4c01-9449-1c7a06186d66@github.com>
 <dB5acntaAu91yElN4M7d-ny4NoX_5Jv0aqyTbxtMmUM=.070b2bdf-1e4b-4c20-b2e9-174b3d8e6f04@github.com>
Message-ID: <NdIjW5fSNiUvL7KsLRl78A2qOZCPVkollrRlq8Ss5NQ=.46a4c01e-97aa-420f-95a1-a2950ddf20e9@github.com>

On Mon, 11 Apr 2022 10:20:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Is it a bug then?

It is not a bug I guess, it is as expected and as commented out about the logic in `read()` method...... The bug states this statement " But if we use append() first and then setText(pane.getText + newText), before every \r\n another \r is added, and in output, extra blank line are added."...... In windows extra \r was added because of the previous logic, it was causing an extra empty line......

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

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


From duke at openjdk.java.net  Mon Apr 11 10:35:47 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Mon, 11 Apr 2022 10:35:47 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v5]
In-Reply-To: <bFJoKiD6n9BimxrGVu8lNW-m3RswKRF_hGhfU905VMs=.94c9f727-2afc-4dde-ab57-f5737d9a034b@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <bFJoKiD6n9BimxrGVu8lNW-m3RswKRF_hGhfU905VMs=.94c9f727-2afc-4dde-ab57-f5737d9a034b@github.com>
Message-ID: <HAlnx-zwi_kHJjopSnl33MZkia3GqHZg6DNrStKvN9Q=.48fb9eb3-02b6-4a31-bab0-b44f8040ac64@github.com>

On Fri, 8 Apr 2022 12:17:37 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> getText function returned extra endOfLine when appended. The reason was in `EditorEditorKit` class, `write(Writer out, Document doc, int pos, int len)` method, where translation happens from buffer to Out(Writer Object) if endOfLine is other than '\n' ( which is '\r\n' in windows). In order to write each line till End of line, the string till '\n' is written including '\r' and again endOfLine is written which results in extra Carriage Return. To solve this issue, a Condition is added which checks if previous character to '\n' is '\r', if true then whole string except Carriage Return ('\r') is written, else whole string till before '\n' is written.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on Review Comments

> > > 
> > 
> > 
> > If I add '\n' after the string then it would be "\n\r\n" which would be mapped to "\r\n\r\n" resulting in extra space......
> 
> Resulting in extra space?
> 
> As far as I can see, both samples have two line breaks and they're preserved. _With the updated code_, right?
Yeah, in old code also the result for this sample would be same I guess, the old code bug was only w.r.t "\r\n" (one line break) resulting in "\r\r\n" (two line breaks).

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

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


From aivanov at openjdk.java.net  Mon Apr 11 10:42:36 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 11 Apr 2022 10:42:36 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v5]
In-Reply-To: <NdIjW5fSNiUvL7KsLRl78A2qOZCPVkollrRlq8Ss5NQ=.46a4c01e-97aa-420f-95a1-a2950ddf20e9@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <bFJoKiD6n9BimxrGVu8lNW-m3RswKRF_hGhfU905VMs=.94c9f727-2afc-4dde-ab57-f5737d9a034b@github.com>
 <QZjXmHvLwwFYgc4_vh6Y5ku4VCuMxtelkX12tAIyuk4=.fcf0c020-a266-422c-b12b-f790119ebae7@github.com>
 <Eqo6tqg-hfnGx_EgGCFIvnM2MX1UQeoR8srjpRp8u-k=.8752cea5-6475-439f-99df-ae67a3953cf0@github.com>
 <n3n3wunKekJMExaqv37loE1yy4jPSwbirtyiUo7mFEk=.0c16d2c8-3501-430c-b927-4c2cc78da5d4@github.com>
 <7jWZ42U57HbI58cze_Z9FxJA-O_19gQBpojKQzJx_1s=.e29e4f45-5925-4c01-9449-1c7a06186d66@github.com>
 <dB5acntaAu91yElN4M7d-ny4NoX_5Jv0aqyTbxtMmUM=.070b2bdf-1e4b-4c20-b2e9-174b3d8e6f04@github.com>
 <NdIjW5fSNiUvL7KsLRl78A2qOZCPVkollrRlq8Ss5NQ=.46a4c01e-97aa-420f-95a1-a2950ddf20e9@github.com>
Message-ID: <E0CYpP_yIOLN-n1S6onHc2radPaWgQYtxAyw6n93Aqo=.b32b1b24-43d4-43d0-8cc1-2d6c03cd4891@github.com>

On Mon, 11 Apr 2022 10:26:35 GMT, Tejesh R <duke at openjdk.java.net> wrote:

> > Is it a bug then?
> 
> It is not a bug I guess, it is as expected and as commented out about the logic in `read()` method...... The bug states this statement " But if we use append() first and then setText(pane.getText + newText), before every \r\n another \r is added, and in output, extra blank line are added."...... In windows extra \r was added because of the previous logic, it was causing an extra empty line......

There will be no extra line if `System.lineSeparator()` is not used. And it shouldn't be used with text APIs: the text model always uses Linux/macOS style line ends that is `\n` only.

If you add `\r` into the text model, eventually it'll get converted to `\n` as specified by `DefaultEditorKit`.

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

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


From aivanov at openjdk.java.net  Mon Apr 11 12:11:56 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 11 Apr 2022 12:11:56 GMT
Subject: RFR: 8283507: Create a regression test for RFE 4287690 [v3]
In-Reply-To: <8I-5r07BeDPRL2uLjrILbcFMQAYszp2c5xpI8v_ZM0c=.c0d2f711-1281-435b-9c83-b31d94d4a3eb@github.com>
References: <SMPz0WRpMUC4SuuVSmlG6rsG_QudZ-1hCbjUzeMIdqk=.8318c1a4-4db6-4c0b-b24c-0b25b3d932a2@github.com>
 <8I-5r07BeDPRL2uLjrILbcFMQAYszp2c5xpI8v_ZM0c=.c0d2f711-1281-435b-9c83-b31d94d4a3eb@github.com>
Message-ID: <SeaoVRA1Z5_0XG7RXLmfVWhjE1iQb-IdcLGvJNNw1jA=.a2b7bd1d-72e6-49b6-961d-36be22df31c4@github.com>

On Fri, 8 Apr 2022 07:12:21 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Create a regression test for [JDK-4287690](https://bugs.openjdk.java.net/browse/JDK-4287690)
>> Issue description:
>> I want JComboBox to send an event just before the popup (drop down) list is displayed.
>> 
>> Fix:
>> This requires some additional API targeted for major release of the JDK (1.4).The PopupMenuEvent will from the JPopupMenu will be forwarded to the JComboBox. A client of the JComboBox can register itself as a PopupMenuListener to receive the notification.
>> So JComboBox should send drop down events when the drop down popup is visible as well as invisible. JComboBox.addPopupMenuListener(PopupMenuListener) can be used to register for pop up events.
>> 
>> Testing:
>> Tested using Mach5 in all platforms available(macos,linux and windows) and got all pass.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fixed: Removed unwanted directory

Looks good.

test/jdk/javax/swing/JComboBox/JComboBoxPopupMenuEventTest.java line 60:

> 58: 
> 59:     private static final String[] compStrs =
> 60:             {"apple", "citibank", "cisco", "cienna", "Oracle", "IBM"};

Probably, all company names should be capitalised?

test/jdk/javax/swing/JComboBox/JComboBoxPopupMenuEventTest.java line 134:

> 132:                 .invokeAndWait(() -> loc.set(jComponent.getLocationOnScreen()));
> 133:         final Point location = loc.get();
> 134:         return location;

Could be simplified to
Suggestion:

        return loc.get();

test/jdk/javax/swing/JComboBox/JComboBoxPopupMenuEventTest.java line 166:

> 164:                 for (String comp : comps) {
> 165:                     comboBox.addItem(comp);
> 166:                 }

Just a suggestion: use `.forEach` and add items to the `comboBox` right in the stream without creating an intermediate list.

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

Marked as reviewed by aivanov (Reviewer).

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


From aivanov at openjdk.java.net  Mon Apr 11 12:22:47 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 11 Apr 2022 12:22:47 GMT
Subject: RFR: 8284535 : Fix PrintLatinCJKTest.java test that is failing
 with Parse Exception [v6]
In-Reply-To: <yl672byV2wQNNcC_01QVttbStT208RYNPpvBYJrBd9I=.ff8bba6d-a726-4bcd-96de-54c552f2489a@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <jRQUt_Gl2j40pMIM7-8I-t65tojV2xvsfqUE3Bszsx0=.bd28654a-b226-4a48-985b-a3d2187ba75d@github.com>
 <yl672byV2wQNNcC_01QVttbStT208RYNPpvBYJrBd9I=.ff8bba6d-a726-4bcd-96de-54c552f2489a@github.com>
Message-ID: <0tBOmlX8CMkaVB8l0nQcd_YKXtQSlAH_8S0_SNQQmUk=.01cb6513-7667-4baa-bf4d-27b20337bfa1@github.com>

On Sat, 9 Apr 2022 06:31:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Just an idea can we replace the builtin in the jtreg "manual" tests machinery by something like this?

An interesting idea. However, this would require updating all the existing tests including those that use its custom UI for `run/manual`.

Is it worth?  
I doubt it?

> Also would like to raise a question: should we show the test instructions in the same VM where the test executed or we can show it in a separate VM?

A good idea. The instructions used to be shown in the same VM. And the majority of UI tests don't cause the VM to crash therefore the complexity of separating instructions from the test UI doesn't seem to provide much benefit.

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

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


From aturbanov at openjdk.java.net  Mon Apr 11 12:26:14 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Mon, 11 Apr 2022 12:26:14 GMT
Subject: RFR: 8284672: Collapse identical catch branches in java.desktop
Message-ID: <Hn-N6jOAqYovweOuFVBMML-Px6xr4Htj-y-snkbcCxA=.937877f9-8125-42a6-8260-382dba3fc005@github.com>

Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types".
It simplifies code. Reduces duplication.
Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' statement

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

Commit messages:
 - [PATCH] Collapse identical catch branches in java.desktop

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

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


From neugens at openjdk.java.net  Mon Apr 11 13:29:48 2022
From: neugens at openjdk.java.net (Mario Torre)
Date: Mon, 11 Apr 2022 13:29:48 GMT
Subject: RFR: 8284093: Memory leak: X11SD_DisposeXImage should also free
 obdata
In-Reply-To: <1X0DLnuKgL-jVip5RrGZZcxQof6Z0njfXDrymX1lojs=.35d58243-f34c-4737-a217-6118ebead825@github.com>
References: <1X0DLnuKgL-jVip5RrGZZcxQof6Z0njfXDrymX1lojs=.35d58243-f34c-4737-a217-6118ebead825@github.com>
Message-ID: <8H73Ke-nAWQ5bYn8x7RfYN8AwCba6hCkzRJb8dzDLLw=.5db7403b-77e3-439a-b1a5-895ffc25455c@github.com>

On Thu, 31 Mar 2022 13:30:40 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this small patch to fix leaking `XShmSegmentInfo` that is attached to `XImage`. 
> 
> Test:
> 
> - [x] jdk_2d

I'm not officially a reviewer but afaik there isn't any other place where the obdata is freed, and X11SD_DropSharedSegment doesn't do it, so we probably need to do it there. Since obdata is malloced in X11SD_CreateSharedImage, it seems correct to free it in X11SD_DisposeXImage (instead of directly within X11SD_DropSharedSegment), so the patch looks good to me.

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

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


From andrew at openjdk.java.net  Mon Apr 11 13:36:51 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Mon, 11 Apr 2022 13:36:51 GMT
Subject: RFR: 8284093: Memory leak: X11SD_DisposeXImage should also free
 obdata
In-Reply-To: <1X0DLnuKgL-jVip5RrGZZcxQof6Z0njfXDrymX1lojs=.35d58243-f34c-4737-a217-6118ebead825@github.com>
References: <1X0DLnuKgL-jVip5RrGZZcxQof6Z0njfXDrymX1lojs=.35d58243-f34c-4737-a217-6118ebead825@github.com>
Message-ID: <MDUPBAzlZIMjTmt3UF3Da2y9nU3Ff2kNxG7-MDJVSdM=.c33740c3-9801-47a2-b279-7fe1713ee3eb@github.com>

On Thu, 31 Mar 2022 13:30:40 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this small patch to fix leaking `XShmSegmentInfo` that is attached to `XImage`. 
> 
> Test:
> 
> - [x] jdk_2d

This looks correct to me.

There is another similar block:

        if (xsdo->shmPMData.shmSegInfo != NULL) {
            X11SD_DropSharedSegment(xsdo->shmPMData.shmSegInfo);
            xsdo->shmPMData.shmSegInfo = NULL;
        }

But `xsdo->shmPMData.shmSegInfo` is assigned `img->obdata` in `X11SD_CreateSharedPixmap`, so looks like this is the one and only place to free this.

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

Marked as reviewed by andrew (Reviewer).

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


From zgu at openjdk.java.net  Mon Apr 11 13:36:53 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 11 Apr 2022 13:36:53 GMT
Subject: RFR: 8284093: Memory leak: X11SD_DisposeXImage should also free
 obdata
In-Reply-To: <8H73Ke-nAWQ5bYn8x7RfYN8AwCba6hCkzRJb8dzDLLw=.5db7403b-77e3-439a-b1a5-895ffc25455c@github.com>
References: <1X0DLnuKgL-jVip5RrGZZcxQof6Z0njfXDrymX1lojs=.35d58243-f34c-4737-a217-6118ebead825@github.com>
 <8H73Ke-nAWQ5bYn8x7RfYN8AwCba6hCkzRJb8dzDLLw=.5db7403b-77e3-439a-b1a5-895ffc25455c@github.com>
Message-ID: <PItj45vPnjhzQxBHthEW4RzcRuZGqzb_Y1nyvbo0EAM=.29230d49-04b9-44d6-b511-34bf50835563@github.com>

On Mon, 11 Apr 2022 13:26:03 GMT, Mario Torre <neugens at openjdk.org> wrote:

>> Please review this small patch to fix leaking `XShmSegmentInfo` that is attached to `XImage`. 
>> 
>> Test:
>> 
>> - [x] jdk_2d
>
> I'm not officially a reviewer but afaik there isn't any other place where the obdata is freed, and X11SD_DropSharedSegment doesn't do it, so we probably need to do it there. Since obdata is malloced in X11SD_CreateSharedImage, it seems correct to free it in X11SD_DisposeXImage (instead of directly within X11SD_DropSharedSegment), so the patch looks good to me.

Thanks, @neugens @gnu-andrew

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

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


From zgu at openjdk.java.net  Mon Apr 11 13:39:43 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 11 Apr 2022 13:39:43 GMT
Subject: Integrated: 8284093: Memory leak: X11SD_DisposeXImage should also free
 obdata
In-Reply-To: <1X0DLnuKgL-jVip5RrGZZcxQof6Z0njfXDrymX1lojs=.35d58243-f34c-4737-a217-6118ebead825@github.com>
References: <1X0DLnuKgL-jVip5RrGZZcxQof6Z0njfXDrymX1lojs=.35d58243-f34c-4737-a217-6118ebead825@github.com>
Message-ID: <MisMFJKln3dUoyLkYXl6Usv1Jda6hmm2phJ8gzVfz-s=.df3a48a2-fd57-4e02-af1b-588ed31026fe@github.com>

On Thu, 31 Mar 2022 13:30:40 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this small patch to fix leaking `XShmSegmentInfo` that is attached to `XImage`. 
> 
> Test:
> 
> - [x] jdk_2d

This pull request has now been integrated.

Changeset: 205cfb84
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/205cfb84968fe93cbfe7d509e1e7d051ed05f97c
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8284093: Memory leak: X11SD_DisposeXImage should also free obdata

Reviewed-by: prr, andrew

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

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


From mvs at openjdk.java.net  Mon Apr 11 13:51:41 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Mon, 11 Apr 2022 13:51:41 GMT
Subject: RFR: 8283507: Create a regression test for RFE 4287690 [v4]
In-Reply-To: <SMPz0WRpMUC4SuuVSmlG6rsG_QudZ-1hCbjUzeMIdqk=.8318c1a4-4db6-4c0b-b24c-0b25b3d932a2@github.com>
References: <SMPz0WRpMUC4SuuVSmlG6rsG_QudZ-1hCbjUzeMIdqk=.8318c1a4-4db6-4c0b-b24c-0b25b3d932a2@github.com>
Message-ID: <gipjHh0eDNvM29I1JHQKkomCZHuwusyIlVkCzT7LeEI=.d3b772a9-94f6-4898-94aa-4c5bdcd008b7@github.com>

> Create a regression test for [JDK-4287690](https://bugs.openjdk.java.net/browse/JDK-4287690)
> Issue description:
> I want JComboBox to send an event just before the popup (drop down) list is displayed.
> 
> Fix:
> This requires some additional API targeted for major release of the JDK (1.4).The PopupMenuEvent will from the JPopupMenu will be forwarded to the JComboBox. A client of the JComboBox can register itself as a PopupMenuListener to receive the notification.
> So JComboBox should send drop down events when the drop down popup is visible as well as invisible. JComboBox.addPopupMenuListener(PopupMenuListener) can be used to register for pop up events.
> 
> Testing:
> Tested using Mach5 in all platforms available(macos,linux and windows) and got all pass.

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

  Review comments fixed: Formatting changes, removed unwanted for loop, company names in Camel

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7906/files
  - new: https://git.openjdk.java.net/jdk/pull/7906/files/cba696d7..a30db6a1

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

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

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


From aivanov at openjdk.java.net  Mon Apr 11 14:01:41 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 11 Apr 2022 14:01:41 GMT
Subject: RFR: 8283507: Create a regression test for RFE 4287690 [v4]
In-Reply-To: <gipjHh0eDNvM29I1JHQKkomCZHuwusyIlVkCzT7LeEI=.d3b772a9-94f6-4898-94aa-4c5bdcd008b7@github.com>
References: <SMPz0WRpMUC4SuuVSmlG6rsG_QudZ-1hCbjUzeMIdqk=.8318c1a4-4db6-4c0b-b24c-0b25b3d932a2@github.com>
 <gipjHh0eDNvM29I1JHQKkomCZHuwusyIlVkCzT7LeEI=.d3b772a9-94f6-4898-94aa-4c5bdcd008b7@github.com>
Message-ID: <ywqLx7NinWvy0aL5jKuaYbjZIFJ51qrPlDJfMTlqp2I=.bbab7c93-3e6a-4144-914a-0da9a7e785ec@github.com>

On Mon, 11 Apr 2022 13:51:41 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Create a regression test for [JDK-4287690](https://bugs.openjdk.java.net/browse/JDK-4287690)
>> Issue description:
>> I want JComboBox to send an event just before the popup (drop down) list is displayed.
>> 
>> Fix:
>> This requires some additional API targeted for major release of the JDK (1.4).The PopupMenuEvent will from the JPopupMenu will be forwarded to the JComboBox. A client of the JComboBox can register itself as a PopupMenuListener to receive the notification.
>> So JComboBox should send drop down events when the drop down popup is visible as well as invisible. JComboBox.addPopupMenuListener(PopupMenuListener) can be used to register for pop up events.
>> 
>> Testing:
>> Tested using Mach5 in all platforms available(macos,linux and windows) and got all pass.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: Formatting changes, removed unwanted for loop, company names in Camel

Marked as reviewed by aivanov (Reviewer).

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

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


From mvs at openjdk.java.net  Mon Apr 11 14:04:52 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Mon, 11 Apr 2022 14:04:52 GMT
Subject: Integrated: 8283507: Create a regression test for RFE 4287690
In-Reply-To: <SMPz0WRpMUC4SuuVSmlG6rsG_QudZ-1hCbjUzeMIdqk=.8318c1a4-4db6-4c0b-b24c-0b25b3d932a2@github.com>
References: <SMPz0WRpMUC4SuuVSmlG6rsG_QudZ-1hCbjUzeMIdqk=.8318c1a4-4db6-4c0b-b24c-0b25b3d932a2@github.com>
Message-ID: <4iPckKBvqPA5HmmxC41SZykZlmqoOKgGE_0D_ZzlP98=.b6a4b975-2b30-472f-8c38-a715dd51cd7f@github.com>

On Tue, 22 Mar 2022 15:48:39 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Create a regression test for [JDK-4287690](https://bugs.openjdk.java.net/browse/JDK-4287690)
> Issue description:
> I want JComboBox to send an event just before the popup (drop down) list is displayed.
> 
> Fix:
> This requires some additional API targeted for major release of the JDK (1.4).The PopupMenuEvent will from the JPopupMenu will be forwarded to the JComboBox. A client of the JComboBox can register itself as a PopupMenuListener to receive the notification.
> So JComboBox should send drop down events when the drop down popup is visible as well as invisible. JComboBox.addPopupMenuListener(PopupMenuListener) can be used to register for pop up events.
> 
> Testing:
> Tested using Mach5 in all platforms available(macos,linux and windows) and got all pass.

This pull request has now been integrated.

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

8283507: Create a regression test for RFE 4287690

Reviewed-by: serb, aivanov

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

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


From avu at openjdk.java.net  Mon Apr 11 15:01:40 2022
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 11 Apr 2022 15:01:40 GMT
Subject: RFR: 8283794: CCE in XRTextRenderer.drawGlyphList and
 XRMaskFill.MaskFill [v2]
In-Reply-To: <VE3eRPzRlyCMFgLc0XrQrvy2pgqszE6ZC3TG7fcDvz8=.5facf5d5-668b-4190-acbc-bb481524d1ac@github.com>
References: <GD4NAkuLptwylcQOI8VBAXXI1rY7ycgz8O2NvPmhIOc=.f2c8334e-d2eb-4717-92a1-de2f9ed301b6@github.com>
 <VE3eRPzRlyCMFgLc0XrQrvy2pgqszE6ZC3TG7fcDvz8=.5facf5d5-668b-4190-acbc-bb481524d1ac@github.com>
Message-ID: <Eph2OCngCnNfxUc23aFd7t20vsJKtvjyFesBODmC3CU=.54069b94-f060-417e-b2a9-0c7eddbe480f@github.com>

On Fri, 1 Apr 2022 15:43:29 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Throwing InvalidPipeException for incompatible surfaces
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8283794: CCE in XRTextRenderer.drawGlyphList and XRMaskFill.MaskFill
>   
>   Extracted try/catch logic of SurfaceData cast to particular SurfaceData subclass into convenience method SurfaceData.convertTo(). Applied the method to XRTextRenderer.drawGlyphList() and XRMaskFill.MaskFill(). Refactored try/catch blocks handling similar cases.

@aghaisas Could you please review these changes.

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

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


From aivanov at openjdk.java.net  Mon Apr 11 16:00:56 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 11 Apr 2022 16:00:56 GMT
Subject: RFR: 8284535 : Fix PrintLatinCJKTest.java test that is failing
 with Parse Exception [v6]
In-Reply-To: <jRQUt_Gl2j40pMIM7-8I-t65tojV2xvsfqUE3Bszsx0=.bd28654a-b226-4a48-985b-a3d2187ba75d@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <jRQUt_Gl2j40pMIM7-8I-t65tojV2xvsfqUE3Bszsx0=.bd28654a-b226-4a48-985b-a3d2187ba75d@github.com>
Message-ID: <lJVf1rHpm3sI_wrf42CryRH4J90MczjleF72Vv_W6aQ=.d901daab-1c20-41f7-beae-11296c29ba6c@github.com>

On Thu, 7 Apr 2022 15:09:27 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
>> 1) Frame which contains test instruction .
>> 2) Pass & Fail button so that user can mark the test pass or fail
>> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
>> 4) Disposing of all the frames.
>> 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284535 : Fix PrintLatinCJKTest.java test that is failing with Parse Exception

test/jdk/java/awt/print/PrinterJob/PrintLatinCJKTest.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 8022536

Why is [800535](https://bugs.openjdk.java.net/browse/JDK-8008535) removed? It's the bug this test is written for.

The additional bug [8022536](https://bugs.openjdk.java.net/browse/JDK-8022536) may cause NPE on Linux if a (default) remote printer is unavailable.

test/jdk/java/awt/print/PrinterJob/PrintLatinCJKTest.java line 52:

> 50:     private static String info = """
> 51:             To test 8022536, if a remote printer is the system default,
> 52:             it should show in the dialog as the selected printer.

Should these two lines be moved to the bottom of the instructions? This case is not the main test case of this test and it's also covered by another test `javax/print/TextFlavorTest.java`.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 58:

> 56:     private static final Timer timer = new Timer(0, null);
> 57: 
> 58:     public enum POSITION {HORIZONTAL, VERTICAL}

Suggestion:

    public enum Position {HORIZONTAL, VERTICAL}

The type shouldn't be all-capital, should it?

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 78:

> 76:      * @throws HeadlessException         HeadlessException
> 77:      * @throws InterruptedException      exception thrown for invokeAndWait
> 78:      * @throws InvocationTargetException exception thrown for invokeAndWait

I expected a more reasonable descriptions when any of the exceptions may be thrown. Anyway, it's unimportant. :)

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 102:

> 100:         instructionsText.setLineWrap(true);
> 101: 
> 102:         int testTimeout = (int) TimeUnit.MINUTES.toMillis(timeoutInMinutes);

Use `long`, it's safer and it's used everywhere when working with time.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 109:

> 107:         timer.setDelay(1000);
> 108:         timer.addActionListener((e) -> {
> 109:             int leftTime = testTimeout - (int) (System.currentTimeMillis() - startTime);

`long timeLeft` is better.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 113:

> 111:                 timer.stop();
> 112:                 testFailedReason = "Failure Reason:\n Timeout " +
> 113:                         "User did not perform testing.";

A suggestion: break string at the line break.
Suggestion:

                testFailedReason = "Failure Reason:\n"
                        + "Timeout - User did not perform testing.";

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 144:

> 142:                 super.windowClosing(e);
> 143:                 testFailedReason = "Failure Reason:\n User closed the " +
> 144:                         "instruction Frame";

Suggestion:

                testFailedReason = "Failure Reason:\n"
                        + "User closed the instruction frame";

I think it's easier to read this way, the parts of the phrase aren't broken.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 181:

> 179:         if (isEventDispatchThread()) {
> 180:             disposeFrames();
> 181:         } else invokeAndWait(PassFailJFrame::disposeFrames);

This is bad from Java Code Style point of view.

Additionally, you stated this method is not to be called on EDT, therefore you know `disposeFrames` should be called via `invokeAndWait`.

Shall this method throw an exception if it's called on EDT? It will prevent accidental mistakes.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 208:

> 206:      * example in the jtreg .jtr file.
> 207:      */
> 208:     public static void getFailureReason() {

It's not public actually.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 232:

> 230:                 super.windowClosing(e);
> 231:                 testFailedReason = "User closed the " +
> 232:                         "dialog";

I see no reason to break this string, it fits into 80-column.

Yet it's not an error: I'd rather leave the failure reason empty. In this case, the window listener can be dropped.

You can safely remove `super.windowClosing(e);`, the implementation in `WindowAdapter` does nothing.

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

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


From aivanov at openjdk.java.net  Mon Apr 11 16:20:58 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 11 Apr 2022 16:20:58 GMT
Subject: RFR: 8284535 : Fix PrintLatinCJKTest.java test that is failing
 with Parse Exception [v6]
In-Reply-To: <jRQUt_Gl2j40pMIM7-8I-t65tojV2xvsfqUE3Bszsx0=.bd28654a-b226-4a48-985b-a3d2187ba75d@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <jRQUt_Gl2j40pMIM7-8I-t65tojV2xvsfqUE3Bszsx0=.bd28654a-b226-4a48-985b-a3d2187ba75d@github.com>
Message-ID: <rE6WtGHt0v_JDVgYhFCf_TzLr7ipoWCsV404LbRWNCU=.59e19220-7d80-4df8-8ba6-e8a657e36f55@github.com>

On Thu, 7 Apr 2022 15:09:27 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
>> 1) Frame which contains test instruction .
>> 2) Pass & Fail button so that user can mark the test pass or fail
>> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
>> 4) Disposing of all the frames.
>> 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284535 : Fix PrintLatinCJKTest.java test that is failing with Parse Exception

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 52:

> 50:     private final static CountDownLatch latch = new CountDownLatch(1);
> 51:     private static volatile boolean failed = false;
> 52:     private static volatile boolean timeout = false;

`false` is the default value, so you can skip assigning `false`.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 198:

> 196:      * well as the frame that is added via addTestFrame(Frame frame)
> 197:      */
> 198:     private static void disposeFrames() {

It should be `synchronized` to prevent access to `frameList` from another thread while it's being iterated.

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

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


From dcubed at openjdk.java.net  Mon Apr 11 17:16:16 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 11 Apr 2022 17:16:16 GMT
Subject: RFR: 8284691: ProblemList
 javax/swing/JTable/8236907/LastVisibleRow.java on macosx
Message-ID: <AT9l0M4XqX1tV-3CigD397Wg5m0gDGsKMTXZ48kkZJA=.69440efb-5d29-47fe-92ba-f75fbcd4c8db@github.com>

A trivial fix to ProblemList javax/swing/JTable/8236907/LastVisibleRow.java on macosx.

This new bug was filed late Friday and already has 6 sightings.

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

Commit messages:
 - 8284691: ProblemList javax/swing/JTable/8236907/LastVisibleRow.java on macosx

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

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


From azvegint at openjdk.java.net  Mon Apr 11 17:22:41 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 11 Apr 2022 17:22:41 GMT
Subject: RFR: 8284691: ProblemList
 javax/swing/JTable/8236907/LastVisibleRow.java on macosx
In-Reply-To: <AT9l0M4XqX1tV-3CigD397Wg5m0gDGsKMTXZ48kkZJA=.69440efb-5d29-47fe-92ba-f75fbcd4c8db@github.com>
References: <AT9l0M4XqX1tV-3CigD397Wg5m0gDGsKMTXZ48kkZJA=.69440efb-5d29-47fe-92ba-f75fbcd4c8db@github.com>
Message-ID: <o3Mcgnz-ki7xgTWvOQnNPbpbJpjeINntw01iZN_kcRw=.84a5e99a-3f23-42da-92ca-4d4157754830@github.com>

On Mon, 11 Apr 2022 17:10:27 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JTable/8236907/LastVisibleRow.java on macosx.
> 
> This new bug was filed late Friday and already has 6 sightings.

Marked as reviewed by azvegint (Reviewer).

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

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


From rriggs at openjdk.java.net  Mon Apr 11 17:33:43 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 11 Apr 2022 17:33:43 GMT
Subject: RFR: 8284691: ProblemList
 javax/swing/JTable/8236907/LastVisibleRow.java on macosx
In-Reply-To: <AT9l0M4XqX1tV-3CigD397Wg5m0gDGsKMTXZ48kkZJA=.69440efb-5d29-47fe-92ba-f75fbcd4c8db@github.com>
References: <AT9l0M4XqX1tV-3CigD397Wg5m0gDGsKMTXZ48kkZJA=.69440efb-5d29-47fe-92ba-f75fbcd4c8db@github.com>
Message-ID: <y-wKye-smMa42zIASs_IhF4X671WHvom0mkLP45iypo=.4ccae2c7-c8ea-4c9a-a674-4ae53bd448eb@github.com>

On Mon, 11 Apr 2022 17:10:27 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JTable/8236907/LastVisibleRow.java on macosx.
> 
> This new bug was filed late Friday and already has 6 sightings.

Marked as reviewed by rriggs (Reviewer).

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

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


From duke at openjdk.java.net  Mon Apr 11 17:50:34 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Mon, 11 Apr 2022 17:50:34 GMT
Subject: RFR: 8284535 : Fix PrintLatinCJKTest.java test that is failing
 with Parse Exception [v7]
In-Reply-To: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
Message-ID: <Fu-Ztd6GtE0BBBMzxGUOBO_oIzwndWphaJDsWIdvjV4=.9d6dd2a8-ef28-499a-bdbc-b4bb2698c1ae@github.com>

> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
> 1) Frame which contains test instruction .
> 2) Pass & Fail button so that user can mark the test pass or fail
> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
> 4) Disposing of all the frames.
> 
> @aivanov-jdk

lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision:

 - Fixed jcheck issue
 - Fixed review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7966/files
  - new: https://git.openjdk.java.net/jdk/pull/7966/files/a10ac21b..1f6852e8

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

  Stats: 40 lines in 2 files changed: 5 ins; 12 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7966.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7966/head:pull/7966

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


From aivanov at openjdk.java.net  Mon Apr 11 18:01:46 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 11 Apr 2022 18:01:46 GMT
Subject: RFR: 8284535 : Fix PrintLatinCJKTest.java test that is failing
 with Parse Exception [v7]
In-Reply-To: <Fu-Ztd6GtE0BBBMzxGUOBO_oIzwndWphaJDsWIdvjV4=.9d6dd2a8-ef28-499a-bdbc-b4bb2698c1ae@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <Fu-Ztd6GtE0BBBMzxGUOBO_oIzwndWphaJDsWIdvjV4=.9d6dd2a8-ef28-499a-bdbc-b4bb2698c1ae@github.com>
Message-ID: <7tDDRAVTkMS3RuT-ckGxnFQosOwKB_khWpcQU0BRqsk=.0b343022-14c6-4cd4-93f1-86351e5398e5@github.com>

On Mon, 11 Apr 2022 17:50:34 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
>> 1) Frame which contains test instruction .
>> 2) Pass & Fail button so that user can mark the test pass or fail
>> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
>> 4) Disposing of all the frames.
>> 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed jcheck issue
>  - Fixed review comments

test/jdk/java/awt/print/PrinterJob/PrintLatinCJKTest.java line 55:

> 53:             the output to the printer, and examine it. It should have
> 54:             text looking like this : \u4e00\u4e01\u4e02\u4e03\u4e04English
> 55:             To test 8022536, if a remote printer is the system default,

Maybe a blank line will separate the two cases clearer.

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

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


From zgu at openjdk.java.net  Mon Apr 11 18:12:07 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 11 Apr 2022 18:12:07 GMT
Subject: RFR: 8284680: sun.font.FontConfigManager.getFontConfig() leaks charset
Message-ID: <MgzLHY7B6i7YyEzX8rkn-cEdkDamqKvNofwkrf1JIKI=.72ba1959-fe21-4f4e-a346-0feb5ae4037c@github.com>

Please review this small patch that releases temporary charsets to avoid memory leak.

Test:

- [x] jdk_2d

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

Commit messages:
 - v0

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

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


From duke at openjdk.java.net  Mon Apr 11 18:17:34 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Mon, 11 Apr 2022 18:17:34 GMT
Subject: RFR: 8284535 : Fix PrintLatinCJKTest.java test that is failing
 with Parse Exception [v8]
In-Reply-To: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
Message-ID: <0FlPbWDHC___agVYDwtV0diWiQRTw8KOIFwckJZLZ-Y=.8a596090-2dd0-45f1-a24d-933c4f6ecd4f@github.com>

> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
> 1) Frame which contains test instruction .
> 2) Pass & Fail button so that user can mark the test pass or fail
> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
> 4) Disposing of all the frames.
> 
> @aivanov-jdk

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

  Mark info as final

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7966/files
  - new: https://git.openjdk.java.net/jdk/pull/7966/files/1f6852e8..07735ce4

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

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

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


From aivanov at openjdk.java.net  Mon Apr 11 18:17:34 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 11 Apr 2022 18:17:34 GMT
Subject: RFR: 8284535 : Fix PrintLatinCJKTest.java test that is failing
 with Parse Exception [v7]
In-Reply-To: <Fu-Ztd6GtE0BBBMzxGUOBO_oIzwndWphaJDsWIdvjV4=.9d6dd2a8-ef28-499a-bdbc-b4bb2698c1ae@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <Fu-Ztd6GtE0BBBMzxGUOBO_oIzwndWphaJDsWIdvjV4=.9d6dd2a8-ef28-499a-bdbc-b4bb2698c1ae@github.com>
Message-ID: <l1a_dH-_XVcYYq2oZPlyCZe7O-vrsDW2F27G72W-3iY=.4ee79d25-d1a3-424e-88a4-e2c371609e2e@github.com>

On Mon, 11 Apr 2022 17:50:34 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
>> 1) Frame which contains test instruction .
>> 2) Pass & Fail button so that user can mark the test pass or fail
>> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
>> 4) Disposing of all the frames.
>> 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed jcheck issue
>  - Fixed review comments

Marked as reviewed by aivanov (Reviewer).

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

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


From aivanov at openjdk.java.net  Mon Apr 11 18:17:34 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 11 Apr 2022 18:17:34 GMT
Subject: RFR: 8284535 : Fix PrintLatinCJKTest.java test that is failing
 with Parse Exception [v8]
In-Reply-To: <0FlPbWDHC___agVYDwtV0diWiQRTw8KOIFwckJZLZ-Y=.8a596090-2dd0-45f1-a24d-933c4f6ecd4f@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <0FlPbWDHC___agVYDwtV0diWiQRTw8KOIFwckJZLZ-Y=.8a596090-2dd0-45f1-a24d-933c4f6ecd4f@github.com>
Message-ID: <ACoIUdNqGauGcfYLEqTcAy2FvgcTP1AJrKP4caPCSmk=.c2a63aa1-454c-4c5c-8c6c-1a35bef21fa5@github.com>

On Mon, 11 Apr 2022 18:13:57 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
>> 1) Frame which contains test instruction .
>> 2) Pass & Fail button so that user can mark the test pass or fail
>> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
>> 4) Disposing of all the frames.
>> 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mark info as final

Marked as reviewed by aivanov (Reviewer).

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

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


From aivanov at openjdk.java.net  Mon Apr 11 18:17:35 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 11 Apr 2022 18:17:35 GMT
Subject: RFR: 8284535 : Fix PrintLatinCJKTest.java test that is failing
 with Parse Exception [v7]
In-Reply-To: <7tDDRAVTkMS3RuT-ckGxnFQosOwKB_khWpcQU0BRqsk=.0b343022-14c6-4cd4-93f1-86351e5398e5@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <Fu-Ztd6GtE0BBBMzxGUOBO_oIzwndWphaJDsWIdvjV4=.9d6dd2a8-ef28-499a-bdbc-b4bb2698c1ae@github.com>
 <7tDDRAVTkMS3RuT-ckGxnFQosOwKB_khWpcQU0BRqsk=.0b343022-14c6-4cd4-93f1-86351e5398e5@github.com>
Message-ID: <-2osUj4MJg3pQ38I64L9LAlTEtnsx49SSKXpHQZQRRg=.75571155-d4d6-4e7f-bddb-7d32b36b2f3b@github.com>

On Mon, 11 Apr 2022 17:57:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fixed jcheck issue
>>  - Fixed review comments
>
> test/jdk/java/awt/print/PrinterJob/PrintLatinCJKTest.java line 55:
> 
>> 53:             the output to the printer, and examine it. It should have
>> 54:             text looking like this : \u4e00\u4e01\u4e02\u4e03\u4e04English
>> 55:             To test 8022536, if a remote printer is the system default,
> 
> Maybe a blank line will separate the two cases clearer.

Thanks!

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

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


From dcubed at openjdk.java.net  Mon Apr 11 18:58:43 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 11 Apr 2022 18:58:43 GMT
Subject: RFR: 8284691: ProblemList
 javax/swing/JTable/8236907/LastVisibleRow.java on macosx
In-Reply-To: <o3Mcgnz-ki7xgTWvOQnNPbpbJpjeINntw01iZN_kcRw=.84a5e99a-3f23-42da-92ca-4d4157754830@github.com>
References: <AT9l0M4XqX1tV-3CigD397Wg5m0gDGsKMTXZ48kkZJA=.69440efb-5d29-47fe-92ba-f75fbcd4c8db@github.com>
 <o3Mcgnz-ki7xgTWvOQnNPbpbJpjeINntw01iZN_kcRw=.84a5e99a-3f23-42da-92ca-4d4157754830@github.com>
Message-ID: <txoWSwaI1NWkHNeqjqFIsNPWWBmS16i16xpHSy-V4S4=.0a3d3ecc-3c06-4623-ac74-a31fdb8356d4@github.com>

On Mon, 11 Apr 2022 17:19:42 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> A trivial fix to ProblemList javax/swing/JTable/8236907/LastVisibleRow.java on macosx.
>> 
>> This new bug was filed late Friday and already has 6 sightings.
>
> Marked as reviewed by azvegint (Reviewer).

@azvegint and @RogerRiggs - Thanks for the reviews!

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

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


From dcubed at openjdk.java.net  Mon Apr 11 18:58:44 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 11 Apr 2022 18:58:44 GMT
Subject: Integrated: 8284691: ProblemList
 javax/swing/JTable/8236907/LastVisibleRow.java on macosx
In-Reply-To: <AT9l0M4XqX1tV-3CigD397Wg5m0gDGsKMTXZ48kkZJA=.69440efb-5d29-47fe-92ba-f75fbcd4c8db@github.com>
References: <AT9l0M4XqX1tV-3CigD397Wg5m0gDGsKMTXZ48kkZJA=.69440efb-5d29-47fe-92ba-f75fbcd4c8db@github.com>
Message-ID: <GJXJJmEl06iMnANCtX6iTIK_t_RS9q-u0MCSDkfFn2U=.94856396-30c0-4d2f-8473-13e8fb9b1aad@github.com>

On Mon, 11 Apr 2022 17:10:27 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JTable/8236907/LastVisibleRow.java on macosx.
> 
> This new bug was filed late Friday and already has 6 sightings.

This pull request has now been integrated.

Changeset: 929f5871
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/929f58714aca877f5b9d97db34a9c01ff7c7e45f
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8284691: ProblemList javax/swing/JTable/8236907/LastVisibleRow.java on macosx

Reviewed-by: azvegint, rriggs

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

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


From serb at openjdk.java.net  Mon Apr 11 22:24:12 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 11 Apr 2022 22:24:12 GMT
Subject: RFR: 8284699: Include all image types to the
 J2DBench.ColorConvertOpTests
Message-ID: <O-4c9xSYGjJFJRhpCFMdc6lgYhMV4fW0rdXTqOE7XS4=.51f30de9-4efa-4f86-818e-daa2663214ee@github.com>

The J2DBench.ColorConvertOp tests are used to track the performance of the littlecms library in the JDK. The new version of the littlecms will add support for the premultiplied alpha. But right now the J2DBench does not test the pre-alpha formats, so I have added all standard types we have.

FYI: I have tested all combinations of these flags w/o issues.

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

Commit messages:
 - Update ColorConvertOpTests.java
 - Initial version of JDK-8284699

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

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


From duke at openjdk.java.net  Mon Apr 11 22:49:40 2022
From: duke at openjdk.java.net (lukeu)
Date: Mon, 11 Apr 2022 22:49:40 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v8]
In-Reply-To: <oLAtmZ-nvXcaycSBywshKYbkuZimPBTKoD77xSauDQU=.2d6243ce-8651-428c-87ac-2a1ba82a7505@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oLAtmZ-nvXcaycSBywshKYbkuZimPBTKoD77xSauDQU=.2d6243ce-8651-428c-87ac-2a1ba82a7505@github.com>
Message-ID: <0g-tqs8KPJDkijGscIODMu5xLieQRH6sIJH13e7tWvA=.b0d9467d-3e93-4536-8c8d-f713e93f297b@github.com>

On Thu, 7 Apr 2022 20:24:29 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed 1.25 scaling overdraw, fixed calcs for right and bottom side borders

Printing, looks good. (Well, ignoring the missing checkboxes! I assume that's a separate thing.)
![JDK-8279614-patch4-printed-cropped](https://user-images.githubusercontent.com/2722420/162843419-6f84983b-71e3-4e53-ad99-5a1808456499.png)

You're going to hate me (I'm sorry!) but I spotted that at 225% and 350% scaling the bottom shadow line can sometime overhang by 1px. (Not that you can really spot it without zooming / looking specifically for it, mind you.)
![JDK-8279614-patch4-scaling_225-zoomed](https://user-images.githubusercontent.com/2722420/162843428-f8fb47f5-9056-4c10-bb16-2d5034fbd104.png)

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

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


From duke at openjdk.java.net  Tue Apr 12 00:13:13 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Tue, 12 Apr 2022 00:13:13 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v10]
In-Reply-To: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
Message-ID: <zrcAJ1FRO79VIefG1fPvmFWUMmIx5OPePnkGhD4A1Vg=.eadfec35-aee8-4bf4-a7e5-e63250f5ac34@github.com>

> Previously while tabbing through the JTable cell, the cell highlighter/focus ring was not visible against the selection background. 
> 
> Changes are made to Aqua LAF to derive a lighter focus ring color by changing saturation and setting brightness component to 100% of original focus ring color so that it is visible while tabbing through `JTable` cells. A new method is added for this purpose which takes in `focusRingColor`, does adjustment to saturation and brightness and returns a new focus ring color. There are edge cases where the HSB transformation does not yield the right focus ring color, for these cases a default color is returned.
> 
> **Edge Cases**
> ![image](https://user-images.githubusercontent.com/95945681/161360456-3929acf1-282b-4c2b-95d1-1d5707c1e238.png)
> 
> The edge case condition consists of two parts ?
> To handle white/black colors - (hsbValues[0] == 0 && hsbValues[1] == 0) - representing hue and saturation of zero obtained for black, white or exactly grey (red=green=color) conditions
> To handle grayish colors - hsbValues[1] <= satGrayScale where satGrayScale <= 0.10 . For any given hue and brightness, a saturation of less than or equal to 10% represents grayish tint colors.
> (The second case was added to accommodate grayish focus ring color returned by system when Accent color = Graphite.  The returned color is not exactly gray but grayish (r=135, g=135, b=140)). 
> To accommodate a more generic case of grayish colors, the satGrayScale has a threshold or buffer of 0.10 or 10%. 
> 
> Used the following resources to test out different grayish colors and optimal saturation offsets used in  `deriveLighterFocusRing()`.
> 
> - [RapidTables](https://www.rapidtables.com/convert/color/rgb-to-hsl.html) 
> - [Colorizer](http://colorizer.org/).
> - [Chart Link](https://codepen.io/HunorMarton/details/eWvewo)
> 
> A test case is added to compare the RGB difference between the original focus ring color & selection background and the new focus ring color & selection background.
> 
> PS: The native L&F (Mac OS) and Swing L&F for JTable cell tabbing differs (on native tables the cell background turns white on focus with a cell focus ring). Since the background for Swing tables can be set by users and also overridden by subclassing `DefaultTableCellRenderer`, and to adhere to current implementation of Swing, the white cell background changes are not incorporated. Only the Focus Ring/ Cell Highlighter is made more prominent.

Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:

 - Merge branch 'master' into focusRing_7124282
 - added new type property and changed method name
 - Merge branch 'master' into focusRing_7124282
 - added more generic condition for edge case and formatted line lengths
 - Merge branch 'openjdk:master' into focusRing_7124282
 - on-the-fly focus ring color changes added
 - updated deriveContrastFocusRing method
 - changed javadocs for the new method and expanded imports
 - formatting changes to test case
 - formatted line lengths, added method-level comments
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/df9f0c9c...c796a99d

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7768/files
  - new: https://git.openjdk.java.net/jdk/pull/7768/files/3e7afcdb..c796a99d

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

  Stats: 136076 lines in 1047 files changed: 98527 ins; 5221 del; 32328 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7768/head:pull/7768

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


From duke at openjdk.java.net  Tue Apr 12 00:22:31 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Tue, 12 Apr 2022 00:22:31 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v11]
In-Reply-To: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
Message-ID: <9T2LZvjkusyRd4JjbAU5_Yn277lAOnC02Esvq_R8yyg=.136fa8f8-0768-4774-8461-4591ca071453@github.com>

> Previously while tabbing through the JTable cell, the cell highlighter/focus ring was not visible against the selection background. 
> 
> Changes are made to Aqua LAF to derive a lighter focus ring color by changing saturation and setting brightness component to 100% of original focus ring color so that it is visible while tabbing through `JTable` cells. A new method is added for this purpose which takes in `focusRingColor`, does adjustment to saturation and brightness and returns a new focus ring color. There are edge cases where the HSB transformation does not yield the right focus ring color, for these cases a default color is returned.
> 
> **Edge Cases**
> ![image](https://user-images.githubusercontent.com/95945681/161360456-3929acf1-282b-4c2b-95d1-1d5707c1e238.png)
> 
> The edge case condition consists of two parts ?
> To handle white/black colors - (hsbValues[0] == 0 && hsbValues[1] == 0) - representing hue and saturation of zero obtained for black, white or exactly grey (red=green=color) conditions
> To handle grayish colors - hsbValues[1] <= satGrayScale where satGrayScale <= 0.10 . For any given hue and brightness, a saturation of less than or equal to 10% represents grayish tint colors.
> (The second case was added to accommodate grayish focus ring color returned by system when Accent color = Graphite.  The returned color is not exactly gray but grayish (r=135, g=135, b=140)). 
> To accommodate a more generic case of grayish colors, the satGrayScale has a threshold or buffer of 0.10 or 10%. 
> 
> Used the following resources to test out different grayish colors and optimal saturation offsets used in  `deriveLighterFocusRing()`.
> 
> - [RapidTables](https://www.rapidtables.com/convert/color/rgb-to-hsl.html) 
> - [Colorizer](http://colorizer.org/).
> - [Chart Link](https://codepen.io/HunorMarton/details/eWvewo)
> 
> A test case is added to compare the RGB difference between the original focus ring color & selection background and the new focus ring color & selection background.
> 
> PS: The native L&F (Mac OS) and Swing L&F for JTable cell tabbing differs (on native tables the cell background turns white on focus with a cell focus ring). Since the background for Swing tables can be set by users and also overridden by subclassing `DefaultTableCellRenderer`, and to adhere to current implementation of Swing, the white cell background changes are not incorporated. Only the Focus Ring/ Cell Highlighter is made more prominent.

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

  added new color to CSystemColors.m - CELL_HIGHLIGHT_COLOR

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7768/files
  - new: https://git.openjdk.java.net/jdk/pull/7768/files/c796a99d..d13e37f8

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

  Stats: 51 lines in 6 files changed: 15 ins; 0 del; 36 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7768/head:pull/7768

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


From duke at openjdk.java.net  Tue Apr 12 00:43:42 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Tue, 12 Apr 2022 00:43:42 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v8]
In-Reply-To: <Qa-HnVCda_3_Z38W4_XLpTg3Q37WDsXhiPSVl7D-AWA=.b6852efc-c828-47bb-ad88-0abead85509b@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <afJ29wQf2smgANBt5YTQC4oODoch8zxa0YqdtUZDfW8=.f4d0de4d-5245-4491-a8e8-05aaf2a4797a@github.com>
 <gzymK8AsH16kj6YIbJoMuRVGTDkKwLd_O3rbbDZCWIQ=.1f491527-2bac-4e6d-a5cc-f8443bf4f352@github.com>
 <MENhs6_2RTKjMOcWkh1CzumSIwQOy75T_wLac37Vkl8=.0da493e3-d91d-4b48-bd58-f69cefce3a9b@github.com>
 <wrQgwI3XG2G9_X8n5n4Q_AzDnMElxB92075XY3bkJMQ=.f5fb8350-489d-44a1-935a-e752b78347cd@github.com>
 <fR3AZPwa0kAz6SJDa5ns4eyyjCIAY_s25IlS2SL2xSw=.c8689931-ded8-448f-8caa-a17b47f7631a@github.com>
 <7ot0fBLQsvKiNsxLdrbnv4R_MNr6qdLN_GBwNPjU-rY=.dcad59a1-d0d6-42b9-bdf4-6290f31a88e0@github.com>
 <aKWrOQ_B3iWzXECCc6lUYE3ii6MOT3uBflVM4oSs7Ck=.07eb26cc-a502-494e-9dfc-b46b2d2dd6b5@github.com>
 <O0CcYkSID4VbXni4_hNoQKMK2TbCon7iW2IWgND1T4A=.3741a949-2397-4958-826d-bbef72e03031@github.com>
 <Qa-HnVCda_3_Z38W4_XLpTg3Q37WDsXhiPSVl7D-AWA=.b6852efc-c828-47bb-ad88-0abead85509b@github.com>
Message-ID: <CcEB04ZMfGKDlJIacXHoYX0mVIgmhKsSj314glVgYwU=.e1fc58f5-3d7e-46ab-afcc-718aa182fbd5@github.com>

On Mon, 11 Apr 2022 07:06:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> @prsadhuk Update PR with the recommended changes. The "controlAccentColor" changes works as expected in Mac 12.3 as well. 
>> One thing that I wanted to clarify with the fix is - the focus ring color ("Focus.ring") is used at two other places AquaButtonUI and AquaFocus (for focused icon). With the current fix I'm setting **KEYBOARD_FOCUS_COLOR** as below - 
>> 
>> <img width="1092" alt="image" src="https://user-images.githubusercontent.com/95945681/162673487-26006ca1-9373-4fe7-8f0b-f99cd47b2eb7.png">
>> 
>> Before and After images of focused icon -
>> 
>> **Before**
>> 
>> <img width="185" alt="image" src="https://user-images.githubusercontent.com/95945681/162674337-ebbfea9f-e753-4b4c-a624-7cef5b8d8c1b.png">
>> 
>> **After (focus around icon slightly darker - focus ring color obtained from controlAccentColor property)**
>> 
>> <img width="198" alt="image" src="https://user-images.githubusercontent.com/95945681/162674444-b917de71-8e91-472e-a8f0-da48df0a43a5.png">
>> 
>> Please let me know in case I need to add a NEW color (as shown below) instead of reusing the KEYBOARD_FOCUS_COLOR if the color effects on focused icon/ button doesn't look correct.
>> 
>> <img width="1099" alt="image" src="https://user-images.githubusercontent.com/95945681/162675955-efd9c77f-6d7b-41e7-803a-50f49154fba5.png">
>
> It seems KEYBOARD_FOCUS_COLOR via `focusRingColor` is also used for menuSelectedBackgroundColor which is used for 
> 
> CheckBoxMenuItem.selectionBackground
> ComboBox.selectionBackground
> Menu.selectionBackground
> MenuBar.selectionBackground
> MenuItem.selectionBackground
> "PopupMenu.selectionBackground", menuSelectedBackgroundColor,
> RadioButtonMenuItem.selectionBackground
> 
> which might also get affected if you use new property, so you need to test all those widgets if you intend to use reuse KEYBOARD_FOCUS_COLOR  so I guess safe bet is to use new color as you mentioned to limit the change to highlight color.

@prsadhuk Following code changes were pushed and ready for re-review

- New color added to CSystemColor.m - CELL_HIGHLIGHT_COLOR, to limit the effects of highlight color changes
- AquaImageFactory and LWCToolkit changed as part of addition of new color
- method renamed from deriveLighterFocusRing() to deriveProminentFocusRing()
- Test case made headful to load system colors

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

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


From serb at openjdk.java.net  Tue Apr 12 01:28:46 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Apr 2022 01:28:46 GMT
Subject: RFR: 8284535 : Fix PrintLatinCJKTest.java test that is failing
 with Parse Exception [v6]
In-Reply-To: <0tBOmlX8CMkaVB8l0nQcd_YKXtQSlAH_8S0_SNQQmUk=.01cb6513-7667-4baa-bf4d-27b20337bfa1@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <jRQUt_Gl2j40pMIM7-8I-t65tojV2xvsfqUE3Bszsx0=.bd28654a-b226-4a48-985b-a3d2187ba75d@github.com>
 <yl672byV2wQNNcC_01QVttbStT208RYNPpvBYJrBd9I=.ff8bba6d-a726-4bcd-96de-54c552f2489a@github.com>
 <0tBOmlX8CMkaVB8l0nQcd_YKXtQSlAH_8S0_SNQQmUk=.01cb6513-7667-4baa-bf4d-27b20337bfa1@github.com>
Message-ID: <LeKIE-V_GGp9es7qDFRhrk-f7yLMfOcBRChryqFsAjk=.4b1b03fc-badd-4455-bc6b-e639708ce979@github.com>

On Mon, 11 Apr 2022 12:19:28 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> An interesting idea. However, this would require updating all the existing tests including those that use its custom UI for run/manual.

Isn't this a goal of this fix:
>We need a common manual test framework code that can be shared across all the client manual test.
?

>A good idea. The instructions used to be shown in the same VM. And the majority of UI tests don't cause the VM to crash therefore the complexity of separating instructions from the test UI doesn't seem to provide much benefit

It means that the java options such as L&F selection/etc will affect the instruction.

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

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


From serb at openjdk.java.net  Tue Apr 12 01:29:53 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Apr 2022 01:29:53 GMT
Subject: RFR: JDK-8282778: Create a regression test for JDK-4699544 [v3]
In-Reply-To: <i_w9f3i_ZuPJCjoTOdQJwr0ImQ46n59CHiUi4GjJWHw=.15d13232-c70f-49a6-9315-d5bf1e902a9c@github.com>
References: <IDgBuK7aFq5DBF_2mWS-l27LMVG9XSZe-2Zl_bITg3M=.527d9ca4-e081-4ce2-b123-1f2580f5e017@github.com>
 <i_w9f3i_ZuPJCjoTOdQJwr0ImQ46n59CHiUi4GjJWHw=.15d13232-c70f-49a6-9315-d5bf1e902a9c@github.com>
Message-ID: <geAZt8w49mYYmMGkAXTQIB0iabZuFVP_6No0L8HMgfc=.1e284314-276d-4b82-b255-f5f1e4c3f12e@github.com>

On Wed, 30 Mar 2022 10:54:32 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a regression test for JDK-4699544
>> 
>> The subclass of javax.swing.JRootPane (AccessibleJRootPane) that implements the accessibility interface javax.accessibility.AccessibleComponent is derived from java.awt.AccessibleAWTComponent, which returns null for getAccessibleAt() because a component does not necessarily have childs.
>> 
>> The root pane always has a content pane child, so getAccessibleAt() should be overwritten by AccessibleJRootPane appropriately.
>> The test added verifies the same.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comments Fixed: Frame on EDT, Line length <= 80 characters

test/jdk/javax/accessibility/4699544/JRootPaneAccessiblAtTest.java line 39:

> 37: public class JRootPaneAccessiblAtTest extends JFrame {
> 38:     JRootPane rootPane;
> 39:     AccessibleComponent accessibleComponent;

Look like these fields became redundant.

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

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


From smandalika at openjdk.java.net  Tue Apr 12 01:34:43 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Tue, 12 Apr 2022 01:34:43 GMT
Subject: Integrated: 8282640: Create a test for JDK-4740761
In-Reply-To: <Rr2xSJSr1_1WFxavIZtwz_rlxf15Yvd5dCxZ_1dcggs=.7415074d-6beb-434e-b463-04388e50b0c8@github.com>
References: <Rr2xSJSr1_1WFxavIZtwz_rlxf15Yvd5dCxZ_1dcggs=.7415074d-6beb-434e-b463-04388e50b0c8@github.com>
Message-ID: <c__x2ihdRBV8DzLr4InU6-mzHvnN2vaBw5jI5xTgx6k=.4bae0076-ccbe-4afb-89a3-ae9c6f055c0a@github.com>

On Fri, 4 Mar 2022 05:35:38 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Create a test for [JDK-4740761](https://bugs.openjdk.java.net/browse/JDK-4740761)
> 
> The issue observed is in a JFrame with a JTextField and a JScrollPane which contains focused component. When the JScrollPane was
> is removed from its parent, focus stays with the the scroller
> of the removed JScrollPane, instead of moving to the TextField.
> 
> The test verifies the same - i.e. it verifies that the removal of the scrollpane moves the focus to the JTextField present in the JFrame.
> This review is for migrating tests from a closed test suite to open.

This pull request has now been integrated.

Changeset: fad3b947
Author:    Srinivas Mandalika <smandalika at openjdk.org>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fad3b9478663d319d1136422e6b4bea72a540544
Stats:     131 lines in 1 file changed: 131 ins; 0 del; 0 mod

8282640: Create a test for JDK-4740761

Reviewed-by: prr, serb

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

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


From prr at openjdk.java.net  Tue Apr 12 02:53:14 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 12 Apr 2022 02:53:14 GMT
Subject: RFR: 8284535 : Fix PrintLatinCJKTest.java test that is failing
 with Parse Exception [v6]
In-Reply-To: <0tBOmlX8CMkaVB8l0nQcd_YKXtQSlAH_8S0_SNQQmUk=.01cb6513-7667-4baa-bf4d-27b20337bfa1@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <jRQUt_Gl2j40pMIM7-8I-t65tojV2xvsfqUE3Bszsx0=.bd28654a-b226-4a48-985b-a3d2187ba75d@github.com>
 <yl672byV2wQNNcC_01QVttbStT208RYNPpvBYJrBd9I=.ff8bba6d-a726-4bcd-96de-54c552f2489a@github.com>
 <0tBOmlX8CMkaVB8l0nQcd_YKXtQSlAH_8S0_SNQQmUk=.01cb6513-7667-4baa-bf4d-27b20337bfa1@github.com>
Message-ID: <rqLMz-TDQvJI_PTPpkTDVPqIvDh_VcPXfek3NwapuC8=.0233d174-0c56-41b4-97ff-9e2934975ad5@github.com>

On Mon, 11 Apr 2022 12:19:28 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>Just an idea can we replace the builtin in the jtreg "manual" tests machinery by something like this?

It might be a nice project to update all of the rest of the tests but it'll be incremental and should start with tests we need to update anyway.

>> Also would like to raise a question: should we show the test instructions in the same VM where the test executed or we can shoiw it in a separate VM?

Separate VM would seem to introduce a lot of questions about how results are communicated and how you launch the target which file is really the @test ... if someone were to introduce  such a helper class along side the one here and let test developers choose which one they want for a while, we could perhaps see which approach works out better. But that would be an exercise outside of the scope of this proposal.

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

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


From psadhukhan at openjdk.java.net  Tue Apr 12 03:21:32 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 12 Apr 2022 03:21:32 GMT
Subject: RFR: 8282716: [macos] Enable
 javax/swing/JScrollPane/TestMouseWheelScroll.java on macos
In-Reply-To: <F0CzPHWEzAuSAyCUAiu3-JJ_Ue7SIyJWFzBwc70Zi6Q=.2734a6fa-2c72-4f5d-81df-32708a47edcd@github.com>
References: <-tuJ1M1iwo7tJ_hOHvrEylZmUdS3DPOSbySVFnJGrBI=.212c7ea6-e12a-48af-a4fa-ee3a586e4a38@github.com>
 <F0CzPHWEzAuSAyCUAiu3-JJ_Ue7SIyJWFzBwc70Zi6Q=.2734a6fa-2c72-4f5d-81df-32708a47edcd@github.com>
Message-ID: <49Qf2bhX-mIeQ2AofD8Iw1BWjRLxrJqUZEqcy-oK3pY=.4ebc0703-bd15-4843-a63d-852846524c0e@github.com>

On Sat, 9 Apr 2022 05:35:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The test was failing on macos and was excluded in macos because the viewposition was not changed after mouse wheel scroll. Seems like mouse wheel scroll direction is opposite in macos compared to windows etc so if we try to down-wheel scroll in macos when view position is at center of viewport (say element 3 is selected out of visible 7 elements), it cannot change viewposition as it cannot "scroll up" (since we are already at topmost viewport) whereas in windows, when we do down-wheel scroll in mouse wheel, it "scroll down" the viewport so viewposition is changed.
>> 
>> Fix is to use opposite scrolling motion in macos to check mouse wheel scroll is happening, which is what the testcase is meant for. CI testing of this test on all platform is ok.
>
> The scroll direction on macOS can be configured, can the test check what type of scroll is used on the current system and then use that to verify the old fix?

Any more comments @mrserb ?

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

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


From aghaisas at openjdk.java.net  Tue Apr 12 04:19:33 2022
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 12 Apr 2022 04:19:33 GMT
Subject: RFR: 8283794: CCE in XRTextRenderer.drawGlyphList and
 XRMaskFill.MaskFill [v2]
In-Reply-To: <VE3eRPzRlyCMFgLc0XrQrvy2pgqszE6ZC3TG7fcDvz8=.5facf5d5-668b-4190-acbc-bb481524d1ac@github.com>
References: <GD4NAkuLptwylcQOI8VBAXXI1rY7ycgz8O2NvPmhIOc=.f2c8334e-d2eb-4717-92a1-de2f9ed301b6@github.com>
 <VE3eRPzRlyCMFgLc0XrQrvy2pgqszE6ZC3TG7fcDvz8=.5facf5d5-668b-4190-acbc-bb481524d1ac@github.com>
Message-ID: <gw6R-Ys52b6soGAs2u7F6-7WiHOzduuG8jRQHs3xX90=.043d4630-576d-44e6-9fbf-b9b5e42aa8b6@github.com>

On Fri, 1 Apr 2022 15:43:29 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Throwing InvalidPipeException for incompatible surfaces
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8283794: CCE in XRTextRenderer.drawGlyphList and XRMaskFill.MaskFill
>   
>   Extracted try/catch logic of SurfaceData cast to particular SurfaceData subclass into convenience method SurfaceData.convertTo(). Applied the method to XRTextRenderer.drawGlyphList() and XRMaskFill.MaskFill(). Refactored try/catch blocks handling similar cases.

I am on vacation this week. I will review this PR on priority next week.

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

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


From serb at openjdk.java.net  Tue Apr 12 04:20:39 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Apr 2022 04:20:39 GMT
Subject: RFR: 8284646: Some swing test fail in macos12-aarch64 host
In-Reply-To: <MelCohsH9Jfezuli0QR2aWK6I78c5c09IT9aSWIWXys=.536ada73-ee97-4191-92d6-b29c73c4e956@github.com>
References: <MelCohsH9Jfezuli0QR2aWK6I78c5c09IT9aSWIWXys=.536ada73-ee97-4191-92d6-b29c73c4e956@github.com>
Message-ID: <nBQvcFR7c88thXalIxu-dkLGD7ypalBo8rOugkMsQiQ=.54191ed5-36be-467f-978f-7166b1e92d93@github.com>

On Mon, 11 Apr 2022 08:38:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Few tests  are seen to be failing in macos12 M1 system due to slight difference in color as mentioned in [JDK-8277816](https://bugs.openjdk.java.net/browse/JDK-8277816)
> 
> It seems the color difference was around 6-7 for swing tests, so these tests are extracted out in this issue and fixed by adding tolerance.
> I could not find, in M1 osx12.3 SystemPreferences, any way to set Color Profile to sRGB IEC61966-2.1 Profile so it seems osx12.x M1 use default setting.
> 
> Several runs in CI system in all platforms including 12.x M1 pass with this change (test job link in JBS)

Please double check that it is not possible to set the "sRGB IEC61966-2.1" color profile(probbaly you need to press some key to see an additional options, or there some user permission issue). I have macOS 12.3 and there is an option to set that profile, and if it is set all theses tests works fine.

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

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


From serb at openjdk.java.net  Tue Apr 12 04:21:41 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Apr 2022 04:21:41 GMT
Subject: RFR: 8282716: [macos] Enable
 javax/swing/JScrollPane/TestMouseWheelScroll.java on macos [v2]
In-Reply-To: <tc-YY_pb7eQtzEZW0RzMG5EPYtGJ2T0Yx71DtVojF5s=.de59bda4-9e66-47ee-a588-489c5ab4ecaa@github.com>
References: <-tuJ1M1iwo7tJ_hOHvrEylZmUdS3DPOSbySVFnJGrBI=.212c7ea6-e12a-48af-a4fa-ee3a586e4a38@github.com>
 <tc-YY_pb7eQtzEZW0RzMG5EPYtGJ2T0Yx71DtVojF5s=.de59bda4-9e66-47ee-a588-489c5ab4ecaa@github.com>
Message-ID: <E5Spd2wBIPJCywAdOzogOY0PVcn7hty_AoYtIrVexng=.5921be27-2346-4bb8-af8b-b22d0885c9a6@github.com>

On Sun, 10 Apr 2022 06:12:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The test was failing on macos and was excluded in macos because the viewposition was not changed after mouse wheel scroll. Seems like mouse wheel scroll direction is opposite in macos compared to windows etc so if we try to down-wheel scroll in macos when view position is at center of viewport (say element 3 is selected out of visible 7 elements), it cannot change viewposition as it cannot "scroll up" (since we are already at topmost viewport) whereas in windows, when we do down-wheel scroll in mouse wheel, it "scroll down" the viewport so viewposition is changed.
>> 
>> Fix is to use opposite scrolling motion in macos to check mouse wheel scroll is happening, which is what the testcase is meant for. CI testing of this test on all platform is ok.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check mousewheel rotation direction at runtime

Marked as reviewed by serb (Reviewer).

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

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


From psadhukhan at openjdk.java.net  Tue Apr 12 04:25:36 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 12 Apr 2022 04:25:36 GMT
Subject: RFR: 8284646: Some swing test fail in macos12-aarch64 host
In-Reply-To: <MelCohsH9Jfezuli0QR2aWK6I78c5c09IT9aSWIWXys=.536ada73-ee97-4191-92d6-b29c73c4e956@github.com>
References: <MelCohsH9Jfezuli0QR2aWK6I78c5c09IT9aSWIWXys=.536ada73-ee97-4191-92d6-b29c73c4e956@github.com>
Message-ID: <UEtcoEqt3KaOODAZqXaUEMuBejHNjHhU_6TDlMSKz68=.a20f97d4-4e14-4101-86d9-10556a3bfcb9@github.com>

On Mon, 11 Apr 2022 08:38:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Few tests  are seen to be failing in macos12 M1 system due to slight difference in color as mentioned in [JDK-8277816](https://bugs.openjdk.java.net/browse/JDK-8277816)
> 
> It seems the color difference was around 6-7 for swing tests, so these tests are extracted out in this issue and fixed by adding tolerance.
> I could not find, in M1 osx12.3 SystemPreferences, any way to set Color Profile to sRGB IEC61966-2.1 Profile so it seems osx12.x M1 use default setting.
> 
> Several runs in CI system in all platforms including 12.x M1 pass with this change (test job link in JBS)

I dont see in M1 osx12.3. Attached "DIsplay" where usually we have COlor tab where we used to set the profile
<img width="664" alt="Screenshot 2022-04-12 at 9 48 55 AM" src="https://user-images.githubusercontent.com/43534309/162879976-19ee9d74-e851-4f7b-b994-9d1583c2015b.png">

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

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


From smandalika at openjdk.java.net  Tue Apr 12 04:25:40 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Tue, 12 Apr 2022 04:25:40 GMT
Subject: Integrated: 8283245: Create a test for JDK-4670319
In-Reply-To: <UrqPfkc5gtakuM1_5bjMxwABKOHUxG5NwTkKpjpFvIk=.3957d27d-ddbe-4aad-aefe-0a3748aca560@github.com>
References: <UrqPfkc5gtakuM1_5bjMxwABKOHUxG5NwTkKpjpFvIk=.3957d27d-ddbe-4aad-aefe-0a3748aca560@github.com>
Message-ID: <hyJr5grrsVV5feZoXsqu-7LP3Ncb4G80oQsie4aU_zg=.f4413df5-04ce-4a60-a747-c7408aaa7509@github.com>

On Tue, 29 Mar 2022 08:04:42 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Write an automated regression test for  JDK-4670319
> 
> Issue
> When a JTree node is expanded or collapsed, an Accessibility PropertyChange event is fired with the old state of "collapsed" and new state of "expanded" (or vice versa). The problem is that the source of the event is the AccessibeJTree, and not the AccessibleJTreeNode. This means that an assistive technology listening to this event is unable to report to the user what node was expanded/collapsed.
> 
> Fix
> Fix for [JDK-4670319](https://bugs.openjdk.java.net/browse/JDK-4670319) addresses the above issue.  When tree node is expanded/collapsed, PropertyChangeEventSource is the Node.
> This review is for a test for validating the above issue.
> 
> This review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

This pull request has now been integrated.

Changeset: 4ce3cf12
Author:    Srinivas Mandalika <smandalika at openjdk.org>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4ce3cf12bff025441f658e1857e92486b5d73ee6
Stats:     115 lines in 1 file changed: 115 ins; 0 del; 0 mod

8283245: Create a test for JDK-4670319

Reviewed-by: serb

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

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


From smandalika at openjdk.java.net  Tue Apr 12 06:09:35 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Tue, 12 Apr 2022 06:09:35 GMT
Subject: RFR: 8284077: Create an automated test for JDK-4170173 [v2]
In-Reply-To: <8iul_waSMDD6G1oVVmwPtW89ihAc6YoMFrTR1-XFmmw=.7802104e-60cb-4b90-9ef5-cc479d3f5a78@github.com>
References: <8iul_waSMDD6G1oVVmwPtW89ihAc6YoMFrTR1-XFmmw=.7802104e-60cb-4b90-9ef5-cc479d3f5a78@github.com>
Message-ID: <Ae-7tZG1zyizB1FXzbtqkgOsw2gJ5Y0ShLNFHCUu4hE=.578127b3-ef9d-4936-8338-14bf12b28e59@github.com>

> Create an automated test for [JDK-4170173](https://bugs.openjdk.java.net/browse/JDK-4170173)
> 
> Issue
> JTextComponent.AccessibleJTextComponent.getAfterIndex(int part, int index) works incorrectly, when 'part' parameter is AccessibleText.WORD.
> It returns a space (" ") instead of the correct word.
> 
> The test verifies the fix for this behavior by checking the getAfterIndex for AccessibleText.CHARACTER,AccessibleText.WORD,AccessibleText.SENTENCE for the components JTextField, JTextArea, JEditorPane.
> 
> While working on this test case there was a related bug relevant to this [JDK-4170174](https://bugs.openjdk.java.net/browse/JDK-4170174) 
> This is marked as duplicate, addressess a similar issue.
> It indicates that JTextComponent.AccessibleJTextComponent.getBeforeIndex(int part, int index) works incorrectly, when part parameter is AccessibleText.WORD.
> It returns a space (" ") instead of correct word.
> 
> Hence an additional test was added for this, for verifying the behavior of getBeforeIndex.
> AccessibleText.CHARACTER,AccessibleText.WORD,AccessibleText.SENTENCE for the components JTextField, JTextArea, JEditorPane.
> 
> The two tests have multiple distinct assertions. For this reason, as well as for maintainability, the two were not clubbed into a single test.
> However, the two tests are still similar in the functional flow of the code and the functionality they are testing as well - hence they have been clubbed into a single review.
> This review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The tests ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

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

  Review Comments Fixed: Simplied test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8138/files
  - new: https://git.openjdk.java.net/jdk/pull/8138/files/0d7673fb..d4c97f68

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

  Stats: 159 lines in 2 files changed: 48 ins; 44 del; 67 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8138/head:pull/8138

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


From smandalika at openjdk.java.net  Tue Apr 12 06:14:40 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Tue, 12 Apr 2022 06:14:40 GMT
Subject: RFR: 8284077: Create an automated test for JDK-4170173 [v2]
In-Reply-To: <JdIu2uEh7kpBQgU4rxLI-_olZ9WVLawWmsDk3oio2Ng=.dfd5a7e7-f62f-49e4-9961-e3017e568435@github.com>
References: <8iul_waSMDD6G1oVVmwPtW89ihAc6YoMFrTR1-XFmmw=.7802104e-60cb-4b90-9ef5-cc479d3f5a78@github.com>
 <JdIu2uEh7kpBQgU4rxLI-_olZ9WVLawWmsDk3oio2Ng=.dfd5a7e7-f62f-49e4-9961-e3017e568435@github.com>
Message-ID: <SQkb3jfzUs8GAVbpDR65U6y1pTcPbeAAEk2c7KoG04o=.25be3baa-b54e-43a0-90cd-f1dd02400d98@github.com>

On Sat, 9 Apr 2022 05:32:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review Comments Fixed: Simplied test
>
> test/jdk/javax/accessibility/4170173/AccessibleJTextAfterIndexTest.java line 114:
> 
>> 112:             jTextComponent.getAccessibleContext().getAccessibleText()
>> 113:             .getAfterIndex(character, characterPosition));
>> 114: 
> 
> It feels that the code above is too smart=) Can we simplify/reformat it a little bit. I do not think that you need to jump from the main thread to the EDT and back for each testcase, just wrap the "doTest" by the invokeAndWait

This is a really good suggestion, thank you. I have simplified the test.

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

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


From psadhukhan at openjdk.java.net  Tue Apr 12 07:33:34 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 12 Apr 2022 07:33:34 GMT
Subject: Integrated: 8282716: [macos] Enable
 javax/swing/JScrollPane/TestMouseWheelScroll.java on macos
In-Reply-To: <-tuJ1M1iwo7tJ_hOHvrEylZmUdS3DPOSbySVFnJGrBI=.212c7ea6-e12a-48af-a4fa-ee3a586e4a38@github.com>
References: <-tuJ1M1iwo7tJ_hOHvrEylZmUdS3DPOSbySVFnJGrBI=.212c7ea6-e12a-48af-a4fa-ee3a586e4a38@github.com>
Message-ID: <0tQzvYQchFOqOJGtalWR7Pw57peOHnPz5A8rhDp4XUk=.efdc7e25-b193-4b8e-b318-c30b632da3c5@github.com>

On Wed, 6 Apr 2022 10:11:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The test was failing on macos and was excluded in macos because the viewposition was not changed after mouse wheel scroll. Seems like mouse wheel scroll direction is opposite in macos compared to windows etc so if we try to down-wheel scroll in macos when view position is at center of viewport (say element 3 is selected out of visible 7 elements), it cannot change viewposition as it cannot "scroll up" (since we are already at topmost viewport) whereas in windows, when we do down-wheel scroll in mouse wheel, it "scroll down" the viewport so viewposition is changed.
> 
> Fix is to use opposite scrolling motion in macos to check mouse wheel scroll is happening, which is what the testcase is meant for. CI testing of this test on all platform is ok.

This pull request has now been integrated.

Changeset: 9545ba7d
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9545ba7dd95eba78cf234b2cf63165afca513787
Stats:     14 lines in 1 file changed: 13 ins; 1 del; 0 mod

8282716: [macos] Enable javax/swing/JScrollPane/TestMouseWheelScroll.java on macos

Reviewed-by: serb

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

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


From avu at openjdk.java.net  Tue Apr 12 08:05:36 2022
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Tue, 12 Apr 2022 08:05:36 GMT
Subject: RFR: 8283794: CCE in XRTextRenderer.drawGlyphList and
 XRMaskFill.MaskFill [v2]
In-Reply-To: <gw6R-Ys52b6soGAs2u7F6-7WiHOzduuG8jRQHs3xX90=.043d4630-576d-44e6-9fbf-b9b5e42aa8b6@github.com>
References: <GD4NAkuLptwylcQOI8VBAXXI1rY7ycgz8O2NvPmhIOc=.f2c8334e-d2eb-4717-92a1-de2f9ed301b6@github.com>
 <VE3eRPzRlyCMFgLc0XrQrvy2pgqszE6ZC3TG7fcDvz8=.5facf5d5-668b-4190-acbc-bb481524d1ac@github.com>
 <gw6R-Ys52b6soGAs2u7F6-7WiHOzduuG8jRQHs3xX90=.043d4630-576d-44e6-9fbf-b9b5e42aa8b6@github.com>
Message-ID: <2pJSq0VxkgghzQ6KybO7uhmuZ7vIAarHJ08J6hkjMbA=.0cf673c1-242a-4654-850e-8c5a7ad4515b@github.com>

On Tue, 12 Apr 2022 04:15:56 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8283794: CCE in XRTextRenderer.drawGlyphList and XRMaskFill.MaskFill
>>   
>>   Extracted try/catch logic of SurfaceData cast to particular SurfaceData subclass into convenience method SurfaceData.convertTo(). Applied the method to XRTextRenderer.drawGlyphList() and XRMaskFill.MaskFill(). Refactored try/catch blocks handling similar cases.
>
> I am on vacation this week. I will review this PR on priority next week.

Thank you very much @aghaisas !

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

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


From psadhukhan at openjdk.java.net  Tue Apr 12 08:53:12 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 12 Apr 2022 08:53:12 GMT
Subject: RFR: 8196465: javax/swing/JComboBox/8182031/ComboPopupTest.java fails
 on Linux
Message-ID: <OK5XeO4MEz2o62f6Ls9QFZCt_HldwCdwDkhWdia4i88=.97497721-7567-4b7b-a514-0afec8353ce6@github.com>

Test was seen to be failing in linux CI system although passing locally.
Added waitForIdle(). 
Test is now passing in all CI systems including linux and mac. Several iterations of the test in CI run is ok (link in JBS)

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

Commit messages:
 - 8196465: javax/swing/JComboBox/8182031/ComboPopupTest.java fails on Linux

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

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


From smandalika at openjdk.java.net  Tue Apr 12 09:05:56 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Tue, 12 Apr 2022 09:05:56 GMT
Subject: RFR: JDK-8282778: Create a regression test for JDK-4699544 [v4]
In-Reply-To: <IDgBuK7aFq5DBF_2mWS-l27LMVG9XSZe-2Zl_bITg3M=.527d9ca4-e081-4ce2-b123-1f2580f5e017@github.com>
References: <IDgBuK7aFq5DBF_2mWS-l27LMVG9XSZe-2Zl_bITg3M=.527d9ca4-e081-4ce2-b123-1f2580f5e017@github.com>
Message-ID: <l1DQwU-SiN176RvD-bai-VoOdZNrM-66Kzo05YqXg3c=.f02b6d75-6024-402e-86d1-f77904fa90c5@github.com>

> Create a regression test for JDK-4699544
> 
> The subclass of javax.swing.JRootPane (AccessibleJRootPane) that implements the accessibility interface javax.accessibility.AccessibleComponent is derived from java.awt.AccessibleAWTComponent, which returns null for getAccessibleAt() because a component does not necessarily have childs.
> 
> The root pane always has a content pane child, so getAccessibleAt() should be overwritten by AccessibleJRootPane appropriately.
> The test added verifies the same.
> This review is for migrating tests from a closed test suite to open.

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

  Review Comments Fixed: removed redundant class variables

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7739/files
  - new: https://git.openjdk.java.net/jdk/pull/7739/files/bcc3bd6c..15bc3210

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

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

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


From smandalika at openjdk.java.net  Tue Apr 12 09:05:59 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Tue, 12 Apr 2022 09:05:59 GMT
Subject: RFR: JDK-8282778: Create a regression test for JDK-4699544 [v3]
In-Reply-To: <geAZt8w49mYYmMGkAXTQIB0iabZuFVP_6No0L8HMgfc=.1e284314-276d-4b82-b255-f5f1e4c3f12e@github.com>
References: <IDgBuK7aFq5DBF_2mWS-l27LMVG9XSZe-2Zl_bITg3M=.527d9ca4-e081-4ce2-b123-1f2580f5e017@github.com>
 <i_w9f3i_ZuPJCjoTOdQJwr0ImQ46n59CHiUi4GjJWHw=.15d13232-c70f-49a6-9315-d5bf1e902a9c@github.com>
 <geAZt8w49mYYmMGkAXTQIB0iabZuFVP_6No0L8HMgfc=.1e284314-276d-4b82-b255-f5f1e4c3f12e@github.com>
Message-ID: <ci8O1wItHsjM1EU5QlQsTaOlJk0O2oYjC17XI5LUwes=.50b71f8c-c3ca-4fdd-956d-41d1ccb184a1@github.com>

On Tue, 12 Apr 2022 01:26:15 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review Comments Fixed: Frame on EDT, Line length <= 80 characters
>
> test/jdk/javax/accessibility/4699544/JRootPaneAccessiblAtTest.java line 39:
> 
>> 37: public class JRootPaneAccessiblAtTest extends JFrame {
>> 38:     JRootPane rootPane;
>> 39:     AccessibleComponent accessibleComponent;
> 
> Look like these fields became redundant.

Fixed.

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

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


From smandalika at openjdk.java.net  Tue Apr 12 09:19:33 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Tue, 12 Apr 2022 09:19:33 GMT
Subject: RFR: 8284524: Create an automated test for JDK-4422362 [v2]
In-Reply-To: <Zc6TLIeUCxotLqICjVkZF4g1hUTkdB7mANhMull6Qzc=.14959182-424c-42f6-979f-7d6eeb266dfb@github.com>
References: <Zc6TLIeUCxotLqICjVkZF4g1hUTkdB7mANhMull6Qzc=.14959182-424c-42f6-979f-7d6eeb266dfb@github.com>
Message-ID: <WHzkHjbiB5VBQQILCYjGhTUlQ5r4cCdKLuhHIej_b8k=.38b70b08-9720-4768-8cb1-f1eee3bc59ea@github.com>

> Create an automated test for [JDK-4422362](https://bugs.openjdk.java.net/browse/JDK-4422362)
> 
> The BoundedRangeModel components (JScrollBar, JSlider, JProgressBar) return
> BoundedRangeModel.getMaximum() from getMaximumAccessibleValue() in their
> AccessibleValue implementation.
> The real maximum value (due to the constraints on BoundedRangeModel) is
> model.getMaximum() - model.getExtent().
> 
> The test verifies that the above is adhered to as expected.
> 
> This review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

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

  8284524: Create an automated test for JDK-4422362

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8158/files
  - new: https://git.openjdk.java.net/jdk/pull/8158/files/5cc47305..0dd792c1

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

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

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


From psadhukhan at openjdk.java.net  Tue Apr 12 12:34:53 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 12 Apr 2022 12:34:53 GMT
Subject: RFR: 8194946: Regression automated Test
 'javax/swing/JFileChooser/6738668/bug6738668.java' fails
Message-ID: <FiMrPev9bDTH-2FrgV7v7aT491L0-tMvqpJAlMt-wuM=.a3ebb1f4-991a-4ae7-b55d-706198d14eb8@github.com>

Test was failing in CI system in nightly testing.
Saw it failed with HeadlessException in macos-x64 and mascos-aarch64 and with GTKL&F not supported in linux-x64 in headless CI system.
Made the test headful and test now passes in all platforms (link in JBS)

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

Commit messages:
 - 8194946: Regression automated Test 'javax/swing/JFileChooser/6738668/bug6738668.java' fails

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

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


From azvegint at openjdk.java.net  Tue Apr 12 12:40:37 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 12 Apr 2022 12:40:37 GMT
Subject: RFR: 8196465: javax/swing/JComboBox/8182031/ComboPopupTest.java
 fails on Linux
In-Reply-To: <OK5XeO4MEz2o62f6Ls9QFZCt_HldwCdwDkhWdia4i88=.97497721-7567-4b7b-a514-0afec8353ce6@github.com>
References: <OK5XeO4MEz2o62f6Ls9QFZCt_HldwCdwDkhWdia4i88=.97497721-7567-4b7b-a514-0afec8353ce6@github.com>
Message-ID: <HhY80aLaB5617lUe-T9zZXqkrRFJ_jOpsIPa5vzJa4c=.12aae9e5-7160-4b15-b966-851b1a8f9ef3@github.com>

On Tue, 12 Apr 2022 08:46:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was seen to be failing in linux CI system although passing locally.
> Added waitForIdle(). 
> Test is now passing in all CI systems including linux and mac. Several iterations of the test in CI run is ok (link in JBS)

Marked as reviewed by azvegint (Reviewer).

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

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


From psadhukhan at openjdk.java.net  Tue Apr 12 13:12:41 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 12 Apr 2022 13:12:41 GMT
Subject: Integrated: 8196465: javax/swing/JComboBox/8182031/ComboPopupTest.java
 fails on Linux
In-Reply-To: <OK5XeO4MEz2o62f6Ls9QFZCt_HldwCdwDkhWdia4i88=.97497721-7567-4b7b-a514-0afec8353ce6@github.com>
References: <OK5XeO4MEz2o62f6Ls9QFZCt_HldwCdwDkhWdia4i88=.97497721-7567-4b7b-a514-0afec8353ce6@github.com>
Message-ID: <wuqgKwcfe--OS-bOSxmY-r94HfCpOAhd9YHU4Cvy2m4=.bfd07f0d-2bb9-4433-8014-d67bb0946ec9@github.com>

On Tue, 12 Apr 2022 08:46:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was seen to be failing in linux CI system although passing locally.
> Added waitForIdle(). 
> Test is now passing in all CI systems including linux and mac. Several iterations of the test in CI run is ok (link in JBS)

This pull request has now been integrated.

Changeset: 83466434
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/83466434fda3bd048fa8e2d274a797a7d9506c16
Stats:     29 lines in 2 files changed: 6 ins; 18 del; 5 mod

8196465: javax/swing/JComboBox/8182031/ComboPopupTest.java fails on Linux

Reviewed-by: azvegint

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

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


From psadhukhan at openjdk.java.net  Tue Apr 12 13:25:15 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 12 Apr 2022 13:25:15 GMT
Subject: RFR: 8194946: Regression automated Test
 'javax/swing/JFileChooser/6738668/bug6738668.java' fails [v2]
In-Reply-To: <FiMrPev9bDTH-2FrgV7v7aT491L0-tMvqpJAlMt-wuM=.a3ebb1f4-991a-4ae7-b55d-706198d14eb8@github.com>
References: <FiMrPev9bDTH-2FrgV7v7aT491L0-tMvqpJAlMt-wuM=.a3ebb1f4-991a-4ae7-b55d-706198d14eb8@github.com>
Message-ID: <UBZSXKBY_fDB5kxG4HH54xKSh7jCyF0ZPJhKBp2nbRc=.cf19788b-55f6-45fa-9766-c124ee7ddb54@github.com>

> Test was failing in CI system in nightly testing.
> Saw it failed with HeadlessException in macos-x64 and mascos-aarch64 and with GTKL&F not supported in linux-x64 in headless CI system.
> Made the test headful and test now passes in all platforms (link in JBS)

Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into JDK-8194946
 - 8194946: Regression automated Test 'javax/swing/JFileChooser/6738668/bug6738668.java' fails

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

Changes: https://git.openjdk.java.net/jdk/pull/8202/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8202&range=01
  Stats: 11 lines in 2 files changed: 9 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8202.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8202/head:pull/8202

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


From aivanov at openjdk.java.net  Tue Apr 12 13:52:46 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 12 Apr 2022 13:52:46 GMT
Subject: RFR: 8284535 : Fix PrintLatinCJKTest.java test that is failing
 with Parse Exception [v8]
In-Reply-To: <0FlPbWDHC___agVYDwtV0diWiQRTw8KOIFwckJZLZ-Y=.8a596090-2dd0-45f1-a24d-933c4f6ecd4f@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <0FlPbWDHC___agVYDwtV0diWiQRTw8KOIFwckJZLZ-Y=.8a596090-2dd0-45f1-a24d-933c4f6ecd4f@github.com>
Message-ID: <mTVjgfcO_bQYwQ6rfdaCO4md0vvqMPUFUj1DJZJFac8=.3b1893d3-a532-442c-9314-f45fced52058@github.com>

On Mon, 11 Apr 2022 18:17:34 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
>> 1) Frame which contains test instruction .
>> 2) Pass & Fail button so that user can mark the test pass or fail
>> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
>> 4) Disposing of all the frames.
>> 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mark info as final

> > An interesting idea. However, this would require updating all the existing tests including those that use its custom UI for run/manual.
> 
> Isn't this a goal of this fix:
> 
> > _We need a common manual test framework code that can be shared across all the client manual test._
> > ?

Doesn't this accomplish this goal?

No, it doesn't replace the (outdated) built-in machinery in jtreg for `manual=yesno`. At the same time, it provides a building block to update those tests.

I like this approach better, in which a test can be easily run without the need for jtreg, I think it greatly simplifies debugging and updating the test.

However, you're right that `applet/manual=yesno` in jtreg can be reimplemented using this new class `PassFailJFrame` even though it's not a goal at this very time. Initially I interpreted your suggestion as replacing all `manual` tests, which doesn't seem a right thing to do because it will break all existing manual tests.

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

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


From duke at openjdk.java.net  Tue Apr 12 13:52:47 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Tue, 12 Apr 2022 13:52:47 GMT
Subject: Integrated: 8284535 : Fix PrintLatinCJKTest.java test that is failing
 with Parse Exception
In-Reply-To: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
Message-ID: <PNfuTR9QtC3LivG2vhs5OmipiGKzQvqPCgyIC1ibpj8=.29ad9c77-9818-49d7-8839-7a78769cd5ee@github.com>

On Fri, 25 Mar 2022 21:06:12 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> We need a common manual test framework code that can be shared across all the client manual test. This framework class should have the following
> 1) Frame which contains test instruction .
> 2) Pass & Fail button so that user can mark the test pass or fail
> 3) Upon failing the test user should be able to elaborate why the test failed and this can be added to the test failure. 
> 4) Disposing of all the frames.
> 
> @aivanov-jdk

This pull request has now been integrated.

Changeset: 3f26d84f
Author:    lawrence.andrews <lawrence.andrews at oracle.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3f26d84f6a03030080328e36a1fd1a08c982838c
Stats:     362 lines in 2 files changed: 312 ins; 31 del; 19 mod

8284535: Fix PrintLatinCJKTest.java test that is failing with Parse Exception
8283712: Create a manual test framework class

Reviewed-by: prr, aivanov

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

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


From aivanov at openjdk.java.net  Tue Apr 12 15:37:40 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 12 Apr 2022 15:37:40 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v5]
In-Reply-To: <bFJoKiD6n9BimxrGVu8lNW-m3RswKRF_hGhfU905VMs=.94c9f727-2afc-4dde-ab57-f5737d9a034b@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <bFJoKiD6n9BimxrGVu8lNW-m3RswKRF_hGhfU905VMs=.94c9f727-2afc-4dde-ab57-f5737d9a034b@github.com>
Message-ID: <ABZjLEwhgG55rHvmZCcwc-4_AEG9j6czkIoTZ5ycVgQ=.c563202a-f9f6-49ab-8c09-e57713d2069c@github.com>

On Fri, 8 Apr 2022 12:17:37 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> getText function returned extra endOfLine when appended. The reason was in `EditorEditorKit` class, `write(Writer out, Document doc, int pos, int len)` method, where translation happens from buffer to Out(Writer Object) if endOfLine is other than '\n' ( which is '\r\n' in windows). In order to write each line till End of line, the string till '\n' is written including '\r' and again endOfLine is written which results in extra Carriage Return. To solve this issue, a Condition is added which checks if previous character to '\n' is '\r', if true then whole string except Carriage Return ('\r') is written, else whole string till before '\n' is written.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on Review Comments

The [`DefaultEditorKit`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/text/DefaultEditorKit.html) class defines handling of new lines: _??while the document is in memory, the "\n" character is used to define a newline??_.

[The comment inside its `read` method](https://github.com/openjdk/jdk/blob/096bca4a9c5e8ac2668dd965df92153ea1d80add/src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java#L212) explains `\r` is converted to `\n` upon reading.

As such, the behaviour described in [JDK-8180276](https://bugs.openjdk.java.net/browse/JDK-8180276) is not a bug. The mistake is that the user uses `System.lineSeparator()` to add a line break to the document model. Since it's the model, `\n` is to be used, which is _system-independent_. When document is written to disk, line breaks are converted to system-dependent according to the value of [`EndOfLineStringProperty`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/text/DefaultEditorKit.html#EndOfLineStringProperty) property of the document.

If we handle `\r` before `\n` when writing out a document, we may get another bug report where `\r` not followed by `\n` results in a line break too. This is why I consider the current behaviour correct. The questions by @prsadhuk and the resulted discussion have led me to this conclusion.

The bug should be closed as *Not an Issue* with the explanation that `\n` should always be used to add line break in a `Document` model, `System.lineSeparator()` should not be used.

Does it sound reasonable?

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

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


From duke at openjdk.java.net  Tue Apr 12 16:23:25 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Tue, 12 Apr 2022 16:23:25 GMT
Subject: RFR: 8283803 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/PrintGlyphVectorTest.java and fix test [v2]
In-Reply-To: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
Message-ID: <hWW6pTOxMZGNkyelxUO0Tavt6Sbkwvv2-bnwjA_zcsM=.199ceb3b-9e6f-4123-8757-fbcd7e25e055@github.com>

> Fixed the following issue.
> 1) Removed yes/no since test was failing due to "Parser error due to yesno in @run main/manual=yesno"
> 2) After removing yes/no test run( just shows the UI and gets dispose immediately). User cannot interact with the test UI and mark the test pass or failed. 
> So added Pass and Fail button to mark the test result.
> 3) Added timeout if in case user does not interact with the test UI.
> 
> @shurymury 
> @aivanov-jdk

lawrence.andrews has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8283803
 - 8283803 : Remove jtreg tag manual=yesno for java/awt/print/PrinterJob/PrintGlyphVectorTest.java and fix test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8004/files
  - new: https://git.openjdk.java.net/jdk/pull/8004/files/97ac125b..e4e53fc6

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

  Stats: 165232 lines in 2102 files changed: 116171 ins; 10863 del; 38198 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8004.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8004/head:pull/8004

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


From duke at openjdk.java.net  Tue Apr 12 17:42:31 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Tue, 12 Apr 2022 17:42:31 GMT
Subject: RFR: 8283803 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/PrintGlyphVectorTest.java and fix test [v3]
In-Reply-To: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
Message-ID: <R8_m3rVtQCxhPY9HKsD40XbzTW5o2nI5L7m4uKibUw8=.78d3d59c-8e35-45fa-90fb-d13213c84076@github.com>

> Fixed the following issue.
> 1) Removed yes/no since test was failing due to "Parser error due to yesno in @run main/manual=yesno"
> 2) After removing yes/no test run( just shows the UI and gets dispose immediately). User cannot interact with the test UI and mark the test pass or failed. 
> So added Pass and Fail button to mark the test result.
> 3) Added timeout if in case user does not interact with the test UI.
> 
> @shurymury 
> @aivanov-jdk

lawrence.andrews has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8283803
 - Merge branch 'openjdk:master' into JDK-8283803
 - 8283803 : Remove jtreg tag manual=yesno for java/awt/print/PrinterJob/PrintGlyphVectorTest.java and fix test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8004/files
  - new: https://git.openjdk.java.net/jdk/pull/8004/files/e4e53fc6..1c765353

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

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

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


From aturbanov at openjdk.java.net  Tue Apr 12 19:58:10 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 12 Apr 2022 19:58:10 GMT
Subject: RFR: 8284775: Simplify String.substring(_, length()) calls
Message-ID: <q6V07wyiK20KKrGGXQplBNLmYi6ymtjdM-tstKgtUw0=.b6f4aa78-06b7-400c-be32-dabb344f7d04@github.com>

Default `to` index for String.substring method call is length of the String.
We can simplify code a bit, by omitting default value.

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

Commit messages:
 - [PATCH] Unnecessary string length argument for String.substring in java.desktop
 - [PATCH] Unnecessary string length argument for String.substring in java.desktop

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

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


From duke at openjdk.java.net  Tue Apr 12 20:14:26 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Tue, 12 Apr 2022 20:14:26 GMT
Subject: RFR: 8283803 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/PrintGlyphVectorTest.java and fix test [v4]
In-Reply-To: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
Message-ID: <Q7SAjLPtEL78pdcd8CEVx1j44uxofLykXK_50Zos3Fo=.727a4ff2-8313-479a-9413-246e4337f5fe@github.com>

> Fixed the following issue.
> 1) Removed yes/no since test was failing due to "Parser error due to yesno in @run main/manual=yesno"
> 2) After removing yes/no test run( just shows the UI and gets dispose immediately). User cannot interact with the test UI and mark the test pass or failed. 
> So added Pass and Fail button to mark the test result.
> 3) Added timeout if in case user does not interact with the test UI.
> 
> @shurymury 
> @aivanov-jdk

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

  Fixed PrintGlyphVectorTest.java to use PassFailJFrame

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8004/files
  - new: https://git.openjdk.java.net/jdk/pull/8004/files/1c765353..9e4e95a4

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

  Stats: 110 lines in 1 file changed: 13 ins; 69 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8004.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8004/head:pull/8004

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


From bpb at openjdk.java.net  Tue Apr 12 20:24:55 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 12 Apr 2022 20:24:55 GMT
Subject: RFR: 8284775: Simplify String.substring(_, length()) calls
In-Reply-To: <q6V07wyiK20KKrGGXQplBNLmYi6ymtjdM-tstKgtUw0=.b6f4aa78-06b7-400c-be32-dabb344f7d04@github.com>
References: <q6V07wyiK20KKrGGXQplBNLmYi6ymtjdM-tstKgtUw0=.b6f4aa78-06b7-400c-be32-dabb344f7d04@github.com>
Message-ID: <RiBjEGpbpI1qp_I7AVCCg7-9axwOIR_dJH47uNfWlvQ=.00d8f7b2-44ec-4010-8043-fe6912a48ff9@github.com>

On Tue, 12 Apr 2022 19:38:33 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Default `to` index for String.substring method call is length of the String.
> We can simplify code a bit, by omitting default value.

Marked as reviewed by bpb (Reviewer).

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

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


From aivanov at openjdk.java.net  Tue Apr 12 20:29:39 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 12 Apr 2022 20:29:39 GMT
Subject: RFR: 8283803 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/PrintGlyphVectorTest.java and fix test [v4]
In-Reply-To: <Q7SAjLPtEL78pdcd8CEVx1j44uxofLykXK_50Zos3Fo=.727a4ff2-8313-479a-9413-246e4337f5fe@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
 <Q7SAjLPtEL78pdcd8CEVx1j44uxofLykXK_50Zos3Fo=.727a4ff2-8313-479a-9413-246e4337f5fe@github.com>
Message-ID: <TfrrtobpTc3sHDSPXSExhaNW4043DlPnctAwDEM72oM=.92aae4e1-3213-4301-86b7-e3f06a480fd1@github.com>

On Tue, 12 Apr 2022 20:14:26 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> Fixed the following issue.
>> 1) Removed yes/no since test was failing due to "Parser error due to yesno in @run main/manual=yesno"
>> 2) After removing yes/no test run( just shows the UI and gets dispose immediately). User cannot interact with the test UI and mark the test pass or failed. 
>> So added Pass and Fail button to mark the test result.
>> 3) Added timeout if in case user does not interact with the test UI.
>> 
>> @shurymury 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed PrintGlyphVectorTest.java to use PassFailJFrame

test/jdk/java/awt/print/PrinterJob/PrintGlyphVectorTest.java line 72:

> 70:         GlyphVector v = font.createGlyphVector(frc, testString);
> 71: 
> 72:         float x = 50f, y = 50f;

A better way would be:

float x = 50f;
float y = 50f;

Declaring the two variables on the same line is discouraged.

test/jdk/java/awt/print/PrinterJob/PrintGlyphVectorTest.java line 97:

> 95:     public void paint(Graphics g) {
> 96:         g.setColor(Color.white);
> 97:         g.fillRect(0,0,getSize().width, getSize().height);

Since you're updating the line any way, please add a space after commas.

test/jdk/java/awt/print/PrinterJob/PrintGlyphVectorTest.java line 128:

> 126:             if (pj == null || pj.getPrintService() == null ||
> 127:                     !pj.printDialog()) {
> 128:                 return;

Isn't it a failure?

test/jdk/java/awt/print/PrinterJob/PrintGlyphVectorTest.java line 132:

> 130:             pj.setPrintable(new PrintGlyphVectorTest());
> 131:             try {
> 132:                 pj.print();

Does it show Print dialog? Should the test fail if the user clicks Cancel there?

Any exception thrown should also fail the test, we expect no exceptions.

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

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


From aivanov at openjdk.java.net  Tue Apr 12 20:32:46 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 12 Apr 2022 20:32:46 GMT
Subject: RFR: 8194946: Regression automated Test
 'javax/swing/JFileChooser/6738668/bug6738668.java' fails [v2]
In-Reply-To: <UBZSXKBY_fDB5kxG4HH54xKSh7jCyF0ZPJhKBp2nbRc=.cf19788b-55f6-45fa-9766-c124ee7ddb54@github.com>
References: <FiMrPev9bDTH-2FrgV7v7aT491L0-tMvqpJAlMt-wuM=.a3ebb1f4-991a-4ae7-b55d-706198d14eb8@github.com>
 <UBZSXKBY_fDB5kxG4HH54xKSh7jCyF0ZPJhKBp2nbRc=.cf19788b-55f6-45fa-9766-c124ee7ddb54@github.com>
Message-ID: <2sepNi7UtvWxTzUszDkHPgKhFfGxQsjk_5n78HoFOHU=.cf6b762f-64c9-4158-aba2-a840fcc34a76@github.com>

On Tue, 12 Apr 2022 13:25:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test was failing in CI system in nightly testing.
>> Saw it failed with HeadlessException in macos-x64 and mascos-aarch64 and with GTKL&F not supported in linux-x64 in headless CI system.
>> Made the test headful and test now passes in all platforms (link in JBS)
>
> Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8194946
>  - 8194946: Regression automated Test 'javax/swing/JFileChooser/6738668/bug6738668.java' fails

Marked as reviewed by aivanov (Reviewer).

test/jdk/javax/swing/JFileChooser/6738668/bug6738668.java line 43:

> 41:                 UIManager.setLookAndFeel(lookAndFeelInfo.getClassName());
> 42:             } catch (UnsupportedLookAndFeelException ignored) {
> 43:                 System.out.println("Unsupported L&F: " + lookAndFeelInfo.getClassName());

Add `continue;` to skip?

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

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


From prr at openjdk.java.net  Tue Apr 12 20:53:16 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 12 Apr 2022 20:53:16 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v14]
In-Reply-To: <UU_cYUuzKhHCbxtgfgxpLdjG1jGNVtm-miTiMYN4Zb0=.87dd0163-a1ec-4d16-978e-7d583018107f@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <UU_cYUuzKhHCbxtgfgxpLdjG1jGNVtm-miTiMYN4Zb0=.87dd0163-a1ec-4d16-978e-7d583018107f@github.com>
Message-ID: <Yd3v0WSYfLgr2tltohRwmvIB56uyQMnF3G_0KG0_elY=.0db0e3ff-faec-4854-97af-fbde901ea789@github.com>

On Fri, 8 Apr 2022 08:51:30 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> Removed the println() line from the Interrupted catch block. Since waitForID() Interrupt indicates completion of Image Loading, println as Interrupt handling was not required.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on Review Comments

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.java.net  Tue Apr 12 20:53:20 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 12 Apr 2022 20:53:20 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v11]
In-Reply-To: <P9fn2Yk5EBPib8khH0LhSMty69hrUKy9jEf7fMSUmc4=.c2fce1f1-d2b6-4890-a408-9e14a00fd578@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <YEi-Ge2_proOlxBQ_qGD4b4u_17FGTmHgPhXAZ-OH14=.b92e4259-eeeb-4fbc-a105-8235572a9d78@github.com>
 <Q9Rzoht-EKO-lEy-xyFOEVkSLY42UclCWsh-31dZdwg=.e986a229-14ec-4f54-bf5c-07546b66dac7@github.com>
 <P9fn2Yk5EBPib8khH0LhSMty69hrUKy9jEf7fMSUmc4=.c2fce1f1-d2b6-4890-a408-9e14a00fd578@github.com>
Message-ID: <uoyejtJacFQhm9-q6ZedJEBVev1fBd0MTp70JcOHmNU=.594c6e43-71ba-4ad3-a3dc-a9afc860b037@github.com>

On Tue, 5 Apr 2022 17:30:31 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/ImageIcon/LoadInterruptTest.java line 74:
>> 
>>> 72: 
>>> 73:         Thread.currentThread().interrupt();
>>> 74:         ImageIcon i = new ImageIcon("https://openjdk.java.net/images/openjdk.png");
>> 
>> This is just asking for trouble. Test machines which can't access that URL might cause the test to behave differently than you expect.
>> Use some local image file loaded from a file: URL 
>> We have plenty you can choose from in other tests.
>
> This is intentional, it makes sure the image is in `LOADING` state to verify that the newly added resets it to `ABORTED`.
> 
> I don't expect the image to load, we don't care. If it succeeds, the status is `COMPLETE`; if it times outs or another error occurs, the status is `ERRORED`.

ok .. I trust this test has been verified in mach5 already ..

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

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


From serb at openjdk.java.net  Wed Apr 13 00:57:19 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 13 Apr 2022 00:57:19 GMT
Subject: RFR: 8284535 : Fix PrintLatinCJKTest.java test that is failing
 with Parse Exception [v8]
In-Reply-To: <mTVjgfcO_bQYwQ6rfdaCO4md0vvqMPUFUj1DJZJFac8=.3b1893d3-a532-442c-9314-f45fced52058@github.com>
References: <RauFnAVZjn_fp4jLmuUeBw15UlvHu_htmTtaEc1JUjk=.1103b76a-2419-4d10-9787-611447e6e49a@github.com>
 <0FlPbWDHC___agVYDwtV0diWiQRTw8KOIFwckJZLZ-Y=.8a596090-2dd0-45f1-a24d-933c4f6ecd4f@github.com>
 <mTVjgfcO_bQYwQ6rfdaCO4md0vvqMPUFUj1DJZJFac8=.3b1893d3-a532-442c-9314-f45fced52058@github.com>
Message-ID: <EhTLzr0lnSlvTfRKvA82wGro8Xmt33KVO1Mcvwg2_q0=.7eaf2a28-e8ed-4446-8273-179fc7fc241d@github.com>

On Tue, 12 Apr 2022 13:48:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I like this approach better, in which a test can be easily run without the need for jtreg, I think it greatly simplifies debugging and updating the test.

The new code depends on the PassFailJFrame from the library so it is not a simple test-in-one-file anyway. The jtreg could be just a wrapper that shows the instructions from the txt file and initialized/run the test via the main method, so the test will not have any external dependenies.  I just worry that we added one more library class and eventually will have one more way to write a manual test.

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

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


From serb at openjdk.java.net  Wed Apr 13 01:05:14 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 13 Apr 2022 01:05:14 GMT
Subject: RFR: 8284775: Simplify String.substring(_, length()) calls
In-Reply-To: <q6V07wyiK20KKrGGXQplBNLmYi6ymtjdM-tstKgtUw0=.b6f4aa78-06b7-400c-be32-dabb344f7d04@github.com>
References: <q6V07wyiK20KKrGGXQplBNLmYi6ymtjdM-tstKgtUw0=.b6f4aa78-06b7-400c-be32-dabb344f7d04@github.com>
Message-ID: <bq3z7hFoWm6fb20wDG3seUdIJqGhaO61CSaBKNaSgHg=.7c85e0b6-9a57-44ed-8417-e3d590c867c4@github.com>

On Tue, 12 Apr 2022 19:38:33 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Default `to` index for String.substring method call is length of the String.
> We can simplify code a bit, by omitting default value.

Marked as reviewed by serb (Reviewer).

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

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


From psadhukhan at openjdk.java.net  Wed Apr 13 07:57:38 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 13 Apr 2022 07:57:38 GMT
Subject: RFR: 8277816: Client tests fail on macos-Aarch64 host
Message-ID: <kLN8DjOu7ZQV4C1jt5pHr9axo4tmgigItGxa4IGuRrg=.21f625ef-b005-4f87-8abc-d9c3f51dc348@github.com>

This tests was failing on macos12 M1 systems due to wrong color profile configurations set in CI systems.
If correct sRGB IEC61966-2.1 is set, then these test passed. Test job link in JBS..

So, removing from Problem list..

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

Commit messages:
 - 8277816: Client tests fail on macos-Aarch64 host

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

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


From psadhukhan at openjdk.java.net  Wed Apr 13 08:56:53 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 13 Apr 2022 08:56:53 GMT
Subject: RFR: 8194946: Regression automated Test
 'javax/swing/JFileChooser/6738668/bug6738668.java' fails [v3]
In-Reply-To: <FiMrPev9bDTH-2FrgV7v7aT491L0-tMvqpJAlMt-wuM=.a3ebb1f4-991a-4ae7-b55d-706198d14eb8@github.com>
References: <FiMrPev9bDTH-2FrgV7v7aT491L0-tMvqpJAlMt-wuM=.a3ebb1f4-991a-4ae7-b55d-706198d14eb8@github.com>
Message-ID: <0hmR3bQDOs7CMrLN_UF1MLhcS3ZhCrDZqrOa0jhE3jI=.939302f5-c23b-4ff7-a3cb-21b19ccbb2be@github.com>

> Test was failing in CI system in nightly testing.
> Saw it failed with HeadlessException in macos-x64 and mascos-aarch64 and with GTKL&F not supported in linux-x64 in headless CI system.
> Made the test headful and test now passes in all platforms (link in JBS)

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

 - Merge branch 'JDK-8194946' of github.com:prsadhuk/jdk into JDK-8194946
 - Add continue

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8202/files
  - new: https://git.openjdk.java.net/jdk/pull/8202/files/9b60c728..bb99222b

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

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

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


From psadhukhan at openjdk.java.net  Wed Apr 13 08:56:56 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 13 Apr 2022 08:56:56 GMT
Subject: RFR: 8194946: Regression automated Test
 'javax/swing/JFileChooser/6738668/bug6738668.java' fails [v2]
In-Reply-To: <2sepNi7UtvWxTzUszDkHPgKhFfGxQsjk_5n78HoFOHU=.cf6b762f-64c9-4158-aba2-a840fcc34a76@github.com>
References: <FiMrPev9bDTH-2FrgV7v7aT491L0-tMvqpJAlMt-wuM=.a3ebb1f4-991a-4ae7-b55d-706198d14eb8@github.com>
 <UBZSXKBY_fDB5kxG4HH54xKSh7jCyF0ZPJhKBp2nbRc=.cf19788b-55f6-45fa-9766-c124ee7ddb54@github.com>
 <2sepNi7UtvWxTzUszDkHPgKhFfGxQsjk_5n78HoFOHU=.cf6b762f-64c9-4158-aba2-a840fcc34a76@github.com>
Message-ID: <e4nrzfvWBAIE2XV5LtBDL5PIThilfn8RwEDVNHa0ljs=.060635d1-d789-464f-9c7b-a3f01d64428a@github.com>

On Tue, 12 Apr 2022 20:28:43 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' into JDK-8194946
>>  - 8194946: Regression automated Test 'javax/swing/JFileChooser/6738668/bug6738668.java' fails
>
> test/jdk/javax/swing/JFileChooser/6738668/bug6738668.java line 43:
> 
>> 41:                 UIManager.setLookAndFeel(lookAndFeelInfo.getClassName());
>> 42:             } catch (UnsupportedLookAndFeelException ignored) {
>> 43:                 System.out.println("Unsupported L&F: " + lookAndFeelInfo.getClassName());
> 
> Add `continue;` to skip?

Yes, added...

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

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


From aivanov at openjdk.java.net  Wed Apr 13 09:54:13 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 13 Apr 2022 09:54:13 GMT
Subject: RFR: 8194946: Regression automated Test
 'javax/swing/JFileChooser/6738668/bug6738668.java' fails [v3]
In-Reply-To: <0hmR3bQDOs7CMrLN_UF1MLhcS3ZhCrDZqrOa0jhE3jI=.939302f5-c23b-4ff7-a3cb-21b19ccbb2be@github.com>
References: <FiMrPev9bDTH-2FrgV7v7aT491L0-tMvqpJAlMt-wuM=.a3ebb1f4-991a-4ae7-b55d-706198d14eb8@github.com>
 <0hmR3bQDOs7CMrLN_UF1MLhcS3ZhCrDZqrOa0jhE3jI=.939302f5-c23b-4ff7-a3cb-21b19ccbb2be@github.com>
Message-ID: <O7RnC661pzzixwwhmzqHSghPCc7cKx6qH0VwamtYcL4=.cd52e430-d5ff-446d-86e9-5c7e37bc035e@github.com>

On Wed, 13 Apr 2022 08:56:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test was failing in CI system in nightly testing.
>> Saw it failed with HeadlessException in macos-x64 and mascos-aarch64 and with GTKL&F not supported in linux-x64 in headless CI system.
>> Made the test headful and test now passes in all platforms (link in JBS)
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8194946' of github.com:prsadhuk/jdk into JDK-8194946
>  - Add continue

Marked as reviewed by aivanov (Reviewer).

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

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


From psadhukhan at openjdk.java.net  Wed Apr 13 11:01:16 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 13 Apr 2022 11:01:16 GMT
Subject: Integrated: 8194946: Regression automated Test
 'javax/swing/JFileChooser/6738668/bug6738668.java' fails
In-Reply-To: <FiMrPev9bDTH-2FrgV7v7aT491L0-tMvqpJAlMt-wuM=.a3ebb1f4-991a-4ae7-b55d-706198d14eb8@github.com>
References: <FiMrPev9bDTH-2FrgV7v7aT491L0-tMvqpJAlMt-wuM=.a3ebb1f4-991a-4ae7-b55d-706198d14eb8@github.com>
Message-ID: <-f_pJjXSuDedpCrLbeJUUa6qnLynG3EjG03pGPDlz5w=.5547fc42-cf58-4e3d-8dda-a010025c107e@github.com>

On Tue, 12 Apr 2022 12:27:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing in CI system in nightly testing.
> Saw it failed with HeadlessException in macos-x64 and mascos-aarch64 and with GTKL&F not supported in linux-x64 in headless CI system.
> Made the test headful and test now passes in all platforms (link in JBS)

This pull request has now been integrated.

Changeset: 70251b06
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/70251b064d0174cd902fc0179fbbd6e00c08c0e4
Stats:     12 lines in 2 files changed: 10 ins; 1 del; 1 mod

8194946: Regression automated Test 'javax/swing/JFileChooser/6738668/bug6738668.java' fails

Reviewed-by: aivanov

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

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


From smandalika at openjdk.java.net  Wed Apr 13 11:14:51 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 13 Apr 2022 11:14:51 GMT
Subject: RFR: 8284767: Create an automated test for JDK-4422535
Message-ID: <iWC939OdQdtwd4aHn2SafTsP1e1knRWsxNCzKos1Cts=.e7b80f3f-8fb2-41a1-af41-0e31131d756e@github.com>

Create an automated test for [JDK-4422535](https://bugs.openjdk.java.net/browse/JDK-4422535)
AccessibleValue implementation only accept Integers
The AccessibleValue implementations of the following components:

java.awt.Scrollbar
javax.swing.AbstractButton
javax.swing.JInternalFrame
javax.swing.JSplitPane
javax.swing.JScrollBar
javax.swing.JProgressBar
javax.swing.JSlider

require the argument to setCurrentAccessibleValue(Number) to be an Integer, else they completely ignore it - it returns a false indicating that the value has not been set by the return value, but they cannot know the reason for that).

The test verifies that for each of the above components, the AccessibleValue is set when it is set to a Number (Float, Double, long etc) and not just for an Integer.

his review is for migrating tests from a closed test suite to open.

Testing:
The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

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

Commit messages:
 - 8284767: Create an automated test for JDK-4422535
 - 8284767: Create an automated test for JDK-4422535

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

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


From azvegint at openjdk.java.net  Wed Apr 13 11:35:33 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 13 Apr 2022 11:35:33 GMT
Subject: RFR: 8159694: HiDPI, Unity,
 java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java
Message-ID: <Hx9FTEiBVH_hHXsOg78zPiBdHtfond1dqW5suSc3Egg=.dd76b22e-5045-4b2a-86c4-a0981f9401ba@github.com>

Window's title height was increased in Gnome/Unity since it was written, so the test tries to initiate drag on frame's header instead of its body. 
Making the frame undecorated solves the issue. 
Testing is green on all platforms.

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

Commit messages:
 - initial

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

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


From mvs at openjdk.java.net  Wed Apr 13 15:50:18 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 13 Apr 2022 15:50:18 GMT
Subject: RFR: 8284521: Write an automated regression test for RFE 4371575
 [v2]
In-Reply-To: <Fg5vKwm4MxPKYJfHGrLMPhWhkQ81VBc25cpCpwneXEA=.ac2b7e8e-1cdb-48d2-a171-112d7bec6fc0@github.com>
References: <FgW8JkNC98cWCRNm8Tpsu75-EYCzO2wP4X-sM9rDkZs=.f66039d3-903b-42b3-b2f4-3af624d6fd4b@github.com>
 <Qv2iYnccQRtvScBKqUy6djNmBu0x2Ldpqg3AgVc3W8E=.0b8277a2-6447-4943-867d-f606358ad598@github.com>
 <Fg5vKwm4MxPKYJfHGrLMPhWhkQ81VBc25cpCpwneXEA=.ac2b7e8e-1cdb-48d2-a171-112d7bec6fc0@github.com>
Message-ID: <_T-d7GvItcowh91b5_cqgiMPiqLQQlNmBIB_PN34sRI=.c5e9a555-a8e7-4d08-8a27-ef0180594b95@github.com>

On Sat, 9 Apr 2022 05:27:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment fixed: Removed unwanted directory
>
> Marked as reviewed by serb (Reviewer).

@mrserb Can you sponsor this PR?

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

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


From prr at openjdk.java.net  Wed Apr 13 17:15:35 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 13 Apr 2022 17:15:35 GMT
Subject: RFR: 8223543: [TESTBUG] Regression test
 java/awt/Graphics2D/DrawString/LCDTextSrcEa.java has issues
Message-ID: <QnP4PRehvVtNAyZirj5Q2Zyo9-9P_PxOkp4xHKw80n0=.6e9f4bc4-da65-4223-8c67-12f1ba05d5fd@github.com>

This test had problem described in the bug report, and most of it was related to being headful.
But actually the test didn't need to be headful - it did the actual rendering it wanted to test to
a software BufferedImage. So make it headless.
Also only Windows always supports LCD text, so run the test there and not Linux or Mac.

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

Commit messages:
 - 8223543

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

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


From duke at openjdk.java.net  Wed Apr 13 18:19:52 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Wed, 13 Apr 2022 18:19:52 GMT
Subject: RFR: 8283803 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/PrintGlyphVectorTest.java and fix test [v5]
In-Reply-To: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
Message-ID: <qp24O1FuBZpkLfLyTJGcBVUo5lq0zv3FXtQJHVpG_V8=.f08d4e45-9586-4363-8d14-463347939874@github.com>

> Fixed the following issue.
> 1) Removed yes/no since test was failing due to "Parser error due to yesno in @run main/manual=yesno"
> 2) After removing yes/no test run( just shows the UI and gets dispose immediately). User cannot interact with the test UI and mark the test pass or failed. 
> So added Pass and Fail button to mark the test result.
> 3) Added timeout if in case user does not interact with the test UI.
> 
> @shurymury 
> @aivanov-jdk

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

  Handled printer not available case

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8004/files
  - new: https://git.openjdk.java.net/jdk/pull/8004/files/9e4e95a4..4a5d327d

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

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

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


From aturbanov at openjdk.java.net  Wed Apr 13 19:12:16 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Wed, 13 Apr 2022 19:12:16 GMT
Subject: Integrated: 8284775: Simplify String.substring(_, length()) calls
In-Reply-To: <q6V07wyiK20KKrGGXQplBNLmYi6ymtjdM-tstKgtUw0=.b6f4aa78-06b7-400c-be32-dabb344f7d04@github.com>
References: <q6V07wyiK20KKrGGXQplBNLmYi6ymtjdM-tstKgtUw0=.b6f4aa78-06b7-400c-be32-dabb344f7d04@github.com>
Message-ID: <pJtFBREeFwvBg3Nl-UZCqBC3nMa5RceXAwxqBkpnsg8=.4f60b19a-c036-43ba-82e7-213a3ebc6a8b@github.com>

On Tue, 12 Apr 2022 19:38:33 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Default `to` index for String.substring method call is length of the String.
> We can simplify code a bit, by omitting default value.

This pull request has now been integrated.

Changeset: bf1c3ef0
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bf1c3ef02b22a615101530642d245fef899d33b7
Stats:     19 lines in 6 files changed: 0 ins; 5 del; 14 mod

8284775: Simplify String.substring(_, length()) calls

Reviewed-by: bpb, serb

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

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


From aturbanov at openjdk.java.net  Wed Apr 13 20:45:35 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Wed, 13 Apr 2022 20:45:35 GMT
Subject: RFR: 8284853: Fix varios 'expected' typo
Message-ID: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>

Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc.

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

Commit messages:
 - [PATCH] Fix 'expected' typo
 - [PATCH] Fix 'expected' typo
 - [PATCH] Fix 'expected' typo

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

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


From azvegint at openjdk.java.net  Wed Apr 13 21:02:26 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 13 Apr 2022 21:02:26 GMT
Subject: RFR: 6626492: Event time in future part 2, now on X
Message-ID: <SKEoIjhvEJL5ZVgxyfrZpUotPcOjtxm2fNB-tR1P4OQ=.f742f921-371c-434c-8c54-b7ab1d799c40@github.com>

This fix simply remove the test from ProblemList, since the issue is no longer reproducible.

Multiple CI test runs are green.

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

Commit messages:
 - initial

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

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


From azvegint at openjdk.java.net  Wed Apr 13 21:35:52 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 13 Apr 2022 21:35:52 GMT
Subject: RFR: 8144030: [macosx] test
 java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails (again)
Message-ID: <Am6BMN4aKMiXkE2cJtjuHsjs_IEa2mC9HIZ8kb61kQ0=.52271f3c-9e74-425a-9bdd-b0f09ae63338@github.com>

This test has two undecorated frames: 

1. background, 300x300
2. shaped foreground, 200x200

After displaying this frames it tries to check color outside of shape but within frame 2 bounds.

Unfortunately, on Linux and macOS there is a shadow around the shaped frame:
![image](https://user-images.githubusercontent.com/77687766/163270586-8dd97e93-582f-481f-999d-f08d4aaafba1.png)
(changed color to green to make it more noticeable).

One way to fix the test would be to add tolerance to color check.
But with old check points blue color may vary in 222-255 range, which is a bit too much.

Instead of this I made this shaped window  the size of background window. 
This allows us to move check points away from shape border and its shadow, but still be able to check whether shape is applied or not.

Testing is green on all platforms.

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

Commit messages:
 - initial

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

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


From azvegint at openjdk.java.net  Wed Apr 13 21:35:52 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 13 Apr 2022 21:35:52 GMT
Subject: RFR: 8144030: [macosx] test
 java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails (again)
In-Reply-To: <Am6BMN4aKMiXkE2cJtjuHsjs_IEa2mC9HIZ8kb61kQ0=.52271f3c-9e74-425a-9bdd-b0f09ae63338@github.com>
References: <Am6BMN4aKMiXkE2cJtjuHsjs_IEa2mC9HIZ8kb61kQ0=.52271f3c-9e74-425a-9bdd-b0f09ae63338@github.com>
Message-ID: <NLmuPi2x4ZyoIhSeU4U4zs9aGmFHqWVrcCpcg-qSPIU=.4f6512fb-9398-43a6-9524-f2fa46eb92e6@github.com>

On Wed, 13 Apr 2022 21:28:35 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This test has two undecorated frames: 
> 
> 1. background, 300x300
> 2. shaped foreground, 200x200
> 
> After displaying this frames it tries to check color outside of shape but within frame 2 bounds.
> 
> Unfortunately, on Linux and macOS there is a shadow around the shaped frame:
> ![image](https://user-images.githubusercontent.com/77687766/163270586-8dd97e93-582f-481f-999d-f08d4aaafba1.png)
> (changed color to green to make it more noticeable).
> 
> One way to fix the test would be to add tolerance to color check.
> But with old check points blue color may vary in 222-255 range, which is a bit too much.
> 
> Instead of this I made this shaped window  the size of background window. 
> This allows us to move check points away from shape border and its shadow, but still be able to check whether shape is applied or not.
> 
> Testing is green on all platforms.

test/jdk/java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java line 144:

> 142:                         point.y,
> 143:                         BACKGROUND_COLOR
> 144:                 );

Dunno why the old version was not checking inner points, but I've added one just to check if the shaped frame is above background one.

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

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


From serb at openjdk.java.net  Wed Apr 13 21:50:17 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 13 Apr 2022 21:50:17 GMT
Subject: RFR: 8144030: [macosx] test
 java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails (again)
In-Reply-To: <NLmuPi2x4ZyoIhSeU4U4zs9aGmFHqWVrcCpcg-qSPIU=.4f6512fb-9398-43a6-9524-f2fa46eb92e6@github.com>
References: <Am6BMN4aKMiXkE2cJtjuHsjs_IEa2mC9HIZ8kb61kQ0=.52271f3c-9e74-425a-9bdd-b0f09ae63338@github.com>
 <NLmuPi2x4ZyoIhSeU4U4zs9aGmFHqWVrcCpcg-qSPIU=.4f6512fb-9398-43a6-9524-f2fa46eb92e6@github.com>
Message-ID: <M6DJlJBmfFJNdqqSuO4-Nmg0PI1o5rT4ydZ3WOFEmaw=.df1d020f-4712-4193-9bfa-b20ce350fc68@github.com>

On Wed, 13 Apr 2022 21:30:06 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This test has two undecorated frames: 
>> 
>> 1. background, 300x300
>> 2. shaped foreground, 200x200
>> 
>> After displaying this frames it tries to check color outside of shape but within frame 2 bounds.
>> 
>> Unfortunately, on Linux and macOS there is a shadow around the shaped frame:
>> ![image](https://user-images.githubusercontent.com/77687766/163270586-8dd97e93-582f-481f-999d-f08d4aaafba1.png)
>> (changed color to green to make it more noticeable).
>> 
>> One way to fix the test would be to add tolerance to color check.
>> But with old check points blue color may vary in 222-255 range, which is a bit too much.
>> 
>> Instead of this I made this shaped window  the size of background window. 
>> This allows us to move check points away from shape border and its shadow, but still be able to check whether shape is applied or not.
>> 
>> Testing is green on all platforms.
>
> test/jdk/java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java line 144:
> 
>> 142:                         point.y,
>> 143:                         BACKGROUND_COLOR
>> 144:                 );
> 
> Dunno why the old version was not checking inner points, but I've added one just to check if the shaped frame is above background one.

Don't we need to check the places where the shadow is rendered that it is not the shape color(to prove that the shape is not simple rectangular)?

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

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


From serb at openjdk.java.net  Wed Apr 13 21:52:23 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 13 Apr 2022 21:52:23 GMT
Subject: RFR: 6626492: Event time in future part 2, now on X
In-Reply-To: <SKEoIjhvEJL5ZVgxyfrZpUotPcOjtxm2fNB-tR1P4OQ=.f742f921-371c-434c-8c54-b7ab1d799c40@github.com>
References: <SKEoIjhvEJL5ZVgxyfrZpUotPcOjtxm2fNB-tR1P4OQ=.f742f921-371c-434c-8c54-b7ab1d799c40@github.com>
Message-ID: <7-ruwhmyTmzmEw6AG_svq2pyebBu-gvMQW4G2hCu7gI=.3b8617c4-80b8-4a01-abc5-d1113e980702@github.com>

On Wed, 13 Apr 2022 20:51:41 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This fix simply remove the test from ProblemList, since the issue is no longer reproducible.
> 
> Multiple CI test runs are green.

Looks fine, I think it was fixed as part of JDK-7194219

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

Marked as reviewed by serb (Reviewer).

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


From serb at openjdk.java.net  Wed Apr 13 21:54:16 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 13 Apr 2022 21:54:16 GMT
Subject: RFR: 8223543: [TESTBUG] Regression test
 java/awt/Graphics2D/DrawString/LCDTextSrcEa.java has issues
In-Reply-To: <QnP4PRehvVtNAyZirj5Q2Zyo9-9P_PxOkp4xHKw80n0=.6e9f4bc4-da65-4223-8c67-12f1ba05d5fd@github.com>
References: <QnP4PRehvVtNAyZirj5Q2Zyo9-9P_PxOkp4xHKw80n0=.6e9f4bc4-da65-4223-8c67-12f1ba05d5fd@github.com>
Message-ID: <oH8B4gkWDO1b7xdIdRrR8M0o_p52mmnC22_cdx97khc=.6be9d29d-58d6-46bd-b64a-f7d87489641d@github.com>

On Wed, 13 Apr 2022 17:08:51 GMT, Phil Race <prr at openjdk.org> wrote:

> This test had problem described in the bug report, and most of it was related to being headful.
> But actually the test didn't need to be headful - it did the actual rendering it wanted to test to
> a software BufferedImage. So make it headless.
> Also only Windows always supports LCD text, so run the test there and not Linux or Mac.

Are there any differences in rendering LCD to the buffered image or to the volatile image?

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

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


From serb at openjdk.java.net  Wed Apr 13 21:55:13 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 13 Apr 2022 21:55:13 GMT
Subject: RFR: 8159694: HiDPI, Unity,
 java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java
In-Reply-To: <Hx9FTEiBVH_hHXsOg78zPiBdHtfond1dqW5suSc3Egg=.dd76b22e-5045-4b2a-86c4-a0981f9401ba@github.com>
References: <Hx9FTEiBVH_hHXsOg78zPiBdHtfond1dqW5suSc3Egg=.dd76b22e-5045-4b2a-86c4-a0981f9401ba@github.com>
Message-ID: <hKktdFNy0eDMSYTqnpMVMQJGQATopJNPtRgtzyRSr0U=.edb9dd5b-91e3-4887-abfd-d104db97de1a@github.com>

On Wed, 13 Apr 2022 11:27:44 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Window's title height was increased in Gnome/Unity since it was written, so the test tries to initiate drag on frame's header instead of its body. 
> Making the frame undecorated solves the issue. 
> Testing is green on all platforms.

Marked as reviewed by serb (Reviewer).

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

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


From prr at openjdk.java.net  Wed Apr 13 22:01:16 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 13 Apr 2022 22:01:16 GMT
Subject: RFR: 8223543: [TESTBUG] Regression test
 java/awt/Graphics2D/DrawString/LCDTextSrcEa.java has issues
In-Reply-To: <oH8B4gkWDO1b7xdIdRrR8M0o_p52mmnC22_cdx97khc=.6be9d29d-58d6-46bd-b64a-f7d87489641d@github.com>
References: <QnP4PRehvVtNAyZirj5Q2Zyo9-9P_PxOkp4xHKw80n0=.6e9f4bc4-da65-4223-8c67-12f1ba05d5fd@github.com>
 <oH8B4gkWDO1b7xdIdRrR8M0o_p52mmnC22_cdx97khc=.6be9d29d-58d6-46bd-b64a-f7d87489641d@github.com>
Message-ID: <fSKYMmr0pqWcm4cqWt4_SNd0_WaOSyzSjrgEgJ7ah80=.3f029992-8d20-4060-b1e7-93ac052220d2@github.com>

On Wed, 13 Apr 2022 21:50:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Are there any differences in rendering LCD to the buffered image or to the volatile image?

There shouldn't be since it is the same code (loops) in both cases. We have to read back from a volatile image to get a s/w surface for LCD text - which is part of why LCD text can be slower than greyscale on some graphics cards where that read back is slow.

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

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


From bpb at openjdk.java.net  Wed Apr 13 22:15:15 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 13 Apr 2022 22:15:15 GMT
Subject: RFR: 8284853: Fix varios 'expected' typo
In-Reply-To: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
Message-ID: <bqVpACr36Y57HyfkdPhkky31heyeGtVmHiuq7sImIdU=.bafb68b4-23f1-483e-a1ae-3852d9852c7f@github.com>

On Wed, 13 Apr 2022 20:36:48 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc.

Expect the Unexpeted.

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

Marked as reviewed by bpb (Reviewer).

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


From serb at openjdk.java.net  Wed Apr 13 22:22:10 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 13 Apr 2022 22:22:10 GMT
Subject: RFR: 8277816: Client tests fail on macos-Aarch64 host
In-Reply-To: <kLN8DjOu7ZQV4C1jt5pHr9axo4tmgigItGxa4IGuRrg=.21f625ef-b005-4f87-8abc-d9c3f51dc348@github.com>
References: <kLN8DjOu7ZQV4C1jt5pHr9axo4tmgigItGxa4IGuRrg=.21f625ef-b005-4f87-8abc-d9c3f51dc348@github.com>
Message-ID: <909PxsAFMSCzddQsanlheMm9C5uZttzdGR8-Ikcagrw=.fd1a241f-13e2-4b1c-8894-80cc0709b0a8@github.com>

On Wed, 13 Apr 2022 07:40:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This tests was failing on macos12 M1 systems due to wrong color profile configurations set in CI systems.
> If correct sRGB IEC61966-2.1 is set, then these test passed. Test job link in JBS..
> 
> So, removing from Problem list..

Marked as reviewed by serb (Reviewer).

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

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


From cjplummer at openjdk.java.net  Wed Apr 13 22:45:18 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 13 Apr 2022 22:45:18 GMT
Subject: RFR: 8284853: Fix varios 'expected' typo
In-Reply-To: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
Message-ID: <QJCzMs3gkj9ursFFOEjh83AzGXE69C_m2I8N0rj-RKc=.a5484f8c-880b-4f18-b0c1-3db360b5b66d@github.com>

On Wed, 13 Apr 2022 20:36:48 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc.

test/jdk/java/lang/StackWalker/StackStreamTest.java line 218:

> 216:     private static <T> void equalsOrThrow(String label, List<T> list, List<T> expected) {
> 217:         System.out.println("List:     " + list);
> 218:         System.out.println("Expected: " + list);

I think there is a per-existing bug here. Shouldn't the second println print `expected` instead of `list`?

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

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


From azvegint at openjdk.java.net  Wed Apr 13 23:18:07 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 13 Apr 2022 23:18:07 GMT
Subject: RFR: 8144030: [macosx] test
 java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails (again)
 [v2]
In-Reply-To: <Am6BMN4aKMiXkE2cJtjuHsjs_IEa2mC9HIZ8kb61kQ0=.52271f3c-9e74-425a-9bdd-b0f09ae63338@github.com>
References: <Am6BMN4aKMiXkE2cJtjuHsjs_IEa2mC9HIZ8kb61kQ0=.52271f3c-9e74-425a-9bdd-b0f09ae63338@github.com>
Message-ID: <SDqNGbdo7Ql0jxGwUaUkWPUfc9u-qvbifU_X2QIVKfc=.983b5999-abc3-41c7-ae88-4c8f8d46c7b2@github.com>

> This test has two undecorated frames: 
> 
> 1. background, 300x300
> 2. shaped foreground, 200x200
> 
> After displaying this frames it tries to check color outside of shape but within frame 2 bounds.
> 
> Unfortunately, on Linux and macOS there is a shadow around the shaped frame:
> ![image](https://user-images.githubusercontent.com/77687766/163270586-8dd97e93-582f-481f-999d-f08d4aaafba1.png)
> (changed color to green to make it more noticeable).
> 
> One way to fix the test would be to add tolerance to color check.
> But with old check points blue color may vary in 222-255 range, which is a bit too much.
> 
> Instead of this I made this shaped window  the size of background window. 
> This allows us to move check points away from shape border and its shadow, but still be able to check whether shape is applied or not.
> 
> Testing is green on all platforms.

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

  check around corners

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8233/files
  - new: https://git.openjdk.java.net/jdk/pull/8233/files/d169081d..dbef3618

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

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

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


From azvegint at openjdk.java.net  Wed Apr 13 23:18:08 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 13 Apr 2022 23:18:08 GMT
Subject: RFR: 8144030: [macosx] test
 java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails (again)
 [v2]
In-Reply-To: <M6DJlJBmfFJNdqqSuO4-Nmg0PI1o5rT4ydZ3WOFEmaw=.df1d020f-4712-4193-9bfa-b20ce350fc68@github.com>
References: <Am6BMN4aKMiXkE2cJtjuHsjs_IEa2mC9HIZ8kb61kQ0=.52271f3c-9e74-425a-9bdd-b0f09ae63338@github.com>
 <NLmuPi2x4ZyoIhSeU4U4zs9aGmFHqWVrcCpcg-qSPIU=.4f6512fb-9398-43a6-9524-f2fa46eb92e6@github.com>
 <M6DJlJBmfFJNdqqSuO4-Nmg0PI1o5rT4ydZ3WOFEmaw=.df1d020f-4712-4193-9bfa-b20ce350fc68@github.com>
Message-ID: <F6IIbPgHBCXWTYe3iyIz4mk8jqQQasaRQ-zQa32HzpE=.3b6df7b0-4fdb-4d4e-8cfa-a27c0127e4d4@github.com>

On Wed, 13 Apr 2022 21:46:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> test/jdk/java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java line 144:
>> 
>>> 142:                         point.y,
>>> 143:                         BACKGROUND_COLOR
>>> 144:                 );
>> 
>> Dunno why the old version was not checking inner points, but I've added one just to check if the shaped frame is above background one.
>
> Don't we need to check the places where the shadow is rendered that it is not the shape color(to prove that the shape is not simple rectangular)?

Sure, extra check added.

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

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


From jeremie.bergeron.1 at ens.etsmtl.ca  Tue Apr 12 17:05:39 2022
From: jeremie.bergeron.1 at ens.etsmtl.ca (=?iso-8859-1?Q?Bergeron=2C_J=E9r=E9mie?=)
Date: Tue, 12 Apr 2022 17:05:39 +0000
Subject: [Request] Post a message to all the list members
Message-ID: <YT3PR01MB91707AD5DC39E495801811EBDBED9@YT3PR01MB9170.CANPRD01.PROD.OUTLOOK.COM>

Hi,

I am the person who created this issues: https://bugs.openjdk.java.net/browse/JDK-8284730

I am messaging you, because I don't have an account, so I can't answer Praveen Narayanaswamy.

I would like to say to him that his suggestion is not an good solution.

I can't copy paste file from "%userprofile%\AppData\Local\Microsoft\Windows\Fonts" to "C:\Windows\Fonts". Yes, it would resolve the problem, but the user probably don't want me to do that (and, they are totally right. It would make a mess in the computer file.).

I would like to add that the method getAllFonts() (https://docs.oracle.com/javase/8/docs/api/java/awt/GraphicsEnvironment.html#getAllFonts--) show the font in the directory "%userprofile%\AppData\Local\Microsoft\Windows\Fonts".

Here is an example how to use it:
GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
Font[] fonts = ge.getAllFonts();

It is for me not logic that getAllFonts can get the font in "%userprofile%\AppData\Local\Microsoft\Windows\Fonts", but PhysicalFont.class.getDeclaredField("platName") could not get them.

In brief, I would like to know if it is possible to Praveen Narayanaswamy to reconsider his decision.

Have a great day


From psadhukhan at openjdk.java.net  Thu Apr 14 07:03:30 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 14 Apr 2022 07:03:30 GMT
Subject: RFR: 7132796: [macosx]
 closed/javax/swing/JComboBox/4517214/bug4517214.java fails on MacOS
Message-ID: <DFryrg8OZJ22xBLpprcnD14oXkSjF57fQA3jdwTD2Ko=.0a3b8830-4d7e-4c7e-8c1f-2932cd7ca1a8@github.com>

JDK-4517214 was fixed for Metal L&F where JComboBox having TitledBorder used to have double height compared to normal JComboBox.
The issue is still observed for macos for Aqua L&F where still double height is seen.
Fix is to prevent adding border insets height to combobox size as was done for [MetalComboxUI.getMinimumSize[](url)](https://github.com/openjdk/jdk/blame/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalComboBoxUI.java#L384)
The closed test is automated and moved to open.

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

Commit messages:
 - 7132796: [macosx] closed/javax/swing/JComboBox/4517214/bug4517214.java fails on MacOS
 - 7132796: [macosx] closed/javax/swing/JComboBox/4517214/bug4517214.java fails on MacOS
 - 7132796: [macosx] closed/javax/swing/JComboBox/4517214/bug4517214.java fails on MacOS

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

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


From azvegint at openjdk.java.net  Thu Apr 14 07:57:06 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 14 Apr 2022 07:57:06 GMT
Subject: Integrated: 6626492: Event time in future part 2, now on X
In-Reply-To: <SKEoIjhvEJL5ZVgxyfrZpUotPcOjtxm2fNB-tR1P4OQ=.f742f921-371c-434c-8c54-b7ab1d799c40@github.com>
References: <SKEoIjhvEJL5ZVgxyfrZpUotPcOjtxm2fNB-tR1P4OQ=.f742f921-371c-434c-8c54-b7ab1d799c40@github.com>
Message-ID: <oYwZBzE68M4_DRDYy8Ewvw8AknepemDo_L6pf615rh0=.4c5c1439-8a85-4b29-9e4e-e45cd37e8317@github.com>

On Wed, 13 Apr 2022 20:51:41 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This fix simply remove the test from ProblemList, since the issue is no longer reproducible.
> 
> Multiple CI test runs are green.

This pull request has now been integrated.

Changeset: 23c6817c
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/23c6817c1a3c05b9db05155952c40f1543b99077
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

6626492: Event time in future part 2, now on X

Reviewed-by: serb

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

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


From azvegint at openjdk.java.net  Thu Apr 14 07:58:13 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 14 Apr 2022 07:58:13 GMT
Subject: Integrated: 8159694: HiDPI, Unity,
 java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java
In-Reply-To: <Hx9FTEiBVH_hHXsOg78zPiBdHtfond1dqW5suSc3Egg=.dd76b22e-5045-4b2a-86c4-a0981f9401ba@github.com>
References: <Hx9FTEiBVH_hHXsOg78zPiBdHtfond1dqW5suSc3Egg=.dd76b22e-5045-4b2a-86c4-a0981f9401ba@github.com>
Message-ID: <Qrbj58cNnE6IsQduIKa1qPXxdusjs69XE9I2rrvJR9M=.1e39d3ce-6140-4f09-b973-aa655eda5fe9@github.com>

On Wed, 13 Apr 2022 11:27:44 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Window's title height was increased in Gnome/Unity since it was written, so the test tries to initiate drag on frame's header instead of its body. 
> Making the frame undecorated solves the issue. 
> Testing is green on all platforms.

This pull request has now been integrated.

Changeset: c3938ec1
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c3938ec18b4026d70d9654235dcd986d90344f5b
Stats:     11 lines in 3 files changed: 6 ins; 1 del; 4 mod

8159694: HiDPI, Unity, java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java

Reviewed-by: serb

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

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


From serb at openjdk.java.net  Thu Apr 14 09:17:18 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 14 Apr 2022 09:17:18 GMT
Subject: RFR: 8144030: [macosx] test
 java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails (again)
 [v2]
In-Reply-To: <SDqNGbdo7Ql0jxGwUaUkWPUfc9u-qvbifU_X2QIVKfc=.983b5999-abc3-41c7-ae88-4c8f8d46c7b2@github.com>
References: <Am6BMN4aKMiXkE2cJtjuHsjs_IEa2mC9HIZ8kb61kQ0=.52271f3c-9e74-425a-9bdd-b0f09ae63338@github.com>
 <SDqNGbdo7Ql0jxGwUaUkWPUfc9u-qvbifU_X2QIVKfc=.983b5999-abc3-41c7-ae88-4c8f8d46c7b2@github.com>
Message-ID: <xtrWEq9f1eHf3m_a02RLW7lNGM1gzoQUOxX0Ek9Vngo=.4949e848-2336-42c3-a6e9-e74bd87839a4@github.com>

On Wed, 13 Apr 2022 23:18:07 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This test has two undecorated frames: 
>> 
>> 1. background, 300x300
>> 2. shaped foreground, 200x200
>> 
>> After displaying this frames it tries to check color outside of shape but within frame 2 bounds.
>> 
>> Unfortunately, on Linux and macOS there is a shadow around the shaped frame:
>> ![image](https://user-images.githubusercontent.com/77687766/163270586-8dd97e93-582f-481f-999d-f08d4aaafba1.png)
>> (changed color to green to make it more noticeable).
>> 
>> One way to fix the test would be to add tolerance to color check.
>> But with old check points blue color may vary in 222-255 range, which is a bit too much.
>> 
>> Instead of this I made this shaped window  the size of background window. 
>> This allows us to move check points away from shape border and its shadow, but still be able to check whether shape is applied or not.
>> 
>> Testing is green on all platforms.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check around corners

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Thu Apr 14 09:18:35 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 14 Apr 2022 09:18:35 GMT
Subject: RFR: 8223543: [TESTBUG] Regression test
 java/awt/Graphics2D/DrawString/LCDTextSrcEa.java has issues
In-Reply-To: <QnP4PRehvVtNAyZirj5Q2Zyo9-9P_PxOkp4xHKw80n0=.6e9f4bc4-da65-4223-8c67-12f1ba05d5fd@github.com>
References: <QnP4PRehvVtNAyZirj5Q2Zyo9-9P_PxOkp4xHKw80n0=.6e9f4bc4-da65-4223-8c67-12f1ba05d5fd@github.com>
Message-ID: <ApeVakwFu-Fynk_SyKxmrkv9iz6u57bXA-2TTAz6tS8=.7841724f-510e-4baf-a943-e68beb364bb0@github.com>

On Wed, 13 Apr 2022 17:08:51 GMT, Phil Race <prr at openjdk.org> wrote:

> This test had problem described in the bug report, and most of it was related to being headful.
> But actually the test didn't need to be headful - it did the actual rendering it wanted to test to
> a software BufferedImage. So make it headless.
> Also only Windows always supports LCD text, so run the test there and not Linux or Mac.

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Thu Apr 14 09:19:37 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 14 Apr 2022 09:19:37 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux [v5]
In-Reply-To: <l8h3eiPB9RcX38ktddI1hgx1RL1ZaCZz0DlXdU-Hgjk=.d5380014-4dff-4334-8be9-fb537221f546@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
 <l8h3eiPB9RcX38ktddI1hgx1RL1ZaCZz0DlXdU-Hgjk=.d5380014-4dff-4334-8be9-fb537221f546@github.com>
Message-ID: <nJnCCAFlvqV2xhbccpox7i_dV-aIii0Vqm_jBSmlldM=.1734aa77-a14b-429c-8bc4-f82de665e26a@github.com>

On Fri, 8 Apr 2022 06:49:09 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> These crashes were not reproducible, so the fix is based on a hypothesis that there are two possible reasons for them:
>> 1. `makeDefaultConfig()` returning `NULL`.
>> 2. A race condition when the number of screens changes.
>> The race scenario: `X11GraphisDevice.makeDefaultConfiguration()` is called on EDT so the call can race with `X11GraphisDevice.invalidate()` that re-sets the screen number of the device; the latter is invoked on the `AWT-XAWT` thread from `X11GraphicsEnvironment.rebuildDevices()`. So by the time `makeDefaultConfiguration()` makes a native call with the device's current screen number, the `x11Screens` array maintained by the native code could have become shorter. And the native methods like `Java_sun_awt_X11GraphicsDevice_getConfigColormap()` assume that the number passed to them is always current and valid. The AWT lock only protects against the changes during the native methods invocation and does not protect against them being called with an outdated screen number. With a larger screen number, those methods read past the end of the `x11Screens` array.
>> 
>> The fix for (1) is to die gracefully instead of crashing in an attempt to de-reference a `NULL` pointer, which might happen upon returning from `makeDefaultConfig()` in `getAllConfigs()`.
>> 
>> The fix for (2) is to eliminate the race by protecting `X11GraphisDevice.screen` with the AWT lock such that it doesn't change when the native methods working with it are active.
>> 
>> We've been shipping JetBrains Runtime with this fix for a few months now and there were no crash reports with those specific patterns against the versions with the fix.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restored the original code in X11GraphicsDevice.java that got auto-formatted

The latest version looks fine to me.

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

Marked as reviewed by serb (Reviewer).

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


From serb at openjdk.java.net  Thu Apr 14 09:20:09 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 14 Apr 2022 09:20:09 GMT
Subject: RFR: 7132796: [macosx]
 closed/javax/swing/JComboBox/4517214/bug4517214.java fails on MacOS
In-Reply-To: <DFryrg8OZJ22xBLpprcnD14oXkSjF57fQA3jdwTD2Ko=.0a3b8830-4d7e-4c7e-8c1f-2932cd7ca1a8@github.com>
References: <DFryrg8OZJ22xBLpprcnD14oXkSjF57fQA3jdwTD2Ko=.0a3b8830-4d7e-4c7e-8c1f-2932cd7ca1a8@github.com>
Message-ID: <3MS0Dcso0EXEjumdqT0HEYF1MaTdVjQ5XMIyqIWPKJ4=.6aaddd8a-90e5-4dc8-95b3-ed49d244b023@github.com>

On Thu, 14 Apr 2022 06:50:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> JDK-4517214 was fixed for Metal L&F where JComboBox having TitledBorder used to have double height compared to normal JComboBox.
> The issue is still observed for macos for Aqua L&F where still double height is seen.
> Fix is to prevent adding border insets height to combobox size as was done for [MetalComboxUI.getMinimumSize[](url)](https://github.com/openjdk/jdk/blame/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalComboBoxUI.java#L384)
> The closed test is automated and moved to open. CI testing on all platform is ok.

test/jdk/javax/swing/JComboBox/TestComboBoxHeight.java line 48:

> 46: 
> 47:     public static void main(String[] args) throws Exception {
> 48:         try {

Can we check all L&Fs?

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

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


From aturbanov at openjdk.java.net  Thu Apr 14 09:28:17 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Thu, 14 Apr 2022 09:28:17 GMT
Subject: RFR: 8284853: Fix various 'expected' typo [v2]
In-Reply-To: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
Message-ID: <bisAVGnhNiqxb9oNb7lsqrjIO84qDRUeqyfw7p7jSME=.e2b1b6c3-fc70-4b5b-8cb2-d1987de9a7dd@github.com>

> Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc.

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

  8284853: Fix various 'expected' typo
  improve test log

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8231/files
  - new: https://git.openjdk.java.net/jdk/pull/8231/files/fe6d9890..9fc75e89

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

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

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


From psadhukhan at openjdk.java.net  Thu Apr 14 09:38:11 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 14 Apr 2022 09:38:11 GMT
Subject: RFR: 7132796: [macosx]
 closed/javax/swing/JComboBox/4517214/bug4517214.java fails on MacOS
In-Reply-To: <3MS0Dcso0EXEjumdqT0HEYF1MaTdVjQ5XMIyqIWPKJ4=.6aaddd8a-90e5-4dc8-95b3-ed49d244b023@github.com>
References: <DFryrg8OZJ22xBLpprcnD14oXkSjF57fQA3jdwTD2Ko=.0a3b8830-4d7e-4c7e-8c1f-2932cd7ca1a8@github.com>
 <3MS0Dcso0EXEjumdqT0HEYF1MaTdVjQ5XMIyqIWPKJ4=.6aaddd8a-90e5-4dc8-95b3-ed49d244b023@github.com>
Message-ID: <cRpHemuP6L-sEIbMYyUCg2WIXjUC6hVsqTX5iMtlgnk=.48c4e5d7-399c-4fb9-acac-bf293fe5d94e@github.com>

On Thu, 14 Apr 2022 09:17:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> JDK-4517214 was fixed for Metal L&F where JComboBox having TitledBorder used to have double height compared to normal JComboBox.
>> The issue is still observed for macos for Aqua L&F where still double height is seen.
>> Fix is to prevent adding border insets height to combobox size as was done for [MetalComboxUI.getMinimumSize[](url)](https://github.com/openjdk/jdk/blame/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalComboBoxUI.java#L384)
>> The closed test is automated and moved to open. CI testing on all platform is ok.
>
> test/jdk/javax/swing/JComboBox/TestComboBoxHeight.java line 48:
> 
>> 46: 
>> 47:     public static void main(String[] args) throws Exception {
>> 48:         try {
> 
> Can we check all L&Fs?

Not now..we already have open JBS for window L&F JDK-8233469 and it also fails in Nimbus which will be looked into separately..
I will like this PR to be for for default L&F only otherwise it will cause failure in CI systems..

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

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


From duke at openjdk.java.net  Thu Apr 14 10:34:26 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Thu, 14 Apr 2022 10:34:26 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux [v5]
In-Reply-To: <6dun2ppw1GHei7MlyCfLlnQ27NsNRSZ5F3Y1kSWrA7E=.08fadf9c-73f4-499e-8b45-f5e3c147bd91@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
 <l8h3eiPB9RcX38ktddI1hgx1RL1ZaCZz0DlXdU-Hgjk=.d5380014-4dff-4334-8be9-fb537221f546@github.com>
 <6dun2ppw1GHei7MlyCfLlnQ27NsNRSZ5F3Y1kSWrA7E=.08fadf9c-73f4-499e-8b45-f5e3c147bd91@github.com>
Message-ID: <8kzfditr4KLCLoieljvFky8980_z0wEFEaHYFzkndvk=.4c71dcaa-2537-429b-b8fa-befa6f32f080@github.com>

On Fri, 8 Apr 2022 16:20:10 GMT, Phil Race <prr at openjdk.org> wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restored the original code in X11GraphicsDevice.java that got auto-formatted
>
> src/java.desktop/unix/classes/sun/awt/X11/XCanvasPeer.java line 90:
> 
>> 88:                 getScreenDevices()[screenNum].
>> 89:                 getDefaultConfiguration();
>> 90:         }
> 
> why did you get rid of the just in case ?
> Actually why is this method being modified at all ? 
> I mean besides adding locking ..

@prrace Are you OK with the current state of things? Let me know if you want part of the changes reverted.

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

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


From yyang at openjdk.java.net  Thu Apr 14 10:42:11 2022
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 14 Apr 2022 10:42:11 GMT
Subject: RFR: 8284853: Fix various 'expected' typo [v2]
In-Reply-To: <bisAVGnhNiqxb9oNb7lsqrjIO84qDRUeqyfw7p7jSME=.e2b1b6c3-fc70-4b5b-8cb2-d1987de9a7dd@github.com>
References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
 <bisAVGnhNiqxb9oNb7lsqrjIO84qDRUeqyfw7p7jSME=.e2b1b6c3-fc70-4b5b-8cb2-d1987de9a7dd@github.com>
Message-ID: <rNQ6IxlRdqzXlRKEfw2Hnyn7pI5_h3ydBV_grUrKfe0=.82d95656-bdd3-4607-a12d-5964ac33f53a@github.com>

On Thu, 14 Apr 2022 09:28:17 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284853: Fix various 'expected' typo
>   improve test log

I found [yet another typo](https://github.com/kelthuzadx/jdk/commit/acb9e15bc0bf5395d1c0875f36992f692734f948), I wonder if you can merge this into your patch so that I do not need to submit a new PR for it? Thanks.

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

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


From azvegint at openjdk.java.net  Thu Apr 14 10:54:19 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 14 Apr 2022 10:54:19 GMT
Subject: RFR: 8277816: Client tests fail on macos-Aarch64 host
In-Reply-To: <kLN8DjOu7ZQV4C1jt5pHr9axo4tmgigItGxa4IGuRrg=.21f625ef-b005-4f87-8abc-d9c3f51dc348@github.com>
References: <kLN8DjOu7ZQV4C1jt5pHr9axo4tmgigItGxa4IGuRrg=.21f625ef-b005-4f87-8abc-d9c3f51dc348@github.com>
Message-ID: <M25dXIy1KpHq2IvPp6EFgX54nsZkhFo2MCBapvF7mdM=.917b3179-b0c2-44c7-b34c-f08a505e32b0@github.com>

On Wed, 13 Apr 2022 07:40:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This tests was failing on macos12 M1 systems due to wrong color profile configurations set in CI systems.
> If correct sRGB IEC61966-2.1 is set, then these test passed. Test job link in JBS..
> 
> So, removing from Problem list..

Marked as reviewed by azvegint (Reviewer).

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

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


From duke at openjdk.java.net  Thu Apr 14 10:54:45 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Thu, 14 Apr 2022 10:54:45 GMT
Subject: RFR: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage [v11]
In-Reply-To: <uoyejtJacFQhm9-q6ZedJEBVev1fBd0MTp70JcOHmNU=.594c6e43-71ba-4ad3-a3dc-a9afc860b037@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
 <YEi-Ge2_proOlxBQ_qGD4b4u_17FGTmHgPhXAZ-OH14=.b92e4259-eeeb-4fbc-a105-8235572a9d78@github.com>
 <Q9Rzoht-EKO-lEy-xyFOEVkSLY42UclCWsh-31dZdwg=.e986a229-14ec-4f54-bf5c-07546b66dac7@github.com>
 <P9fn2Yk5EBPib8khH0LhSMty69hrUKy9jEf7fMSUmc4=.c2fce1f1-d2b6-4890-a408-9e14a00fd578@github.com>
 <uoyejtJacFQhm9-q6ZedJEBVev1fBd0MTp70JcOHmNU=.594c6e43-71ba-4ad3-a3dc-a9afc860b037@github.com>
Message-ID: <ign8t4Ll0HRDxFni7MGLdYhCVgk2J0-45AUZr4x-eMc=.ac013916-1a0f-4303-8238-27945d713f36@github.com>

On Tue, 12 Apr 2022 20:50:48 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is intentional, it makes sure the image is in `LOADING` state to verify that the newly added resets it to `ABORTED`.
>> 
>> I don't expect the image to load, we don't care. If it succeeds, the status is `COMPLETE`; if it times outs or another error occurs, the status is `ERRORED`.
>
> ok .. I trust this test has been verified in mach5 already ..

Yes, I have verified in mach5......

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

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


From azvegint at openjdk.java.net  Thu Apr 14 11:12:29 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 14 Apr 2022 11:12:29 GMT
Subject: RFR: 8223543: [TESTBUG] Regression test
 java/awt/Graphics2D/DrawString/LCDTextSrcEa.java has issues
In-Reply-To: <QnP4PRehvVtNAyZirj5Q2Zyo9-9P_PxOkp4xHKw80n0=.6e9f4bc4-da65-4223-8c67-12f1ba05d5fd@github.com>
References: <QnP4PRehvVtNAyZirj5Q2Zyo9-9P_PxOkp4xHKw80n0=.6e9f4bc4-da65-4223-8c67-12f1ba05d5fd@github.com>
Message-ID: <D4lnKLLsoAvfI3qrM_m7l2DuLzr6jAlqkhT1IOSq-Gg=.28598a01-b714-49fc-baca-b5d60fd3e6e5@github.com>

On Wed, 13 Apr 2022 17:08:51 GMT, Phil Race <prr at openjdk.org> wrote:

> This test had problem described in the bug report, and most of it was related to being headful.
> But actually the test didn't need to be headful - it did the actual rendering it wanted to test to
> a software BufferedImage. So make it headless.
> Also only Windows always supports LCD text, so run the test there and not Linux or Mac.

Marked as reviewed by azvegint (Reviewer).

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

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


From duke at openjdk.java.net  Thu Apr 14 11:14:37 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Thu, 14 Apr 2022 11:14:37 GMT
Subject: Integrated: 8236987: Remove call to System.out.println from
 ImageIcon.loadImage
In-Reply-To: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
References: <pViWoZrp-Yqg6Q0MlWaThhgrdiox7cI5Tmkopn4dOgc=.d59d4390-2d01-40d1-ba93-90a4c5804ecb@github.com>
Message-ID: <JD4Y5NRTX453mDDnrhN-DRmlnVGrCJFdiIEptxJ7_Fo=.da7fcb73-6e3a-4a63-8901-9be85dbf3795@github.com>

On Wed, 9 Mar 2022 10:04:09 GMT, Tejesh R <duke at openjdk.java.net> wrote:

> Removed the println() line from the Interrupted catch block. Since waitForID() Interrupt indicates completion of Image Loading, println as Interrupt handling was not required.

This pull request has now been integrated.

Changeset: f2640317
Author:    Tejesh R <tejesh.r at oracle.com>
Committer: Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f26403172f2e19e2ed4efd0f06f00beaebde1031
Stats:     96 lines in 2 files changed: 95 ins; 0 del; 1 mod

8236987: Remove call to System.out.println from ImageIcon.loadImage

Reviewed-by: aivanov, psadhukhan, prr

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

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


From aivanov at openjdk.java.net  Thu Apr 14 12:48:15 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 14 Apr 2022 12:48:15 GMT
Subject: RFR: 8223543: [TESTBUG] Regression test
 java/awt/Graphics2D/DrawString/LCDTextSrcEa.java has issues
In-Reply-To: <QnP4PRehvVtNAyZirj5Q2Zyo9-9P_PxOkp4xHKw80n0=.6e9f4bc4-da65-4223-8c67-12f1ba05d5fd@github.com>
References: <QnP4PRehvVtNAyZirj5Q2Zyo9-9P_PxOkp4xHKw80n0=.6e9f4bc4-da65-4223-8c67-12f1ba05d5fd@github.com>
Message-ID: <1EIc_o631mZjO901PBRnvRKHYZQv5mbU6mCUQrggoJw=.eb6fee9e-f5b3-427c-9cf4-933e04b42137@github.com>

On Wed, 13 Apr 2022 17:08:51 GMT, Phil Race <prr at openjdk.org> wrote:

> This test had problem described in the bug report, and most of it was related to being headful.
> But actually the test didn't need to be headful - it did the actual rendering it wanted to test to
> a software BufferedImage. So make it headless.
> Also only Windows always supports LCD text, so run the test there and not Linux or Mac.

Marked as reviewed by aivanov (Reviewer).

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

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


From ihse at openjdk.java.net  Thu Apr 14 13:13:15 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 14 Apr 2022 13:13:15 GMT
Subject: RFR: 8284853: Fix various 'expected' typo [v2]
In-Reply-To: <bisAVGnhNiqxb9oNb7lsqrjIO84qDRUeqyfw7p7jSME=.e2b1b6c3-fc70-4b5b-8cb2-d1987de9a7dd@github.com>
References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
 <bisAVGnhNiqxb9oNb7lsqrjIO84qDRUeqyfw7p7jSME=.e2b1b6c3-fc70-4b5b-8cb2-d1987de9a7dd@github.com>
Message-ID: <X-2el87FZNWkIJqRe20t_Bl9wIiXf3fwfEt1TELtIZk=.a3adafdc-952b-4f8b-a0be-fa4415426f06@github.com>

On Thu, 14 Apr 2022 09:28:17 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284853: Fix various 'expected' typo
>   improve test log

Build changes look good.

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

Marked as reviewed by ihse (Reviewer).

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


From azvegint at openjdk.java.net  Thu Apr 14 14:31:03 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 14 Apr 2022 14:31:03 GMT
Subject: RFR: 8159599: [TEST_BUG]
 java/awt/Modal/ModalInternalFrameTest/ModalInternalFrameTest.java
Message-ID: <YK4XPjlYqSfUNstD5kB6NjU0kJIIC8IS_YejaCPqC34=.5060adf2-a9e9-4e79-a542-a93c6177599f@github.com>

The SimpleWindowActivationTest test does not fail even without modifications(multiple CI test runs are green).
So just remove it from ProblemList would be enough.

However I did some clean up and added some delays for  "extra safety".

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

Commit messages:
 - initial
 - initial

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

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


From ihse at openjdk.java.net  Thu Apr 14 16:12:27 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 14 Apr 2022 16:12:27 GMT
Subject: RFR: 8284891: Fix typos in build system files
Message-ID: <48sHX_PTeLN0flIYI_TiwTd3gsE3QGm3xw_iaoA6mTU=.2efe1eea-0398-43ca-ad71-3ce4671c0ffe@github.com>

I ran `codespell` on the `make` directory, and accepted those changes where it indeed discovered real typos.

(Due to false positives this can unfortunately not be run automatically) 

Most of the fixes are in comments. A few are in messages aimed at the user.

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

Commit messages:
 - 8284891: Fix typos in build system files

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

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


From erikj at openjdk.java.net  Thu Apr 14 16:29:40 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 14 Apr 2022 16:29:40 GMT
Subject: RFR: 8284891: Fix typos in build system files
In-Reply-To: <48sHX_PTeLN0flIYI_TiwTd3gsE3QGm3xw_iaoA6mTU=.2efe1eea-0398-43ca-ad71-3ce4671c0ffe@github.com>
References: <48sHX_PTeLN0flIYI_TiwTd3gsE3QGm3xw_iaoA6mTU=.2efe1eea-0398-43ca-ad71-3ce4671c0ffe@github.com>
Message-ID: <eOghGOYfVNtq52tpdDhCbiKEXTUC49ROtX8_2BfvTV8=.e21f3899-eab3-4c74-8328-e2e5ca85102f@github.com>

On Thu, 14 Apr 2022 16:05:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on the `make` directory, and accepted those changes where it indeed discovered real typos.
> 
> (Due to false positives this can unfortunately not be run automatically) 
> 
> Most of the fixes are in comments. A few are in messages aimed at the user.

Marked as reviewed by erikj (Reviewer).

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

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


From duke at openjdk.java.net  Thu Apr 14 16:59:33 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 14 Apr 2022 16:59:33 GMT
Subject: RFR: 8274082 : Wrong test case name specified in jtreg run tag for
 java/awt/print/PrinterJob/SwingUIText.java [v2]
In-Reply-To: <ZCvrnk1meFmsJa3Q5hk2onn7kUQL18cxrktRywdActc=.befc4c76-c87c-4261-8888-0cee83df9a80@github.com>
References: <ZCvrnk1meFmsJa3Q5hk2onn7kUQL18cxrktRywdActc=.befc4c76-c87c-4261-8888-0cee83df9a80@github.com>
Message-ID: <SuDeIcq05jcT1BuJLB2rlV3u8dMo9OV_yCvhYniAviY=.c6090e4b-7051-4874-a9f1-d97c11d0f0f4@github.com>

> Following issues were fixed in this test 
> 1) Fixed - Parser error due to yesno in @run main/manual=yesno
> 2) Fixed Wrong test name specified in @run jtreg
> @run main/manual=yesno PrintTextTest . It should be @run main/manual=yesno SwingUIText
> 3) Instruction frame does not have 'Pass' or 'Fail' button to mark the test as Pass or Fail after verifying Text on UI and print out. 
> 4) Fixed - Test UI ( test instruction frame, UI frame and Print Dialog) just gets disposed automatically without interacting via running the test case with jtreg. 
> 
> @shurymury

lawrence.andrews has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8274082
 - 8274082 : Wrong test case name specified in jtreg run tag for java/awt/print/PrinterJob/SwingUIText.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7946/files
  - new: https://git.openjdk.java.net/jdk/pull/7946/files/f1dca5de..0916e6ea

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

  Stats: 187386 lines in 2481 files changed: 134302 ins; 12666 del; 40418 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7946.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7946/head:pull/7946

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


From aturbanov at openjdk.java.net  Thu Apr 14 18:09:34 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Thu, 14 Apr 2022 18:09:34 GMT
Subject: RFR: 8284853: Fix various 'expected' typo [v2]
In-Reply-To: <rNQ6IxlRdqzXlRKEfw2Hnyn7pI5_h3ydBV_grUrKfe0=.82d95656-bdd3-4607-a12d-5964ac33f53a@github.com>
References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
 <bisAVGnhNiqxb9oNb7lsqrjIO84qDRUeqyfw7p7jSME=.e2b1b6c3-fc70-4b5b-8cb2-d1987de9a7dd@github.com>
 <rNQ6IxlRdqzXlRKEfw2Hnyn7pI5_h3ydBV_grUrKfe0=.82d95656-bdd3-4607-a12d-5964ac33f53a@github.com>
Message-ID: <b2zhGMW2RG0f8ZRDrnI8nSfW-JeuZx8-DNvJaGRXu4g=.dcfbe0fb-6f7c-4f46-8fbe-458a42f7ca21@github.com>

On Thu, 14 Apr 2022 10:38:33 GMT, Yi Yang <yyang at openjdk.org> wrote:

>I found [yet another typo](https://github.com/kelthuzadx/jdk/commit/acb9e15bc0bf5395d1c0875f36992f692734f948), I wonder if you can merge this into your patch so that I do not need to submit a new PR for it? Thanks.

I think it deserves a separate ticket. BTW there are a lot of other typos in JDK, especially in comments.

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

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


From aturbanov at openjdk.java.net  Thu Apr 14 18:09:37 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Thu, 14 Apr 2022 18:09:37 GMT
Subject: Integrated: 8284853: Fix various 'expected' typo
In-Reply-To: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
Message-ID: <EazeFRrVhzLud87RZyQuAAcvVVGBXgS_8bvUToeijvA=.6d3c58fc-5c53-4e82-8166-8ce446c200c6@github.com>

On Wed, 13 Apr 2022 20:36:48 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc.

This pull request has now been integrated.

Changeset: 48c75498
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/48c75498060f076287d3d44c49934db9ac70887b
Stats:     65 lines in 28 files changed: 0 ins; 0 del; 65 mod

8284853: Fix various 'expected' typo

Reviewed-by: bpb, ihse

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

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


From ihse at openjdk.java.net  Thu Apr 14 19:37:33 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 14 Apr 2022 19:37:33 GMT
Subject: Integrated: 8284891: Fix typos in build system files
In-Reply-To: <48sHX_PTeLN0flIYI_TiwTd3gsE3QGm3xw_iaoA6mTU=.2efe1eea-0398-43ca-ad71-3ce4671c0ffe@github.com>
References: <48sHX_PTeLN0flIYI_TiwTd3gsE3QGm3xw_iaoA6mTU=.2efe1eea-0398-43ca-ad71-3ce4671c0ffe@github.com>
Message-ID: <2mF5V7umZUZe-exsy8TAj69oQs5CZ1A41lGknDaoNVc=.bf65fd9f-8851-4626-8bd1-6f23fef1e945@github.com>

On Thu, 14 Apr 2022 16:05:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on the `make` directory, and accepted those changes where it indeed discovered real typos.
> 
> (Due to false positives this can unfortunately not be run automatically) 
> 
> Most of the fixes are in comments. A few are in messages aimed at the user.

This pull request has now been integrated.

Changeset: 160eb2bd
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/160eb2bd392fea29dd690ee9781174d14dc0b659
Stats:     72 lines in 46 files changed: 0 ins; 0 del; 72 mod

8284891: Fix typos in build system files

Reviewed-by: erikj

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

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


From aivanov at openjdk.java.net  Thu Apr 14 20:31:51 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 14 Apr 2022 20:31:51 GMT
Subject: RFR: 8284884: Replace polling with waiting in
 javax/swing/text/html/parser/Parser/8078268/bug8078268.java
Message-ID: <ZzShBwEJLSeOoiFdyiUtYUOUMq2yOHaS_z-mkOcrHrs=.1b342753-44ec-4dcc-879a-3d6dabfe1824@github.com>

A quick fix for the `javax/swing/text/html/parser/Parser/8078268/bug8078268.java` which replaces `Thread.sleep` in a loop with `CountDownLatch.await`.

The code is shorter and clearer.

The test fails on the builds without the fix for [JDK-8078268](https://bugs.openjdk.java.net/browse/JDK-8078268). I ran it in the CI and it passes.

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

Commit messages:
 - 8284884: Drop author
 - 8284884: Replace polling with waiting in javax/swing/text/html/parser/Parser/8078268/bug8078268.java

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

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


From aivanov at openjdk.java.net  Thu Apr 14 20:36:19 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 14 Apr 2022 20:36:19 GMT
Subject: RFR: 8284884: Replace polling with waiting in
 javax/swing/text/html/parser/Parser/8078268/bug8078268.java [v2]
In-Reply-To: <ZzShBwEJLSeOoiFdyiUtYUOUMq2yOHaS_z-mkOcrHrs=.1b342753-44ec-4dcc-879a-3d6dabfe1824@github.com>
References: <ZzShBwEJLSeOoiFdyiUtYUOUMq2yOHaS_z-mkOcrHrs=.1b342753-44ec-4dcc-879a-3d6dabfe1824@github.com>
Message-ID: <AaMSO2hxsZdz2d9VsSdzPgBy4ke2K7xO_NUKkTIVuVE=.33813eab-0e20-49d9-9f54-0d5481791f68@github.com>

> A quick fix for the `javax/swing/text/html/parser/Parser/8078268/bug8078268.java` which replaces `Thread.sleep` in a loop with `CountDownLatch.await`.
> 
> The code is shorter and clearer.
> 
> The test fails on the builds without the fix for [JDK-8078268](https://bugs.openjdk.java.net/browse/JDK-8078268). I ran it in the CI and it passes.

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

  Simplify filename handling

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8252/files
  - new: https://git.openjdk.java.net/jdk/pull/8252/files/0609a11f..83d6301d

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

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

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


From duke at openjdk.java.net  Thu Apr 14 23:36:28 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 14 Apr 2022 23:36:28 GMT
Subject: RFR: 8283803 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/PrintGlyphVectorTest.java and fix test [v6]
In-Reply-To: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
Message-ID: <CBj_HxHytYESfXcMZIzRAgPYsOtHA-aUEkPe_v1FGns=.685d7a65-a7c2-4ae7-8a91-9d6f25d7ece4@github.com>

> Fixed the following issue.
> 1) Removed yes/no since test was failing due to "Parser error due to yesno in @run main/manual=yesno"
> 2) After removing yes/no test run( just shows the UI and gets dispose immediately). User cannot interact with the test UI and mark the test pass or failed. 
> So added Pass and Fail button to mark the test result.
> 3) Added timeout if in case user does not interact with the test UI.
> 
> @shurymury 
> @aivanov-jdk

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

  Enhance PassFailJFrame.java & fixed PrintGlyphVectorTest.java test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8004/files
  - new: https://git.openjdk.java.net/jdk/pull/8004/files/4a5d327d..af60daf0

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

  Stats: 69 lines in 2 files changed: 47 ins; 6 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8004.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8004/head:pull/8004

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


From duke at openjdk.java.net  Thu Apr 14 23:45:28 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 14 Apr 2022 23:45:28 GMT
Subject: RFR: 8284898 : Enhance PassFailJFrame [v7]
In-Reply-To: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
Message-ID: <3EmU2J5RtgVxJUd0q8x16cb0DI1nj6jPbaswnaiudMg=.509ddf8b-401b-450a-93a6-da64b94bfb2b@github.com>

> Fixed the following issue.
> 1) Removed yes/no since test was failing due to "Parser error due to yesno in @run main/manual=yesno"
> 2) After removing yes/no test run( just shows the UI and gets dispose immediately). User cannot interact with the test UI and mark the test pass or failed. 
> So added Pass and Fail button to mark the test result.
> 3) Added timeout if in case user does not interact with the test UI.
> 
> @shurymury 
> @aivanov-jdk

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

  Update PrintGlyphVectorTest.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8004/files
  - new: https://git.openjdk.java.net/jdk/pull/8004/files/af60daf0..e891ed17

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

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

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


From prr at openjdk.java.net  Fri Apr 15 01:08:44 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 15 Apr 2022 01:08:44 GMT
Subject: Integrated: 8223543: [TESTBUG] Regression test
 java/awt/Graphics2D/DrawString/LCDTextSrcEa.java has issues
In-Reply-To: <QnP4PRehvVtNAyZirj5Q2Zyo9-9P_PxOkp4xHKw80n0=.6e9f4bc4-da65-4223-8c67-12f1ba05d5fd@github.com>
References: <QnP4PRehvVtNAyZirj5Q2Zyo9-9P_PxOkp4xHKw80n0=.6e9f4bc4-da65-4223-8c67-12f1ba05d5fd@github.com>
Message-ID: <LlCsEfHV5JXw9432IvWauY8Y1iUZOPvAzoDop6W-Vcw=.842c6f87-cd9f-4f77-9db9-fdb7fea714de@github.com>

On Wed, 13 Apr 2022 17:08:51 GMT, Phil Race <prr at openjdk.org> wrote:

> This test had problem described in the bug report, and most of it was related to being headful.
> But actually the test didn't need to be headful - it did the actual rendering it wanted to test to
> a software BufferedImage. So make it headless.
> Also only Windows always supports LCD text, so run the test there and not Linux or Mac.

This pull request has now been integrated.

Changeset: d41331e6
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d41331e6f2255aa07dbbbbccf62e39c50269e269
Stats:     51 lines in 1 file changed: 18 ins; 25 del; 8 mod

8223543: [TESTBUG] Regression test java/awt/Graphics2D/DrawString/LCDTextSrcEa.java has issues

Reviewed-by: serb, azvegint, aivanov

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

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


From prr at openjdk.java.net  Fri Apr 15 01:22:39 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 15 Apr 2022 01:22:39 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v5]
In-Reply-To: <bFJoKiD6n9BimxrGVu8lNW-m3RswKRF_hGhfU905VMs=.94c9f727-2afc-4dde-ab57-f5737d9a034b@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <bFJoKiD6n9BimxrGVu8lNW-m3RswKRF_hGhfU905VMs=.94c9f727-2afc-4dde-ab57-f5737d9a034b@github.com>
Message-ID: <K_RQ5rxh68N4FeYHoM5O3wJ6Vv0omh0VR_Z_uaUBciQ=.bdd3af1a-2309-4408-8c1f-0329c1d1fc47@github.com>

On Fri, 8 Apr 2022 12:17:37 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> getText function returned extra endOfLine when appended. The reason was in `EditorEditorKit` class, `write(Writer out, Document doc, int pos, int len)` method, where translation happens from buffer to Out(Writer Object) if endOfLine is other than '\n' ( which is '\r\n' in windows). In order to write each line till End of line, the string till '\n' is written including '\r' and again endOfLine is written which results in extra Carriage Return. To solve this issue, a Condition is added which checks if previous character to '\n' is '\r', if true then whole string except Carriage Return ('\r') is written, else whole string till before '\n' is written.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on Review Comments

Not 100% certain on this but "not an issue" sounds safest to me.
Doing nothing is the only way to be sure you didn't introduce a regression.
I'd expect folks who were doing this from code learned .. but what happens if a user pastes
a few lines of text from windows Notepad - and it contains \r\n ?
You can't stop users doing that and they will be surprised.
If that is happening I'd give serious consideration to doing the translation of \r\n -> \n not just
on reading the initial text but in all mutations of the text.
at the very least if we already set DefaultEditorKit.EndOfLineStringProperty we'd want to .. 
But would such mutations alone also trigger setting DefaultEditorKit.EndOfLineStringProperty ?

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

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


From psadhukhan at openjdk.java.net  Fri Apr 15 05:32:59 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 15 Apr 2022 05:32:59 GMT
Subject: RFR: 8042380: Test javax/swing/JFileChooser/4524490/bug4524490.java
 fails with InvocationTargetException
Message-ID: <iwmtWKDSm1kLO6l4y8Yc7ulCL6Yb8Aw0Li072Vpb1UY=.4b3cca2e-8e90-42cb-bab9-1b83a8743033@github.com>

This test used to fail in nightly testing few years back and it seems it fails because we used to run in samevm mode at that time.
Several iterations of this test pass in CI testing in all platforms (link in JBS) so removing from Problemlist.

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

Commit messages:
 - 8042380: Test javax/swing/JFileChooser/4524490/bug4524490.java fails with InvocationTargetException

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

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


From serb at openjdk.java.net  Fri Apr 15 06:06:42 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 15 Apr 2022 06:06:42 GMT
Subject: RFR: 8042380: Test
 javax/swing/JFileChooser/4524490/bug4524490.java fails with
 InvocationTargetException
In-Reply-To: <iwmtWKDSm1kLO6l4y8Yc7ulCL6Yb8Aw0Li072Vpb1UY=.4b3cca2e-8e90-42cb-bab9-1b83a8743033@github.com>
References: <iwmtWKDSm1kLO6l4y8Yc7ulCL6Yb8Aw0Li072Vpb1UY=.4b3cca2e-8e90-42cb-bab9-1b83a8743033@github.com>
Message-ID: <fRSSXXjHw0GW0rakvFzB0RNd1fcpVsRkMTjuJXXnQDo=.7cff1366-d967-4f86-ae5b-70a48043ad24@github.com>

On Fri, 15 Apr 2022 05:26:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test used to fail in nightly testing few years back and it seems it fails because we used to run in samevm mode at that time.
> Several iterations of this test pass in CI testing in all platforms (link in JBS) so removing from Problemlist.

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Fri Apr 15 06:08:40 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 15 Apr 2022 06:08:40 GMT
Subject: RFR: 8284884: Replace polling with waiting in
 javax/swing/text/html/parser/Parser/8078268/bug8078268.java [v2]
In-Reply-To: <AaMSO2hxsZdz2d9VsSdzPgBy4ke2K7xO_NUKkTIVuVE=.33813eab-0e20-49d9-9f54-0d5481791f68@github.com>
References: <ZzShBwEJLSeOoiFdyiUtYUOUMq2yOHaS_z-mkOcrHrs=.1b342753-44ec-4dcc-879a-3d6dabfe1824@github.com>
 <AaMSO2hxsZdz2d9VsSdzPgBy4ke2K7xO_NUKkTIVuVE=.33813eab-0e20-49d9-9f54-0d5481791f68@github.com>
Message-ID: <2Dcis2vt-oSLgC3xHJ0XI0B1eCKo3e4Poq6W-U5k3nQ=.7567a100-de1c-40de-9d76-0e22977a7117@github.com>

On Thu, 14 Apr 2022 20:36:19 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> A quick fix for the `javax/swing/text/html/parser/Parser/8078268/bug8078268.java` which replaces `Thread.sleep` in a loop with `CountDownLatch.await`.
>> 
>> The code is shorter and clearer.
>> 
>> The test fails on the builds without the fix for [JDK-8078268](https://bugs.openjdk.java.net/browse/JDK-8078268). I ran it in the CI and it passes.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify filename handling

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8252


From serb at openjdk.java.net  Fri Apr 15 06:09:40 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 15 Apr 2022 06:09:40 GMT
Subject: RFR: 8159599: [TEST_BUG]
 java/awt/Modal/ModalInternalFrameTest/ModalInternalFrameTest.java
In-Reply-To: <YK4XPjlYqSfUNstD5kB6NjU0kJIIC8IS_YejaCPqC34=.5060adf2-a9e9-4e79-a542-a93c6177599f@github.com>
References: <YK4XPjlYqSfUNstD5kB6NjU0kJIIC8IS_YejaCPqC34=.5060adf2-a9e9-4e79-a542-a93c6177599f@github.com>
Message-ID: <OANfV9ElR5HohtqCDwpWIMQa7p3II4TGTc19Mv1n4xc=.cddf92bc-b8bf-48f2-9e86-ac82c3b5bfe3@github.com>

On Thu, 14 Apr 2022 14:22:18 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The SimpleWindowActivationTest test does not fail even without modifications(multiple CI test runs are green).
> So just remove it from ProblemList would be enough.
> 
> However I did some clean up and added some delays for  "extra safety".

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8244


From psadhukhan at openjdk.java.net  Fri Apr 15 06:17:43 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 15 Apr 2022 06:17:43 GMT
Subject: RFR: 8284884: Replace polling with waiting in
 javax/swing/text/html/parser/Parser/8078268/bug8078268.java [v2]
In-Reply-To: <AaMSO2hxsZdz2d9VsSdzPgBy4ke2K7xO_NUKkTIVuVE=.33813eab-0e20-49d9-9f54-0d5481791f68@github.com>
References: <ZzShBwEJLSeOoiFdyiUtYUOUMq2yOHaS_z-mkOcrHrs=.1b342753-44ec-4dcc-879a-3d6dabfe1824@github.com>
 <AaMSO2hxsZdz2d9VsSdzPgBy4ke2K7xO_NUKkTIVuVE=.33813eab-0e20-49d9-9f54-0d5481791f68@github.com>
Message-ID: <t0R7pQFCgNM2Ql_65NBFfaQFHDZJTWG7feBFnfnD57c=.2de534df-be5d-428b-aefe-f987e5bb816d@github.com>

On Thu, 14 Apr 2022 20:36:19 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> A quick fix for the `javax/swing/text/html/parser/Parser/8078268/bug8078268.java` which replaces `Thread.sleep` in a loop with `CountDownLatch.await`.
>> 
>> The code is shorter and clearer.
>> 
>> The test fails on the builds without the fix for [JDK-8078268](https://bugs.openjdk.java.net/browse/JDK-8078268). I ran it in the CI and it passes.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify filename handling

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8252


From psadhukhan at openjdk.java.net  Fri Apr 15 08:35:43 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 15 Apr 2022 08:35:43 GMT
Subject: Integrated: 8042380: Test
 javax/swing/JFileChooser/4524490/bug4524490.java fails with
 InvocationTargetException
In-Reply-To: <iwmtWKDSm1kLO6l4y8Yc7ulCL6Yb8Aw0Li072Vpb1UY=.4b3cca2e-8e90-42cb-bab9-1b83a8743033@github.com>
References: <iwmtWKDSm1kLO6l4y8Yc7ulCL6Yb8Aw0Li072Vpb1UY=.4b3cca2e-8e90-42cb-bab9-1b83a8743033@github.com>
Message-ID: <cilR-2QxTsaPjKfaYAkjdtYdDHjo_IqwIhZ4JbW-nX8=.f52bf5e5-00da-482d-84ff-42b5d3079a57@github.com>

On Fri, 15 Apr 2022 05:26:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test used to fail in nightly testing few years back and it seems it fails because we used to run in samevm mode at that time.
> Several iterations of this test pass in CI testing in all platforms (link in JBS) so removing from Problemlist.

This pull request has now been integrated.

Changeset: 510003cf
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/510003cfe33c34e62735c9fd49178d86b69b89ed
Stats:     2 lines in 2 files changed: 0 ins; 1 del; 1 mod

8042380: Test javax/swing/JFileChooser/4524490/bug4524490.java fails with InvocationTargetException

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8257


From psadhukhan at openjdk.java.net  Fri Apr 15 10:06:21 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 15 Apr 2022 10:06:21 GMT
Subject: RFR: 8266246: Swing test PressedIconTest.java sometimes fails on macOS
 11 ARM
Message-ID: <q1SN67zcbRVAI3f85u2FCXSc_5-As_Ex50ytDFvXNN0=.bbf645ad-514d-45b2-bf12-3ab7f58b4291@github.com>

javax/swing/JButton/8151303/PressedIconTest.java was failing few times in macos M1 system owing t color profile issue.

java.lang.RuntimeException: Colors are different!
at PressedIconTest.main(PressedIconTest.java:88) 


Test is now passing in all mac M1 systems in CI (link in jBS) so can be removed from problemlist.

-------------

Commit messages:
 - 8266246: Swing test PressedIconTest.java sometimes fails on macOS 11 ARM

Changes: https://git.openjdk.java.net/jdk/pull/8261/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8261&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266246
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8261.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8261/head:pull/8261

PR: https://git.openjdk.java.net/jdk/pull/8261


From duke at openjdk.java.net  Fri Apr 15 13:47:40 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Fri, 15 Apr 2022 13:47:40 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable
In-Reply-To: <zfQQvk5LZ4fCIfoIZFBUjBcvPX2J6_Pa4A1KjGe2nhg=.29b270d9-3599-4f82-a69b-fc7dd3210d4f@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <uksHJqxb2IOTEeiGv1bGVuYlR1vpYwchxNpPKsxnIMA=.a4c5938e-457f-4238-9962-634abcc6a9d0@github.com>
 <zfQQvk5LZ4fCIfoIZFBUjBcvPX2J6_Pa4A1KjGe2nhg=.29b270d9-3599-4f82-a69b-fc7dd3210d4f@github.com>
Message-ID: <QSBRL0wFUJe_ClWr0TOwOMqi-JpvGCbsGgmFkt-MdzE=.34d57b2f-9e6f-430e-9e55-c798aa8cedf8@github.com>

On Mon, 21 Feb 2022 12:16:53 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> I've stared at the javadoc for Class.isAssignableFrom and Class.isInstance and if a non-null instance is used to get a non-null class they are PROBABLY the same but it is far from clear. The implementations of both are at least native and may be instrinsicified. The doc for Class.isAssignableFrom cites JLS 5.1.4 which in what I found is about primitives so I suspect it is woefully out of date 
>> https://docs.oracle.com/javase/specs/jls/se17/html/jls-5.html#jls-5.1.4
>> 
>> What client tests have you run that touch the code you are changing ?
>> 
>> In short I see insufficient value in the changes here and would prefer you drop the client part so I don't have to worry about it.
>
>>In short I see insufficient value in the changes here and would prefer you drop the client part so I don't have to worry about it.
> 
> I think, usage of `isInstance` is much clear for most java developers. Everyone knows about java _instanceof_ operator. And `isInstance` method javadoc is very straight forward: `This method is the dynamic equivalent of the Java language instanceof operator.`
> 
> Method `isAssignableFrom` is opposite: it brings unnecessary complexity in the code. And it's easy to confuse orders of parameters. Even JBS confirms that:
> 1. [Wrong isAssignableFrom test when adding Principal to Subject ](https://bugs.openjdk.java.net/browse/JDK-8034820)
> 2. [isAssignableFrom checks in KeyFactorySpi.engineGetKeySpec appear to be backwards](https://bugs.openjdk.java.net/browse/JDK-8254717)
> 3. [isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards](https://bugs.openjdk.java.net/browse/JDK-8279800)
> 
> So, it gives all 3 points to prefer isInstance method: it's shorter, it's clearer for most java developers, it's faster.

> @turbanoff
> > Method `isAssignableFrom` is opposite: it brings unnecessary complexity in the code. And it's easy to confuse orders of parameters. Even JBS confirms that:
> 
> Maybe we should add `Class::isSubclassOf(Class<?> that)` that performs `that.isAssignableFrom(this)`:

I?have?opened [JI?9073064](https://bugs.openjdk.java.net/browse/JI-9073064 "[JI?9073064] Add?the?method `Class::isSublassOf(Class<?>)` to?`java.lang.Class` that?does the?inverse of?`Class::isAssignableFrom`") for?this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7061


From aivanov at openjdk.java.net  Fri Apr 15 13:57:44 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 15 Apr 2022 13:57:44 GMT
Subject: Integrated: 8284884: Replace polling with waiting in
 javax/swing/text/html/parser/Parser/8078268/bug8078268.java
In-Reply-To: <ZzShBwEJLSeOoiFdyiUtYUOUMq2yOHaS_z-mkOcrHrs=.1b342753-44ec-4dcc-879a-3d6dabfe1824@github.com>
References: <ZzShBwEJLSeOoiFdyiUtYUOUMq2yOHaS_z-mkOcrHrs=.1b342753-44ec-4dcc-879a-3d6dabfe1824@github.com>
Message-ID: <8SkRENPAWCfWSWhE7PVDdnAzvJIJ8ew67U40yF8W0ws=.08d3d037-65a8-424d-b9e9-93c2af9b1d4f@github.com>

On Thu, 14 Apr 2022 20:25:56 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> A quick fix for the `javax/swing/text/html/parser/Parser/8078268/bug8078268.java` which replaces `Thread.sleep` in a loop with `CountDownLatch.await`.
> 
> The code is shorter and clearer.
> 
> The test fails on the builds without the fix for [JDK-8078268](https://bugs.openjdk.java.net/browse/JDK-8078268). I ran it in the CI and it passes.

This pull request has now been integrated.

Changeset: 53580b33
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/53580b336ac83addfaf20763e37781cebec7c531
Stats:     27 lines in 1 file changed: 10 ins; 8 del; 9 mod

8284884: Replace polling with waiting in javax/swing/text/html/parser/Parser/8078268/bug8078268.java

Reviewed-by: serb, psadhukhan

-------------

PR: https://git.openjdk.java.net/jdk/pull/8252


From aivanov at openjdk.java.net  Fri Apr 15 14:35:56 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 15 Apr 2022 14:35:56 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v5]
In-Reply-To: <K_RQ5rxh68N4FeYHoM5O3wJ6Vv0omh0VR_Z_uaUBciQ=.bdd3af1a-2309-4408-8c1f-0329c1d1fc47@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <bFJoKiD6n9BimxrGVu8lNW-m3RswKRF_hGhfU905VMs=.94c9f727-2afc-4dde-ab57-f5737d9a034b@github.com>
 <K_RQ5rxh68N4FeYHoM5O3wJ6Vv0omh0VR_Z_uaUBciQ=.bdd3af1a-2309-4408-8c1f-0329c1d1fc47@github.com>
Message-ID: <UrkBLvIwRAOkv9tqYWYXZ9FSjrsZonKYH4GgeDhnkZg=.dde8dc96-b5d8-46d8-9fc1-8cc779af2d51@github.com>

On Fri, 15 Apr 2022 01:18:58 GMT, Phil Race <prr at openjdk.org> wrote:

> but what happens if a user pastes
> a few lines of text from windows Notepad - and it contains \r\n ?

This is handled: The text is converted by `PasteAction` somehow, the model contains only `\n` as the result.

If it weren't handled, there would be bug reports about this.

`JTextField` filters out all line breaks on clipboard, they're replaced with spaces on paste.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8122


From aivanov at openjdk.java.net  Fri Apr 15 16:39:44 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 15 Apr 2022 16:39:44 GMT
Subject: RFR: 8159599: [TEST_BUG]
 java/awt/Modal/ModalInternalFrameTest/ModalInternalFrameTest.java
In-Reply-To: <YK4XPjlYqSfUNstD5kB6NjU0kJIIC8IS_YejaCPqC34=.5060adf2-a9e9-4e79-a542-a93c6177599f@github.com>
References: <YK4XPjlYqSfUNstD5kB6NjU0kJIIC8IS_YejaCPqC34=.5060adf2-a9e9-4e79-a542-a93c6177599f@github.com>
Message-ID: <Dr8AZnvDbv_vlpOw8ME_BUjEJ-rwaF9IMJjXqY9CxzQ=.59184afa-edf1-404f-8cca-5883db39e989@github.com>

On Thu, 14 Apr 2022 14:22:18 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The SimpleWindowActivationTest test does not fail even without modifications(multiple CI test runs are green).
> So just remove it from ProblemList would be enough.
> 
> However I did some clean up and added some delays for  "extra safety".

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8244


From prr at openjdk.java.net  Fri Apr 15 16:40:41 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 15 Apr 2022 16:40:41 GMT
Subject: RFR: 8180276: JTextPane getText return extra when mixed with
 methods of Document [v5]
In-Reply-To: <bFJoKiD6n9BimxrGVu8lNW-m3RswKRF_hGhfU905VMs=.94c9f727-2afc-4dde-ab57-f5737d9a034b@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
 <bFJoKiD6n9BimxrGVu8lNW-m3RswKRF_hGhfU905VMs=.94c9f727-2afc-4dde-ab57-f5737d9a034b@github.com>
Message-ID: <5MgfAceJbrEAjFsR_th5s_QvstoCkqaoEdr4pOMVYAI=.c485b5cd-7ebc-4e11-8223-c5b0eb2be42a@github.com>

On Fri, 8 Apr 2022 12:17:37 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> getText function returned extra endOfLine when appended. The reason was in `EditorEditorKit` class, `write(Writer out, Document doc, int pos, int len)` method, where translation happens from buffer to Out(Writer Object) if endOfLine is other than '\n' ( which is '\r\n' in windows). In order to write each line till End of line, the string till '\n' is written including '\r' and again endOfLine is written which results in extra Carriage Return. To solve this issue, a Condition is added which checks if previous character to '\n' is '\r', if true then whole string except Carriage Return ('\r') is written, else whole string till before '\n' is written.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on Review Comments

Well then, let's close this out as not an issue and use the new JBS issue you created to update the docs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8122


From achung at openjdk.java.net  Fri Apr 15 18:01:11 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Fri, 15 Apr 2022 18:01:11 GMT
Subject: RFR: 8198622: java/awt/Focus/TypeAhead/TestFocusFreeze.java fails on
 mac
Message-ID: <8guUkZCRSqeoI9P6-bxBTJjWgQuw_nQbLcfuUeUv3MA=.0fffd884-dff4-4bdc-a522-be7cf921a72c@github.com>

test passes, so removing from problem list

-------------

Commit messages:
 - remove test from ProblemList

Changes: https://git.openjdk.java.net/jdk/pull/8254/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8254&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8198622
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8254.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8254/head:pull/8254

PR: https://git.openjdk.java.net/jdk/pull/8254


From prr at openjdk.java.net  Fri Apr 15 18:07:43 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 15 Apr 2022 18:07:43 GMT
Subject: Integrated: 8283704: Add sealed modifier to
 java.awt.MultipleGradientPaint
In-Reply-To: <lF7oZR5JgTFhOkiNkOKDNg4u_bxta0Tf-F1KlgJxrzo=.84cead53-1457-4f15-a012-6cfc9f51975c@github.com>
References: <lF7oZR5JgTFhOkiNkOKDNg4u_bxta0Tf-F1KlgJxrzo=.84cead53-1457-4f15-a012-6cfc9f51975c@github.com>
Message-ID: <JR9mkYsT8k3Y6DJ41sdj3tQSVuoS9DLUdY7LKWz0lVA=.762bcd4d-ac0f-407b-9591-2bbe2382448d@github.com>

On Fri, 1 Apr 2022 19:18:39 GMT, Phil Race <prr at openjdk.org> wrote:

> Along the same lines as other recent additions of the sealed modifier but this one is quite simple.
> Only MultiGradientPaint is touched. The two extant sub-classes it permits are already final
> 
> CSR for review : https://bugs.openjdk.java.net/browse/JDK-8284188
> 
> jtreg and JCK API tests pass

This pull request has now been integrated.

Changeset: 9f97f5de
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9f97f5de684588be6caf0f0ababe5fe773b13d77
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8283704: Add sealed modifier to java.awt.MultipleGradientPaint

Reviewed-by: darcy, serb, aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/8079


From prr at openjdk.java.net  Fri Apr 15 18:20:38 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 15 Apr 2022 18:20:38 GMT
Subject: RFR: 8266246: Swing test PressedIconTest.java sometimes fails on
 macOS 11 ARM
In-Reply-To: <q1SN67zcbRVAI3f85u2FCXSc_5-As_Ex50ytDFvXNN0=.bbf645ad-514d-45b2-bf12-3ab7f58b4291@github.com>
References: <q1SN67zcbRVAI3f85u2FCXSc_5-As_Ex50ytDFvXNN0=.bbf645ad-514d-45b2-bf12-3ab7f58b4291@github.com>
Message-ID: <X1UxOY6uVuBKeDbPUletALYWT-drpc6UjEHgh4LITPw=.92d01d3b-f3cc-4668-a772-d5c7d8558dc5@github.com>

On Fri, 15 Apr 2022 09:57:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javax/swing/JButton/8151303/PressedIconTest.java was failing few times in macos M1 system owing t color profile issue.
> 
> java.lang.RuntimeException: Colors are different!
> at PressedIconTest.main(PressedIconTest.java:88) 
> 
> 
> Test is now passing in all mac M1 systems in CI (link in jBS) so can be removed from problemlist.

Are you sure that was the issue ? I submitted this as an intermittent issue about a year ago and I'm sure that
the color profile wasn't being toggled on every run.
I think you'd have to run the test 100 times so be reasonably sure.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8261


From prr at openjdk.java.net  Fri Apr 15 18:26:40 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 15 Apr 2022 18:26:40 GMT
Subject: RFR: 8198622: java/awt/Focus/TypeAhead/TestFocusFreeze.java fails
 on mac
In-Reply-To: <8guUkZCRSqeoI9P6-bxBTJjWgQuw_nQbLcfuUeUv3MA=.0fffd884-dff4-4bdc-a522-be7cf921a72c@github.com>
References: <8guUkZCRSqeoI9P6-bxBTJjWgQuw_nQbLcfuUeUv3MA=.0fffd884-dff4-4bdc-a522-be7cf921a72c@github.com>
Message-ID: <N4k6-YzFhQS7GM1jEFnNHlUs4oM6AHMxbONihKjhwY8=.57a8374d-9be0-4057-a576-71134ef07e9e@github.com>

On Thu, 14 Apr 2022 21:12:07 GMT, Alisen Chung <achung at openjdk.org> wrote:

> test passes, so removing from problem list

Hmm .. so no idea why it passes now ? 4 years since this bug was filed but the info then was minimal. 
Can you see if it reproduces with JDK 11 ? If "it fails", then try later JDKs one by one until you find what fixed it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8254


From prr at openjdk.java.net  Fri Apr 15 18:30:40 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 15 Apr 2022 18:30:40 GMT
Subject: RFR: 8284699: Include all image types to the
 J2DBench.ColorConvertOpTests
In-Reply-To: <O-4c9xSYGjJFJRhpCFMdc6lgYhMV4fW0rdXTqOE7XS4=.51f30de9-4efa-4f86-818e-daa2663214ee@github.com>
References: <O-4c9xSYGjJFJRhpCFMdc6lgYhMV4fW0rdXTqOE7XS4=.51f30de9-4efa-4f86-818e-daa2663214ee@github.com>
Message-ID: <GwJyGonAM8cu8XO74YQtTQ0SNXCUurWAk0DDIcqhfF4=.79ad5a64-c70e-4005-ba62-cf82a7db3c00@github.com>

On Mon, 11 Apr 2022 21:06:08 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The J2DBench.ColorConvertOp tests are used to track the performance of the littlecms library in the JDK. The new version of the littlecms will add support for the premultiplied alpha. But right now the J2DBench does not test the pre-alpha formats, so I have added all standard types we have.
> 
> FYI: I have tested all combinations of these flags w/o issues.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8188


From prr at openjdk.java.net  Fri Apr 15 18:46:40 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 15 Apr 2022 18:46:40 GMT
Subject: RFR: 8284680: sun.font.FontConfigManager.getFontConfig() leaks
 charset
In-Reply-To: <MgzLHY7B6i7YyEzX8rkn-cEdkDamqKvNofwkrf1JIKI=.72ba1959-fe21-4f4e-a346-0feb5ae4037c@github.com>
References: <MgzLHY7B6i7YyEzX8rkn-cEdkDamqKvNofwkrf1JIKI=.72ba1959-fe21-4f4e-a346-0feb5ae4037c@github.com>
Message-ID: <bIZYEobkONaW5kpYH0AxKNH4IMySq_ddVGkt9tE-GnM=.863c3f13-3188-4be0-8e20-d92822ed4554@github.com>

On Mon, 11 Apr 2022 18:05:09 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this small patch that releases temporary charsets to avoid memory leak.
> 
> Test:
> 
> - [x] jdk_2d

src/java.desktop/unix/native/common/awt/fontpath.c line 1112:

> 1110:                     if (currentUnionSet != charset) {
> 1111:                         (*FcCharSetDestroy)(currentUnionSet);
> 1112:                     }

Hmm. I worry that you may be replacing a leak with a crash.
The original "charset" was returned from FcPatternGetCharSet() and I don't think it was a copy and will be freed when the pattern is destroyed.
So that should not be freed here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8187


From azvegint at openjdk.java.net  Sat Apr 16 09:55:37 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Sat, 16 Apr 2022 09:55:37 GMT
Subject: Integrated: 8159599: [TEST_BUG]
 java/awt/Modal/ModalInternalFrameTest/ModalInternalFrameTest.java
In-Reply-To: <YK4XPjlYqSfUNstD5kB6NjU0kJIIC8IS_YejaCPqC34=.5060adf2-a9e9-4e79-a542-a93c6177599f@github.com>
References: <YK4XPjlYqSfUNstD5kB6NjU0kJIIC8IS_YejaCPqC34=.5060adf2-a9e9-4e79-a542-a93c6177599f@github.com>
Message-ID: <sp57Ngmo6GOoerFB5fWvYyQUkZCM2VvuND9JTNs_yOQ=.d88e6347-4b28-47ad-b804-a1201ede1c34@github.com>

On Thu, 14 Apr 2022 14:22:18 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The SimpleWindowActivationTest test does not fail even without modifications(multiple CI test runs are green).
> So just remove it from ProblemList would be enough.
> 
> However I did some clean up and added some delays for  "extra safety".

This pull request has now been integrated.

Changeset: f5beafa5
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f5beafa53f93a6ec03278dfd7063d7b3b0b9d241
Stats:     23 lines in 2 files changed: 13 ins; 3 del; 7 mod

8159599: [TEST_BUG] java/awt/Modal/ModalInternalFrameTest/ModalInternalFrameTest.java

Reviewed-by: serb, aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/8244


From azvegint at openjdk.java.net  Sat Apr 16 10:05:32 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Sat, 16 Apr 2022 10:05:32 GMT
Subject: Integrated: 8144030: [macosx] test
 java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails (again)
In-Reply-To: <Am6BMN4aKMiXkE2cJtjuHsjs_IEa2mC9HIZ8kb61kQ0=.52271f3c-9e74-425a-9bdd-b0f09ae63338@github.com>
References: <Am6BMN4aKMiXkE2cJtjuHsjs_IEa2mC9HIZ8kb61kQ0=.52271f3c-9e74-425a-9bdd-b0f09ae63338@github.com>
Message-ID: <xm_BwLhfPRX3WulpeBBUaAWUo8cwmSoMFErOshaJcgs=.c75de2d9-fe48-441f-8be9-fd987603af7f@github.com>

On Wed, 13 Apr 2022 21:28:35 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This test has two undecorated frames: 
> 
> 1. background, 300x300
> 2. shaped foreground, 200x200
> 
> After displaying this frames it tries to check color outside of shape but within frame 2 bounds.
> 
> Unfortunately, on Linux and macOS there is a shadow around the shaped frame:
> ![image](https://user-images.githubusercontent.com/77687766/163270586-8dd97e93-582f-481f-999d-f08d4aaafba1.png)
> (changed color to green to make it more noticeable).
> 
> One way to fix the test would be to add tolerance to color check.
> But with old check points blue color may vary in 222-255 range, which is a bit too much.
> 
> Instead of this I made this shaped window  the size of background window. 
> This allows us to move check points away from shape border and its shadow, but still be able to check whether shape is applied or not.
> 
> Testing is green on all platforms.

This pull request has now been integrated.

Changeset: e5041ae3
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e5041ae3d45b43be10d5da747d773882ebf0482b
Stats:     116 lines in 2 files changed: 44 ins; 28 del; 44 mod

8144030: [macosx] test java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails (again)

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8233


From aivanov at openjdk.java.net  Sat Apr 16 17:52:12 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Sat, 16 Apr 2022 17:52:12 GMT
Subject: RFR: 8284189: Replace usages of 'a the' in java.desktop
Message-ID: <GEeFsO6UCFVr_EI5oDxdC8cIFCLDSSRpuQDs4owG43M=.a17abdd1-8fc6-4729-8d78-32bf6d84ff4e@github.com>

Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?

I fixed a couple of other spelling mistakes.

-------------

Commit messages:
 - 8284189: Miscellaneous spelling fixes
 - 8284189: Drop unneeded comma
 - 8284189: Replace usages of 'the a' etc in java.desktop
 - 8284189: Replace usages of 'the a' etc in java.desktop
 - 8284189: Replace usages of 'the the' in java.desktop
 - 8284189: Replace usages of 'the the' in java.desktop
 - 8284189: Replace usages of 'the the' in java.desktop
 - 8284189: Replace usages of 'an? an?' in java.desktop
 - 8284189: Replace usages of 'an? an?' in java.desktop
 - 8284189: Replace usages of 'an a' in java.desktop
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/e5041ae3...cc5b0b5b

Changes: https://git.openjdk.java.net/jdk/pull/8274/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8274&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284189
  Stats: 395 lines in 39 files changed: 196 ins; 48 del; 151 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8274.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8274/head:pull/8274

PR: https://git.openjdk.java.net/jdk/pull/8274


From philip.race at oracle.com  Sat Apr 16 22:06:40 2022
From: philip.race at oracle.com (Philip Race)
Date: Sat, 16 Apr 2022 15:06:40 -0700
Subject: Client-Libs Wiki page on writing regression tests
Message-ID: <ea40b47e-3f2d-63da-6a26-ab4f7ecf3189@oracle.com>


I have added a sub-page to the client-libs OpenJDK wiki on writing jtreg 
tests.

https://wiki.openjdk.java.net/display/ClientLibs/Creating+Client+jtreg+tests

A good part of it is about stable automated tests. I'm sure there are 
things I forgot to say.
Please look at it and if there any specific suggestions for corrections 
or additional content
please send them to me. Small and specific is better.

Or even better remember ANY member of the client-lib group [1] can edit 
this themselves ..

-phil.

[1] https://openjdk.java.net/census#client-libs




From prr at openjdk.java.net  Sat Apr 16 22:54:40 2022
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 16 Apr 2022 22:54:40 GMT
Subject: RFR: 8284898 : Enhance PassFailJFrame [v7]
In-Reply-To: <3EmU2J5RtgVxJUd0q8x16cb0DI1nj6jPbaswnaiudMg=.509ddf8b-401b-450a-93a6-da64b94bfb2b@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
 <3EmU2J5RtgVxJUd0q8x16cb0DI1nj6jPbaswnaiudMg=.509ddf8b-401b-450a-93a6-da64b94bfb2b@github.com>
Message-ID: <TIR7ENECF_DZBDZh62nyB9oDPG914LagW8zOOwwg4lw=.1b6c1473-6640-4bff-93b5-81dd5aa673e3@github.com>

On Thu, 14 Apr 2022 23:45:28 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> Fixed the following issue.
>> 1) Removed yes/no since test was failing due to "Parser error due to yesno in @run main/manual=yesno"
>> 2) After removing yes/no test run( just shows the UI and gets dispose immediately). User cannot interact with the test UI and mark the test pass or failed. 
>> So added Pass and Fail button to mark the test result.
>> 3) Added timeout if in case user does not interact with the test UI.
>> 
>> @shurymury 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update PrintGlyphVectorTest.java

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 311:

> 309:     /**
> 310:      *  Forcibly pass the test.
> 311:      */

you mean fail.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8004


From duke at openjdk.java.net  Sat Apr 16 23:02:13 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Sat, 16 Apr 2022 23:02:13 GMT
Subject: RFR: 8284898 : Enhance PassFailJFrame [v8]
In-Reply-To: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
Message-ID: <XftwO5PFc8tGB_pUJ0iFssgl7Ctt2iWyHs5X2yv_5AE=.d7effd3d-9f54-450e-9058-71110ec38442@github.com>

> Fixed the following issue.
> 1) Removed yes/no since test was failing due to "Parser error due to yesno in @run main/manual=yesno"
> 2) After removing yes/no test run( just shows the UI and gets dispose immediately). User cannot interact with the test UI and mark the test pass or failed. 
> So added Pass and Fail button to mark the test result.
> 3) Added timeout if in case user does not interact with the test UI.
> 
> @shurymury 
> @aivanov-jdk

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  Update PassFailJFrame.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8004/files
  - new: https://git.openjdk.java.net/jdk/pull/8004/files/e891ed17..0d971ba3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8004&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8004&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8004.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8004/head:pull/8004

PR: https://git.openjdk.java.net/jdk/pull/8004


From prr at openjdk.java.net  Sat Apr 16 23:02:15 2022
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 16 Apr 2022 23:02:15 GMT
Subject: RFR: 8284898 : Enhance PassFailJFrame [v7]
In-Reply-To: <3EmU2J5RtgVxJUd0q8x16cb0DI1nj6jPbaswnaiudMg=.509ddf8b-401b-450a-93a6-da64b94bfb2b@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
 <3EmU2J5RtgVxJUd0q8x16cb0DI1nj6jPbaswnaiudMg=.509ddf8b-401b-450a-93a6-da64b94bfb2b@github.com>
Message-ID: <bko9Ay4eDcJjTxEgRQRSI4dQzpMsE_9f0Ri6-gbg-Aw=.00fc7e9c-f7af-4de0-9fd8-28c34569464d@github.com>

On Thu, 14 Apr 2022 23:45:28 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> Fixed the following issue.
>> 1) Removed yes/no since test was failing due to "Parser error due to yesno in @run main/manual=yesno"
>> 2) After removing yes/no test run( just shows the UI and gets dispose immediately). User cannot interact with the test UI and mark the test pass or failed. 
>> So added Pass and Fail button to mark the test result.
>> 3) Added timeout if in case user does not interact with the test UI.
>> 
>> @shurymury 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update PrintGlyphVectorTest.java

Approving since I think the minor things I pointed out aren't problems for the test

test/jdk/java/awt/print/PrinterJob/PrintGlyphVectorTest.java line 131:

> 129:         PrinterJob pj = PrinterJob.getPrinterJob();
> 130:         if (pj == null || pj.getPrintService() == null) {
> 131:             System.out.println("Printer not configured or available."

I realise the test was already doing the pj == null check but per. the spec, this shouldn't happen
https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/print/PrinterJob.html#getPrinterJob()

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8004


From duke at openjdk.java.net  Sat Apr 16 23:02:16 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Sat, 16 Apr 2022 23:02:16 GMT
Subject: RFR: 8284898 : Enhance PassFailJFrame [v7]
In-Reply-To: <TIR7ENECF_DZBDZh62nyB9oDPG914LagW8zOOwwg4lw=.1b6c1473-6640-4bff-93b5-81dd5aa673e3@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
 <3EmU2J5RtgVxJUd0q8x16cb0DI1nj6jPbaswnaiudMg=.509ddf8b-401b-450a-93a6-da64b94bfb2b@github.com>
 <TIR7ENECF_DZBDZh62nyB9oDPG914LagW8zOOwwg4lw=.1b6c1473-6640-4bff-93b5-81dd5aa673e3@github.com>
Message-ID: <69jbypffQDINWAazLh8r4Vtushcwi14v7uJk0eygeqg=.b3ccbbbb-288e-4087-a906-6b9b2df3ea62@github.com>

On Sat, 16 Apr 2022 22:51:43 GMT, Phil Race <prr at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update PrintGlyphVectorTest.java
>
> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 311:
> 
>> 309:     /**
>> 310:      *  Forcibly pass the test.
>> 311:      */
> 
> you mean fail.

Yes, I was meant to fail. Let me correct it.
Thanks! for catching. I had fixed this but mostly forget to commit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8004


From aivanov at openjdk.java.net  Sun Apr 17 22:09:42 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Sun, 17 Apr 2022 22:09:42 GMT
Subject: RFR: 8284898 : Enhance PassFailJFrame [v8]
In-Reply-To: <XftwO5PFc8tGB_pUJ0iFssgl7Ctt2iWyHs5X2yv_5AE=.d7effd3d-9f54-450e-9058-71110ec38442@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
 <XftwO5PFc8tGB_pUJ0iFssgl7Ctt2iWyHs5X2yv_5AE=.d7effd3d-9f54-450e-9058-71110ec38442@github.com>
Message-ID: <B-RcMd7QgxnkSKzWqAR68xLbXy6YEjBZFQvw5TgDK0M=.c6551c3e-1674-415a-bcdd-1d612ee45d18@github.com>

On Sat, 16 Apr 2022 23:02:13 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> Fixed the following issue.
>> 1) Removed yes/no since test was failing due to "Parser error due to yesno in @run main/manual=yesno"
>> 2) After removing yes/no test run( just shows the UI and gets dispose immediately). User cannot interact with the test UI and mark the test pass or failed. 
>> So added Pass and Fail button to mark the test result.
>> 3) Added timeout if in case user does not interact with the test UI.
>> 
>> @shurymury 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update PassFailJFrame.java

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 54:

> 52:     private static final int COLUMNS = 40;
> 53:     private static final long TEST_TIMEOUT = 5;
> 54:     private static final String TITLE = "Test Instruction Frame";

Please put the constants above the latch and separate them with a blank line.

I'd put the constants in the order of parameters: title, timeout, rows, columns.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 89:

> 87:      *
> 88:      * @param title                title of the Frame.
> 89:      * @param instructions         instruction for the tester on how to test and what

_the instructions_ for the tester?

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 104:

> 102:             InvocationTargetException {
> 103:         if (isEventDispatchThread()) {
> 104:             createUI(title, instructions, testTimeOutInMinutes, rows, columns);

Does it make sense to use shorter version like `testTimeout` or `timeout` instead of longer `testTimeoutInMinutes`?

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 193:

> 191:      * @throws InterruptedException      exception thrown when thread is
> 192:      *                                   interrupted
> 193:      * @throws InvocationTargetException exception thrown while creating UI

_?Exception exception_ doesn't look good.

In the rendered javadoc it reads like: throws `InterruptedException` ... (followed by text). The text usually starts with the word *if* followed by the condition when the exception is thrown.

The first item was documented in a usual way. The second one should look something like: _if an exception is thrown while disposing of frames on EDT._

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 313:

> 311:      */
> 312:     public static void forceFail() {
> 313:         latch.countDown();

You must set `failed` to `true`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8004


From aivanov at openjdk.java.net  Sun Apr 17 22:09:43 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Sun, 17 Apr 2022 22:09:43 GMT
Subject: RFR: 8284898 : Enhance PassFailJFrame [v7]
In-Reply-To: <bko9Ay4eDcJjTxEgRQRSI4dQzpMsE_9f0Ri6-gbg-Aw=.00fc7e9c-f7af-4de0-9fd8-28c34569464d@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
 <3EmU2J5RtgVxJUd0q8x16cb0DI1nj6jPbaswnaiudMg=.509ddf8b-401b-450a-93a6-da64b94bfb2b@github.com>
 <bko9Ay4eDcJjTxEgRQRSI4dQzpMsE_9f0Ri6-gbg-Aw=.00fc7e9c-f7af-4de0-9fd8-28c34569464d@github.com>
Message-ID: <_Az-bEhHlGsNoccQhAlllq0OxNBZR9D4LLV4sDDipGU=.ba603986-b8f8-45da-82f6-99b3838fa8ef@github.com>

On Sat, 16 Apr 2022 22:54:43 GMT, Phil Race <prr at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update PrintGlyphVectorTest.java
>
> test/jdk/java/awt/print/PrinterJob/PrintGlyphVectorTest.java line 131:
> 
>> 129:         PrinterJob pj = PrinterJob.getPrinterJob();
>> 130:         if (pj == null || pj.getPrintService() == null) {
>> 131:             System.out.println("Printer not configured or available."
> 
> I realise the test was already doing the pj == null check but per. the spec, this shouldn't happen
> https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/print/PrinterJob.html#getPrinterJob()

Right, and IDE generates a warning: _`pj == null` is always false_. I suggest removing this condition and thus resolving the warning.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8004


From aivanov at openjdk.java.net  Sun Apr 17 22:09:43 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Sun, 17 Apr 2022 22:09:43 GMT
Subject: RFR: 8284898 : Enhance PassFailJFrame [v7]
In-Reply-To: <_Az-bEhHlGsNoccQhAlllq0OxNBZR9D4LLV4sDDipGU=.ba603986-b8f8-45da-82f6-99b3838fa8ef@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
 <3EmU2J5RtgVxJUd0q8x16cb0DI1nj6jPbaswnaiudMg=.509ddf8b-401b-450a-93a6-da64b94bfb2b@github.com>
 <bko9Ay4eDcJjTxEgRQRSI4dQzpMsE_9f0Ri6-gbg-Aw=.00fc7e9c-f7af-4de0-9fd8-28c34569464d@github.com>
 <_Az-bEhHlGsNoccQhAlllq0OxNBZR9D4LLV4sDDipGU=.ba603986-b8f8-45da-82f6-99b3838fa8ef@github.com>
Message-ID: <e2BLwSiAIL9tnVf11EcGOltkes44_8_gn4PTp7prkV8=.2eb3b423-aaf7-4364-a7c1-2adc7a919c9f@github.com>

On Sun, 17 Apr 2022 22:01:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/java/awt/print/PrinterJob/PrintGlyphVectorTest.java line 131:
>> 
>>> 129:         PrinterJob pj = PrinterJob.getPrinterJob();
>>> 130:         if (pj == null || pj.getPrintService() == null) {
>>> 131:             System.out.println("Printer not configured or available."
>> 
>> I realise the test was already doing the pj == null check but per. the spec, this shouldn't happen
>> https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/print/PrinterJob.html#getPrinterJob()
>
> Right, and IDE generates a warning: _`pj == null` is always false_. I suggest removing this condition and thus resolving the warning.

Just a bit of optimisation: you can postpone creating the test frame. The frame is not needed if the test passes because there's no print service.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8004


From aivanov at openjdk.java.net  Sun Apr 17 22:13:46 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Sun, 17 Apr 2022 22:13:46 GMT
Subject: RFR: 8284898 : Enhance PassFailJFrame [v8]
In-Reply-To: <XftwO5PFc8tGB_pUJ0iFssgl7Ctt2iWyHs5X2yv_5AE=.d7effd3d-9f54-450e-9058-71110ec38442@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
 <XftwO5PFc8tGB_pUJ0iFssgl7Ctt2iWyHs5X2yv_5AE=.d7effd3d-9f54-450e-9058-71110ec38442@github.com>
Message-ID: <pF9a9tL2hYrxjq0dZwbOSE58UQFLSNFI7_xFJlE2A6c=.4a4093cd-8ee5-4ae8-bf98-555a4a2e9422@github.com>

On Sat, 16 Apr 2022 23:02:13 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> Fixed the following issue.
>> 1) Removed yes/no since test was failing due to "Parser error due to yesno in @run main/manual=yesno"
>> 2) After removing yes/no test run( just shows the UI and gets dispose immediately). User cannot interact with the test UI and mark the test pass or failed. 
>> So added Pass and Fail button to mark the test result.
>> 3) Added timeout if in case user does not interact with the test UI.
>> 
>> @shurymury 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update PassFailJFrame.java

I think the main issue fixed should remain: _8283803: Remove jtreg tag manual=yesno for java/awt/print/PrinterJob/PrintGlyphVectorTest.java and fix test_ as it was originally.

The one that's main now: _8284898: Enhance PassFailJFrame_ should really be secondary.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8004


From aivanov at openjdk.java.net  Sun Apr 17 22:27:33 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Sun, 17 Apr 2022 22:27:33 GMT
Subject: RFR: 8284898 : Enhance PassFailJFrame [v8]
In-Reply-To: <XftwO5PFc8tGB_pUJ0iFssgl7Ctt2iWyHs5X2yv_5AE=.d7effd3d-9f54-450e-9058-71110ec38442@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
 <XftwO5PFc8tGB_pUJ0iFssgl7Ctt2iWyHs5X2yv_5AE=.d7effd3d-9f54-450e-9058-71110ec38442@github.com>
Message-ID: <E74cfXkjwRpwJeUVjYSWOgwTo9WkEKbAB1RHpr89VA4=.b3fe2c02-8f78-44af-92eb-c2ca3a2f6327@github.com>

On Sat, 16 Apr 2022 23:02:13 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> Fixed the following issue.
>> 1) Removed yes/no since test was failing due to "Parser error due to yesno in @run main/manual=yesno"
>> 2) After removing yes/no test run( just shows the UI and gets dispose immediately). User cannot interact with the test UI and mark the test pass or failed. 
>> So added Pass and Fail button to mark the test result.
>> 3) Added timeout if in case user does not interact with the test UI.
>> 
>> @shurymury 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update PassFailJFrame.java

Both modified files contain a couple of unused imports.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8004


From serb at openjdk.java.net  Mon Apr 18 03:38:39 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 18 Apr 2022 03:38:39 GMT
Subject: Integrated: 8284699: Include all image types to the
 J2DBench.ColorConvertOpTests
In-Reply-To: <O-4c9xSYGjJFJRhpCFMdc6lgYhMV4fW0rdXTqOE7XS4=.51f30de9-4efa-4f86-818e-daa2663214ee@github.com>
References: <O-4c9xSYGjJFJRhpCFMdc6lgYhMV4fW0rdXTqOE7XS4=.51f30de9-4efa-4f86-818e-daa2663214ee@github.com>
Message-ID: <WHWKmxhvWiIlN1BoXciVBgx6dwfDmuPEzKVlOX60ISI=.5dfc47fc-ab56-4c1f-b81d-33d9afb92591@github.com>

On Mon, 11 Apr 2022 21:06:08 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The J2DBench.ColorConvertOp tests are used to track the performance of the littlecms library in the JDK. The new version of the littlecms will add support for the premultiplied alpha. But right now the J2DBench does not test the pre-alpha formats, so I have added all standard types we have.
> 
> FYI: I have tested all combinations of these flags w/o issues.

This pull request has now been integrated.

Changeset: 21ea740e
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/21ea740e1da48054ee46efda493d0812a35d786e
Stats:     15 lines in 1 file changed: 11 ins; 1 del; 3 mod

8284699: Include all image types to the J2DBench.ColorConvertOpTests

Reviewed-by: prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/8188


From psadhukhan at openjdk.java.net  Mon Apr 18 04:16:36 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 18 Apr 2022 04:16:36 GMT
Subject: RFR: 8266246: Swing test PressedIconTest.java sometimes fails on
 macOS 11 ARM
In-Reply-To: <q1SN67zcbRVAI3f85u2FCXSc_5-As_Ex50ytDFvXNN0=.bbf645ad-514d-45b2-bf12-3ab7f58b4291@github.com>
References: <q1SN67zcbRVAI3f85u2FCXSc_5-As_Ex50ytDFvXNN0=.bbf645ad-514d-45b2-bf12-3ab7f58b4291@github.com>
Message-ID: <DIQ6AGN5fNj16QCh0nK2VXx_qVG21wP-2HJtOssjuvQ=.abce3c93-ec79-4592-b11e-70b0b091c8d9@github.com>

On Fri, 15 Apr 2022 09:57:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javax/swing/JButton/8151303/PressedIconTest.java was failing few times in macos M1 system owing t color profile issue.
> 
> java.lang.RuntimeException: Colors are different!
> at PressedIconTest.main(PressedIconTest.java:88) 
> 
> 
> Test is now passing in all mac M1 systems in CI (link in jBS) so can be removed from problemlist.

I have run the test 100 times and all are green. Test job link in JBS.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8261


From psadhukhan at openjdk.java.net  Mon Apr 18 04:17:39 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 18 Apr 2022 04:17:39 GMT
Subject: RFR: 7132796: [macosx]
 closed/javax/swing/JComboBox/4517214/bug4517214.java fails on MacOS
In-Reply-To: <DFryrg8OZJ22xBLpprcnD14oXkSjF57fQA3jdwTD2Ko=.0a3b8830-4d7e-4c7e-8c1f-2932cd7ca1a8@github.com>
References: <DFryrg8OZJ22xBLpprcnD14oXkSjF57fQA3jdwTD2Ko=.0a3b8830-4d7e-4c7e-8c1f-2932cd7ca1a8@github.com>
Message-ID: <b9nYu6F7tb0AE5Wa7V8CkITC2hsgCXE-aUumjo8AA3o=.4b998976-41b8-4864-9379-7a3b9e90e753@github.com>

On Thu, 14 Apr 2022 06:50:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> JDK-4517214 was fixed for Metal L&F where JComboBox having TitledBorder used to have double height compared to normal JComboBox.
> The issue is still observed for macos for Aqua L&F where still double height is seen.
> Fix is to prevent adding border insets height to combobox size as was done for [MetalComboxUI.getMinimumSize[](url)](https://github.com/openjdk/jdk/blame/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalComboBoxUI.java#L384)
> The closed test is automated and moved to open. CI testing on all platform is ok.

Any more comments on this @mrserb ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8237


From jdv at openjdk.java.net  Mon Apr 18 05:17:34 2022
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 18 Apr 2022 05:17:34 GMT
Subject: RFR: 8284189: Replace usages of 'a the' in java.desktop
In-Reply-To: <GEeFsO6UCFVr_EI5oDxdC8cIFCLDSSRpuQDs4owG43M=.a17abdd1-8fc6-4729-8d78-32bf6d84ff4e@github.com>
References: <GEeFsO6UCFVr_EI5oDxdC8cIFCLDSSRpuQDs4owG43M=.a17abdd1-8fc6-4729-8d78-32bf6d84ff4e@github.com>
Message-ID: <fiLm9NN-mzbgPqCmhKJYyUdkcRnkXMLG97xR1Pjptn0=.0d31ce70-4087-4cda-8999-08355b2e0877@github.com>

On Sat, 16 Apr 2022 17:45:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> I fixed a couple of other spelling mistakes.

src/java.desktop/share/classes/java/awt/Graphics.java line 29:

> 27: import java.io.*;
> 28: import java.lang.*;
> 29: import java.util.*;

Are these unused imports?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8274


From jdv at openjdk.java.net  Mon Apr 18 05:23:39 2022
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 18 Apr 2022 05:23:39 GMT
Subject: RFR: 8284189: Replace usages of 'a the' in java.desktop
In-Reply-To: <GEeFsO6UCFVr_EI5oDxdC8cIFCLDSSRpuQDs4owG43M=.a17abdd1-8fc6-4729-8d78-32bf6d84ff4e@github.com>
References: <GEeFsO6UCFVr_EI5oDxdC8cIFCLDSSRpuQDs4owG43M=.a17abdd1-8fc6-4729-8d78-32bf6d84ff4e@github.com>
Message-ID: <pZaCJNzXXtvGvo-4JEDtTwoKhEzAZ399UllVFwJ2uPM=.3154bc15-710c-439b-9e4e-16ad012e0205@github.com>

On Sat, 16 Apr 2022 17:45:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> I fixed a couple of other spelling mistakes.

This PR has a lot of other changes than just correcting spelling mistakes and a/an combinations.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8274


From duke at openjdk.java.net  Mon Apr 18 05:24:43 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Mon, 18 Apr 2022 05:24:43 GMT
Subject: Withdrawn: 8180276: JTextPane getText return extra when mixed with
 methods of Document
In-Reply-To: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
References: <Rae7AVto9nT_p7d_VZQxq-eLi_4EMloOepQXIXt_yhQ=.70de1d88-b1fc-4b7f-bf28-da3257d41ca3@github.com>
Message-ID: <YMzulcvGdSz0QjfCOJxVtMatDj4zTmOLm3-R2-aiBCc=.dd602fe1-e4f3-45a4-9111-357a5a5f0467@github.com>

On Wed, 6 Apr 2022 10:02:10 GMT, Tejesh R <duke at openjdk.java.net> wrote:

> getText function returned extra endOfLine when appended. The reason was in `EditorEditorKit` class, `write(Writer out, Document doc, int pos, int len)` method, where translation happens from buffer to Out(Writer Object) if endOfLine is other than '\n' ( which is '\r\n' in windows). In order to write each line till End of line, the string till '\n' is written including '\r' and again endOfLine is written which results in extra Carriage Return. To solve this issue, a Condition is added which checks if previous character to '\n' is '\r', if true then whole string except Carriage Return ('\r') is written, else whole string till before '\n' is written.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8122


From psadhukhan at openjdk.java.net  Mon Apr 18 07:19:02 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 18 Apr 2022 07:19:02 GMT
Subject: RFR: 8208565: [TEST_BUG]
 javax\swing\PopupFactory\6276087\NonOpaquePopupMenuTest.java throws NPE
Message-ID: <DmXd07y2BGuoEk_ocIftawU6FoCTUfzwmuaSxa9px2M=.018977f0-14c1-41f3-be46-a3d430b37773@github.com>

Test was failing in the past owing to NPE while accessing JMenu probably owing to fact the test did not wait for UI to be visible before starting the test, so added a delay after the frame is made visible. Also, added disposal of frame.
Also, it seems JDK-8213535 fix might be having a positive impact on this test.

Several iterations of this test in all platforms have passed (link in JBS).

-------------

Commit messages:
 - 8208565: [TEST_BUG] javax\swing\PopupFactory\6276087\NonOpaquePopupMenuTest.java throws NPE
 - 8208565: [TEST_BUG] javax\swing\PopupFactory\6276087\NonOpaquePopupMenuTest.java throws NPE

Changes: https://git.openjdk.java.net/jdk/pull/8282/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8282&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8208565
  Stats: 84 lines in 2 files changed: 27 ins; 30 del; 27 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8282.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8282/head:pull/8282

PR: https://git.openjdk.java.net/jdk/pull/8282


From jdv at openjdk.java.net  Mon Apr 18 08:27:35 2022
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 18 Apr 2022 08:27:35 GMT
Subject: RFR: 8266246: Swing test PressedIconTest.java sometimes fails on
 macOS 11 ARM
In-Reply-To: <DIQ6AGN5fNj16QCh0nK2VXx_qVG21wP-2HJtOssjuvQ=.abce3c93-ec79-4592-b11e-70b0b091c8d9@github.com>
References: <q1SN67zcbRVAI3f85u2FCXSc_5-As_Ex50ytDFvXNN0=.bbf645ad-514d-45b2-bf12-3ab7f58b4291@github.com>
 <DIQ6AGN5fNj16QCh0nK2VXx_qVG21wP-2HJtOssjuvQ=.abce3c93-ec79-4592-b11e-70b0b091c8d9@github.com>
Message-ID: <X69y6YeiJIZ3hMPvcJ2CR8wSuDxBXJBG71Z0EVTdyKw=.ce37b155-9c0f-4726-8bd7-30ce28441d74@github.com>

On Mon, 18 Apr 2022 04:12:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> javax/swing/JButton/8151303/PressedIconTest.java was failing few times in macos M1 system owing t color profile issue.
>> 
>> java.lang.RuntimeException: Colors are different!
>> at PressedIconTest.main(PressedIconTest.java:88) 
>> 
>> 
>> Test is now passing in all mac M1 systems in CI (link in jBS) so can be removed from problemlist.
>
> I have run the test 100 times and all are green. Test job link in JBS.

@prsadhuk Is latest CI test ran without JTREG_RETRY_COUNT? In intermittent cases it is better to run CI tests without retries.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8261


From psadhukhan at openjdk.java.net  Mon Apr 18 09:52:40 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 18 Apr 2022 09:52:40 GMT
Subject: RFR: 8266246: Swing test PressedIconTest.java sometimes fails on
 macOS 11 ARM
In-Reply-To: <q1SN67zcbRVAI3f85u2FCXSc_5-As_Ex50ytDFvXNN0=.bbf645ad-514d-45b2-bf12-3ab7f58b4291@github.com>
References: <q1SN67zcbRVAI3f85u2FCXSc_5-As_Ex50ytDFvXNN0=.bbf645ad-514d-45b2-bf12-3ab7f58b4291@github.com>
Message-ID: <BYNhltegtnywNanFNOWHuO7Eq22bFDhqkKe0T5e0cNE=.93ca5d28-38e7-4783-8f77-e04f317182f3@github.com>

On Fri, 15 Apr 2022 09:57:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javax/swing/JButton/8151303/PressedIconTest.java was failing few times in macos M1 system owing t color profile issue.
> 
> java.lang.RuntimeException: Colors are different!
> at PressedIconTest.main(PressedIconTest.java:88) 
> 
> 
> Test is now passing in all mac M1 systems in CI (link in jBS) so can be removed from problemlist.

Yes, same test with 100 iterations passes without JTREG_RETRY_COUNT too..

-------------

PR: https://git.openjdk.java.net/jdk/pull/8261


From dbatrak at openjdk.java.net  Mon Apr 18 10:00:39 2022
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Mon, 18 Apr 2022 10:00:39 GMT
Subject: RFR: 8185261: Font fallback sometimes doesn't work in Swing text
 components [v2]
In-Reply-To: <4SfhJKrUWWmdo2ZioTjqiU5b3a4cZBwWhMX89auZBRg=.5bf8b903-dbb2-4e7c-adaf-59c5e8212e72@github.com>
References: <5qQoyooaZzlKSp4iMudwLZ16MotrGrPB7GhQ3aAVYjo=.8e97ba6f-4aab-40d7-944f-4f68dc2b7b1c@github.com>
 <4SfhJKrUWWmdo2ZioTjqiU5b3a4cZBwWhMX89auZBRg=.5bf8b903-dbb2-4e7c-adaf-59c5e8212e72@github.com>
Message-ID: <oHkJ4IJlXQaj1AmZ10sYo5TD_ePdXZCurZcnB1bBAzs=.86eee7fa-51c2-4876-9c1c-cd51d08ccac1@github.com>

On Tue, 1 Feb 2022 21:40:53 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

>> The proposed fix makes fonts with and without fallback components distinguishable (in terms of `equals` method), so that
>> font metrics cache (and other similar code) can handle them separately. This is achieved by adding a new boolean field
>> to `Font` class, specifically denoting fonts with fallback components. The latter ones don't need to pretend to be
>> 'created' fonts anymore, to preserve their `Font2D` handle.
>> It's not possible to use the existing `createdFont` field in `equals` implementation, as JCK requires a 'real' created
>> font (the one obtained using `Font.createFont` method) to be equal to the same font after serialization and
>> deserialization.
>
> Dmitry Batrak has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove 'headful' requirement from test case

Still waiting for a response.

If you're not comfortable with changing `Font.equals` behaviour, let's introduce some other public method, which can be used to distinguish fonts with and without fallback components. I believe, it should be in public API, as the issue isn't just about JEditorPane (etc) implementation. Even though it's not a documented feature, client code can easily construct a font with fallback components using existing public API - one should just use `new javax.swing.text.StyleContext().getFont(family, style, size)` instead of `new java.awt.Font(family, style, size)`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7313


From aghaisas at openjdk.java.net  Mon Apr 18 11:39:40 2022
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 18 Apr 2022 11:39:40 GMT
Subject: RFR: 8283794: CCE in XRTextRenderer.drawGlyphList and
 XRMaskFill.MaskFill [v2]
In-Reply-To: <gw6R-Ys52b6soGAs2u7F6-7WiHOzduuG8jRQHs3xX90=.043d4630-576d-44e6-9fbf-b9b5e42aa8b6@github.com>
References: <GD4NAkuLptwylcQOI8VBAXXI1rY7ycgz8O2NvPmhIOc=.f2c8334e-d2eb-4717-92a1-de2f9ed301b6@github.com>
 <VE3eRPzRlyCMFgLc0XrQrvy2pgqszE6ZC3TG7fcDvz8=.5facf5d5-668b-4190-acbc-bb481524d1ac@github.com>
 <gw6R-Ys52b6soGAs2u7F6-7WiHOzduuG8jRQHs3xX90=.043d4630-576d-44e6-9fbf-b9b5e42aa8b6@github.com>
Message-ID: <DUAewBeEgdp4lPyzPkOHPTfKi97a6oosRpOC7kAsa78=.3739feac-debf-426d-8361-52b151a43685@github.com>

On Tue, 12 Apr 2022 04:15:56 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8283794: CCE in XRTextRenderer.drawGlyphList and XRMaskFill.MaskFill
>>   
>>   Extracted try/catch logic of SurfaceData cast to particular SurfaceData subclass into convenience method SurfaceData.convertTo(). Applied the method to XRTextRenderer.drawGlyphList() and XRMaskFill.MaskFill(). Refactored try/catch blocks handling similar cases.
>
> I am on vacation this week. I will review this PR on priority next week.

> Looks fine, I suggest checking the fix via mach5. @aghaisas please take a look.

The fix looks good. Also, the mach5 run is green with this change.
@avu, is it possible to add an automated test?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8015


From jdv at openjdk.java.net  Mon Apr 18 12:23:37 2022
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 18 Apr 2022 12:23:37 GMT
Subject: RFR: 8266246: Swing test PressedIconTest.java sometimes fails on
 macOS 11 ARM
In-Reply-To: <q1SN67zcbRVAI3f85u2FCXSc_5-As_Ex50ytDFvXNN0=.bbf645ad-514d-45b2-bf12-3ab7f58b4291@github.com>
References: <q1SN67zcbRVAI3f85u2FCXSc_5-As_Ex50ytDFvXNN0=.bbf645ad-514d-45b2-bf12-3ab7f58b4291@github.com>
Message-ID: <53azHsYF4UO7upBdRFxUDKdWpojLZ29722A9TNE9MR4=.eb7f98c9-a861-4fc6-a547-863123637aa3@github.com>

On Fri, 15 Apr 2022 09:57:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javax/swing/JButton/8151303/PressedIconTest.java was failing few times in macos M1 system owing t color profile issue.
> 
> java.lang.RuntimeException: Colors are different!
> at PressedIconTest.main(PressedIconTest.java:88) 
> 
> 
> Test is now passing in all mac M1 systems in CI (link in jBS) so can be removed from problemlist.

Marked as reviewed by jdv (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8261


From jdv at openjdk.java.net  Mon Apr 18 12:45:33 2022
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 18 Apr 2022 12:45:33 GMT
Subject: RFR: 8198622: java/awt/Focus/TypeAhead/TestFocusFreeze.java fails
 on mac
In-Reply-To: <8guUkZCRSqeoI9P6-bxBTJjWgQuw_nQbLcfuUeUv3MA=.0fffd884-dff4-4bdc-a522-be7cf921a72c@github.com>
References: <8guUkZCRSqeoI9P6-bxBTJjWgQuw_nQbLcfuUeUv3MA=.0fffd884-dff4-4bdc-a522-be7cf921a72c@github.com>
Message-ID: <L29Ji7zb_XLSW3w_Hp3ltj3BItqelr5RaktBJaQjeuI=.87750728-01e0-464e-9294-10174ebfdc09@github.com>

On Thu, 14 Apr 2022 21:12:07 GMT, Alisen Chung <achung at openjdk.org> wrote:

> test passes, so removing from problem list

We should add https://bugs.openjdk.java.net/browse/JDK-6447537 also in the PR and decouple test/java/awt/KeyboardFocusmanager/TypeAhead/EnqueueWithDialogTest failure into new bug. https://bugs.openjdk.java.net/browse/JDK-8198622 captures failure only specific to macOS.

https://bugs.openjdk.java.net/browse/JDK-6447537 captures history of why this test started failing in Windows & Linux which might give idea about how it is not failing now. Also its better to run the test multiple times since we are de-problem listing on all platforms.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8254


From aivanov at openjdk.java.net  Mon Apr 18 12:59:43 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 18 Apr 2022 12:59:43 GMT
Subject: RFR: 8284189: Replace usages of 'a the' in java.desktop
In-Reply-To: <fiLm9NN-mzbgPqCmhKJYyUdkcRnkXMLG97xR1Pjptn0=.0d31ce70-4087-4cda-8999-08355b2e0877@github.com>
References: <GEeFsO6UCFVr_EI5oDxdC8cIFCLDSSRpuQDs4owG43M=.a17abdd1-8fc6-4729-8d78-32bf6d84ff4e@github.com>
 <fiLm9NN-mzbgPqCmhKJYyUdkcRnkXMLG97xR1Pjptn0=.0d31ce70-4087-4cda-8999-08355b2e0877@github.com>
Message-ID: <pDHT4NCqwdW3myzlI_FJI5IXn5YCTwaEmAncrAHi2j8=.97dc0de0-5047-425b-802d-9bc6954a50d8@github.com>

On Mon, 18 Apr 2022 05:14:27 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
>> 
>> I fixed a couple of other spelling mistakes.
>> 
>> I also expanded wildcard imports.
>
> src/java.desktop/share/classes/java/awt/Graphics.java line 29:
> 
>> 27: import java.io.*;
>> 28: import java.lang.*;
>> 29: import java.util.*;
> 
> Are these unused imports?

Yes, they're unused. The class has a list of abstract methods.

The build is successful.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8274


From aivanov at openjdk.java.net  Mon Apr 18 13:07:40 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 18 Apr 2022 13:07:40 GMT
Subject: RFR: 8284189: Replace usages of 'a the' in java.desktop
In-Reply-To: <pZaCJNzXXtvGvo-4JEDtTwoKhEzAZ399UllVFwJ2uPM=.3154bc15-710c-439b-9e4e-16ad012e0205@github.com>
References: <GEeFsO6UCFVr_EI5oDxdC8cIFCLDSSRpuQDs4owG43M=.a17abdd1-8fc6-4729-8d78-32bf6d84ff4e@github.com>
 <pZaCJNzXXtvGvo-4JEDtTwoKhEzAZ399UllVFwJ2uPM=.3154bc15-710c-439b-9e4e-16ad012e0205@github.com>
Message-ID: <kSa7JpJRqz8FUQlXehUATKmTP3YrPEdaYxA6aoZ6wHw=.8f103cb4-dcdc-460b-b7b0-971cd500c780@github.com>

On Mon, 18 Apr 2022 05:20:11 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> This PR has a lot of other changes than just correcting spelling mistakes and a/an combinations.

Expanding wildcard imports is not _a lot of other changes_. The build is successful, expanding imports doesn't hinder reviewing other changes.

However, I should've mentioned this in the PR description. Now I've updated it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8274


From jdv at openjdk.java.net  Mon Apr 18 13:20:42 2022
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 18 Apr 2022 13:20:42 GMT
Subject: RFR: 7132796: [macosx]
 closed/javax/swing/JComboBox/4517214/bug4517214.java fails on MacOS
In-Reply-To: <b9nYu6F7tb0AE5Wa7V8CkITC2hsgCXE-aUumjo8AA3o=.4b998976-41b8-4864-9379-7a3b9e90e753@github.com>
References: <DFryrg8OZJ22xBLpprcnD14oXkSjF57fQA3jdwTD2Ko=.0a3b8830-4d7e-4c7e-8c1f-2932cd7ca1a8@github.com>
 <b9nYu6F7tb0AE5Wa7V8CkITC2hsgCXE-aUumjo8AA3o=.4b998976-41b8-4864-9379-7a3b9e90e753@github.com>
Message-ID: <XQB6yFPdUZ6iAKimcYlm3InuN_7MaPJpgtr4aw7r0tk=.9e647a00-3cad-4965-a77b-fec6988efae9@github.com>

On Mon, 18 Apr 2022 04:14:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> JDK-4517214 was fixed for Metal L&F where JComboBox having TitledBorder used to have double height compared to normal JComboBox.
>> The issue is still observed for macos for Aqua L&F where still double height is seen.
>> Fix is to prevent adding border insets height to combobox size as was done for [MetalComboxUI.getMinimumSize[](url)](https://github.com/openjdk/jdk/blame/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalComboBoxUI.java#L384)
>> The closed test is automated and moved to open. CI testing on all platform is ok.
>
> Any more comments on this @mrserb ?

@prsadhuk I am not seeing an internal PR to remove this test case from closed repo. I thought we usually raise closed PR first about movement and then open PR. Have things changed recently.

Also having "closed" in open PR title is confusing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8237


From psadhukhan at openjdk.java.net  Mon Apr 18 13:24:41 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 18 Apr 2022 13:24:41 GMT
Subject: RFR: 7132796: [macosx]
 closed/javax/swing/JComboBox/4517214/bug4517214.java fails on MacOS
In-Reply-To: <DFryrg8OZJ22xBLpprcnD14oXkSjF57fQA3jdwTD2Ko=.0a3b8830-4d7e-4c7e-8c1f-2932cd7ca1a8@github.com>
References: <DFryrg8OZJ22xBLpprcnD14oXkSjF57fQA3jdwTD2Ko=.0a3b8830-4d7e-4c7e-8c1f-2932cd7ca1a8@github.com>
Message-ID: <puIZzirgljISrIlsYLhR5eGpzJ8suqS2Lf_UsbKMLt8=.5848dc3d-8d3a-4661-bdc5-3dfa2f473cf3@github.com>

On Thu, 14 Apr 2022 06:50:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> JDK-4517214 was fixed for Metal L&F where JComboBox having TitledBorder used to have double height compared to normal JComboBox.
> The issue is still observed for macos for Aqua L&F where still double height is seen.
> Fix is to prevent adding border insets height to combobox size as was done for [MetalComboxUI.getMinimumSize[](url)](https://github.com/openjdk/jdk/blame/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalComboBoxUI.java#L384)
> The closed test is automated and moved to open. CI testing on all platform is ok.

The above holds true for test fix in closed. Since this is a product fix w.r.t closed test and NOT a test fix, I have raised an open PR first. If and when this goes through, closed PR will be raised to remove the test and also from problemlist.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8237


From jdv at openjdk.java.net  Mon Apr 18 13:28:41 2022
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 18 Apr 2022 13:28:41 GMT
Subject: RFR: 8284189: Replace usages of 'a the' in java.desktop
In-Reply-To: <GEeFsO6UCFVr_EI5oDxdC8cIFCLDSSRpuQDs4owG43M=.a17abdd1-8fc6-4729-8d78-32bf6d84ff4e@github.com>
References: <GEeFsO6UCFVr_EI5oDxdC8cIFCLDSSRpuQDs4owG43M=.a17abdd1-8fc6-4729-8d78-32bf6d84ff4e@github.com>
Message-ID: <KipHVhWEPVdylGYysZQZ7Mn9Zx42mdhe9DUIQLyLnIs=.3ea5598b-4332-44d5-a4b1-a7b293654b52@github.com>

On Sat, 16 Apr 2022 17:45:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> I fixed a couple of other spelling mistakes.
> 
> I also expanded wildcard imports.

test/jdk/javax/accessibility/manual/ComboBoxDemo.html line 63:

> 61:         <td style="Width:100%;" colspan="3">
> 62:             <ol>
> 63:                 <li>Verify that space and down arrow bring up the drop-down list.<br>

Is this HTML refactoring needed as part of this PR?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8274


From jdv at openjdk.java.net  Mon Apr 18 13:32:39 2022
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 18 Apr 2022 13:32:39 GMT
Subject: RFR: 8284189: Replace usages of 'a the' in java.desktop
In-Reply-To: <kSa7JpJRqz8FUQlXehUATKmTP3YrPEdaYxA6aoZ6wHw=.8f103cb4-dcdc-460b-b7b0-971cd500c780@github.com>
References: <GEeFsO6UCFVr_EI5oDxdC8cIFCLDSSRpuQDs4owG43M=.a17abdd1-8fc6-4729-8d78-32bf6d84ff4e@github.com>
 <pZaCJNzXXtvGvo-4JEDtTwoKhEzAZ399UllVFwJ2uPM=.3154bc15-710c-439b-9e4e-16ad012e0205@github.com>
 <kSa7JpJRqz8FUQlXehUATKmTP3YrPEdaYxA6aoZ6wHw=.8f103cb4-dcdc-460b-b7b0-971cd500c780@github.com>
Message-ID: <rP_2EExZW-DTziY-rp5XlSoHpueCVpZ4hU1KYAAbdk8=.565bafc0-f68e-4678-8e93-0c01a23e8d1a@github.com>

On Mon, 18 Apr 2022 13:04:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > This PR has a lot of other changes than just correcting spelling mistakes and a/an combinations.
> 
> Expanding wildcard imports is not _a lot of other changes_. The build is successful, expanding imports doesn't hinder reviewing other changes.
> 
> However, I should've mentioned this in the PR description. Now I've updated it.

>From reviewer's perspective, when i read description of PR mentioning only documentation changes and then go ahead and see code updates it raises doubts. Thanks for updating the description.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8274


From aivanov at openjdk.java.net  Mon Apr 18 14:58:37 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 18 Apr 2022 14:58:37 GMT
Subject: RFR: 8284189: Replace usages of 'a the' in java.desktop
In-Reply-To: <KipHVhWEPVdylGYysZQZ7Mn9Zx42mdhe9DUIQLyLnIs=.3ea5598b-4332-44d5-a4b1-a7b293654b52@github.com>
References: <GEeFsO6UCFVr_EI5oDxdC8cIFCLDSSRpuQDs4owG43M=.a17abdd1-8fc6-4729-8d78-32bf6d84ff4e@github.com>
 <KipHVhWEPVdylGYysZQZ7Mn9Zx42mdhe9DUIQLyLnIs=.3ea5598b-4332-44d5-a4b1-a7b293654b52@github.com>
Message-ID: <ZgBHAh32BubhjV8euUHanxKIIhodEGl8LLnMjsOdppM=.1c72cfb9-a1c2-4472-b301-987d19e6e6a0@github.com>

On Mon, 18 Apr 2022 13:24:55 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
>> 
>> I fixed a couple of other spelling mistakes.
>> 
>> I also expanded wildcard imports.
>
> test/jdk/javax/accessibility/manual/ComboBoxDemo.html line 63:
> 
>> 61:         <td style="Width:100%;" colspan="3">
>> 62:             <ol>
>> 63:                 <li>Verify that space and down arrow bring up the drop-down list.<br>
> 
> Is this HTML refactoring needed as part of this PR?

The `<img>` element is placed after `</li>` and before the next `<li>`. In HTML `<ol>` doesn't allow anything but `<li>` elements. I placed the image to where it was supposed to be.

I decided it was easier and more efficient to fix it as part of this change rather than submit a new bug and create a new pull request afterwards.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8274


From aivanov at openjdk.java.net  Mon Apr 18 15:13:34 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 18 Apr 2022 15:13:34 GMT
Subject: RFR: 8284189: Replace usages of 'a the' in java.desktop [v2]
In-Reply-To: <GEeFsO6UCFVr_EI5oDxdC8cIFCLDSSRpuQDs4owG43M=.a17abdd1-8fc6-4729-8d78-32bf6d84ff4e@github.com>
References: <GEeFsO6UCFVr_EI5oDxdC8cIFCLDSSRpuQDs4owG43M=.a17abdd1-8fc6-4729-8d78-32bf6d84ff4e@github.com>
Message-ID: <VFw3VJIWmWL28o0EXtPjMrw-V7bncTtelQPndTrOenE=.7b69ad1f-6c5f-4f71-a5d3-62a2e04c0452@github.com>

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> I fixed a couple of other spelling mistakes.
> 
> I also expanded wildcard imports.

Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  8284189: Revert additional changes for ComboBoxDemo.html

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8274/files
  - new: https://git.openjdk.java.net/jdk/pull/8274/files/cc5b0b5b..73733262

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8274&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8274&range=00-01

  Stats: 9 lines in 1 file changed: 2 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8274.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8274/head:pull/8274

PR: https://git.openjdk.java.net/jdk/pull/8274


From aivanov at openjdk.java.net  Mon Apr 18 15:13:35 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 18 Apr 2022 15:13:35 GMT
Subject: RFR: 8284189: Replace usages of 'a the' in java.desktop [v2]
In-Reply-To: <ZgBHAh32BubhjV8euUHanxKIIhodEGl8LLnMjsOdppM=.1c72cfb9-a1c2-4472-b301-987d19e6e6a0@github.com>
References: <GEeFsO6UCFVr_EI5oDxdC8cIFCLDSSRpuQDs4owG43M=.a17abdd1-8fc6-4729-8d78-32bf6d84ff4e@github.com>
 <KipHVhWEPVdylGYysZQZ7Mn9Zx42mdhe9DUIQLyLnIs=.3ea5598b-4332-44d5-a4b1-a7b293654b52@github.com>
 <ZgBHAh32BubhjV8euUHanxKIIhodEGl8LLnMjsOdppM=.1c72cfb9-a1c2-4472-b301-987d19e6e6a0@github.com>
Message-ID: <BxgMGD6eTqSoxTGDm_LVKFNvmbh89th2wed-md69YPY=.823b2cbb-f9f9-4d25-945e-a2f5b17aeacf@github.com>

On Mon, 18 Apr 2022 14:55:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/accessibility/manual/ComboBoxDemo.html line 63:
>> 
>>> 61:         <td style="Width:100%;" colspan="3">
>>> 62:             <ol>
>>> 63:                 <li>Verify that space and down arrow bring up the drop-down list.<br>
>> 
>> Is this HTML refactoring needed as part of this PR?
>
> The `<img>` element is placed after `</li>` and before the next `<li>`. In HTML `<ol>` doesn't allow anything but `<li>` elements. I placed the image to where it was supposed to be.
> 
> I decided it was easier and more efficient to fix it as part of this change rather than submit a new bug and create a new pull request afterwards.

In fact, you're right: I looked at the other HTML files near this one, and some of them also contain similar markup errors. It'll be wiser to address them separately.

I submitted [JDK-8284958](https://bugs.openjdk.java.net/browse/JDK-8284958) and reverted all changes to `ComboBoxDemo.html` but ?a the? to ?the?.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8274


From aivanov at openjdk.java.net  Mon Apr 18 15:25:38 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 18 Apr 2022 15:25:38 GMT
Subject: RFR: 8284189: Replace usages of 'a the' in java.desktop [v2]
In-Reply-To: <VFw3VJIWmWL28o0EXtPjMrw-V7bncTtelQPndTrOenE=.7b69ad1f-6c5f-4f71-a5d3-62a2e04c0452@github.com>
References: <GEeFsO6UCFVr_EI5oDxdC8cIFCLDSSRpuQDs4owG43M=.a17abdd1-8fc6-4729-8d78-32bf6d84ff4e@github.com>
 <VFw3VJIWmWL28o0EXtPjMrw-V7bncTtelQPndTrOenE=.7b69ad1f-6c5f-4f71-a5d3-62a2e04c0452@github.com>
Message-ID: <7MlgwBFMiNPAIN1oNq7x8yVUQUpixnqIwZUlxmNCB_Q=.89f528ed-ea2d-4b74-892c-4a5f7ee7f880@github.com>

On Mon, 18 Apr 2022 15:13:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
>> 
>> I fixed a couple of other spelling mistakes.
>> 
>> I also expanded wildcard imports.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284189: Revert additional changes for ComboBoxDemo.html

test/jdk/javax/accessibility/manual/ComboBoxDemo.html line 75:

> 73: </html>
> 74: 
> 75:         

The file contained trailing white-space at the last line, it is removed by the IDE.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8274


From prr at openjdk.java.net  Mon Apr 18 16:34:36 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 18 Apr 2022 16:34:36 GMT
Subject: RFR: 8284189: Replace usages of 'a the' in java.desktop [v2]
In-Reply-To: <VFw3VJIWmWL28o0EXtPjMrw-V7bncTtelQPndTrOenE=.7b69ad1f-6c5f-4f71-a5d3-62a2e04c0452@github.com>
References: <GEeFsO6UCFVr_EI5oDxdC8cIFCLDSSRpuQDs4owG43M=.a17abdd1-8fc6-4729-8d78-32bf6d84ff4e@github.com>
 <VFw3VJIWmWL28o0EXtPjMrw-V7bncTtelQPndTrOenE=.7b69ad1f-6c5f-4f71-a5d3-62a2e04c0452@github.com>
Message-ID: <WgwcUzQ7Dt93IO-fDZj_-N1qpA4zLDUzj_jpf2n7Oo4=.94bfb1f2-febd-410a-9a29-d49728c99a1d@github.com>

On Mon, 18 Apr 2022 15:13:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
>> 
>> I fixed a couple of other spelling mistakes.
>> 
>> I also expanded wildcard imports.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284189: Revert additional changes for ComboBoxDemo.html

looks fine.
Note that even though API javadoc is touched all these typos fall well below
the threshold for a CSR, even the correction from
java.awt.font.LineBreakMeasureer to java.awt.font.LineBreakMeasurer

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8274


From zgu at openjdk.java.net  Mon Apr 18 19:20:33 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 18 Apr 2022 19:20:33 GMT
Subject: RFR: 8284680: sun.font.FontConfigManager.getFontConfig() leaks
 charset
In-Reply-To: <bIZYEobkONaW5kpYH0AxKNH4IMySq_ddVGkt9tE-GnM=.863c3f13-3188-4be0-8e20-d92822ed4554@github.com>
References: <MgzLHY7B6i7YyEzX8rkn-cEdkDamqKvNofwkrf1JIKI=.72ba1959-fe21-4f4e-a346-0feb5ae4037c@github.com>
 <bIZYEobkONaW5kpYH0AxKNH4IMySq_ddVGkt9tE-GnM=.863c3f13-3188-4be0-8e20-d92822ed4554@github.com>
Message-ID: <C9CyUhpRBR5vdmDn1lLZ_V7gw2U2tCEM0fTzpl7C3_o=.df57fada-555a-4d22-9f2c-a5836440c305@github.com>

On Fri, 15 Apr 2022 18:43:27 GMT, Phil Race <prr at openjdk.org> wrote:

>> Please review this small patch that releases temporary charsets to avoid memory leak.
>> 
>> Test:
>> 
>> - [x] jdk_2d
>
> src/java.desktop/unix/native/common/awt/fontpath.c line 1112:
> 
>> 1110:                     if (currentUnionSet != charset) {
>> 1111:                         (*FcCharSetDestroy)(currentUnionSet);
>> 1112:                     }
> 
> Hmm. I worry that you may be replacing a leak with a crash.
> The original "charset" was returned from FcPatternGetCharSet() and I don't think it was a copy and will be freed when the pattern is destroyed.
> So that should not be freed here.

Right, that is why I have `if (currentUnionSet != charset)` check to prevent from freeing original `charset`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8187


From jdv at openjdk.java.net  Tue Apr 19 03:49:26 2022
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 19 Apr 2022 03:49:26 GMT
Subject: RFR: 8284189: Replace usages of 'a the' in java.desktop [v2]
In-Reply-To: <VFw3VJIWmWL28o0EXtPjMrw-V7bncTtelQPndTrOenE=.7b69ad1f-6c5f-4f71-a5d3-62a2e04c0452@github.com>
References: <GEeFsO6UCFVr_EI5oDxdC8cIFCLDSSRpuQDs4owG43M=.a17abdd1-8fc6-4729-8d78-32bf6d84ff4e@github.com>
 <VFw3VJIWmWL28o0EXtPjMrw-V7bncTtelQPndTrOenE=.7b69ad1f-6c5f-4f71-a5d3-62a2e04c0452@github.com>
Message-ID: <2j7rvlzl2if6TGFXVj3yUOoe7exG_GMZW9VcTQuneaI=.1cfacf6d-f6b0-42e9-b9e1-ac3eadc7de52@github.com>

On Mon, 18 Apr 2022 15:13:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
>> 
>> I fixed a couple of other spelling mistakes.
>> 
>> I also expanded wildcard imports.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284189: Revert additional changes for ComboBoxDemo.html

Marked as reviewed by jdv (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8274


From mvs at openjdk.java.net  Tue Apr 19 05:49:27 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 19 Apr 2022 05:49:27 GMT
Subject: RFR: 8283624: Create an automated regression test for RFE-4390885
 [v2]
In-Reply-To: <eQHQrJiEwEu6-kwABzL-6y9ejTW3GG1ST1nKi9lDus4=.b3f954b0-8616-4fda-8df7-a395a9a3c18f@github.com>
References: <DfOvs0ck3_ucgdZG8gdlmXPriMoEM9-RjaveRlmRZYA=.b6690b6a-4a51-4c98-b5ee-6409fe4b0f84@github.com>
 <eQHQrJiEwEu6-kwABzL-6y9ejTW3GG1ST1nKi9lDus4=.b3f954b0-8616-4fda-8df7-a395a9a3c18f@github.com>
Message-ID: <Okc37rR3G0C1ziLCt0SNiRh_2G1TfiKf-2ymUgynieg=.082dae9c-36de-44bb-812c-8f982fa3a6aa@github.com>

On Fri, 8 Apr 2022 07:14:28 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Write a regression test for [JDK-4390885](https://bugs.openjdk.java.net/browse/JDK-4390885) Enhancement Request.
>> 
>> Issue:
>> Please add the ability to set the location of a JFileChooser. This might be a
>> bug, but JFileChooser.setLocation() has no effect when
>> JFileChooser.showXXXXDialog() is called. This is becoming very important as the
>> popularity of multiple monitors is increasing. These dialogs show up on the
>> wrong monitor which is really annoying. Also due to bug #4189244 I am unable to
>> avoid painting problems by positioning the dialog away from the menu item that
>> initiated it.
>> 
>> Fix:
>> Now it's possible to set the location of Dialog in JFileChooser.
>> 
>> Testing:
>> 1. Tested in Mach5 10 times per platform(macos,linux,windows) and got all Pass.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fixed: Removed unwanted directory

@aivanov-jdk Can you review this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7996


From mvs at openjdk.java.net  Tue Apr 19 05:54:29 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 19 Apr 2022 05:54:29 GMT
Subject: Integrated: 8284521: Write an automated regression test for RFE
 4371575
In-Reply-To: <FgW8JkNC98cWCRNm8Tpsu75-EYCzO2wP4X-sM9rDkZs=.f66039d3-903b-42b3-b2f4-3af624d6fd4b@github.com>
References: <FgW8JkNC98cWCRNm8Tpsu75-EYCzO2wP4X-sM9rDkZs=.f66039d3-903b-42b3-b2f4-3af624d6fd4b@github.com>
Message-ID: <9F6dNPvpB0tq6We1Ydr4TWoGwI545Kh9GIuXjJC2em4=.8e4687f3-c871-492b-a255-4de8b2c4fe49@github.com>

On Thu, 7 Apr 2022 11:08:38 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Write an automated regression test for [JDK-4371575](https://bugs.openjdk.java.net/browse/JDK-4371575)
> 
> Issue:
> As part of the Merlin focus project, JComponent.setRequestFocusEnabled was
> deprecated and its implementation was changed to map exactly to the new
> method Component.setFocusable. Scott believes that the old behavior may be
> preferable. He would like to be able to specify that a Component is focusable,
> and should receive focus during keyboard traversal, but that it should not
> automatically take focus when the user clicks on it with the mouse.
> 
> We are concerned that the accessibility team would be against this behavior,
> and this also seems like more of a PLAF issue. Nevertheless, we should look
> into it before beta ships.
> 
> Fix:
> After some discussion we decided that the best balance of the old and new would be to make this an advisory property. This property will not be synonymous with focusable. Instead our mouse listeners will check this property before requesting focus. This provides as closely as possible the old behavior, while allowing people to use the new focusable property if they don't want a component focusable at all.
> 
> Testing:
> Tested in mach5, 10 times with all the 3 available platform like macosx, windows and linux and got all Pass.

This pull request has now been integrated.

Changeset: 447c2d13
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Abdul Kolarkunnu <akolarkunnu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/447c2d13d055fbe640ec4714a961543a03a4f2ad
Stats:     138 lines in 1 file changed: 138 ins; 0 del; 0 mod

8284521: Write an automated regression test for RFE 4371575

Reviewed-by: prr, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8143


From psadhukhan at openjdk.java.net  Tue Apr 19 07:03:28 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 19 Apr 2022 07:03:28 GMT
Subject: Integrated: 8266246: Swing test PressedIconTest.java sometimes fails
 on macOS 11 ARM
In-Reply-To: <q1SN67zcbRVAI3f85u2FCXSc_5-As_Ex50ytDFvXNN0=.bbf645ad-514d-45b2-bf12-3ab7f58b4291@github.com>
References: <q1SN67zcbRVAI3f85u2FCXSc_5-As_Ex50ytDFvXNN0=.bbf645ad-514d-45b2-bf12-3ab7f58b4291@github.com>
Message-ID: <vreLjDj1TY_aRlvwacW_M9bQNygu2nV1kh9bWZ49U90=.c31adf87-a625-408e-87a1-272c07fee015@github.com>

On Fri, 15 Apr 2022 09:57:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javax/swing/JButton/8151303/PressedIconTest.java was failing few times in macos M1 system owing t color profile issue.
> 
> java.lang.RuntimeException: Colors are different!
> at PressedIconTest.main(PressedIconTest.java:88) 
> 
> 
> Test is now passing in all mac M1 systems in CI (link in jBS) so can be removed from problemlist.

This pull request has now been integrated.

Changeset: c5e9719c
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c5e9719c40ed4d83b3978f45bacbf8e066cae02d
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8266246: Swing test PressedIconTest.java sometimes fails on macOS 11 ARM

Reviewed-by: jdv

-------------

PR: https://git.openjdk.java.net/jdk/pull/8261


From dmarkov at openjdk.java.net  Tue Apr 19 07:18:26 2022
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Tue, 19 Apr 2022 07:18:26 GMT
Subject: RFR: 8284189: Replace usages of 'a the' in java.desktop [v2]
In-Reply-To: <VFw3VJIWmWL28o0EXtPjMrw-V7bncTtelQPndTrOenE=.7b69ad1f-6c5f-4f71-a5d3-62a2e04c0452@github.com>
References: <GEeFsO6UCFVr_EI5oDxdC8cIFCLDSSRpuQDs4owG43M=.a17abdd1-8fc6-4729-8d78-32bf6d84ff4e@github.com>
 <VFw3VJIWmWL28o0EXtPjMrw-V7bncTtelQPndTrOenE=.7b69ad1f-6c5f-4f71-a5d3-62a2e04c0452@github.com>
Message-ID: <SzYZa_Hr4fqAqudVrieQnNym-7ao4FUxLeA2GWjiS-E=.1593fcdd-8997-4034-ab43-cb629ce80bc2@github.com>

On Mon, 18 Apr 2022 15:13:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
>> 
>> I fixed a couple of other spelling mistakes.
>> 
>> I also expanded wildcard imports.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284189: Revert additional changes for ComboBoxDemo.html

Marked as reviewed by dmarkov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8274


From psadhukhan at openjdk.java.net  Tue Apr 19 09:17:45 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 19 Apr 2022 09:17:45 GMT
Subject: RFR: 8284993: Replace System.exit call in swing tests with
 RuntimeException
Message-ID: <HpC4smoyLOHwI71LRFJ6DUrsnsujjgLQHM0VE6dsDTc=.6730db17-3b19-4eac-bd54-8a9f253d5f5f@github.com>

Few swing tests call System.exit() which might stop the test harness from executing further tests if any of the test fail. We should replace with RuntimeException.

-------------

Commit messages:
 - 8284993: Replace System.exit call in swing tests with RuntimeException
 - 8284993: Replace System.exit call in swing tests with RuntimeException

Changes: https://git.openjdk.java.net/jdk/pull/8293/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8293&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284993
  Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8293.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8293/head:pull/8293

PR: https://git.openjdk.java.net/jdk/pull/8293


From azvegint at openjdk.java.net  Tue Apr 19 11:54:45 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 19 Apr 2022 11:54:45 GMT
Subject: RFR: 8023814: Test
 java/awt/im/memoryleak/InputContextMemoryLeakTest.java fails
Message-ID: <FsGax91Svfmrlgpy6WEZAdKSQHNS7jZnezgPUS10txg=.1c141c87-d702-457b-8066-58d5b32501e6@github.com>

Removing the test from problem list, since I am unable to reproduce the issue even with old Ubuntu distros with jdk8.
Bug filed against Solaris initially, but I did not test on it, since it is no longer supported.

Multiple mach5 testing is green.

`dispose` added for convenience if test is executed without jtreg.

-------------

Commit messages:
 - initial

Changes: https://git.openjdk.java.net/jdk/pull/8295/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8295&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8023814
  Stats: 9 lines in 2 files changed: 5 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8295.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8295/head:pull/8295

PR: https://git.openjdk.java.net/jdk/pull/8295


From psadhukhan at openjdk.java.net  Tue Apr 19 13:01:49 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 19 Apr 2022 13:01:49 GMT
Subject: RFR: 8042381: Test javax/swing/JRootPane/4670486/bug4670486.java fails
 with Action has not been received
Message-ID: <WQAfA_YZiHz0U83Eh7Z9xO3j37nkU0F6MJkmLSRj7EU=.e8230f97-5612-455b-9a27-1a898d703512@github.com>

This test was failing long time back probably due to samevm mode execution but not failing in recent run.
Reduce sutodelay time consistent with other test, move frame to center and added wait time after frame is made visible.

Several iterations of the test passed in all platforms (link in JBS)

-------------

Commit messages:
 - Merge branch 'master' into JDK-8042381
 - 8042381: Test javax/swing/JRootPane/4670486/bug4670486.java fails with Action has not been received

Changes: https://git.openjdk.java.net/jdk/pull/8296/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8296&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8042381
  Stats: 4 lines in 2 files changed: 2 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8296.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8296/head:pull/8296

PR: https://git.openjdk.java.net/jdk/pull/8296


From duke at openjdk.java.net  Tue Apr 19 17:03:16 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Tue, 19 Apr 2022 17:03:16 GMT
Subject: RFR: 8283803: Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/PrintGlyphVectorTest.java and fix test [v9]
In-Reply-To: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
Message-ID: <FolEr2-LeqRqqTaY9iKFad0tmBNAz8J1GEYQFHxrXdU=.be364e09-2f2e-4441-a22a-c9052d19c839@github.com>

> Fixed the following issue.
> 1) Removed yes/no since test was failing due to "Parser error due to yesno in @run main/manual=yesno"
> 2) After removing yes/no test run( just shows the UI and gets dispose immediately). User cannot interact with the test UI and mark the test pass or failed. 
> So added Pass and Fail button to mark the test result.
> 3) Added timeout if in case user does not interact with the test UI.
> 
> @shurymury 
> @aivanov-jdk

lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'JDK-8283803' of https://github.com/lawrence-andrew/jdk into JDK-8283803
 - Removed checking pj for null

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8004/files
  - new: https://git.openjdk.java.net/jdk/pull/8004/files/0d971ba3..12e418b7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8004&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8004&range=07-08

  Stats: 44 lines in 2 files changed: 14 ins; 9 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8004.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8004/head:pull/8004

PR: https://git.openjdk.java.net/jdk/pull/8004


From azvegint at openjdk.java.net  Tue Apr 19 18:25:35 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 19 Apr 2022 18:25:35 GMT
Subject: RFR: 8042381: Test javax/swing/JRootPane/4670486/bug4670486.java
 fails with Action has not been received
In-Reply-To: <WQAfA_YZiHz0U83Eh7Z9xO3j37nkU0F6MJkmLSRj7EU=.e8230f97-5612-455b-9a27-1a898d703512@github.com>
References: <WQAfA_YZiHz0U83Eh7Z9xO3j37nkU0F6MJkmLSRj7EU=.e8230f97-5612-455b-9a27-1a898d703512@github.com>
Message-ID: <LLsE_Q2saQcGYwp99b-WCudQd99k8Hu1zfA6tTWvttg=.e4df5ac9-828d-4bfe-9311-09a9fcfcab0c@github.com>

On Tue, 19 Apr 2022 12:53:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test was failing long time back probably due to samevm mode execution but not failing in recent run.
> Reduce sutodelay time consistent with other test, move frame to center and added wait time after frame is made visible.
> 
> Several iterations of the test passed in all platforms (link in JBS)

Marked as reviewed by azvegint (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8296


From azvegint at openjdk.java.net  Tue Apr 19 18:53:23 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 19 Apr 2022 18:53:23 GMT
Subject: RFR: 8284993: Replace System.exit call in swing tests with
 RuntimeException
In-Reply-To: <HpC4smoyLOHwI71LRFJ6DUrsnsujjgLQHM0VE6dsDTc=.6730db17-3b19-4eac-bd54-8a9f253d5f5f@github.com>
References: <HpC4smoyLOHwI71LRFJ6DUrsnsujjgLQHM0VE6dsDTc=.6730db17-3b19-4eac-bd54-8a9f253d5f5f@github.com>
Message-ID: <aKAe22qOtlGkogC13vadTX-3dqKPMfWJKgXNrh9QaDU=.b38ee7cd-d80c-4694-b434-e9a4da2d4840@github.com>

On Tue, 19 Apr 2022 09:10:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Few swing tests call System.exit() which might stop the test harness from executing further tests if any of the test fail. We should replace with RuntimeException.

test/jdk/javax/swing/JComboBox/8019180/Test8019180.java line 66:

> 64:             }
> 65:             SwingUtilities.getWindowAncestor(this.test).dispose();
> 66:             LATCH.countDown();

Looks like that before the fix all tests had graceful shutdown in standalone mode.

Now there are hanging open windows when they fails.
e.g. those two lines could be wrapped in `finally` block for graceful test finish.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8293


From aivanov at openjdk.java.net  Tue Apr 19 18:56:41 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 19 Apr 2022 18:56:41 GMT
Subject: RFR: 8283803: Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/PrintGlyphVectorTest.java and fix test [v9]
In-Reply-To: <FolEr2-LeqRqqTaY9iKFad0tmBNAz8J1GEYQFHxrXdU=.be364e09-2f2e-4441-a22a-c9052d19c839@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
 <FolEr2-LeqRqqTaY9iKFad0tmBNAz8J1GEYQFHxrXdU=.be364e09-2f2e-4441-a22a-c9052d19c839@github.com>
Message-ID: <zRJJMgchHFSkdHR3uOeDv28p2WJBJqsXncl9KOCughM=.367ece88-ef98-4a6d-83f2-b7adb91b9cef@github.com>

On Tue, 19 Apr 2022 17:03:16 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> Fixed the following issue.
>> 1) Removed yes/no since test was failing due to "Parser error due to yesno in @run main/manual=yesno"
>> 2) After removing yes/no test run( just shows the UI and gets dispose immediately). User cannot interact with the test UI and mark the test pass or failed. 
>> So added Pass and Fail button to mark the test result.
>> 3) Added timeout if in case user does not interact with the test UI.
>> 
>> @shurymury 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8283803' of https://github.com/lawrence-andrew/jdk into JDK-8283803
>  - Removed checking pj for null

Marked as reviewed by aivanov (Reviewer).

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 123:

> 121:         instructionsText.setLineWrap(true);
> 122: 
> 123:         long tTimeout = TimeUnit.MINUTES.toMillis(testTimeOut);

Here you could probably reused `testTimeout`:

testTimeOut = TimeUnit.MINUTES.toMillis(testTimeOut);

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 197:

> 195:      *                                   interrupted
> 196:      * @throws InvocationTargetException if an exception is thrown while
> 197:      *                                   disposing frames on EDT

Suggestion:

     *                                   disposing of frames on EDT

?Dispose? requires the preposition.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8004


From aivanov at openjdk.java.net  Tue Apr 19 19:27:28 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 19 Apr 2022 19:27:28 GMT
Subject: RFR: 8283803: Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/PrintGlyphVectorTest.java and fix test [v9]
In-Reply-To: <FolEr2-LeqRqqTaY9iKFad0tmBNAz8J1GEYQFHxrXdU=.be364e09-2f2e-4441-a22a-c9052d19c839@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
 <FolEr2-LeqRqqTaY9iKFad0tmBNAz8J1GEYQFHxrXdU=.be364e09-2f2e-4441-a22a-c9052d19c839@github.com>
Message-ID: <TlXjVYs8rxCtGOsVKkj7FPXs2eZc8ju6-e6dTmShsOQ=.f6f98228-ba7b-4061-a805-5de8c49c6cd6@github.com>

On Tue, 19 Apr 2022 17:03:16 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> Fixed the following issue.
>> 1) Removed yes/no since test was failing due to "Parser error due to yesno in @run main/manual=yesno"
>> 2) After removing yes/no test run( just shows the UI and gets dispose immediately). User cannot interact with the test UI and mark the test pass or failed. 
>> So added Pass and Fail button to mark the test result.
>> 3) Added timeout if in case user does not interact with the test UI.
>> 
>> @shurymury 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8283803' of https://github.com/lawrence-andrew/jdk into JDK-8283803
>  - Removed checking pj for null

You probably need to use `/issue remove 8283803` to remove duplicate entry from the commit message.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8004


From duke at openjdk.java.net  Tue Apr 19 19:48:28 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Tue, 19 Apr 2022 19:48:28 GMT
Subject: RFR: 8283803: Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/PrintGlyphVectorTest.java and fix test [v9]
In-Reply-To: <zRJJMgchHFSkdHR3uOeDv28p2WJBJqsXncl9KOCughM=.367ece88-ef98-4a6d-83f2-b7adb91b9cef@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
 <FolEr2-LeqRqqTaY9iKFad0tmBNAz8J1GEYQFHxrXdU=.be364e09-2f2e-4441-a22a-c9052d19c839@github.com>
 <zRJJMgchHFSkdHR3uOeDv28p2WJBJqsXncl9KOCughM=.367ece88-ef98-4a6d-83f2-b7adb91b9cef@github.com>
Message-ID: <99eMf_7TmyG1Mg2ED2hpYs6AvOzAzOivZJM4FcUFw_c=.f82a847d-e60f-42b3-a19f-f279db580770@github.com>

On Tue, 19 Apr 2022 18:47:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8283803' of https://github.com/lawrence-andrew/jdk into JDK-8283803
>>  - Removed checking pj for null
>
> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 123:
> 
>> 121:         instructionsText.setLineWrap(true);
>> 122: 
>> 123:         long tTimeout = TimeUnit.MINUTES.toMillis(testTimeOut);
> 
> Here you could probably reused `testTimeout`:
> 
> testTimeOut = TimeUnit.MINUTES.toMillis(testTimeOut);

testTimeOut is used with in lambda hence it should be final. So I just created a new variable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8004


From azvegint at openjdk.java.net  Tue Apr 19 20:11:09 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 19 Apr 2022 20:11:09 GMT
Subject: RFR: 8129827: [TEST_BUG] Test
 java/awt/Robot/RobotWheelTest/RobotWheelTest.java fails
Message-ID: <yq6IVScF0JllG8OmDLu2_FPx_-wS5pir1-2cXeb2Be8=.4af01d28-0106-4ba2-93fe-391314b6469e@github.com>

Test was written based on assumption that we will receive only one `mouseWheelMoved` event after `robot.mouseWheel(20)` call, but we can receive 20 intstead.

So the test is modified to accumulate wheel rotation values before checking.

Testing is green on all platforms.

-------------

Commit messages:
 - initial

Changes: https://git.openjdk.java.net/jdk/pull/8305/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8305&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8129827
  Stats: 43 lines in 2 files changed: 32 ins; 6 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8305.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8305/head:pull/8305

PR: https://git.openjdk.java.net/jdk/pull/8305


From aivanov at openjdk.java.net  Tue Apr 19 20:28:25 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 19 Apr 2022 20:28:25 GMT
Subject: RFR: 8283803: Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/PrintGlyphVectorTest.java and fix test [v9]
In-Reply-To: <99eMf_7TmyG1Mg2ED2hpYs6AvOzAzOivZJM4FcUFw_c=.f82a847d-e60f-42b3-a19f-f279db580770@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
 <FolEr2-LeqRqqTaY9iKFad0tmBNAz8J1GEYQFHxrXdU=.be364e09-2f2e-4441-a22a-c9052d19c839@github.com>
 <zRJJMgchHFSkdHR3uOeDv28p2WJBJqsXncl9KOCughM=.367ece88-ef98-4a6d-83f2-b7adb91b9cef@github.com>
 <99eMf_7TmyG1Mg2ED2hpYs6AvOzAzOivZJM4FcUFw_c=.f82a847d-e60f-42b3-a19f-f279db580770@github.com>
Message-ID: <zeGyqVGbMRG12WUvnsUG2dcp-QAvAnhDDAoSmX34OdE=.1f66aa53-2664-4a41-8311-1a15fcbddb77@github.com>

On Tue, 19 Apr 2022 19:45:20 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 123:
>> 
>>> 121:         instructionsText.setLineWrap(true);
>>> 122: 
>>> 123:         long tTimeout = TimeUnit.MINUTES.toMillis(testTimeOut);
>> 
>> Here you could probably reused `testTimeout`:
>> 
>> testTimeOut = TimeUnit.MINUTES.toMillis(testTimeOut);
>
> testTimeOut is used with in lambda hence it should be final. So I just created a new variable.

I see. Yes, lambdas and anonymous classes require final or effectively final variables.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8004


From duke at openjdk.java.net  Tue Apr 19 20:33:15 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Tue, 19 Apr 2022 20:33:15 GMT
Subject: RFR: 8283803: Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/PrintGlyphVectorTest.java and fix test [v10]
In-Reply-To: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
Message-ID: <yd_NVfGZBbpjjNqmzQHkohR0Iju60V3_D5zq9tWSNek=.e529373d-0c94-4411-aacc-0c179abbb8a3@github.com>

> Fixed the following issue.
> 1) Removed yes/no since test was failing due to "Parser error due to yesno in @run main/manual=yesno"
> 2) After removing yes/no test run( just shows the UI and gets dispose immediately). User cannot interact with the test UI and mark the test pass or failed. 
> So added Pass and Fail button to mark the test result.
> 3) Added timeout if in case user does not interact with the test UI.
> 
> @shurymury 
> @aivanov-jdk

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  Update PassFailJFrame.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8004/files
  - new: https://git.openjdk.java.net/jdk/pull/8004/files/12e418b7..c5551243

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8004&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8004&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8004.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8004/head:pull/8004

PR: https://git.openjdk.java.net/jdk/pull/8004


From duke at openjdk.java.net  Tue Apr 19 21:10:59 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Tue, 19 Apr 2022 21:10:59 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in JTabbedPane
Message-ID: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>

The exisiting manual test case tests different html styles of JTabbedPane tab title. The tab with "big" as title is seen to be clipped on Aqua LAF for larger font-size. In other LAFs it is observed that bigger font-size can be accommodated without clipping.

The following approaches were evaluated before considering it as not a test issue -

- Aqua LAF has a different tab style compared to other LAFs as seen in the screenshot below. Limiting font size on Aqua LAF requires scaling down the text which might be incompatible with Aqua LAF.

- Removing existing constraints on text and icon is incompatible for Aqua LAF.

- Since the above two approaches are incompatible with Aqua, a third approach was considered - explicitly stating in test that text may not fit in the tab and this is not a test bug.

![image](https://user-images.githubusercontent.com/95945681/164093604-ca7ecbc3-09c2-4338-bd2a-f8c81c12f360.png)

-------------

Commit messages:
 - expanded imports
 - JTabbedPane test case changes

Changes: https://git.openjdk.java.net/jdk/pull/8307/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8307&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251177
  Stats: 13 lines in 2 files changed: 8 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8307.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8307/head:pull/8307

PR: https://git.openjdk.java.net/jdk/pull/8307


From duke at openjdk.java.net  Tue Apr 19 21:11:12 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Tue, 19 Apr 2022 21:11:12 GMT
Subject: RFR: 8283803: Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/PrintGlyphVectorTest.java and fix test [v11]
In-Reply-To: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
Message-ID: <IT4N8SYxvuihYK0T1CI0GswsAH5x9hkjXKTfGsy9lkc=.48235156-596f-4312-b110-6be46c93b10f@github.com>

> Fixed the following issue.
> 1) Removed yes/no since test was failing due to "Parser error due to yesno in @run main/manual=yesno"
> 2) After removing yes/no test run( just shows the UI and gets dispose immediately). User cannot interact with the test UI and mark the test pass or failed. 
> So added Pass and Fail button to mark the test result.
> 3) Added timeout if in case user does not interact with the test UI.
> 
> @shurymury 
> @aivanov-jdk

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  Update PassFailJFrame.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8004/files
  - new: https://git.openjdk.java.net/jdk/pull/8004/files/c5551243..796e3933

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8004&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8004&range=09-10

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8004.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8004/head:pull/8004

PR: https://git.openjdk.java.net/jdk/pull/8004


From aivanov at openjdk.java.net  Tue Apr 19 21:11:13 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 19 Apr 2022 21:11:13 GMT
Subject: RFR: 8283803: Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/PrintGlyphVectorTest.java and fix test [v11]
In-Reply-To: <IT4N8SYxvuihYK0T1CI0GswsAH5x9hkjXKTfGsy9lkc=.48235156-596f-4312-b110-6be46c93b10f@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
 <IT4N8SYxvuihYK0T1CI0GswsAH5x9hkjXKTfGsy9lkc=.48235156-596f-4312-b110-6be46c93b10f@github.com>
Message-ID: <4esCyMsk5lbr7LZoZuOO9Uw_1-S0e9VAmLAw5VIm_Mk=.75abaf8b-435d-4c5c-830a-2be075d32ae5@github.com>

On Tue, 19 Apr 2022 21:08:10 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> Fixed the following issue.
>> 1) Removed yes/no since test was failing due to "Parser error due to yesno in @run main/manual=yesno"
>> 2) After removing yes/no test run( just shows the UI and gets dispose immediately). User cannot interact with the test UI and mark the test pass or failed. 
>> So added Pass and Fail button to mark the test result.
>> 3) Added timeout if in case user does not interact with the test UI.
>> 
>> @shurymury 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update PassFailJFrame.java

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8004


From duke at openjdk.java.net  Tue Apr 19 21:11:13 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Tue, 19 Apr 2022 21:11:13 GMT
Subject: Integrated: 8283803: Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/PrintGlyphVectorTest.java and fix test
In-Reply-To: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
References: <h26lmM_j5pbzKlazasgG6s2w4w9yPt8lcpq0LTIk6WM=.c1188299-8587-4c18-8857-9a1a44d812cb@github.com>
Message-ID: <PdfGyfdB6ZNWJg9v7CKPiBRzVRZAwdHCu7Sst_yH9SE=.4ce415f9-ca5f-4cf3-a3b7-06c88a5810b7@github.com>

On Mon, 28 Mar 2022 20:23:20 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> Fixed the following issue.
> 1) Removed yes/no since test was failing due to "Parser error due to yesno in @run main/manual=yesno"
> 2) After removing yes/no test run( just shows the UI and gets dispose immediately). User cannot interact with the test UI and mark the test pass or failed. 
> So added Pass and Fail button to mark the test result.
> 3) Added timeout if in case user does not interact with the test UI.
> 
> @shurymury 
> @aivanov-jdk

This pull request has now been integrated.

Changeset: ed23033d
Author:    lawrence.andrews <87324768+lawrence-andrew at users.noreply.github.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ed23033dc6b3d4833ce2c8d07f273747ab8ae406
Stats:     206 lines in 2 files changed: 110 ins; 48 del; 48 mod

8283803: Remove jtreg tag manual=yesno for java/awt/print/PrinterJob/PrintGlyphVectorTest.java and fix test
8284898: Enhance PassFailJFrame

Reviewed-by: prr, aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/8004


From kizune at openjdk.java.net  Tue Apr 19 21:22:28 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 19 Apr 2022 21:22:28 GMT
Subject: RFR: 8042381: Test javax/swing/JRootPane/4670486/bug4670486.java
 fails with Action has not been received
In-Reply-To: <WQAfA_YZiHz0U83Eh7Z9xO3j37nkU0F6MJkmLSRj7EU=.e8230f97-5612-455b-9a27-1a898d703512@github.com>
References: <WQAfA_YZiHz0U83Eh7Z9xO3j37nkU0F6MJkmLSRj7EU=.e8230f97-5612-455b-9a27-1a898d703512@github.com>
Message-ID: <jYG5RnZ9FcpsUPcWYoBz9CefMWim7Uwi2dxUQ5r5pTI=.3b46e71b-a6ad-48c2-8622-9da52ccab2e4@github.com>

On Tue, 19 Apr 2022 12:53:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test was failing long time back probably due to samevm mode execution but not failing in recent run.
> Reduce sutodelay time consistent with other test, move frame to center and added wait time after frame is made visible.
> 
> Several iterations of the test passed in all platforms (link in JBS)

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8296


From kizune at openjdk.java.net  Wed Apr 20 05:01:08 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 20 Apr 2022 05:01:08 GMT
Subject: RFR: 8266247: Swing test bug7154030.java sometimes fails on macOS 11
 ARM
Message-ID: <6NjM3IIB8sz7952nBBPoh6GX3z7Oj_wrAGmi9id71ws=.d997e533-28de-4e07-980b-0e5e7fbc7990@github.com>

Change background and foreground colors to white and black to avoid color shift problems.

-------------

Commit messages:
 - 8266247: Swing test bug7154030.java sometimes fails on macOS 11 ARM

Changes: https://git.openjdk.java.net/jdk/pull/8313/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8313&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266247
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8313.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8313/head:pull/8313

PR: https://git.openjdk.java.net/jdk/pull/8313


From kizune at openjdk.java.net  Wed Apr 20 05:18:01 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 20 Apr 2022 05:18:01 GMT
Subject: RFR: 6829250: Reg test:
 java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java fails in Windows
Message-ID: <qDTR6A9kV9lbOGfZGYj5S5b9_M_5zhjvfak1NWPbwPY=.dce17901-1416-411a-a31f-f3f09d78389c@github.com>

Only check that insets of the fully expanded undecorated window is not bigger than device insets. They can be smaller, it is a normal situation.

-------------

Commit messages:
 - 6829250: Reg test: java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java fails in Windows

Changes: https://git.openjdk.java.net/jdk/pull/8314/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8314&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-6829250
  Stats: 10 lines in 2 files changed: 6 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8314.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8314/head:pull/8314

PR: https://git.openjdk.java.net/jdk/pull/8314


From mvs at openjdk.java.net  Wed Apr 20 07:14:33 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 20 Apr 2022 07:14:33 GMT
Subject: RFR: 8283624: Create an automated regression test for RFE-4390885
 [v3]
In-Reply-To: <DfOvs0ck3_ucgdZG8gdlmXPriMoEM9-RjaveRlmRZYA=.b6690b6a-4a51-4c98-b5ee-6409fe4b0f84@github.com>
References: <DfOvs0ck3_ucgdZG8gdlmXPriMoEM9-RjaveRlmRZYA=.b6690b6a-4a51-4c98-b5ee-6409fe4b0f84@github.com>
Message-ID: <ulXuyM6cAT0OpsHOXQQCYcMFq29lzpwg66Jn8WHC5pY=.ba10753a-f153-4abb-965d-460660da17f7@github.com>

> Write a regression test for [JDK-4390885](https://bugs.openjdk.java.net/browse/JDK-4390885) Enhancement Request.
> 
> Issue:
> Please add the ability to set the location of a JFileChooser. This might be a
> bug, but JFileChooser.setLocation() has no effect when
> JFileChooser.showXXXXDialog() is called. This is becoming very important as the
> popularity of multiple monitors is increasing. These dialogs show up on the
> wrong monitor which is really annoying. Also due to bug #4189244 I am unable to
> avoid painting problems by positioning the dialog away from the menu item that
> initiated it.
> 
> Fix:
> Now it's possible to set the location of Dialog in JFileChooser.
> 
> Testing:
> 1. Tested in Mach5 10 times per platform(macos,linux,windows) and got all Pass.

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Removed some duplicate code

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7996/files
  - new: https://git.openjdk.java.net/jdk/pull/7996/files/76337e2f..22e4eebc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7996&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7996&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7996.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7996/head:pull/7996

PR: https://git.openjdk.java.net/jdk/pull/7996


From psadhukhan at openjdk.java.net  Wed Apr 20 08:13:26 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 20 Apr 2022 08:13:26 GMT
Subject: RFR: 8266247: Swing test bug7154030.java sometimes fails on macOS
 11 ARM
In-Reply-To: <6NjM3IIB8sz7952nBBPoh6GX3z7Oj_wrAGmi9id71ws=.d997e533-28de-4e07-980b-0e5e7fbc7990@github.com>
References: <6NjM3IIB8sz7952nBBPoh6GX3z7Oj_wrAGmi9id71ws=.d997e533-28de-4e07-980b-0e5e7fbc7990@github.com>
Message-ID: <njuSvJ4sdNhLoaB11VVOmoULn7P3YQG7KUdHyC8wpNM=.9d7c358d-90d5-44a5-98ab-100166514c70@github.com>

On Wed, 20 Apr 2022 04:52:08 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Change background and foreground colors to white and black to avoid color shift problems.

looks ok..
I hope this is tested against all CI platforms not only in mac M1..

-------------

Marked as reviewed by psadhukhan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8313


From psadhukhan at openjdk.java.net  Wed Apr 20 08:40:25 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 20 Apr 2022 08:40:25 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane
In-Reply-To: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
Message-ID: <UYtSCOmEQ9-zCA1X8_sK25lyyJW0_PygewDMezdaVQI=.40a415a2-844c-4a9f-a651-489a4d21cf60@github.com>

On Tue, 19 Apr 2022 21:03:13 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

> The exisiting manual test case tests different html styles of JTabbedPane tab title. The tab with "big" as title is seen to be clipped on Aqua LAF for larger font-size. In other LAFs it is observed that bigger font-size can be accommodated without clipping.
> 
> The following approaches were evaluated before considering it as not a test issue -
> 
> - Aqua LAF has a different tab style compared to other LAFs as seen in the screenshot below. Limiting font size on Aqua LAF requires scaling down the text which might be incompatible with Aqua LAF.
> 
> - Removing existing constraints on text and icon is incompatible for Aqua LAF.
> 
> Since the above two approaches are incompatible with Aqua and it is not a test issue, a note has been added about clipped text and this test has been removed from problem list
> 
> ![image](https://user-images.githubusercontent.com/95945681/164093604-ca7ecbc3-09c2-4338-bd2a-f8c81c12f360.png)

test/jdk/javax/swing/JTabbedPane/4209065/bug4209065.java line 59:

> 57:                       + "fit the tab.</center></html>";
> 58:         tp.addTab("<html><center><font size=+2>big</font></center></html>",
> 59:                 new JLabel(text));

If you are saying text may not fit the tab, then I guess no need to change font size from +3 to +2, leave it as it is..

-------------

PR: https://git.openjdk.java.net/jdk/pull/8307


From psadhukhan at openjdk.java.net  Wed Apr 20 09:07:26 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 20 Apr 2022 09:07:26 GMT
Subject: Integrated: 8042381: Test
 javax/swing/JRootPane/4670486/bug4670486.java fails with Action has not been
 received
In-Reply-To: <WQAfA_YZiHz0U83Eh7Z9xO3j37nkU0F6MJkmLSRj7EU=.e8230f97-5612-455b-9a27-1a898d703512@github.com>
References: <WQAfA_YZiHz0U83Eh7Z9xO3j37nkU0F6MJkmLSRj7EU=.e8230f97-5612-455b-9a27-1a898d703512@github.com>
Message-ID: <1kaBA2yVL3Xz-66gEM80ssoer1_8QggVyZK4-TrntIg=.4d491bb0-eadc-4e7c-a287-f3f4e2ef1403@github.com>

On Tue, 19 Apr 2022 12:53:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test was failing long time back probably due to samevm mode execution but not failing in recent run.
> Reduce sutodelay time consistent with other test, move frame to center and added wait time after frame is made visible.
> 
> Several iterations of the test passed in all platforms (link in JBS)

This pull request has now been integrated.

Changeset: 1b716210
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1b71621008a62a4f806e2e97579fb8716be290a5
Stats:     4 lines in 2 files changed: 2 ins; 1 del; 1 mod

8042381: Test javax/swing/JRootPane/4670486/bug4670486.java fails with Action has not been received

Reviewed-by: azvegint, kizune

-------------

PR: https://git.openjdk.java.net/jdk/pull/8296


From psadhukhan at openjdk.java.net  Wed Apr 20 09:23:15 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 20 Apr 2022 09:23:15 GMT
Subject: RFR: 8284993: Replace System.exit call in swing tests with
 RuntimeException [v2]
In-Reply-To: <HpC4smoyLOHwI71LRFJ6DUrsnsujjgLQHM0VE6dsDTc=.6730db17-3b19-4eac-bd54-8a9f253d5f5f@github.com>
References: <HpC4smoyLOHwI71LRFJ6DUrsnsujjgLQHM0VE6dsDTc=.6730db17-3b19-4eac-bd54-8a9f253d5f5f@github.com>
Message-ID: <BaNazzLjrmtqjRute9_qY6EcJxfnuLv3QmmdLHCEdbQ=.f3b2c581-1fc8-421c-b95d-678757e5702b@github.com>

> Few swing tests call System.exit() which might stop the test harness from executing further tests if any of the test fail. We should replace with RuntimeException.

Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:

 - test fix
 - test fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8293/files
  - new: https://git.openjdk.java.net/jdk/pull/8293/files/f00eaac8..6b4f510a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8293&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8293&range=00-01

  Stats: 15 lines in 1 file changed: 10 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8293.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8293/head:pull/8293

PR: https://git.openjdk.java.net/jdk/pull/8293


From psadhukhan at openjdk.java.net  Wed Apr 20 09:23:15 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 20 Apr 2022 09:23:15 GMT
Subject: RFR: 8284993: Replace System.exit call in swing tests with
 RuntimeException [v2]
In-Reply-To: <aKAe22qOtlGkogC13vadTX-3dqKPMfWJKgXNrh9QaDU=.b38ee7cd-d80c-4694-b434-e9a4da2d4840@github.com>
References: <HpC4smoyLOHwI71LRFJ6DUrsnsujjgLQHM0VE6dsDTc=.6730db17-3b19-4eac-bd54-8a9f253d5f5f@github.com>
 <aKAe22qOtlGkogC13vadTX-3dqKPMfWJKgXNrh9QaDU=.b38ee7cd-d80c-4694-b434-e9a4da2d4840@github.com>
Message-ID: <sIgr3ix6khXWe7NQguxiq_iLEbnTCSbCrigPUviN_a8=.6c4b475e-d9c7-4124-b231-6a02c7af5fbe@github.com>

On Tue, 19 Apr 2022 18:32:39 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - test fix
>>  - test fix
>
> test/jdk/javax/swing/JComboBox/8019180/Test8019180.java line 66:
> 
>> 64:             }
>> 65:             SwingUtilities.getWindowAncestor(this.test).dispose();
>> 66:             LATCH.countDown();
> 
> Looks like that before the fix all tests had graceful shutdown in standalone mode.
> 
> Now there are hanging open windows when they fails.
> e.g. those two lines could be wrapped in `finally` block for graceful test finish.

I am not able to reproduce this observation. Anyway, I have added dispose in finally block

-------------

PR: https://git.openjdk.java.net/jdk/pull/8293


From psadhukhan at openjdk.java.net  Wed Apr 20 09:32:42 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 20 Apr 2022 09:32:42 GMT
Subject: RFR: 8023814: Test
 java/awt/im/memoryleak/InputContextMemoryLeakTest.java fails
In-Reply-To: <FsGax91Svfmrlgpy6WEZAdKSQHNS7jZnezgPUS10txg=.1c141c87-d702-457b-8066-58d5b32501e6@github.com>
References: <FsGax91Svfmrlgpy6WEZAdKSQHNS7jZnezgPUS10txg=.1c141c87-d702-457b-8066-58d5b32501e6@github.com>
Message-ID: <lvIEEvEWyK5RMkEApCOGKHoQcoXn9FFpZLAQISPhiL0=.4e74d902-bde7-40f9-bed7-69a9a8313211@github.com>

On Tue, 19 Apr 2022 11:48:10 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Removing the test from problem list, since I am unable to reproduce the issue even with old Ubuntu distros with jdk8.
> Bug filed against Solaris initially, but I did not test on it, since it is no longer supported.
> 
> Multiple mach5 testing is green.
> 
> `dispose` added for convenience if test is executed without jtreg.

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8295


From azvegint at openjdk.java.net  Wed Apr 20 10:07:28 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 20 Apr 2022 10:07:28 GMT
Subject: RFR: 8284993: Replace System.exit call in swing tests with
 RuntimeException [v2]
In-Reply-To: <sIgr3ix6khXWe7NQguxiq_iLEbnTCSbCrigPUviN_a8=.6c4b475e-d9c7-4124-b231-6a02c7af5fbe@github.com>
References: <HpC4smoyLOHwI71LRFJ6DUrsnsujjgLQHM0VE6dsDTc=.6730db17-3b19-4eac-bd54-8a9f253d5f5f@github.com>
 <aKAe22qOtlGkogC13vadTX-3dqKPMfWJKgXNrh9QaDU=.b38ee7cd-d80c-4694-b434-e9a4da2d4840@github.com>
 <sIgr3ix6khXWe7NQguxiq_iLEbnTCSbCrigPUviN_a8=.6c4b475e-d9c7-4124-b231-6a02c7af5fbe@github.com>
Message-ID: <Ae4tWNfCkzXNG85HlSqw5kRewzbnglpLbadw8HfGdLQ=.a964f783-d123-4e12-8f93-1ddf2f87ca3c@github.com>

On Wed, 20 Apr 2022 09:17:31 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/javax/swing/JComboBox/8019180/Test8019180.java line 66:
>> 
>>> 64:             }
>>> 65:             SwingUtilities.getWindowAncestor(this.test).dispose();
>>> 66:             LATCH.countDown();
>> 
>> Looks like that before the fix all tests had graceful shutdown in standalone mode.
>> 
>> Now there are hanging open windows when they fails.
>> e.g. those two lines could be wrapped in `finally` block for graceful test finish.
>
> I am not able to reproduce this observation. Anyway, I have added dispose in finally block

It is because the test is not failing right now, you can change  `>` to `<` in `if (0 > this.test.getSelectedIndex()) {`  to fail the test.

It will still hang after latest modifications when launched with `java Test8019180.java` because of `LATCH` is still awaiting for its `countdown` (which is not called after throwing an exception).

It is not an issue if you run it with jtreg.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8293


From psadhukhan at openjdk.java.net  Wed Apr 20 10:46:01 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 20 Apr 2022 10:46:01 GMT
Subject: RFR: 8284993: Replace System.exit call in swing tests with
 RuntimeException [v3]
In-Reply-To: <HpC4smoyLOHwI71LRFJ6DUrsnsujjgLQHM0VE6dsDTc=.6730db17-3b19-4eac-bd54-8a9f253d5f5f@github.com>
References: <HpC4smoyLOHwI71LRFJ6DUrsnsujjgLQHM0VE6dsDTc=.6730db17-3b19-4eac-bd54-8a9f253d5f5f@github.com>
Message-ID: <cxqxUjjA6LqzoSXo18IplpFjIzb07bRF1mXiQrHrJLg=.30416b7b-a914-4d74-9bf5-004a882ce279@github.com>

> Few swing tests call System.exit() which might stop the test harness from executing further tests if any of the test fail. We should replace with RuntimeException.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Test fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8293/files
  - new: https://git.openjdk.java.net/jdk/pull/8293/files/6b4f510a..2c8508a6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8293&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8293&range=01-02

  Stats: 18 lines in 1 file changed: 3 ins; 0 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8293.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8293/head:pull/8293

PR: https://git.openjdk.java.net/jdk/pull/8293


From psadhukhan at openjdk.java.net  Wed Apr 20 10:46:02 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 20 Apr 2022 10:46:02 GMT
Subject: RFR: 8284993: Replace System.exit call in swing tests with
 RuntimeException [v3]
In-Reply-To: <Ae4tWNfCkzXNG85HlSqw5kRewzbnglpLbadw8HfGdLQ=.a964f783-d123-4e12-8f93-1ddf2f87ca3c@github.com>
References: <HpC4smoyLOHwI71LRFJ6DUrsnsujjgLQHM0VE6dsDTc=.6730db17-3b19-4eac-bd54-8a9f253d5f5f@github.com>
 <aKAe22qOtlGkogC13vadTX-3dqKPMfWJKgXNrh9QaDU=.b38ee7cd-d80c-4694-b434-e9a4da2d4840@github.com>
 <sIgr3ix6khXWe7NQguxiq_iLEbnTCSbCrigPUviN_a8=.6c4b475e-d9c7-4124-b231-6a02c7af5fbe@github.com>
 <Ae4tWNfCkzXNG85HlSqw5kRewzbnglpLbadw8HfGdLQ=.a964f783-d123-4e12-8f93-1ddf2f87ca3c@github.com>
Message-ID: <Iusmr-v3fpgd_RLR6QJHq3eWJIapc7Ph0WpbMQWTnwA=.45509c11-26f1-4b73-aa05-12c6a1b12db8@github.com>

On Wed, 20 Apr 2022 10:03:10 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> I am not able to reproduce this observation. Anyway, I have added dispose in finally block
>
> It is because the test is not failing right now, you can change  `>` to `<` in `if (0 > this.test.getSelectedIndex()) {`  to fail the test.
> 
> It will still hang after latest modifications when launched with `java Test8019180.java` because of `LATCH` is still awaiting for its `countdown` (which is not called after throwing an exception).
> 
> It is not an issue if you run it with jtreg.

ok modified test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8293


From azvegint at openjdk.java.net  Wed Apr 20 11:25:21 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 20 Apr 2022 11:25:21 GMT
Subject: RFR: 8284993: Replace System.exit call in swing tests with
 RuntimeException [v3]
In-Reply-To: <cxqxUjjA6LqzoSXo18IplpFjIzb07bRF1mXiQrHrJLg=.30416b7b-a914-4d74-9bf5-004a882ce279@github.com>
References: <HpC4smoyLOHwI71LRFJ6DUrsnsujjgLQHM0VE6dsDTc=.6730db17-3b19-4eac-bd54-8a9f253d5f5f@github.com>
 <cxqxUjjA6LqzoSXo18IplpFjIzb07bRF1mXiQrHrJLg=.30416b7b-a914-4d74-9bf5-004a882ce279@github.com>
Message-ID: <VN9tL8o5o9AsShldjUSMhCXrhSZ8PALeFrZTtSPLElU=.aad1ee83-5a99-4e23-98c2-05574bf4c159@github.com>

On Wed, 20 Apr 2022 10:46:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Few swing tests call System.exit() which might stop the test harness from executing further tests if any of the test fail. We should replace with RuntimeException.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

Marked as reviewed by azvegint (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8293


From mvs at openjdk.java.net  Wed Apr 20 13:11:12 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 20 Apr 2022 13:11:12 GMT
Subject: RFR: 8274597: Some of the dnd tests time out and fail intermittently
Message-ID: <PKtuBdvWgS96mNNJUmJbDu4WHk7yfGMXrXVahFBjio8=.25fcec82-0939-43b0-adeb-a6c1c6d9fe2f@github.com>

These dnd tests fails with a time out intermittently in some machines(mostly Windows 11) which creates frequent noise in CI.
1. java/awt/dnd/AcceptDropMultipleTimes/AcceptDropMultipleTimes.java
2. java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java
3. java/awt/dnd/DropTargetEnterExitTest/ExtraDragEnterTest.java

Issue :
These tests are using the Util.drag() method and there was no robot.delay() added between different mouse actions in this method. This could potentially make tests using this method unstable.

Fix:
Adding a small auto delay of 100ms to fix this.

Testing:
1. All the three tests are run 15 times per platform.
2. All the tests in java/awt/dnd package run 5 times per platform
3. All the three tests are run 5 times specifically on Windows 11 platform.

-------------

Commit messages:
 - 8274597: Some of the dnd tests time out and fail intermittently

Changes: https://git.openjdk.java.net/jdk/pull/8316/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8316&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274597
  Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8316.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8316/head:pull/8316

PR: https://git.openjdk.java.net/jdk/pull/8316


From mvs at openjdk.java.net  Wed Apr 20 13:28:17 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 20 Apr 2022 13:28:17 GMT
Subject: RFR: 8274597: Some of the dnd tests time out and fail
 intermittently [v2]
In-Reply-To: <PKtuBdvWgS96mNNJUmJbDu4WHk7yfGMXrXVahFBjio8=.25fcec82-0939-43b0-adeb-a6c1c6d9fe2f@github.com>
References: <PKtuBdvWgS96mNNJUmJbDu4WHk7yfGMXrXVahFBjio8=.25fcec82-0939-43b0-adeb-a6c1c6d9fe2f@github.com>
Message-ID: <-M3RkI7ibFy3E3pyMdIyr-7-WWbZQXFo_4no53mvgDY=.761ad3d4-ff6c-4453-a328-173492e14616@github.com>

> These dnd tests fails with a time out intermittently in some machines(mostly Windows 11) which creates frequent noise in CI.
> 1. java/awt/dnd/AcceptDropMultipleTimes/AcceptDropMultipleTimes.java
> 2. java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java
> 3. java/awt/dnd/DropTargetEnterExitTest/ExtraDragEnterTest.java
> 
> Issue :
> These tests are using the Util.drag() method and there was no robot.delay() added between different mouse actions in this method. This could potentially make tests using this method unstable.
> 
> Fix:
> Adding a small auto delay of 100ms to fix this.
> 
> Testing:
> 1. All the three tests are run 15 times per platform.
> 2. All the tests in java/awt/dnd package run 5 times per platform
> 3. All the three tests are run 5 times specifically on Windows 11 platform.

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Added blank line at end of file

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8316/files
  - new: https://git.openjdk.java.net/jdk/pull/8316/files/1a1657a0..f008f89a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8316&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8316&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8316.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8316/head:pull/8316

PR: https://git.openjdk.java.net/jdk/pull/8316


From zgu at openjdk.java.net  Wed Apr 20 13:56:14 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 20 Apr 2022 13:56:14 GMT
Subject: RFR: 8284956: Potential leak awtImageData/color_data when initializes
 X11GraphicsEnvironment
Message-ID: <3POzEJ3BfvLSZncFAN7pluxsSz9_UB_wyeCMV53X-CQ=.e24bef4e-3638-4338-bd3e-3d341e21428a@github.com>

During initializing native data of `X11GraphicsEnvironment`, a single `AwtGraphicsConfigData` is used/reused, not only failed cases, but also succeeded cases. So `AwtGraphicsConfigData` internal states need to be cleanup properly to avoid memory leaks.

Test:
- [x] jdk_awt

-------------

Commit messages:
 - Merge branch 'master' into JDK-8284956-memleak_awtImageData_awt_allocate_colors
 - cleanup
 - v1
 - v0

Changes: https://git.openjdk.java.net/jdk/pull/8317/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8317&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284956
  Stats: 36 lines in 1 file changed: 25 ins; 4 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8317.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8317/head:pull/8317

PR: https://git.openjdk.java.net/jdk/pull/8317


From kevinw at openjdk.java.net  Wed Apr 20 14:04:32 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 20 Apr 2022 14:04:32 GMT
Subject: RFR: 8284853: Fix various 'expected' typo [v2]
In-Reply-To: <b2zhGMW2RG0f8ZRDrnI8nSfW-JeuZx8-DNvJaGRXu4g=.dcfbe0fb-6f7c-4f46-8fbe-458a42f7ca21@github.com>
References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
 <bisAVGnhNiqxb9oNb7lsqrjIO84qDRUeqyfw7p7jSME=.e2b1b6c3-fc70-4b5b-8cb2-d1987de9a7dd@github.com>
 <rNQ6IxlRdqzXlRKEfw2Hnyn7pI5_h3ydBV_grUrKfe0=.82d95656-bdd3-4607-a12d-5964ac33f53a@github.com>
 <b2zhGMW2RG0f8ZRDrnI8nSfW-JeuZx8-DNvJaGRXu4g=.dcfbe0fb-6f7c-4f46-8fbe-458a42f7ca21@github.com>
Message-ID: <eqgDmfDmNbkCo4R5oiilfxQxAs12V1ZP453zph4DSms=.1595dc28-ee07-43e1-b36d-4e2bc0fb3e36@github.com>

On Thu, 14 Apr 2022 18:04:16 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> I found [yet another typo](https://github.com/kelthuzadx/jdk/commit/acb9e15bc0bf5395d1c0875f36992f692734f948) ...

I didn't think "JVMInvokeMethodSlack" was a typo.  I think it's the idea of "slack space" meaning leftover space.  We require a certain amount of this space.  We need some slack on the stack, in order to invoke.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8231


From duke at openjdk.java.net  Wed Apr 20 16:03:49 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 16:03:49 GMT
Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int)
Message-ID: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>

These are the changes that too many to be reviewed in 8186958, thus split some of them out.

-------------

Commit messages:
 - 9073085: ues HashMap.newHashMap to replace new HashMap(int)

Changes: https://git.openjdk.java.net/jdk/pull/8301/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285149
  Stats: 36 lines in 20 files changed: 0 ins; 0 del; 36 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8301.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301

PR: https://git.openjdk.java.net/jdk/pull/8301


From avu at openjdk.java.net  Wed Apr 20 16:04:28 2022
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Wed, 20 Apr 2022 16:04:28 GMT
Subject: RFR: 8283794: CCE in XRTextRenderer.drawGlyphList and
 XRMaskFill.MaskFill [v2]
In-Reply-To: <DUAewBeEgdp4lPyzPkOHPTfKi97a6oosRpOC7kAsa78=.3739feac-debf-426d-8361-52b151a43685@github.com>
References: <GD4NAkuLptwylcQOI8VBAXXI1rY7ycgz8O2NvPmhIOc=.f2c8334e-d2eb-4717-92a1-de2f9ed301b6@github.com>
 <VE3eRPzRlyCMFgLc0XrQrvy2pgqszE6ZC3TG7fcDvz8=.5facf5d5-668b-4190-acbc-bb481524d1ac@github.com>
 <gw6R-Ys52b6soGAs2u7F6-7WiHOzduuG8jRQHs3xX90=.043d4630-576d-44e6-9fbf-b9b5e42aa8b6@github.com>
 <DUAewBeEgdp4lPyzPkOHPTfKi97a6oosRpOC7kAsa78=.3739feac-debf-426d-8361-52b151a43685@github.com>
Message-ID: <IxYhoAQQO_AGYVo-rz8P_iml-h_ZZIlB4SJpTER0Tt4=.08a2baef-6024-479a-ba72-812040f2f1cf@github.com>

On Mon, 18 Apr 2022 11:36:33 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> I am on vacation this week. I will review this PR on priority next week.
>
>> Looks fine, I suggest checking the fix via mach5. @aghaisas please take a look.
> 
> The fix looks good. Also, the mach5 run is green with this change.
> @avu, is it possible to add an automated test?

@aghaisas actually we have one test/jdk/sun/java2d/ClassCastExceptionForInvalidSurface.java

-------------

PR: https://git.openjdk.java.net/jdk/pull/8015


From psadhukhan at openjdk.java.net  Wed Apr 20 16:05:28 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 20 Apr 2022 16:05:28 GMT
Subject: RFR: 8208565: [TEST_BUG]
 javax\swing\PopupFactory\6276087\NonOpaquePopupMenuTest.java throws NPE
In-Reply-To: <DmXd07y2BGuoEk_ocIftawU6FoCTUfzwmuaSxa9px2M=.018977f0-14c1-41f3-be46-a3d430b37773@github.com>
References: <DmXd07y2BGuoEk_ocIftawU6FoCTUfzwmuaSxa9px2M=.018977f0-14c1-41f3-be46-a3d430b37773@github.com>
Message-ID: <MeOs_LvQM_j7YjHTtWKNpoMY1CgbrZOLDhyctR-bLdg=.5660277d-1802-4ad9-8465-db03efa09397@github.com>

On Mon, 18 Apr 2022 07:11:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing in the past owing to NPE while accessing JMenu probably owing to fact the test did not wait for UI to be visible before starting the test, so added a delay after the frame is made visible. Also, added disposal of frame.
> Also, it seems JDK-8213535 fix might be having a positive impact on this test.
> 
> Several iterations of this test in all platforms have passed (link in JBS).

Any reviewers for this test fix?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8282


From avu at openjdk.java.net  Wed Apr 20 16:14:12 2022
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Wed, 20 Apr 2022 16:14:12 GMT
Subject: RFR: 8283794: CCE in XRTextRenderer.drawGlyphList and
 XRMaskFill.MaskFill [v3]
In-Reply-To: <GD4NAkuLptwylcQOI8VBAXXI1rY7ycgz8O2NvPmhIOc=.f2c8334e-d2eb-4717-92a1-de2f9ed301b6@github.com>
References: <GD4NAkuLptwylcQOI8VBAXXI1rY7ycgz8O2NvPmhIOc=.f2c8334e-d2eb-4717-92a1-de2f9ed301b6@github.com>
Message-ID: <Y6ihZoI5QOf9r2GjLgLC20CVg2WSbhKq7Nw7mEc5qkg=.a424151a-bd9e-4090-9caa-0dea9d47c1ad@github.com>

> Throwing InvalidPipeException for incompatible surfaces

Alexey Ushakov has updated the pull request incrementally with two additional commits since the last revision:

 - 8283794: CCE in XRTextRenderer.drawGlyphList and XRMaskFill.MaskFill
   
   Copyright correction
 - 8283794: CCE in XRTextRenderer.drawGlyphList and XRMaskFill.MaskFill
   
   Updated regression test with bugID

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8015/files
  - new: https://git.openjdk.java.net/jdk/pull/8015/files/d9a132ef..390cd480

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8015&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8015&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8015.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8015/head:pull/8015

PR: https://git.openjdk.java.net/jdk/pull/8015


From duke at openjdk.java.net  Wed Apr 20 16:24:06 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Wed, 20 Apr 2022 16:24:06 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v2]
In-Reply-To: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
Message-ID: <F1TwKOY3z35DLh6riDnJOMdHj9-tN1q0UrpoJSXQiR4=.ebc417f2-61e2-4168-b9ea-245b4ded25ad@github.com>

> The exisiting manual test case tests different html styles of JTabbedPane tab title. The tab with "big" as title is seen to be clipped on Aqua LAF for larger font-size. In other LAFs it is observed that bigger font-size can be accommodated without clipping.
> 
> The following approaches were evaluated before considering it as not a test issue -
> 
> - Aqua LAF has a different tab style compared to other LAFs as seen in the screenshot below. Limiting font size on Aqua LAF requires scaling down the text which might be incompatible with Aqua LAF.
> 
> - Removing existing constraints on text and icon is incompatible for Aqua LAF.
> 
> Since the above two approaches are incompatible with Aqua and it is not a test issue, a note has been added about clipped text and this test has been removed from problem list
> 
> ![image](https://user-images.githubusercontent.com/95945681/164093604-ca7ecbc3-09c2-4338-bd2a-f8c81c12f360.png)

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  changed font-size to 3

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8307/files
  - new: https://git.openjdk.java.net/jdk/pull/8307/files/aca2d2e6..951c0725

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8307&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8307&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8307.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8307/head:pull/8307

PR: https://git.openjdk.java.net/jdk/pull/8307


From duke at openjdk.java.net  Wed Apr 20 16:24:07 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Wed, 20 Apr 2022 16:24:07 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v2]
In-Reply-To: <UYtSCOmEQ9-zCA1X8_sK25lyyJW0_PygewDMezdaVQI=.40a415a2-844c-4a9f-a651-489a4d21cf60@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
 <UYtSCOmEQ9-zCA1X8_sK25lyyJW0_PygewDMezdaVQI=.40a415a2-844c-4a9f-a651-489a4d21cf60@github.com>
Message-ID: <1snXeQsA-i3WSAYcqvmqqWAIJ-ns0bMONSJGgSv_TMs=.049a06f2-c717-45e7-ad88-6af4c3fc1941@github.com>

On Wed, 20 Apr 2022 08:36:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changed font-size to 3
>
> test/jdk/javax/swing/JTabbedPane/4209065/bug4209065.java line 59:
> 
>> 57:                       + "fit the tab.</center></html>";
>> 58:         tp.addTab("<html><center><font size=+2>big</font></center></html>",
>> 59:                 new JLabel(text));
> 
> If you are saying text may not fit the tab, then I guess no need to change font size from +3 to +2, leave it as it is..

@prsadhuk Font-size of +2 is where it starts to get clipped but as you suggested we can change it back to +3 because of the included note. Updated the test case.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8307


From duke at openjdk.java.net  Wed Apr 20 16:27:36 2022
From: duke at openjdk.java.net (liach)
Date: Wed, 20 Apr 2022 16:27:36 GMT
Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int)
In-Reply-To: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
Message-ID: <LNr5eBXHxyrGXyQlFUv2XMd1MjqR6IXTM6IK8iI8lbY=.0c03ce0e-587b-40f7-b145-5eb1a32c902f@github.com>

On Tue, 19 Apr 2022 17:44:10 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> These are the changes that too many to be reviewed in 8186958, thus split some of them out.

Would you consider replacing usages of `new HashMap<>(size, 1)`, such as in `AnnotationInvocationHandler`, as well? Such maps have a smaller table and are more likely to have collisions than `HashMap.newHashMap(size)`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8301


From psadhukhan at openjdk.java.net  Wed Apr 20 16:41:25 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 20 Apr 2022 16:41:25 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v2]
In-Reply-To: <F1TwKOY3z35DLh6riDnJOMdHj9-tN1q0UrpoJSXQiR4=.ebc417f2-61e2-4168-b9ea-245b4ded25ad@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
 <F1TwKOY3z35DLh6riDnJOMdHj9-tN1q0UrpoJSXQiR4=.ebc417f2-61e2-4168-b9ea-245b4ded25ad@github.com>
Message-ID: <RtZMKMpcmcMepoQsYQ9oZ3CxY9eqVHKfEfDCM0z3diI=.28d688a6-99c5-4cf2-b026-dee9703fbb77@github.com>

On Wed, 20 Apr 2022 16:24:06 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> The exisiting manual test case tests different html styles of JTabbedPane tab title. The tab with "big" as title is seen to be clipped on Aqua LAF for larger font-size. In other LAFs it is observed that bigger font-size can be accommodated without clipping.
>> 
>> The following approaches were evaluated before considering it as not a test issue -
>> 
>> - Aqua LAF has a different tab style compared to other LAFs as seen in the screenshot below. Limiting font size on Aqua LAF requires scaling down the text which might be incompatible with Aqua LAF.
>> 
>> - Removing existing constraints on text and icon is incompatible for Aqua LAF.
>> 
>> Since the above two approaches are incompatible with Aqua and it is not a test issue, a note has been added about clipped text and this test has been removed from problem list
>> 
>> ![image](https://user-images.githubusercontent.com/95945681/164093604-ca7ecbc3-09c2-4338-bd2a-f8c81c12f360.png)
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed font-size to 3

looks ok. 
You should consider removing "The tab title may
 * not always fit within the tab." from the summary as it should be what the test is supposed to test. Intricate details are already put in the instructions.
 Also @author tab should be removed.

-------------

Marked as reviewed by psadhukhan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8307


From kizune at openjdk.java.net  Wed Apr 20 16:51:35 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 20 Apr 2022 16:51:35 GMT
Subject: Integrated: 8266247: Swing test bug7154030.java sometimes fails on
 macOS 11 ARM
In-Reply-To: <6NjM3IIB8sz7952nBBPoh6GX3z7Oj_wrAGmi9id71ws=.d997e533-28de-4e07-980b-0e5e7fbc7990@github.com>
References: <6NjM3IIB8sz7952nBBPoh6GX3z7Oj_wrAGmi9id71ws=.d997e533-28de-4e07-980b-0e5e7fbc7990@github.com>
Message-ID: <fVqUU73BafZJvFRQQbyB7O3hrB6yTF8iJamF47aropM=.99227522-bc2b-405b-b5f8-35c87381d7cc@github.com>

On Wed, 20 Apr 2022 04:52:08 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Change background and foreground colors to white and black to avoid color shift problems.

This pull request has now been integrated.

Changeset: 018017a9
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/018017a9175cbfe02e9db0db402ca2aa689ac587
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8266247: Swing test bug7154030.java sometimes fails on macOS 11 ARM

Reviewed-by: psadhukhan

-------------

PR: https://git.openjdk.java.net/jdk/pull/8313


From duke at openjdk.java.net  Wed Apr 20 16:53:33 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Wed, 20 Apr 2022 16:53:33 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v3]
In-Reply-To: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
Message-ID: <05K-K4EXhEOwcpYe3s-nyiNSQnmIzS_m1fj_tYiRYLw=.f4f04a43-a55a-4835-b0d8-a13e36a2241f@github.com>

> The exisiting manual test case tests different html styles of JTabbedPane tab title. The tab with "big" as title is seen to be clipped on Aqua LAF for larger font-size. In other LAFs it is observed that bigger font-size can be accommodated without clipping.
> 
> The following approaches were evaluated before considering it as not a test issue -
> 
> - Aqua LAF has a different tab style compared to other LAFs as seen in the screenshot below. Limiting font size on Aqua LAF requires scaling down the text which might be incompatible with Aqua LAF.
> 
> - Removing existing constraints on text and icon is incompatible for Aqua LAF.
> 
> Since the above two approaches are incompatible with Aqua and it is not a test issue, a note has been added about clipped text and this test has been removed from problem list
> 
> ![image](https://user-images.githubusercontent.com/95945681/164093604-ca7ecbc3-09c2-4338-bd2a-f8c81c12f360.png)

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  test summary updated

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8307/files
  - new: https://git.openjdk.java.net/jdk/pull/8307/files/951c0725..521d2790

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8307&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8307&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8307.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8307/head:pull/8307

PR: https://git.openjdk.java.net/jdk/pull/8307


From duke at openjdk.java.net  Wed Apr 20 16:53:35 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Wed, 20 Apr 2022 16:53:35 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v2]
In-Reply-To: <RtZMKMpcmcMepoQsYQ9oZ3CxY9eqVHKfEfDCM0z3diI=.28d688a6-99c5-4cf2-b026-dee9703fbb77@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
 <F1TwKOY3z35DLh6riDnJOMdHj9-tN1q0UrpoJSXQiR4=.ebc417f2-61e2-4168-b9ea-245b4ded25ad@github.com>
 <RtZMKMpcmcMepoQsYQ9oZ3CxY9eqVHKfEfDCM0z3diI=.28d688a6-99c5-4cf2-b026-dee9703fbb77@github.com>
Message-ID: <zrO7zLiQ_ppVfSVIjRqeouVJEFes-FvzbGb8MThLiL8=.3a0ca61a-2733-4f69-bfc5-5a92ebfdff94@github.com>

On Wed, 20 Apr 2022 16:38:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> looks ok. You should consider removing "The tab title may
> 
>     * not always fit within the tab." from the summary as it should be what the test is supposed to test. Intricate details are already put in the instructions.
>       Also @author tab should be removed.

Updated test summary as suggested

-------------

PR: https://git.openjdk.java.net/jdk/pull/8307


From kizune at openjdk.java.net  Wed Apr 20 17:10:50 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 20 Apr 2022 17:10:50 GMT
Subject: RFR: 8273506: java Robot API did the 'm' keypress and caused
 /awt/event/KeyEvent/KeyCharTest/KeyCharTest.html is timing out on macOS 12
Message-ID: <jmtC1w9SyvfAg940bq60x20bVshEm5P2g7IExDWnpBk=.1cdcdbc2-881c-4cce-a2c0-73873369e0c5@github.com>

Clear the kCGEventFlagMaskSecondaryFn flag if it is set before posting keyboard events to the system queue.

-------------

Commit messages:
 - 8273506: java Robot API did the 'm' keypress and caused /awt/event/KeyEvent/KeyCharTest/KeyCharTest.html is timing out on macOS 12

Changes: https://git.openjdk.java.net/jdk/pull/8320/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8320&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273506
  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8320.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8320/head:pull/8320

PR: https://git.openjdk.java.net/jdk/pull/8320


From achung at openjdk.java.net  Wed Apr 20 17:41:26 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 20 Apr 2022 17:41:26 GMT
Subject: RFR: 8198622: java/awt/Focus/TypeAhead/TestFocusFreeze.java fails
 on mac
In-Reply-To: <8guUkZCRSqeoI9P6-bxBTJjWgQuw_nQbLcfuUeUv3MA=.0fffd884-dff4-4bdc-a522-be7cf921a72c@github.com>
References: <8guUkZCRSqeoI9P6-bxBTJjWgQuw_nQbLcfuUeUv3MA=.0fffd884-dff4-4bdc-a522-be7cf921a72c@github.com>
Message-ID: <UErGR1nP6VZawmMvzxyUIsG-Gi9VAUKoLNU1sZDoeuI=.7342c4fe-5e2f-4495-9629-c08777b4770a@github.com>

On Thu, 14 Apr 2022 21:12:07 GMT, Alisen Chung <achung at openjdk.org> wrote:

> test passes, so removing from problem list

The test passes in jdk8 through jdk11 on macos.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8254


From dbatrak at openjdk.java.net  Wed Apr 20 17:48:28 2022
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Wed, 20 Apr 2022 17:48:28 GMT
Subject: RFR: 8273506: java Robot API did the 'm' keypress and caused
 /awt/event/KeyEvent/KeyCharTest/KeyCharTest.html is timing out on macOS 12
In-Reply-To: <jmtC1w9SyvfAg940bq60x20bVshEm5P2g7IExDWnpBk=.1cdcdbc2-881c-4cce-a2c0-73873369e0c5@github.com>
References: <jmtC1w9SyvfAg940bq60x20bVshEm5P2g7IExDWnpBk=.1cdcdbc2-881c-4cce-a2c0-73873369e0c5@github.com>
Message-ID: <kaJGNAzIoSfkc2ohpvORvTdePHZFrQ0JRNDzqDyQvZ0=.207cc183-389a-4de0-a32e-2d7ad469508a@github.com>

On Wed, 20 Apr 2022 17:04:09 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Clear the kCGEventFlagMaskSecondaryFn flag if it is set before posting keyboard events to the system queue.

Just a note - with the proposed fix, some generated events will be different from those generated by a real keyboard - namely events for arrow keys and F1-F12 keys, as those have 'inherent' Fn modifier set, regardless of whether Fn key was pressed during event generation. This won't be observable from Java applications, as Java APIs don't expose Fn modifier in `KeyEvent`-s, but can theoretically make some difference when interacting with other apps (I don't know about any problematic cases currently though). If this can be considered a problem, it's possible to improve the fix by not clearing Fn flag for key events 'inherently' having that Fn modifier. Simple approach might just hard-code them, and a more robust one (but a bit more complicated as well) can determine the set of affected keycodes on Robot startup, by examining flags set by `CGEventCreateKeyboardEvent` in a 'clear' event source state.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8320


From achung at openjdk.java.net  Wed Apr 20 17:57:33 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 20 Apr 2022 17:57:33 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v9]
In-Reply-To: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
Message-ID: <AhEe_-kkkng-coIj4RCY0-S6WXrnq_k_pk-zOI8p7D4=.39a8c652-83b5-4ba8-b635-e68bee30845a@github.com>

> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  forgot to change starting x value of bottom line

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7449/files
  - new: https://git.openjdk.java.net/jdk/pull/7449/files/5d4854df..4dc1287e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7449.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7449/head:pull/7449

PR: https://git.openjdk.java.net/jdk/pull/7449


From achung at openjdk.java.net  Wed Apr 20 17:57:35 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 20 Apr 2022 17:57:35 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v8]
In-Reply-To: <oLAtmZ-nvXcaycSBywshKYbkuZimPBTKoD77xSauDQU=.2d6243ce-8651-428c-87ac-2a1ba82a7505@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oLAtmZ-nvXcaycSBywshKYbkuZimPBTKoD77xSauDQU=.2d6243ce-8651-428c-87ac-2a1ba82a7505@github.com>
Message-ID: <SEpvZ4WAyFwB5mQqDSTEJjVvsRu32jQ4_T6EFZN1RXc=.bd2c997d-b099-44e5-a4e0-bfabe9f3784c@github.com>

On Thu, 7 Apr 2022 20:24:29 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed 1.25 scaling overdraw, fixed calcs for right and bottom side borders

Made a small change with the bottom line to match the left line of the border

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From achung at openjdk.java.net  Wed Apr 20 18:05:04 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 20 Apr 2022 18:05:04 GMT
Subject: RFR: 8198622: java/awt/Focus/TypeAhead/TestFocusFreeze.java fails
 on mac [v2]
In-Reply-To: <8guUkZCRSqeoI9P6-bxBTJjWgQuw_nQbLcfuUeUv3MA=.0fffd884-dff4-4bdc-a522-be7cf921a72c@github.com>
References: <8guUkZCRSqeoI9P6-bxBTJjWgQuw_nQbLcfuUeUv3MA=.0fffd884-dff4-4bdc-a522-be7cf921a72c@github.com>
Message-ID: <ygwdpSWCc4hSCtiFjVMqNRreKPoPhDW0cfn64VEH91o=.c7bfbf6d-f5c1-4dd1-b381-46e414b82da7@github.com>

> test passes, so removing from problem list

Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge master
 - remove test from ProblemList

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8254/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8254&range=01
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8254.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8254/head:pull/8254

PR: https://git.openjdk.java.net/jdk/pull/8254


From achung at openjdk.java.net  Wed Apr 20 18:05:05 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 20 Apr 2022 18:05:05 GMT
Subject: RFR: 8198622: java/awt/Focus/TypeAhead/TestFocusFreeze.java fails
 on mac
In-Reply-To: <8guUkZCRSqeoI9P6-bxBTJjWgQuw_nQbLcfuUeUv3MA=.0fffd884-dff4-4bdc-a522-be7cf921a72c@github.com>
References: <8guUkZCRSqeoI9P6-bxBTJjWgQuw_nQbLcfuUeUv3MA=.0fffd884-dff4-4bdc-a522-be7cf921a72c@github.com>
Message-ID: <LrobyiEgm3yczdmXzY_xlvXCjjpK0sskbqAdX1t9AmA=.212c0dd5-dfc1-48f6-98c7-1698d7dc2c94@github.com>

On Thu, 14 Apr 2022 21:12:07 GMT, Alisen Chung <achung at openjdk.org> wrote:

> test passes, so removing from problem list

Heres the decoupled bug: https://bugs.openjdk.java.net/browse/JDK-8285278

-------------

PR: https://git.openjdk.java.net/jdk/pull/8254


From kizune at openjdk.java.net  Wed Apr 20 18:20:25 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 20 Apr 2022 18:20:25 GMT
Subject: RFR: 8273506: java Robot API did the 'm' keypress and caused
 /awt/event/KeyEvent/KeyCharTest/KeyCharTest.html is timing out on macOS 12
In-Reply-To: <kaJGNAzIoSfkc2ohpvORvTdePHZFrQ0JRNDzqDyQvZ0=.207cc183-389a-4de0-a32e-2d7ad469508a@github.com>
References: <jmtC1w9SyvfAg940bq60x20bVshEm5P2g7IExDWnpBk=.1cdcdbc2-881c-4cce-a2c0-73873369e0c5@github.com>
 <kaJGNAzIoSfkc2ohpvORvTdePHZFrQ0JRNDzqDyQvZ0=.207cc183-389a-4de0-a32e-2d7ad469508a@github.com>
Message-ID: <wZJdEny72PgfgmaTC0ixAkWteehTTJyOEFlBzbqjjrk=.197d3b3e-6e35-478f-ac5f-6946fc5b9896@github.com>

On Wed, 20 Apr 2022 17:45:04 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> Just a note - with the proposed fix, some generated events will be different from those generated by a real keyboard - namely events for arrow keys and F1-F12 keys

As far as i can tell they are not different, the Quartz layer adds these flags back for the composite keys so functionally there is no difference even when we interact with the external applications. The problem was that Quartz code does not clear them when events are processed and that is what caused the issue on AWT Robot side of things.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8320


From duke at openjdk.java.net  Wed Apr 20 18:32:22 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 18:32:22 GMT
Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int)
 [v2]
In-Reply-To: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
Message-ID: <vosOPRVEkanQrHXgADYyNl1zqUSskcEvnQKJsDt1lkE=.0f13b7c5-935c-4706-bfbe-338a2255a173@github.com>

> These are the changes that too many to be reviewed in 8186958, thus split some of them out.

XenoAmess has updated the pull request incrementally with two additional commits since the last revision:

 - add more replaces
 - add more replaces

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8301/files
  - new: https://git.openjdk.java.net/jdk/pull/8301/files/2ac4d7bc..28afb90b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=00-01

  Stats: 109 lines in 64 files changed: 0 ins; 10 del; 99 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8301.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301

PR: https://git.openjdk.java.net/jdk/pull/8301


From duke at openjdk.java.net  Wed Apr 20 19:24:25 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 19:24:25 GMT
Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int)
 [v3]
In-Reply-To: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
Message-ID: <K5smO4U1soQAppd1LY9JqanDnB5mXk6GccdIh_0xrxQ=.44138af7-abb8-4a9d-9a21-9258befa0ee9@github.com>

> These are the changes that too many to be reviewed in 8186958, thus split some of them out.

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  add more replaces

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8301/files
  - new: https://git.openjdk.java.net/jdk/pull/8301/files/28afb90b..4f2d4838

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=01-02

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8301.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301

PR: https://git.openjdk.java.net/jdk/pull/8301


From prr at openjdk.java.net  Wed Apr 20 19:34:27 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 20 Apr 2022 19:34:27 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v3]
In-Reply-To: <05K-K4EXhEOwcpYe3s-nyiNSQnmIzS_m1fj_tYiRYLw=.f4f04a43-a55a-4835-b0d8-a13e36a2241f@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
 <05K-K4EXhEOwcpYe3s-nyiNSQnmIzS_m1fj_tYiRYLw=.f4f04a43-a55a-4835-b0d8-a13e36a2241f@github.com>
Message-ID: <aO7hDEl9gduVOU09-mbF4huGKEfOLGtGLHwxT4nMDDw=.8b3be4a8-db82-40c8-9d3a-62d98216fb51@github.com>

On Wed, 20 Apr 2022 16:53:33 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> The exisiting manual test case tests different html styles of JTabbedPane tab title. The tab with "big" as title is seen to be clipped on Aqua LAF for larger font-size. In other LAFs it is observed that bigger font-size can be accommodated without clipping.
>> 
>> The following approaches were evaluated before considering it as not a test issue -
>> 
>> - Aqua LAF has a different tab style compared to other LAFs as seen in the screenshot below. Limiting font size on Aqua LAF requires scaling down the text which might be incompatible with Aqua LAF.
>> 
>> - Removing existing constraints on text and icon is incompatible for Aqua LAF.
>> 
>> Since the above two approaches are incompatible with Aqua and it is not a test issue, a note has been added about clipped text and this test has been removed from problem list
>> 
>> ![image](https://user-images.githubusercontent.com/95945681/164093604-ca7ecbc3-09c2-4338-bd2a-f8c81c12f360.png)
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test summary updated

test/jdk/javax/swing/JTabbedPane/4209065/bug4209065.java line 55:

> 53:                       + "<br>the descriptions, press <em><b>PASS</b></em><br>"
> 54:                       + "<br> NOTE: the text (tab title) may not always "
> 55:                       + "fit the tab.</center></html>";

How about 
NOTE: where a large font is used, the text may be larger than the tab height but this is OK and not a failure.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8307


From prr at openjdk.java.net  Wed Apr 20 19:38:25 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 20 Apr 2022 19:38:25 GMT
Subject: RFR: 8284993: Replace System.exit call in swing tests with
 RuntimeException [v3]
In-Reply-To: <cxqxUjjA6LqzoSXo18IplpFjIzb07bRF1mXiQrHrJLg=.30416b7b-a914-4d74-9bf5-004a882ce279@github.com>
References: <HpC4smoyLOHwI71LRFJ6DUrsnsujjgLQHM0VE6dsDTc=.6730db17-3b19-4eac-bd54-8a9f253d5f5f@github.com>
 <cxqxUjjA6LqzoSXo18IplpFjIzb07bRF1mXiQrHrJLg=.30416b7b-a914-4d74-9bf5-004a882ce279@github.com>
Message-ID: <POx_-z5UbsSLy7Es7idYOsy1VDCevJO5tHXbDruEaIg=.966193a2-7efc-4a61-ba0c-1ac5bebb43b6@github.com>

On Wed, 20 Apr 2022 10:46:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Few swing tests call System.exit() which might stop the test harness from executing further tests if any of the test fail. We should replace with RuntimeException.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

test/jdk/javax/swing/JComboBox/8019180/Test8019180.java line 74:

> 72:                 if (0 > this.test.getSelectedIndex()) {
> 73:                     System.err.println("ERROR: no selection");
> 74:                     throw new RuntimeException("Combobox not selected");

So this is relying on jtreg to catch exceptions not handled by a thread ?
Wouldn't it be better to flag the failure and have it thrown by the main thread ?

BTW since all the client tests are run in othervm mode, System.exit() isn't a real problem but it is still fine to fix this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8293


From duke at openjdk.java.net  Wed Apr 20 20:07:26 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Wed, 20 Apr 2022 20:07:26 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v3]
In-Reply-To: <aO7hDEl9gduVOU09-mbF4huGKEfOLGtGLHwxT4nMDDw=.8b3be4a8-db82-40c8-9d3a-62d98216fb51@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
 <05K-K4EXhEOwcpYe3s-nyiNSQnmIzS_m1fj_tYiRYLw=.f4f04a43-a55a-4835-b0d8-a13e36a2241f@github.com>
 <aO7hDEl9gduVOU09-mbF4huGKEfOLGtGLHwxT4nMDDw=.8b3be4a8-db82-40c8-9d3a-62d98216fb51@github.com>
Message-ID: <wAclp9gME1gs8Cef_S4GjLtfqnO8mfqVpXxX4F3w8-c=.af0801e5-de91-4275-822c-9a29a7dff57e@github.com>

On Wed, 20 Apr 2022 19:30:49 GMT, Phil Race <prr at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test summary updated
>
> test/jdk/javax/swing/JTabbedPane/4209065/bug4209065.java line 55:
> 
>> 53:                       + "<br>the descriptions, press <em><b>PASS</b></em><br>"
>> 54:                       + "<br> NOTE: the text (tab title) may not always "
>> 55:                       + "fit the tab.</center></html>";
> 
> How about 
> NOTE: where a large font is used, the text may be larger than the tab height but this is OK and not a failure.

@prrace Sounds more clear. I'm currently working on changing the test case to use PassFailFrame as well and will include this change along with the other changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8307


From duke at openjdk.java.net  Wed Apr 20 21:25:26 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Wed, 20 Apr 2022 21:25:26 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v4]
In-Reply-To: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
Message-ID: <m8YQhhM88nD0h6Hr9k_CxyhO3wSXSUyp17B57e3Gbto=.dfbe54c9-57ab-424a-adc8-5db12f784ebe@github.com>

> The exisiting manual test case tests different html styles of JTabbedPane tab title. The tab with "big" as title is seen to be clipped on Aqua LAF for larger font-size. In other LAFs it is observed that bigger font-size can be accommodated without clipping.
> 
> The following approaches were evaluated before considering it as not a test issue -
> 
> - Aqua LAF has a different tab style compared to other LAFs as seen in the screenshot below. Limiting font size on Aqua LAF requires scaling down the text which might be incompatible with Aqua LAF.
> 
> - Removing existing constraints on text and icon is incompatible for Aqua LAF.
> 
> Since the above two approaches are incompatible with Aqua and it is not a test issue, a note has been added about clipped text and this test has been removed from problem list
> 
> ![image](https://user-images.githubusercontent.com/95945681/164093604-ca7ecbc3-09c2-4338-bd2a-f8c81c12f360.png)

Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - merging master
 - test summary updated
 - changed font-size to 3
 - expanded imports
 - JTabbedPane test case changes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8307/files
  - new: https://git.openjdk.java.net/jdk/pull/8307/files/521d2790..b1491b12

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8307&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8307&range=02-03

  Stats: 9803 lines in 339 files changed: 6702 ins; 1723 del; 1378 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8307.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8307/head:pull/8307

PR: https://git.openjdk.java.net/jdk/pull/8307


From prr at openjdk.java.net  Wed Apr 20 23:20:01 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 20 Apr 2022 23:20:01 GMT
Subject: RFR: 8285094: Test java/awt/Frame/InvisibleOwner/InvisibleOwner.java
 failing on Linux
Message-ID: <nZJd4Qchm9OYGaFr3iBBm3XdYmqWXHzjfLElnUaCL90=.2fa7fc8c-23e2-46df-a5c5-acb33e7bf5fc@github.com>

As discussed in https://bugs.openjdk.java.net/browse/JDK-8285094 it seems that the test
java/awt/Frame/GetGraphicsStressTest/GetGraphicsStressTest.java destabilises the Xserver.
This causes java/awt/Frame/InvisibleOwner/InvisibleOwner.java to fail and even before that
other tests which do  pass are not visibly behaving as expected.

I didn't find any Xserver logs of "bad stuff" happening so it just seems like the Xserver was
having trouble keeping up and JDK was behaving correctly as it could despite the Xserver sending
lots of requests to repaint.

Just the "sleep" at the end of GetGraphicsStressTest.java seems to be enough but I'd already
reworked InvisibleOwner.java and I'd like to think it is a bit better than before.

-------------

Commit messages:
 - 8285094
 - 8285094

Changes: https://git.openjdk.java.net/jdk/pull/8312/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8312&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285094
  Stats: 138 lines in 2 files changed: 74 ins; 9 del; 55 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8312.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8312/head:pull/8312

PR: https://git.openjdk.java.net/jdk/pull/8312


From duke at openjdk.java.net  Wed Apr 20 23:38:32 2022
From: duke at openjdk.java.net (lukeu)
Date: Wed, 20 Apr 2022 23:38:32 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v8]
In-Reply-To: <SEpvZ4WAyFwB5mQqDSTEJjVvsRu32jQ4_T6EFZN1RXc=.bd2c997d-b099-44e5-a4e0-bfabe9f3784c@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <oLAtmZ-nvXcaycSBywshKYbkuZimPBTKoD77xSauDQU=.2d6243ce-8651-428c-87ac-2a1ba82a7505@github.com>
 <SEpvZ4WAyFwB5mQqDSTEJjVvsRu32jQ4_T6EFZN1RXc=.bd2c997d-b099-44e5-a4e0-bfabe9f3784c@github.com>
Message-ID: <hA_lLI8OO0LgInfD4plWbb6EAzHR09IBe_6Ae386sMQ=.d1e6d33d-f14f-4fa1-be01-cf3744953b83@github.com>

On Wed, 20 Apr 2022 17:53:24 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Made a small change with the bottom line to match the left line of the border

Great, that looks like it'll fix it so I won't test again, I'll defer to the others now for the code review. (I'd be happy to chip in there too, but I'm not sure if "random guy on github" is qualified/authorized to?)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7449


From duke at openjdk.java.net  Wed Apr 20 23:55:05 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Wed, 20 Apr 2022 23:55:05 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v5]
In-Reply-To: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
Message-ID: <eaCCY61HB7mlF1p_jRPAC887VXoRx6jm5BoI7JyQLW4=.9129f134-0b17-4d41-bbc3-089aff822bac@github.com>

> The exisiting manual test case tests different html styles of JTabbedPane tab title. The tab with "big" as title is seen to be clipped on Aqua LAF for larger font-size. In other LAFs it is observed that bigger font-size can be accommodated without clipping.
> 
> The following approaches were evaluated before considering it as not a test issue -
> 
> - Aqua LAF has a different tab style compared to other LAFs as seen in the screenshot below. Limiting font size on Aqua LAF requires scaling down the text which might be incompatible with Aqua LAF.
> 
> - Removing existing constraints on text and icon is incompatible for Aqua LAF.
> 
> Since the above two approaches are incompatible with Aqua and it is not a test issue, a note has been added about clipped text and this test has been removed from problem list
> 
> ![image](https://user-images.githubusercontent.com/95945681/164093604-ca7ecbc3-09c2-4338-bd2a-f8c81c12f360.png)

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  changed test case to use PassFailJFrame instead of Applet

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8307/files
  - new: https://git.openjdk.java.net/jdk/pull/8307/files/b1491b12..2fd26ad6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8307&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8307&range=03-04

  Stats: 103 lines in 2 files changed: 38 ins; 51 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8307.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8307/head:pull/8307

PR: https://git.openjdk.java.net/jdk/pull/8307


From duke at openjdk.java.net  Wed Apr 20 23:55:08 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Wed, 20 Apr 2022 23:55:08 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v4]
In-Reply-To: <m8YQhhM88nD0h6Hr9k_CxyhO3wSXSUyp17B57e3Gbto=.dfbe54c9-57ab-424a-adc8-5db12f784ebe@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
 <m8YQhhM88nD0h6Hr9k_CxyhO3wSXSUyp17B57e3Gbto=.dfbe54c9-57ab-424a-adc8-5db12f784ebe@github.com>
Message-ID: <YxD9VlA7dOWBVf_fxWyW2RjCqrIrUxhER6xaK58ajKE=.f38deefa-cade-416a-9117-b8838385ac58@github.com>

On Wed, 20 Apr 2022 21:25:26 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> The exisiting manual test case tests different html styles of JTabbedPane tab title. The tab with "big" as title is seen to be clipped on Aqua LAF for larger font-size. In other LAFs it is observed that bigger font-size can be accommodated without clipping.
>> 
>> The following approaches were evaluated before considering it as not a test issue -
>> 
>> - Aqua LAF has a different tab style compared to other LAFs as seen in the screenshot below. Limiting font size on Aqua LAF requires scaling down the text which might be incompatible with Aqua LAF.
>> 
>> - Removing existing constraints on text and icon is incompatible for Aqua LAF.
>> 
>> Since the above two approaches are incompatible with Aqua and it is not a test issue, a note has been added about clipped text and this test has been removed from problem list
>> 
>> ![image](https://user-images.githubusercontent.com/95945681/164093604-ca7ecbc3-09c2-4338-bd2a-f8c81c12f360.png)
>
> Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - merging master
>  - test summary updated
>  - changed font-size to 3
>  - expanded imports
>  - JTabbedPane test case changes

Updated the test case to use `PassFailJFrame` instead of `Applet` and deleted bug4209065.html file used previously by Applet for this test case.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8307


From psadhukhan at openjdk.java.net  Thu Apr 21 04:18:20 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 21 Apr 2022 04:18:20 GMT
Subject: RFR: 8284993: Replace System.exit call in swing tests with
 RuntimeException [v4]
In-Reply-To: <HpC4smoyLOHwI71LRFJ6DUrsnsujjgLQHM0VE6dsDTc=.6730db17-3b19-4eac-bd54-8a9f253d5f5f@github.com>
References: <HpC4smoyLOHwI71LRFJ6DUrsnsujjgLQHM0VE6dsDTc=.6730db17-3b19-4eac-bd54-8a9f253d5f5f@github.com>
Message-ID: <kd0QIzNJGR9Sjj87TeigCUsLKoZJY4_xbKlnxHh5-G8=.e0601a3b-bd01-43c0-b408-6d910a242a2a@github.com>

> Few swing tests call System.exit() which might stop the test harness from executing further tests if any of the test fail. We should replace with RuntimeException.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  throw exception in main

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8293/files
  - new: https://git.openjdk.java.net/jdk/pull/8293/files/2c8508a6..7d49634d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8293&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8293&range=02-03

  Stats: 23 lines in 1 file changed: 5 ins; 3 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8293.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8293/head:pull/8293

PR: https://git.openjdk.java.net/jdk/pull/8293


From psadhukhan at openjdk.java.net  Thu Apr 21 04:33:24 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 21 Apr 2022 04:33:24 GMT
Subject: RFR: 8284993: Replace System.exit call in swing tests with
 RuntimeException [v3]
In-Reply-To: <POx_-z5UbsSLy7Es7idYOsy1VDCevJO5tHXbDruEaIg=.966193a2-7efc-4a61-ba0c-1ac5bebb43b6@github.com>
References: <HpC4smoyLOHwI71LRFJ6DUrsnsujjgLQHM0VE6dsDTc=.6730db17-3b19-4eac-bd54-8a9f253d5f5f@github.com>
 <cxqxUjjA6LqzoSXo18IplpFjIzb07bRF1mXiQrHrJLg=.30416b7b-a914-4d74-9bf5-004a882ce279@github.com>
 <POx_-z5UbsSLy7Es7idYOsy1VDCevJO5tHXbDruEaIg=.966193a2-7efc-4a61-ba0c-1ac5bebb43b6@github.com>
Message-ID: <FwepCedaYLKjoQp0MSMQn2CBs9mgQfe_-sF3cWgKWgI=.833e08c7-248a-46c2-817d-da3d49ed223a@github.com>

On Wed, 20 Apr 2022 19:35:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test fix
>
> test/jdk/javax/swing/JComboBox/8019180/Test8019180.java line 74:
> 
>> 72:                 if (0 > this.test.getSelectedIndex()) {
>> 73:                     System.err.println("ERROR: no selection");
>> 74:                     throw new RuntimeException("Combobox not selected");
> 
> So this is relying on jtreg to catch exceptions not handled by a thread ?
> Wouldn't it be better to flag the failure and have it thrown by the main thread ?
> 
> BTW since all the client tests are run in othervm mode, System.exit() isn't a real problem but it is still fine to fix this.

modified to throw exception in main

-------------

PR: https://git.openjdk.java.net/jdk/pull/8293


From duke at openjdk.java.net  Thu Apr 21 07:00:11 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Thu, 21 Apr 2022 07:00:11 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux [v5]
In-Reply-To: <6dun2ppw1GHei7MlyCfLlnQ27NsNRSZ5F3Y1kSWrA7E=.08fadf9c-73f4-499e-8b45-f5e3c147bd91@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
 <l8h3eiPB9RcX38ktddI1hgx1RL1ZaCZz0DlXdU-Hgjk=.d5380014-4dff-4334-8be9-fb537221f546@github.com>
 <6dun2ppw1GHei7MlyCfLlnQ27NsNRSZ5F3Y1kSWrA7E=.08fadf9c-73f4-499e-8b45-f5e3c147bd91@github.com>
Message-ID: <VTIzBcoEAB4Sqz4nM5gYE4L1g3uCm1kL5zR2D_HA1fc=.7adaaa08-5f39-4d27-8914-3db345a4d315@github.com>

On Fri, 8 Apr 2022 16:20:10 GMT, Phil Race <prr at openjdk.org> wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restored the original code in X11GraphicsDevice.java that got auto-formatted
>
> src/java.desktop/unix/classes/sun/awt/X11/XCanvasPeer.java line 90:
> 
>> 88:                 getScreenDevices()[screenNum].
>> 89:                 getDefaultConfiguration();
>> 90:         }
> 
> why did you get rid of the just in case ?
> Actually why is this method being modified at all ? 
> I mean besides adding locking ..

@prrace polite ping

-------------

PR: https://git.openjdk.java.net/jdk/pull/7182


From azvegint at openjdk.java.net  Thu Apr 21 08:07:52 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 21 Apr 2022 08:07:52 GMT
Subject: RFR: 8225777: java/awt/Mixing/MixingOnDialog.java fails on Ubuntu
Message-ID: <VQLsDzN8qiIssQllKP6jgXgc1UwWbjO3O2rS8eT8wTk=.dc8fa68c-816f-41c9-9bb8-20d503246440@github.com>

The test was failing due to it tried to place windows too close to left top corner, so they got shifted from the dock and top panel on Gnome.

Shifting all test windows fixes the issue.


Testing is green on all platforms.

-------------

Commit messages:
 - initial

Changes: https://git.openjdk.java.net/jdk/pull/8326/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8326&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8225777
  Stats: 15 lines in 2 files changed: 5 ins; 1 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8326.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8326/head:pull/8326

PR: https://git.openjdk.java.net/jdk/pull/8326


From ihse at openjdk.java.net  Thu Apr 21 08:44:15 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 21 Apr 2022 08:44:15 GMT
Subject: RFR: 8285306: Fix typos in java.desktop
Message-ID: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>

I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.

I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.

I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).

The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

-------------

Commit messages:
 - Pass #2
 - Pass #1

Changes: https://git.openjdk.java.net/jdk/pull/8328/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8328&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285306
  Stats: 1015 lines in 493 files changed: 0 ins; 0 del; 1015 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8328.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8328/head:pull/8328

PR: https://git.openjdk.java.net/jdk/pull/8328


From psadhukhan at openjdk.java.net  Thu Apr 21 08:48:27 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 21 Apr 2022 08:48:27 GMT
Subject: RFR: 8285094: Test
 java/awt/Frame/InvisibleOwner/InvisibleOwner.java failing on Linux
In-Reply-To: <nZJd4Qchm9OYGaFr3iBBm3XdYmqWXHzjfLElnUaCL90=.2fa7fc8c-23e2-46df-a5c5-acb33e7bf5fc@github.com>
References: <nZJd4Qchm9OYGaFr3iBBm3XdYmqWXHzjfLElnUaCL90=.2fa7fc8c-23e2-46df-a5c5-acb33e7bf5fc@github.com>
Message-ID: <Vo4JGg-LrcU3dOrj9rqq4J9KDXFNo9KPwpaDqoA62z0=.af03b56d-4d06-4a9a-9a23-8f7265356c73@github.com>

On Wed, 20 Apr 2022 04:13:09 GMT, Phil Race <prr at openjdk.org> wrote:

> As discussed in https://bugs.openjdk.java.net/browse/JDK-8285094 it seems that the test
> java/awt/Frame/GetGraphicsStressTest/GetGraphicsStressTest.java destabilises the Xserver.
> This causes java/awt/Frame/InvisibleOwner/InvisibleOwner.java to fail and even before that
> other tests which do  pass are not visibly behaving as expected.
> 
> I didn't find any Xserver logs of "bad stuff" happening so it just seems like the Xserver was
> having trouble keeping up and JDK was behaving correctly as it could despite the Xserver sending
> lots of requests to repaint.
> 
> Just the "sleep" at the end of GetGraphicsStressTest.java seems to be enough but I'd already
> reworked InvisibleOwner.java and I'd like to think it is a bit better than before.

Maybe a Thread.sleep(1000) is also needed after frame.setVisible(true); and also frame.dispose() as test() is called 4 times so we will give time to setup test after frame is visible and frame is disposed at test completion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8312


From aghaisas at openjdk.java.net  Thu Apr 21 09:53:28 2022
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 21 Apr 2022 09:53:28 GMT
Subject: RFR: 8283794: CCE in XRTextRenderer.drawGlyphList and
 XRMaskFill.MaskFill [v3]
In-Reply-To: <Y6ihZoI5QOf9r2GjLgLC20CVg2WSbhKq7Nw7mEc5qkg=.a424151a-bd9e-4090-9caa-0dea9d47c1ad@github.com>
References: <GD4NAkuLptwylcQOI8VBAXXI1rY7ycgz8O2NvPmhIOc=.f2c8334e-d2eb-4717-92a1-de2f9ed301b6@github.com>
 <Y6ihZoI5QOf9r2GjLgLC20CVg2WSbhKq7Nw7mEc5qkg=.a424151a-bd9e-4090-9caa-0dea9d47c1ad@github.com>
Message-ID: <nbahy3X8ZWE4IZBAxLC-ny_TV1OBXmsEaUJU4af8IJs=.a3e88030-86c5-4565-89d5-27d1c212feda@github.com>

On Wed, 20 Apr 2022 16:14:12 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Throwing InvalidPipeException for incompatible surfaces
>
> Alexey Ushakov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8283794: CCE in XRTextRenderer.drawGlyphList and XRMaskFill.MaskFill
>    
>    Copyright correction
>  - 8283794: CCE in XRTextRenderer.drawGlyphList and XRMaskFill.MaskFill
>    
>    Updated regression test with bugID

Marked as reviewed by aghaisas (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8015


From avu at openjdk.java.net  Thu Apr 21 10:00:27 2022
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Thu, 21 Apr 2022 10:00:27 GMT
Subject: Integrated: 8283794: CCE in XRTextRenderer.drawGlyphList and
 XRMaskFill.MaskFill
In-Reply-To: <GD4NAkuLptwylcQOI8VBAXXI1rY7ycgz8O2NvPmhIOc=.f2c8334e-d2eb-4717-92a1-de2f9ed301b6@github.com>
References: <GD4NAkuLptwylcQOI8VBAXXI1rY7ycgz8O2NvPmhIOc=.f2c8334e-d2eb-4717-92a1-de2f9ed301b6@github.com>
Message-ID: <YVGqZzmY0BppMtS4xKrNct9ZJlMdeTeeMB5oKQx2TYM=.ff94cb9a-2be2-47bc-9bf8-65bf86967742@github.com>

On Tue, 29 Mar 2022 10:44:51 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Throwing InvalidPipeException for incompatible surfaces

This pull request has now been integrated.

Changeset: 90983431
Author:    Alexey Ushakov <avu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/90983431c5493ea32a983bfe948ec8b32a9a28af
Stats:     129 lines in 12 files changed: 19 ins; 67 del; 43 mod

8283794: CCE in XRTextRenderer.drawGlyphList and XRMaskFill.MaskFill

Reviewed-by: serb, aghaisas

-------------

PR: https://git.openjdk.java.net/jdk/pull/8015


From psadhukhan at openjdk.java.net  Thu Apr 21 10:18:30 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 21 Apr 2022 10:18:30 GMT
Subject: Withdrawn: 8284646: Some swing test fail in macos12-aarch64 host
In-Reply-To: <MelCohsH9Jfezuli0QR2aWK6I78c5c09IT9aSWIWXys=.536ada73-ee97-4191-92d6-b29c73c4e956@github.com>
References: <MelCohsH9Jfezuli0QR2aWK6I78c5c09IT9aSWIWXys=.536ada73-ee97-4191-92d6-b29c73c4e956@github.com>
Message-ID: <MuG5FpnnnnnUif6D0ATmtwv3gsCDCgWHCQEovKbuB48=.e947a721-24bb-4e4a-ad7c-61c50276d231@github.com>

On Mon, 11 Apr 2022 08:38:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Few tests  are seen to be failing in macos12 M1 system due to slight difference in color as mentioned in [JDK-8277816](https://bugs.openjdk.java.net/browse/JDK-8277816)
> 
> It seems the color difference was around 6-7 for swing tests, so these tests are extracted out in this issue and fixed by adding tolerance.
> I could not find, in M1 osx12.3 SystemPreferences, any way to set Color Profile to sRGB IEC61966-2.1 Profile so it seems osx12.x M1 use default setting.
> 
> Several runs in CI system in all platforms including 12.x M1 pass with this change (test job link in JBS)

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8176


From psadhukhan at openjdk.java.net  Thu Apr 21 10:19:26 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 21 Apr 2022 10:19:26 GMT
Subject: Integrated: 8277816: Client tests fail on macos-Aarch64 host
In-Reply-To: <kLN8DjOu7ZQV4C1jt5pHr9axo4tmgigItGxa4IGuRrg=.21f625ef-b005-4f87-8abc-d9c3f51dc348@github.com>
References: <kLN8DjOu7ZQV4C1jt5pHr9axo4tmgigItGxa4IGuRrg=.21f625ef-b005-4f87-8abc-d9c3f51dc348@github.com>
Message-ID: <9Hgo3ybRynwB19Hrv8Kfh3IwWA4XO265nYoZ8m2adcU=.81e88e02-7691-4707-8de4-be1e7c17ed6e@github.com>

On Wed, 13 Apr 2022 07:40:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This tests was failing on macos12 M1 systems due to wrong color profile configurations set in CI systems.
> If correct sRGB IEC61966-2.1 is set, then these test passed. Test job link in JBS..
> 
> So, removing from Problem list..

This pull request has now been integrated.

Changeset: 994a439e
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/994a439e09c48100fc56b4eeccd85da1d1d2b4c3
Stats:     8 lines in 1 file changed: 0 ins; 8 del; 0 mod

8277816: Client tests fail on macos-Aarch64 host

Reviewed-by: serb, azvegint

-------------

PR: https://git.openjdk.java.net/jdk/pull/8216


From jpai at openjdk.java.net  Thu Apr 21 10:44:04 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 21 Apr 2022 10:44:04 GMT
Subject: Integrated: 8285361: ClassCastExceptionForInvalidSurface.java has an
 incorrect copyright header
Message-ID: <fnIUl0pnMcD3Cg5kBf2rzJ_ER6uegK8riaZlpev6KEA=.799b0a94-0204-40c9-8b56-e5e610235cbc@github.com>

Can I please get a review for this trivial fix to the copyright header?

-------------

Commit messages:
 - fix copyright header

Changes: https://git.openjdk.java.net/jdk/pull/8331/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8331&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285361
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8331.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8331/head:pull/8331

PR: https://git.openjdk.java.net/jdk/pull/8331


From dholmes at openjdk.java.net  Thu Apr 21 10:44:04 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 21 Apr 2022 10:44:04 GMT
Subject: Integrated: 8285361: ClassCastExceptionForInvalidSurface.java has
 an incorrect copyright header
In-Reply-To: <fnIUl0pnMcD3Cg5kBf2rzJ_ER6uegK8riaZlpev6KEA=.799b0a94-0204-40c9-8b56-e5e610235cbc@github.com>
References: <fnIUl0pnMcD3Cg5kBf2rzJ_ER6uegK8riaZlpev6KEA=.799b0a94-0204-40c9-8b56-e5e610235cbc@github.com>
Message-ID: <3ExofbybIF7AKsJLur7V6cJOFEubG-8teJCHzjwq5tI=.c7c9a7ae-e17c-4ef5-959d-c6158e8ce928@github.com>

On Thu, 21 Apr 2022 10:34:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this trivial fix to the copyright header?

Thanks for fixing.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8331


From jpai at openjdk.java.net  Thu Apr 21 10:44:04 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 21 Apr 2022 10:44:04 GMT
Subject: Integrated: 8285361: ClassCastExceptionForInvalidSurface.java has
 an incorrect copyright header
In-Reply-To: <fnIUl0pnMcD3Cg5kBf2rzJ_ER6uegK8riaZlpev6KEA=.799b0a94-0204-40c9-8b56-e5e610235cbc@github.com>
References: <fnIUl0pnMcD3Cg5kBf2rzJ_ER6uegK8riaZlpev6KEA=.799b0a94-0204-40c9-8b56-e5e610235cbc@github.com>
Message-ID: <zea8_7CRELAybRPdtbOsTYRyK910UcYzd6ae12lBSlA=.58fdbcd9-20b9-451b-ac54-7a79534b656d@github.com>

On Thu, 21 Apr 2022 10:34:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this trivial fix to the copyright header?

Thank you David for the quick review.

(Given the trivial nature of this fix and the fact that tier1 testing failed without this change, going ahead with the integration without waiting for additional reviews)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8331


From jpai at openjdk.java.net  Thu Apr 21 10:44:04 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 21 Apr 2022 10:44:04 GMT
Subject: Integrated: 8285361: ClassCastExceptionForInvalidSurface.java has an
 incorrect copyright header
In-Reply-To: <fnIUl0pnMcD3Cg5kBf2rzJ_ER6uegK8riaZlpev6KEA=.799b0a94-0204-40c9-8b56-e5e610235cbc@github.com>
References: <fnIUl0pnMcD3Cg5kBf2rzJ_ER6uegK8riaZlpev6KEA=.799b0a94-0204-40c9-8b56-e5e610235cbc@github.com>
Message-ID: <LHMlKJhO37te8SQ4G1TgchBRfZSn37l6UcUu8E0q-Cs=.3ce0e738-3595-44f8-b3ce-61f9d3eb534b@github.com>

On Thu, 21 Apr 2022 10:34:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this trivial fix to the copyright header?

This pull request has now been integrated.

Changeset: 9a905ccc
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9a905ccc5e6411c3b68277b58e7c40b405e33afc
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8285361: ClassCastExceptionForInvalidSurface.java has an incorrect copyright header

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/8331


From smandalika at openjdk.java.net  Thu Apr 21 10:58:06 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Thu, 21 Apr 2022 10:58:06 GMT
Subject: RFR: 8285305: Create an automated test for JDK-4495286
Message-ID: <tfMcUiiqM3zbwahwkdBXMSFXcHiCqyZoRJLZgekkagQ=.5392b0b4-bd49-400a-8bf0-aef5f1354d6e@github.com>

Create an automated test for [JDK-4495286](https://bugs.openjdk.java.net/browse/JDK-4495286)

AccessibleJTable.setAccessibleSelction should select rows/cols when cell selection.
When cell selection is not enabled, there is no way, using
accessibility, to select rows or columns. It seems logical that selecting a cell
using accessibility should have the same effect as clicking on a cell with the
mouse. That is, if row or column selection is enabled, then selecting a cell
should instead cause the row or column to be selected.
 The proposed test verifies that the above behavior is fixed.

This review is for migrating tests from a closed test suite to open.

Testing:
The test ran successfully on Mach5 with multiple runs (40) on windows-x64, linux-x64 and macos-x64.

-------------

Commit messages:
 - 8285305: Create an automated test for JDK-4495286

Changes: https://git.openjdk.java.net/jdk/pull/8333/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8333&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285305
  Stats: 174 lines in 1 file changed: 174 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8333.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8333/head:pull/8333

PR: https://git.openjdk.java.net/jdk/pull/8333


From dbatrak at openjdk.java.net  Thu Apr 21 11:27:29 2022
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Thu, 21 Apr 2022 11:27:29 GMT
Subject: RFR: 8273506: java Robot API did the 'm' keypress and caused
 /awt/event/KeyEvent/KeyCharTest/KeyCharTest.html is timing out on macOS 12
In-Reply-To: <jmtC1w9SyvfAg940bq60x20bVshEm5P2g7IExDWnpBk=.1cdcdbc2-881c-4cce-a2c0-73873369e0c5@github.com>
References: <jmtC1w9SyvfAg940bq60x20bVshEm5P2g7IExDWnpBk=.1cdcdbc2-881c-4cce-a2c0-73873369e0c5@github.com>
Message-ID: <-INTLEgzMkhahnEFU5otsJpsxIX-4ZLtWWNo18-O9vI=.b23dc777-0774-4578-8105-e9496fca3b37@github.com>

On Wed, 20 Apr 2022 17:04:09 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Clear the kCGEventFlagMaskSecondaryFn flag if it is set before posting keyboard events to the system queue.

I assumed that whatever keys we set on an event being posted using `CGEventPost`, are delivered unchanged to the 'receiving' applications. But I did a test, and that doesn't seem to be the case. You're right, Quartz (or some other subsystem) does set those flags before delivering the events. Sorry for the noise.
Interestingly, extending the fix to NumPad flag (that 'sticks' in the global state similarly) doesn't work in the same way - the flag isn't being added automatically for arrow keys' KeyUp event by Quartz, but that's out of scope.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8320


From azvegint at openjdk.java.net  Thu Apr 21 13:08:28 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 21 Apr 2022 13:08:28 GMT
Subject: Integrated: 8023814: Test
 java/awt/im/memoryleak/InputContextMemoryLeakTest.java fails
In-Reply-To: <FsGax91Svfmrlgpy6WEZAdKSQHNS7jZnezgPUS10txg=.1c141c87-d702-457b-8066-58d5b32501e6@github.com>
References: <FsGax91Svfmrlgpy6WEZAdKSQHNS7jZnezgPUS10txg=.1c141c87-d702-457b-8066-58d5b32501e6@github.com>
Message-ID: <3wIRV8luNUdvlze89MOJq19pumBvwGwoqprSsbosH4g=.b4d28fc9-43ce-4271-b17d-c7141aefaa31@github.com>

On Tue, 19 Apr 2022 11:48:10 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Removing the test from problem list, since I am unable to reproduce the issue even with old Ubuntu distros with jdk8.
> Bug filed against Solaris initially, but I did not test on it, since it is no longer supported.
> 
> Multiple mach5 testing is green.
> 
> `dispose` added for convenience if test is executed without jtreg.

This pull request has now been integrated.

Changeset: 42baaa3b
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/42baaa3bb8f240c04e85598d971597ae87c355b6
Stats:     9 lines in 2 files changed: 5 ins; 2 del; 2 mod

8023814: Test java/awt/im/memoryleak/InputContextMemoryLeakTest.java fails

Reviewed-by: psadhukhan

-------------

PR: https://git.openjdk.java.net/jdk/pull/8295


From azvegint at openjdk.java.net  Thu Apr 21 13:31:00 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 21 Apr 2022 13:31:00 GMT
Subject: RFR: 8129778: Few awt test fail for Solaris 11 with RuntimeException
Message-ID: <nntgIawtEjj5eQGzpFvrWv4rQvXscCv_xw2jZ13-GAk=.73f66862-88aa-4eba-bbe7-fc95e54566af@github.com>

Those tests were failing on Solaris, which is no longer supported.

They pass as they are, but decreasing of delays reduce execution time significantly:

e.g. proposed changes drops execution time from ~5min to ~2 min 
for MouseButtonsAndKeyMasksTest on my machine.

Testing is green on all platforms.

-------------

Commit messages:
 - initial

Changes: https://git.openjdk.java.net/jdk/pull/8339/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8339&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8129778
  Stats: 44 lines in 4 files changed: 22 ins; 6 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8339.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8339/head:pull/8339

PR: https://git.openjdk.java.net/jdk/pull/8339


From azvegint at openjdk.java.net  Thu Apr 21 14:48:26 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 21 Apr 2022 14:48:26 GMT
Subject: RFR: 8285094: Test
 java/awt/Frame/InvisibleOwner/InvisibleOwner.java failing on Linux
In-Reply-To: <nZJd4Qchm9OYGaFr3iBBm3XdYmqWXHzjfLElnUaCL90=.2fa7fc8c-23e2-46df-a5c5-acb33e7bf5fc@github.com>
References: <nZJd4Qchm9OYGaFr3iBBm3XdYmqWXHzjfLElnUaCL90=.2fa7fc8c-23e2-46df-a5c5-acb33e7bf5fc@github.com>
Message-ID: <4cb8q0W_V5_LF_wk_MkwVBGTfN_LcwQ0VZKKDzhdr48=.ba51c584-0460-4392-afd2-519d625078bf@github.com>

On Wed, 20 Apr 2022 04:13:09 GMT, Phil Race <prr at openjdk.org> wrote:

> As discussed in https://bugs.openjdk.java.net/browse/JDK-8285094 it seems that the test
> java/awt/Frame/GetGraphicsStressTest/GetGraphicsStressTest.java destabilises the Xserver.
> This causes java/awt/Frame/InvisibleOwner/InvisibleOwner.java to fail and even before that
> other tests which do  pass are not visibly behaving as expected.
> 
> I didn't find any Xserver logs of "bad stuff" happening so it just seems like the Xserver was
> having trouble keeping up and JDK was behaving correctly as it could despite the Xserver sending
> lots of requests to repaint.
> 
> Just the "sleep" at the end of GetGraphicsStressTest.java seems to be enough but I'd already
> reworked InvisibleOwner.java and I'd like to think it is a bit better than before.

test/jdk/java/awt/Frame/InvisibleOwner/InvisibleOwner.java line 35:

> 33: import java.awt.EventQueue;
> 34: import java.awt.Frame;
> 35: import java.awt.Graphics;

Unused import

test/jdk/java/awt/Frame/InvisibleOwner/InvisibleOwner.java line 135:

> 133:                             ownedWindowBounds.y + ownedWindowBounds.height / 2);
> 134:             robot.mousePress(InputEvent.BUTTON1_MASK);
> 135:             robot.mouseRelease(InputEvent.BUTTON1_MASK);

Nit: Shouldn't we use BUTTON1_DOWN_MASK instead of deprecated BUTTON1_MASK?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8312


From prr at openjdk.java.net  Thu Apr 21 15:23:31 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 21 Apr 2022 15:23:31 GMT
Subject: RFR: 8285094: Test
 java/awt/Frame/InvisibleOwner/InvisibleOwner.java failing on Linux [v2]
In-Reply-To: <nZJd4Qchm9OYGaFr3iBBm3XdYmqWXHzjfLElnUaCL90=.2fa7fc8c-23e2-46df-a5c5-acb33e7bf5fc@github.com>
References: <nZJd4Qchm9OYGaFr3iBBm3XdYmqWXHzjfLElnUaCL90=.2fa7fc8c-23e2-46df-a5c5-acb33e7bf5fc@github.com>
Message-ID: <1FY4ypDIGUN3Hkz3R8hN6zyJonmrErTzUlU50bijZtw=.7ea435d2-6268-4454-9c58-e98fca7c8c20@github.com>

> As discussed in https://bugs.openjdk.java.net/browse/JDK-8285094 it seems that the test
> java/awt/Frame/GetGraphicsStressTest/GetGraphicsStressTest.java destabilises the Xserver.
> This causes java/awt/Frame/InvisibleOwner/InvisibleOwner.java to fail and even before that
> other tests which do  pass are not visibly behaving as expected.
> 
> I didn't find any Xserver logs of "bad stuff" happening so it just seems like the Xserver was
> having trouble keeping up and JDK was behaving correctly as it could despite the Xserver sending
> lots of requests to repaint.
> 
> Just the "sleep" at the end of GetGraphicsStressTest.java seems to be enough but I'd already
> reworked InvisibleOwner.java and I'd like to think it is a bit better than before.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8285094

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8312/files
  - new: https://git.openjdk.java.net/jdk/pull/8312/files/d6ab588b..160b4eae

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8312&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8312&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8312.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8312/head:pull/8312

PR: https://git.openjdk.java.net/jdk/pull/8312


From prr at openjdk.java.net  Thu Apr 21 15:26:24 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 21 Apr 2022 15:26:24 GMT
Subject: RFR: 8285094: Test
 java/awt/Frame/InvisibleOwner/InvisibleOwner.java failing on Linux [v2]
In-Reply-To: <Vo4JGg-LrcU3dOrj9rqq4J9KDXFNo9KPwpaDqoA62z0=.af03b56d-4d06-4a9a-9a23-8f7265356c73@github.com>
References: <nZJd4Qchm9OYGaFr3iBBm3XdYmqWXHzjfLElnUaCL90=.2fa7fc8c-23e2-46df-a5c5-acb33e7bf5fc@github.com>
 <Vo4JGg-LrcU3dOrj9rqq4J9KDXFNo9KPwpaDqoA62z0=.af03b56d-4d06-4a9a-9a23-8f7265356c73@github.com>
Message-ID: <7Zl6pvBm-f2AI6Zce-Krcqspb-eC5myP-DBCQAIYiHI=.0542f161-427c-43db-badf-817d56e94922@github.com>

On Thu, 21 Apr 2022 08:45:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Maybe a Thread.sleep(1000) is also needed after frame.setVisible(true); and also frame.dispose() as test() is called 4 times so we will give time to setup test after frame is visible and frame is disposed at test completion.

I did not find this to be necessary. As I wrote putting a sleep at the beginning of InvisibleOwner also cures this so I am sure it is just a matter of letting things settle down AFTER the test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8312


From prr at openjdk.java.net  Thu Apr 21 15:26:25 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 21 Apr 2022 15:26:25 GMT
Subject: RFR: 8285094: Test
 java/awt/Frame/InvisibleOwner/InvisibleOwner.java failing on Linux [v2]
In-Reply-To: <4cb8q0W_V5_LF_wk_MkwVBGTfN_LcwQ0VZKKDzhdr48=.ba51c584-0460-4392-afd2-519d625078bf@github.com>
References: <nZJd4Qchm9OYGaFr3iBBm3XdYmqWXHzjfLElnUaCL90=.2fa7fc8c-23e2-46df-a5c5-acb33e7bf5fc@github.com>
 <4cb8q0W_V5_LF_wk_MkwVBGTfN_LcwQ0VZKKDzhdr48=.ba51c584-0460-4392-afd2-519d625078bf@github.com>
Message-ID: <J1EN14f--HeKT79NTNpRC4wVpFyMDgzOWfu-70y6TJA=.23d53f6e-2095-4132-8902-feb9ce25cde6@github.com>

On Thu, 21 Apr 2022 14:42:03 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8285094
>
> test/jdk/java/awt/Frame/InvisibleOwner/InvisibleOwner.java line 135:
> 
>> 133:                             ownedWindowBounds.y + ownedWindowBounds.height / 2);
>> 134:             robot.mousePress(InputEvent.BUTTON1_MASK);
>> 135:             robot.mouseRelease(InputEvent.BUTTON1_MASK);
> 
> Nit: Shouldn't we use BUTTON1_DOWN_MASK instead of deprecated BUTTON1_MASK?

That is how it was before but I fixed this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8312


From duke at openjdk.java.net  Thu Apr 21 15:31:25 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Thu, 21 Apr 2022 15:31:25 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v3]
In-Reply-To: <aO7hDEl9gduVOU09-mbF4huGKEfOLGtGLHwxT4nMDDw=.8b3be4a8-db82-40c8-9d3a-62d98216fb51@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
 <05K-K4EXhEOwcpYe3s-nyiNSQnmIzS_m1fj_tYiRYLw=.f4f04a43-a55a-4835-b0d8-a13e36a2241f@github.com>
 <aO7hDEl9gduVOU09-mbF4huGKEfOLGtGLHwxT4nMDDw=.8b3be4a8-db82-40c8-9d3a-62d98216fb51@github.com>
Message-ID: <14AUPNhYs2AU7VnJU-0jZMxK2EjwJWIf2Bn5t3w9oJ0=.5b8bd7b2-2380-404f-bdaf-8585d9bdda1e@github.com>

On Wed, 20 Apr 2022 19:30:49 GMT, Phil Race <prr at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test summary updated
>
> test/jdk/javax/swing/JTabbedPane/4209065/bug4209065.java line 55:
> 
>> 53:                       + "<br>the descriptions, press <em><b>PASS</b></em><br>"
>> 54:                       + "<br> NOTE: the text (tab title) may not always "
>> 55:                       + "fit the tab.</center></html>";
> 
> How about 
> NOTE: where a large font is used, the text may be larger than the tab height but this is OK and not a failure.

@prrace @prsadhuk This PR might require a re-review since the test case has new changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8307


From duke at openjdk.java.net  Thu Apr 21 15:37:28 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Thu, 21 Apr 2022 15:37:28 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v8]
In-Reply-To: <Qa-HnVCda_3_Z38W4_XLpTg3Q37WDsXhiPSVl7D-AWA=.b6852efc-c828-47bb-ad88-0abead85509b@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <afJ29wQf2smgANBt5YTQC4oODoch8zxa0YqdtUZDfW8=.f4d0de4d-5245-4491-a8e8-05aaf2a4797a@github.com>
 <gzymK8AsH16kj6YIbJoMuRVGTDkKwLd_O3rbbDZCWIQ=.1f491527-2bac-4e6d-a5cc-f8443bf4f352@github.com>
 <MENhs6_2RTKjMOcWkh1CzumSIwQOy75T_wLac37Vkl8=.0da493e3-d91d-4b48-bd58-f69cefce3a9b@github.com>
 <wrQgwI3XG2G9_X8n5n4Q_AzDnMElxB92075XY3bkJMQ=.f5fb8350-489d-44a1-935a-e752b78347cd@github.com>
 <fR3AZPwa0kAz6SJDa5ns4eyyjCIAY_s25IlS2SL2xSw=.c8689931-ded8-448f-8caa-a17b47f7631a@github.com>
 <7ot0fBLQsvKiNsxLdrbnv4R_MNr6qdLN_GBwNPjU-rY=.dcad59a1-d0d6-42b9-bdf4-6290f31a88e0@github.com>
 <aKWrOQ_B3iWzXECCc6lUYE3ii6MOT3uBflVM4oSs7Ck=.07eb26cc-a502-494e-9dfc-b46b2d2dd6b5@github.com>
 <O0CcYkSID4VbXni4_hNoQKMK2TbCon7iW2IWgND1T4A=.3741a949-2397-4958-826d-bbef72e03031@github.com>
 <Qa-HnVCda_3_Z38W4_XLpTg3Q37WDsXhiPSVl7D-AWA=.b6852efc-c828-47bb-ad88-0abead85509b@github.com>
Message-ID: <wsF6QAGcYWv5e6vsUR4Eiw6g6dglqhfsEugIdu2Puzw=.c9b1d103-7ff0-4291-92ff-d62b46fb81fe@github.com>

On Mon, 11 Apr 2022 07:06:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> @prsadhuk Update PR with the recommended changes. The "controlAccentColor" changes works as expected in Mac 12.3 as well. 
>> One thing that I wanted to clarify with the fix is - the focus ring color ("Focus.ring") is used at two other places AquaButtonUI and AquaFocus (for focused icon). With the current fix I'm setting **KEYBOARD_FOCUS_COLOR** as below - 
>> 
>> <img width="1092" alt="image" src="https://user-images.githubusercontent.com/95945681/162673487-26006ca1-9373-4fe7-8f0b-f99cd47b2eb7.png">
>> 
>> Before and After images of focused icon -
>> 
>> **Before**
>> 
>> <img width="185" alt="image" src="https://user-images.githubusercontent.com/95945681/162674337-ebbfea9f-e753-4b4c-a624-7cef5b8d8c1b.png">
>> 
>> **After (focus around icon slightly darker - focus ring color obtained from controlAccentColor property)**
>> 
>> <img width="198" alt="image" src="https://user-images.githubusercontent.com/95945681/162674444-b917de71-8e91-472e-a8f0-da48df0a43a5.png">
>> 
>> Please let me know in case I need to add a NEW color (as shown below) instead of reusing the KEYBOARD_FOCUS_COLOR if the color effects on focused icon/ button doesn't look correct.
>> 
>> <img width="1099" alt="image" src="https://user-images.githubusercontent.com/95945681/162675955-efd9c77f-6d7b-41e7-803a-50f49154fba5.png">
>
> It seems KEYBOARD_FOCUS_COLOR via `focusRingColor` is also used for menuSelectedBackgroundColor which is used for 
> 
> CheckBoxMenuItem.selectionBackground
> ComboBox.selectionBackground
> Menu.selectionBackground
> MenuBar.selectionBackground
> MenuItem.selectionBackground
> "PopupMenu.selectionBackground", menuSelectedBackgroundColor,
> RadioButtonMenuItem.selectionBackground
> 
> which might also get affected if you use new property, so you need to test all those widgets if you intend to use reuse KEYBOARD_FOCUS_COLOR  so I guess safe bet is to use new color as you mentioned to limit the change to highlight color.

@prsadhuk With the new changes a public method is added to AquaImageFactory, does this require a CSR?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From psadhukhan at openjdk.java.net  Thu Apr 21 16:22:29 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 21 Apr 2022 16:22:29 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v5]
In-Reply-To: <eaCCY61HB7mlF1p_jRPAC887VXoRx6jm5BoI7JyQLW4=.9129f134-0b17-4d41-bbc3-089aff822bac@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
 <eaCCY61HB7mlF1p_jRPAC887VXoRx6jm5BoI7JyQLW4=.9129f134-0b17-4d41-bbc3-089aff822bac@github.com>
Message-ID: <KHbIp6WW25l2fgzNFa5-q-HutbSZHstdOdC9TnKw5UM=.71ff96fd-6d3b-4e3d-978f-0f8fe12426d9@github.com>

On Wed, 20 Apr 2022 23:55:05 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> The exisiting manual test case tests different html styles of JTabbedPane tab title. The tab with "big" as title is seen to be clipped on Aqua LAF for larger font-size. In other LAFs it is observed that bigger font-size can be accommodated without clipping.
>> 
>> The following approaches were evaluated before considering it as not a test issue -
>> 
>> - Aqua LAF has a different tab style compared to other LAFs as seen in the screenshot below. Limiting font size on Aqua LAF requires scaling down the text which might be incompatible with Aqua LAF.
>> 
>> - Removing existing constraints on text and icon is incompatible for Aqua LAF.
>> 
>> Since the above two approaches are incompatible with Aqua and it is not a test issue, a note has been added about clipped text and this test has been removed from problem list
>> 
>> ![image](https://user-images.githubusercontent.com/95945681/164093604-ca7ecbc3-09c2-4338-bd2a-f8c81c12f360.png)
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed test case to use PassFailJFrame instead of Applet

test/jdk/javax/swing/JTabbedPane/4209065/bug4209065.java line 51:

> 49:              tab height but this is OK and NOT a failure.
> 50:             """;
> 51: 

looks ok in jtreg but standalone execution in my windows fails with this String initialization. Probably we can do normal string with "+" as continuation instead of """ literal


javac bug4209065.java
bug4209065.java:44: error: unclosed string literal
    private static final String text = """

-------------

PR: https://git.openjdk.java.net/jdk/pull/8307


From psadhukhan at openjdk.java.net  Thu Apr 21 16:32:36 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 21 Apr 2022 16:32:36 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v8]
In-Reply-To: <wsF6QAGcYWv5e6vsUR4Eiw6g6dglqhfsEugIdu2Puzw=.c9b1d103-7ff0-4291-92ff-d62b46fb81fe@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <afJ29wQf2smgANBt5YTQC4oODoch8zxa0YqdtUZDfW8=.f4d0de4d-5245-4491-a8e8-05aaf2a4797a@github.com>
 <gzymK8AsH16kj6YIbJoMuRVGTDkKwLd_O3rbbDZCWIQ=.1f491527-2bac-4e6d-a5cc-f8443bf4f352@github.com>
 <MENhs6_2RTKjMOcWkh1CzumSIwQOy75T_wLac37Vkl8=.0da493e3-d91d-4b48-bd58-f69cefce3a9b@github.com>
 <wrQgwI3XG2G9_X8n5n4Q_AzDnMElxB92075XY3bkJMQ=.f5fb8350-489d-44a1-935a-e752b78347cd@github.com>
 <fR3AZPwa0kAz6SJDa5ns4eyyjCIAY_s25IlS2SL2xSw=.c8689931-ded8-448f-8caa-a17b47f7631a@github.com>
 <7ot0fBLQsvKiNsxLdrbnv4R_MNr6qdLN_GBwNPjU-rY=.dcad59a1-d0d6-42b9-bdf4-6290f31a88e0@github.com>
 <aKWrOQ_B3iWzXECCc6lUYE3ii6MOT3uBflVM4oSs7Ck=.07eb26cc-a502-494e-9dfc-b46b2d2dd6b5@github.com>
 <O0CcYkSID4VbXni4_hNoQKMK2TbCon7iW2IWgND1T4A=.3741a949-2397-4958-826d-bbef72e03031@github.com>
 <Qa-HnVCda_3_Z38W4_XLpTg3Q37WDsXhiPSVl7D-AWA=.b6852efc-c828-47bb-ad88-0abead85509b@github.com>
 <wsF6QAGcYWv5e6vsUR4Eiw6g6dglqhfsEug
 Idu2Puzw=.c9b1d103-7ff0-4291-92ff-d62b46fb81fe@github.com>
Message-ID: <x1dD7jenIMDB7o3vKBpylUWi1wkWJwaqnjnndwea9X0=.922fa092-a334-4f41-b426-c097c944fe3f@github.com>

On Thu, 21 Apr 2022 15:34:05 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> It seems KEYBOARD_FOCUS_COLOR via `focusRingColor` is also used for menuSelectedBackgroundColor which is used for 
>> 
>> CheckBoxMenuItem.selectionBackground
>> ComboBox.selectionBackground
>> Menu.selectionBackground
>> MenuBar.selectionBackground
>> MenuItem.selectionBackground
>> "PopupMenu.selectionBackground", menuSelectedBackgroundColor,
>> RadioButtonMenuItem.selectionBackground
>> 
>> which might also get affected if you use new property, so you need to test all those widgets if you intend to use reuse KEYBOARD_FOCUS_COLOR  so I guess safe bet is to use new color as you mentioned to limit the change to highlight color.
>
> @prsadhuk With the new changes a public method is added to AquaImageFactory, does this require a CSR?

If you are talking about getCellHighlightColorUIResource() then no. We don't have specs for this class.
I have added similar getSelectedControlColorUIResource method for JDK-8251377 without CSR

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From duke at openjdk.java.net  Thu Apr 21 16:33:30 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Thu, 21 Apr 2022 16:33:30 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v5]
In-Reply-To: <KHbIp6WW25l2fgzNFa5-q-HutbSZHstdOdC9TnKw5UM=.71ff96fd-6d3b-4e3d-978f-0f8fe12426d9@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
 <eaCCY61HB7mlF1p_jRPAC887VXoRx6jm5BoI7JyQLW4=.9129f134-0b17-4d41-bbc3-089aff822bac@github.com>
 <KHbIp6WW25l2fgzNFa5-q-HutbSZHstdOdC9TnKw5UM=.71ff96fd-6d3b-4e3d-978f-0f8fe12426d9@github.com>
Message-ID: <UyfHXtqLuWk6vuQeOPnAH7ErAqoXBiMU3tmghLs8QCY=.4641a3eb-0906-4f1f-b6d7-35d78ef69193@github.com>

On Thu, 21 Apr 2022 16:18:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changed test case to use PassFailJFrame instead of Applet
>
> test/jdk/javax/swing/JTabbedPane/4209065/bug4209065.java line 51:
> 
>> 49:              tab height but this is OK and NOT a failure.
>> 50:             """;
>> 51: 
> 
> looks ok in jtreg but standalone execution in my windows fails with this String initialization. Probably we can do normal string with "+" as continuation instead of """ literal
> 
> 
> javac bug4209065.java
> bug4209065.java:44: error: unclosed string literal
>     private static final String text = """

@prsadhuk Thanks for catching it. I'll make the required changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8307


From duke at openjdk.java.net  Thu Apr 21 16:37:41 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Thu, 21 Apr 2022 16:37:41 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v8]
In-Reply-To: <x1dD7jenIMDB7o3vKBpylUWi1wkWJwaqnjnndwea9X0=.922fa092-a334-4f41-b426-c097c944fe3f@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <afJ29wQf2smgANBt5YTQC4oODoch8zxa0YqdtUZDfW8=.f4d0de4d-5245-4491-a8e8-05aaf2a4797a@github.com>
 <gzymK8AsH16kj6YIbJoMuRVGTDkKwLd_O3rbbDZCWIQ=.1f491527-2bac-4e6d-a5cc-f8443bf4f352@github.com>
 <MENhs6_2RTKjMOcWkh1CzumSIwQOy75T_wLac37Vkl8=.0da493e3-d91d-4b48-bd58-f69cefce3a9b@github.com>
 <wrQgwI3XG2G9_X8n5n4Q_AzDnMElxB92075XY3bkJMQ=.f5fb8350-489d-44a1-935a-e752b78347cd@github.com>
 <fR3AZPwa0kAz6SJDa5ns4eyyjCIAY_s25IlS2SL2xSw=.c8689931-ded8-448f-8caa-a17b47f7631a@github.com>
 <7ot0fBLQsvKiNsxLdrbnv4R_MNr6qdLN_GBwNPjU-rY=.dcad59a1-d0d6-42b9-bdf4-6290f31a88e0@github.com>
 <aKWrOQ_B3iWzXECCc6lUYE3ii6MOT3uBflVM4oSs7Ck=.07eb26cc-a502-494e-9dfc-b46b2d2dd6b5@github.com>
 <O0CcYkSID4VbXni4_hNoQKMK2TbCon7iW2IWgND1T4A=.3741a949-2397-4958-826d-bbef72e03031@github.com>
 <Qa-HnVCda_3_Z38W4_XLpTg3Q37WDsXhiPSVl7D-AWA=.b6852efc-c828-47bb-ad88-0abead85509b@github.com>
 <wsF6QAGcYWv5e6vsUR4Eiw6g6dglqhfsEug
 Idu2Puzw=.c9b1d103-7ff0-4291-92ff-d62b46fb81fe@github.com>
 <x1dD7jenIMDB7o3vKBpylUWi1wkWJwaqnjnndwea9X0=.922fa092-a334-4f41-b426-c097c944fe3f@github.com>
Message-ID: <WlRf4P1rAQkzsYc9kjbiY3osAACxhRgpwF4Auq_ieR4=.36392874-d594-4d80-a152-4b4129da0081@github.com>

On Thu, 21 Apr 2022 16:28:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> @prsadhuk With the new changes a public method is added to AquaImageFactory, does this require a CSR?
>
> If you are talking about getCellHighlightColorUIResource() then no. We don't have specs for this class.
> I have added similar getSelectedControlColorUIResource method for JDK-8251377 without CSR

@prsadhuk Thank you! Noted. Yes, it is the`getCellHighlightColorUIResource()` method.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From prr at openjdk.java.net  Thu Apr 21 17:25:07 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 21 Apr 2022 17:25:07 GMT
Subject: RFR: 8284965: closed test sun/java2d/OpenGL/XORPaint.java is unstable
Message-ID: <jXlD0hMF8qqSCVHqlppJoClNCXpgaeJrAbl6Ku6FY5M=.69f4c6b1-78cb-418d-b400-ba018ac4474a@github.com>

This fix moves a closed test to open but updated to be more comprehensive in testing multiple pipelines and with some stabilisation improvements.

-------------

Commit messages:
 - 8284965

Changes: https://git.openjdk.java.net/jdk/pull/8345/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8345&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284965
  Stats: 239 lines in 1 file changed: 239 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8345.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8345/head:pull/8345

PR: https://git.openjdk.java.net/jdk/pull/8345


From duke at openjdk.java.net  Thu Apr 21 17:31:06 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Thu, 21 Apr 2022 17:31:06 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v6]
In-Reply-To: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
Message-ID: <TI0MVdrlslDU6pCvkvhfqt-nyM9Ee6ARnhVUrKfj0Jw=.a9311abe-8c09-4cec-8287-45f594779b78@github.com>

> The exisiting manual test case tests different html styles of JTabbedPane tab title. The tab with "big" as title is seen to be clipped on Aqua LAF for larger font-size. In other LAFs it is observed that bigger font-size can be accommodated without clipping.
> 
> The following approaches were evaluated before considering it as not a test issue -
> 
> - Aqua LAF has a different tab style compared to other LAFs as seen in the screenshot below. Limiting font size on Aqua LAF requires scaling down the text which might be incompatible with Aqua LAF.
> 
> - Removing existing constraints on text and icon is incompatible for Aqua LAF.
> 
> Since the above two approaches are incompatible with Aqua and it is not a test issue, a note has been added about clipped text and this test has been removed from problem list
> 
> ![image](https://user-images.githubusercontent.com/95945681/164093604-ca7ecbc3-09c2-4338-bd2a-f8c81c12f360.png)

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  removed triple quotes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8307/files
  - new: https://git.openjdk.java.net/jdk/pull/8307/files/2fd26ad6..09109ab3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8307&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8307&range=04-05

  Stats: 7 lines in 1 file changed: 0 ins; 2 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8307.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8307/head:pull/8307

PR: https://git.openjdk.java.net/jdk/pull/8307


From azvegint at openjdk.java.net  Thu Apr 21 17:54:48 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 21 Apr 2022 17:54:48 GMT
Subject: RFR: 8193543: Regression automated test
 '/open/test/jdk/java/awt/TrayIcon/SystemTrayInstance/SystemTrayInstanceTest.java'
 fails
Message-ID: <6S1J2MYhxOU4Gt_H5xTetVR0pkrM7iIlLfkOf9mlo_g=.ccdbb91e-16b1-4982-85d8-27e6a2754939@github.com>

Looks like this test was written based on assumption that SystemTray is supported on all platforms.

However on Linux it may not be true. 

Availability of SystemTray is detected by getting owner of `_NET_SYSTEM_TRAY` selection:

https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/unix/classes/sun/awt/X11/XSystemTrayPeer.java#L42

https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/unix/classes/sun/awt/X11/XSystemTrayPeer.java#L58-L59


As an example, SystemTray is not available on Wayland because of this.



So I modified the test:

- WIndows and macOS: expecting SystemTray.
- Linux: check absence/presence of `UnsupportedOperationException` exception of `SystemTray.getSystemTray()` call  based on `SystemTray.isSupported()` result.

-------------

Commit messages:
 - initial

Changes: https://git.openjdk.java.net/jdk/pull/8346/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8346&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8193543
  Stats: 29 lines in 2 files changed: 14 ins; 2 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8346.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8346/head:pull/8346

PR: https://git.openjdk.java.net/jdk/pull/8346


From azvegint at openjdk.java.net  Thu Apr 21 18:05:26 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 21 Apr 2022 18:05:26 GMT
Subject: RFR: 8285094: Test
 java/awt/Frame/InvisibleOwner/InvisibleOwner.java failing on Linux [v2]
In-Reply-To: <J1EN14f--HeKT79NTNpRC4wVpFyMDgzOWfu-70y6TJA=.23d53f6e-2095-4132-8902-feb9ce25cde6@github.com>
References: <nZJd4Qchm9OYGaFr3iBBm3XdYmqWXHzjfLElnUaCL90=.2fa7fc8c-23e2-46df-a5c5-acb33e7bf5fc@github.com>
 <4cb8q0W_V5_LF_wk_MkwVBGTfN_LcwQ0VZKKDzhdr48=.ba51c584-0460-4392-afd2-519d625078bf@github.com>
 <J1EN14f--HeKT79NTNpRC4wVpFyMDgzOWfu-70y6TJA=.23d53f6e-2095-4132-8902-feb9ce25cde6@github.com>
Message-ID: <V-3J74wrPWmop7dP4LKOuKoBH3gr14yS4C6U-uF3dmo=.e2d6b125-db72-4e76-acb5-25b4923f6ffe@github.com>

On Thu, 21 Apr 2022 15:23:31 GMT, Phil Race <prr at openjdk.org> wrote:

>> test/jdk/java/awt/Frame/InvisibleOwner/InvisibleOwner.java line 135:
>> 
>>> 133:                             ownedWindowBounds.y + ownedWindowBounds.height / 2);
>>> 134:             robot.mousePress(InputEvent.BUTTON1_MASK);
>>> 135:             robot.mouseRelease(InputEvent.BUTTON1_MASK);
>> 
>> Nit: Shouldn't we use BUTTON1_DOWN_MASK instead of deprecated BUTTON1_MASK?
>
> That is how it was before but I fixed this.

Thought that we are cleaning up such deprecated things.
There is another place with BUTTON1_MASK below though.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8312


From kizune at openjdk.java.net  Thu Apr 21 18:50:16 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 21 Apr 2022 18:50:16 GMT
Subject: RFR: 8273506: java Robot API did the 'm' keypress and caused
 /awt/event/KeyEvent/KeyCharTest/KeyCharTest.html is timing out on macOS 12
 [v2]
In-Reply-To: <jmtC1w9SyvfAg940bq60x20bVshEm5P2g7IExDWnpBk=.1cdcdbc2-881c-4cce-a2c0-73873369e0c5@github.com>
References: <jmtC1w9SyvfAg940bq60x20bVshEm5P2g7IExDWnpBk=.1cdcdbc2-881c-4cce-a2c0-73873369e0c5@github.com>
Message-ID: <33wbZN4ZDtQ564BCCatIOTX2sVRXi308jFUzKbKOaVE=.4ecfdde4-74ed-4319-bf86-492c3e47a32b@github.com>

> Clear the kCGEventFlagMaskSecondaryFn flag if it is set before posting keyboard events to the system queue.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Adding test case.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8320/files
  - new: https://git.openjdk.java.net/jdk/pull/8320/files/94dd52e3..1be2fc50

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8320&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8320&range=00-01

  Stats: 100 lines in 1 file changed: 100 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8320.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8320/head:pull/8320

PR: https://git.openjdk.java.net/jdk/pull/8320


From aivanov at openjdk.java.net  Thu Apr 21 19:19:29 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 21 Apr 2022 19:19:29 GMT
Subject: RFR: 8284189: Replace usages of 'a the' in java.desktop [v2]
In-Reply-To: <WgwcUzQ7Dt93IO-fDZj_-N1qpA4zLDUzj_jpf2n7Oo4=.94bfb1f2-febd-410a-9a29-d49728c99a1d@github.com>
References: <GEeFsO6UCFVr_EI5oDxdC8cIFCLDSSRpuQDs4owG43M=.a17abdd1-8fc6-4729-8d78-32bf6d84ff4e@github.com>
 <VFw3VJIWmWL28o0EXtPjMrw-V7bncTtelQPndTrOenE=.7b69ad1f-6c5f-4f71-a5d3-62a2e04c0452@github.com>
 <WgwcUzQ7Dt93IO-fDZj_-N1qpA4zLDUzj_jpf2n7Oo4=.94bfb1f2-febd-410a-9a29-d49728c99a1d@github.com>
Message-ID: <4iPpfwXvVnyAqi9GYaEUQJA2MCRAhrB872z5X4hfhN4=.c625d459-56e8-485d-8dd3-3e0f9b0bbd81@github.com>

On Mon, 18 Apr 2022 16:31:15 GMT, Phil Race <prr at openjdk.org> wrote:

> Note that even though API javadoc is touched all these typos fall well below the threshold for a CSR?

That was my understanding. Thank you for confirming it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8274


From aivanov at openjdk.java.net  Thu Apr 21 19:19:30 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 21 Apr 2022 19:19:30 GMT
Subject: Integrated: 8284189: Replace usages of 'a the' in java.desktop
In-Reply-To: <GEeFsO6UCFVr_EI5oDxdC8cIFCLDSSRpuQDs4owG43M=.a17abdd1-8fc6-4729-8d78-32bf6d84ff4e@github.com>
References: <GEeFsO6UCFVr_EI5oDxdC8cIFCLDSSRpuQDs4owG43M=.a17abdd1-8fc6-4729-8d78-32bf6d84ff4e@github.com>
Message-ID: <TNy5u54zMoJiUisvK6WdJpfJLEBrfBF4PlcmL8W7v9c=.6a214c15-d849-47e5-9f68-3b37f81da4b0@github.com>

On Sat, 16 Apr 2022 17:45:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> I fixed a couple of other spelling mistakes.
> 
> I also expanded wildcard imports.

This pull request has now been integrated.

Changeset: ec4fb47b
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ec4fb47b90c9737dfdc285ebe98367a221c90c79
Stats:     387 lines in 39 files changed: 196 ins; 46 del; 145 mod

8284189: Replace usages of 'a the' in java.desktop

Reviewed-by: jdv, prr, dmarkov

-------------

PR: https://git.openjdk.java.net/jdk/pull/8274


From achung at openjdk.java.net  Thu Apr 21 20:00:55 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Thu, 21 Apr 2022 20:00:55 GMT
Subject: RFR: 7080150: [TEST_BUG][macosx] No mac os x EmbeddedFrame support in
 regression regtesthelpers
Message-ID: <abWDTHr4uorNjVddaR6Ai-ZOn_5XNpg__RO5PSi4z-o=.01f596f9-c7c8-4ccc-8dba-84f28eca25c2@github.com>

added EmbeddedFrame support for macosx in regtesthelpers

-------------

Commit messages:
 - Merge branch 'master' into 7080150
 - removed from ProblemList.txt
 - added macos EmbeddedFrame support to AWT regtesthelpers

Changes: https://git.openjdk.java.net/jdk/pull/8348/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8348&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-7080150
  Stats: 7 lines in 2 files changed: 6 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8348.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8348/head:pull/8348

PR: https://git.openjdk.java.net/jdk/pull/8348


From achung at openjdk.java.net  Thu Apr 21 20:07:17 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Thu, 21 Apr 2022 20:07:17 GMT
Subject: RFR: 7080150: [TEST_BUG][macosx] No mac os x EmbeddedFrame support
 in regression regtesthelpers [v2]
In-Reply-To: <abWDTHr4uorNjVddaR6Ai-ZOn_5XNpg__RO5PSi4z-o=.01f596f9-c7c8-4ccc-8dba-84f28eca25c2@github.com>
References: <abWDTHr4uorNjVddaR6Ai-ZOn_5XNpg__RO5PSi4z-o=.01f596f9-c7c8-4ccc-8dba-84f28eca25c2@github.com>
Message-ID: <YN2s_fyZJZsnMmSemoNnlt356YNhw-6YQO8qNPB3RBw=.71f188ab-a1e6-4cef-80ec-c0b61e5e6b31@github.com>

> added EmbeddedFrame support for macosx in regtesthelpers

Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch '7080150' of github.com:alisenchung/jdk into 7080150
 - fixed merge conflict

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8348/files
  - new: https://git.openjdk.java.net/jdk/pull/8348/files/9570e351..39f6490b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8348&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8348&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8348.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8348/head:pull/8348

PR: https://git.openjdk.java.net/jdk/pull/8348


From tnakamura at openjdk.java.net  Fri Apr 22 00:33:44 2022
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Fri, 22 Apr 2022 00:33:44 GMT
Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong size
Message-ID: <z72T3X_wgR6K7BdFL7Tqg8t6GXbJh-Vk0pDGCJjUnEE=.ba87e570-fc0b-45d5-8099-9ffeeeb09fc5@github.com>

Japanese logical fonts are drawn with wrong size since Java 18.
It's triggered by JEP 400, UTF-8 by Default. `sun.awt.FontConfiguration` (and `sun.awt.windows.WFontConfiguration`) seems to expect the native encoding instead of the default encoding. This patch changes to use native encoding.

Tested: jdk_desktop on Windows, Linux, and macOS

-------------

Commit messages:
 - 8285308: Win: Japanese logical fonts are drawn with wrong size

Changes: https://git.openjdk.java.net/jdk/pull/8329/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8329&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285308
  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8329.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8329/head:pull/8329

PR: https://git.openjdk.java.net/jdk/pull/8329


From prr at openjdk.java.net  Fri Apr 22 03:27:25 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 22 Apr 2022 03:27:25 GMT
Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong
 size
In-Reply-To: <z72T3X_wgR6K7BdFL7Tqg8t6GXbJh-Vk0pDGCJjUnEE=.ba87e570-fc0b-45d5-8099-9ffeeeb09fc5@github.com>
References: <z72T3X_wgR6K7BdFL7Tqg8t6GXbJh-Vk0pDGCJjUnEE=.ba87e570-fc0b-45d5-8099-9ffeeeb09fc5@github.com>
Message-ID: <Y_2oKMsrT3TUVaZI7xUMo59febA0uYZPSNgNbqdEpvw=.b48a99ad-5aa8-4f18-9528-545fe624b0a2@github.com>

On Thu, 21 Apr 2022 09:14:14 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

> Japanese logical fonts are drawn with wrong size since Java 18.
> It's triggered by JEP 400, UTF-8 by Default. `sun.awt.FontConfiguration` (and `sun.awt.windows.WFontConfiguration`) seems to expect the native encoding instead of the default encoding. This patch changes to use native encoding.
> 
> Tested: jdk_desktop on Windows, Linux, and macOS

Hmm. I am surprised that the glyphs are actually bigger. Did you come to understand the exact mechanism (steps)
by which this triggers the wrong size ? Without that explanation it isn't apparent to me we've understood the problem
even if this fixes it.

And whilst you tested linux & mac it is a shared code change so it is another reason to understand .. 

And are you sure you can't write a test ? Even something that uses heuristics around the metrics ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8329


From psadhukhan at openjdk.java.net  Fri Apr 22 04:00:10 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 22 Apr 2022 04:00:10 GMT
Subject: RFR: 8284993: Replace System.exit call in swing tests with
 RuntimeException [v5]
In-Reply-To: <HpC4smoyLOHwI71LRFJ6DUrsnsujjgLQHM0VE6dsDTc=.6730db17-3b19-4eac-bd54-8a9f253d5f5f@github.com>
References: <HpC4smoyLOHwI71LRFJ6DUrsnsujjgLQHM0VE6dsDTc=.6730db17-3b19-4eac-bd54-8a9f253d5f5f@github.com>
Message-ID: <yqN00sQhreLHWY6zN1SLRWVm0A_taXepeaegsgPicKw=.149de672-02bf-497a-a0ba-e945cac869d5@github.com>

> Few swing tests call System.exit() which might stop the test harness from executing further tests if any of the test fail. We should replace with RuntimeException.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  whitespace fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8293/files
  - new: https://git.openjdk.java.net/jdk/pull/8293/files/7d49634d..95567d23

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8293&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8293&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8293.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8293/head:pull/8293

PR: https://git.openjdk.java.net/jdk/pull/8293


From psadhukhan at openjdk.java.net  Fri Apr 22 05:10:16 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 22 Apr 2022 05:10:16 GMT
Subject: RFR: 8129827: [TEST_BUG] Test
 java/awt/Robot/RobotWheelTest/RobotWheelTest.java fails
In-Reply-To: <yq6IVScF0JllG8OmDLu2_FPx_-wS5pir1-2cXeb2Be8=.4af01d28-0106-4ba2-93fe-391314b6469e@github.com>
References: <yq6IVScF0JllG8OmDLu2_FPx_-wS5pir1-2cXeb2Be8=.4af01d28-0106-4ba2-93fe-391314b6469e@github.com>
Message-ID: <xOSzDSXdRRklUx6FVRQB8Q67asSpEHXes8ktUKmpJek=.b956093a-a17d-4c78-879e-c76ede9ae977@github.com>

On Tue, 19 Apr 2022 20:03:57 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Test was written based on assumption that we will receive only one `mouseWheelMoved` event with `getWheelRotation() == 20` after `robot.mouseWheel(20)` call, but we can receive 20  events with `getWheelRotation == 1` instead.
> 
> So the test is modified to accumulate wheel rotation values before checking.
> 
> Testing is green on all platforms.

test/jdk/java/awt/Robot/RobotWheelTest/RobotWheelTest.java line 47:

> 45: 
> 46:     private static AtomicInteger wheelRotation = new AtomicInteger();
> 47:     private static int wheelSign = Platform.isOSX() ? -1 : 1;

Is this the scroll rotation direction?
If it is, then as you can see in  JDK-8282716 review comments, this direction can be configured so we cannot rely on this it will always be -1 for macos...
Maybe you can do the same as it is done there to check at runtime what is the scroll direction configured?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8305


From psadhukhan at openjdk.java.net  Fri Apr 22 05:20:18 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 22 Apr 2022 05:20:18 GMT
Subject: RFR: 8225777: java/awt/Mixing/MixingOnDialog.java fails on Ubuntu
In-Reply-To: <VQLsDzN8qiIssQllKP6jgXgc1UwWbjO3O2rS8eT8wTk=.dc8fa68c-816f-41c9-9bb8-20d503246440@github.com>
References: <VQLsDzN8qiIssQllKP6jgXgc1UwWbjO3O2rS8eT8wTk=.dc8fa68c-816f-41c9-9bb8-20d503246440@github.com>
Message-ID: <fxz94-qMf_Od_n7pRWsz8lDADoKKH3VEQMmrdF9KseY=.1ebcb05c-6123-424a-8e1c-bf8e5b3bdfab@github.com>

On Thu, 21 Apr 2022 07:58:39 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The test was failing due to it tried to place windows too close to left top corner, so they got shifted from the dock and top panel on Gnome.
> 
> Shifting all test windows fixes the issue.
> 
> 
> Testing is green on all platforms.

Is it possible to remove the obsolete "Standard Test Machinery Section" which we have removed from other tests?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8326


From kizune at openjdk.java.net  Fri Apr 22 06:16:04 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 22 Apr 2022 06:16:04 GMT
Subject: RFR: 8196367: java/awt/List/SingleModeDeselect/SingleModeDeselect.java
 times out
Message-ID: <RIp2Ct6nMnFaHBjOegrgbWQkW9ADpi2_67NissUngQ0=.6756c018-50d2-46e1-a21b-edb807fd7ad5@github.com>

Clean up imports;
Close and dispose frame before exiting the test;

-------------

Commit messages:
 - Remove test from the ProblemList
 - 8196367: java/awt/List/SingleModeDeselect/SingleModeDeselect.java times out

Changes: https://git.openjdk.java.net/jdk/pull/8351/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8351&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8196367
  Stats: 20 lines in 2 files changed: 9 ins; 4 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8351.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8351/head:pull/8351

PR: https://git.openjdk.java.net/jdk/pull/8351


From smandalika at openjdk.java.net  Fri Apr 22 06:37:08 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Fri, 22 Apr 2022 06:37:08 GMT
Subject: RFR: 8285373: Create an automated test for JDK-4702233
Message-ID: <zrkWQo-BoTq0XlQX_0_-CwnPIKkCge6wW8E5EqLAYRs=.2345ef0a-25eb-414c-ade6-de10d49d2bbe@github.com>

Create an automated test for [JDK-4702233](https://bugs.openjdk.java.net/browse/JDK-4702233)

Several new AccessibleRole and AccessibleRelation constants are needed in those classes in the java.accessibility package. These new contants codify additions made in the GNOME, Netscape, and UNO (StarOffice) accessibility APIs.
StarOffice 6.1 and GNOME accessibility require new role, state and relation
constants in the javax.accessibility package. The existing constants are
inadequate for providing accessibility to StarOffice and GNOME applications
as required by Section 508.

Solution
--------
Define new constants in the javax.accessibility package.
AccessibleRelation
AccessibleRoles
AccessibleState
AccessibleAction
AccessibleContext

The test validates the public fields of the above AccessibleConstants.

This review is for migrating tests from a closed test suite to open.

Testing:
The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

-------------

Commit messages:
 - 8285373: Create an automated test for JDK-4702233

Changes: https://git.openjdk.java.net/jdk/pull/8342/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8342&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285373
  Stats: 387 lines in 6 files changed: 387 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8342.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8342/head:pull/8342

PR: https://git.openjdk.java.net/jdk/pull/8342


From psadhukhan at openjdk.java.net  Fri Apr 22 06:48:28 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 22 Apr 2022 06:48:28 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v5]
In-Reply-To: <UyfHXtqLuWk6vuQeOPnAH7ErAqoXBiMU3tmghLs8QCY=.4641a3eb-0906-4f1f-b6d7-35d78ef69193@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
 <eaCCY61HB7mlF1p_jRPAC887VXoRx6jm5BoI7JyQLW4=.9129f134-0b17-4d41-bbc3-089aff822bac@github.com>
 <KHbIp6WW25l2fgzNFa5-q-HutbSZHstdOdC9TnKw5UM=.71ff96fd-6d3b-4e3d-978f-0f8fe12426d9@github.com>
 <UyfHXtqLuWk6vuQeOPnAH7ErAqoXBiMU3tmghLs8QCY=.4641a3eb-0906-4f1f-b6d7-35d78ef69193@github.com>
Message-ID: <_UHIfMMCOOxGYhiLHw-J2ZBCz5trAaQLrYmtmkYgihw=.74272360-b9e8-4475-93b0-7291e6afbbd1@github.com>

On Thu, 21 Apr 2022 16:30:20 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> test/jdk/javax/swing/JTabbedPane/4209065/bug4209065.java line 51:
>> 
>>> 49:              tab height but this is OK and NOT a failure.
>>> 50:             """;
>>> 51: 
>> 
>> looks ok in jtreg but standalone execution in my windows fails with this String initialization. Probably we can do normal string with "+" as continuation instead of """ literal
>> 
>> 
>> javac bug4209065.java
>> bug4209065.java:44: error: unclosed string literal
>>     private static final String text = """
>
> @prsadhuk Thanks for catching it. I'll make the required changes.

SInce you are hardcoding PassFailFrame column to 35, it seems some word break is not perfect in the above instructions.
Probably, you can put \n break at appropriate positions in NOTE to show better.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8307


From psadhukhan at openjdk.java.net  Fri Apr 22 06:51:29 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 22 Apr 2022 06:51:29 GMT
Subject: Integrated: 8284993: Replace System.exit call in swing tests with
 RuntimeException
In-Reply-To: <HpC4smoyLOHwI71LRFJ6DUrsnsujjgLQHM0VE6dsDTc=.6730db17-3b19-4eac-bd54-8a9f253d5f5f@github.com>
References: <HpC4smoyLOHwI71LRFJ6DUrsnsujjgLQHM0VE6dsDTc=.6730db17-3b19-4eac-bd54-8a9f253d5f5f@github.com>
Message-ID: <U2RfwP00H0EW77nrJCAVql3w-Ir9GSmyEAAy-nWIx7E=.b9aa8b72-6030-424c-a461-5bcae2a056df@github.com>

On Tue, 19 Apr 2022 09:10:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Few swing tests call System.exit() which might stop the test harness from executing further tests if any of the test fail. We should replace with RuntimeException.

This pull request has now been integrated.

Changeset: 80219a48
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/80219a48c34719263cd41dacd02ba19dd39b1b27
Stats:     26 lines in 6 files changed: 15 ins; 1 del; 10 mod

8284993: Replace System.exit call in swing tests with RuntimeException

Reviewed-by: azvegint

-------------

PR: https://git.openjdk.java.net/jdk/pull/8293


From azvegint at openjdk.java.net  Fri Apr 22 07:05:25 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 22 Apr 2022 07:05:25 GMT
Subject: RFR: 8129827: [TEST_BUG] Test
 java/awt/Robot/RobotWheelTest/RobotWheelTest.java fails
In-Reply-To: <xOSzDSXdRRklUx6FVRQB8Q67asSpEHXes8ktUKmpJek=.b956093a-a17d-4c78-879e-c76ede9ae977@github.com>
References: <yq6IVScF0JllG8OmDLu2_FPx_-wS5pir1-2cXeb2Be8=.4af01d28-0106-4ba2-93fe-391314b6469e@github.com>
 <xOSzDSXdRRklUx6FVRQB8Q67asSpEHXes8ktUKmpJek=.b956093a-a17d-4c78-879e-c76ede9ae977@github.com>
Message-ID: <6dD801a__gyug1ZTaC8ZRgUuO7cGQVDXovLAQ8GXDto=.4ad9f4bb-6c01-401b-9c19-79b5d7ae6259@github.com>

On Fri, 22 Apr 2022 05:06:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test was written based on assumption that we will receive only one `mouseWheelMoved` event with `getWheelRotation() == 20` after `robot.mouseWheel(20)` call, but we can receive 20  events with `getWheelRotation == 1` instead.
>> 
>> So the test is modified to accumulate wheel rotation values before checking.
>> 
>> Testing is green on all platforms.
>
> test/jdk/java/awt/Robot/RobotWheelTest/RobotWheelTest.java line 47:
> 
>> 45: 
>> 46:     private static AtomicInteger wheelRotation = new AtomicInteger();
>> 47:     private static int wheelSign = Platform.isOSX() ? -1 : 1;
> 
> Is this the scroll rotation direction?
> If it is, then as you can see in  JDK-8282716 review comments, this direction can be configured so we cannot rely on this it will always be -1 for macos...
> Maybe you can do the same as it is done there to check at runtime what is the scroll direction configured?

It is the scroll rotation direction.

Just checked, enabling/disabling `Scroll direction: Natural` for mouse or trackpad does not affect robot scrolling, so the test passes regardless of these settings.

Besides that verification of `getWheelRotation()` method itself is significant part of the test, so I doubt we can use it to detect scroll direction.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8305


From psadhukhan at openjdk.java.net  Fri Apr 22 07:21:24 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 22 Apr 2022 07:21:24 GMT
Subject: RFR: 8129827: [TEST_BUG] Test
 java/awt/Robot/RobotWheelTest/RobotWheelTest.java fails
In-Reply-To: <yq6IVScF0JllG8OmDLu2_FPx_-wS5pir1-2cXeb2Be8=.4af01d28-0106-4ba2-93fe-391314b6469e@github.com>
References: <yq6IVScF0JllG8OmDLu2_FPx_-wS5pir1-2cXeb2Be8=.4af01d28-0106-4ba2-93fe-391314b6469e@github.com>
Message-ID: <_V4KtYyaN2lYwxz004ECmodtkX6VLErXyxJIWmkGTSo=.6eef856a-c470-4133-85d0-df9190e7a567@github.com>

On Tue, 19 Apr 2022 20:03:57 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Test was written based on assumption that we will receive only one `mouseWheelMoved` event with `getWheelRotation() == 20` after `robot.mouseWheel(20)` call, but we can receive 20  events with `getWheelRotation == 1` instead.
> 
> So the test is modified to accumulate wheel rotation values before checking.
> 
> Testing is green on all platforms.

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8305


From psadhukhan at openjdk.java.net  Fri Apr 22 07:21:25 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 22 Apr 2022 07:21:25 GMT
Subject: RFR: 8129827: [TEST_BUG] Test
 java/awt/Robot/RobotWheelTest/RobotWheelTest.java fails
In-Reply-To: <6dD801a__gyug1ZTaC8ZRgUuO7cGQVDXovLAQ8GXDto=.4ad9f4bb-6c01-401b-9c19-79b5d7ae6259@github.com>
References: <yq6IVScF0JllG8OmDLu2_FPx_-wS5pir1-2cXeb2Be8=.4af01d28-0106-4ba2-93fe-391314b6469e@github.com>
 <xOSzDSXdRRklUx6FVRQB8Q67asSpEHXes8ktUKmpJek=.b956093a-a17d-4c78-879e-c76ede9ae977@github.com>
 <6dD801a__gyug1ZTaC8ZRgUuO7cGQVDXovLAQ8GXDto=.4ad9f4bb-6c01-401b-9c19-79b5d7ae6259@github.com>
Message-ID: <sLX23dUP-SKAJytXTH4b2tRq_eiMizBDsmeSw8Z9C-8=.c0c5354b-9cb5-4bf6-9dbb-ec5c68eea676@github.com>

On Fri, 22 Apr 2022 07:02:27 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> test/jdk/java/awt/Robot/RobotWheelTest/RobotWheelTest.java line 47:
>> 
>>> 45: 
>>> 46:     private static AtomicInteger wheelRotation = new AtomicInteger();
>>> 47:     private static int wheelSign = Platform.isOSX() ? -1 : 1;
>> 
>> Is this the scroll rotation direction?
>> If it is, then as you can see in  JDK-8282716 review comments, this direction can be configured so we cannot rely on this it will always be -1 for macos...
>> Maybe you can do the same as it is done there to check at runtime what is the scroll direction configured?
>
> It is the scroll rotation direction.
> 
> Just checked, enabling/disabling `Scroll direction: Natural` for mouse or trackpad does not affect robot scrolling, so the test passes regardless of these settings.
> 
> Besides that verification of `getWheelRotation()` method itself is significant part of the test, so I doubt we can use it to detect scroll direction.

Ok. Thanks for the clarification.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8305


From serb at openjdk.java.net  Fri Apr 22 07:36:43 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Apr 2022 07:36:43 GMT
Subject: RFR: 8264666: Change implementation of safeAdd/safeMult in the
 LCMSImageLayout class [v2]
In-Reply-To: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
References: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
Message-ID: <q46O47wfBtE83i1q8k8ztS9DPacmCsNL_zW67ZYNhaw=.ed1aca9d-f892-4395-ba35-3883e499c814@github.com>

> - The hand-crafted methods for addition and multiplication are replaced by the "Math" versions.
> - Cleanup: the usage of do/while(false) is removed

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Initial version 8264666
 - Merge branch 'master' into LCMSImageLayout
 - Revert "safeXX -> xxExact"
   
   This reverts commit a1876fa596a6831f036c04f45fa89c2caba47087.
 - Revert "delete "do{...} while (false);""
   
   This reverts commit a9e91601c355f96c82dd8b2b8564a3a3e7b96aef.
 - delete "do{...} while (false);"
 - safeXX -> xxExact

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3333/files
  - new: https://git.openjdk.java.net/jdk/pull/3333/files/a9e91601..b183980c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3333&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3333&range=00-01

  Stats: 2331707 lines in 19244 files changed: 1311618 ins; 893703 del; 126386 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3333.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3333/head:pull/3333

PR: https://git.openjdk.java.net/jdk/pull/3333


From azvegint at openjdk.java.net  Fri Apr 22 07:37:09 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 22 Apr 2022 07:37:09 GMT
Subject: RFR: 8225777: java/awt/Mixing/MixingOnDialog.java fails on Ubuntu
 [v2]
In-Reply-To: <VQLsDzN8qiIssQllKP6jgXgc1UwWbjO3O2rS8eT8wTk=.dc8fa68c-816f-41c9-9bb8-20d503246440@github.com>
References: <VQLsDzN8qiIssQllKP6jgXgc1UwWbjO3O2rS8eT8wTk=.dc8fa68c-816f-41c9-9bb8-20d503246440@github.com>
Message-ID: <Uw1VJWx0g9RASy-dqZEgsLO2z6nJf8wArs-PBnW2YpU=.9f6a12bc-522e-4f8f-a436-7ac2ea580df2@github.com>

> The test was failing due to it tried to place windows too close to left top corner, so they got shifted from the dock and top panel on Gnome.
> 
> Shifting all test windows fixes the issue.
> 
> 
> Testing is green on all platforms.

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  Standard Test Machinery removed

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8326/files
  - new: https://git.openjdk.java.net/jdk/pull/8326/files/75694893..cae948ae

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8326&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8326&range=00-01

  Stats: 167 lines in 1 file changed: 7 ins; 148 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8326.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8326/head:pull/8326

PR: https://git.openjdk.java.net/jdk/pull/8326


From azvegint at openjdk.java.net  Fri Apr 22 07:37:09 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 22 Apr 2022 07:37:09 GMT
Subject: RFR: 8225777: java/awt/Mixing/MixingOnDialog.java fails on Ubuntu
 [v2]
In-Reply-To: <fxz94-qMf_Od_n7pRWsz8lDADoKKH3VEQMmrdF9KseY=.1ebcb05c-6123-424a-8e1c-bf8e5b3bdfab@github.com>
References: <VQLsDzN8qiIssQllKP6jgXgc1UwWbjO3O2rS8eT8wTk=.dc8fa68c-816f-41c9-9bb8-20d503246440@github.com>
 <fxz94-qMf_Od_n7pRWsz8lDADoKKH3VEQMmrdF9KseY=.1ebcb05c-6123-424a-8e1c-bf8e5b3bdfab@github.com>
Message-ID: <Wss_VZVwIugPFk8I8dQx1nOdkdguNVwWmioYIMinU9s=.63b6a0c8-25ff-4edb-853b-71a6766e7f5e@github.com>

On Fri, 22 Apr 2022 05:17:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Is it possible to remove the obsolete "Standard Test Machinery Section" which we have removed from other tests?

Sure, updated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8326


From psadhukhan at openjdk.java.net  Fri Apr 22 08:24:28 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 22 Apr 2022 08:24:28 GMT
Subject: RFR: 8225777: java/awt/Mixing/MixingOnDialog.java fails on Ubuntu
 [v2]
In-Reply-To: <Uw1VJWx0g9RASy-dqZEgsLO2z6nJf8wArs-PBnW2YpU=.9f6a12bc-522e-4f8f-a436-7ac2ea580df2@github.com>
References: <VQLsDzN8qiIssQllKP6jgXgc1UwWbjO3O2rS8eT8wTk=.dc8fa68c-816f-41c9-9bb8-20d503246440@github.com>
 <Uw1VJWx0g9RASy-dqZEgsLO2z6nJf8wArs-PBnW2YpU=.9f6a12bc-522e-4f8f-a436-7ac2ea580df2@github.com>
Message-ID: <WE4WeYj42rsiSgZ3-wAyHYbqvFvGqK-TNT4zbMjda4A=.ea2702ba-6791-4397-b826-bc8828f1d41d@github.com>

On Fri, 22 Apr 2022 07:37:09 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> The test was failing due to it tried to place windows too close to left top corner, so they got shifted from the dock and top panel on Gnome.
>> 
>> Shifting all test windows fixes the issue.
>> 
>> 
>> Testing is green on all platforms.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Standard Test Machinery removed

Seems like the test does not finish in standalone mode nor dispose its frame.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8326


From psadhukhan at openjdk.java.net  Fri Apr 22 08:41:22 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 22 Apr 2022 08:41:22 GMT
Subject: RFR: 7080150: [TEST_BUG][macosx] No mac os x EmbeddedFrame support
 in regression regtesthelpers [v2]
In-Reply-To: <YN2s_fyZJZsnMmSemoNnlt356YNhw-6YQO8qNPB3RBw=.71f188ab-a1e6-4cef-80ec-c0b61e5e6b31@github.com>
References: <abWDTHr4uorNjVddaR6Ai-ZOn_5XNpg__RO5PSi4z-o=.01f596f9-c7c8-4ccc-8dba-84f28eca25c2@github.com>
 <YN2s_fyZJZsnMmSemoNnlt356YNhw-6YQO8qNPB3RBw=.71f188ab-a1e6-4cef-80ec-c0b61e5e6b31@github.com>
Message-ID: <wb06X6ii7k1iM3dN5IIyBJtz_wIdj9Ksd1crlxQZTeI=.44583be9-2b68-43ab-9071-52776edacaf0@github.com>

On Thu, 21 Apr 2022 20:07:17 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> added EmbeddedFrame support for macosx in regtesthelpers
>
> Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch '7080150' of github.com:alisenchung/jdk into 7080150
>  - fixed merge conflict

test/jdk/java/awt/regtesthelpers/UtilInternal.java line 81:

> 79:             Method get_target = window_peer_class.getMethod("getTarget", new Class[0]);
> 80:             System.out.println("get_target = " + get_target);
> 81:             return (Frame) get_target.invoke(frame_peer, new Object[0]);

Shouldn't we invoke sun/lwawt/macosx/CEmbeddedFrame same as we do for windows/linux via WEmbeddedFrame and XEmbeddedFrame?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8348


From azvegint at openjdk.java.net  Fri Apr 22 10:24:18 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 22 Apr 2022 10:24:18 GMT
Subject: RFR: 8225777: java/awt/Mixing/MixingOnDialog.java fails on Ubuntu
 [v3]
In-Reply-To: <VQLsDzN8qiIssQllKP6jgXgc1UwWbjO3O2rS8eT8wTk=.dc8fa68c-816f-41c9-9bb8-20d503246440@github.com>
References: <VQLsDzN8qiIssQllKP6jgXgc1UwWbjO3O2rS8eT8wTk=.dc8fa68c-816f-41c9-9bb8-20d503246440@github.com>
Message-ID: <NbEim_BkQ6QS_LAzd0UzwmbcNpXS-ex96jHxYbIJHcU=.7694afec-e299-4025-ae2e-98b34021a40d@github.com>

> The test was failing due to it tried to place windows too close to left top corner, so they got shifted from the dock and top panel on Gnome.
> 
> Shifting all test windows fixes the issue.
> 
> 
> Testing is green on all platforms.

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  dialog disposal

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8326/files
  - new: https://git.openjdk.java.net/jdk/pull/8326/files/cae948ae..a6f180aa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8326&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8326&range=01-02

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8326.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8326/head:pull/8326

PR: https://git.openjdk.java.net/jdk/pull/8326


From azvegint at openjdk.java.net  Fri Apr 22 10:24:18 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 22 Apr 2022 10:24:18 GMT
Subject: RFR: 8225777: java/awt/Mixing/MixingOnDialog.java fails on Ubuntu
 [v2]
In-Reply-To: <WE4WeYj42rsiSgZ3-wAyHYbqvFvGqK-TNT4zbMjda4A=.ea2702ba-6791-4397-b826-bc8828f1d41d@github.com>
References: <VQLsDzN8qiIssQllKP6jgXgc1UwWbjO3O2rS8eT8wTk=.dc8fa68c-816f-41c9-9bb8-20d503246440@github.com>
 <Uw1VJWx0g9RASy-dqZEgsLO2z6nJf8wArs-PBnW2YpU=.9f6a12bc-522e-4f8f-a436-7ac2ea580df2@github.com>
 <WE4WeYj42rsiSgZ3-wAyHYbqvFvGqK-TNT4zbMjda4A=.ea2702ba-6791-4397-b826-bc8828f1d41d@github.com>
Message-ID: <WD5FIYzdBZeoIKxszrPtBRwD47hJHo6KPBdwLODSDLo=.15995b4c-e7da-4a93-a44c-e431260d770c@github.com>

On Fri, 22 Apr 2022 08:20:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Seems like the test does not finish in standalone mode nor dispose its frame.

fixed

-------------

PR: https://git.openjdk.java.net/jdk/pull/8326


From duke at openjdk.java.net  Fri Apr 22 16:44:07 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Fri, 22 Apr 2022 16:44:07 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v7]
In-Reply-To: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
Message-ID: <ELLNwhbSpCFrd0UOUDfh7RnGBCY8TNF9R4DLHg9ciH4=.d8b502ac-7eb4-432c-8283-638c5223e55f@github.com>

> The exisiting manual test case tests different html styles of JTabbedPane tab title. The tab with "big" as title is seen to be clipped on Aqua LAF for larger font-size. In other LAFs it is observed that bigger font-size can be accommodated without clipping.
> 
> The following approaches were evaluated before considering it as not a test issue -
> 
> - Aqua LAF has a different tab style compared to other LAFs as seen in the screenshot below. Limiting font size on Aqua LAF requires scaling down the text which might be incompatible with Aqua LAF.
> 
> - Removing existing constraints on text and icon is incompatible for Aqua LAF.
> 
> Since the above two approaches are incompatible with Aqua and it is not a test issue, a note has been added about clipped text and this test has been removed from problem list
> 
> ![image](https://user-images.githubusercontent.com/95945681/164093604-ca7ecbc3-09c2-4338-bd2a-f8c81c12f360.png)

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  formatted test instructions

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8307/files
  - new: https://git.openjdk.java.net/jdk/pull/8307/files/09109ab3..476d083b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8307&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8307&range=05-06

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8307.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8307/head:pull/8307

PR: https://git.openjdk.java.net/jdk/pull/8307


From duke at openjdk.java.net  Fri Apr 22 16:44:07 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Fri, 22 Apr 2022 16:44:07 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v5]
In-Reply-To: <_UHIfMMCOOxGYhiLHw-J2ZBCz5trAaQLrYmtmkYgihw=.74272360-b9e8-4475-93b0-7291e6afbbd1@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
 <eaCCY61HB7mlF1p_jRPAC887VXoRx6jm5BoI7JyQLW4=.9129f134-0b17-4d41-bbc3-089aff822bac@github.com>
 <KHbIp6WW25l2fgzNFa5-q-HutbSZHstdOdC9TnKw5UM=.71ff96fd-6d3b-4e3d-978f-0f8fe12426d9@github.com>
 <UyfHXtqLuWk6vuQeOPnAH7ErAqoXBiMU3tmghLs8QCY=.4641a3eb-0906-4f1f-b6d7-35d78ef69193@github.com>
 <_UHIfMMCOOxGYhiLHw-J2ZBCz5trAaQLrYmtmkYgihw=.74272360-b9e8-4475-93b0-7291e6afbbd1@github.com>
Message-ID: <l29t7v_wjgLiZNGoo2EpMrbKoPHvQEQMZ73rNz9l4Xc=.42a709b7-da8c-456d-bd2d-199f08142051@github.com>

On Fri, 22 Apr 2022 06:44:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> @prsadhuk Thanks for catching it. I'll make the required changes.
>
> SInce you are hardcoding PassFailFrame column to 35, it seems some word break is not perfect in the above instructions.
> Probably, you can put \n break at appropriate positions in NOTE to show better.

@prsadhuk Formatted test instructions as suggested.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8307


From serb at openjdk.java.net  Fri Apr 22 16:59:26 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Apr 2022 16:59:26 GMT
Subject: RFR: 8284965: closed test sun/java2d/OpenGL/XORPaint.java is
 unstable
In-Reply-To: <jXlD0hMF8qqSCVHqlppJoClNCXpgaeJrAbl6Ku6FY5M=.69f4c6b1-78cb-418d-b400-ba018ac4474a@github.com>
References: <jXlD0hMF8qqSCVHqlppJoClNCXpgaeJrAbl6Ku6FY5M=.69f4c6b1-78cb-418d-b400-ba018ac4474a@github.com>
Message-ID: <HdJd4ghTvcFPclCZYUpsLy7n5tmx3PeCMvV2hYVJM_s=.5a38f6d1-94a2-46c0-bc7c-89a02db0e90b@github.com>

On Thu, 21 Apr 2022 17:15:20 GMT, Phil Race <prr at openjdk.org> wrote:

> This fix moves a closed test to open but updated to be more comprehensive in testing multiple pipelines and with some stabilisation improvements.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8345


From serb at openjdk.java.net  Fri Apr 22 17:00:36 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Apr 2022 17:00:36 GMT
Subject: RFR: 8129778: Few awt test fail for Solaris 11 with
 RuntimeException
In-Reply-To: <nntgIawtEjj5eQGzpFvrWv4rQvXscCv_xw2jZ13-GAk=.73f66862-88aa-4eba-bbe7-fc95e54566af@github.com>
References: <nntgIawtEjj5eQGzpFvrWv4rQvXscCv_xw2jZ13-GAk=.73f66862-88aa-4eba-bbe7-fc95e54566af@github.com>
Message-ID: <o0mU35s_PMBJRbTmnPp4az8q1iM0I9PqJ0zp3GaH0cc=.42a36925-620f-4621-b3a3-899093eb6091@github.com>

On Thu, 21 Apr 2022 13:24:15 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Those tests were failing on Solaris, which is no longer supported.
> 
> They pass as they are, but decreasing of delays reduce execution time significantly:
> 
> e.g. proposed changes drops execution time from ~5min to ~2 min 
> for MouseButtonsAndKeyMasksTest on my machine.
> 
> Testing is green on all platforms.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8339


From serb at openjdk.java.net  Fri Apr 22 17:09:28 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Apr 2022 17:09:28 GMT
Subject: RFR: 8225777: java/awt/Mixing/MixingOnDialog.java fails on Ubuntu
 [v3]
In-Reply-To: <NbEim_BkQ6QS_LAzd0UzwmbcNpXS-ex96jHxYbIJHcU=.7694afec-e299-4025-ae2e-98b34021a40d@github.com>
References: <VQLsDzN8qiIssQllKP6jgXgc1UwWbjO3O2rS8eT8wTk=.dc8fa68c-816f-41c9-9bb8-20d503246440@github.com>
 <NbEim_BkQ6QS_LAzd0UzwmbcNpXS-ex96jHxYbIJHcU=.7694afec-e299-4025-ae2e-98b34021a40d@github.com>
Message-ID: <4rS9YCoQeoS3MAPjKpGYKpaNN288a5ibi488pif5-f8=.faef92c1-8aa2-4fe8-b18d-f02fa2dca5d6@github.com>

On Fri, 22 Apr 2022 10:24:18 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> The test was failing due to it tried to place windows too close to left top corner, so they got shifted from the dock and top panel on Gnome.
>> 
>> Shifting all test windows fixes the issue.
>> 
>> 
>> Testing is green on all platforms.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   dialog disposal

test/jdk/java/awt/Mixing/MixingOnDialog.java line 87:

> 85:         // Move the mouse pointer to the position where both
> 86:         //    buttons overlap
> 87:         Point heavyLoc = heavy.getLocationOnScreen();

"heavy" is assigned on a different thread, some synchronization could added.

test/jdk/java/awt/Mixing/MixingOnDialog.java line 95:

> 93:         robot.waitForIdle();
> 94: 
> 95:         SwingUtilities.invokeLater(() -> d.dispose());

invokeLater might not be executed before end of the test, it will be run after the main method ends.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8326


From psadhukhan at openjdk.java.net  Fri Apr 22 17:16:24 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 22 Apr 2022 17:16:24 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v7]
In-Reply-To: <ELLNwhbSpCFrd0UOUDfh7RnGBCY8TNF9R4DLHg9ciH4=.d8b502ac-7eb4-432c-8283-638c5223e55f@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
 <ELLNwhbSpCFrd0UOUDfh7RnGBCY8TNF9R4DLHg9ciH4=.d8b502ac-7eb4-432c-8283-638c5223e55f@github.com>
Message-ID: <jeAx7pZVCINgY2_7G5sV5TxBVBG178X3Y9r4MZNmJqA=.a4fbbae7-5dbd-4579-8768-0d09afbb7271@github.com>

On Fri, 22 Apr 2022 16:44:07 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> The exisiting manual test case tests different html styles of JTabbedPane tab title. The tab with "big" as title is seen to be clipped on Aqua LAF for larger font-size. In other LAFs it is observed that bigger font-size can be accommodated without clipping.
>> 
>> The following approaches were evaluated before considering it as not a test issue -
>> 
>> - Aqua LAF has a different tab style compared to other LAFs as seen in the screenshot below. Limiting font size on Aqua LAF requires scaling down the text which might be incompatible with Aqua LAF.
>> 
>> - Removing existing constraints on text and icon is incompatible for Aqua LAF.
>> 
>> Since the above two approaches are incompatible with Aqua and it is not a test issue, a note has been added about clipped text and this test has been removed from problem list
>> 
>> ![image](https://user-images.githubusercontent.com/95945681/164093604-ca7ecbc3-09c2-4338-bd2a-f8c81c12f360.png)
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   formatted test instructions

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8307


From prr at openjdk.java.net  Fri Apr 22 17:41:24 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 22 Apr 2022 17:41:24 GMT
Subject: RFR: 8129778: Few awt test fail for Solaris 11 with
 RuntimeException
In-Reply-To: <nntgIawtEjj5eQGzpFvrWv4rQvXscCv_xw2jZ13-GAk=.73f66862-88aa-4eba-bbe7-fc95e54566af@github.com>
References: <nntgIawtEjj5eQGzpFvrWv4rQvXscCv_xw2jZ13-GAk=.73f66862-88aa-4eba-bbe7-fc95e54566af@github.com>
Message-ID: <ORoiAJkWczgp1pyY4EtgFXx5_OtB_Wmt5NSTf4oPyJI=.1a01be35-ac18-4642-b25b-a381818d00a9@github.com>

On Thu, 21 Apr 2022 13:24:15 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Those tests were failing on Solaris, which is no longer supported.
> 
> They pass as they are, but decreasing of delays reduce execution time significantly:
> 
> e.g. proposed changes drops execution time from ~5min to ~2 min 
> for MouseButtonsAndKeyMasksTest on my machine.
> 
> Testing is green on all platforms.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8339


From naoto at openjdk.java.net  Fri Apr 22 17:49:27 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 22 Apr 2022 17:49:27 GMT
Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong
 size
In-Reply-To: <z72T3X_wgR6K7BdFL7Tqg8t6GXbJh-Vk0pDGCJjUnEE=.ba87e570-fc0b-45d5-8099-9ffeeeb09fc5@github.com>
References: <z72T3X_wgR6K7BdFL7Tqg8t6GXbJh-Vk0pDGCJjUnEE=.ba87e570-fc0b-45d5-8099-9ffeeeb09fc5@github.com>
Message-ID: <EkfMHAN30pF5gKrYt7wXu4AG_ynlrIAHT3PyYkfgYHw=.e60a87e6-59fe-419a-8329-3d1355771190@github.com>

On Thu, 21 Apr 2022 09:14:14 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

> Japanese logical fonts are drawn with wrong size since Java 18.
> It's triggered by JEP 400, UTF-8 by Default. `sun.awt.FontConfiguration` (and `sun.awt.windows.WFontConfiguration`) seems to expect the native encoding instead of the default encoding. This patch changes to use native encoding.
> 
> Tested: jdk_desktop on Windows, Linux, and macOS

With JEP 400, the default charset may differ from the platform encoding, which is the case like this on Windows (mac & Linux won't be affected as they already use UTF-8 natively) and the mitigation here looks fine to me. But the real issue here to me is why the font size gets bigger depending on the encoding (windows-31j vs. UTF-8)?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8329


From azvegint at openjdk.java.net  Fri Apr 22 17:52:20 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 22 Apr 2022 17:52:20 GMT
Subject: RFR: 8225777: java/awt/Mixing/MixingOnDialog.java fails on Ubuntu
 [v4]
In-Reply-To: <VQLsDzN8qiIssQllKP6jgXgc1UwWbjO3O2rS8eT8wTk=.dc8fa68c-816f-41c9-9bb8-20d503246440@github.com>
References: <VQLsDzN8qiIssQllKP6jgXgc1UwWbjO3O2rS8eT8wTk=.dc8fa68c-816f-41c9-9bb8-20d503246440@github.com>
Message-ID: <_LqQzGG2KEEVS73LQzkX-DluseYWv4-sA2GVCt7CvBA=.4dc7be33-ea42-4333-8d24-ac37bc7b65d3@github.com>

> The test was failing due to it tried to place windows too close to left top corner, so they got shifted from the dock and top panel on Gnome.
> 
> Shifting all test windows fixes the issue.
> 
> 
> Testing is green on all platforms.

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8326/files
  - new: https://git.openjdk.java.net/jdk/pull/8326/files/a6f180aa..7b5e49ea

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8326&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8326&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8326.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8326/head:pull/8326

PR: https://git.openjdk.java.net/jdk/pull/8326


From achung at openjdk.java.net  Fri Apr 22 17:52:37 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Fri, 22 Apr 2022 17:52:37 GMT
Subject: RFR: 7080150: [TEST_BUG][macosx] No mac os x EmbeddedFrame support
 in regression regtesthelpers [v2]
In-Reply-To: <wb06X6ii7k1iM3dN5IIyBJtz_wIdj9Ksd1crlxQZTeI=.44583be9-2b68-43ab-9071-52776edacaf0@github.com>
References: <abWDTHr4uorNjVddaR6Ai-ZOn_5XNpg__RO5PSi4z-o=.01f596f9-c7c8-4ccc-8dba-84f28eca25c2@github.com>
 <YN2s_fyZJZsnMmSemoNnlt356YNhw-6YQO8qNPB3RBw=.71f188ab-a1e6-4cef-80ec-c0b61e5e6b31@github.com>
 <wb06X6ii7k1iM3dN5IIyBJtz_wIdj9Ksd1crlxQZTeI=.44583be9-2b68-43ab-9071-52776edacaf0@github.com>
Message-ID: <6ZgUTjzqY7BMiXBOVBgNe0eDs-cRoH6AaHf3xv_fV9Q=.c2db1051-7791-49db-9cfd-fd730aa67b90@github.com>

On Fri, 22 Apr 2022 08:38:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch '7080150' of github.com:alisenchung/jdk into 7080150
>>  - fixed merge conflict
>
> test/jdk/java/awt/regtesthelpers/UtilInternal.java line 81:
> 
>> 79:             Method get_target = window_peer_class.getMethod("getTarget", new Class[0]);
>> 80:             System.out.println("get_target = " + get_target);
>> 81:             return (Frame) get_target.invoke(frame_peer, new Object[0]);
> 
> Shouldn't we invoke sun/lwawt/macosx/CEmbeddedFrame same as we do for windows/linux via WEmbeddedFrame and XEmbeddedFrame?

CEmbeddedFrame doesn't have a way to pass in a handle like in WEmbeddedFrame and XEmbeddedFrame, so I can't pass in the peer's target. If I try to use CEmbeddedFrame the test window will pop up but the EmbeddedFrame won't show up and the test fails

-------------

PR: https://git.openjdk.java.net/jdk/pull/8348


From achung at openjdk.java.net  Fri Apr 22 18:07:28 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Fri, 22 Apr 2022 18:07:28 GMT
Subject: RFR: 8284767: Create an automated test for JDK-4422535
In-Reply-To: <iWC939OdQdtwd4aHn2SafTsP1e1knRWsxNCzKos1Cts=.e7b80f3f-8fb2-41a1-af41-0e31131d756e@github.com>
References: <iWC939OdQdtwd4aHn2SafTsP1e1knRWsxNCzKos1Cts=.e7b80f3f-8fb2-41a1-af41-0e31131d756e@github.com>
Message-ID: <kNE14UIut-46FLz8TyB-DQN7WDZkDM_eV05KZagop1Q=.dcdc183c-79bf-4489-8a4c-9ef172039570@github.com>

On Wed, 13 Apr 2022 11:02:05 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Create an automated test for [JDK-4422535](https://bugs.openjdk.java.net/browse/JDK-4422535)
> AccessibleValue implementation only accept Integers
> The AccessibleValue implementations of the following components:
> 
> java.awt.Scrollbar
> javax.swing.AbstractButton
> javax.swing.JInternalFrame
> javax.swing.JSplitPane
> javax.swing.JScrollBar
> javax.swing.JProgressBar
> javax.swing.JSlider
> 
> require the argument to setCurrentAccessibleValue(Number) to be an Integer, else they completely ignore it - it returns a false indicating that the value has not been set by the return value, but they cannot know the reason for that).
> 
> The test verifies that for each of the above components, the AccessibleValue is set when it is set to a Number (Float, Double, long etc) and not just for an Integer.
> 
> his review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

test/jdk/javax/accessibility/4422535/SetCurrentAccessibleValueTest.java line 93:

> 91:         }
> 92: 
> 93:         if (!jScrollBar.getAccessibleContext().getAccessibleValue()

maybe you could write a loop to run each component?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8220


From prr at openjdk.java.net  Fri Apr 22 18:18:27 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 22 Apr 2022 18:18:27 GMT
Subject: RFR: 8225777: java/awt/Mixing/MixingOnDialog.java fails on Ubuntu
 [v4]
In-Reply-To: <_LqQzGG2KEEVS73LQzkX-DluseYWv4-sA2GVCt7CvBA=.4dc7be33-ea42-4333-8d24-ac37bc7b65d3@github.com>
References: <VQLsDzN8qiIssQllKP6jgXgc1UwWbjO3O2rS8eT8wTk=.dc8fa68c-816f-41c9-9bb8-20d503246440@github.com>
 <_LqQzGG2KEEVS73LQzkX-DluseYWv4-sA2GVCt7CvBA=.4dc7be33-ea42-4333-8d24-ac37bc7b65d3@github.com>
Message-ID: <lQak_5lLEpKZ1gZPtilq7cJve4R7wPnPWJjn4nQGLJc=.1407c764-d3b3-48ba-84a0-dd281a8fe414@github.com>

On Fri, 22 Apr 2022 17:52:20 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> The test was failing due to it tried to place windows too close to left top corner, so they got shifted from the dock and top panel on Gnome.
>> 
>> Shifting all test windows fixes the issue.
>> 
>> 
>> Testing is green on all platforms.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8326


From duke at openjdk.java.net  Fri Apr 22 18:18:36 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Fri, 22 Apr 2022 18:18:36 GMT
Subject: RFR: 8196367:
 java/awt/List/SingleModeDeselect/SingleModeDeselect.java times out
In-Reply-To: <RIp2Ct6nMnFaHBjOegrgbWQkW9ADpi2_67NissUngQ0=.6756c018-50d2-46e1-a21b-edb807fd7ad5@github.com>
References: <RIp2Ct6nMnFaHBjOegrgbWQkW9ADpi2_67NissUngQ0=.6756c018-50d2-46e1-a21b-edb807fd7ad5@github.com>
Message-ID: <ZsqTEPdYi0k2v5BE2mOCFB3VHXJsU8DV1L5K6HgKTBE=.24ab3ec4-879c-4ec6-8d11-13ad801e6e5d@github.com>

On Thu, 21 Apr 2022 22:03:17 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Clean up imports;
> Close and dispose frame before exiting the test;

test/jdk/java/awt/List/SingleModeDeselect/SingleModeDeselect.java line 66:

> 64:                 throw new RuntimeException("Test failed: List.getSelectedIndex() returns "+list.getSelectedIndex());
> 65:             }
> 66:         } finally {

Can these try blocks be combined into one block? Also from my previous PR's, I believe it's standard to have spaces around the "+" before `list.getSelectedIndex()`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8351


From achung at openjdk.java.net  Fri Apr 22 19:48:46 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Fri, 22 Apr 2022 19:48:46 GMT
Subject: RFR: JDK-8202790: DnD test DisposeFrameOnDragTest.java does not clean
 up
Message-ID: <QdsX-pN6mlmPluFzEBtyEHd0xBqbqH2wfR58jxC4BHg=.e606e5c6-ead4-49e9-98e2-97fb0fcf045c@github.com>

Added a background to the test to prevent the file from dragging onto the desktop and creating an extra file.

-------------

Commit messages:
 - added background to prevent file creation during drag and drop

Changes: https://git.openjdk.java.net/jdk/pull/8370/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8370&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8202790
  Stats: 8 lines in 2 files changed: 7 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8370.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8370/head:pull/8370

PR: https://git.openjdk.java.net/jdk/pull/8370


From duke at openjdk.java.net  Fri Apr 22 20:13:00 2022
From: duke at openjdk.java.net (Dan Lutker)
Date: Fri, 22 Apr 2022 20:13:00 GMT
Subject: RFR: 7131823: Loading some animated GIFs fails with
 =?UTF-8?B?QXJyYXlJbmRleE91dE9mQm91bmRzReKApg==?=
Message-ID: <LjpJTsq96m0N24mLMjS0p1aqlUBXvBHz9-E2uh4MPQU=.8df8c3ec-9271-498a-9f84-bff49db24e67@github.com>

?xception: Index 4096 out of bounds for length 4096

Adapted from https://github.com/openjdk/jfx/commit/7b7050c46299c0e6771ae02fbb5ceaf22104d3e4

# Testing done
Build locally on linux and ran jdk_imageio tests.

-------------

Commit messages:
 - 7131823: Loading some animated GIFs fails with ArrayIndexOutOfBoundsException: Index 4096 out of bounds for length 4096

Changes: https://git.openjdk.java.net/jdk/pull/8371/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8371&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-7131823
  Stats: 173 lines in 2 files changed: 155 ins; 3 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8371.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8371/head:pull/8371

PR: https://git.openjdk.java.net/jdk/pull/8371


From achung at openjdk.java.net  Fri Apr 22 20:45:43 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Fri, 22 Apr 2022 20:45:43 GMT
Subject: RFR: 8198666: Many java/awt/Modal/OnTop/ test fails on mac
Message-ID: <N4gaazOwBJPl-soN1a8chVdup4YqVMNHhmNPWpSybtw=.e6d1eb0e-9ede-40df-acd5-d7f45a371ee4@github.com>

Removed passing tests from problem list

-------------

Commit messages:
 - removed other tests from problem list
 - removed tests from ProblemList

Changes: https://git.openjdk.java.net/jdk/pull/8368/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8368&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8198666
  Stats: 30 lines in 1 file changed: 0 ins; 30 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8368.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8368/head:pull/8368

PR: https://git.openjdk.java.net/jdk/pull/8368


From kizune at openjdk.java.net  Fri Apr 22 21:05:26 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 22 Apr 2022 21:05:26 GMT
Subject: RFR: 8198666: Many java/awt/Modal/OnTop/ test fails on mac
In-Reply-To: <N4gaazOwBJPl-soN1a8chVdup4YqVMNHhmNPWpSybtw=.e6d1eb0e-9ede-40df-acd5-d7f45a371ee4@github.com>
References: <N4gaazOwBJPl-soN1a8chVdup4YqVMNHhmNPWpSybtw=.e6d1eb0e-9ede-40df-acd5-d7f45a371ee4@github.com>
Message-ID: <zA3Qw0d4I-MqQzuyR3y-qcfCoTWzI4CTX_4er2jd9V0=.fa0c1b9f-2bb4-439c-be7e-99cdca787023@github.com>

On Fri, 22 Apr 2022 17:38:28 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Removed passing tests from problem list

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8368


From kizune at openjdk.java.net  Fri Apr 22 21:57:23 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 22 Apr 2022 21:57:23 GMT
Subject: RFR: 8196367:
 java/awt/List/SingleModeDeselect/SingleModeDeselect.java times out [v2]
In-Reply-To: <RIp2Ct6nMnFaHBjOegrgbWQkW9ADpi2_67NissUngQ0=.6756c018-50d2-46e1-a21b-edb807fd7ad5@github.com>
References: <RIp2Ct6nMnFaHBjOegrgbWQkW9ADpi2_67NissUngQ0=.6756c018-50d2-46e1-a21b-edb807fd7ad5@github.com>
Message-ID: <d1G3pnLgw8mrtP8y4idWhxp_5zmgZYDpdUl4FtoMHyU=.2bbb6592-1685-4732-9461-e7daeb0fb292@github.com>

> Clean up imports;
> Close and dispose frame before exiting the test;

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Use one tyr/catch instead of two
  Generic code cleanup

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8351/files
  - new: https://git.openjdk.java.net/jdk/pull/8351/files/7b86b9ba..fe4aee44

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8351&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8351&range=00-01

  Stats: 14 lines in 1 file changed: 5 ins; 7 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8351.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8351/head:pull/8351

PR: https://git.openjdk.java.net/jdk/pull/8351


From serb at openjdk.java.net  Fri Apr 22 22:00:24 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Apr 2022 22:00:24 GMT
Subject: RFR: 8198666: Many java/awt/Modal/OnTop/ test fails on mac
In-Reply-To: <N4gaazOwBJPl-soN1a8chVdup4YqVMNHhmNPWpSybtw=.e6d1eb0e-9ede-40df-acd5-d7f45a371ee4@github.com>
References: <N4gaazOwBJPl-soN1a8chVdup4YqVMNHhmNPWpSybtw=.e6d1eb0e-9ede-40df-acd5-d7f45a371ee4@github.com>
Message-ID: <jMfigIasF6OQ7Bb3F8f9B1rO_9AOLIRxQfHcNK-7-9Y=.03085c7b-c3f3-4be6-bb01-cd32aa36cc81@github.com>

On Fri, 22 Apr 2022 17:38:28 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Removed passing tests from problem list

When these tests were added to the problem list all of them fail at least once in a couple of iterations, see [JDK-8198693](https://bugs.openjdk.java.net/browse/JDK-8198693). Please make sure that they are stable enough via many iterations.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8368


From serb at openjdk.java.net  Fri Apr 22 22:19:24 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Apr 2022 22:19:24 GMT
Subject: RFR: 7131823: Loading some animated GIFs fails with
 =?UTF-8?B?QXJyYXlJbmRleE91dE9mQm91bmRzReKApg==?=
In-Reply-To: <LjpJTsq96m0N24mLMjS0p1aqlUBXvBHz9-E2uh4MPQU=.8df8c3ec-9271-498a-9f84-bff49db24e67@github.com>
References: <LjpJTsq96m0N24mLMjS0p1aqlUBXvBHz9-E2uh4MPQU=.8df8c3ec-9271-498a-9f84-bff49db24e67@github.com>
Message-ID: <2QLXKnvAiE6yowDnu5FlGiSrE4OliYWLiNGpRbEZTzc=.4dd85add-6fb3-4f8f-8224-914b75f3a7b0@github.com>

On Fri, 22 Apr 2022 20:04:32 GMT, Dan Lutker <duke at openjdk.java.net> wrote:

> ?xception: Index 4096 out of bounds for length 4096
> 
> Adapted from https://github.com/openjdk/jfx/commit/7b7050c46299c0e6771ae02fbb5ceaf22104d3e4
> 
> # Testing done
> Build locally on linux and ran jdk_imageio tests.

The fix looks fine. But I think the JBS description of the bug has two issues, and this change fixes only the first. So it will be better to fix both if it is clear what is the problem. Or create a separate issue for the AIOB exception.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8371


From serb at openjdk.java.net  Fri Apr 22 22:21:21 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Apr 2022 22:21:21 GMT
Subject: RFR: JDK-8202790: DnD test DisposeFrameOnDragTest.java does not
 clean up
In-Reply-To: <QdsX-pN6mlmPluFzEBtyEHd0xBqbqH2wfR58jxC4BHg=.e606e5c6-ead4-49e9-98e2-97fb0fcf045c@github.com>
References: <QdsX-pN6mlmPluFzEBtyEHd0xBqbqH2wfR58jxC4BHg=.e606e5c6-ead4-49e9-98e2-97fb0fcf045c@github.com>
Message-ID: <gSNKzTv7f6xKdHPsn4RdWub1IOxDjXrP4A23NObhDZE=.66e11860-5765-4b9d-92ec-97383b55b23e@github.com>

On Fri, 22 Apr 2022 19:41:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Added a background to the test to prevent the file from dragging onto the desktop and creating an extra file.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8370


From prr at openjdk.java.net  Fri Apr 22 22:24:23 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 22 Apr 2022 22:24:23 GMT
Subject: RFR: 8198666: Many java/awt/Modal/OnTop/ test fails on mac
In-Reply-To: <N4gaazOwBJPl-soN1a8chVdup4YqVMNHhmNPWpSybtw=.e6d1eb0e-9ede-40df-acd5-d7f45a371ee4@github.com>
References: <N4gaazOwBJPl-soN1a8chVdup4YqVMNHhmNPWpSybtw=.e6d1eb0e-9ede-40df-acd5-d7f45a371ee4@github.com>
Message-ID: <d9-aF6MUEGlXZQNHciG1VFWBEys05Whx7MY2Hw08ueU=.6d305e7e-2c98-4016-b69f-4ac7e64d2d5a@github.com>

On Fri, 22 Apr 2022 17:38:28 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Removed passing tests from problem list

Yeah, these modal tests were VERY unstable.  I can't think of anything we fixed which would make them stable again,
so we should repeat these tests maybe 100 times to make sure they pass before removing them.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8368


From serb at openjdk.java.net  Fri Apr 22 22:24:24 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Apr 2022 22:24:24 GMT
Subject: RFR: 7132796: [macosx]
 closed/javax/swing/JComboBox/4517214/bug4517214.java fails on MacOS
In-Reply-To: <DFryrg8OZJ22xBLpprcnD14oXkSjF57fQA3jdwTD2Ko=.0a3b8830-4d7e-4c7e-8c1f-2932cd7ca1a8@github.com>
References: <DFryrg8OZJ22xBLpprcnD14oXkSjF57fQA3jdwTD2Ko=.0a3b8830-4d7e-4c7e-8c1f-2932cd7ca1a8@github.com>
Message-ID: <LSVqLnxD_znEaJw2BLBpPBx4XemnLujxRCyrxI06_2I=.1d76deda-43fb-4a3e-9ed1-cb6ee9748e2e@github.com>

On Thu, 14 Apr 2022 06:50:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> JDK-4517214 was fixed for Metal L&F where JComboBox having TitledBorder used to have double height compared to normal JComboBox.
> The issue is still observed for macos for Aqua L&F where still double height is seen.
> Fix is to prevent adding border insets height to combobox size as was done for [MetalComboxUI.getMinimumSize[](url)](https://github.com/openjdk/jdk/blame/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalComboBoxUI.java#L384)
> The closed test is automated and moved to open. CI testing on all platform is ok.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8237


From kizune at openjdk.java.net  Fri Apr 22 22:27:26 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 22 Apr 2022 22:27:26 GMT
Subject: RFR: 8196367:
 java/awt/List/SingleModeDeselect/SingleModeDeselect.java times out [v2]
In-Reply-To: <ZsqTEPdYi0k2v5BE2mOCFB3VHXJsU8DV1L5K6HgKTBE=.24ab3ec4-879c-4ec6-8d11-13ad801e6e5d@github.com>
References: <RIp2Ct6nMnFaHBjOegrgbWQkW9ADpi2_67NissUngQ0=.6756c018-50d2-46e1-a21b-edb807fd7ad5@github.com>
 <ZsqTEPdYi0k2v5BE2mOCFB3VHXJsU8DV1L5K6HgKTBE=.24ab3ec4-879c-4ec6-8d11-13ad801e6e5d@github.com>
Message-ID: <xHJreZyukvd2Ly9T4_QIxylpm9DL1QAbQBe7jWAuo7A=.7fe69127-1cce-4ba5-846c-f9c4ca129483@github.com>

On Fri, 22 Apr 2022 17:54:49 GMT, DamonGuy <duke at openjdk.java.net> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use one tyr/catch instead of two
>>   Generic code cleanup
>
> test/jdk/java/awt/List/SingleModeDeselect/SingleModeDeselect.java line 66:
> 
>> 64:                 throw new RuntimeException("Test failed: List.getSelectedIndex() returns "+list.getSelectedIndex());
>> 65:             }
>> 66:         } finally {
> 
> Can these try blocks be combined into one block? Also from my previous PR's, I believe it's standard to have spaces around the "+" before `list.getSelectedIndex()`.

Yeah, it is part of the old code but since i'm moving these lines around i might as well fix that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8351


From serb at openjdk.java.net  Fri Apr 22 22:28:35 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Apr 2022 22:28:35 GMT
Subject: RFR: 8193543: Regression automated test
 '/open/test/jdk/java/awt/TrayIcon/SystemTrayInstance/SystemTrayInstanceTest.java'
 fails
In-Reply-To: <6S1J2MYhxOU4Gt_H5xTetVR0pkrM7iIlLfkOf9mlo_g=.ccdbb91e-16b1-4982-85d8-27e6a2754939@github.com>
References: <6S1J2MYhxOU4Gt_H5xTetVR0pkrM7iIlLfkOf9mlo_g=.ccdbb91e-16b1-4982-85d8-27e6a2754939@github.com>
Message-ID: <bIMMkedreRVK7IPcbzFY2CpDq3mdHPA7sVMDnteDbTE=.4b8175b0-414e-4c3c-bf89-b70f66b66e71@github.com>

On Thu, 21 Apr 2022 17:47:12 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Looks like this test was written based on assumption that SystemTray is supported on all platforms.
> 
> However on Linux it may not be true. 
> 
> Availability of SystemTray is detected by getting owner of `_NET_SYSTEM_TRAY` selection:
> 
> https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/unix/classes/sun/awt/X11/XSystemTrayPeer.java#L42
> 
> https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/unix/classes/sun/awt/X11/XSystemTrayPeer.java#L58-L59
> 
> 
> As an example, SystemTray is not available on Wayland because of this.
> 
> 
> 
> So I modified the test:
> 
> - WIndows and macOS: expecting available SystemTray.
> - Linux: check absence/presence of `UnsupportedOperationException` exception of `SystemTray.getSystemTray()` call  based on `SystemTray.isSupported()` result.
> 
> Testing is green on all platforms.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8346


From serb at openjdk.java.net  Fri Apr 22 22:33:26 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Apr 2022 22:33:26 GMT
Subject: RFR: 7080150: [TEST_BUG][macosx] No mac os x EmbeddedFrame support
 in regression regtesthelpers [v2]
In-Reply-To: <6ZgUTjzqY7BMiXBOVBgNe0eDs-cRoH6AaHf3xv_fV9Q=.c2db1051-7791-49db-9cfd-fd730aa67b90@github.com>
References: <abWDTHr4uorNjVddaR6Ai-ZOn_5XNpg__RO5PSi4z-o=.01f596f9-c7c8-4ccc-8dba-84f28eca25c2@github.com>
 <YN2s_fyZJZsnMmSemoNnlt356YNhw-6YQO8qNPB3RBw=.71f188ab-a1e6-4cef-80ec-c0b61e5e6b31@github.com>
 <wb06X6ii7k1iM3dN5IIyBJtz_wIdj9Ksd1crlxQZTeI=.44583be9-2b68-43ab-9071-52776edacaf0@github.com>
 <6ZgUTjzqY7BMiXBOVBgNe0eDs-cRoH6AaHf3xv_fV9Q=.c2db1051-7791-49db-9cfd-fd730aa67b90@github.com>
Message-ID: <gFlM0AY12mdaZOxwWoEQ18f6ftWlVO5-sIEzLZ-g99g=.8f0acf8c-d5c4-4381-8fbf-595a3759f77f@github.com>

On Fri, 22 Apr 2022 17:49:26 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> test/jdk/java/awt/regtesthelpers/UtilInternal.java line 81:
>> 
>>> 79:             Method get_target = window_peer_class.getMethod("getTarget", new Class[0]);
>>> 80:             System.out.println("get_target = " + get_target);
>>> 81:             return (Frame) get_target.invoke(frame_peer, new Object[0]);
>> 
>> Shouldn't we invoke sun/lwawt/macosx/CEmbeddedFrame same as we do for windows/linux via WEmbeddedFrame and XEmbeddedFrame?
>
> CEmbeddedFrame doesn't have a way to pass in a handle like in WEmbeddedFrame and XEmbeddedFrame, so I can't pass in the peer's target. If I try to use CEmbeddedFrame the test window will pop up but the EmbeddedFrame won't show up and the test fails

Are you sure that CEmbeddedFrame is used in the embedding functionality? We have another one on macOS CViewEmbeddedFrame. One of them was used for applets another one was used by the JAWT and SWT. Please double-check that the correct one is used for this test, and another one probably can be removed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8348


From duke at openjdk.java.net  Fri Apr 22 22:37:24 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Fri, 22 Apr 2022 22:37:24 GMT
Subject: RFR: 8196367:
 java/awt/List/SingleModeDeselect/SingleModeDeselect.java times out [v2]
In-Reply-To: <d1G3pnLgw8mrtP8y4idWhxp_5zmgZYDpdUl4FtoMHyU=.2bbb6592-1685-4732-9461-e7daeb0fb292@github.com>
References: <RIp2Ct6nMnFaHBjOegrgbWQkW9ADpi2_67NissUngQ0=.6756c018-50d2-46e1-a21b-edb807fd7ad5@github.com>
 <d1G3pnLgw8mrtP8y4idWhxp_5zmgZYDpdUl4FtoMHyU=.2bbb6592-1685-4732-9461-e7daeb0fb292@github.com>
Message-ID: <M8YSo34LBY6OJH9mDXFg8rFI8lLj9PRPOfhwiRn_q1s=.300eab73-f7cb-411b-83fe-ee7995f4396d@github.com>

On Fri, 22 Apr 2022 21:57:23 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Clean up imports;
>> Close and dispose frame before exiting the test;
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use one tyr/catch instead of two
>   Generic code cleanup

Looks good to me now. I ran the test with & without your changes and it no longer times out when it did previously.

-------------

Marked as reviewed by DamonGuy at github.com (no known OpenJDK username).

PR: https://git.openjdk.java.net/jdk/pull/8351


From serb at openjdk.java.net  Fri Apr 22 23:19:25 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Apr 2022 23:19:25 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v7]
In-Reply-To: <ELLNwhbSpCFrd0UOUDfh7RnGBCY8TNF9R4DLHg9ciH4=.d8b502ac-7eb4-432c-8283-638c5223e55f@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
 <ELLNwhbSpCFrd0UOUDfh7RnGBCY8TNF9R4DLHg9ciH4=.d8b502ac-7eb4-432c-8283-638c5223e55f@github.com>
Message-ID: <zwnj1_oWbP5E1Ubhjk4UgTH0r68aY0BeZZDg6BrUV2s=.2b4ffd55-d773-49eb-a837-6f1f9bacbb7e@github.com>

On Fri, 22 Apr 2022 16:44:07 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> The exisiting manual test case tests different html styles of JTabbedPane tab title. The tab with "big" as title is seen to be clipped on Aqua LAF for larger font-size. In other LAFs it is observed that bigger font-size can be accommodated without clipping.
>> 
>> The following approaches were evaluated before considering it as not a test issue -
>> 
>> - Aqua LAF has a different tab style compared to other LAFs as seen in the screenshot below. Limiting font size on Aqua LAF requires scaling down the text which might be incompatible with Aqua LAF.
>> 
>> - Removing existing constraints on text and icon is incompatible for Aqua LAF.
>> 
>> Since the above two approaches are incompatible with Aqua and it is not a test issue, a note has been added about clipped text and this test has been removed from problem list
>> 
>> ![image](https://user-images.githubusercontent.com/95945681/164093604-ca7ecbc3-09c2-4338-bd2a-f8c81c12f360.png)
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   formatted test instructions

Probably we should think about care of the big font in the aqua L&F and decrease the size we know it is too big?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8307


From serb at openjdk.java.net  Fri Apr 22 23:29:26 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Apr 2022 23:29:26 GMT
Subject: RFR: 8273506: java Robot API did the 'm' keypress and caused
 /awt/event/KeyEvent/KeyCharTest/KeyCharTest.html is timing out on macOS 12
 [v2]
In-Reply-To: <33wbZN4ZDtQ564BCCatIOTX2sVRXi308jFUzKbKOaVE=.4ecfdde4-74ed-4319-bf86-492c3e47a32b@github.com>
References: <jmtC1w9SyvfAg940bq60x20bVshEm5P2g7IExDWnpBk=.1cdcdbc2-881c-4cce-a2c0-73873369e0c5@github.com>
 <33wbZN4ZDtQ564BCCatIOTX2sVRXi308jFUzKbKOaVE=.4ecfdde4-74ed-4319-bf86-492c3e47a32b@github.com>
Message-ID: <MAimCg0Q8gqv0vhLraXUMDe0OG-YVRhrIkoa5WILhGU=.bd98a8ac-14e7-4198-9dbe-66fa10f6c5fb@github.com>

On Thu, 21 Apr 2022 18:50:16 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Clear the kCGEventFlagMaskSecondaryFn flag if it is set before posting keyboard events to the system queue.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding test case.

I am not sure do we need to discard the possibility to press the shortcuts via the FN key, if the user may press them then why the robot cannot do the same? Looks like the behavior of this key is similar to the capslock which can be toggled on/off and may have a similar issue? If yes then we can press that button in the test twice to set an initial state(similar to how could fix the same issue for the capslock).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8320


From duke at openjdk.java.net  Fri Apr 22 23:39:26 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Fri, 22 Apr 2022 23:39:26 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v7]
In-Reply-To: <zwnj1_oWbP5E1Ubhjk4UgTH0r68aY0BeZZDg6BrUV2s=.2b4ffd55-d773-49eb-a837-6f1f9bacbb7e@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
 <ELLNwhbSpCFrd0UOUDfh7RnGBCY8TNF9R4DLHg9ciH4=.d8b502ac-7eb4-432c-8283-638c5223e55f@github.com>
 <zwnj1_oWbP5E1Ubhjk4UgTH0r68aY0BeZZDg6BrUV2s=.2b4ffd55-d773-49eb-a837-6f1f9bacbb7e@github.com>
Message-ID: <luRX8eCoGyRuwQe_GYznZuZ5wIiebh_JY-yv_WC-7Y8=.07e99da1-cb7c-43d7-a219-3dd39984e785@github.com>

On Fri, 22 Apr 2022 23:15:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Probably we should think about care of the big font in the aqua L&F and decrease the size we know it is too big?

@mrserb since point size are estimates will this pose a problem while decreasing the size of the text? 
"to decrease the size when it is too big" do you mean the size set in the html string (tab-title) is parsed first, set to a lower value before tab height calculations are carried out?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8307


From serb at openjdk.java.net  Fri Apr 22 23:45:27 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Apr 2022 23:45:27 GMT
Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int)
 [v3]
In-Reply-To: <K5smO4U1soQAppd1LY9JqanDnB5mXk6GccdIh_0xrxQ=.44138af7-abb8-4a9d-9a21-9258befa0ee9@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
 <K5smO4U1soQAppd1LY9JqanDnB5mXk6GccdIh_0xrxQ=.44138af7-abb8-4a9d-9a21-9258befa0ee9@github.com>
Message-ID: <c5sN9QCc34gf8MlSn2U5w6eEnJegb1CxrI9Vm06U3Yg=.3f23a70e-bf36-44df-a0ab-ff3c3b9d9447@github.com>

On Wed, 20 Apr 2022 19:24:25 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> These are the changes that too many to be reviewed in 8186958, thus split some of them out.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add more replaces

src/demo/share/java2d/J2DBench/src/j2dbench/tests/text/TextTests.java line 291:

> 289: 
> 290: 
> 291:     static HashMap strcache = HashMap.newHashMap(tscripts.length);

This code maintains compatibility with jdk1.4, not necessary to change it.

src/java.datatransfer/share/classes/java/awt/datatransfer/SystemFlavorMap.java line 815:

> 813:         }
> 814: 
> 815:         Map<String, DataFlavor> retval =HashMap.newHashMap(natives.length);

missed space after '='

-------------

PR: https://git.openjdk.java.net/jdk/pull/8301


From serb at openjdk.java.net  Fri Apr 22 23:47:27 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Apr 2022 23:47:27 GMT
Subject: RFR: 8225777: java/awt/Mixing/MixingOnDialog.java fails on Ubuntu
 [v4]
In-Reply-To: <_LqQzGG2KEEVS73LQzkX-DluseYWv4-sA2GVCt7CvBA=.4dc7be33-ea42-4333-8d24-ac37bc7b65d3@github.com>
References: <VQLsDzN8qiIssQllKP6jgXgc1UwWbjO3O2rS8eT8wTk=.dc8fa68c-816f-41c9-9bb8-20d503246440@github.com>
 <_LqQzGG2KEEVS73LQzkX-DluseYWv4-sA2GVCt7CvBA=.4dc7be33-ea42-4333-8d24-ac37bc7b65d3@github.com>
Message-ID: <nuMfYj2Ld_AC_ZKGjtVbwAIg0qEcB402tYNdDOvSIj4=.ce08739a-86d4-4bfe-b3bd-35a1d1874492@github.com>

On Fri, 22 Apr 2022 17:52:20 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> The test was failing due to it tried to place windows too close to left top corner, so they got shifted from the dock and top panel on Gnome.
>> 
>> Shifting all test windows fixes the issue.
>> 
>> 
>> Testing is green on all platforms.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8326


From serb at openjdk.java.net  Fri Apr 22 23:52:51 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Apr 2022 23:52:51 GMT
Subject: RFR: 8264666: Change implementation of safeAdd/safeMult in the
 LCMSImageLayout class [v2]
In-Reply-To: <q46O47wfBtE83i1q8k8ztS9DPacmCsNL_zW67ZYNhaw=.ed1aca9d-f892-4395-ba35-3883e499c814@github.com>
References: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
 <q46O47wfBtE83i1q8k8ztS9DPacmCsNL_zW67ZYNhaw=.ed1aca9d-f892-4395-ba35-3883e499c814@github.com>
Message-ID: <NrVqzwXVxe8DKp3NL2JVW85X7JXse-zWsgh_1pxSLa4=.9529346a-0f6f-46cf-9d81-861ab433a2f5@github.com>

On Fri, 22 Apr 2022 07:36:43 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Description of the new version of the fix:
>> While I have worked on this change and tried to consider the comments, I have found that the usages of the "safeAdd/safeMult" in the LCMSImageLayout class are incorrect. Both methods are based on the "Math" versions but throw a different exception. The problem is that its implementation may accept the negative values during intermediate calculation, see the old implementation of "[verify](https://github.com/openjdk/jdk/blob/139615b1815d4afd3593536d83fa8b25430f35e7/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java#L343)" method:
>>  1. We check the "offset" value: 0 <= offset <  dataArrayLength
>>  2. We do some intermediate calculations that "accept" negative values
>>  3. We check the final "off" value: 0 <= offset <  dataArrayLength
>> 
>> I wondered is it possible to provide some data that using wrong/negative data at step2 may result in the correct check at step3. I spent some time and was able to reproduce the problem with the attached test case. Note that the test is a little bit cryptic since it is not possible to reproduce it by input image data.
>> 
>> Note: I have removed all cleanup from the fix, to make it simpler.
>> 
>> <======>
>> Description of the old version of the fix:
>> - The hand-crafted methods for addition and multiplication are replaced by the "Math" versions.
>> - Cleanup: the usage of do/while(false) is removed
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Initial version 8264666
>  - Merge branch 'master' into LCMSImageLayout
>  - Revert "safeXX -> xxExact"
>    
>    This reverts commit a1876fa596a6831f036c04f45fa89c2caba47087.
>  - Revert "delete "do{...} while (false);""
>    
>    This reverts commit a9e91601c355f96c82dd8b2b8564a3a3e7b96aef.
>  - delete "do{...} while (false);"
>  - safeXX -> xxExact

The fix is reworked based on the new facts about that methods.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3333


From prr at openjdk.java.net  Fri Apr 22 23:59:24 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 22 Apr 2022 23:59:24 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v7]
In-Reply-To: <ELLNwhbSpCFrd0UOUDfh7RnGBCY8TNF9R4DLHg9ciH4=.d8b502ac-7eb4-432c-8283-638c5223e55f@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
 <ELLNwhbSpCFrd0UOUDfh7RnGBCY8TNF9R4DLHg9ciH4=.d8b502ac-7eb4-432c-8283-638c5223e55f@github.com>
Message-ID: <T_fM_w7Iqx4lIbK8vJ3yE3VlmEzUYZJkD-OtUqx5uFk=.c7923c09-6526-41ee-830a-f61702ad3ab6@github.com>

On Fri, 22 Apr 2022 16:44:07 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> The exisiting manual test case tests different html styles of JTabbedPane tab title. The tab with "big" as title is seen to be clipped on Aqua LAF for larger font-size. In other LAFs it is observed that bigger font-size can be accommodated without clipping.
>> 
>> The following approaches were evaluated before considering it as not a test issue -
>> 
>> - Aqua LAF has a different tab style compared to other LAFs as seen in the screenshot below. Limiting font size on Aqua LAF requires scaling down the text which might be incompatible with Aqua LAF.
>> 
>> - Removing existing constraints on text and icon is incompatible for Aqua LAF.
>> 
>> Since the above two approaches are incompatible with Aqua and it is not a test issue, a note has been added about clipped text and this test has been removed from problem list
>> 
>> ![image](https://user-images.githubusercontent.com/95945681/164093604-ca7ecbc3-09c2-4338-bd2a-f8c81c12f360.png)
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   formatted test instructions

This is just to fix a complaint about the test.
Whether we want to make that policy change of ignoring font sizes that are "too big" is a separate issue. 
And  the best we could do is some estimate based on metrics of the font, which probably could be based
on the L&Fs max tab button size and calculated once. But some text could still be clipped.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8307


From duke at openjdk.java.net  Sat Apr 23 00:14:36 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Sat, 23 Apr 2022 00:14:36 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v7]
In-Reply-To: <T_fM_w7Iqx4lIbK8vJ3yE3VlmEzUYZJkD-OtUqx5uFk=.c7923c09-6526-41ee-830a-f61702ad3ab6@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
 <ELLNwhbSpCFrd0UOUDfh7RnGBCY8TNF9R4DLHg9ciH4=.d8b502ac-7eb4-432c-8283-638c5223e55f@github.com>
 <T_fM_w7Iqx4lIbK8vJ3yE3VlmEzUYZJkD-OtUqx5uFk=.c7923c09-6526-41ee-830a-f61702ad3ab6@github.com>
Message-ID: <-z0bHZlTfo7fN7BsGzz1PgoC8RvhLYSC6ZCRbgFoV2U=.6e809e27-166c-4de8-a58d-ddc982caddc8@github.com>

On Fri, 22 Apr 2022 23:56:05 GMT, Phil Race <prr at openjdk.org> wrote:

> This is just to fix a complaint about the test. Whether we want to make that policy change of ignoring font sizes that are "too big" is a separate issue. And the best we could do is some estimate based on metrics of the font, which probably could be based on the L&Fs max tab button size and calculated once. But some text could still be clipped.

@prrace Thank you Phil. Makes sense and will look into it as a separate issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8307


From kizune at openjdk.java.net  Sat Apr 23 07:25:36 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sat, 23 Apr 2022 07:25:36 GMT
Subject: RFR: 8273506: java Robot API did the 'm' keypress and caused
 /awt/event/KeyEvent/KeyCharTest/KeyCharTest.html is timing out on macOS 12
 [v2]
In-Reply-To: <MAimCg0Q8gqv0vhLraXUMDe0OG-YVRhrIkoa5WILhGU=.bd98a8ac-14e7-4198-9dbe-66fa10f6c5fb@github.com>
References: <jmtC1w9SyvfAg940bq60x20bVshEm5P2g7IExDWnpBk=.1cdcdbc2-881c-4cce-a2c0-73873369e0c5@github.com>
 <33wbZN4ZDtQ564BCCatIOTX2sVRXi308jFUzKbKOaVE=.4ecfdde4-74ed-4319-bf86-492c3e47a32b@github.com>
 <MAimCg0Q8gqv0vhLraXUMDe0OG-YVRhrIkoa5WILhGU=.bd98a8ac-14e7-4198-9dbe-66fa10f6c5fb@github.com>
Message-ID: <ATVnDSAZVpL6Ejw_ioaEB_f2rpnVo9pp9AyXetvR3lo=.f84a1a65-6193-4104-91c0-0d5901a21fc9@github.com>

On Fri, 22 Apr 2022 23:26:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I am not sure do we need to discard the possibility to press the shortcuts via the FN key, if the user may press them then why the robot cannot do the same? Looks like the behavior of this key is similar to the capslock which can be toggled on/off and may have a similar issue? If yes then we can press that button in the test twice to set an initial state(similar to how could fix the same issue for the capslock).

Ok, starting from the beginning - there is no possibility to press the Function key with Robot, the corresponding key code (OSX_Function - 0x3F) has not mapped to any of the keys available to Robot. Function key does not act like a caps lock - it acts like a shift. Just like a shift, it can only be fixated by the accessibility feature "sticky keys". Once Function key is released the global state should be changed in a way as if this key is not active. We do not issue key press or key release event for the Function key. The reason of why global state is being changed this way when we issue key press/key release sequence or a totally unrelated key (OSX_DownArrow - 0x7D) is unknown, it happens in the native code outside of our control. All we can do is to eliminate the consequences of this action that started to cause problems in Mac OS X 12.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8320


From duke at openjdk.java.net  Sat Apr 23 14:34:58 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Sat, 23 Apr 2022 14:34:58 GMT
Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int)
 [v4]
In-Reply-To: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
Message-ID: <zFlFjdt_WK9VyWsAxqnfhvu-MmJe1IKc7WtyBNkPE5A=.ec807db1-ad90-4e27-99d7-8a1ea145aa71@github.com>

> These are the changes that too many to be reviewed in 8186958, thus split some of them out.

XenoAmess has updated the pull request incrementally with two additional commits since the last revision:

 - maintains compatibility with jdk1.4 for TextTests
 - fix missed space after '='

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8301/files
  - new: https://git.openjdk.java.net/jdk/pull/8301/files/4f2d4838..684d1528

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8301.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301

PR: https://git.openjdk.java.net/jdk/pull/8301


From duke at openjdk.java.net  Sat Apr 23 14:35:00 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Sat, 23 Apr 2022 14:35:00 GMT
Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int)
 [v3]
In-Reply-To: <c5sN9QCc34gf8MlSn2U5w6eEnJegb1CxrI9Vm06U3Yg=.3f23a70e-bf36-44df-a0ab-ff3c3b9d9447@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
 <K5smO4U1soQAppd1LY9JqanDnB5mXk6GccdIh_0xrxQ=.44138af7-abb8-4a9d-9a21-9258befa0ee9@github.com>
 <c5sN9QCc34gf8MlSn2U5w6eEnJegb1CxrI9Vm06U3Yg=.3f23a70e-bf36-44df-a0ab-ff3c3b9d9447@github.com>
Message-ID: <rdVSOTyOu5G4qCiqJvK5w1_8xBgS62FcEZzco7j6eGE=.15f860a9-c29b-4a15-bae9-ab373509e775@github.com>

On Fri, 22 Apr 2022 23:31:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add more replaces
>
> src/demo/share/java2d/J2DBench/src/j2dbench/tests/text/TextTests.java line 291:
> 
>> 289: 
>> 290: 
>> 291:     static HashMap strcache = HashMap.newHashMap(tscripts.length);
> 
> This code maintains compatibility with jdk1.4, not necessary to change it.

@mrserb done.

> src/java.datatransfer/share/classes/java/awt/datatransfer/SystemFlavorMap.java line 815:
> 
>> 813:         }
>> 814: 
>> 815:         Map<String, DataFlavor> retval =HashMap.newHashMap(natives.length);
> 
> missed space after '='

@mrserb done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8301


From mvs at openjdk.java.net  Sat Apr 23 14:50:17 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Sat, 23 Apr 2022 14:50:17 GMT
Subject: RFR: 8283624: Create an automated regression test for RFE-4390885
 [v3]
In-Reply-To: <ulXuyM6cAT0OpsHOXQQCYcMFq29lzpwg66Jn8WHC5pY=.ba10753a-f153-4abb-965d-460660da17f7@github.com>
References: <DfOvs0ck3_ucgdZG8gdlmXPriMoEM9-RjaveRlmRZYA=.b6690b6a-4a51-4c98-b5ee-6409fe4b0f84@github.com>
 <ulXuyM6cAT0OpsHOXQQCYcMFq29lzpwg66Jn8WHC5pY=.ba10753a-f153-4abb-965d-460660da17f7@github.com>
Message-ID: <Xsx7J1xzkEOpVM44rglgMM5CRMlABJOivQibTF4AiGg=.56b0efa4-012f-4080-a862-a5af68d13d57@github.com>

On Wed, 20 Apr 2022 07:14:33 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Write a regression test for [JDK-4390885](https://bugs.openjdk.java.net/browse/JDK-4390885) Enhancement Request.
>> 
>> Issue:
>> Please add the ability to set the location of a JFileChooser. This might be a
>> bug, but JFileChooser.setLocation() has no effect when
>> JFileChooser.showXXXXDialog() is called. This is becoming very important as the
>> popularity of multiple monitors is increasing. These dialogs show up on the
>> wrong monitor which is really annoying. Also due to bug #4189244 I am unable to
>> avoid painting problems by positioning the dialog away from the menu item that
>> initiated it.
>> 
>> Fix:
>> Now it's possible to set the location of Dialog in JFileChooser.
>> 
>> Testing:
>> 1. Tested in Mach5 10 times per platform(macos,linux,windows) and got all Pass.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed some duplicate code

Any volunteers?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7996


From azvegint at openjdk.java.net  Sat Apr 23 20:43:40 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Sat, 23 Apr 2022 20:43:40 GMT
Subject: Integrated: 8129827: [TEST_BUG] Test
 java/awt/Robot/RobotWheelTest/RobotWheelTest.java fails
In-Reply-To: <yq6IVScF0JllG8OmDLu2_FPx_-wS5pir1-2cXeb2Be8=.4af01d28-0106-4ba2-93fe-391314b6469e@github.com>
References: <yq6IVScF0JllG8OmDLu2_FPx_-wS5pir1-2cXeb2Be8=.4af01d28-0106-4ba2-93fe-391314b6469e@github.com>
Message-ID: <gada6ePa0ngyVTwe4sMKFMS7QJtOU7x11hmdtsAQRSw=.5812ccb4-b345-4086-b1a6-a160971353b8@github.com>

On Tue, 19 Apr 2022 20:03:57 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Test was written based on assumption that we will receive only one `mouseWheelMoved` event with `getWheelRotation() == 20` after `robot.mouseWheel(20)` call, but we can receive 20  events with `getWheelRotation == 1` instead.
> 
> So the test is modified to accumulate wheel rotation values before checking.
> 
> Testing is green on all platforms.

This pull request has now been integrated.

Changeset: a1efb955
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a1efb95536fb3995780336604cc727f921770c63
Stats:     43 lines in 2 files changed: 32 ins; 6 del; 5 mod

8129827: [TEST_BUG] Test java/awt/Robot/RobotWheelTest/RobotWheelTest.java fails

Reviewed-by: psadhukhan

-------------

PR: https://git.openjdk.java.net/jdk/pull/8305


From azvegint at openjdk.java.net  Sat Apr 23 20:45:36 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Sat, 23 Apr 2022 20:45:36 GMT
Subject: Integrated: 8193543: Regression automated test
 '/open/test/jdk/java/awt/TrayIcon/SystemTrayInstance/SystemTrayInstanceTest.java'
 fails
In-Reply-To: <6S1J2MYhxOU4Gt_H5xTetVR0pkrM7iIlLfkOf9mlo_g=.ccdbb91e-16b1-4982-85d8-27e6a2754939@github.com>
References: <6S1J2MYhxOU4Gt_H5xTetVR0pkrM7iIlLfkOf9mlo_g=.ccdbb91e-16b1-4982-85d8-27e6a2754939@github.com>
Message-ID: <4ZDol2DNUoE5XS3Qrt_piKBVI_0IeqWG6kaIXshWEng=.5e207f17-bb12-46cb-8daa-3aa0be9914c7@github.com>

On Thu, 21 Apr 2022 17:47:12 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Looks like this test was written based on assumption that SystemTray is supported on all platforms.
> 
> However on Linux it may not be true. 
> 
> Availability of SystemTray is detected by getting owner of `_NET_SYSTEM_TRAY` selection:
> 
> https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/unix/classes/sun/awt/X11/XSystemTrayPeer.java#L42
> 
> https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/unix/classes/sun/awt/X11/XSystemTrayPeer.java#L58-L59
> 
> 
> As an example, SystemTray is not available on Wayland because of this.
> 
> 
> 
> So I modified the test:
> 
> - WIndows and macOS: expecting available SystemTray.
> - Linux: check absence/presence of `UnsupportedOperationException` exception of `SystemTray.getSystemTray()` call  based on `SystemTray.isSupported()` result.
> 
> Testing is green on all platforms.

This pull request has now been integrated.

Changeset: 08024d95
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/08024d9583d02398d986db0e9b32fe19a2b8fec2
Stats:     29 lines in 2 files changed: 14 ins; 2 del; 13 mod

8193543: Regression automated test '/open/test/jdk/java/awt/TrayIcon/SystemTrayInstance/SystemTrayInstanceTest.java' fails

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8346


From tnakamura at openjdk.java.net  Mon Apr 25 08:15:18 2022
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Mon, 25 Apr 2022 08:15:18 GMT
Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong
 size [v2]
In-Reply-To: <z72T3X_wgR6K7BdFL7Tqg8t6GXbJh-Vk0pDGCJjUnEE=.ba87e570-fc0b-45d5-8099-9ffeeeb09fc5@github.com>
References: <z72T3X_wgR6K7BdFL7Tqg8t6GXbJh-Vk0pDGCJjUnEE=.ba87e570-fc0b-45d5-8099-9ffeeeb09fc5@github.com>
Message-ID: <SAu4OKejClHuOK9uEAFVXIKnqfGBcfn3MtqNhuMoCPM=.fba07a11-93eb-494d-b098-62bd2b4fd107@github.com>

> Japanese logical fonts are drawn with wrong size since Java 18.
> It's triggered by JEP 400, UTF-8 by Default. `sun.awt.FontConfiguration` (and `sun.awt.windows.WFontConfiguration`) seems to expect the native encoding instead of the default encoding. This patch changes to use native encoding.
> 
> Tested: jdk_desktop on Windows, Linux, and macOS

Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision:

  Moved the fix to WFontConfiguration

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8329/files
  - new: https://git.openjdk.java.net/jdk/pull/8329/files/b8d737de..2a409cc6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8329&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8329&range=00-01

  Stats: 17 lines in 2 files changed: 10 ins; 3 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8329.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8329/head:pull/8329

PR: https://git.openjdk.java.net/jdk/pull/8329


From psadhukhan at openjdk.java.net  Mon Apr 25 09:43:55 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 25 Apr 2022 09:43:55 GMT
Subject: RFR: 8284888 : [macos]
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with
 "NimbusLookAndFeel] : ERROR: icon and imageIcon not same."
Message-ID: <pfa7K1bO4jVy0R3GkJTdMJG5eYhcdgojfPL_pILKlOA=.c2789888-0055-47a7-9c95-19f5d0cf3be0@github.com>

Test used to fail in specific CI macos M1 system owing to miniscule color difference 


x 0 y 0 red1 171 red2 171 green1 174 green2 175 blue1 184 blue2 184
x 0 y 1 red1 172 red2 173 green1 177 green2 177 blue1 185 blue2 185
x 0 y 2 red1 173 red2 174 green1 177 green2 178 blue1 187 blue2 187
x 0 y 6 red1 0 red2 0 green1 1 green2 0 blue1 0 blue2 0
x 0 y 15 red1 1 red2 0 green1 0 green2 0 blue1 0 blue2 0


SInce we already have color-tolerance check present, there is no need of exact color value check.
Also, made the frame undecorated and remove unneeded library being built. 
Several iterations of the test passed in the same system (where it used to fail 4/7) along with other platforms (link in JBS)

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/8380/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8380&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284888
  Stats: 14 lines in 1 file changed: 4 ins; 3 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8380.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8380/head:pull/8380

PR: https://git.openjdk.java.net/jdk/pull/8380


From azvegint at openjdk.java.net  Mon Apr 25 10:05:29 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 25 Apr 2022 10:05:29 GMT
Subject: Integrated: 8225777: java/awt/Mixing/MixingOnDialog.java fails on
 Ubuntu
In-Reply-To: <VQLsDzN8qiIssQllKP6jgXgc1UwWbjO3O2rS8eT8wTk=.dc8fa68c-816f-41c9-9bb8-20d503246440@github.com>
References: <VQLsDzN8qiIssQllKP6jgXgc1UwWbjO3O2rS8eT8wTk=.dc8fa68c-816f-41c9-9bb8-20d503246440@github.com>
Message-ID: <Rr6Dmj1jtznEmqGHbrAeN9zg1-0W7vhK6WpI0i6I-1I=.794973ca-ab5a-4426-827f-dfa5c17b857d@github.com>

On Thu, 21 Apr 2022 07:58:39 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The test was failing due to it tried to place windows too close to left top corner, so they got shifted from the dock and top panel on Gnome.
> 
> Shifting all test windows fixes the issue.
> 
> 
> Testing is green on all platforms.

This pull request has now been integrated.

Changeset: 36f2e524
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/36f2e5240b8c4d94643188d3a9d87d906c1e8bdf
Stats:     177 lines in 2 files changed: 7 ins; 141 del; 29 mod

8225777: java/awt/Mixing/MixingOnDialog.java fails on Ubuntu

Reviewed-by: prr, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8326


From azvegint at openjdk.java.net  Mon Apr 25 10:06:20 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 25 Apr 2022 10:06:20 GMT
Subject: Integrated: 8129778: Few awt test fail for Solaris 11 with
 RuntimeException
In-Reply-To: <nntgIawtEjj5eQGzpFvrWv4rQvXscCv_xw2jZ13-GAk=.73f66862-88aa-4eba-bbe7-fc95e54566af@github.com>
References: <nntgIawtEjj5eQGzpFvrWv4rQvXscCv_xw2jZ13-GAk=.73f66862-88aa-4eba-bbe7-fc95e54566af@github.com>
Message-ID: <ieduuTfEQRcHa5DKaoeoencTqBt9d5TK-qbwK5YZd-0=.c3ffcbc3-92db-4fd6-a61f-5dd0c0d90fc9@github.com>

On Thu, 21 Apr 2022 13:24:15 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Those tests were failing on Solaris, which is no longer supported.
> 
> They pass as they are, but decreasing of delays reduce execution time significantly:
> 
> e.g. proposed changes drops execution time from ~5min to ~2 min 
> for MouseButtonsAndKeyMasksTest on my machine.
> 
> Testing is green on all platforms.

This pull request has now been integrated.

Changeset: 293bc5e5
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/293bc5e5cdef4590106de81473cc8b2d2793987a
Stats:     44 lines in 4 files changed: 22 ins; 6 del; 16 mod

8129778: Few awt test fail for Solaris 11 with RuntimeException

Reviewed-by: serb, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/8339


From smandalika at openjdk.java.net  Mon Apr 25 11:36:28 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Mon, 25 Apr 2022 11:36:28 GMT
Subject: RFR: 8282857: Create a regression test for JDK-4702690 [v3]
In-Reply-To: <1MCuz4h2_IMc9oR2q-DP_O5xoiS_7j1cQ8DTHaQxDlU=.a5b07c51-39fa-4c39-aa2d-74643c22cf0f@github.com>
References: <jklfp2oMIJWjzE4tz62KCLHfBqlaV0GlyZqk-wUiFHI=.7a721efc-e549-4058-819e-2785e64d9e8d@github.com>
 <1MCuz4h2_IMc9oR2q-DP_O5xoiS_7j1cQ8DTHaQxDlU=.a5b07c51-39fa-4c39-aa2d-74643c22cf0f@github.com>
Message-ID: <Ay6L_GuthMHrRalFUFG4z29EbnspDdxFJFifo33lezw=.a12d866f-b69e-4cc9-9dea-207347cc6bf1@github.com>

On Wed, 6 Apr 2022 07:02:25 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a regression test for [JDK-4702690](https://bugs.openjdk.java.net/browse/JDK-4702690)
>> 
>> In many cases in Swing it is possible to easily programatically determine that a JScrollBar (or two) is scrolling some JPanel (the cannonical case is a JScrollPane).
>> In these cases, when accessibility support is instantiated (e.g. the AccessibleJScrollBar is created), a Controller_For and Controled_By relation should be instantiated between the AccessibleJScrollBar and the AccessibleJPanel that the JScrollBar and JPanel are associated with.
>> 
>> This allows various assistive technologies, especially voice-recognition technologies, to better interact with scrolling items.
>> 
>> The test put up validates that the target object for these properties(CONTROLLED_BY, CONTROLLED_FOR) are set appropriately for JScrollPane and JScrollBar.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review Comments Fixed: Swing Components on EDT, 80 chars lines
>  - Review Comments Fixed: Swing Components on EDT, 80 chars lines

@mrserb  can you please review the changes after incorporating the earlier feedback ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7753


From smandalika at openjdk.java.net  Mon Apr 25 11:36:42 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Mon, 25 Apr 2022 11:36:42 GMT
Subject: RFR: JDK-8282778: Create a regression test for JDK-4699544 [v4]
In-Reply-To: <l1DQwU-SiN176RvD-bai-VoOdZNrM-66Kzo05YqXg3c=.f02b6d75-6024-402e-86d1-f77904fa90c5@github.com>
References: <IDgBuK7aFq5DBF_2mWS-l27LMVG9XSZe-2Zl_bITg3M=.527d9ca4-e081-4ce2-b123-1f2580f5e017@github.com>
 <l1DQwU-SiN176RvD-bai-VoOdZNrM-66Kzo05YqXg3c=.f02b6d75-6024-402e-86d1-f77904fa90c5@github.com>
Message-ID: <G695XhTnmKvLMkL2oavcdIN0QRWfCA3NTxN7xkSMXNA=.97ca6700-0168-4f7c-b461-d712b8a36927@github.com>

On Tue, 12 Apr 2022 09:05:56 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a regression test for JDK-4699544
>> 
>> The subclass of javax.swing.JRootPane (AccessibleJRootPane) that implements the accessibility interface javax.accessibility.AccessibleComponent is derived from java.awt.AccessibleAWTComponent, which returns null for getAccessibleAt() because a component does not necessarily have childs.
>> 
>> The root pane always has a content pane child, so getAccessibleAt() should be overwritten by AccessibleJRootPane appropriately.
>> The test added verifies the same.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comments Fixed: removed redundant class variables

@mrserb  can you please review the changes after incorporating the earlier feedback ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7739


From smandalika at openjdk.java.net  Mon Apr 25 11:37:31 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Mon, 25 Apr 2022 11:37:31 GMT
Subject: RFR: JDK-8282933: Create a test for JDK-4529616 [v4]
In-Reply-To: <H2pSp3zG5j_dE6MBWYMTfLlKdBxJBhlaq3rmlwptvdY=.5f6096c0-efd9-465f-b69a-0de8dc6333d8@github.com>
References: <3d_szd4R6oyDqof-g7sLsV_wkAzuEuma-aXiiUZ03Zw=.6579f560-f11e-4bea-a292-dfcee111a246@github.com>
 <H2pSp3zG5j_dE6MBWYMTfLlKdBxJBhlaq3rmlwptvdY=.5f6096c0-efd9-465f-b69a-0de8dc6333d8@github.com>
Message-ID: <fwLUbQeqdiOTWg5O5o-By_5lE8VeUrbsz1z-9AFVJ0Y=.8e04db33-267d-44ca-accf-0370addee095@github.com>

On Thu, 7 Apr 2022 07:02:18 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> JDK-8282933: Create a test for JDK-4529616 
>> AccessibleJTableCell.isShowing() returns false when the cell is actually on
>> the screen.
>> The test validates the fix for the above issue by verifying that the isShowing call returns true when invoked via the  accessiblity context.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282933: Whitespace issue fixed

Hi! Can someone please take a look at PR and provide their valuable feedback ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7783


From smandalika at openjdk.java.net  Mon Apr 25 11:39:30 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Mon, 25 Apr 2022 11:39:30 GMT
Subject: RFR: JDK-8282777: Create a Regression test for JDK-4515031 [v3]
In-Reply-To: <dQC9zgpn-bZxlGt1-tES09zUq849yPRfM_BcCW7zrqg=.ae67997b-49dc-4b67-a90c-bf7e4d0592c8@github.com>
References: <D8K1EcGCjhQQzplHsgYncKPvGmSPhrAs7RNDIl_pQlo=.e8d60f67-9cf4-4ac7-957b-ddbecffc85de@github.com>
 <dQC9zgpn-bZxlGt1-tES09zUq849yPRfM_BcCW7zrqg=.ae67997b-49dc-4b67-a90c-bf7e4d0592c8@github.com>
Message-ID: <Ui2_W8_PwvH2ALDZudVPlKVq_I05BH5YUtB5CCKd0aQ=.0e233005-9048-4633-b0b6-6e567047aad4@github.com>

On Wed, 30 Mar 2022 10:05:22 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a Regression test for [JDK-4515031](https://bugs.openjdk.java.net/browse/JDK-4515031)
>> 
>> The issue indicates the need for a a getAccessibleDescription being implemented for the JFileChooser.
>> The test added verifies the same.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comments Fixed: Button on EDT, split long lines, volatile description string

@mrserb can you please review the changes after incorporating the earlier feedback ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7738


From smandalika at openjdk.java.net  Mon Apr 25 11:40:30 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Mon, 25 Apr 2022 11:40:30 GMT
Subject: RFR: 8284077: Create an automated test for JDK-4170173 [v2]
In-Reply-To: <Ae-7tZG1zyizB1FXzbtqkgOsw2gJ5Y0ShLNFHCUu4hE=.578127b3-ef9d-4936-8338-14bf12b28e59@github.com>
References: <8iul_waSMDD6G1oVVmwPtW89ihAc6YoMFrTR1-XFmmw=.7802104e-60cb-4b90-9ef5-cc479d3f5a78@github.com>
 <Ae-7tZG1zyizB1FXzbtqkgOsw2gJ5Y0ShLNFHCUu4hE=.578127b3-ef9d-4936-8338-14bf12b28e59@github.com>
Message-ID: <QHvXv6VbFcB_jOLtrmkCop1wUAEAX6xXHANSNx0LgDU=.642e2d59-a879-49b4-87ad-efc9071dbdbd@github.com>

On Tue, 12 Apr 2022 06:09:35 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4170173](https://bugs.openjdk.java.net/browse/JDK-4170173)
>> 
>> Issue
>> JTextComponent.AccessibleJTextComponent.getAfterIndex(int part, int index) works incorrectly, when 'part' parameter is AccessibleText.WORD.
>> It returns a space (" ") instead of the correct word.
>> 
>> The test verifies the fix for this behavior by checking the getAfterIndex for AccessibleText.CHARACTER,AccessibleText.WORD,AccessibleText.SENTENCE for the components JTextField, JTextArea, JEditorPane.
>> 
>> While working on this test case there was a related bug relevant to this [JDK-4170174](https://bugs.openjdk.java.net/browse/JDK-4170174) 
>> This is marked as duplicate, addressess a similar issue.
>> It indicates that JTextComponent.AccessibleJTextComponent.getBeforeIndex(int part, int index) works incorrectly, when part parameter is AccessibleText.WORD.
>> It returns a space (" ") instead of correct word.
>> 
>> Hence an additional test was added for this, for verifying the behavior of getBeforeIndex.
>> AccessibleText.CHARACTER,AccessibleText.WORD,AccessibleText.SENTENCE for the components JTextField, JTextArea, JEditorPane.
>> 
>> The two tests have multiple distinct assertions. For this reason, as well as for maintainability, the two were not clubbed into a single test.
>> However, the two tests are still similar in the functional flow of the code and the functionality they are testing as well - hence they have been clubbed into a single review.
>> This review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The tests ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comments Fixed: Simplied test

@mrserb can you please review the changes after I have incorporated the earlier feedback ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8138


From smandalika at openjdk.java.net  Mon Apr 25 11:41:25 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Mon, 25 Apr 2022 11:41:25 GMT
Subject: RFR: 8284524: Create an automated test for JDK-4422362 [v2]
In-Reply-To: <WHzkHjbiB5VBQQILCYjGhTUlQ5r4cCdKLuhHIej_b8k=.38b70b08-9720-4768-8cb1-f1eee3bc59ea@github.com>
References: <Zc6TLIeUCxotLqICjVkZF4g1hUTkdB7mANhMull6Qzc=.14959182-424c-42f6-979f-7d6eeb266dfb@github.com>
 <WHzkHjbiB5VBQQILCYjGhTUlQ5r4cCdKLuhHIej_b8k=.38b70b08-9720-4768-8cb1-f1eee3bc59ea@github.com>
Message-ID: <Q8m5NM0nLoZWuetsYtMSDJ05pNr5dm_jKh44CWJ1WVk=.4aa74d42-b87c-49d8-bfad-679f3b90c3eb@github.com>

On Tue, 12 Apr 2022 09:19:33 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4422362](https://bugs.openjdk.java.net/browse/JDK-4422362)
>> 
>> The BoundedRangeModel components (JScrollBar, JSlider, JProgressBar) return
>> BoundedRangeModel.getMaximum() from getMaximumAccessibleValue() in their
>> AccessibleValue implementation.
>> The real maximum value (due to the constraints on BoundedRangeModel) is
>> model.getMaximum() - model.getExtent().
>> 
>> The test verifies that the above is adhered to as expected.
>> 
>> This review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284524: Create an automated test for JDK-4422362

Hi! Can someone please take a look at this PR and provide their valuable feedback ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8158


From smandalika at openjdk.java.net  Mon Apr 25 13:25:38 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Mon, 25 Apr 2022 13:25:38 GMT
Subject: RFR: 8285373: Create an automated test for JDK-4702233
In-Reply-To: <zrkWQo-BoTq0XlQX_0_-CwnPIKkCge6wW8E5EqLAYRs=.2345ef0a-25eb-414c-ade6-de10d49d2bbe@github.com>
References: <zrkWQo-BoTq0XlQX_0_-CwnPIKkCge6wW8E5EqLAYRs=.2345ef0a-25eb-414c-ade6-de10d49d2bbe@github.com>
Message-ID: <ntPgtjrojaWL5nt4rJJbAqPJYfNWFBnxTZAxVG-lOm8=.2b575273-49e1-408b-8833-aecfebfbfef5@github.com>

On Thu, 21 Apr 2022 15:54:02 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Create an automated test for [JDK-4702233](https://bugs.openjdk.java.net/browse/JDK-4702233)
> 
> Several new AccessibleRole and AccessibleRelation constants are needed in those classes in the java.accessibility package. These new contants codify additions made in the GNOME, Netscape, and UNO (StarOffice) accessibility APIs.
> StarOffice 6.1 and GNOME accessibility require new role, state and relation
> constants in the javax.accessibility package. The existing constants are
> inadequate for providing accessibility to StarOffice and GNOME applications
> as required by Section 508.
> 
> Solution
> --------
> Define new constants in the javax.accessibility package.
> AccessibleRelation
> AccessibleRoles
> AccessibleState
> AccessibleAction
> AccessibleContext
> 
> The test validates the public fields of the above AccessibleConstants.
> 
> This review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

Hi! Can someone please take a look at this PR and provide their valuable feedback ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8342


From smandalika at openjdk.java.net  Mon Apr 25 13:27:49 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Mon, 25 Apr 2022 13:27:49 GMT
Subject: RFR: 8285305: Create an automated test for JDK-4495286
In-Reply-To: <tfMcUiiqM3zbwahwkdBXMSFXcHiCqyZoRJLZgekkagQ=.5392b0b4-bd49-400a-8bf0-aef5f1354d6e@github.com>
References: <tfMcUiiqM3zbwahwkdBXMSFXcHiCqyZoRJLZgekkagQ=.5392b0b4-bd49-400a-8bf0-aef5f1354d6e@github.com>
Message-ID: <5fEx9Yh6mRMaadW78bDMKsYC_KUNkkaT3ofjV3fSFF8=.4d084c28-d8f6-4939-a23d-7e73fe163e5c@github.com>

On Thu, 21 Apr 2022 10:51:18 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Create an automated test for [JDK-4495286](https://bugs.openjdk.java.net/browse/JDK-4495286)
> 
> AccessibleJTable.setAccessibleSelction should select rows/cols when cell selection.
> When cell selection is not enabled, there is no way, using
> accessibility, to select rows or columns. It seems logical that selecting a cell
> using accessibility should have the same effect as clicking on a cell with the
> mouse. That is, if row or column selection is enabled, then selecting a cell
> should instead cause the row or column to be selected.
>  The proposed test verifies that the above behavior is fixed.
> 
> This review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The test ran successfully on Mach5 with multiple runs (40) on windows-x64, linux-x64 and macos-x64.

Hi! Can someone please take a look at this PR and provide their valuable feedback ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8333


From achung at openjdk.java.net  Mon Apr 25 16:10:36 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 25 Apr 2022 16:10:36 GMT
Subject: RFR: 8198666: Many java/awt/Modal/OnTop/ test fails on mac
In-Reply-To: <N4gaazOwBJPl-soN1a8chVdup4YqVMNHhmNPWpSybtw=.e6d1eb0e-9ede-40df-acd5-d7f45a371ee4@github.com>
References: <N4gaazOwBJPl-soN1a8chVdup4YqVMNHhmNPWpSybtw=.e6d1eb0e-9ede-40df-acd5-d7f45a371ee4@github.com>
Message-ID: <zIxNY6hAVOZj-YaxfdIdjlcIKMV9o09qV6is0iUYXrs=.cec54dc0-34e0-4ef6-948d-80ddd0d7d2ac@github.com>

On Fri, 22 Apr 2022 17:38:28 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Removed passing tests from problem list

Tests were run 100 times and passed

-------------

PR: https://git.openjdk.java.net/jdk/pull/8368


From duke at openjdk.java.net  Mon Apr 25 16:46:28 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Mon, 25 Apr 2022 16:46:28 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v7]
In-Reply-To: <ELLNwhbSpCFrd0UOUDfh7RnGBCY8TNF9R4DLHg9ciH4=.d8b502ac-7eb4-432c-8283-638c5223e55f@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
 <ELLNwhbSpCFrd0UOUDfh7RnGBCY8TNF9R4DLHg9ciH4=.d8b502ac-7eb4-432c-8283-638c5223e55f@github.com>
Message-ID: <fOYknyfTJSubabSPD7Zevw9jJNs0whCjmadF9yu7bOY=.08abd8ba-4536-49be-8d85-3a8d05764e36@github.com>

On Fri, 22 Apr 2022 16:44:07 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> The exisiting manual test case tests different html styles of JTabbedPane tab title. The tab with "big" as title is seen to be clipped on Aqua LAF for larger font-size. In other LAFs it is observed that bigger font-size can be accommodated without clipping.
>> 
>> The following approaches were evaluated before considering it as not a test issue -
>> 
>> - Aqua LAF has a different tab style compared to other LAFs as seen in the screenshot below. Limiting font size on Aqua LAF requires scaling down the text which might be incompatible with Aqua LAF.
>> 
>> - Removing existing constraints on text and icon is incompatible for Aqua LAF.
>> 
>> Since the above two approaches are incompatible with Aqua and it is not a test issue, a note has been added about clipped text and this test has been removed from problem list
>> 
>> ![image](https://user-images.githubusercontent.com/95945681/164093604-ca7ecbc3-09c2-4338-bd2a-f8c81c12f360.png)
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   formatted test instructions

PR requires a second reviewer approval

-------------

PR: https://git.openjdk.java.net/jdk/pull/8307


From duke at openjdk.java.net  Mon Apr 25 16:50:28 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Mon, 25 Apr 2022 16:50:28 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v8]
In-Reply-To: <5VA647IOBnDIdo8c2iI3eonRjOA-udrPOEoBqqpVBQ8=.92d2beb7-c8b6-4d96-b120-723d34c0c356@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <afJ29wQf2smgANBt5YTQC4oODoch8zxa0YqdtUZDfW8=.f4d0de4d-5245-4491-a8e8-05aaf2a4797a@github.com>
 <5VA647IOBnDIdo8c2iI3eonRjOA-udrPOEoBqqpVBQ8=.92d2beb7-c8b6-4d96-b120-723d34c0c356@github.com>
Message-ID: <ufljMm7YKtJW2H7sT-10IMhrXGgR__5vAdyHiPrBZOE=.1c10f3e1-0430-411f-80de-c498eccd22e6@github.com>

On Tue, 5 Apr 2022 05:48:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Need more change

@prsadhuk Suggested changes have been incorporated. Needs to be re-reviewed. 
PR requires second reviewer

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From serb at openjdk.java.net  Mon Apr 25 17:16:25 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 25 Apr 2022 17:16:25 GMT
Subject: RFR: 8284888 : [macos]
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with
 "NimbusLookAndFeel] : ERROR: icon and imageIcon not same."
In-Reply-To: <pfa7K1bO4jVy0R3GkJTdMJG5eYhcdgojfPL_pILKlOA=.c2789888-0055-47a7-9c95-19f5d0cf3be0@github.com>
References: <pfa7K1bO4jVy0R3GkJTdMJG5eYhcdgojfPL_pILKlOA=.c2789888-0055-47a7-9c95-19f5d0cf3be0@github.com>
Message-ID: <pVCxp6isoaxt_-eoYl_PvVn2oN0CML8AFX_Brbv1nuA=.bcdc033e-3fc1-4619-88ec-943c2792790b@github.com>

On Mon, 25 Apr 2022 09:37:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test used to fail in specific CI macos M1 system owing to miniscule color difference 
> 
> 
> x 0 y 0 red1 171 red2 171 green1 174 green2 175 blue1 184 blue2 184
> x 0 y 1 red1 172 red2 173 green1 177 green2 177 blue1 185 blue2 185
> x 0 y 2 red1 173 red2 174 green1 177 green2 178 blue1 187 blue2 187
> x 0 y 6 red1 0 red2 0 green1 1 green2 0 blue1 0 blue2 0
> x 0 y 15 red1 1 red2 0 green1 0 green2 0 blue1 0 blue2 0
> 
> 
> SInce we already have color-tolerance check present, there is no need of exact color value check.
> Also, made the frame undecorated and remove unneeded library being built. 
> Several iterations of the test passed in the same system (where it used to fail 4/10) along with other platforms (link in JBS)

The JDK-8284888 bug is not public, cannot see a bug description.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8380


From achung at openjdk.java.net  Mon Apr 25 17:24:23 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 25 Apr 2022 17:24:23 GMT
Subject: RFR: 7080150: [TEST_BUG][macosx] No mac os x EmbeddedFrame support
 in regression regtesthelpers [v2]
In-Reply-To: <gFlM0AY12mdaZOxwWoEQ18f6ftWlVO5-sIEzLZ-g99g=.8f0acf8c-d5c4-4381-8fbf-595a3759f77f@github.com>
References: <abWDTHr4uorNjVddaR6Ai-ZOn_5XNpg__RO5PSi4z-o=.01f596f9-c7c8-4ccc-8dba-84f28eca25c2@github.com>
 <YN2s_fyZJZsnMmSemoNnlt356YNhw-6YQO8qNPB3RBw=.71f188ab-a1e6-4cef-80ec-c0b61e5e6b31@github.com>
 <wb06X6ii7k1iM3dN5IIyBJtz_wIdj9Ksd1crlxQZTeI=.44583be9-2b68-43ab-9071-52776edacaf0@github.com>
 <6ZgUTjzqY7BMiXBOVBgNe0eDs-cRoH6AaHf3xv_fV9Q=.c2db1051-7791-49db-9cfd-fd730aa67b90@github.com>
 <gFlM0AY12mdaZOxwWoEQ18f6ftWlVO5-sIEzLZ-g99g=.8f0acf8c-d5c4-4381-8fbf-595a3759f77f@github.com>
Message-ID: <l6nSMLad89tD5o-k4jem-uIGBJA4_3t8B09W18tdx3s=.5b58283b-b512-4aef-96b9-b8e80a2a9279@github.com>

On Fri, 22 Apr 2022 22:30:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> CEmbeddedFrame doesn't have a way to pass in a handle like in WEmbeddedFrame and XEmbeddedFrame, so I can't pass in the peer's target. If I try to use CEmbeddedFrame the test window will pop up but the EmbeddedFrame won't show up and the test fails
>
> Are you sure that CEmbeddedFrame is used in the embedding functionality? We have another one on macOS CViewEmbeddedFrame. One of them was used for applets another one was used by the JAWT and SWT. Please double-check that the correct one is used for this test, and another one probably can be removed.

I see that windows and linux have a long value that identifies the window that gets pass into the constructor of the EmbeddedFrame class object. Is there an equivalent in macOS? I see that CViewEmbeddedFrame has the nsViewPtr that is equivalent, but I don't see any way to find that value from LWComponentPeer.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8348


From prr at openjdk.java.net  Mon Apr 25 19:26:29 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 25 Apr 2022 19:26:29 GMT
Subject: RFR: JDK-8202790: DnD test DisposeFrameOnDragTest.java does not
 clean up
In-Reply-To: <QdsX-pN6mlmPluFzEBtyEHd0xBqbqH2wfR58jxC4BHg=.e606e5c6-ead4-49e9-98e2-97fb0fcf045c@github.com>
References: <QdsX-pN6mlmPluFzEBtyEHd0xBqbqH2wfR58jxC4BHg=.e606e5c6-ead4-49e9-98e2-97fb0fcf045c@github.com>
Message-ID: <t-ZEI8tI2e3K9JyLkI9Ddju1HzlsRFVxPTsYEbH96VQ=.eac48320-63aa-47ee-9d36-2bf941b8f9c5@github.com>

On Fri, 22 Apr 2022 19:41:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Added a background to the test to prevent the file from dragging onto the desktop and creating an extra file.

InputEvent.BUTTON1_MASK);

could be BUTTON1_DOWN_MASK since you are touching this already.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8370


From serb at openjdk.java.net  Mon Apr 25 19:49:26 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 25 Apr 2022 19:49:26 GMT
Subject: RFR: 8284888 : [macos]
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with
 "NimbusLookAndFeel] : ERROR: icon and imageIcon not same."
In-Reply-To: <pfa7K1bO4jVy0R3GkJTdMJG5eYhcdgojfPL_pILKlOA=.c2789888-0055-47a7-9c95-19f5d0cf3be0@github.com>
References: <pfa7K1bO4jVy0R3GkJTdMJG5eYhcdgojfPL_pILKlOA=.c2789888-0055-47a7-9c95-19f5d0cf3be0@github.com>
Message-ID: <rOXq0Qh4aY03S6zkaM7cRpBQlWTCjbJM2Z8O1nhtJn8=.95141015-509b-42b1-9560-e3a09f6d1548@github.com>

On Mon, 25 Apr 2022 09:37:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test used to fail in specific CI macos M1 system owing to miniscule color difference 
> 
> 
> x 0 y 0 red1 171 red2 171 green1 174 green2 175 blue1 184 blue2 184
> x 0 y 1 red1 172 red2 173 green1 177 green2 177 blue1 185 blue2 185
> x 0 y 2 red1 173 red2 174 green1 177 green2 178 blue1 187 blue2 187
> x 0 y 6 red1 0 red2 0 green1 1 green2 0 blue1 0 blue2 0
> x 0 y 15 red1 1 red2 0 green1 0 green2 0 blue1 0 blue2 0
> 
> 
> SInce we already have color-tolerance check present, there is no need of exact color value check.
> Also, made the frame undecorated and remove unneeded library being built. 
> Several iterations of the test passed in the same system (where it used to fail 4/10) along with other platforms (link in JBS)

BTW did you have a chance to check why to images are not the same? Is it a problem in the robot or in the rendering? Can it be related to upscaling/downscaling?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8380


From serb at openjdk.java.net  Mon Apr 25 19:49:45 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 25 Apr 2022 19:49:45 GMT
Subject: RFR: 8198666: Many java/awt/Modal/OnTop/ test fails on mac
In-Reply-To: <N4gaazOwBJPl-soN1a8chVdup4YqVMNHhmNPWpSybtw=.e6d1eb0e-9ede-40df-acd5-d7f45a371ee4@github.com>
References: <N4gaazOwBJPl-soN1a8chVdup4YqVMNHhmNPWpSybtw=.e6d1eb0e-9ede-40df-acd5-d7f45a371ee4@github.com>
Message-ID: <zghYr5jPNPyPQHGi0_tG3P8_7qA-L43D_lZC7WxgNIU=.6740238d-bce6-4981-bbf1-7f40fa1a33f0@github.com>

On Fri, 22 Apr 2022 17:38:28 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Removed passing tests from problem list

Good to know that these tests become stable.

-------------

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8368


From achung at openjdk.java.net  Mon Apr 25 21:46:27 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 25 Apr 2022 21:46:27 GMT
Subject: RFR: JDK-8202790: DnD test DisposeFrameOnDragTest.java does not
 clean up [v2]
In-Reply-To: <QdsX-pN6mlmPluFzEBtyEHd0xBqbqH2wfR58jxC4BHg=.e606e5c6-ead4-49e9-98e2-97fb0fcf045c@github.com>
References: <QdsX-pN6mlmPluFzEBtyEHd0xBqbqH2wfR58jxC4BHg=.e606e5c6-ead4-49e9-98e2-97fb0fcf045c@github.com>
Message-ID: <Epij-uCRSPH5jkGjEJL3ZxpMN6081DO9yLrX5hM3WPo=.225d15a1-8d92-4c57-9e18-9b62cf4f4933@github.com>

> Added a background to the test to prevent the file from dragging onto the desktop and creating an extra file.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  changed button mask to button down mask

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8370/files
  - new: https://git.openjdk.java.net/jdk/pull/8370/files/e9dace84..795d2a2d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8370&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8370&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8370.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8370/head:pull/8370

PR: https://git.openjdk.java.net/jdk/pull/8370


From kizune at openjdk.java.net  Mon Apr 25 21:54:27 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 25 Apr 2022 21:54:27 GMT
Subject: RFR: JDK-8202790: DnD test DisposeFrameOnDragTest.java does not
 clean up [v2]
In-Reply-To: <Epij-uCRSPH5jkGjEJL3ZxpMN6081DO9yLrX5hM3WPo=.225d15a1-8d92-4c57-9e18-9b62cf4f4933@github.com>
References: <QdsX-pN6mlmPluFzEBtyEHd0xBqbqH2wfR58jxC4BHg=.e606e5c6-ead4-49e9-98e2-97fb0fcf045c@github.com>
 <Epij-uCRSPH5jkGjEJL3ZxpMN6081DO9yLrX5hM3WPo=.225d15a1-8d92-4c57-9e18-9b62cf4f4933@github.com>
Message-ID: <QIg4uJF0CWXt8hhvMkrcOpnScucHZ3jW7hFSm19AWMo=.4be7ad44-34cb-4a3f-ba55-049c2746e721@github.com>

On Mon, 25 Apr 2022 21:46:27 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Added a background to the test to prevent the file from dragging onto the desktop and creating an extra file.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed button mask to button down mask

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8370


From kizune at openjdk.java.net  Mon Apr 25 21:57:03 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 25 Apr 2022 21:57:03 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v7]
In-Reply-To: <ELLNwhbSpCFrd0UOUDfh7RnGBCY8TNF9R4DLHg9ciH4=.d8b502ac-7eb4-432c-8283-638c5223e55f@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
 <ELLNwhbSpCFrd0UOUDfh7RnGBCY8TNF9R4DLHg9ciH4=.d8b502ac-7eb4-432c-8283-638c5223e55f@github.com>
Message-ID: <4i0T8PjQa_xsdd_CcbuV26ukematijv0mjh1UYwwIQA=.497dab04-f5f4-4c1f-a409-132a08c99e56@github.com>

On Fri, 22 Apr 2022 16:44:07 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> The exisiting manual test case tests different html styles of JTabbedPane tab title. The tab with "big" as title is seen to be clipped on Aqua LAF for larger font-size. In other LAFs it is observed that bigger font-size can be accommodated without clipping.
>> 
>> The following approaches were evaluated before considering it as not a test issue -
>> 
>> - Aqua LAF has a different tab style compared to other LAFs as seen in the screenshot below. Limiting font size on Aqua LAF requires scaling down the text which might be incompatible with Aqua LAF.
>> 
>> - Removing existing constraints on text and icon is incompatible for Aqua LAF.
>> 
>> Since the above two approaches are incompatible with Aqua and it is not a test issue, a note has been added about clipped text and this test has been removed from problem list
>> 
>> ![image](https://user-images.githubusercontent.com/95945681/164093604-ca7ecbc3-09c2-4338-bd2a-f8c81c12f360.png)
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   formatted test instructions

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8307


From duke at openjdk.java.net  Mon Apr 25 22:31:49 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Mon, 25 Apr 2022 22:31:49 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v7]
In-Reply-To: <zwnj1_oWbP5E1Ubhjk4UgTH0r68aY0BeZZDg6BrUV2s=.2b4ffd55-d773-49eb-a837-6f1f9bacbb7e@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
 <ELLNwhbSpCFrd0UOUDfh7RnGBCY8TNF9R4DLHg9ciH4=.d8b502ac-7eb4-432c-8283-638c5223e55f@github.com>
 <zwnj1_oWbP5E1Ubhjk4UgTH0r68aY0BeZZDg6BrUV2s=.2b4ffd55-d773-49eb-a837-6f1f9bacbb7e@github.com>
Message-ID: <LoXsd6NSXHenWWef7VjkJ_f0R2DvWU9g98wLBInUvDU=.5ebeec64-5533-4193-bad1-7b9019ee2e03@github.com>

On Fri, 22 Apr 2022 23:15:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   formatted test instructions
>
> Probably we should think about care of the big font in the aqua L&F and decrease the size we know it is too big?

@mrserb  I have added a new issue ([JDK-8285615](https://bugs.openjdk.java.net/browse/JDK-8285615)) to keep track and handle big fonts for Aqua LAF as a separate issue from the test issue. I wanted to check if you wanted to add anything more to this PR or the newly created issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8307


From duke at openjdk.java.net  Mon Apr 25 22:43:13 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Mon, 25 Apr 2022 22:43:13 GMT
Subject: RFR: 8285612 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
Message-ID: <FjDS9wBgC4UrrnUaCoI-5tyAVVmg3FDQoNbPgij8rQI=.a18da791-1675-46dd-9ec8-cbd5f4f8a092@github.com>

1) Removed yesno to eliminate parserException
2) Added code to fit into manual framework so that timeout, pass & fail is handled.
3) Added code to mark the test as pass if printer service is not available
4) Added code to handle pressing or clicking of 'Cancel' button.

@shurymury 
@aivanov-jdk

-------------

Commit messages:
 - 8285612 : Remove jtreg tag manual=yesno for java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java

Changes: https://git.openjdk.java.net/jdk/pull/8391/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8391&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285612
  Stats: 160 lines in 1 file changed: 66 ins; 50 del; 44 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8391.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8391/head:pull/8391

PR: https://git.openjdk.java.net/jdk/pull/8391


From prr at openjdk.java.net  Mon Apr 25 23:02:54 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 25 Apr 2022 23:02:54 GMT
Subject: RFR: JDK-8202790: DnD test DisposeFrameOnDragTest.java does not
 clean up [v2]
In-Reply-To: <Epij-uCRSPH5jkGjEJL3ZxpMN6081DO9yLrX5hM3WPo=.225d15a1-8d92-4c57-9e18-9b62cf4f4933@github.com>
References: <QdsX-pN6mlmPluFzEBtyEHd0xBqbqH2wfR58jxC4BHg=.e606e5c6-ead4-49e9-98e2-97fb0fcf045c@github.com>
 <Epij-uCRSPH5jkGjEJL3ZxpMN6081DO9yLrX5hM3WPo=.225d15a1-8d92-4c57-9e18-9b62cf4f4933@github.com>
Message-ID: <28HU4vrRBnDRzQLQN7czzkP8cNy21PeejLWQhA1_HZI=.545d71ad-4d5d-41e2-8ffd-c406435eb614@github.com>

On Mon, 25 Apr 2022 21:46:27 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Added a background to the test to prevent the file from dragging onto the desktop and creating an extra file.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed button mask to button down mask

Marked as reviewed by prr (Reviewer).

It looks OK. Would be nice to have a comment explaining that you are trying to prevent drop on to the desktop
which might accept this dragged text.
In fact you should explain this in the bug report eval too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8370


From serb at openjdk.java.net  Mon Apr 25 23:06:54 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 25 Apr 2022 23:06:54 GMT
Subject: RFR: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane [v7]
In-Reply-To: <ELLNwhbSpCFrd0UOUDfh7RnGBCY8TNF9R4DLHg9ciH4=.d8b502ac-7eb4-432c-8283-638c5223e55f@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
 <ELLNwhbSpCFrd0UOUDfh7RnGBCY8TNF9R4DLHg9ciH4=.d8b502ac-7eb4-432c-8283-638c5223e55f@github.com>
Message-ID: <9rr0MSXnGerpXmpnQtEuciG14u9eG-hyTzU-6zY-k4o=.65d08265-91f8-4626-a7bc-b15de5f00526@github.com>

On Fri, 22 Apr 2022 16:44:07 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> The exisiting manual test case tests different html styles of JTabbedPane tab title. The tab with "big" as title is seen to be clipped on Aqua LAF for larger font-size. In other LAFs it is observed that bigger font-size can be accommodated without clipping.
>> 
>> The following approaches were evaluated before considering it as not a test issue -
>> 
>> - Aqua LAF has a different tab style compared to other LAFs as seen in the screenshot below. Limiting font size on Aqua LAF requires scaling down the text which might be incompatible with Aqua LAF.
>> 
>> - Removing existing constraints on text and icon is incompatible for Aqua LAF.
>> 
>> Since the above two approaches are incompatible with Aqua and it is not a test issue, a note has been added about clipped text and this test has been removed from problem list
>> 
>> ![image](https://user-images.githubusercontent.com/95945681/164093604-ca7ecbc3-09c2-4338-bd2a-f8c81c12f360.png)
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   formatted test instructions

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8307


From prr at openjdk.java.net  Mon Apr 25 23:48:51 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 25 Apr 2022 23:48:51 GMT
Subject: RFR: JDK-8202790: DnD test DisposeFrameOnDragTest.java does not
 clean up [v2]
In-Reply-To: <Epij-uCRSPH5jkGjEJL3ZxpMN6081DO9yLrX5hM3WPo=.225d15a1-8d92-4c57-9e18-9b62cf4f4933@github.com>
References: <QdsX-pN6mlmPluFzEBtyEHd0xBqbqH2wfR58jxC4BHg=.e606e5c6-ead4-49e9-98e2-97fb0fcf045c@github.com>
 <Epij-uCRSPH5jkGjEJL3ZxpMN6081DO9yLrX5hM3WPo=.225d15a1-8d92-4c57-9e18-9b62cf4f4933@github.com>
Message-ID: <AUC3Ckdwhr8OYCPf22Oef54b5Tu3EFltO_hsjF6I3Ag=.265cad9b-2ad7-4d3e-b496-814c87f08233@github.com>

On Mon, 25 Apr 2022 21:46:27 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Added a background to the test to prevent the file from dragging onto the desktop and creating an extra file.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed button mask to button down mask

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8370


From tnakamura at openjdk.java.net  Tue Apr 26 00:02:51 2022
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Tue, 26 Apr 2022 00:02:51 GMT
Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong
 size
In-Reply-To: <Y_2oKMsrT3TUVaZI7xUMo59febA0uYZPSNgNbqdEpvw=.b48a99ad-5aa8-4f18-9528-545fe624b0a2@github.com>
References: <z72T3X_wgR6K7BdFL7Tqg8t6GXbJh-Vk0pDGCJjUnEE=.ba87e570-fc0b-45d5-8099-9ffeeeb09fc5@github.com>
 <Y_2oKMsrT3TUVaZI7xUMo59febA0uYZPSNgNbqdEpvw=.b48a99ad-5aa8-4f18-9528-545fe624b0a2@github.com>
Message-ID: <Ixosca1Net5Xg_WPrTeGJkfWDgRhZt8WF7VMnWsjnDs=.11a59db9-e1ca-4028-a385-8fdcf729aa99@github.com>

On Fri, 22 Apr 2022 03:24:09 GMT, Phil Race <prr at openjdk.org> wrote:

>> Japanese logical fonts are drawn with wrong size since Java 18.
>> It's triggered by JEP 400, UTF-8 by Default. `sun.awt.FontConfiguration` (and `sun.awt.windows.WFontConfiguration`) seems to expect the native encoding instead of the default encoding. This patch changes to use native encoding.
>> 
>> Tested: jdk_desktop on Windows, Linux, and macOS
>
> Hmm. I am surprised that the glyphs are actually bigger. Did you come to understand the exact mechanism (steps)
> by which this triggers the wrong size ? Without that explanation it isn't apparent to me we've understood the problem
> even if this fixes it.
> 
> And whilst you tested linux & mac it is a shared code change so it is another reason to understand .. 
> 
> And are you sure you can't write a test ? Even something that uses heuristics around the metrics ?

Thank you for the comments, @prrace @naotoj 

The bigger fonts are caused by the behavior of RichEdit component. I was able to recreate the similar behavior with a native application. I attached the code and the screen shot to JBS. RichEdit seems to use fallback font if English font (Arial, for example) was set for Japanese text. It could show Japanese, but its size was not perfect. So, we need to set a proper font.

NG case (Java18): "Arial 9pt" with ANSI_CHARSET was used.
OK case (Java17): "MS Gothic 9pt" with SHIFTJIS_CHARSET was used.

> And whilst you tested linux & mac it is a shared code change so it is another reason to understand ..

OK, I moved the fix to Windows part. I need to change setEncoding method to protected, because "encoding" value was used in the constructor.

> And are you sure you can't write a test ? Even something that uses heuristics around the metrics ?

Sorry, I tried some ways, but I couldn't. It tightly binds with OS settings.

A pre-submit test was failed once, but passed after rerun.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8329


From duke at openjdk.java.net  Tue Apr 26 01:51:18 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Tue, 26 Apr 2022 01:51:18 GMT
Subject: RFR: 8285617 : Fix
 java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java manual test
Message-ID: <gJfXkDtoO4VBJIFH8Drdqj-YXGwKeGPmrIq8kzIT1Ug=.5267a947-1938-4cba-a3a3-45a43b6ae135@github.com>

1) Removed yesno since test was failing with parser error due to @run main/manual=yesno 
2) User can't decide whether it as pass or fail after looking into the printout so add the PassFailJFrame support

@shurymury 
@aivanov-jdk

-------------

Commit messages:
 - 8285617 : Fix java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java manual test

Changes: https://git.openjdk.java.net/jdk/pull/8395/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8395&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285617
  Stats: 49 lines in 1 file changed: 26 ins; 7 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8395.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8395/head:pull/8395

PR: https://git.openjdk.java.net/jdk/pull/8395


From psadhukhan at openjdk.java.net  Tue Apr 26 03:52:01 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 26 Apr 2022 03:52:01 GMT
Subject: RFR: 8284888 : [macos]
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with
 "NimbusLookAndFeel] : ERROR: icon and imageIcon not same."
In-Reply-To: <pfa7K1bO4jVy0R3GkJTdMJG5eYhcdgojfPL_pILKlOA=.c2789888-0055-47a7-9c95-19f5d0cf3be0@github.com>
References: <pfa7K1bO4jVy0R3GkJTdMJG5eYhcdgojfPL_pILKlOA=.c2789888-0055-47a7-9c95-19f5d0cf3be0@github.com>
Message-ID: <1OYwEG8b8QLK1qYmQ3DIAL6XwKN-Le4-1ceI2-hX2u4=.6df0b3d6-c07e-46a6-8ecb-99ac2b65e075@github.com>

On Mon, 25 Apr 2022 09:37:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test used to fail in specific CI macos M1 system owing to miniscule color difference 
> 
> 
> x 0 y 0 red1 171 red2 171 green1 174 green2 175 blue1 184 blue2 184
> x 0 y 1 red1 172 red2 173 green1 177 green2 177 blue1 185 blue2 185
> x 0 y 2 red1 173 red2 174 green1 177 green2 178 blue1 187 blue2 187
> x 0 y 6 red1 0 red2 0 green1 1 green2 0 blue1 0 blue2 0
> x 0 y 15 red1 1 red2 0 green1 0 green2 0 blue1 0 blue2 0
> 
> 
> SInce we already have color-tolerance check present, there is no need of exact color value check.
> Also, made the frame undecorated and remove unneeded library being built. 
> Several iterations of the test passed in the same system (where it used to fail 4/10) along with other platforms (link in JBS)

The bug is made public.
The images looks alike visually. I could not find anything wrong with rendering or robot which otherwise could have caused issue in other systems and platforms but it's only failing in this CI system (but color profile setting is ok). As per [JDK-8266247](https://bugs.openjdk.java.net/browse/JDK-8266247) which also happens in same mc, some faulty video memory is doubted.
Also, it's not happening everytime but intermittently so seeing all this, I have just relaxed color check a bit

-------------

PR: https://git.openjdk.java.net/jdk/pull/8380


From psadhukhan at openjdk.java.net  Tue Apr 26 04:01:04 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 26 Apr 2022 04:01:04 GMT
Subject: RFR: 8208565: [TEST_BUG]
 javax\swing\PopupFactory\6276087\NonOpaquePopupMenuTest.java throws NPE
In-Reply-To: <DmXd07y2BGuoEk_ocIftawU6FoCTUfzwmuaSxa9px2M=.018977f0-14c1-41f3-be46-a3d430b37773@github.com>
References: <DmXd07y2BGuoEk_ocIftawU6FoCTUfzwmuaSxa9px2M=.018977f0-14c1-41f3-be46-a3d430b37773@github.com>
Message-ID: <qovTgMXe6jD_IrblDhwPwzx6nrSR8yCV7M_K3v1EceY=.2812b2bc-d68f-402c-a8cd-f80ca5fe5edf@github.com>

On Mon, 18 Apr 2022 07:11:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing in the past owing to NPE while accessing JMenu probably owing to fact the test did not wait for UI to be visible before starting the test, so added a delay after the frame is made visible. Also, added disposal of frame.
> Also, it seems JDK-8213535 fix might be having a positive impact on this test.
> 
> Several iterations of this test in all platforms have passed (link in JBS).

Any reviewers?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8282


From psadhukhan at openjdk.java.net  Tue Apr 26 05:34:50 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 26 Apr 2022 05:34:50 GMT
Subject: RFR: 7080150: [TEST_BUG][macosx] No mac os x EmbeddedFrame support
 in regression regtesthelpers [v2]
In-Reply-To: <l6nSMLad89tD5o-k4jem-uIGBJA4_3t8B09W18tdx3s=.5b58283b-b512-4aef-96b9-b8e80a2a9279@github.com>
References: <abWDTHr4uorNjVddaR6Ai-ZOn_5XNpg__RO5PSi4z-o=.01f596f9-c7c8-4ccc-8dba-84f28eca25c2@github.com>
 <YN2s_fyZJZsnMmSemoNnlt356YNhw-6YQO8qNPB3RBw=.71f188ab-a1e6-4cef-80ec-c0b61e5e6b31@github.com>
 <wb06X6ii7k1iM3dN5IIyBJtz_wIdj9Ksd1crlxQZTeI=.44583be9-2b68-43ab-9071-52776edacaf0@github.com>
 <6ZgUTjzqY7BMiXBOVBgNe0eDs-cRoH6AaHf3xv_fV9Q=.c2db1051-7791-49db-9cfd-fd730aa67b90@github.com>
 <gFlM0AY12mdaZOxwWoEQ18f6ftWlVO5-sIEzLZ-g99g=.8f0acf8c-d5c4-4381-8fbf-595a3759f77f@github.com>
 <l6nSMLad89tD5o-k4jem-uIGBJA4_3t8B09W18tdx3s=.5b58283b-b512-4aef-96b9-b8e80a2a9279@github.com>
Message-ID: <eIm-b-JNmktrMrpSPTH4kgT8k1uhEd4jhrttHc3wgIU=.bb8fa5cc-762d-4777-9994-2e5a21a7ef78@github.com>

On Mon, 25 Apr 2022 17:20:39 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Are you sure that CEmbeddedFrame is used in the embedding functionality? We have another one on macOS CViewEmbeddedFrame. One of them was used for applets another one was used by the JAWT and SWT. Please double-check that the correct one is used for this test, and another one probably can be removed.
>
> I see that windows and linux have a long value that identifies the window that gets pass into the constructor of the EmbeddedFrame class object. Is there an equivalent in macOS? I see that CViewEmbeddedFrame has the nsViewPtr that is equivalent, but I don't see any way to find that value from LWComponentPeer.

It seems LWCToolkit creates a CViewPlatformEmbeddedFrame for VIEW_EMBEDDED_FRAME type so probably you can call CViewPlatformEmbeddedFrame.getNSViewPtr to get the long value and then call CViewEmbeddedFrame with the nsviewPtr value

-------------

PR: https://git.openjdk.java.net/jdk/pull/8348


From psadhukhan at openjdk.java.net  Tue Apr 26 06:01:06 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 26 Apr 2022 06:01:06 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v11]
In-Reply-To: <9T2LZvjkusyRd4JjbAU5_Yn277lAOnC02Esvq_R8yyg=.136fa8f8-0768-4774-8461-4591ca071453@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <9T2LZvjkusyRd4JjbAU5_Yn277lAOnC02Esvq_R8yyg=.136fa8f8-0768-4774-8461-4591ca071453@github.com>
Message-ID: <kcMV8wS-VOOH5n8BSiJLyjA-BO4Xf44Ysp2SxlnejSE=.cedf7f24-d198-4203-8015-4f4f62d3cce4@github.com>

On Tue, 12 Apr 2022 00:22:31 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> Previously while tabbing through the JTable cell, the cell highlighter/focus ring was not visible against the selection background. 
>> 
>> Changes are made to Aqua LAF to derive a lighter focus ring color by changing saturation and setting brightness component to 100% of original focus ring color so that it is visible while tabbing through `JTable` cells. A new method is added for this purpose which takes in `focusRingColor`, does adjustment to saturation and brightness and returns a new focus ring color. There are edge cases where the HSB transformation does not yield the right focus ring color, for these cases a default color is returned.
>> 
>> **Edge Cases**
>> ![image](https://user-images.githubusercontent.com/95945681/161360456-3929acf1-282b-4c2b-95d1-1d5707c1e238.png)
>> 
>> The edge case condition consists of two parts ?
>> To handle white/black colors - (hsbValues[0] == 0 && hsbValues[1] == 0) - representing hue and saturation of zero obtained for black, white or exactly grey (red=green=color) conditions
>> To handle grayish colors - hsbValues[1] <= satGrayScale where satGrayScale <= 0.10 . For any given hue and brightness, a saturation of less than or equal to 10% represents grayish tint colors.
>> (The second case was added to accommodate grayish focus ring color returned by system when Accent color = Graphite.  The returned color is not exactly gray but grayish (r=135, g=135, b=140)). 
>> To accommodate a more generic case of grayish colors, the satGrayScale has a threshold or buffer of 0.10 or 10%. 
>> 
>> Used the following resources to test out different grayish colors and optimal saturation offsets used in  `deriveLighterFocusRing()`.
>> 
>> - [RapidTables](https://www.rapidtables.com/convert/color/rgb-to-hsl.html) 
>> - [Colorizer](http://colorizer.org/).
>> - [Chart Link](https://codepen.io/HunorMarton/details/eWvewo)
>> 
>> A test case is added to compare the RGB difference between the original focus ring color & selection background and the new focus ring color & selection background.
>> 
>> PS: The native L&F (Mac OS) and Swing L&F for JTable cell tabbing differs (on native tables the cell background turns white on focus with a cell focus ring). Since the background for Swing tables can be set by users and also overridden by subclassing `DefaultTableCellRenderer`, and to adhere to current implementation of Swing, the white cell background changes are not incorporated. Only the Focus Ring/ Cell Highlighter is made more prominent.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added new color to CSystemColors.m - CELL_HIGHLIGHT_COLOR

src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java line 392:

> 390: 
> 391:         // for table cell highlighter
> 392:         final Color cellFocusRing = AquaImageFactory.getCellHighlightColorUIResource();

overall looks ok. I believe you have tested well in BigSur and Monterey also..
Minor nit, this cellFocusRing should be "cellFocusRingColor" like other color variables.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From jdv at openjdk.java.net  Tue Apr 26 06:06:54 2022
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 26 Apr 2022 06:06:54 GMT
Subject: RFR: 8198622: java/awt/Focus/TypeAhead/TestFocusFreeze.java fails
 on mac [v2]
In-Reply-To: <ygwdpSWCc4hSCtiFjVMqNRreKPoPhDW0cfn64VEH91o=.c7bfbf6d-f5c1-4dd1-b381-46e414b82da7@github.com>
References: <8guUkZCRSqeoI9P6-bxBTJjWgQuw_nQbLcfuUeUv3MA=.0fffd884-dff4-4bdc-a522-be7cf921a72c@github.com>
 <ygwdpSWCc4hSCtiFjVMqNRreKPoPhDW0cfn64VEH91o=.c7bfbf6d-f5c1-4dd1-b381-46e414b82da7@github.com>
Message-ID: <vYoSPpAIp1B9YAmSytz4kiuc1nTSwaCUfat2vtwvA4g=.f2e3650d-74b1-4856-b85e-0af866e5ea38@github.com>

On Wed, 20 Apr 2022 18:05:04 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> test passes, so removing from problem list
>
> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge master
>  - remove test from ProblemList

Marked as reviewed by jdv (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8254


From mvs at openjdk.java.net  Tue Apr 26 07:11:44 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Tue, 26 Apr 2022 07:11:44 GMT
Subject: RFR: 8274597: Some of the dnd tests time out and fail
 intermittently [v2]
In-Reply-To: <-M3RkI7ibFy3E3pyMdIyr-7-WWbZQXFo_4no53mvgDY=.761ad3d4-ff6c-4453-a328-173492e14616@github.com>
References: <PKtuBdvWgS96mNNJUmJbDu4WHk7yfGMXrXVahFBjio8=.25fcec82-0939-43b0-adeb-a6c1c6d9fe2f@github.com>
 <-M3RkI7ibFy3E3pyMdIyr-7-WWbZQXFo_4no53mvgDY=.761ad3d4-ff6c-4453-a328-173492e14616@github.com>
Message-ID: <AsdAfY-XOsv10wcnJTiyxNB21VIZk0W7r5ivi4JBGa8=.331d91c7-b578-40ef-a893-f3fc9c426463@github.com>

On Wed, 20 Apr 2022 13:28:17 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> These dnd tests fails with a time out intermittently in some machines(mostly Windows 11) which creates frequent noise in CI.
>> 1. java/awt/dnd/AcceptDropMultipleTimes/AcceptDropMultipleTimes.java
>> 2. java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java
>> 3. java/awt/dnd/DropTargetEnterExitTest/ExtraDragEnterTest.java
>> 
>> Issue :
>> These tests are using the Util.drag() method and there was no robot.delay() added between different mouse actions in this method. This could potentially make tests using this method unstable.
>> 
>> Fix:
>> Adding a small auto delay of 100ms to fix this.
>> 
>> Testing:
>> 1. All the three tests are run 15 times per platform.
>> 2. All the tests in java/awt/dnd package run 5 times per platform
>> 3. All the three tests are run 5 times specifically on Windows 11 platform.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added blank line at end of file

Any takers?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8316


From smandalika at openjdk.java.net  Tue Apr 26 09:28:28 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Tue, 26 Apr 2022 09:28:28 GMT
Subject: RFR: 8284767: Create an automated test for JDK-4422535 [v2]
In-Reply-To: <iWC939OdQdtwd4aHn2SafTsP1e1knRWsxNCzKos1Cts=.e7b80f3f-8fb2-41a1-af41-0e31131d756e@github.com>
References: <iWC939OdQdtwd4aHn2SafTsP1e1knRWsxNCzKos1Cts=.e7b80f3f-8fb2-41a1-af41-0e31131d756e@github.com>
Message-ID: <1cZzZNkeKLMbo_-pRiMpaTbVQnRhEZdtJJ1tKQckWQA=.58617cb8-1e88-4bde-9936-f4a0788a72ea@github.com>

> Create an automated test for [JDK-4422535](https://bugs.openjdk.java.net/browse/JDK-4422535)
> AccessibleValue implementation only accept Integers
> The AccessibleValue implementations of the following components:
> 
> java.awt.Scrollbar
> javax.swing.AbstractButton
> javax.swing.JInternalFrame
> javax.swing.JSplitPane
> javax.swing.JScrollBar
> javax.swing.JProgressBar
> javax.swing.JSlider
> 
> require the argument to setCurrentAccessibleValue(Number) to be an Integer, else they completely ignore it - it returns a false indicating that the value has not been set by the return value, but they cannot know the reason for that).
> 
> The test verifies that for each of the above components, the AccessibleValue is set when it is set to a Number (Float, Double, long etc) and not just for an Integer.
> 
> his review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Review Comments Fixed: Simplified test code with a loop over the JComponents being tested.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8220/files
  - new: https://git.openjdk.java.net/jdk/pull/8220/files/21061b62..8536a648

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8220&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8220&range=00-01

  Stats: 267 lines in 1 file changed: 4 ins; 248 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8220.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8220/head:pull/8220

PR: https://git.openjdk.java.net/jdk/pull/8220


From smandalika at openjdk.java.net  Tue Apr 26 09:28:29 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Tue, 26 Apr 2022 09:28:29 GMT
Subject: RFR: 8284767: Create an automated test for JDK-4422535 [v2]
In-Reply-To: <kNE14UIut-46FLz8TyB-DQN7WDZkDM_eV05KZagop1Q=.dcdc183c-79bf-4489-8a4c-9ef172039570@github.com>
References: <iWC939OdQdtwd4aHn2SafTsP1e1knRWsxNCzKos1Cts=.e7b80f3f-8fb2-41a1-af41-0e31131d756e@github.com>
 <kNE14UIut-46FLz8TyB-DQN7WDZkDM_eV05KZagop1Q=.dcdc183c-79bf-4489-8a4c-9ef172039570@github.com>
Message-ID: <yZYaR0-M3Nery8Fsarz9xaU9SxCY1B0KfmbE0W_Xb6k=.9d9777f1-a712-48e8-a11d-7e3e53ef1951@github.com>

On Fri, 22 Apr 2022 18:02:47 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review Comments Fixed: Simplified test code with a loop over the JComponents being tested.
>
> test/jdk/javax/accessibility/4422535/SetCurrentAccessibleValueTest.java line 93:
> 
>> 91:         }
>> 92: 
>> 93:         if (!jScrollBar.getAccessibleContext().getAccessibleValue()
> 
> maybe you could write a loop to run each component?

Done. Simplified test code with a loop over the JComponents being tested.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8220


From prr at openjdk.java.net  Tue Apr 26 16:53:53 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 26 Apr 2022 16:53:53 GMT
Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong
 size [v2]
In-Reply-To: <SAu4OKejClHuOK9uEAFVXIKnqfGBcfn3MtqNhuMoCPM=.fba07a11-93eb-494d-b098-62bd2b4fd107@github.com>
References: <z72T3X_wgR6K7BdFL7Tqg8t6GXbJh-Vk0pDGCJjUnEE=.ba87e570-fc0b-45d5-8099-9ffeeeb09fc5@github.com>
 <SAu4OKejClHuOK9uEAFVXIKnqfGBcfn3MtqNhuMoCPM=.fba07a11-93eb-494d-b098-62bd2b4fd107@github.com>
Message-ID: <INZ7eXvOf4rTqh3KQ6HCHa9REoaHhQbMzPWeiW3lf24=.3f1df644-95aa-4925-838b-4f3ed86769bf@github.com>

On Mon, 25 Apr 2022 08:15:18 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

>> Japanese logical fonts are drawn with wrong size since Java 18.
>> It's triggered by JEP 400, UTF-8 by Default. `sun.awt.FontConfiguration` (and `sun.awt.windows.WFontConfiguration`) seems to expect the native encoding instead of the default encoding. This patch changes to use native encoding.
>> 
>> Tested: jdk_desktop on Windows, Linux, and macOS
>
> Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved the fix to WFontConfiguration

Hmm. I'm not sure I'm seeing what you see in the native app. 
There the Latin font is larger than the JDK case, and the Japanese font is smaller than the JDK case,
and they end up about the same size as each other.
Also you have to remember if you select "8 pt" in a windows native app, that (at 100% scale) is at 96dpi, not 72dpi.
So that's 96/72 times the size of the Java  8 pt font. 8 * 96 / 72 will round up to 11 pixels in native, not the 8 pixels in Java.

Also JDK - in theory - controls the exact fonts that are used even in a TextField.

I'd like to see this resolved but I'm still not feeling like I have a sufficient understanding.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8329


From duke at openjdk.java.net  Tue Apr 26 17:05:12 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Tue, 26 Apr 2022 17:05:12 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v11]
In-Reply-To: <kcMV8wS-VOOH5n8BSiJLyjA-BO4Xf44Ysp2SxlnejSE=.cedf7f24-d198-4203-8015-4f4f62d3cce4@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <9T2LZvjkusyRd4JjbAU5_Yn277lAOnC02Esvq_R8yyg=.136fa8f8-0768-4774-8461-4591ca071453@github.com>
 <kcMV8wS-VOOH5n8BSiJLyjA-BO4Xf44Ysp2SxlnejSE=.cedf7f24-d198-4203-8015-4f4f62d3cce4@github.com>
Message-ID: <WuI-hPrPp8DdP4bIqmJX_2KpiBDSOGkAoMwo-VgAL2s=.a882a980-8c93-4c8d-aee2-c0d3fc2b0d6c@github.com>

On Tue, 26 Apr 2022 05:57:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added new color to CSystemColors.m - CELL_HIGHLIGHT_COLOR
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java line 392:
> 
>> 390: 
>> 391:         // for table cell highlighter
>> 392:         final Color cellFocusRing = AquaImageFactory.getCellHighlightColorUIResource();
> 
> overall looks ok. I believe you have tested well in BigSur and Monterey also..
> Minor nit, this cellFocusRing should be "cellFocusRingColor" like other color variables.

@prsadhuk I have tested it on BigSur and Monterey, the new changes are working well. I will change the variable name as suggested and update the PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From duke at openjdk.java.net  Tue Apr 26 19:49:13 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Tue, 26 Apr 2022 19:49:13 GMT
Subject: RFR: JDK-8282772: JButton text set as HTML content has unwanted
 padding
Message-ID: <IZSuTxegoGBNFqjBNLrh4P_xp2g7nSB5ylXRfMSXSCM=.3ff25a09-3671-41b2-be73-e3912c6c67b1@github.com>

The insets for buttons were incorrect for L&Fs except for Aqua when the text is set to HTML. This was fixed in Aqua by adding a conditional to check for the BasicHTML property key in the button component. This same logic can be used to fix Metal & Motif L&Fs in BasicButtonUI, but Nimbus is not fixed by this. Nimbus gets its default values from a skin.laf file, and when the defaults here are set to have left & right insets to 0 for ButtonUI, the issue is fixed. I also tested for non-HTML text after the changes, and the changes do not affect normal text.

The HtmlButtonImageTest has been changed to cycle through all L&Fs available on a device.

-------------

Commit messages:
 - Added conditional for HTML in BasicButtonUI. Edited default Nimbus ButtonUI insets. Edited HtmlButtonImageTest to cycle all L&Fs. Recreated this branch to fix sync issue.

Changes: https://git.openjdk.java.net/jdk/pull/8407/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8407&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282772
  Stats: 67 lines in 3 files changed: 45 ins; 4 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8407.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8407/head:pull/8407

PR: https://git.openjdk.java.net/jdk/pull/8407


From prr at openjdk.java.net  Tue Apr 26 20:18:47 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 26 Apr 2022 20:18:47 GMT
Subject: RFR: JDK-8282772: JButton text set as HTML content has unwanted
 padding
In-Reply-To: <IZSuTxegoGBNFqjBNLrh4P_xp2g7nSB5ylXRfMSXSCM=.3ff25a09-3671-41b2-be73-e3912c6c67b1@github.com>
References: <IZSuTxegoGBNFqjBNLrh4P_xp2g7nSB5ylXRfMSXSCM=.3ff25a09-3671-41b2-be73-e3912c6c67b1@github.com>
Message-ID: <MxuevbqFOvzfINWYcGXgPCyvNrctakyXL7bJtpBBGhc=.9c0a867f-243b-42c0-975a-a5b1e8cfafcd@github.com>

On Tue, 26 Apr 2022 19:42:05 GMT, DamonGuy <duke at openjdk.java.net> wrote:

> The insets for buttons were incorrect for L&Fs except for Aqua when the text is set to HTML. This was fixed in Aqua by adding a conditional to check for the BasicHTML property key in the button component. This same logic can be used to fix Metal & Motif L&Fs in BasicButtonUI, but Nimbus is not fixed by this. Nimbus gets its default values from a skin.laf file, and when the defaults here are set to have left & right insets to 0 for ButtonUI, the issue is fixed. I also tested for non-HTML text after the changes, and the changes do not affect normal text.
> 
> The HtmlButtonImageTest has been changed to cycle through all L&Fs available on a device.

src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf line 271:

> (failed to retrieve contents of file, check the PR for context)
> I also tested for non-HTML text after the changes, and the changes do not affect normal text.

And this is true for this Nimbus case too ? Whereas your code update in BasicButtonUI is checking for HTML, I don't see how it could *not* change normal text in the Nimbus case.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8407


From prr at openjdk.java.net  Tue Apr 26 20:19:51 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 26 Apr 2022 20:19:51 GMT
Subject: RFR: 8285617 : Fix
 java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java manual test
In-Reply-To: <gJfXkDtoO4VBJIFH8Drdqj-YXGwKeGPmrIq8kzIT1Ug=.5267a947-1938-4cba-a3a3-45a43b6ae135@github.com>
References: <gJfXkDtoO4VBJIFH8Drdqj-YXGwKeGPmrIq8kzIT1Ug=.5267a947-1938-4cba-a3a3-45a43b6ae135@github.com>
Message-ID: <Uli_6o09iEbX3YLQu74vZeMKf-_pzbumBrG3ZwlB_6w=.731b7a8d-d5cb-4c0f-9ad3-78c5966c7070@github.com>

On Tue, 26 Apr 2022 01:44:45 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> 1) Removed yesno since test was failing with parser error due to @run main/manual=yesno 
> 2) User can't decide whether it as pass or fail after looking into the printout so add the PassFailJFrame support
> 
> @shurymury 
> @aivanov-jdk

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8395


From prr at openjdk.java.net  Tue Apr 26 20:25:51 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 26 Apr 2022 20:25:51 GMT
Subject: RFR: 8285612 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
In-Reply-To: <FjDS9wBgC4UrrnUaCoI-5tyAVVmg3FDQoNbPgij8rQI=.a18da791-1675-46dd-9ec8-cbd5f4f8a092@github.com>
References: <FjDS9wBgC4UrrnUaCoI-5tyAVVmg3FDQoNbPgij8rQI=.a18da791-1675-46dd-9ec8-cbd5f4f8a092@github.com>
Message-ID: <dwbWCJ54li8F1hAc727w6gSkK4QMNa4AqZwiCU1rVqI=.73977fdb-7832-41c0-b0dc-d3bee3664091@github.com>

On Mon, 25 Apr 2022 22:36:59 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> 1) Removed yesno to eliminate parserException
> 2) Added code to fit into manual framework so that timeout, pass & fail is handled.
> 3) Added code to mark the test as pass if printer service is not available
> 4) Added code to handle pressing or clicking of 'Cancel' button.
> 
> @shurymury 
> @aivanov-jdk

test/jdk/java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java line 81:

> 79:                 b) that numerical text on the image is displayed similarly
> 80:                 e) that the green quadrilaterals match on-screen
> 81:                 f) that the rendering is clipped at the default (typically1 inch)

typically1 inch -> typically 1 inch

test/jdk/java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java line 89:

> 87:             PassFailJFrame passFailJFrame = new PassFailJFrame("Test " +
> 88:                     "Instruction", instruction, 15);
> 89:             createTestUI();

might as well make this
EventQueue.invokeAndWait(createTestUI())

-------------

PR: https://git.openjdk.java.net/jdk/pull/8391


From prr at openjdk.java.net  Tue Apr 26 20:32:52 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 26 Apr 2022 20:32:52 GMT
Subject: RFR: 8196367:
 java/awt/List/SingleModeDeselect/SingleModeDeselect.java times out [v2]
In-Reply-To: <d1G3pnLgw8mrtP8y4idWhxp_5zmgZYDpdUl4FtoMHyU=.2bbb6592-1685-4732-9461-e7daeb0fb292@github.com>
References: <RIp2Ct6nMnFaHBjOegrgbWQkW9ADpi2_67NissUngQ0=.6756c018-50d2-46e1-a21b-edb807fd7ad5@github.com>
 <d1G3pnLgw8mrtP8y4idWhxp_5zmgZYDpdUl4FtoMHyU=.2bbb6592-1685-4732-9461-e7daeb0fb292@github.com>
Message-ID: <U7YcWAfbU8sQIbXNXaY1_OCht_36WJcwEsaj1GpYceE=.ba2cd45c-3296-439d-931b-b44284c8d101@github.com>

On Fri, 22 Apr 2022 21:57:23 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Clean up imports;
>> Close and dispose frame before exiting the test;
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use one tyr/catch instead of two
>   Generic code cleanup

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8351


From achung at openjdk.java.net  Tue Apr 26 20:34:03 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Tue, 26 Apr 2022 20:34:03 GMT
Subject: Integrated: JDK-8202790: DnD test DisposeFrameOnDragTest.java does not
 clean up
In-Reply-To: <QdsX-pN6mlmPluFzEBtyEHd0xBqbqH2wfR58jxC4BHg=.e606e5c6-ead4-49e9-98e2-97fb0fcf045c@github.com>
References: <QdsX-pN6mlmPluFzEBtyEHd0xBqbqH2wfR58jxC4BHg=.e606e5c6-ead4-49e9-98e2-97fb0fcf045c@github.com>
Message-ID: <0Vb48-6dhzQwXQbTldmIrXfYwnppWPaNPGt2BzeusAs=.9ce9ccad-f50a-4587-afe5-b21c86261595@github.com>

On Fri, 22 Apr 2022 19:41:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Added a background to the test to prevent the file from dragging onto the desktop and creating an extra file.

This pull request has now been integrated.

Changeset: 102a305f
Author:    Alisen Chung <achung at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/102a305f73d52d8e378de46c3c0b170db0f2c8af
Stats:     9 lines in 2 files changed: 7 ins; 1 del; 1 mod

8202790: DnD test DisposeFrameOnDragTest.java does not clean up

Reviewed-by: serb, kizune, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/8370


From achung at openjdk.java.net  Tue Apr 26 20:34:46 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Tue, 26 Apr 2022 20:34:46 GMT
Subject: Integrated: 8198666: Many java/awt/Modal/OnTop/ test fails on mac
In-Reply-To: <N4gaazOwBJPl-soN1a8chVdup4YqVMNHhmNPWpSybtw=.e6d1eb0e-9ede-40df-acd5-d7f45a371ee4@github.com>
References: <N4gaazOwBJPl-soN1a8chVdup4YqVMNHhmNPWpSybtw=.e6d1eb0e-9ede-40df-acd5-d7f45a371ee4@github.com>
Message-ID: <0BRN_BoTO4jl_-FAYGnXjN1WkgZz0kv3Y0hpGxMcQNA=.7a96384b-dfbc-4f17-99ac-131e89f2baf6@github.com>

On Fri, 22 Apr 2022 17:38:28 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Removed passing tests from problem list

This pull request has now been integrated.

Changeset: dbcf3893
Author:    Alisen Chung <achung at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dbcf38932ef4f87b560ec660851368ac5697f4da
Stats:     30 lines in 1 file changed: 0 ins; 30 del; 0 mod

8198666: Many java/awt/Modal/OnTop/ test fails on mac

Reviewed-by: kizune, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8368


From prr at openjdk.java.net  Tue Apr 26 20:36:59 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 26 Apr 2022 20:36:59 GMT
Subject: Integrated: 8284965: closed test sun/java2d/OpenGL/XORPaint.java is
 unstable
In-Reply-To: <jXlD0hMF8qqSCVHqlppJoClNCXpgaeJrAbl6Ku6FY5M=.69f4c6b1-78cb-418d-b400-ba018ac4474a@github.com>
References: <jXlD0hMF8qqSCVHqlppJoClNCXpgaeJrAbl6Ku6FY5M=.69f4c6b1-78cb-418d-b400-ba018ac4474a@github.com>
Message-ID: <cJkSIU240Fz9JZa0pH2u2bWpGp0DUPqqqVjP3C3dzs0=.df2c2295-5afe-4fb4-afc0-eaf4fb9564fb@github.com>

On Thu, 21 Apr 2022 17:15:20 GMT, Phil Race <prr at openjdk.org> wrote:

> This fix moves a closed test to open but updated to be more comprehensive in testing multiple pipelines and with some stabilisation improvements.

This pull request has now been integrated.

Changeset: 110edd99
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/110edd9999c1d26154fc090562d7c8b2ded18a10
Stats:     239 lines in 1 file changed: 239 ins; 0 del; 0 mod

8284965: closed test sun/java2d/OpenGL/XORPaint.java is unstable

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8345


From kizune at openjdk.java.net  Tue Apr 26 20:58:24 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 26 Apr 2022 20:58:24 GMT
Subject: RFR: 8196367:
 java/awt/List/SingleModeDeselect/SingleModeDeselect.java times out [v3]
In-Reply-To: <RIp2Ct6nMnFaHBjOegrgbWQkW9ADpi2_67NissUngQ0=.6756c018-50d2-46e1-a21b-edb807fd7ad5@github.com>
References: <RIp2Ct6nMnFaHBjOegrgbWQkW9ADpi2_67NissUngQ0=.6756c018-50d2-46e1-a21b-edb807fd7ad5@github.com>
Message-ID: <8c5coAq2GVLjhadsfYp_1RPmB1qD2sK67wCWpGw4sMw=.ce100fc6-ea1b-4953-abe9-564d401b58da@github.com>

> Clean up imports;
> Close and dispose frame before exiting the test;

Alexander Zuev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into JDK-8196367
 - Use one tyr/catch instead of two
   Generic code cleanup
 - Remove test from the ProblemList
 - 8196367: java/awt/List/SingleModeDeselect/SingleModeDeselect.java times out
   
   Clean up imports;
   Close and dispose frame before exiting the test;

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8351/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8351&range=02
  Stats: 27 lines in 2 files changed: 12 ins; 9 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8351.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8351/head:pull/8351

PR: https://git.openjdk.java.net/jdk/pull/8351


From kizune at openjdk.java.net  Tue Apr 26 20:58:25 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 26 Apr 2022 20:58:25 GMT
Subject: Integrated: 8196367:
 java/awt/List/SingleModeDeselect/SingleModeDeselect.java times out
In-Reply-To: <RIp2Ct6nMnFaHBjOegrgbWQkW9ADpi2_67NissUngQ0=.6756c018-50d2-46e1-a21b-edb807fd7ad5@github.com>
References: <RIp2Ct6nMnFaHBjOegrgbWQkW9ADpi2_67NissUngQ0=.6756c018-50d2-46e1-a21b-edb807fd7ad5@github.com>
Message-ID: <NssXuSD_rSaRLOOpDIZy0dy0LSyuioygDlIFiphhWKQ=.d86be13e-860a-4944-8b18-027194af088f@github.com>

On Thu, 21 Apr 2022 22:03:17 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Clean up imports;
> Close and dispose frame before exiting the test;

This pull request has now been integrated.

Changeset: e574cc0e
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e574cc0e2b3330daf7494b809a06b12f2c875916
Stats:     27 lines in 2 files changed: 12 ins; 9 del; 6 mod

8196367: java/awt/List/SingleModeDeselect/SingleModeDeselect.java times out

Reviewed-by: prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/8351


From kizune at openjdk.java.net  Tue Apr 26 22:06:09 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 26 Apr 2022 22:06:09 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v3]
In-Reply-To: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
Message-ID: <QNwEljGPhlL8ImZFy0IGjfr7p8kenkdyliH6ic9UY_Y=.3ce0d201-7dcf-48d8-9fab-0b45c875a6c6@github.com>

> Detect the situation where we do need to perform interpolation during ImageIcon
> painting and set a hint to the rendering to perform bicubic approximation so
> image details are preserved during transition.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Take into account scale factor;
  Create a new Graphics2D object instead of juggle the rendering hints;

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7805/files
  - new: https://git.openjdk.java.net/jdk/pull/7805/files/6967cc18..a6aef9a9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7805&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7805&range=01-02

  Stats: 19 lines in 1 file changed: 2 ins; 2 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7805.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7805/head:pull/7805

PR: https://git.openjdk.java.net/jdk/pull/7805


From kizune at openjdk.java.net  Tue Apr 26 22:20:10 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 26 Apr 2022 22:20:10 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v3]
In-Reply-To: <QNwEljGPhlL8ImZFy0IGjfr7p8kenkdyliH6ic9UY_Y=.3ce0d201-7dcf-48d8-9fab-0b45c875a6c6@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <QNwEljGPhlL8ImZFy0IGjfr7p8kenkdyliH6ic9UY_Y=.3ce0d201-7dcf-48d8-9fab-0b45c875a6c6@github.com>
Message-ID: <qcZJDRaqC5FDpZ9Wa6N8Dbfg-8pg1KFYKh7I7kaGCd8=.8cf18223-32ff-43db-a5e8-74836784f782@github.com>

On Tue, 26 Apr 2022 22:06:09 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Detect the situation where we do need to perform interpolation during ImageIcon
>> painting and set a hint to the rendering to perform bicubic approximation so
>> image details are preserved during transition.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Take into account scale factor;
>   Create a new Graphics2D object instead of juggle the rendering hints;

Ok, i have modified PR to use the scale factor to determine if we will need the scaling operation at all and i'm creating a new Graphics2D object so i do not need to swap the rendering hints. Saying that BICUBIC is expensive - i have found any noticeable performance impact when using this code. And it is not always the scale down that needs this hint - even scaling up of the icons when scaling factor is set to 125 or 175% gives much better result for icons that do not have the exact match in size for the said scaling.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7805


From serb at openjdk.java.net  Tue Apr 26 22:20:11 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 26 Apr 2022 22:20:11 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v3]
In-Reply-To: <GPzIIvLxz-v5hjtHLPCqEmpMn0dyJybVfPhQbVtMvKM=.517d28de-1197-4f4b-97da-7f7109c6df0d@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <rWCyzbxnTraucb96bdEvdDEv7Dx0SdlW0ur1RFoTzMA=.0c697691-3dba-476b-80ac-2a8f0306cf80@github.com>
 <ykpowK0z6aNXzTun2818uIhiF1V-VIF5ZTzmWtaGKDk=.ebb3750e-f8f0-4e81-9358-be6a6618e259@github.com>
 <GPzIIvLxz-v5hjtHLPCqEmpMn0dyJybVfPhQbVtMvKM=.517d28de-1197-4f4b-97da-7f7109c6df0d@github.com>
Message-ID: <CA0IiPIFpYcJDacE4HFSGlwpzUCs8V7d4eOdwaN7SjI=.164af885-a85b-4bf8-8084-b393b11a1451@github.com>

On Wed, 16 Mar 2022 05:36:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> This might be a rookie question:
>>> 
>>> When it comes to modifying and restoring a Graphics, I've seen two common patterns: A. Call `newG = g.create()` and later `newG.dispose()` B. Call `g.setX(newValue)` and then call `g.setX(oldValue)` later
>>> 
>>> Is there guidance on when to use which? Or is one always preferred?
>> 
>> Usually i follow the rule of minimal action. When i need to set a lot of hints that needs to be later unrolled such as changing graphics coordinates and such - i'm creating a new Graphics. When i only need to manipulate a single hint and it can easily be unrolled - i am using the same object. In this case i'm changing just a single hint.
>
> I am not sure that this is the right place to change the hints.
> If we want to always scale the icon using the bicubic interpolation then it is better to do it where we call the paintIcon() method in some jcomponent(this probably may be configured by some option - similar to the text antialisaing). But it will affect performance since the bicubic is much slower.
> 
> But before discussing this shared code change could you please provide some info on why it worked fine before? Why we try to downscale the image and do not get an exact size from the native.

I suggest to recheck the issues described above, updating the shared implementation of `ImageIcon.java` seems wrong

-------------

PR: https://git.openjdk.java.net/jdk/pull/7805


From kizune at openjdk.java.net  Tue Apr 26 22:27:23 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 26 Apr 2022 22:27:23 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v3]
In-Reply-To: <QNwEljGPhlL8ImZFy0IGjfr7p8kenkdyliH6ic9UY_Y=.3ce0d201-7dcf-48d8-9fab-0b45c875a6c6@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <QNwEljGPhlL8ImZFy0IGjfr7p8kenkdyliH6ic9UY_Y=.3ce0d201-7dcf-48d8-9fab-0b45c875a6c6@github.com>
Message-ID: <l3-n06aLCnuDyt_zhUD39rskW34haYGoBDKmvxYbVJk=.31733d17-7089-43df-8c2c-2af7aa97d0b4@github.com>

On Tue, 26 Apr 2022 22:06:09 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Detect the situation where we do need to perform interpolation during ImageIcon
>> painting and set a hint to the rendering to perform bicubic approximation so
>> image details are preserved during transition.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Take into account scale factor;
>   Create a new Graphics2D object instead of juggle the rendering hints;

> I suggest to recheck the issues described above, updating the shared implementation of ImageIcon.java seems wrong

Yes, the issue manifests itself only on Windows - but i was able to reproduce it using generic MultiResolutionIcon in the test case so while it CAN be fixed in the Windows specific code i still think addressing it in the shared code is a right thing to do.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7805


From darcy at openjdk.java.net  Tue Apr 26 22:33:21 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 26 Apr 2022 22:33:21 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces
Message-ID: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>

To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.

To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.

Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).

I'll update copyright years before pushing.

-------------

Commit messages:
 - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces

Changes: https://git.openjdk.java.net/jdk/pull/8410/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285676
  Stats: 76 lines in 40 files changed: 76 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8410.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8410/head:pull/8410

PR: https://git.openjdk.java.net/jdk/pull/8410


From duke at openjdk.java.net  Tue Apr 26 22:41:14 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Tue, 26 Apr 2022 22:41:14 GMT
Subject: RFR: 8285612 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java [v2]
In-Reply-To: <FjDS9wBgC4UrrnUaCoI-5tyAVVmg3FDQoNbPgij8rQI=.a18da791-1675-46dd-9ec8-cbd5f4f8a092@github.com>
References: <FjDS9wBgC4UrrnUaCoI-5tyAVVmg3FDQoNbPgij8rQI=.a18da791-1675-46dd-9ec8-cbd5f4f8a092@github.com>
Message-ID: <6dYI6zyPcsfDxamssY5OvarQUnj_L73kZEm1zw-9UBE=.3fa6d985-201e-4a76-b6b1-5e72555d4158@github.com>

> 1) Removed yesno to eliminate parserException
> 2) Added code to fit into manual framework so that timeout, pass & fail is handled.
> 3) Added code to mark the test as pass if printer service is not available
> 4) Added code to handle pressing or clicking of 'Cancel' button.
> 
> @shurymury 
> @aivanov-jdk

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/8391/files
  - new: https://git.openjdk.java.net/jdk/pull/8391/files/1af25bff..53aa04cb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8391&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8391&range=00-01

  Stats: 7 lines in 1 file changed: 2 ins; 3 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8391.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8391/head:pull/8391

PR: https://git.openjdk.java.net/jdk/pull/8391


From serb at openjdk.java.net  Tue Apr 26 22:49:40 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 26 Apr 2022 22:49:40 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v3]
In-Reply-To: <l3-n06aLCnuDyt_zhUD39rskW34haYGoBDKmvxYbVJk=.31733d17-7089-43df-8c2c-2af7aa97d0b4@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <QNwEljGPhlL8ImZFy0IGjfr7p8kenkdyliH6ic9UY_Y=.3ce0d201-7dcf-48d8-9fab-0b45c875a6c6@github.com>
 <l3-n06aLCnuDyt_zhUD39rskW34haYGoBDKmvxYbVJk=.31733d17-7089-43df-8c2c-2af7aa97d0b4@github.com>
Message-ID: <7zYHFtn9L54eIDP49ZZtZA_kDPWwhwWTo1Zzy82gyYc=.21baf5bc-9604-4242-92d7-65bfb68cf9a0@github.com>

On Tue, 26 Apr 2022 22:23:55 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Yes, the issue manifests itself only on Windows - but i was able to reproduce it using generic MultiResolutionIcon in the test case so while it CAN be fixed in the Windows specific code i still think addressing it in the shared code is a right thing to do.

Fixing it in the ImageIcon is similar to fixing it by changing internal default state of the rendering pipeline in any other places like images/graphics/fonts, while we have to change that state "externally". We have to set BICUBIC interpolation in the place where we draw that image/icon.

But before discussing that, it would be good to understand:
 - is it a regression or not, if yes then what change caused that, did we have some wrong assumption?
 - why we need to downscale the image, 16x16/32x32 is quite common sizes why we cannot read an exact size from the native which I think will provide the best quality?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7805


From duke at openjdk.java.net  Tue Apr 26 23:00:05 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Tue, 26 Apr 2022 23:00:05 GMT
Subject: Integrated: JDK-8251177: [macosx] The text "big" is truncated in
 JTabbedPane
In-Reply-To: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
References: <tGEnyQKeJF0yuglCYEfoACz0rtF6AUlSjIbD3z0QWMc=.e4054fc3-04df-46c3-ad01-5d4d47dafee2@github.com>
Message-ID: <tQut8Xz1dxZswjiIi7NiOj84qqPW8IwOVcLUJ6WVGQQ=.fb5f782e-37da-471a-971a-f4aeb79c2e40@github.com>

On Tue, 19 Apr 2022 21:03:13 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

> The exisiting manual test case tests different html styles of JTabbedPane tab title. The tab with "big" as title is seen to be clipped on Aqua LAF for larger font-size. In other LAFs it is observed that bigger font-size can be accommodated without clipping.
> 
> The following approaches were evaluated before considering it as not a test issue -
> 
> - Aqua LAF has a different tab style compared to other LAFs as seen in the screenshot below. Limiting font size on Aqua LAF requires scaling down the text which might be incompatible with Aqua LAF.
> 
> - Removing existing constraints on text and icon is incompatible for Aqua LAF.
> 
> Since the above two approaches are incompatible with Aqua and it is not a test issue, a note has been added about clipped text and this test has been removed from problem list
> 
> ![image](https://user-images.githubusercontent.com/95945681/164093604-ca7ecbc3-09c2-4338-bd2a-f8c81c12f360.png)

This pull request has now been integrated.

Changeset: 16ebe40a
Author:    Harshitha Onkar <harshitha.onkar at oracle.com>
Committer: Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/16ebe40a1bcd1fe43126fe1dca27bb64cb12de16
Stats:     91 lines in 3 files changed: 28 ins; 38 del; 25 mod

8251177: [macosx] The text "big" is truncated in JTabbedPane

Reviewed-by: psadhukhan, kizune, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8307


From wetmore at openjdk.java.net  Tue Apr 26 23:05:58 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 26 Apr 2022 23:05:58 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces
In-Reply-To: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
Message-ID: <Mrv3-W6N7gjMctLzqz8_Dq_MPIoUkqUa2N0Gbg9Xf7g=.f0b54b3f-1f6b-4f9b-bac5-e29f1fe6aff5@github.com>

On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
> 
> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
> 
> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
> 
> I'll update copyright years before pushing.

The two `java.security` ones LGTM.

-------------

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8410


From kizune at openjdk.java.net  Tue Apr 26 23:25:43 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 26 Apr 2022 23:25:43 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v3]
In-Reply-To: <7zYHFtn9L54eIDP49ZZtZA_kDPWwhwWTo1Zzy82gyYc=.21baf5bc-9604-4242-92d7-65bfb68cf9a0@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <QNwEljGPhlL8ImZFy0IGjfr7p8kenkdyliH6ic9UY_Y=.3ce0d201-7dcf-48d8-9fab-0b45c875a6c6@github.com>
 <l3-n06aLCnuDyt_zhUD39rskW34haYGoBDKmvxYbVJk=.31733d17-7089-43df-8c2c-2af7aa97d0b4@github.com>
 <7zYHFtn9L54eIDP49ZZtZA_kDPWwhwWTo1Zzy82gyYc=.21baf5bc-9604-4242-92d7-65bfb68cf9a0@github.com>
Message-ID: <9YGqKP4x5N0miiskVwMoF201g7ng3JjTnJF5ctGkD5w=.9b763d6a-469d-49b0-83cd-79cc46cdfecd@github.com>

On Tue, 26 Apr 2022 22:46:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Fixing it in the ImageIcon is similar to fixing it by changing internal default state of the rendering pipeline in any other places like images/graphics/fonts, while we have to change that state "externally". We have to set BICUBIC interpolation in the place where we draw that image/icon.

We are setting the BICUBIC only in place where we draw the image part of ImageIcon. There is no benefit in pushing this change down the pipeline.

> But before discussing that, it would be good to understand:
> 
>     * is it a regression or not, if yes then what change caused that, did we have some wrong assumption?

It is not a regression, it is a side effect of the JDK-8182043 combined with the Windows 10 update that changed the default windows file icon to the blank white sheet with 1 pixel wide dark gray border.

>     * why we need to downscale the image, 16x16/32x32 is quite common sizes why we cannot read an exact size from the native which I think will provide the best quality?

Because we can not read this icon from the native, when we ask Windows API to provide this icon it ignores the icon size and gives the same 32x32 icon instead. We knew this upfront and the consensus was that we will provide the icon in the MultiResolutionImage and scaling during painting will be good enough to scale it properly. But it is not. The default scale algorithm is terrible and when new icons appeared it became obvious. Aside of that default scaling on fractional magnification factors such as 5/8 or 7/8 looks just bad - a lot of scaling artifacts and missing details. That has to be addressed and that's what i'm trying to do.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7805


From jjg at openjdk.java.net  Tue Apr 26 23:38:42 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 26 Apr 2022 23:38:42 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces
In-Reply-To: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
Message-ID: <MURKJqzm5cRIvi152qaevEt30OPStqQaWymnG2TkkBA=.f8562675-7851-4f1d-8854-94acd825c47b@github.com>

On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
> 
> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
> 
> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
> 
> I'll update copyright years before pushing.

src/java.base/share/classes/java/lang/ClassValue.java line 43:

> 41:  * it can use a {@code ClassValue} to cache information needed to
> 42:  * perform the message send quickly, for each class encountered.
> 43:  * @param <T> type of the derived value

stylistically, compared to other comments, you are missing an initial "the"

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410


From serb at openjdk.java.net  Tue Apr 26 23:52:41 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 26 Apr 2022 23:52:41 GMT
Subject: RFR: 8273506: java Robot API did the 'm' keypress and caused
 /awt/event/KeyEvent/KeyCharTest/KeyCharTest.html is timing out on macOS 12
 [v2]
In-Reply-To: <ATVnDSAZVpL6Ejw_ioaEB_f2rpnVo9pp9AyXetvR3lo=.f84a1a65-6193-4104-91c0-0d5901a21fc9@github.com>
References: <jmtC1w9SyvfAg940bq60x20bVshEm5P2g7IExDWnpBk=.1cdcdbc2-881c-4cce-a2c0-73873369e0c5@github.com>
 <33wbZN4ZDtQ564BCCatIOTX2sVRXi308jFUzKbKOaVE=.4ecfdde4-74ed-4319-bf86-492c3e47a32b@github.com>
 <MAimCg0Q8gqv0vhLraXUMDe0OG-YVRhrIkoa5WILhGU=.bd98a8ac-14e7-4198-9dbe-66fa10f6c5fb@github.com>
 <ATVnDSAZVpL6Ejw_ioaEB_f2rpnVo9pp9AyXetvR3lo=.f84a1a65-6193-4104-91c0-0d5901a21fc9@github.com>
Message-ID: <37TufUb6JsjhJ_XeyGHMDcBKynjT8g6wUzw8klRoWOA=.fd51e990-f13a-47da-abb1-4fdda23aba65@github.com>

On Sat, 23 Apr 2022 07:21:51 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Ok, starting from the beginning - there is no possibility to press the Function key with Robot, the corresponding key code (OSX_Function - 0x3F) has not mapped to any of the keys available to Robot. Function key does not act like a caps lock - it acts like a shift. Just like a shift, it can only be fixated by the accessibility feature "sticky keys". Once Function key is released the global state should be changed in a way as if this key is not active. We do not issue key press or key release event for the Function key. The reason of why global state is being changed this way when we issue key press/key release sequence for a totally unrelated key (OSX_DownArrow - 0x7D) is unknown, it happens in the native code outside of our control. All we can do is to eliminate the consequences of this action that started to cause problems in Mac OS X 12.

That description is very helpful, thank you. Based on that it looks like this is a bug in the macOS, did we report it to the Apple?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8320


From serb at openjdk.java.net  Wed Apr 27 00:03:45 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 27 Apr 2022 00:03:45 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v3]
In-Reply-To: <9YGqKP4x5N0miiskVwMoF201g7ng3JjTnJF5ctGkD5w=.9b763d6a-469d-49b0-83cd-79cc46cdfecd@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <QNwEljGPhlL8ImZFy0IGjfr7p8kenkdyliH6ic9UY_Y=.3ce0d201-7dcf-48d8-9fab-0b45c875a6c6@github.com>
 <l3-n06aLCnuDyt_zhUD39rskW34haYGoBDKmvxYbVJk=.31733d17-7089-43df-8c2c-2af7aa97d0b4@github.com>
 <7zYHFtn9L54eIDP49ZZtZA_kDPWwhwWTo1Zzy82gyYc=.21baf5bc-9604-4242-92d7-65bfb68cf9a0@github.com>
 <9YGqKP4x5N0miiskVwMoF201g7ng3JjTnJF5ctGkD5w=.9b763d6a-469d-49b0-83cd-79cc46cdfecd@github.com>
Message-ID: <W6AqQeqEwesfv4ol5hrabENk_BbYhKB6ZPpFGSsqh_c=.a448304e-e2c9-4592-a8a7-9f16b6b64982@github.com>

On Tue, 26 Apr 2022 23:22:18 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> We are setting the BICUBIC only in place where we draw the image part of ImageIcon. There is no benefit in pushing this change down the pipeline.

We don't need to push change down to the pipeline, we should push it up to the place where we paint this ImageIcon, eventually where we call ImageIcon.paintIcon()

> It is not a regression, it is a side effect of the JDK-8182043 combined with the Windows 10 update that changed the default windows file icon to the blank white sheet with 1 pixel wide dark gray border.
> Because we can not read this icon from the native, when we ask Windows API to provide this icon it ignores the icon size and gives the same 32x32 icon instead. We knew this upfront and the consensus was that we will provide the icon in the MultiResolutionImage and scaling during painting will be good enough to scale it properly. But it is not.

Then why, as described in the JBS, it worked before? Did we request different image, or size, or did we skip scaling?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7805


From duke at openjdk.java.net  Wed Apr 27 00:14:21 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Wed, 27 Apr 2022 00:14:21 GMT
Subject: RFR: 8285687 : Remove jtreg tag manual=yesno for
 ava/awt/print/PrinterJob/PageRangesDlgTest.java
Message-ID: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com>

1) Fixed Parser error by removing  yesno from @run main/manual=yesno 
2) Used PassFaileJFrame to show the test instruction to the user instead of printing the test instruction on the console or jtreg log file. 
3) If printer is not configured then mark the test as passed.

@shurymury 
@aivanov-jdk

-------------

Commit messages:
 - 8285687 : Remove jtreg tag manual=yesno for ava/awt/print/PrinterJob/PageRangesDlgTest.java

Changes: https://git.openjdk.java.net/jdk/pull/8412/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8412&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285687
  Stats: 66 lines in 1 file changed: 37 ins; 22 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8412.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8412/head:pull/8412

PR: https://git.openjdk.java.net/jdk/pull/8412


From smarks at openjdk.java.net  Wed Apr 27 01:48:49 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 27 Apr 2022 01:48:49 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces
In-Reply-To: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
Message-ID: <RP5pEdBu7p3ahgfvtS8xGO42CfAqviuauaYR6Iq_HZw=.f150aa97-e496-41c2-96b5-011975f9a112@github.com>

On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
> 
> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
> 
> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
> 
> I'll update copyright years before pushing.

I've looked at the changes in java.util (but not sub packages). They're fine, modulo some minor wording changes.

src/java.base/share/classes/java/util/AbstractMap.java line 601:

> 599:      * {@code Map.entrySet().toArray}.
> 600:      *
> 601:      * @param <K> the type of keys maintained

Please update to match java.util.Map, which says "the type of keys maintained by this map"

src/java.base/share/classes/java/util/AbstractMap.java line 748:

> 746:      *
> 747:      * @param <K> the type of keys maintained
> 748:      * @param <V> the type of mapped values

Please update to match Map.Entry, which says simply "the type of key" and "the type of the value"

src/java.base/share/classes/java/util/Dictionary.java line 44:

> 42:  * @param <K> the type of keys
> 43:  * @param <V> the type of mapped values
> 44:  *

Urgh. This class is obsolete, but it was retrofitted to implement Map and was subsequently generified, so I'd update these to match java.util.Map.

-------------

Marked as reviewed by smarks (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8410


From prr at openjdk.java.net  Wed Apr 27 03:41:42 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 27 Apr 2022 03:41:42 GMT
Subject: RFR: 8285306: Fix typos in java.desktop
In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
Message-ID: <4QVTblMgjEo2KBoDGn1G67qqvHtOkdmqeU4e88o2eHU=.faf55412-6b4a-4fe4-ac84-82ee0cea2f8d@github.com>

On Thu, 21 Apr 2022 08:35:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
> 
> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

static class AquaHierarchyButtonListener implements HierarchyListener {
-        // Everytime a hierarchy is change we need to check if the button if moved on or from
+        // Every time a hierarchy is change we need to check if the button if moved on or from

change -> changed
if moved -> is moved

src/java.desktop/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java


-            // it won't be invoced if focuse is moved to a html element
+            // it won't be invoced if focus is moved to a html element

invoced -> invoked
"a html" -> "an html"

src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiOut.c
+    // $$fb 2002-04-04: It is responsibility of the application developer to

"is the"

src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_MidiOut.c

+    // $$fb 2002-04-04: It is responsibility of the application developer to

same as above

Regarding changes in gif + freetype 
diff --git a/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c b/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c

diff --git a/src/java.desktop/share/native/libfontmanager/freetypeScaler.c b/src/java.desktop/share/native/libfontmanager/freetypeScaler.c

Please exclude ALL 3rd party libraries from this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8328


From kizune at openjdk.java.net  Wed Apr 27 03:45:44 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 27 Apr 2022 03:45:44 GMT
Subject: RFR: 8273506: java Robot API did the 'm' keypress and caused
 /awt/event/KeyEvent/KeyCharTest/KeyCharTest.html is timing out on macOS 12
 [v2]
In-Reply-To: <37TufUb6JsjhJ_XeyGHMDcBKynjT8g6wUzw8klRoWOA=.fd51e990-f13a-47da-abb1-4fdda23aba65@github.com>
References: <jmtC1w9SyvfAg940bq60x20bVshEm5P2g7IExDWnpBk=.1cdcdbc2-881c-4cce-a2c0-73873369e0c5@github.com>
 <33wbZN4ZDtQ564BCCatIOTX2sVRXi308jFUzKbKOaVE=.4ecfdde4-74ed-4319-bf86-492c3e47a32b@github.com>
 <MAimCg0Q8gqv0vhLraXUMDe0OG-YVRhrIkoa5WILhGU=.bd98a8ac-14e7-4198-9dbe-66fa10f6c5fb@github.com>
 <ATVnDSAZVpL6Ejw_ioaEB_f2rpnVo9pp9AyXetvR3lo=.f84a1a65-6193-4104-91c0-0d5901a21fc9@github.com>
 <37TufUb6JsjhJ_XeyGHMDcBKynjT8g6wUzw8klRoWOA=.fd51e990-f13a-47da-abb1-4fdda23aba65@github.com>
Message-ID: <ady_Pz8WC6Fs_IIaow2qfa_SXLMZlBcDfkJ8wFqzyQU=.0d8f0564-cf86-4ec6-9770-3e0bcee6be73@github.com>

On Tue, 26 Apr 2022 23:49:26 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> That description is very helpful, thank you. Based on that it looks like this is a bug in the macOS, did we report it to the Apple?

No, we did not. I probably will but it is unlikely it will be addressed quickly so fixing this issue on out side seems to be required anyways.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8320


From duke at openjdk.java.net  Wed Apr 27 04:34:20 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Wed, 27 Apr 2022 04:34:20 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v12]
In-Reply-To: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
Message-ID: <1iSsUS97cm0YKPQwV4J0zAh6HLgpQgK7XPCK56sRkgs=.48893e06-8ea8-4d39-8509-09d0fd5caec2@github.com>

> Previously while tabbing through the JTable cell, the cell highlighter/focus ring was not visible against the selection background. 
> 
> Changes are made to Aqua LAF to derive a lighter focus ring color by changing saturation and setting brightness component to 100% of original focus ring color so that it is visible while tabbing through `JTable` cells. A new method is added for this purpose which takes in `focusRingColor`, does adjustment to saturation and brightness and returns a new focus ring color. There are edge cases where the HSB transformation does not yield the right focus ring color, for these cases a default color is returned.
> 
> **Edge Cases**
> ![image](https://user-images.githubusercontent.com/95945681/161360456-3929acf1-282b-4c2b-95d1-1d5707c1e238.png)
> 
> The edge case condition consists of two parts ?
> To handle white/black colors - (hsbValues[0] == 0 && hsbValues[1] == 0) - representing hue and saturation of zero obtained for black, white or exactly grey (red=green=color) conditions
> To handle grayish colors - hsbValues[1] <= satGrayScale where satGrayScale <= 0.10 . For any given hue and brightness, a saturation of less than or equal to 10% represents grayish tint colors.
> (The second case was added to accommodate grayish focus ring color returned by system when Accent color = Graphite.  The returned color is not exactly gray but grayish (r=135, g=135, b=140)). 
> To accommodate a more generic case of grayish colors, the satGrayScale has a threshold or buffer of 0.10 or 10%. 
> 
> Used the following resources to test out different grayish colors and optimal saturation offsets used in  `deriveLighterFocusRing()`.
> 
> - [RapidTables](https://www.rapidtables.com/convert/color/rgb-to-hsl.html) 
> - [Colorizer](http://colorizer.org/).
> - [Chart Link](https://codepen.io/HunorMarton/details/eWvewo)
> 
> A test case is added to compare the RGB difference between the original focus ring color & selection background and the new focus ring color & selection background.
> 
> PS: The native L&F (Mac OS) and Swing L&F for JTable cell tabbing differs (on native tables the cell background turns white on focus with a cell focus ring). Since the background for Swing tables can be set by users and also overridden by subclassing `DefaultTableCellRenderer`, and to adhere to current implementation of Swing, the white cell background changes are not incorporated. Only the Focus Ring/ Cell Highlighter is made more prominent.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  chnaged variable name

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7768/files
  - new: https://git.openjdk.java.net/jdk/pull/7768/files/d13e37f8..a1c17b7a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7768&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7768&range=10-11

  Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7768/head:pull/7768

PR: https://git.openjdk.java.net/jdk/pull/7768


From duke at openjdk.java.net  Wed Apr 27 04:34:21 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Wed, 27 Apr 2022 04:34:21 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v11]
In-Reply-To: <kcMV8wS-VOOH5n8BSiJLyjA-BO4Xf44Ysp2SxlnejSE=.cedf7f24-d198-4203-8015-4f4f62d3cce4@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <9T2LZvjkusyRd4JjbAU5_Yn277lAOnC02Esvq_R8yyg=.136fa8f8-0768-4774-8461-4591ca071453@github.com>
 <kcMV8wS-VOOH5n8BSiJLyjA-BO4Xf44Ysp2SxlnejSE=.cedf7f24-d198-4203-8015-4f4f62d3cce4@github.com>
Message-ID: <prhBPBbRhCWLou-WZbBQyKtTqPyxIz4jNOw9rdGWof8=.276592d4-9504-4119-a16c-8bd811f15f7a@github.com>

On Tue, 26 Apr 2022 05:57:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added new color to CSystemColors.m - CELL_HIGHLIGHT_COLOR
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java line 392:
> 
>> 390: 
>> 391:         // for table cell highlighter
>> 392:         final Color cellFocusRing = AquaImageFactory.getCellHighlightColorUIResource();
> 
> overall looks ok. I believe you have tested well in BigSur and Monterey also..
> Minor nit, this cellFocusRing should be "cellFocusRingColor" like other color variables.

@prsadhuk Updated the PR. A note on the test case, since the test case is automated it tests the cell focus ring with colors loaded during the start of program execution and any on-the-fly accent color changes were tested manually.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From duke at openjdk.java.net  Wed Apr 27 04:36:27 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Wed, 27 Apr 2022 04:36:27 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v13]
In-Reply-To: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
Message-ID: <14wuJKRV_wzf0QtTpOODhGOghNcbGpHqN3daYz_wDJU=.90c0cc59-d36b-4ab9-ac1e-13c2bf965a1b@github.com>

> Previously while tabbing through the JTable cell, the cell highlighter/focus ring was not visible against the selection background. 
> 
> Changes are made to Aqua LAF to derive a lighter focus ring color by changing saturation and setting brightness component to 100% of original focus ring color so that it is visible while tabbing through `JTable` cells. A new method is added for this purpose which takes in `focusRingColor`, does adjustment to saturation and brightness and returns a new focus ring color. There are edge cases where the HSB transformation does not yield the right focus ring color, for these cases a default color is returned.
> 
> **Edge Cases**
> ![image](https://user-images.githubusercontent.com/95945681/161360456-3929acf1-282b-4c2b-95d1-1d5707c1e238.png)
> 
> The edge case condition consists of two parts ?
> To handle white/black colors - (hsbValues[0] == 0 && hsbValues[1] == 0) - representing hue and saturation of zero obtained for black, white or exactly grey (red=green=color) conditions
> To handle grayish colors - hsbValues[1] <= satGrayScale where satGrayScale <= 0.10 . For any given hue and brightness, a saturation of less than or equal to 10% represents grayish tint colors.
> (The second case was added to accommodate grayish focus ring color returned by system when Accent color = Graphite.  The returned color is not exactly gray but grayish (r=135, g=135, b=140)). 
> To accommodate a more generic case of grayish colors, the satGrayScale has a threshold or buffer of 0.10 or 10%. 
> 
> Used the following resources to test out different grayish colors and optimal saturation offsets used in  `deriveLighterFocusRing()`.
> 
> - [RapidTables](https://www.rapidtables.com/convert/color/rgb-to-hsl.html) 
> - [Colorizer](http://colorizer.org/).
> - [Chart Link](https://codepen.io/HunorMarton/details/eWvewo)
> 
> A test case is added to compare the RGB difference between the original focus ring color & selection background and the new focus ring color & selection background.
> 
> PS: The native L&F (Mac OS) and Swing L&F for JTable cell tabbing differs (on native tables the cell background turns white on focus with a cell focus ring). Since the background for Swing tables can be set by users and also overridden by subclassing `DefaultTableCellRenderer`, and to adhere to current implementation of Swing, the white cell background changes are not incorporated. Only the Focus Ring/ Cell Highlighter is made more prominent.

Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:

 - Merge branch 'master' into focusRing_7124282
 - chnaged variable name
 - added new color to CSystemColors.m - CELL_HIGHLIGHT_COLOR
 - Merge branch 'master' into focusRing_7124282
 - added new type property and changed method name
 - Merge branch 'master' into focusRing_7124282
 - added more generic condition for edge case and formatted line lengths
 - Merge branch 'openjdk:master' into focusRing_7124282
 - on-the-fly focus ring color changes added
 - updated deriveContrastFocusRing method
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/37279529...e82a1ca0

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7768/files
  - new: https://git.openjdk.java.net/jdk/pull/7768/files/a1c17b7a..e82a1ca0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7768&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7768&range=11-12

  Stats: 34367 lines in 1328 files changed: 23140 ins; 5225 del; 6002 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7768/head:pull/7768

PR: https://git.openjdk.java.net/jdk/pull/7768


From achung at openjdk.java.net  Wed Apr 27 04:37:45 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 27 Apr 2022 04:37:45 GMT
Subject: Integrated: 8198622: java/awt/Focus/TypeAhead/TestFocusFreeze.java
 fails on mac
In-Reply-To: <8guUkZCRSqeoI9P6-bxBTJjWgQuw_nQbLcfuUeUv3MA=.0fffd884-dff4-4bdc-a522-be7cf921a72c@github.com>
References: <8guUkZCRSqeoI9P6-bxBTJjWgQuw_nQbLcfuUeUv3MA=.0fffd884-dff4-4bdc-a522-be7cf921a72c@github.com>
Message-ID: <CCccOJYJgK_XCfPznBXUIy4zA-jdxExR0-IyQk6MXso=.d10cf7e5-0a91-4e12-a3ac-89a098e31e4d@github.com>

On Thu, 14 Apr 2022 21:12:07 GMT, Alisen Chung <achung at openjdk.org> wrote:

> test passes, so removing from problem list

This pull request has now been integrated.

Changeset: cc89f1bc
Author:    Alisen Chung <achung at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cc89f1bc618c6199030bd7cd1df050a175e13b4b
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8198622: java/awt/Focus/TypeAhead/TestFocusFreeze.java fails on mac
6447537: EnqueueWithDialogTest & TestFocusFreeze fail

Reviewed-by: jdv

-------------

PR: https://git.openjdk.java.net/jdk/pull/8254


From prr at openjdk.java.net  Wed Apr 27 04:39:43 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 27 Apr 2022 04:39:43 GMT
Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int)
 [v4]
In-Reply-To: <zFlFjdt_WK9VyWsAxqnfhvu-MmJe1IKc7WtyBNkPE5A=.ec807db1-ad90-4e27-99d7-8a1ea145aa71@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
 <zFlFjdt_WK9VyWsAxqnfhvu-MmJe1IKc7WtyBNkPE5A=.ec807db1-ad90-4e27-99d7-8a1ea145aa71@github.com>
Message-ID: <S9LU83ceTWEKtLvzA4D63u3Qysv4rk6f83rZ7QvfR5E=.936ea9b1-c42b-47c7-8a98-4c8803c67fe8@github.com>

On Sat, 23 Apr 2022 14:34:58 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> These are the changes that too many to be reviewed in 8186958, thus split some of them out.
>
> XenoAmess has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - maintains compatibility with jdk1.4 for TextTests
>  - fix missed space after '='

I'm getting a bit tired of seeing these JDK wide changes with lots of files touched.
Delete all changes in desktop from this PR and re-submit them as a separate PR.

Also do not change J2DBench. We deliberately avoid using new API so that we can take it and
run it on very old JDK versions to help track regressions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8301


From jdv at openjdk.java.net  Wed Apr 27 04:49:41 2022
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 27 Apr 2022 04:49:41 GMT
Subject: RFR: 8208565: [TEST_BUG]
 javax\swing\PopupFactory\6276087\NonOpaquePopupMenuTest.java throws NPE
In-Reply-To: <DmXd07y2BGuoEk_ocIftawU6FoCTUfzwmuaSxa9px2M=.018977f0-14c1-41f3-be46-a3d430b37773@github.com>
References: <DmXd07y2BGuoEk_ocIftawU6FoCTUfzwmuaSxa9px2M=.018977f0-14c1-41f3-be46-a3d430b37773@github.com>
Message-ID: <9BUZD6ZFkDUkMSIKxFXvaMeE4rrBr5pKhzij-kf382U=.99158d34-13be-48d5-8c13-91cc8e02f68d@github.com>

On Mon, 18 Apr 2022 07:11:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing in the past owing to NPE while accessing JMenu probably owing to fact the test did not wait for UI to be visible before starting the test, so added a delay after the frame is made visible. Also, added disposal of frame.
> Also, it seems JDK-8213535 fix might be having a positive impact on this test.
> 
> Several iterations of this test in all platforms have passed (link in JBS).

We should link JDK-8065099 also in this PR. As we are de-problemlisting that bug also.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8282


From duke at openjdk.java.net  Wed Apr 27 05:18:43 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 27 Apr 2022 05:18:43 GMT
Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int)
 [v4]
In-Reply-To: <S9LU83ceTWEKtLvzA4D63u3Qysv4rk6f83rZ7QvfR5E=.936ea9b1-c42b-47c7-8a98-4c8803c67fe8@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
 <zFlFjdt_WK9VyWsAxqnfhvu-MmJe1IKc7WtyBNkPE5A=.ec807db1-ad90-4e27-99d7-8a1ea145aa71@github.com>
 <S9LU83ceTWEKtLvzA4D63u3Qysv4rk6f83rZ7QvfR5E=.936ea9b1-c42b-47c7-8a98-4c8803c67fe8@github.com>
Message-ID: <xW_IMRaU3A70QAxx5vnH990FVkxQnTq1EAf-F7rz3Nw=.17ca4b0e-ee2b-45bb-8cd1-c380bb6a0990@github.com>

On Wed, 27 Apr 2022 04:36:37 GMT, Phil Race <prr at openjdk.org> wrote:

> I'm getting a bit tired of seeing these JDK wide changes with lots of files touched. 

@prrace

I'm also a bit tired of seeing so many amazing mis-use in existed codes in jdk. 

In some place I even see somebody creates a HashMap with factor = 10.

I felt my eyes widen and likes seeing a new world or something, then I suddenly notice that he the writer might not have the ability to use HashMap, but use it just as HashTable.

Nevermind.

> Delete all changes in desktop from this PR and re-submit them as a separate PR.
> 
> Also do not change J2DBench. We deliberately avoid using new API so that we can take it and run it on very old JDK versions to help track regressions.

Will do 10+ hours later when I off work.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8301


From jdv at openjdk.java.net  Wed Apr 27 05:19:41 2022
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 27 Apr 2022 05:19:41 GMT
Subject: RFR: 8208565: [TEST_BUG]
 javax\swing\PopupFactory\6276087\NonOpaquePopupMenuTest.java throws NPE
In-Reply-To: <DmXd07y2BGuoEk_ocIftawU6FoCTUfzwmuaSxa9px2M=.018977f0-14c1-41f3-be46-a3d430b37773@github.com>
References: <DmXd07y2BGuoEk_ocIftawU6FoCTUfzwmuaSxa9px2M=.018977f0-14c1-41f3-be46-a3d430b37773@github.com>
Message-ID: <yaQ-l0Xx5eIazAeWXa6_6ubC3iUPmlVjPPa05BXUVWQ=.a8c51e23-043a-418e-9758-672fc7025400@github.com>

On Mon, 18 Apr 2022 07:11:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing in the past owing to NPE while accessing JMenu probably owing to fact the test did not wait for UI to be visible before starting the test, so added a delay after the frame is made visible. Also, added disposal of frame.
> Also, it seems JDK-8213535 fix might be having a positive impact on this test.
> 
> Several iterations of this test in all platforms have passed (link in JBS).

Marked as reviewed by jdv (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8282


From psadhukhan at openjdk.java.net  Wed Apr 27 06:48:49 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 27 Apr 2022 06:48:49 GMT
Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the
 highlight border is the same color as the cell. [v13]
In-Reply-To: <14wuJKRV_wzf0QtTpOODhGOghNcbGpHqN3daYz_wDJU=.90c0cc59-d36b-4ab9-ac1e-13c2bf965a1b@github.com>
References: <mN2x3SSgi7yW6jfXruikl9rw55awKLh2_z_uAWVN6eU=.d65f94b4-4075-4970-a80b-0478378f4d48@github.com>
 <14wuJKRV_wzf0QtTpOODhGOghNcbGpHqN3daYz_wDJU=.90c0cc59-d36b-4ab9-ac1e-13c2bf965a1b@github.com>
Message-ID: <H2tAx8-agXDimuolGm7YvIyweTtKXUSXdEXn58PEzcM=.7a2cb47b-f4f5-4a57-ba14-d816ae9d427e@github.com>

On Wed, 27 Apr 2022 04:36:27 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> Previously while tabbing through the JTable cell, the cell highlighter/focus ring was not visible against the selection background. 
>> 
>> Changes are made to Aqua LAF to derive a lighter focus ring color by changing saturation and setting brightness component to 100% of original focus ring color so that it is visible while tabbing through `JTable` cells. A new method is added for this purpose which takes in `focusRingColor`, does adjustment to saturation and brightness and returns a new focus ring color. There are edge cases where the HSB transformation does not yield the right focus ring color, for these cases a default color is returned.
>> 
>> **Edge Cases**
>> ![image](https://user-images.githubusercontent.com/95945681/161360456-3929acf1-282b-4c2b-95d1-1d5707c1e238.png)
>> 
>> The edge case condition consists of two parts ?
>> To handle white/black colors - (hsbValues[0] == 0 && hsbValues[1] == 0) - representing hue and saturation of zero obtained for black, white or exactly grey (red=green=color) conditions
>> To handle grayish colors - hsbValues[1] <= satGrayScale where satGrayScale <= 0.10 . For any given hue and brightness, a saturation of less than or equal to 10% represents grayish tint colors.
>> (The second case was added to accommodate grayish focus ring color returned by system when Accent color = Graphite.  The returned color is not exactly gray but grayish (r=135, g=135, b=140)). 
>> To accommodate a more generic case of grayish colors, the satGrayScale has a threshold or buffer of 0.10 or 10%. 
>> 
>> Used the following resources to test out different grayish colors and optimal saturation offsets used in  `deriveLighterFocusRing()`.
>> 
>> - [RapidTables](https://www.rapidtables.com/convert/color/rgb-to-hsl.html) 
>> - [Colorizer](http://colorizer.org/).
>> - [Chart Link](https://codepen.io/HunorMarton/details/eWvewo)
>> 
>> A test case is added to compare the RGB difference between the original focus ring color & selection background and the new focus ring color & selection background.
>> 
>> PS: The native L&F (Mac OS) and Swing L&F for JTable cell tabbing differs (on native tables the cell background turns white on focus with a cell focus ring). Since the background for Swing tables can be set by users and also overridden by subclassing `DefaultTableCellRenderer`, and to adhere to current implementation of Swing, the white cell background changes are not incorporated. Only the Focus Ring/ Cell Highlighter is made more prominent.
>
> Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Merge branch 'master' into focusRing_7124282
>  - chnaged variable name
>  - added new color to CSystemColors.m - CELL_HIGHLIGHT_COLOR
>  - Merge branch 'master' into focusRing_7124282
>  - added new type property and changed method name
>  - Merge branch 'master' into focusRing_7124282
>  - added more generic condition for edge case and formatted line lengths
>  - Merge branch 'openjdk:master' into focusRing_7124282
>  - on-the-fly focus ring color changes added
>  - updated deriveContrastFocusRing method
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/1475f0f5...e82a1ca0

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7768


From serb at openjdk.java.net  Wed Apr 27 07:11:37 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 27 Apr 2022 07:11:37 GMT
Subject: RFR: 8285687 : Remove jtreg tag manual=yesno for
 ava/awt/print/PrinterJob/PageRangesDlgTest.java
In-Reply-To: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com>
References: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com>
Message-ID: <lRXG5HvypGnJC1fKGHQ2HbiiobpIW0irWCiTzGGDFs0=.c8db3c61-767a-4d40-8787-7fd418562236@github.com>

On Wed, 27 Apr 2022 00:06:41 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> 1) Fixed Parser error by removing  yesno from @run main/manual=yesno 
> 2) Used PassFaileJFrame to show the test instruction to the user instead of printing the test instruction on the console or jtreg log file. 
> 3) If printer is not configured then mark the test as passed.
> 
> @shurymury 
> @aivanov-jdk

The question about this and other tests is, should the test pass if the printer is not installed? I guess the printer is one of the pre-requirements for such tests and it should be configured properly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8412


From serb at openjdk.java.net  Wed Apr 27 07:14:44 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 27 Apr 2022 07:14:44 GMT
Subject: RFR: 8284888 : [macos]
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with
 "NimbusLookAndFeel] : ERROR: icon and imageIcon not same."
In-Reply-To: <1OYwEG8b8QLK1qYmQ3DIAL6XwKN-Le4-1ceI2-hX2u4=.6df0b3d6-c07e-46a6-8ecb-99ac2b65e075@github.com>
References: <pfa7K1bO4jVy0R3GkJTdMJG5eYhcdgojfPL_pILKlOA=.c2789888-0055-47a7-9c95-19f5d0cf3be0@github.com>
 <1OYwEG8b8QLK1qYmQ3DIAL6XwKN-Le4-1ceI2-hX2u4=.6df0b3d6-c07e-46a6-8ecb-99ac2b65e075@github.com>
Message-ID: <k2YkJg_Mi8gb2t6yE3Q3VYHZ5CrNkE0NHWqh0NMTWZg=.f1b0a738-fd58-488a-b595-7d743e0cd355@github.com>

On Tue, 26 Apr 2022 03:49:02 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The bug is made public. The images looks alike visually. I could not find anything wrong with rendering or robot which otherwise could have caused issue in other systems and platforms but it's only failing in this CI system (but color profile setting is ok). As per [JDK-8266247](https://bugs.openjdk.java.net/browse/JDK-8266247) which also happens in same mc, some faulty video memory is doubted. Also, it's not happening everytime but intermittently so seeing all this, I have just relaxed color check a bit

I am not sure that the color profile or something like that can be the root cause, because the test does not check an exact RGB of the color, instead, it renders the image twice and then compares, so it is strange that the results are different.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8380


From serb at openjdk.java.net  Wed Apr 27 07:18:41 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 27 Apr 2022 07:18:41 GMT
Subject: RFR: 8285305: Create an automated test for JDK-4495286
In-Reply-To: <tfMcUiiqM3zbwahwkdBXMSFXcHiCqyZoRJLZgekkagQ=.5392b0b4-bd49-400a-8bf0-aef5f1354d6e@github.com>
References: <tfMcUiiqM3zbwahwkdBXMSFXcHiCqyZoRJLZgekkagQ=.5392b0b4-bd49-400a-8bf0-aef5f1354d6e@github.com>
Message-ID: <5PGrwTbHa9J4OrhF_QE7YQOAuykcDOadl7PmH5ID5Hs=.24df96e1-5d43-4b83-a1b7-42169cb85e44@github.com>

On Thu, 21 Apr 2022 10:51:18 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Create an automated test for [JDK-4495286](https://bugs.openjdk.java.net/browse/JDK-4495286)
> 
> AccessibleJTable.setAccessibleSelction should select rows/cols when cell selection.
> When cell selection is not enabled, there is no way, using
> accessibility, to select rows or columns. It seems logical that selecting a cell
> using accessibility should have the same effect as clicking on a cell with the
> mouse. That is, if row or column selection is enabled, then selecting a cell
> should instead cause the row or column to be selected.
>  The proposed test verifies that the above behavior is fixed.
> 
> This review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The test ran successfully on Mach5 with multiple runs (40) on windows-x64, linux-x64 and macos-x64.

test/jdk/javax/accessibility/4495286/AccessibleJTableSelectionTest.java line 8:

> 6:  * under the terms of the GNU General Public License version 2 only, as
> 7: 
> 8:  * published by the Free Software Foundation.

typo

-------------

PR: https://git.openjdk.java.net/jdk/pull/8333


From psadhukhan at openjdk.java.net  Wed Apr 27 07:21:42 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 27 Apr 2022 07:21:42 GMT
Subject: Integrated: 8208565: [TEST_BUG]
 javax\swing\PopupFactory\6276087\NonOpaquePopupMenuTest.java throws NPE
In-Reply-To: <DmXd07y2BGuoEk_ocIftawU6FoCTUfzwmuaSxa9px2M=.018977f0-14c1-41f3-be46-a3d430b37773@github.com>
References: <DmXd07y2BGuoEk_ocIftawU6FoCTUfzwmuaSxa9px2M=.018977f0-14c1-41f3-be46-a3d430b37773@github.com>
Message-ID: <8TOrBbbl98DKxw5ndjPeafW2dbaNydsWqjAW9sLdHWc=.a29e7acf-988e-4ebc-96fa-18186cd5ca97@github.com>

On Mon, 18 Apr 2022 07:11:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing in the past owing to NPE while accessing JMenu probably owing to fact the test did not wait for UI to be visible before starting the test, so added a delay after the frame is made visible. Also, added disposal of frame.
> Also, it seems JDK-8213535 fix might be having a positive impact on this test.
> 
> Several iterations of this test in all platforms have passed (link in JBS).

This pull request has now been integrated.

Changeset: 72f82dd7
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/72f82dd723bf1c048d140238154580db434706e2
Stats:     84 lines in 2 files changed: 27 ins; 30 del; 27 mod

8208565: [TEST_BUG] javax\swing\PopupFactory\6276087\NonOpaquePopupMenuTest.java throws NPE
8065099: [macos] javax/swing/PopupFactory/6276087/NonOpaquePopupMenuTest.java fails: no background shine through

Reviewed-by: jdv

-------------

PR: https://git.openjdk.java.net/jdk/pull/8282


From goetz at openjdk.java.net  Wed Apr 27 07:22:46 2022
From: goetz at openjdk.java.net (Goetz Lindenmaier)
Date: Wed, 27 Apr 2022 07:22:46 GMT
Subject: RFR: 8285687 : Remove jtreg tag manual=yesno for
 ava/awt/print/PrinterJob/PageRangesDlgTest.java
In-Reply-To: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com>
References: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com>
Message-ID: <JeNoxJWQH_aglZn028m4M5B79z-A6jC5GHIgl2S3ITE=.f5641df9-0eaf-43c7-9e8b-93ea3e16428c@github.com>

On Wed, 27 Apr 2022 00:06:41 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> 1) Fixed Parser error by removing  yesno from @run main/manual=yesno 
> 2) Used PassFaileJFrame to show the test instruction to the user instead of printing the test instruction on the console or jtreg log file. 
> 3) If printer is not configured then mark the test as passed.
> 
> @shurymury 
> @aivanov-jdk

Hi,  if this needs a printer, you might want to add @key printer? Best regards, Goetz

-------------

PR: https://git.openjdk.java.net/jdk/pull/8412


From serb at openjdk.java.net  Wed Apr 27 07:33:42 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 27 Apr 2022 07:33:42 GMT
Subject: RFR: 6829250: Reg test:
 java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java fails in Windows
In-Reply-To: <qDTR6A9kV9lbOGfZGYj5S5b9_M_5zhjvfak1NWPbwPY=.dce17901-1416-411a-a31f-f3f09d78389c@github.com>
References: <qDTR6A9kV9lbOGfZGYj5S5b9_M_5zhjvfak1NWPbwPY=.dce17901-1416-411a-a31f-f3f09d78389c@github.com>
Message-ID: <YW26FpKhLBZ7OinfOhL65yoc4fpwrkXhZQAaJlA-LaQ=.e8f99138-58bc-45b1-ba18-24fa7d32db13@github.com>

On Wed, 20 Apr 2022 05:10:23 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Only check that insets of the fully expanded undecorated window is not bigger than device insets. They can be smaller, it is a normal situation.

I as far as I remember the same behavior was on old windows and jdk7 or even [jdk6](https://stackoverflow.com/questions/7403584/does-jframe-setextendedstatemaximized-both-work-with-undecorated-frames), the root cause is that awt does not support the "MAXIMIZED_BOTH"/etc states for the undecorated frames, we should implement it similar to this https://bugs.openjdk.java.net/browse/JDK-8176359

-------------

PR: https://git.openjdk.java.net/jdk/pull/8314


From serb at openjdk.java.net  Wed Apr 27 07:37:02 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 27 Apr 2022 07:37:02 GMT
Subject: RFR: 8274597: Some of the dnd tests time out and fail
 intermittently [v2]
In-Reply-To: <-M3RkI7ibFy3E3pyMdIyr-7-WWbZQXFo_4no53mvgDY=.761ad3d4-ff6c-4453-a328-173492e14616@github.com>
References: <PKtuBdvWgS96mNNJUmJbDu4WHk7yfGMXrXVahFBjio8=.25fcec82-0939-43b0-adeb-a6c1c6d9fe2f@github.com>
 <-M3RkI7ibFy3E3pyMdIyr-7-WWbZQXFo_4no53mvgDY=.761ad3d4-ff6c-4453-a328-173492e14616@github.com>
Message-ID: <xa8ad8NPar2QsdRJyN_YhdEuxUFBPgtCvxW061CxsN4=.f580b1bf-a53e-4dfc-b221-1bc316b2b4c8@github.com>

On Wed, 20 Apr 2022 13:28:17 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> These dnd tests fails with a time out intermittently in some machines(mostly Windows 11) which creates frequent noise in CI.
>> 1. java/awt/dnd/AcceptDropMultipleTimes/AcceptDropMultipleTimes.java
>> 2. java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java
>> 3. java/awt/dnd/DropTargetEnterExitTest/ExtraDragEnterTest.java
>> 
>> Issue :
>> These tests are using the Util.drag() method and there was no robot.delay() added between different mouse actions in this method. This could potentially make tests using this method unstable.
>> 
>> Fix:
>> Adding a small auto delay of 100ms to fix this.
>> 
>> Testing:
>> 1. All the three tests are run 15 times per platform.
>> 2. All the tests in java/awt/dnd package run 5 times per platform
>> 3. All the three tests are run 5 times specifically on Windows 11 platform.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added blank line at end of file

Why do these tests timeout? is it possible that we can get a deadlock there?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8316


From psadhukhan at openjdk.java.net  Wed Apr 27 07:38:39 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 27 Apr 2022 07:38:39 GMT
Subject: RFR: 8284888 : [macos]
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with
 "NimbusLookAndFeel] : ERROR: icon and imageIcon not same."
In-Reply-To: <k2YkJg_Mi8gb2t6yE3Q3VYHZ5CrNkE0NHWqh0NMTWZg=.f1b0a738-fd58-488a-b595-7d743e0cd355@github.com>
References: <pfa7K1bO4jVy0R3GkJTdMJG5eYhcdgojfPL_pILKlOA=.c2789888-0055-47a7-9c95-19f5d0cf3be0@github.com>
 <1OYwEG8b8QLK1qYmQ3DIAL6XwKN-Le4-1ceI2-hX2u4=.6df0b3d6-c07e-46a6-8ecb-99ac2b65e075@github.com>
 <k2YkJg_Mi8gb2t6yE3Q3VYHZ5CrNkE0NHWqh0NMTWZg=.f1b0a738-fd58-488a-b595-7d743e0cd355@github.com>
Message-ID: <YDw1aahmhxdF-lXm-uHjCW4Gt46D8VGZ9f02a8pb56o=.b2b8c153-0fd4-4c46-8733-4017b5108baf@github.com>

On Wed, 27 Apr 2022 07:11:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > The bug is made public. The images looks alike visually. I could not find anything wrong with rendering or robot which otherwise could have caused issue in other systems and platforms but it's only failing in this CI system (but color profile setting is ok). As per [JDK-8266247](https://bugs.openjdk.java.net/browse/JDK-8266247) which also happens in same mc, some faulty video memory is doubted. Also, it's not happening everytime but intermittently so seeing all this, I have just relaxed color check a bit
> 
> I am not sure that the color profile or something like that can be the root cause, because the test does not check an exact RGB of the color, instead, it renders the image twice and then compares, so it is strange that the results are different.

Not sure I understand. It does not render same image twice but it renders an `ImageIcon `and an `Icon `and compare the bufferedimage of those 2 so I guess it alright to not have exact color check                  `   if (red1 != red2 || green1 != green2 || blue1 != blue2) {` and rely on color tolerance which we have in many tests involving bufferedimages..

-------------

PR: https://git.openjdk.java.net/jdk/pull/8380


From serb at openjdk.java.net  Wed Apr 27 07:39:43 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 27 Apr 2022 07:39:43 GMT
Subject: RFR: 8284077: Create an automated test for JDK-4170173 [v2]
In-Reply-To: <Ae-7tZG1zyizB1FXzbtqkgOsw2gJ5Y0ShLNFHCUu4hE=.578127b3-ef9d-4936-8338-14bf12b28e59@github.com>
References: <8iul_waSMDD6G1oVVmwPtW89ihAc6YoMFrTR1-XFmmw=.7802104e-60cb-4b90-9ef5-cc479d3f5a78@github.com>
 <Ae-7tZG1zyizB1FXzbtqkgOsw2gJ5Y0ShLNFHCUu4hE=.578127b3-ef9d-4936-8338-14bf12b28e59@github.com>
Message-ID: <R3Ad18AFN9PbK5C5gK_nYXoaY-t3mr0V7neb2BGLZ0E=.4584835e-650a-4804-a447-1eb60546f591@github.com>

On Tue, 12 Apr 2022 06:09:35 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4170173](https://bugs.openjdk.java.net/browse/JDK-4170173)
>> 
>> Issue
>> JTextComponent.AccessibleJTextComponent.getAfterIndex(int part, int index) works incorrectly, when 'part' parameter is AccessibleText.WORD.
>> It returns a space (" ") instead of the correct word.
>> 
>> The test verifies the fix for this behavior by checking the getAfterIndex for AccessibleText.CHARACTER,AccessibleText.WORD,AccessibleText.SENTENCE for the components JTextField, JTextArea, JEditorPane.
>> 
>> While working on this test case there was a related bug relevant to this [JDK-4170174](https://bugs.openjdk.java.net/browse/JDK-4170174) 
>> This is marked as duplicate, addressess a similar issue.
>> It indicates that JTextComponent.AccessibleJTextComponent.getBeforeIndex(int part, int index) works incorrectly, when part parameter is AccessibleText.WORD.
>> It returns a space (" ") instead of correct word.
>> 
>> Hence an additional test was added for this, for verifying the behavior of getBeforeIndex.
>> AccessibleText.CHARACTER,AccessibleText.WORD,AccessibleText.SENTENCE for the components JTextField, JTextArea, JEditorPane.
>> 
>> The two tests have multiple distinct assertions. For this reason, as well as for maintainability, the two were not clubbed into a single test.
>> However, the two tests are still similar in the functional flow of the code and the functionality they are testing as well - hence they have been clubbed into a single review.
>> This review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The tests ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comments Fixed: Simplied test

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8138


From serb at openjdk.java.net  Wed Apr 27 07:42:44 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 27 Apr 2022 07:42:44 GMT
Subject: RFR: 8283624: Create an automated regression test for RFE-4390885
 [v3]
In-Reply-To: <ulXuyM6cAT0OpsHOXQQCYcMFq29lzpwg66Jn8WHC5pY=.ba10753a-f153-4abb-965d-460660da17f7@github.com>
References: <DfOvs0ck3_ucgdZG8gdlmXPriMoEM9-RjaveRlmRZYA=.b6690b6a-4a51-4c98-b5ee-6409fe4b0f84@github.com>
 <ulXuyM6cAT0OpsHOXQQCYcMFq29lzpwg66Jn8WHC5pY=.ba10753a-f153-4abb-965d-460660da17f7@github.com>
Message-ID: <k4OIcldKdlGKvDlImZmq2pYpTlW-9opU3MMP1MaTqi4=.005427c6-3b63-4346-add2-a1ada74f5be6@github.com>

On Wed, 20 Apr 2022 07:14:33 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Write a regression test for [JDK-4390885](https://bugs.openjdk.java.net/browse/JDK-4390885) Enhancement Request.
>> 
>> Issue:
>> Please add the ability to set the location of a JFileChooser. This might be a
>> bug, but JFileChooser.setLocation() has no effect when
>> JFileChooser.showXXXXDialog() is called. This is becoming very important as the
>> popularity of multiple monitors is increasing. These dialogs show up on the
>> wrong monitor which is really annoying. Also due to bug #4189244 I am unable to
>> avoid painting problems by positioning the dialog away from the menu item that
>> initiated it.
>> 
>> Fix:
>> Now it's possible to set the location of Dialog in JFileChooser.
>> 
>> Testing:
>> 1. Tested in Mach5 10 times per platform(macos,linux,windows) and got all Pass.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed some duplicate code

test/jdk/javax/swing/JFileChooser/JFileChooserSetLocationTest.java line 103:

> 101:                         () -> pt.set(panel.getLocationOnScreen()));
> 102:                 Point panel_loc = pt.get();
> 103:                 xIn = (panel_loc.x + panel.getSize().width) / 2;

The getSize should be called on EDT as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7996


From serb at openjdk.java.net  Wed Apr 27 07:44:46 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 27 Apr 2022 07:44:46 GMT
Subject: RFR: JDK-8282933: Create a test for JDK-4529616 [v4]
In-Reply-To: <H2pSp3zG5j_dE6MBWYMTfLlKdBxJBhlaq3rmlwptvdY=.5f6096c0-efd9-465f-b69a-0de8dc6333d8@github.com>
References: <3d_szd4R6oyDqof-g7sLsV_wkAzuEuma-aXiiUZ03Zw=.6579f560-f11e-4bea-a292-dfcee111a246@github.com>
 <H2pSp3zG5j_dE6MBWYMTfLlKdBxJBhlaq3rmlwptvdY=.5f6096c0-efd9-465f-b69a-0de8dc6333d8@github.com>
Message-ID: <ufaIhs7GIH3iEFXNJBgzE8hykqadPhnJg68f9SpMgms=.ff4d919f-f6f4-414f-9df8-5d301d31dbad@github.com>

On Thu, 7 Apr 2022 07:02:18 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> JDK-8282933: Create a test for JDK-4529616 
>> AccessibleJTableCell.isShowing() returns false when the cell is actually on
>> the screen.
>> The test validates the fix for the above issue by verifying that the isShowing call returns true when invoked via the  accessiblity context.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282933: Whitespace issue fixed

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7783


From serb at openjdk.java.net  Wed Apr 27 07:45:46 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 27 Apr 2022 07:45:46 GMT
Subject: RFR: JDK-8282777: Create a Regression test for JDK-4515031 [v3]
In-Reply-To: <dQC9zgpn-bZxlGt1-tES09zUq849yPRfM_BcCW7zrqg=.ae67997b-49dc-4b67-a90c-bf7e4d0592c8@github.com>
References: <D8K1EcGCjhQQzplHsgYncKPvGmSPhrAs7RNDIl_pQlo=.e8d60f67-9cf4-4ac7-957b-ddbecffc85de@github.com>
 <dQC9zgpn-bZxlGt1-tES09zUq849yPRfM_BcCW7zrqg=.ae67997b-49dc-4b67-a90c-bf7e4d0592c8@github.com>
Message-ID: <eJsaNzOdssWBPOxi6FmR7VCaEqzzwDcAvEfFV4hRQXU=.072d986d-5c45-4063-958d-2e7083256e0c@github.com>

On Wed, 30 Mar 2022 10:05:22 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a Regression test for [JDK-4515031](https://bugs.openjdk.java.net/browse/JDK-4515031)
>> 
>> The issue indicates the need for a a getAccessibleDescription being implemented for the JFileChooser.
>> The test added verifies the same.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comments Fixed: Button on EDT, split long lines, volatile description string

Please confirm that mach5 is green after this fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7738


From tnakamura at openjdk.java.net  Wed Apr 27 07:49:46 2022
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Wed, 27 Apr 2022 07:49:46 GMT
Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong
 size [v2]
In-Reply-To: <INZ7eXvOf4rTqh3KQ6HCHa9REoaHhQbMzPWeiW3lf24=.3f1df644-95aa-4925-838b-4f3ed86769bf@github.com>
References: <z72T3X_wgR6K7BdFL7Tqg8t6GXbJh-Vk0pDGCJjUnEE=.ba87e570-fc0b-45d5-8099-9ffeeeb09fc5@github.com>
 <SAu4OKejClHuOK9uEAFVXIKnqfGBcfn3MtqNhuMoCPM=.fba07a11-93eb-494d-b098-62bd2b4fd107@github.com>
 <INZ7eXvOf4rTqh3KQ6HCHa9REoaHhQbMzPWeiW3lf24=.3f1df644-95aa-4925-838b-4f3ed86769bf@github.com>
Message-ID: <oRmz4ufhsy5mA0aDCE-OkztArV4575BotTVqM_fNuq8=.9a1be0da-ac23-485b-9aa6-7fe84f129709@github.com>

On Tue, 26 Apr 2022 16:50:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Moved the fix to WFontConfiguration
>
> Hmm. I'm not sure I'm seeing what you see in the native app. 
> There the Latin font is larger than the JDK case, and the Japanese font is smaller than the JDK case,
> and they end up about the same size as each other.
> Also you have to remember if you select "8 pt" in a windows native app, that (at 100% scale) is at 96dpi, not 72dpi.
> So that's 96/72 times the size of the Java  8 pt font. 8 * 96 / 72 will round up to 11 pixels in native, not the 8 pixels in Java.
> 
> Also JDK - in theory - controls the exact fonts that are used even in a TextField.
> 
> I'd like to see this resolved but I'm still not feeling like I have a sufficient understanding.

@prrace
Sorry for your confusion. Please allow me to explain with 30-point case. That's too small Japanese characters than alphabets.
(With 8-point case, the native application clipped upper side, but I couldn't find the reason.)

Java code:
`t.setFont(new Font(Font.SERIF, Font.PLAIN, 30));`
Native code:
`CreateFont(-30, 0, 0, 0, 0, 0, 0, 0, ANSI_CHARSET, 0, 0, 0, 0, _TEXT("Times New Roman"));`

These codes displayed the exact same glyphs. Screen shot was attached in JBS.

> Also JDK - in theory - controls the exact fonts that are used even in a TextField.

Well, I think TextField sets only one font (HFONT) via `AwtTextComponent::SetFont(AwtFont* font)`.
`spyxx` command recorded only that WM_SETFONT event.

So, we need to pick up a proper font from fontconfig file.
Now, unexpected encoding was set and unexpected font was picked up.

Expected native call:
`CreateFont(-30, 0, 0, 0, 0, 0, 0, 0, SHIFTJIS_CHARSET, 0, 0, 0, 0, _TEXT("MS Mincho"));`

-------------

PR: https://git.openjdk.java.net/jdk/pull/8329


From smandalika at openjdk.java.net  Wed Apr 27 08:02:20 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 27 Apr 2022 08:02:20 GMT
Subject: RFR: 8285693: Create an automated test for JDK-4702199
Message-ID: <MTg-FeYK5rgMiV-6xNy3f2TU86wShnNCyQXNNqTD_m0=.a2ec3667-5e74-43e4-8f38-215cec53443b@github.com>

reate an automated test for [JDK-4702199](https://bugs.openjdk.java.net/browse/JDK-4702199)

In order for spatial Braille to work and screen reader "review mode", we need bounding rectangle information for all text on the screen, and also the ability to get text substrings. StarOffice 6.1, Netscape and GNOME accessibility also require this new interface for describing text in their applications. This new interface is required for accessibility to StarOffice 6.1, Netscape and GNOME applications as required by Section 508

The solution is to define a new interface and related two helper classes.
AccessibleExtendedText,
AccessibleTextSequence.
AccessibleAttributeSequence

The test validates the public fields of the above classes.
This review is for migrating tests from a closed test suite to open.

Testing:
The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

-------------

Commit messages:
 - 8285693: Create an automated test for JDK-4702199

Changes: https://git.openjdk.java.net/jdk/pull/8416/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8416&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285693
  Stats: 96 lines in 1 file changed: 96 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8416.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8416/head:pull/8416

PR: https://git.openjdk.java.net/jdk/pull/8416


From smandalika at openjdk.java.net  Wed Apr 27 08:02:43 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 27 Apr 2022 08:02:43 GMT
Subject: RFR: 8284077: Create an automated test for JDK-4170173 [v2]
In-Reply-To: <R3Ad18AFN9PbK5C5gK_nYXoaY-t3mr0V7neb2BGLZ0E=.4584835e-650a-4804-a447-1eb60546f591@github.com>
References: <8iul_waSMDD6G1oVVmwPtW89ihAc6YoMFrTR1-XFmmw=.7802104e-60cb-4b90-9ef5-cc479d3f5a78@github.com>
 <Ae-7tZG1zyizB1FXzbtqkgOsw2gJ5Y0ShLNFHCUu4hE=.578127b3-ef9d-4936-8338-14bf12b28e59@github.com>
 <R3Ad18AFN9PbK5C5gK_nYXoaY-t3mr0V7neb2BGLZ0E=.4584835e-650a-4804-a447-1eb60546f591@github.com>
Message-ID: <PJctj7S717MfGya2XbI6k7Jf1thUnbsme6i4qblqZnY=.e3458c83-6dc2-4730-8d89-d55f2bcf8ab9@github.com>

On Wed, 27 Apr 2022 07:36:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review Comments Fixed: Simplied test
>
> Marked as reviewed by serb (Reviewer).

@mrserb Can you please sponsor this PR?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8138


From smandalika at openjdk.java.net  Wed Apr 27 08:02:46 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 27 Apr 2022 08:02:46 GMT
Subject: RFR: JDK-8282933: Create a test for JDK-4529616 [v4]
In-Reply-To: <ufaIhs7GIH3iEFXNJBgzE8hykqadPhnJg68f9SpMgms=.ff4d919f-f6f4-414f-9df8-5d301d31dbad@github.com>
References: <3d_szd4R6oyDqof-g7sLsV_wkAzuEuma-aXiiUZ03Zw=.6579f560-f11e-4bea-a292-dfcee111a246@github.com>
 <H2pSp3zG5j_dE6MBWYMTfLlKdBxJBhlaq3rmlwptvdY=.5f6096c0-efd9-465f-b69a-0de8dc6333d8@github.com>
 <ufaIhs7GIH3iEFXNJBgzE8hykqadPhnJg68f9SpMgms=.ff4d919f-f6f4-414f-9df8-5d301d31dbad@github.com>
Message-ID: <OVljy3amUiyiizUD8a4VA-fg45cZIKdmvW7pU7Uf86Q=.3f29fb89-0433-459e-b858-6c47943650e8@github.com>

On Wed, 27 Apr 2022 07:41:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8282933: Whitespace issue fixed
>
> Marked as reviewed by serb (Reviewer).

@mrserb Can you please sponsor this PR?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7783


From smandalika at openjdk.java.net  Wed Apr 27 08:08:32 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 27 Apr 2022 08:08:32 GMT
Subject: RFR: 8285305: Create an automated test for JDK-4495286 [v2]
In-Reply-To: <tfMcUiiqM3zbwahwkdBXMSFXcHiCqyZoRJLZgekkagQ=.5392b0b4-bd49-400a-8bf0-aef5f1354d6e@github.com>
References: <tfMcUiiqM3zbwahwkdBXMSFXcHiCqyZoRJLZgekkagQ=.5392b0b4-bd49-400a-8bf0-aef5f1354d6e@github.com>
Message-ID: <Y-LI_FvW_21e_o3NoDsdi5eagXRSkdt-uPbL_SLwMjg=.9e11f51d-65db-4252-93ab-ac37fb5c8254@github.com>

> Create an automated test for [JDK-4495286](https://bugs.openjdk.java.net/browse/JDK-4495286)
> 
> AccessibleJTable.setAccessibleSelction should select rows/cols when cell selection.
> When cell selection is not enabled, there is no way, using
> accessibility, to select rows or columns. It seems logical that selecting a cell
> using accessibility should have the same effect as clicking on a cell with the
> mouse. That is, if row or column selection is enabled, then selecting a cell
> should instead cause the row or column to be selected.
>  The proposed test verifies that the above behavior is fixed.
> 
> This review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The test ran successfully on Mach5 with multiple runs (40) on windows-x64, linux-x64 and macos-x64.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed: Typo in Copyright Header

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8333/files
  - new: https://git.openjdk.java.net/jdk/pull/8333/files/3c76b2af..98c96eb4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8333&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8333&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8333.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8333/head:pull/8333

PR: https://git.openjdk.java.net/jdk/pull/8333


From smandalika at openjdk.java.net  Wed Apr 27 08:12:43 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 27 Apr 2022 08:12:43 GMT
Subject: RFR: JDK-8282777: Create a Regression test for JDK-4515031 [v3]
In-Reply-To: <dQC9zgpn-bZxlGt1-tES09zUq849yPRfM_BcCW7zrqg=.ae67997b-49dc-4b67-a90c-bf7e4d0592c8@github.com>
References: <D8K1EcGCjhQQzplHsgYncKPvGmSPhrAs7RNDIl_pQlo=.e8d60f67-9cf4-4ac7-957b-ddbecffc85de@github.com>
 <dQC9zgpn-bZxlGt1-tES09zUq849yPRfM_BcCW7zrqg=.ae67997b-49dc-4b67-a90c-bf7e4d0592c8@github.com>
Message-ID: <TPO5sC-Oj1N63woZYVy-iFFy6paoTR0UOzJ6pkYr8KI=.970ee33f-1479-4f5d-9070-59521dbff593@github.com>

On Wed, 30 Mar 2022 10:05:22 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a Regression test for [JDK-4515031](https://bugs.openjdk.java.net/browse/JDK-4515031)
>> 
>> The issue indicates the need for a a getAccessibleDescription being implemented for the JFileChooser.
>> The test added verifies the same.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comments Fixed: Button on EDT, split long lines, volatile description string

Testing:
The tests ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7738


From smandalika at openjdk.java.net  Wed Apr 27 08:49:36 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 27 Apr 2022 08:49:36 GMT
Subject: RFR: 8285305: Create an automated test for JDK-4495286 [v2]
In-Reply-To: <5PGrwTbHa9J4OrhF_QE7YQOAuykcDOadl7PmH5ID5Hs=.24df96e1-5d43-4b83-a1b7-42169cb85e44@github.com>
References: <tfMcUiiqM3zbwahwkdBXMSFXcHiCqyZoRJLZgekkagQ=.5392b0b4-bd49-400a-8bf0-aef5f1354d6e@github.com>
 <5PGrwTbHa9J4OrhF_QE7YQOAuykcDOadl7PmH5ID5Hs=.24df96e1-5d43-4b83-a1b7-42169cb85e44@github.com>
Message-ID: <i3PPL61nd320yveQ1p2L_pwGUS2nYf-J-6CIhgbxfyU=.566e9f5c-fa25-4a37-8458-deb0b0fa190a@github.com>

On Wed, 27 Apr 2022 07:13:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments fixed: Typo in Copyright Header
>
> test/jdk/javax/accessibility/4495286/AccessibleJTableSelectionTest.java line 8:
> 
>> 6:  * under the terms of the GNU General Public License version 2 only, as
>> 7: 
>> 8:  * published by the Free Software Foundation.
> 
> typo

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8333


From mvs at openjdk.java.net  Wed Apr 27 10:17:16 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 27 Apr 2022 10:17:16 GMT
Subject: RFR: 8283624: Create an automated regression test for RFE-4390885
 [v4]
In-Reply-To: <DfOvs0ck3_ucgdZG8gdlmXPriMoEM9-RjaveRlmRZYA=.b6690b6a-4a51-4c98-b5ee-6409fe4b0f84@github.com>
References: <DfOvs0ck3_ucgdZG8gdlmXPriMoEM9-RjaveRlmRZYA=.b6690b6a-4a51-4c98-b5ee-6409fe4b0f84@github.com>
Message-ID: <ua67EQsKDpRJBS8ScbjUAeQsVvTWBLMW9OSVE5YoQSg=.235836cc-c780-4c35-9072-be094952ddd4@github.com>

> Write a regression test for [JDK-4390885](https://bugs.openjdk.java.net/browse/JDK-4390885) Enhancement Request.
> 
> Issue:
> Please add the ability to set the location of a JFileChooser. This might be a
> bug, but JFileChooser.setLocation() has no effect when
> JFileChooser.showXXXXDialog() is called. This is becoming very important as the
> popularity of multiple monitors is increasing. These dialogs show up on the
> wrong monitor which is really annoying. Also due to bug #4189244 I am unable to
> avoid painting problems by positioning the dialog away from the menu item that
> initiated it.
> 
> Fix:
> Now it's possible to set the location of Dialog in JFileChooser.
> 
> Testing:
> 1. Tested in Mach5 10 times per platform(macos,linux,windows) and got all Pass.

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Review comment fixed: Accessed panel.getSize() in EDT

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7996/files
  - new: https://git.openjdk.java.net/jdk/pull/7996/files/22e4eebc..54c4a6aa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7996&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7996&range=02-03

  Stats: 10 lines in 1 file changed: 5 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7996.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7996/head:pull/7996

PR: https://git.openjdk.java.net/jdk/pull/7996


From mvs at openjdk.java.net  Wed Apr 27 10:17:18 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 27 Apr 2022 10:17:18 GMT
Subject: RFR: 8283624: Create an automated regression test for RFE-4390885
 [v3]
In-Reply-To: <k4OIcldKdlGKvDlImZmq2pYpTlW-9opU3MMP1MaTqi4=.005427c6-3b63-4346-add2-a1ada74f5be6@github.com>
References: <DfOvs0ck3_ucgdZG8gdlmXPriMoEM9-RjaveRlmRZYA=.b6690b6a-4a51-4c98-b5ee-6409fe4b0f84@github.com>
 <ulXuyM6cAT0OpsHOXQQCYcMFq29lzpwg66Jn8WHC5pY=.ba10753a-f153-4abb-965d-460660da17f7@github.com>
 <k4OIcldKdlGKvDlImZmq2pYpTlW-9opU3MMP1MaTqi4=.005427c6-3b63-4346-add2-a1ada74f5be6@github.com>
Message-ID: <dfkoqGuVl0E0z5k5Pim-N7Mjdh6_9tNFwORjV39MJA4=.d0261f4e-7e68-43b7-8c4a-bc9875eb455c@github.com>

On Wed, 27 Apr 2022 07:38:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed some duplicate code
>
> test/jdk/javax/swing/JFileChooser/JFileChooserSetLocationTest.java line 103:
> 
>> 101:                         () -> pt.set(panel.getLocationOnScreen()));
>> 102:                 Point panel_loc = pt.get();
>> 103:                 xIn = (panel_loc.x + panel.getSize().width) / 2;
> 
> The getSize should be called on EDT as well.

Changed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7996


From dfuchs at openjdk.java.net  Wed Apr 27 10:59:43 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 27 Apr 2022 10:59:43 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces
In-Reply-To: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
Message-ID: <Yowb9HvfI12BYoNV5lO8UNm3n19-kn6QLGAqjnJPvDk=.658abf24-fbcc-4100-bc38-69e9fcc2e6cc@github.com>

On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
> 
> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
> 
> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
> 
> I'll update copyright years before pushing.

Hi Joe, just two suggestions about the javax.management changes. Otherwise looks good!

src/java.management/share/classes/javax/management/openmbean/ArrayType.java line 96:

> 94:  *
> 95:  * @param <T> the Java type that instances described by this type must
> 96:  * have.

Instead of "instances" - would it be more correct to say "array elements"?

src/java.management/share/classes/javax/management/openmbean/SimpleType.java line 60:

> 58:  * @param <T> the Java type that instances described by this type must
> 59:  * have.
> 60:  *

I would suggest to say "that values described by this type"...

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410


From mvs at openjdk.java.net  Wed Apr 27 11:03:41 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 27 Apr 2022 11:03:41 GMT
Subject: RFR: 8274597: Some of the dnd tests time out and fail
 intermittently [v2]
In-Reply-To: <xa8ad8NPar2QsdRJyN_YhdEuxUFBPgtCvxW061CxsN4=.f580b1bf-a53e-4dfc-b221-1bc316b2b4c8@github.com>
References: <PKtuBdvWgS96mNNJUmJbDu4WHk7yfGMXrXVahFBjio8=.25fcec82-0939-43b0-adeb-a6c1c6d9fe2f@github.com>
 <-M3RkI7ibFy3E3pyMdIyr-7-WWbZQXFo_4no53mvgDY=.761ad3d4-ff6c-4453-a328-173492e14616@github.com>
 <xa8ad8NPar2QsdRJyN_YhdEuxUFBPgtCvxW061CxsN4=.f580b1bf-a53e-4dfc-b221-1bc316b2b4c8@github.com>
Message-ID: <GlNM6e3_we0aTMRnYoei07YmGs-4IzXampa_HZ-chHw=.d3653467-3356-4331-bad7-d8750da4d47d@github.com>

On Wed, 27 Apr 2022 07:33:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Why do these tests timeout? is it possible that we can get a deadlock there?

This doesn't seem to be a deadlock. When there is no sufficient delay after the mouse release(dragged mouse pointer release to drop the content), the frame is getting disposed even before the drop() method gets called. So it waits for the drop() method which will never happen as the frame has been already disposed. Instead of the fix suggested here, this can be also fixed by just increasing the robot delay after mouse release to at least 100ms.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8316


From prappo at openjdk.java.net  Wed Apr 27 11:13:27 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 27 Apr 2022 11:13:27 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces
In-Reply-To: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
Message-ID: <vknck6J2mGnJrlNFGLsdkIPJz4L3Joc3kIoGdJ1PmXw=.c9f196a3-79cf-4ac3-81e8-fbacd55e7a8b@github.com>

On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
> 
> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
> 
> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
> 
> I'll update copyright years before pushing.

I note that many years ago you filed JDK-6327933, which I'm currently looking at. If implemented, many of the issues from this PR will be addressed automatically, including those in `java.util.concurrent`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410


From mvs at openjdk.java.net  Wed Apr 27 11:39:14 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Wed, 27 Apr 2022 11:39:14 GMT
Subject: RFR: 8285698: Create a test to check the focus stealing of JPopupMenu
 from JComboBox
Message-ID: <kPLwG_jUjruQ9KhzhBfvkJ1B8DvwvV9QQM_agBHz3n0=.da639f83-94e7-4fcc-9577-bd358f8f6f49@github.com>

This test verifies that showing a JPopupMenu shouldn't steal the focus out of current focused component..
This fix moves an unstable closed test to open but updated to be more comprehensive in testing multiple Look and Feels and with some stabilisation improvements. The closed test had some dependencies with some proprietary libraries which are all removed here.

Testing:
Tested using mach5 10 times per platform and got all Pass.

-------------

Commit messages:
 - 8285698: Create a test to check the focus stealing of JPopupMenu from JComboBox

Changes: https://git.openjdk.java.net/jdk/pull/8426/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8426&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285698
  Stats: 183 lines in 1 file changed: 183 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8426.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8426/head:pull/8426

PR: https://git.openjdk.java.net/jdk/pull/8426


From psadhukhan at openjdk.java.net  Wed Apr 27 12:26:44 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 27 Apr 2022 12:26:44 GMT
Subject: RFR: 8285617 : Fix
 java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java manual test
In-Reply-To: <gJfXkDtoO4VBJIFH8Drdqj-YXGwKeGPmrIq8kzIT1Ug=.5267a947-1938-4cba-a3a3-45a43b6ae135@github.com>
References: <gJfXkDtoO4VBJIFH8Drdqj-YXGwKeGPmrIq8kzIT1Ug=.5267a947-1938-4cba-a3a3-45a43b6ae135@github.com>
Message-ID: <ZG3g7wbwi4ccGBvKQ4WqJ9jzQKFoKqPt4YdOykdqHbo=.6d26775e-07ad-4a7f-86e8-cdbc75fc1884@github.com>

On Tue, 26 Apr 2022 01:44:45 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> 1) Removed yesno since test was failing with parser error due to @run main/manual=yesno 
> 2) User can't decide whether it as pass or fail after looking into the printout so add the PassFailJFrame support
> 
> @shurymury 
> @aivanov-jdk

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8395


From duke at openjdk.java.net  Wed Apr 27 12:26:44 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Wed, 27 Apr 2022 12:26:44 GMT
Subject: Integrated: 8285617 : Fix
 java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java manual test
In-Reply-To: <gJfXkDtoO4VBJIFH8Drdqj-YXGwKeGPmrIq8kzIT1Ug=.5267a947-1938-4cba-a3a3-45a43b6ae135@github.com>
References: <gJfXkDtoO4VBJIFH8Drdqj-YXGwKeGPmrIq8kzIT1Ug=.5267a947-1938-4cba-a3a3-45a43b6ae135@github.com>
Message-ID: <yKiId28c2APBokkVy6DFKNJSI_d6j6k_lvNhHkepzw8=.c9c132d3-d47d-492a-9612-46c9b72a5963@github.com>

On Tue, 26 Apr 2022 01:44:45 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> 1) Removed yesno since test was failing with parser error due to @run main/manual=yesno 
> 2) User can't decide whether it as pass or fail after looking into the printout so add the PassFailJFrame support
> 
> @shurymury 
> @aivanov-jdk

This pull request has now been integrated.

Changeset: e7c3b9de
Author:    lawrence.andrews <lawrence.andrews at oracle.com>
Committer: Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e7c3b9de649d4b28ba16844e042afcf3c89323e5
Stats:     49 lines in 1 file changed: 26 ins; 7 del; 16 mod

8285617: Fix java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java manual test

Reviewed-by: prr, psadhukhan

-------------

PR: https://git.openjdk.java.net/jdk/pull/8395


From mbaesken at openjdk.java.net  Wed Apr 27 15:05:16 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 27 Apr 2022 15:05:16 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings
Message-ID: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>

Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
Macros for Conditional Declarations
"Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."

However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).

-------------

Commit messages:
 - JDK-8285730

Changes: https://git.openjdk.java.net/jdk/pull/8428/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285730
  Stats: 14 lines in 7 files changed: 1 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8428.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8428/head:pull/8428

PR: https://git.openjdk.java.net/jdk/pull/8428


From alanb at openjdk.java.net  Wed Apr 27 15:14:43 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 27 Apr 2022 15:14:43 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings
In-Reply-To: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
Message-ID: <fb6V2fi9al6WD5-n-IlcGF5Iv9Bg1EbphIZGUnVezlQ=.fd40ece0-21ec-42f5-9669-af7cd0f47bb8@github.com>

On Wed, 27 Apr 2022 14:57:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
> Macros for Conditional Declarations
> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
> 
> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).

src/java.base/windows/native/libnio/ch/wepoll.c line 159:

> 157: 
> 158: #undef _WIN32_WINNT
> 159: #define _WIN32_WINNT 0x0601

This is 3rd party code and would prefer not change it if possible.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8428


From smandalika at openjdk.java.net  Wed Apr 27 15:28:53 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 27 Apr 2022 15:28:53 GMT
Subject: RFR: JDK-8282778: Create a regression test for JDK-4699544 [v4]
In-Reply-To: <l1DQwU-SiN176RvD-bai-VoOdZNrM-66Kzo05YqXg3c=.f02b6d75-6024-402e-86d1-f77904fa90c5@github.com>
References: <IDgBuK7aFq5DBF_2mWS-l27LMVG9XSZe-2Zl_bITg3M=.527d9ca4-e081-4ce2-b123-1f2580f5e017@github.com>
 <l1DQwU-SiN176RvD-bai-VoOdZNrM-66Kzo05YqXg3c=.f02b6d75-6024-402e-86d1-f77904fa90c5@github.com>
Message-ID: <P0csGJrJWdO6GIKIWQg53L2Cmv9zyU3kYkhZVqTxLeM=.62d1e51a-cb85-4159-9851-8f89a1ce4533@github.com>

On Tue, 12 Apr 2022 09:05:56 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a regression test for JDK-4699544
>> 
>> The subclass of javax.swing.JRootPane (AccessibleJRootPane) that implements the accessibility interface javax.accessibility.AccessibleComponent is derived from java.awt.AccessibleAWTComponent, which returns null for getAccessibleAt() because a component does not necessarily have childs.
>> 
>> The root pane always has a content pane child, so getAccessibleAt() should be overwritten by AccessibleJRootPane appropriately.
>> The test added verifies the same.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comments Fixed: removed redundant class variables

The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7739


From smandalika at openjdk.java.net  Wed Apr 27 15:28:53 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 27 Apr 2022 15:28:53 GMT
Subject: RFR: JDK-8282777: Create a Regression test for JDK-4515031 [v3]
In-Reply-To: <dQC9zgpn-bZxlGt1-tES09zUq849yPRfM_BcCW7zrqg=.ae67997b-49dc-4b67-a90c-bf7e4d0592c8@github.com>
References: <D8K1EcGCjhQQzplHsgYncKPvGmSPhrAs7RNDIl_pQlo=.e8d60f67-9cf4-4ac7-957b-ddbecffc85de@github.com>
 <dQC9zgpn-bZxlGt1-tES09zUq849yPRfM_BcCW7zrqg=.ae67997b-49dc-4b67-a90c-bf7e4d0592c8@github.com>
Message-ID: <dhJkrYmSJ2hGojkRHJjlEJGxZyU6O-OaNnzEZYe590I=.e69238ae-fcee-4357-82e4-19f656d9a9e4@github.com>

On Wed, 30 Mar 2022 10:05:22 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a Regression test for [JDK-4515031](https://bugs.openjdk.java.net/browse/JDK-4515031)
>> 
>> The issue indicates the need for a a getAccessibleDescription being implemented for the JFileChooser.
>> The test added verifies the same.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comments Fixed: Button on EDT, split long lines, volatile description string

Yes. The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7738


From smandalika at openjdk.java.net  Wed Apr 27 15:32:42 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 27 Apr 2022 15:32:42 GMT
Subject: RFR: JDK-8282933: Create a test for JDK-4529616 [v4]
In-Reply-To: <H2pSp3zG5j_dE6MBWYMTfLlKdBxJBhlaq3rmlwptvdY=.5f6096c0-efd9-465f-b69a-0de8dc6333d8@github.com>
References: <3d_szd4R6oyDqof-g7sLsV_wkAzuEuma-aXiiUZ03Zw=.6579f560-f11e-4bea-a292-dfcee111a246@github.com>
 <H2pSp3zG5j_dE6MBWYMTfLlKdBxJBhlaq3rmlwptvdY=.5f6096c0-efd9-465f-b69a-0de8dc6333d8@github.com>
Message-ID: <XYShS_4o3xHa8tgwQ_gTP2oSSDULnXLm9RwzZTWEGXM=.c9254c4e-cdc3-41c3-aa2a-565c8d29b729@github.com>

On Thu, 7 Apr 2022 07:02:18 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> JDK-8282933: Create a test for JDK-4529616 
>> AccessibleJTableCell.isShowing() returns false when the cell is actually on
>> the screen.
>> The test validates the fix for the above issue by verifying that the isShowing call returns true when invoked via the  accessiblity context.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282933: Whitespace issue fixed

The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7783


From smandalika at openjdk.java.net  Wed Apr 27 15:32:45 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 27 Apr 2022 15:32:45 GMT
Subject: RFR: 8282857: Create a regression test for JDK-4702690 [v3]
In-Reply-To: <1MCuz4h2_IMc9oR2q-DP_O5xoiS_7j1cQ8DTHaQxDlU=.a5b07c51-39fa-4c39-aa2d-74643c22cf0f@github.com>
References: <jklfp2oMIJWjzE4tz62KCLHfBqlaV0GlyZqk-wUiFHI=.7a721efc-e549-4058-819e-2785e64d9e8d@github.com>
 <1MCuz4h2_IMc9oR2q-DP_O5xoiS_7j1cQ8DTHaQxDlU=.a5b07c51-39fa-4c39-aa2d-74643c22cf0f@github.com>
Message-ID: <1XA-7n40a5bQcXiVjcsRm74Djff-vCXZ6-vI5rl7M_0=.22bbb88b-8eab-4934-bcb7-4e581c069660@github.com>

On Wed, 6 Apr 2022 07:02:25 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a regression test for [JDK-4702690](https://bugs.openjdk.java.net/browse/JDK-4702690)
>> 
>> In many cases in Swing it is possible to easily programatically determine that a JScrollBar (or two) is scrolling some JPanel (the cannonical case is a JScrollPane).
>> In these cases, when accessibility support is instantiated (e.g. the AccessibleJScrollBar is created), a Controller_For and Controled_By relation should be instantiated between the AccessibleJScrollBar and the AccessibleJPanel that the JScrollBar and JPanel are associated with.
>> 
>> This allows various assistive technologies, especially voice-recognition technologies, to better interact with scrolling items.
>> 
>> The test put up validates that the target object for these properties(CONTROLLED_BY, CONTROLLED_FOR) are set appropriately for JScrollPane and JScrollBar.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review Comments Fixed: Swing Components on EDT, 80 chars lines
>  - Review Comments Fixed: Swing Components on EDT, 80 chars lines

The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7753


From kizune at openjdk.java.net  Wed Apr 27 15:44:42 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 27 Apr 2022 15:44:42 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v3]
In-Reply-To: <W6AqQeqEwesfv4ol5hrabENk_BbYhKB6ZPpFGSsqh_c=.a448304e-e2c9-4592-a8a7-9f16b6b64982@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <QNwEljGPhlL8ImZFy0IGjfr7p8kenkdyliH6ic9UY_Y=.3ce0d201-7dcf-48d8-9fab-0b45c875a6c6@github.com>
 <l3-n06aLCnuDyt_zhUD39rskW34haYGoBDKmvxYbVJk=.31733d17-7089-43df-8c2c-2af7aa97d0b4@github.com>
 <7zYHFtn9L54eIDP49ZZtZA_kDPWwhwWTo1Zzy82gyYc=.21baf5bc-9604-4242-92d7-65bfb68cf9a0@github.com>
 <9YGqKP4x5N0miiskVwMoF201g7ng3JjTnJF5ctGkD5w=.9b763d6a-469d-49b0-83cd-79cc46cdfecd@github.com>
 <W6AqQeqEwesfv4ol5hrabENk_BbYhKB6ZPpFGSsqh_c=.a448304e-e2c9-4592-a8a7-9f16b6b64982@github.com>
Message-ID: <o5b5cKS2vQBNzAUK1a9o_i1vriHLmPZF5CfeWNo3pVo=.685dbdf8-3470-426b-b777-b445f1f14bb1@github.com>

On Wed, 27 Apr 2022 00:00:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> We don't need to push change down to the pipeline, we should push it up to the place where we paint this ImageIcon, eventually where we call ImageIcon.paintIcon()

Why? As i shown in the test case the problem affects any ImageIcon based on the MultiResolutionImage. I'm not trying to solve the singular issue that in the Windows LaF - i am trying to eliminate the reason this problem can show up.

> Then why, as described in the JBS, it worked before? Did we request different image, or size, or did we skip scaling?

Because before that change we were using different binary API to retrieve icons. This API only allows gathering 8x8 and 16x16 icons. The new API can be used for requesting icons of any size but for some files it ignores the requested size and only returns 32x32 icon. In this case we creating the multi resolution image with that icon inside and allow icon painting routine do the scaling. As i shown in my test for this bug the scaling works poorly and here i'm trying to enhance it. Can it be done in WinLAF? Yes, absolutely, but it will not solve the more generic issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7805


From kizune at openjdk.java.net  Wed Apr 27 16:40:41 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 27 Apr 2022 16:40:41 GMT
Subject: RFR: 6829250: Reg test:
 java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java fails in Windows
In-Reply-To: <YW26FpKhLBZ7OinfOhL65yoc4fpwrkXhZQAaJlA-LaQ=.e8f99138-58bc-45b1-ba18-24fa7d32db13@github.com>
References: <qDTR6A9kV9lbOGfZGYj5S5b9_M_5zhjvfak1NWPbwPY=.dce17901-1416-411a-a31f-f3f09d78389c@github.com>
 <YW26FpKhLBZ7OinfOhL65yoc4fpwrkXhZQAaJlA-LaQ=.e8f99138-58bc-45b1-ba18-24fa7d32db13@github.com>
Message-ID: <L76k1XG6OONjtdJa2TlDSmthKUmOQmE6dMPO_dpS5eM=.51f88bb9-398f-4837-850c-ef0a5234c3bb@github.com>

On Wed, 27 Apr 2022 07:30:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I as far as I remember the same behavior was on old windows and jdk7 or even [jdk6](https://stackoverflow.com/questions/7403584/does-jframe-setextendedstatemaximized-both-work-with-undecorated-frames), the root cause is that awt does not support the "MAXIMIZED_BOTH"

The MAXIMIZED_BOTH for undecorated frames works, however, for undecorated frames it allows window to overlap the taskbar so the window occupies the entirety of the screen. I do not think it is a bug.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8314


From prr at openjdk.java.net  Wed Apr 27 17:52:48 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 27 Apr 2022 17:52:48 GMT
Subject: RFR: 8284672: Collapse identical catch branches in java.desktop
In-Reply-To: <Hn-N6jOAqYovweOuFVBMML-Px6xr4Htj-y-snkbcCxA=.937877f9-8125-42a6-8260-382dba3fc005@github.com>
References: <Hn-N6jOAqYovweOuFVBMML-Px6xr4Htj-y-snkbcCxA=.937877f9-8125-42a6-8260-382dba3fc005@github.com>
Message-ID: <sHkXMpkUXAG5rkkJnednTmISoY4Li2RNOFQcf6zytQ8=.1afdaf08-c759-4ef7-b11c-b63b3d983e04@github.com>

On Fri, 8 Apr 2022 06:50:15 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types".
> It simplifies code. Reduces duplication.
> Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' statement

Marked as reviewed by prr (Reviewer).

src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java line 610:

> 608:                     }
> 609:                 } catch (MalformedURLException ex) {
> 610:                     // OK to just ignore. We'll use a fallback theme.

subclass of IOException I suppose

src/java.desktop/share/classes/com/sun/media/sound/DLSSoundbankReader.java line 50:

> 48:         try {
> 49:             return new DLSSoundbank(url);
> 50:         } catch (IOException e) {

So how can this method throw the declared IOException ?
Hmm I suppose the API super-class declares it is

src/java.desktop/share/classes/com/sun/media/sound/SF2SoundbankReader.java line 50:

> 48:         try {
> 49:             return new SF2Soundbank(url);
> 50:         } catch (IOException e) {

same here

-------------

PR: https://git.openjdk.java.net/jdk/pull/8154


From prr at openjdk.java.net  Wed Apr 27 17:56:51 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 27 Apr 2022 17:56:51 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings
In-Reply-To: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
Message-ID: <faXxzwdpTMHryL66kIS6m6kMXxNkuZilSGnWNdcqym4=.4dd9d26c-aa39-4c0b-b962-fefd1344856f@github.com>

On Wed, 27 Apr 2022 14:57:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
> Macros for Conditional Declarations
> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
> 
> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).

This is OK by me, but I wonder if the build folks might want to think about this and whether it should be centralised somehow
since it seems odd to mandate different versions of windows in different places.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8428


From prr at openjdk.java.net  Wed Apr 27 18:02:44 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 27 Apr 2022 18:02:44 GMT
Subject: RFR: 8284956: Potential leak awtImageData/color_data when
 initializes X11GraphicsEnvironment
In-Reply-To: <3POzEJ3BfvLSZncFAN7pluxsSz9_UB_wyeCMV53X-CQ=.e24bef4e-3638-4338-bd3e-3d341e21428a@github.com>
References: <3POzEJ3BfvLSZncFAN7pluxsSz9_UB_wyeCMV53X-CQ=.e24bef4e-3638-4338-bd3e-3d341e21428a@github.com>
Message-ID: <Zmx2TzCp2_93_2HAkeU7GGtTaB8y9fYVC-y4SXHX_Y4=.2cab479c-9c1d-4cfb-847e-c4823d9ae644@github.com>

On Wed, 20 Apr 2022 13:48:19 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> During initializing native data of `X11GraphicsEnvironment`, a single `AwtGraphicsConfigData` is used/reused, not only failed cases, but also succeeded cases. So `AwtGraphicsConfigData` internal states need to be cleanup properly to avoid memory leaks.
> 
> Test:
> - [x] jdk_awt

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8317


From prr at openjdk.java.net  Wed Apr 27 18:05:48 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 27 Apr 2022 18:05:48 GMT
Subject: RFR: 8284680: sun.font.FontConfigManager.getFontConfig() leaks
 charset
In-Reply-To: <MgzLHY7B6i7YyEzX8rkn-cEdkDamqKvNofwkrf1JIKI=.72ba1959-fe21-4f4e-a346-0feb5ae4037c@github.com>
References: <MgzLHY7B6i7YyEzX8rkn-cEdkDamqKvNofwkrf1JIKI=.72ba1959-fe21-4f4e-a346-0feb5ae4037c@github.com>
Message-ID: <pLMz22VKHillS1f2i9YqP7IQl2FrcucVJaSLTorp3T0=.5da506a0-9d86-4235-9e9e-71cdd9d0d420@github.com>

On Mon, 11 Apr 2022 18:05:09 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this small patch that releases temporary charsets to avoid memory leak.
> 
> Test:
> 
> - [x] jdk_2d

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8187


From prr at openjdk.java.net  Wed Apr 27 18:08:55 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 27 Apr 2022 18:08:55 GMT
Subject: RFR: 8285687 : Remove jtreg tag manual=yesno for
 ava/awt/print/PrinterJob/PageRangesDlgTest.java
In-Reply-To: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com>
References: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com>
Message-ID: <-oFYub4AXIGvGCGaoILSPxKmftgTjR2Cb2_oCfJFbxk=.504a9287-f8e0-458a-af7d-674625ee5236@github.com>

On Wed, 27 Apr 2022 00:06:41 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> 1) Fixed Parser error by removing  yesno from @run main/manual=yesno 
> 2) Used PassFaileJFrame to show the test instruction to the user instead of printing the test instruction on the console or jtreg log file. 
> 3) If printer is not configured then mark the test as passed.
> 
> @shurymury 
> @aivanov-jdk

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8412


From prr at openjdk.java.net  Wed Apr 27 18:14:45 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 27 Apr 2022 18:14:45 GMT
Subject: RFR: 8274597: Some of the dnd tests time out and fail
 intermittently [v2]
In-Reply-To: <-M3RkI7ibFy3E3pyMdIyr-7-WWbZQXFo_4no53mvgDY=.761ad3d4-ff6c-4453-a328-173492e14616@github.com>
References: <PKtuBdvWgS96mNNJUmJbDu4WHk7yfGMXrXVahFBjio8=.25fcec82-0939-43b0-adeb-a6c1c6d9fe2f@github.com>
 <-M3RkI7ibFy3E3pyMdIyr-7-WWbZQXFo_4no53mvgDY=.761ad3d4-ff6c-4453-a328-173492e14616@github.com>
Message-ID: <LhNoZ8WmTxofgpc8gwmmYzG9_lezkJI5MgS0TZjEWGg=.70c18641-c309-4381-bc13-9849b296c880@github.com>

On Wed, 20 Apr 2022 13:28:17 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> These dnd tests fails with a time out intermittently in some machines(mostly Windows 11) which creates frequent noise in CI.
>> 1. java/awt/dnd/AcceptDropMultipleTimes/AcceptDropMultipleTimes.java
>> 2. java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java
>> 3. java/awt/dnd/DropTargetEnterExitTest/ExtraDragEnterTest.java
>> 
>> Issue :
>> These tests are using the Util.drag() method and there was no robot.delay() added between different mouse actions in this method. This could potentially make tests using this method unstable.
>> 
>> Fix:
>> Adding a small auto delay of 100ms to fix this.
>> 
>> Testing:
>> 1. All the three tests are run 15 times per platform.
>> 2. All the tests in java/awt/dnd package run 5 times per platform
>> 3. All the three tests are run 5 times specifically on Windows 11 platform.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added blank line at end of file

test/jdk/java/awt/regtesthelpers/Util.java line 325:

> 323:             robot.setAutoDelay(100);
> 324:             autoDelaySet = true;
> 325:         }

If this is the right place to fix it - in the Util class - then you can just call delay(100) in the places you need it - no need to set and then unset auto-delay.

Changing Util you will need to re-validate all tests that use this utility method.

Based on the explanation you gave ~mrserb I wonder if the test should also be waiting for the drop before disposing, not just throwing an arbitrary wait into the mix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8316


From smandalika at openjdk.java.net  Wed Apr 27 18:18:49 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 27 Apr 2022 18:18:49 GMT
Subject: Integrated: JDK-8282933: Create a test for JDK-4529616
In-Reply-To: <3d_szd4R6oyDqof-g7sLsV_wkAzuEuma-aXiiUZ03Zw=.6579f560-f11e-4bea-a292-dfcee111a246@github.com>
References: <3d_szd4R6oyDqof-g7sLsV_wkAzuEuma-aXiiUZ03Zw=.6579f560-f11e-4bea-a292-dfcee111a246@github.com>
Message-ID: <4hrd0HoaJLJrdrcMrJiX2N1XkQJrfo1umA1k78klCR4=.5afe3288-1c2b-440f-a16c-c2f84a505b1e@github.com>

On Fri, 11 Mar 2022 06:30:04 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> JDK-8282933: Create a test for JDK-4529616 
> AccessibleJTableCell.isShowing() returns false when the cell is actually on
> the screen.
> The test validates the fix for the above issue by verifying that the isShowing call returns true when invoked via the  accessiblity context.
> This review is for migrating tests from a closed test suite to open.

This pull request has now been integrated.

Changeset: a0b984a7
Author:    Srinivas Mandalika <smandalika at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a0b984a778c1f9a89fd3e1e474b5a5165a0841b0
Stats:     92 lines in 1 file changed: 92 ins; 0 del; 0 mod

8282933: Create a test for JDK-4529616

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/7783


From prr at openjdk.java.net  Wed Apr 27 18:19:30 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 27 Apr 2022 18:19:30 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux [v5]
In-Reply-To: <l8h3eiPB9RcX38ktddI1hgx1RL1ZaCZz0DlXdU-Hgjk=.d5380014-4dff-4334-8be9-fb537221f546@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
 <l8h3eiPB9RcX38ktddI1hgx1RL1ZaCZz0DlXdU-Hgjk=.d5380014-4dff-4334-8be9-fb537221f546@github.com>
Message-ID: <GDZJX4KWGVf-oWNs1nQPuq-ep3mMRTAu6ldsphY5ei4=.66a2fa7d-06c5-41f8-9e7d-f0b7bd778fda@github.com>

On Fri, 8 Apr 2022 06:49:09 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> These crashes were not reproducible, so the fix is based on a hypothesis that there are two possible reasons for them:
>> 1. `makeDefaultConfig()` returning `NULL`.
>> 2. A race condition when the number of screens changes.
>> The race scenario: `X11GraphisDevice.makeDefaultConfiguration()` is called on EDT so the call can race with `X11GraphisDevice.invalidate()` that re-sets the screen number of the device; the latter is invoked on the `AWT-XAWT` thread from `X11GraphicsEnvironment.rebuildDevices()`. So by the time `makeDefaultConfiguration()` makes a native call with the device's current screen number, the `x11Screens` array maintained by the native code could have become shorter. And the native methods like `Java_sun_awt_X11GraphicsDevice_getConfigColormap()` assume that the number passed to them is always current and valid. The AWT lock only protects against the changes during the native methods invocation and does not protect against them being called with an outdated screen number. With a larger screen number, those methods read past the end of the `x11Screens` array.
>> 
>> The fix for (1) is to die gracefully instead of crashing in an attempt to de-reference a `NULL` pointer, which might happen upon returning from `makeDefaultConfig()` in `getAllConfigs()`.
>> 
>> The fix for (2) is to eliminate the race by protecting `X11GraphisDevice.screen` with the AWT lock such that it doesn't change when the native methods working with it are active.
>> 
>> We've been shipping JetBrains Runtime with this fix for a few months now and there were no crash reports with those specific patterns against the versions with the fix.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restored the original code in X11GraphicsDevice.java that got auto-formatted

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7182


From smandalika at openjdk.java.net  Wed Apr 27 18:19:56 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 27 Apr 2022 18:19:56 GMT
Subject: Integrated: 8284077: Create an automated test for JDK-4170173
In-Reply-To: <8iul_waSMDD6G1oVVmwPtW89ihAc6YoMFrTR1-XFmmw=.7802104e-60cb-4b90-9ef5-cc479d3f5a78@github.com>
References: <8iul_waSMDD6G1oVVmwPtW89ihAc6YoMFrTR1-XFmmw=.7802104e-60cb-4b90-9ef5-cc479d3f5a78@github.com>
Message-ID: <tSYTmnPxNK47CMjdlzeayB_cur6kFTT5GeI6ad9fQoM=.e266f66c-5915-4e89-9d77-1b1d7657cfaf@github.com>

On Thu, 7 Apr 2022 07:40:18 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Create an automated test for [JDK-4170173](https://bugs.openjdk.java.net/browse/JDK-4170173)
> 
> Issue
> JTextComponent.AccessibleJTextComponent.getAfterIndex(int part, int index) works incorrectly, when 'part' parameter is AccessibleText.WORD.
> It returns a space (" ") instead of the correct word.
> 
> The test verifies the fix for this behavior by checking the getAfterIndex for AccessibleText.CHARACTER,AccessibleText.WORD,AccessibleText.SENTENCE for the components JTextField, JTextArea, JEditorPane.
> 
> While working on this test case there was a related bug relevant to this [JDK-4170174](https://bugs.openjdk.java.net/browse/JDK-4170174) 
> This is marked as duplicate, addressess a similar issue.
> It indicates that JTextComponent.AccessibleJTextComponent.getBeforeIndex(int part, int index) works incorrectly, when part parameter is AccessibleText.WORD.
> It returns a space (" ") instead of correct word.
> 
> Hence an additional test was added for this, for verifying the behavior of getBeforeIndex.
> AccessibleText.CHARACTER,AccessibleText.WORD,AccessibleText.SENTENCE for the components JTextField, JTextArea, JEditorPane.
> 
> The two tests have multiple distinct assertions. For this reason, as well as for maintainability, the two were not clubbed into a single test.
> However, the two tests are still similar in the functional flow of the code and the functionality they are testing as well - hence they have been clubbed into a single review.
> This review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The tests ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

This pull request has now been integrated.

Changeset: 6db2e16b
Author:    Srinivas Mandalika <smandalika at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6db2e16b948ccb78839285051e136b8a023b2f7b
Stats:     251 lines in 2 files changed: 251 ins; 0 del; 0 mod

8284077: Create an automated test for JDK-4170173

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8138


From prr at openjdk.java.net  Wed Apr 27 18:22:56 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 27 Apr 2022 18:22:56 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v12]
In-Reply-To: <V_dusBmHOneHnSxQxMHeTd_Dk3zljmHwI2XSlDPOeok=.c9faa61f-d98a-40fd-b79c-0328ed985006@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <pkujGIpXv0UwX2gxeX6kOzKXHiqoImRI9BuglmWbHbE=.a4801fee-2fc4-4a78-97b6-4ea27396492a@github.com>
 <V_dusBmHOneHnSxQxMHeTd_Dk3zljmHwI2XSlDPOeok=.c9faa61f-d98a-40fd-b79c-0328ed985006@github.com>
Message-ID: <WkEdS3e07vWd4voH0T05DysFfvO-YExRT2ltfKLerHc=.991eaa35-12a9-4389-b882-df775974d347@github.com>

On Fri, 4 Mar 2022 22:38:33 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>>   
>>   This is a second follow-up response to prrace's code review feedback about method modifiers.
>>   
>>   This commit more carefully preserves the getBounds2D() method modifiers for all 3 classes: the Path2D.Double, the Path2D.Float, and the Path2D itself.
>>   
>>   It is possible (if unlikely) that someone previously extended the Path2D class and overrode getBounds2D(), because the Path2D#getBounds2D() method was *not* final. So with this commit: any such existing code will not break. Meanwhile the subclasses (Double and Float) preserve their previous modifiers (final, synchronized).
>>   
>>   This is in response to prrace's code review:
>>   
>>   >    You are changing the signature of public API
>>   >    src/java.desktop/share/classes/java/awt/geom/Path2D.java
>>   >    public final synchronized Rectangle2D getBounds2D() => public Rectangle2D getBounds2D() {
>>   >
>>   > So no longer final, and no longer synchronized.
>>   > This means a CSR is required and we need to think about it ..
>>   > the intention was that the subclass not over-ride.
>>   > And why remove synchronized ? I am fairly sure it was there to
>>   > make sure no one was mutating the Path whilst
>>   > bounds are being calculated.
>>   > And you are using getPathIterator(AffineTransform) and the docs
>>   > for that say it isn't thread safe.
>>   > So I think this implementation needs to be thought about very carefully.
>
> I don't suppose any new client-lib members would be willing to set up a CSR for this PR?
> 
> No worries if not. I just wanted to double-check before this PR gets auto-closed.
> 
> (I'm under the impression I can't initiate a CSR and there's nothing else I can do here; if I'm wrong please let me know.)

This is waiting for @mickleness to type "/integrate", so I can follow it up with "/sponsor"
I don't think it can get pushed unless the fixer does that /integrate.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6227


From duke at openjdk.java.net  Wed Apr 27 18:23:41 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Wed, 27 Apr 2022 18:23:41 GMT
Subject: Integrated: 8280468: Crashes in getConfigColormap, getConfigVisualId, 
 XVisualIDFromVisual on Linux
In-Reply-To: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
Message-ID: <pmMzV89vUuEAMyH_rKzlz9pMAwqlQ_lzJbX7rFJWTmM=.f15b41a8-91e0-47c8-b0cf-e8ca9c009a00@github.com>

On Fri, 21 Jan 2022 17:02:38 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

> These crashes were not reproducible, so the fix is based on a hypothesis that there are two possible reasons for them:
> 1. `makeDefaultConfig()` returning `NULL`.
> 2. A race condition when the number of screens changes.
> The race scenario: `X11GraphisDevice.makeDefaultConfiguration()` is called on EDT so the call can race with `X11GraphisDevice.invalidate()` that re-sets the screen number of the device; the latter is invoked on the `AWT-XAWT` thread from `X11GraphicsEnvironment.rebuildDevices()`. So by the time `makeDefaultConfiguration()` makes a native call with the device's current screen number, the `x11Screens` array maintained by the native code could have become shorter. And the native methods like `Java_sun_awt_X11GraphicsDevice_getConfigColormap()` assume that the number passed to them is always current and valid. The AWT lock only protects against the changes during the native methods invocation and does not protect against them being called with an outdated screen number. With a larger screen number, those methods read past the end of the `x11Screens` array.
> 
> The fix for (1) is to die gracefully instead of crashing in an attempt to de-reference a `NULL` pointer, which might happen upon returning from `makeDefaultConfig()` in `getAllConfigs()`.
> 
> The fix for (2) is to eliminate the race by protecting `X11GraphisDevice.screen` with the AWT lock such that it doesn't change when the native methods working with it are active.
> 
> We've been shipping JetBrains Runtime with this fix for a few months now and there were no crash reports with those specific patterns against the versions with the fix.

This pull request has now been integrated.

Changeset: 05dac5a2
Author:    Maxim Kartashev <maxim.kartashev at jetbrains.com>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/05dac5a23ed2813b2f4f2e4f007ebb93b4ae23ef
Stats:     79 lines in 3 files changed: 34 ins; 28 del; 17 mod

8280468: Crashes in getConfigColormap, getConfigVisualId, XVisualIDFromVisual on Linux

Reviewed-by: serb, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/7182


From duke at openjdk.java.net  Wed Apr 27 18:31:54 2022
From: duke at openjdk.java.net (Jeremy)
Date: Wed, 27 Apr 2022 18:31:54 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v12]
In-Reply-To: <pkujGIpXv0UwX2gxeX6kOzKXHiqoImRI9BuglmWbHbE=.a4801fee-2fc4-4a78-97b6-4ea27396492a@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <pkujGIpXv0UwX2gxeX6kOzKXHiqoImRI9BuglmWbHbE=.a4801fee-2fc4-4a78-97b6-4ea27396492a@github.com>
Message-ID: <sVw_cp4HPyjJ5H3xs90_ddTurJUSo2Ez-ojkZXXV_ro=.023d49d7-8f9d-49a2-891b-839b43e4d72f@github.com>

On Thu, 16 Dec 2021 18:33:37 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>   
>   This is a second follow-up response to prrace's code review feedback about method modifiers.
>   
>   This commit more carefully preserves the getBounds2D() method modifiers for all 3 classes: the Path2D.Double, the Path2D.Float, and the Path2D itself.
>   
>   It is possible (if unlikely) that someone previously extended the Path2D class and overrode getBounds2D(), because the Path2D#getBounds2D() method was *not* final. So with this commit: any such existing code will not break. Meanwhile the subclasses (Double and Float) preserve their previous modifiers (final, synchronized).
>   
>   This is in response to prrace's code review:
>   
>   >    You are changing the signature of public API
>   >    src/java.desktop/share/classes/java/awt/geom/Path2D.java
>   >    public final synchronized Rectangle2D getBounds2D() => public Rectangle2D getBounds2D() {
>   >
>   > So no longer final, and no longer synchronized.
>   > This means a CSR is required and we need to think about it ..
>   > the intention was that the subclass not over-ride.
>   > And why remove synchronized ? I am fairly sure it was there to
>   > make sure no one was mutating the Path whilst
>   > bounds are being calculated.
>   > And you are using getPathIterator(AffineTransform) and the docs
>   > for that say it isn't thread safe.
>   > So I think this implementation needs to be thought about very carefully.

Sorry, it's been a hectic month over here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6227


From erikj at openjdk.java.net  Wed Apr 27 18:45:50 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 27 Apr 2022 18:45:50 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings
In-Reply-To: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
Message-ID: <5-HeJlcacDvbVk9KSvjZuq9oVSneaCrDOB7F7hn-dJY=.63974f0b-5f61-4141-85de-43fe83af0fc0@github.com>

On Wed, 27 Apr 2022 14:57:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
> Macros for Conditional Declarations
> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
> 
> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).

Requiring different windows versions in different parts of the product doesn't make much sense, but I think it's even worse trying to keep all these different locations in sync. At least most of these have a comment explaining why that particular Windows version is required there. Changing these values invalidates those comments. 

If we are to do something about this, then we need to define this macro in a central location, and verify the value in configure. Then we would provide it either on compile command lines, or in a globally included config.h.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8428


From duke at openjdk.java.net  Wed Apr 27 18:45:59 2022
From: duke at openjdk.java.net (Jeremy)
Date: Wed, 27 Apr 2022 18:45:59 GMT
Subject: Integrated: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box
In-Reply-To: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
Message-ID: <jkbuBeSZi7HJ2_rdcM7KbEA5PDYVtBqul3YubV5oLxA=.62f47f0f-0d19-4f58-861d-78669c5ab304@github.com>

On Wed, 3 Nov 2021 07:27:03 GMT, Jeremy <duke at openjdk.java.net> wrote:

> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
> 
> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
> B. Updating the unit test to forgive the discrepancy.
> 
> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
> 
> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
> 
> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.

This pull request has now been integrated.

Changeset: 8a16842b
Author:    jeremy <jeremy.wood at mac.com>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8a16842b4e906b2eede0c01914f41010cabc51c2
Stats:     713 lines in 6 files changed: 594 ins; 114 del; 5 mod

8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box

Reviewed-by: prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/6227


From prr at openjdk.java.net  Wed Apr 27 18:46:02 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 27 Apr 2022 18:46:02 GMT
Subject: RFR: 8264666: Change implementation of safeAdd/safeMult in the
 LCMSImageLayout class [v2]
In-Reply-To: <q46O47wfBtE83i1q8k8ztS9DPacmCsNL_zW67ZYNhaw=.ed1aca9d-f892-4395-ba35-3883e499c814@github.com>
References: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
 <q46O47wfBtE83i1q8k8ztS9DPacmCsNL_zW67ZYNhaw=.ed1aca9d-f892-4395-ba35-3883e499c814@github.com>
Message-ID: <RyWSHv8CvkAjfntltH_iAZ7wiiNeyWHmY7oRy7dKdSs=.2e7a0963-b7a9-495b-a3ee-e536ccd36dc0@github.com>

On Fri, 22 Apr 2022 07:36:43 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Description of the new version of the fix:
>> While I have worked on this change and tried to consider the comments, I have found that the usages of the "safeAdd/safeMult" in the LCMSImageLayout class are incorrect. Both methods are based on the "Math" versions but throw a different exception. The problem is that its implementation may accept the negative values during intermediate calculation, see the old implementation of "[verify](https://github.com/openjdk/jdk/blob/139615b1815d4afd3593536d83fa8b25430f35e7/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java#L343)" method:
>>  1. We check the "offset" value: 0 <= offset <  dataArrayLength
>>  2. We do some intermediate calculations that "accept" negative values
>>  3. We check the final "off" value: 0 <= offset <  dataArrayLength
>> 
>> I wondered is it possible to provide some data that using wrong/negative data at step2 may result in the correct check at step3. I spent some time and was able to reproduce the problem with the attached test case. Note that the test is a little bit cryptic since it is not possible to reproduce it by input image data.
>> 
>> Note: I have removed all cleanup from the fix, to make it simpler.
>> 
>> <======>
>> Description of the old version of the fix:
>> - The hand-crafted methods for addition and multiplication are replaced by the "Math" versions.
>> - Cleanup: the usage of do/while(false) is removed
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Initial version 8264666
>  - Merge branch 'master' into LCMSImageLayout
>  - Revert "safeXX -> xxExact"
>    
>    This reverts commit a1876fa596a6831f036c04f45fa89c2caba47087.
>  - Revert "delete "do{...} while (false);""
>    
>    This reverts commit a9e91601c355f96c82dd8b2b8564a3a3e7b96aef.
>  - delete "do{...} while (false);"
>  - safeXX -> xxExact

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3333


From prr at openjdk.java.net  Wed Apr 27 18:46:06 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 27 Apr 2022 18:46:06 GMT
Subject: RFR: 8264666: Change implementation of safeAdd/safeMult in the
 LCMSImageLayout class [v2]
In-Reply-To: <lKPSt_BhmEJ7-NzSOHrbZGR0tqnSiaarTZwCNJA8u20=.f8d93fa2-cf6f-4bd8-bed5-8ad630088dd5@github.com>
References: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
 <lKPSt_BhmEJ7-NzSOHrbZGR0tqnSiaarTZwCNJA8u20=.f8d93fa2-cf6f-4bd8-bed5-8ad630088dd5@github.com>
Message-ID: <hJdVbKKjrpEyetNW-YbYcYef39DCMCJchLXGF4HBJvA=.e20ebfa9-0410-42dd-a0bb-ecc50dd01050@github.com>

On Sun, 4 Apr 2021 07:58:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Initial version 8264666
>>  - Merge branch 'master' into LCMSImageLayout
>>  - Revert "safeXX -> xxExact"
>>    
>>    This reverts commit a1876fa596a6831f036c04f45fa89c2caba47087.
>>  - Revert "delete "do{...} while (false);""
>>    
>>    This reverts commit a9e91601c355f96c82dd8b2b8564a3a3e7b96aef.
>>  - delete "do{...} while (false);"
>>  - safeXX -> xxExact
>
> src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java line 241:
> 
>> 239:                     l.dataType = DT_INT;
>> 240: 
>> 241:                     if (l.nextRowOffset == l.width * 4 * intRaster.getPixelStride()) {
> 
> Any idea why the "do/while(false)" was used here?

I can only guess it was just style ..

-------------

PR: https://git.openjdk.java.net/jdk/pull/3333


From duke at openjdk.java.net  Wed Apr 27 18:52:46 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Wed, 27 Apr 2022 18:52:46 GMT
Subject: RFR: JDK-8282772: JButton text set as HTML content has unwanted
 padding [v2]
In-Reply-To: <IZSuTxegoGBNFqjBNLrh4P_xp2g7nSB5ylXRfMSXSCM=.3ff25a09-3671-41b2-be73-e3912c6c67b1@github.com>
References: <IZSuTxegoGBNFqjBNLrh4P_xp2g7nSB5ylXRfMSXSCM=.3ff25a09-3671-41b2-be73-e3912c6c67b1@github.com>
Message-ID: <KAUjhQE2nCh3gy2DworUnO3Jet9hlgORvxwnSShdIyg=.a0ef5921-94f0-4ab2-860e-1cafb45f37cc@github.com>

> The insets for buttons were incorrect for L&Fs except for Aqua when the text is set to HTML. This was fixed in Aqua by adding a conditional to check for the BasicHTML property key in the button component. This same logic can be used to fix Metal & Motif L&Fs in BasicButtonUI, but Nimbus is not fixed by this. Nimbus gets its default values from a skin.laf file, and when the defaults here are set to have left & right insets to 0 for ButtonUI, the issue is fixed. I also tested for non-HTML text after the changes, and the changes do not affect normal text.
> 
> The HtmlButtonImageTest has been changed to cycle through all L&Fs available on a device.

DamonGuy has updated the pull request incrementally with one additional commit since the last revision:

  Changed approach to fix.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8407/files
  - new: https://git.openjdk.java.net/jdk/pull/8407/files/50001b33..05bd9a42

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8407&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8407&range=00-01

  Stats: 32 lines in 2 files changed: 20 ins; 3 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8407.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8407/head:pull/8407

PR: https://git.openjdk.java.net/jdk/pull/8407


From duke at openjdk.java.net  Wed Apr 27 18:52:46 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Wed, 27 Apr 2022 18:52:46 GMT
Subject: RFR: JDK-8282772: JButton text set as HTML content has unwanted
 padding [v2]
In-Reply-To: <MxuevbqFOvzfINWYcGXgPCyvNrctakyXL7bJtpBBGhc=.9c0a867f-243b-42c0-975a-a5b1e8cfafcd@github.com>
References: <IZSuTxegoGBNFqjBNLrh4P_xp2g7nSB5ylXRfMSXSCM=.3ff25a09-3671-41b2-be73-e3912c6c67b1@github.com>
 <MxuevbqFOvzfINWYcGXgPCyvNrctakyXL7bJtpBBGhc=.9c0a867f-243b-42c0-975a-a5b1e8cfafcd@github.com>
Message-ID: <SQbcdMJbH5QjNmM_7MTk2TX4KWmMmfIs_thJFM1oTLg=.4787b941-beca-42f6-86e3-5096bc9a9ff0@github.com>

On Tue, 26 Apr 2022 20:15:20 GMT, Phil Race <prr at openjdk.org> wrote:

>> DamonGuy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed approach to fix.
>
> src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf line 271:
> 
>> (failed to retrieve contents of file, check the PR for context)
>> I also tested for non-HTML text after the changes, and the changes do not affect normal text.
> 
> And this is true for this Nimbus case too ? Whereas your code update in BasicButtonUI is checking for HTML, I don't see how it could *not* change normal text in the Nimbus case.

I thought the same thing. In the test, I forced the L&F to nimbus only and tested with the left and right insets set to 0 and 14. The text appears normally and identically for both cases  (HTML text and non-HTML text). I also tried changing the size of the button from 37x37 to 100x100 and 200x200. The appearance was the same for all cases.

However, I just tried using different text from the tests before and I do get cases where text gets snipped to "..." when the new insets wouldn't. So, you're right that normal text is affected. I just used text that wasn't long enough in testing.

The reason I went this route for the fix was because in NimbusStyle, the insets are retrieved but the property key but the button component for BasicHTML is not set yet and returns null. So, I can't use this method to set the insets to 0 since the property key has not been set in the stack yet.

I finally found the applicable class of where to make the edits yesterday. I just made the changes similar to the other L&Fs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8407


From prr at openjdk.java.net  Wed Apr 27 19:01:34 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 27 Apr 2022 19:01:34 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v3]
In-Reply-To: <OcvupXGyRpq-jvVetEJfUNZh5SOvFpDfnU3lVetXQAM=.9e335175-b56d-42d9-b8ab-a487716f0c8b@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <OcvupXGyRpq-jvVetEJfUNZh5SOvFpDfnU3lVetXQAM=.9e335175-b56d-42d9-b8ab-a487716f0c8b@github.com>
Message-ID: <RDBwBYo25kk38qQle5K-VsDqZYTYTDH6ElLGc_KwHRQ=.a8a4c66c-18db-421a-ac5d-f5b31f8c117f@github.com>

On Wed, 30 Mar 2022 17:08:37 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

>> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
>> It includes:
>> - Bitmap glyph loading via Freetype
>> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
>> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
>> - Small fixes in related code like null-checks which could cause NPE & comment typos
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269806: Fix emoji rendering with -Dsun.java2d.xrender=false and AA=OFF

So any ideas ?

You might also try what happens if you try a font size of 100 .. IIRC when it is > 80 then we switch to outlines, and
here that might mean the glyphs suddenly vanish. And we do this because we don't want to cache massive glyphs.
So you may need to special case that too - if you aren't already.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4798


From achung at openjdk.java.net  Wed Apr 27 19:56:15 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 27 Apr 2022 19:56:15 GMT
Subject: RFR: 8284613: invalid use of @serial tag
Message-ID: <MrkxTykAMv5p3K4dNGCKKAItLiiGXN66lkEeUJXagTA=.34011a10-e882-40e1-ab1b-2779bbf29bcf@github.com>

Removed serial tag in method documentation

-------------

Commit messages:
 - removed serial tag in methods that were causing warnings

Changes: https://git.openjdk.java.net/jdk/pull/8432/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8432&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284613
  Stats: 12 lines in 12 files changed: 0 ins; 2 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8432.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8432/head:pull/8432

PR: https://git.openjdk.java.net/jdk/pull/8432


From prr at openjdk.java.net  Wed Apr 27 20:04:46 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 27 Apr 2022 20:04:46 GMT
Subject: RFR: 8276266: Clean up incorrect client-libs ProblemList.txt
 entries [v2]
In-Reply-To: <Q68GylRF9581gV18UsW8evlKv6xh2vRSKtANJF0JSQc=.6f764d5f-78b7-4781-b569-80dd14cad809@github.com>
References: <-gLIqdVcPOaZgxCVSkMNQ6FzygLGTk7O710l-Mwc4zc=.8b8a3124-9d44-4893-af45-89c22d49b589@github.com>
 <Q68GylRF9581gV18UsW8evlKv6xh2vRSKtANJF0JSQc=.6f764d5f-78b7-4781-b569-80dd14cad809@github.com>
Message-ID: <4-K_9Mwg1qdQrrMSTvG5VnTJrNKrKoZWRThb7K1JsEs=.9df69fce-3a88-4b67-ae25-a1fad92fd91f@github.com>

On Tue, 2 Nov 2021 01:29:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> We have a few stale entries in the Problem list.
>> We need to remap some tests to still open bugs
>> 7100044 -> 6849371
>> 8203047 -> 8072110
>> 8233703 -> 8238436
>> 8273618 -> 8273617
>> 
>> We need to remove these FIXED bugs
>> java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.java 7185258 macosx-all
>> 
>> java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java 8000171 windows-all
>> (actually closed as a dup of 8196100 which is fixed)
>> 
>> And this RESOLVED / not reproducible.
>>  java/awt/SplashScreen/MultiResolutionSplash/MultiResolutionSplashTest.java 8061235 macosx-all
>> 
>> I've verified that the removed ones do pass in the CI test system so we should be OK unless they are very intermittent or environment specific
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8276266: Clean up incorrect client-libs ProblemList.txt entries

@prsadhuk - still looking for a response from you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6203


From duke at openjdk.java.net  Wed Apr 27 21:05:33 2022
From: duke at openjdk.java.net (Dan Lutker)
Date: Wed, 27 Apr 2022 21:05:33 GMT
Subject: RFR: 7131823: Loading some animated GIFs fails with
 =?UTF-8?B?QXJyYXlJbmRleE91dE9mQm91bmRzReKApg==?= [v2]
In-Reply-To: <LjpJTsq96m0N24mLMjS0p1aqlUBXvBHz9-E2uh4MPQU=.8df8c3ec-9271-498a-9f84-bff49db24e67@github.com>
References: <LjpJTsq96m0N24mLMjS0p1aqlUBXvBHz9-E2uh4MPQU=.8df8c3ec-9271-498a-9f84-bff49db24e67@github.com>
Message-ID: <pc_ow7b0-tVanpxg5N3G6nDpWK4eCkvz8FXB_SGDv0M=.23bc0b6c-52be-4d51-85a5-666ec77251e5@github.com>

> ?xception: Index 4096 out of bounds for length 4096
> 
> Adapted from https://github.com/openjdk/jfx/commit/7b7050c46299c0e6771ae02fbb5ceaf22104d3e4
> 
> # Testing done
> Build locally on linux and ran jdk_imageio tests.

Dan Lutker 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 one additional commit since the last revision:

  7131823: Loading some animated GIFs fails with ArrayIndexOutOfBoundsException: Index 4096 out of bounds for length 4096

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8371/files
  - new: https://git.openjdk.java.net/jdk/pull/8371/files/de0d6875..dac34ed4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8371&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8371&range=00-01

  Stats: 11304 lines in 231 files changed: 8598 ins; 938 del; 1768 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8371.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8371/head:pull/8371

PR: https://git.openjdk.java.net/jdk/pull/8371


From kizune at openjdk.java.net  Wed Apr 27 21:50:46 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 27 Apr 2022 21:50:46 GMT
Subject: RFR: 7131823: Loading some animated GIFs fails with
 =?UTF-8?B?QXJyYXlJbmRleE91dE9mQm91bmRzReKApg==?= [v2]
In-Reply-To: <pc_ow7b0-tVanpxg5N3G6nDpWK4eCkvz8FXB_SGDv0M=.23bc0b6c-52be-4d51-85a5-666ec77251e5@github.com>
References: <LjpJTsq96m0N24mLMjS0p1aqlUBXvBHz9-E2uh4MPQU=.8df8c3ec-9271-498a-9f84-bff49db24e67@github.com>
 <pc_ow7b0-tVanpxg5N3G6nDpWK4eCkvz8FXB_SGDv0M=.23bc0b6c-52be-4d51-85a5-666ec77251e5@github.com>
Message-ID: <GpK7vBhoG3vxuHTYvo2oJprP8yQpLJBDBq_JU8KMYso=.14f5fe77-4e13-4e4b-bba7-4087767098f1@github.com>

On Wed, 27 Apr 2022 21:05:33 GMT, Dan Lutker <duke at openjdk.java.net> wrote:

>> ?xception: Index 4096 out of bounds for length 4096
>> 
>> Adapted from https://github.com/openjdk/jfx/commit/7b7050c46299c0e6771ae02fbb5ceaf22104d3e4
>> 
>> # Testing done
>> Build locally on linux and ran jdk_imageio tests.
>
> Dan Lutker 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 one additional commit since the last revision:
> 
>   7131823: Loading some animated GIFs fails with ArrayIndexOutOfBoundsException: Index 4096 out of bounds for length 4096

Code looks good but PR needs to be updated so title matches the one from the JBS.

-------------

Marked as reviewed by kizune (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8371


From duke at openjdk.java.net  Wed Apr 27 21:53:46 2022
From: duke at openjdk.java.net (Dan Lutker)
Date: Wed, 27 Apr 2022 21:53:46 GMT
Subject: RFR: 7131823: Loading some animated GIFs fails with
 =?UTF-8?B?QXJyYXlJbmRleE91dE9mQm91bmRzReKApg==?= [v2]
In-Reply-To: <GpK7vBhoG3vxuHTYvo2oJprP8yQpLJBDBq_JU8KMYso=.14f5fe77-4e13-4e4b-bba7-4087767098f1@github.com>
References: <LjpJTsq96m0N24mLMjS0p1aqlUBXvBHz9-E2uh4MPQU=.8df8c3ec-9271-498a-9f84-bff49db24e67@github.com>
 <pc_ow7b0-tVanpxg5N3G6nDpWK4eCkvz8FXB_SGDv0M=.23bc0b6c-52be-4d51-85a5-666ec77251e5@github.com>
 <GpK7vBhoG3vxuHTYvo2oJprP8yQpLJBDBq_JU8KMYso=.14f5fe77-4e13-4e4b-bba7-4087767098f1@github.com>
Message-ID: <p27u-IU6e8kPQ5xLcMkmoFA68uPHEaSxb-wgtiL3010=.d58bc9de-70da-45a2-a1fa-ddd221bfec86@github.com>

On Wed, 27 Apr 2022 21:47:07 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Code looks good but PR needs to be updated so title matches the one from the JBS.

I was thinking about changing the title of the bug since "bug in GIFImageReader" isn't very descriptive.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8371


From duke at openjdk.java.net  Wed Apr 27 22:10:43 2022
From: duke at openjdk.java.net (Dan Lutker)
Date: Wed, 27 Apr 2022 22:10:43 GMT
Subject: RFR: 7131823: bug in GIFImageReader [v3]
In-Reply-To: <LjpJTsq96m0N24mLMjS0p1aqlUBXvBHz9-E2uh4MPQU=.8df8c3ec-9271-498a-9f84-bff49db24e67@github.com>
References: <LjpJTsq96m0N24mLMjS0p1aqlUBXvBHz9-E2uh4MPQU=.8df8c3ec-9271-498a-9f84-bff49db24e67@github.com>
Message-ID: <IcHWyIghu2fjG930628ruMlpLUSZxqHzUQ_hnv4fgQI=.08340002-aaaa-4458-9a30-0fde8754e79a@github.com>

> ?xception: Index 4096 out of bounds for length 4096
> 
> Adapted from https://github.com/openjdk/jfx/commit/7b7050c46299c0e6771ae02fbb5ceaf22104d3e4
> 
> # Testing done
> Build locally on linux and ran jdk_imageio tests.

Dan Lutker has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  7131823: bug in GIFImageReader

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8371/files
  - new: https://git.openjdk.java.net/jdk/pull/8371/files/dac34ed4..beba00de

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8371&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8371&range=01-02

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8371.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8371/head:pull/8371

PR: https://git.openjdk.java.net/jdk/pull/8371


From lbourges at openjdk.java.net  Wed Apr 27 22:17:52 2022
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 27 Apr 2022 22:17:52 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v12]
In-Reply-To: <pkujGIpXv0UwX2gxeX6kOzKXHiqoImRI9BuglmWbHbE=.a4801fee-2fc4-4a78-97b6-4ea27396492a@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <pkujGIpXv0UwX2gxeX6kOzKXHiqoImRI9BuglmWbHbE=.a4801fee-2fc4-4a78-97b6-4ea27396492a@github.com>
Message-ID: <3F9aRrvTaPbcUUfpsAjnzyE9X-fpfh2NBpB39VD-MPw=.fb439b94-720e-411b-8779-036f08a9af2f@github.com>

On Thu, 16 Dec 2021 18:33:37 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>   
>   This is a second follow-up response to prrace's code review feedback about method modifiers.
>   
>   This commit more carefully preserves the getBounds2D() method modifiers for all 3 classes: the Path2D.Double, the Path2D.Float, and the Path2D itself.
>   
>   It is possible (if unlikely) that someone previously extended the Path2D class and overrode getBounds2D(), because the Path2D#getBounds2D() method was *not* final. So with this commit: any such existing code will not break. Meanwhile the subclasses (Double and Float) preserve their previous modifiers (final, synchronized).
>   
>   This is in response to prrace's code review:
>   
>   >    You are changing the signature of public API
>   >    src/java.desktop/share/classes/java/awt/geom/Path2D.java
>   >    public final synchronized Rectangle2D getBounds2D() => public Rectangle2D getBounds2D() {
>   >
>   > So no longer final, and no longer synchronized.
>   > This means a CSR is required and we need to think about it ..
>   > the intention was that the subclass not over-ride.
>   > And why remove synchronized ? I am fairly sure it was there to
>   > make sure no one was mutating the Path whilst
>   > bounds are being calculated.
>   > And you are using getPathIterator(AffineTransform) and the docs
>   > for that say it isn't thread safe.
>   > So I think this implementation needs to be thought about very carefully.

Congratulations!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6227


From dholmes at openjdk.java.net  Wed Apr 27 22:25:42 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 27 Apr 2022 22:25:42 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings
In-Reply-To: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
Message-ID: <rWorImiZNvGNpXp8KHtwgCoB2Tb14yf_u0NrjWj_U5U=.e68fed00-088f-485d-a00d-c0e82b4ee430@github.com>

On Wed, 27 Apr 2022 14:57:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
> Macros for Conditional Declarations
> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
> 
> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).

There is obviously a lot of history here and different parts of the codebase had hit different minimum OS version requirements at different times. While at one time we would have had to cater for building on systems with and without a given API those days are long gone for the code being touched here (AFAICS). As Erik states we should be able to set a minimum _WIN32_WINNT_ value needed to build all the codebase and simply have that checked and set at configure time. The code itself would not need to define _WIN32_WINNT.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8428


From duke at openjdk.java.net  Wed Apr 27 22:45:28 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Wed, 27 Apr 2022 22:45:28 GMT
Subject: RFR: 8285687 : Remove jtreg tag manual=yesno for
 ava/awt/print/PrinterJob/PageRangesDlgTest.java [v2]
In-Reply-To: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com>
References: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com>
Message-ID: <Z501dGRBBfzbJHIVVBoHG-rPNqDEAU6acFENRCmJxnE=.b5285de1-00c7-4991-9d1f-ea884fad63d2@github.com>

> 1) Fixed Parser error by removing  yesno from @run main/manual=yesno 
> 2) Used PassFaileJFrame to show the test instruction to the user instead of printing the test instruction on the console or jtreg log file. 
> 3) If printer is not configured then mark the test as passed.
> 
> @shurymury 
> @aivanov-jdk

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  Added @key printer since this test needs printer

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8412/files
  - new: https://git.openjdk.java.net/jdk/pull/8412/files/8ec07eb3..c178312a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8412&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8412&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8412.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8412/head:pull/8412

PR: https://git.openjdk.java.net/jdk/pull/8412


From darcy at openjdk.java.net  Wed Apr 27 23:10:43 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 27 Apr 2022 23:10:43 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces
In-Reply-To: <RP5pEdBu7p3ahgfvtS8xGO42CfAqviuauaYR6Iq_HZw=.f150aa97-e496-41c2-96b5-011975f9a112@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <RP5pEdBu7p3ahgfvtS8xGO42CfAqviuauaYR6Iq_HZw=.f150aa97-e496-41c2-96b5-011975f9a112@github.com>
Message-ID: <RMzI2aRmREJTRF1hSH5u1MGcDtmwsYsyMz7Ft5qAYiI=.f9088e0f-f0ff-4d24-9538-d7392b86e7e3@github.com>

On Wed, 27 Apr 2022 01:39:27 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
>> 
>> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
>> 
>> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
>> 
>> I'll update copyright years before pushing.
>
> src/java.base/share/classes/java/util/AbstractMap.java line 601:
> 
>> 599:      * {@code Map.entrySet().toArray}.
>> 600:      *
>> 601:      * @param <K> the type of keys maintained
> 
> Please update to match java.util.Map, which says "the type of keys maintained by this map"

I said "keys maintained", omitting "by this map" to finesse the question of if the SimpleEntry class *is* a map, or is used to implement a map, etc. I can change it to include "by this map" if the map/entry distinction is okay to be blurred.

> src/java.base/share/classes/java/util/Dictionary.java line 44:
> 
>> 42:  * @param <K> the type of keys
>> 43:  * @param <V> the type of mapped values
>> 44:  *
> 
> Urgh. This class is obsolete, but it was retrofitted to implement Map and was subsequently generified, so I'd update these to match java.util.Map.

The javadoc of Dictionary states "The Dictionary class [...] maps keys to values." which was my guide for the wording, but I don't mind changing it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410


From darcy at openjdk.java.net  Wed Apr 27 23:15:42 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 27 Apr 2022 23:15:42 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces
In-Reply-To: <Yowb9HvfI12BYoNV5lO8UNm3n19-kn6QLGAqjnJPvDk=.658abf24-fbcc-4100-bc38-69e9fcc2e6cc@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <Yowb9HvfI12BYoNV5lO8UNm3n19-kn6QLGAqjnJPvDk=.658abf24-fbcc-4100-bc38-69e9fcc2e6cc@github.com>
Message-ID: <FqWMvgtk0Spd3D-dO9NYW5AFX7RKzroP49uZczgJm3E=.d0fabe8c-0df2-42f3-a08d-adad36c419e1@github.com>

On Wed, 27 Apr 2022 10:54:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
>> 
>> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
>> 
>> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
>> 
>> I'll update copyright years before pushing.
>
> src/java.management/share/classes/javax/management/openmbean/ArrayType.java line 96:
> 
>> 94:  *
>> 95:  * @param <T> the Java type that instances described by this type must
>> 96:  * have.
> 
> Instead of "instances" - would it be more correct to say "array elements"?

Will change to "the Java component type that arrays described by ArrayType must have"

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410


From darcy at openjdk.java.net  Wed Apr 27 23:21:40 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 27 Apr 2022 23:21:40 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v2]
In-Reply-To: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
Message-ID: <rfkwVrxJUYtAglhFuLinI39eAp43OOLUutHk_yTO8Es=.4191cbf0-e27c-48b3-bbf9-bff30684d10b@github.com>

> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
> 
> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
> 
> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
> 
> I'll update copyright years before pushing.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Respond to review feedback.
 - Merge branch 'master' into JDK-8285676
 - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8410/files
  - new: https://git.openjdk.java.net/jdk/pull/8410/files/fe47dd2f..e0ac5dcb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=00-01

  Stats: 5958 lines in 128 files changed: 4827 ins; 485 del; 646 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8410.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8410/head:pull/8410

PR: https://git.openjdk.java.net/jdk/pull/8410


From darcy at openjdk.java.net  Wed Apr 27 23:21:52 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 27 Apr 2022 23:21:52 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v2]
In-Reply-To: <Yowb9HvfI12BYoNV5lO8UNm3n19-kn6QLGAqjnJPvDk=.658abf24-fbcc-4100-bc38-69e9fcc2e6cc@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <Yowb9HvfI12BYoNV5lO8UNm3n19-kn6QLGAqjnJPvDk=.658abf24-fbcc-4100-bc38-69e9fcc2e6cc@github.com>
Message-ID: <EL78CD9RDpLjQbXH_gjyKLrDIEL4cF0ASceOdtkSqYc=.d8df7bd0-6307-4c27-9116-faecf433b872@github.com>

On Wed, 27 Apr 2022 10:55:22 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Respond to review feedback.
>>  - Merge branch 'master' into JDK-8285676
>>  - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces
>
> src/java.management/share/classes/javax/management/openmbean/SimpleType.java line 60:
> 
>> (failed to retrieve contents of file, check the PR for context)
> I would suggest to say "that values described by this type"...

Will change to "the Java type that values described by this SimpleType must have."

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410


From smarks at openjdk.java.net  Wed Apr 27 23:31:55 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 27 Apr 2022 23:31:55 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v2]
In-Reply-To: <RMzI2aRmREJTRF1hSH5u1MGcDtmwsYsyMz7Ft5qAYiI=.f9088e0f-f0ff-4d24-9538-d7392b86e7e3@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <RP5pEdBu7p3ahgfvtS8xGO42CfAqviuauaYR6Iq_HZw=.f150aa97-e496-41c2-96b5-011975f9a112@github.com>
 <RMzI2aRmREJTRF1hSH5u1MGcDtmwsYsyMz7Ft5qAYiI=.f9088e0f-f0ff-4d24-9538-d7392b86e7e3@github.com>
Message-ID: <fkKoR7pfREQcqsmRI_-jRBbhdLZKwRXZy_M5Ds9NJRw=.07181639-b665-4781-b2ac-3c839611f19e@github.com>

On Wed, 27 Apr 2022 23:04:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/AbstractMap.java line 601:
>> 
>>> 599:      * {@code Map.entrySet().toArray}.
>>> 600:      *
>>> 601:      * @param <K> the type of keys maintained
>> 
>> Please update to match java.util.Map, which says "the type of keys maintained by this map"
>
> I said "keys maintained", omitting "by this map" to finesse the question of if the SimpleEntry class *is* a map, or is used to implement a map, etc. I can change it to include "by this map" if the map/entry distinction is okay to be blurred.

Whoops, sorry, this is `SimpleEntry`, which is _not_ a `Map`. In this case I'd follow `Map.Entry` which says "the type of the key" and "the type of the map".

>> src/java.base/share/classes/java/util/Dictionary.java line 44:
>> 
>>> 42:  * @param <K> the type of keys
>>> 43:  * @param <V> the type of mapped values
>>> 44:  *
>> 
>> Urgh. This class is obsolete, but it was retrofitted to implement Map and was subsequently generified, so I'd update these to match java.util.Map.
>
> The javadoc of Dictionary states "The Dictionary class [...] maps keys to values." which was my guide for the wording, but I don't mind changing it.

My bad, `Dictionary` was not retrofitted to implement `Map` but it gained `K` and `V` type parameters to align with `Map`. No need to change this; it doesn't really matter.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410


From darcy at openjdk.java.net  Thu Apr 28 01:34:19 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Apr 2022 01:34:19 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v3]
In-Reply-To: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
Message-ID: <EKgw2cuyScL05pjYGZSXIoPhtm_UOy1JVl-YQ5Eh1W8=.96f0bf77-d828-4ad2-8976-822c9d4668e2@github.com>

> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
> 
> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
> 
> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
> 
> I'll update copyright years before pushing.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to more review feedback.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8410/files
  - new: https://git.openjdk.java.net/jdk/pull/8410/files/e0ac5dcb..db4919a9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8410.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8410/head:pull/8410

PR: https://git.openjdk.java.net/jdk/pull/8410


From prr at openjdk.java.net  Thu Apr 28 01:34:19 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 28 Apr 2022 01:34:19 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v3]
In-Reply-To: <EKgw2cuyScL05pjYGZSXIoPhtm_UOy1JVl-YQ5Eh1W8=.96f0bf77-d828-4ad2-8976-822c9d4668e2@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <EKgw2cuyScL05pjYGZSXIoPhtm_UOy1JVl-YQ5Eh1W8=.96f0bf77-d828-4ad2-8976-822c9d4668e2@github.com>
Message-ID: <WSNF09SBgw2xrvMnmYct_zfP7iLL_QWUJ2BMs7SCzTg=.dde930a6-f976-4de9-85ba-d0c1bf094660@github.com>

On Thu, 28 Apr 2022 01:31:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
>> 
>> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
>> 
>> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
>> 
>> I'll update copyright years before pushing.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to more review feedback.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410


From darcy at openjdk.java.net  Thu Apr 28 01:34:19 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Apr 2022 01:34:19 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v3]
In-Reply-To: <fkKoR7pfREQcqsmRI_-jRBbhdLZKwRXZy_M5Ds9NJRw=.07181639-b665-4781-b2ac-3c839611f19e@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <RP5pEdBu7p3ahgfvtS8xGO42CfAqviuauaYR6Iq_HZw=.f150aa97-e496-41c2-96b5-011975f9a112@github.com>
 <RMzI2aRmREJTRF1hSH5u1MGcDtmwsYsyMz7Ft5qAYiI=.f9088e0f-f0ff-4d24-9538-d7392b86e7e3@github.com>
 <fkKoR7pfREQcqsmRI_-jRBbhdLZKwRXZy_M5Ds9NJRw=.07181639-b665-4781-b2ac-3c839611f19e@github.com>
Message-ID: <sKsmjRtcuOZvIyMTUBHXWUbsfNj4Gesl0jQVM5sck08=.72b0f059-77ec-438b-916d-1a5483bd49a2@github.com>

On Wed, 27 Apr 2022 23:24:57 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> I said "keys maintained", omitting "by this map" to finesse the question of if the SimpleEntry class *is* a map, or is used to implement a map, etc. I can change it to include "by this map" if the map/entry distinction is okay to be blurred.
>
> Whoops, sorry, this is `SimpleEntry`, which is _not_ a `Map`. In this case I'd follow `Map.Entry` which says "the type of the key" and "the type of the map".

Will change to the Map.Entry wording "the type of key" and "the type of the value", respectively.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410


From psadhukhan at openjdk.java.net  Thu Apr 28 03:47:37 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 28 Apr 2022 03:47:37 GMT
Subject: RFR: 8276266: Clean up incorrect client-libs ProblemList.txt
 entries
In-Reply-To: <u32Q5yNSHj0bo8IQHpzQ7OAVZ5b_fqlkKJvZoQEDOME=.a5840cea-7383-4950-b9c1-e91eadb5ffeb@github.com>
References: <-gLIqdVcPOaZgxCVSkMNQ6FzygLGTk7O710l-Mwc4zc=.8b8a3124-9d44-4893-af45-89c22d49b589@github.com>
 <ZtQfaBZJjucLrzsLY9g7GHJayRM45RaNd9GuIC0hOoY=.7e71aa86-5339-4d5c-b6fc-c83d4cad909a@github.com>
 <u32Q5yNSHj0bo8IQHpzQ7OAVZ5b_fqlkKJvZoQEDOME=.a5840cea-7383-4950-b9c1-e91eadb5ffeb@github.com>
Message-ID: <TzPPA9e73wMHgU-Pvh-FwRzcJCs1EGVBPYw_OGOnNEo=.05698f9a-df25-4052-9ed3-b1b53bcc2003@github.com>

On Tue, 2 Nov 2021 16:10:43 GMT, Phil Race <prr at openjdk.org> wrote:

> > I am not sure why the macOS-specific JDK-8203047 was closed as a duplicate of x11 specific JDK-8072110?
> > The HandleExceptionOnEDT from the JDK-8203047 is not even mentioned in the JDK-8072110.
> 
> I don't know. This was done by @prsadhuk - Prasanta can you explain that ?

I am not sure on this now...Seems like it might have been a mistake seeing it now..probably I was trying to close as dup with some other JBS but inadvertently mentioned the wrong one..

-------------

PR: https://git.openjdk.java.net/jdk/pull/6203


From mbaesken at openjdk.java.net  Thu Apr 28 07:16:38 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 28 Apr 2022 07:16:38 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings
In-Reply-To: <fb6V2fi9al6WD5-n-IlcGF5Iv9Bg1EbphIZGUnVezlQ=.fd40ece0-21ec-42f5-9669-af7cd0f47bb8@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <fb6V2fi9al6WD5-n-IlcGF5Iv9Bg1EbphIZGUnVezlQ=.fd40ece0-21ec-42f5-9669-af7cd0f47bb8@github.com>
Message-ID: <jTYB50MGyVQqaGZ8LsgICew0lkS-GYdN9UCjkKsM0y0=.a14f468d-1d6d-4cad-a012-0f030a5f1313@github.com>

On Wed, 27 Apr 2022 15:10:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
>> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
>> Macros for Conditional Declarations
>> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
>> 
>> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).
>
> src/java.base/windows/native/libnio/ch/wepoll.c line 159:
> 
>> 157: 
>> 158: #undef _WIN32_WINNT
>> 159: #define _WIN32_WINNT 0x0601
> 
> This is 3rd party code and would prefer not change it if possible.

Hi Alan, I agree (thats why I did not change the define in harfbuzz,  but I missed that wepoll.c is 3rd party code as well).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8428


From mbaesken at openjdk.java.net  Thu Apr 28 07:19:42 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 28 Apr 2022 07:19:42 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings
In-Reply-To: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
Message-ID: <B6xmDBhPc8oL1MWp13PNRBe1uzGr8wscK18o_Cg5ajw=.d2b9fbdc-9a73-4a7a-8aa4-a9f2ea2262bb@github.com>

On Wed, 27 Apr 2022 14:57:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
> Macros for Conditional Declarations
> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
> 
> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).

Hi Erik/David/Phil, we already have a good central place where we set the definition of WIN32_LEAN_AND_MEAN 

autoconf/flags-cflags.m4:460:    ALWAYS_DEFINES_JDK="-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE \
autoconf/flags-cflags.m4:462:    ALWAYS_DEFINES_JVM="-DNOMINMAX -DWIN32_LEAN_AND_MEAN"

should we add there the _WIN32_WINNT=0x0601  define  (and remove the differing defines instead at the other places) ?
(defines of _WIN32_WINNT in 3rd party code would stay like wepoll.c and harfbuzz).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8428


From dfuchs at openjdk.java.net  Thu Apr 28 08:03:43 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 28 Apr 2022 08:03:43 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v3]
In-Reply-To: <EKgw2cuyScL05pjYGZSXIoPhtm_UOy1JVl-YQ5Eh1W8=.96f0bf77-d828-4ad2-8976-822c9d4668e2@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <EKgw2cuyScL05pjYGZSXIoPhtm_UOy1JVl-YQ5Eh1W8=.96f0bf77-d828-4ad2-8976-822c9d4668e2@github.com>
Message-ID: <N43fg2ZtC9VIYO6SXPz4dxYjotBQhGA2Fz5iliN_eEg=.6fd7ceac-fbde-4d97-a6cc-5c5e16a70ec9@github.com>

On Thu, 28 Apr 2022 01:34:19 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
>> 
>> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
>> 
>> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
>> 
>> I'll update copyright years before pushing.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to more review feedback.

Thanks for the updates Joe. Your new wording looks good to me.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8410


From alanb at openjdk.java.net  Thu Apr 28 08:14:25 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 28 Apr 2022 08:14:25 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v3]
In-Reply-To: <EKgw2cuyScL05pjYGZSXIoPhtm_UOy1JVl-YQ5Eh1W8=.96f0bf77-d828-4ad2-8976-822c9d4668e2@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <EKgw2cuyScL05pjYGZSXIoPhtm_UOy1JVl-YQ5Eh1W8=.96f0bf77-d828-4ad2-8976-822c9d4668e2@github.com>
Message-ID: <Ib04OwgWvasO3awv0GtN9pNgsFFhA6ZyEhJTfrO5KKY=.88362bf9-a83f-448a-9cfc-53743a6af63f@github.com>

On Thu, 28 Apr 2022 01:34:19 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
>> 
>> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
>> 
>> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
>> 
>> I'll update copyright years before pushing.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to more review feedback.

src/java.base/share/classes/java/nio/file/SecureDirectoryStream.java line 55:

> 53:  * against the <i>original path</i> of the directory (irrespective of if the
> 54:  * directory is moved since it was opened).
> 55:  * @param <T> the type of path

It may not be a path. The type parameter is specified in the super interfaces, can you copy that down instead?

src/java.base/share/classes/java/nio/file/WatchEvent.java line 51:

> 49:     /**
> 50:      * An event kind, for the purposes of identification.
> 51:      * @param <T> the type of the context value

This is okay but the it differs slightly to the type parameters specified further up. I think the issue here is that it was just wasn't copied down to WatchEvent.Kind.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410


From duke at openjdk.java.net  Thu Apr 28 09:19:19 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Thu, 28 Apr 2022 09:19:19 GMT
Subject: RFR: 8254759: [TEST_BUG] [macosx]
 javax/swing/JInternalFrame/4202966/IntFrameCoord.html fails
Message-ID: <Xzq3WueM7chkh0W1Vwy-IztwkFFUV9aAxqvJ6Jj9Rt8=.f6065b51-f381-4b5e-a618-a692c17ffdb7@github.com>

Closed repo test fix from the test sprint. This test was approved in the closed repo and has been converted to an open repo test.

This test checks if the coordinates are still correct after changing focuses between different JInternalFrames. The test is now automated instead of manual like the previous, closed version. This needs to be a headful test to allow robot to click on the different frames and to check coordinates.

The issue was that in MacOS, the button wouldn't appear at a normal size. To fix this, the bounds have been increased to allow the button to be fully visible with the designated frame sizes on all L&Fs.

-------------

Commit messages:
 - Moved test from closed repo to open repo.

Changes: https://git.openjdk.java.net/jdk/pull/8444/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8444&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254759
  Stats: 145 lines in 1 file changed: 145 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8444.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8444/head:pull/8444

PR: https://git.openjdk.java.net/jdk/pull/8444


From psadhukhan at openjdk.java.net  Thu Apr 28 12:06:08 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 28 Apr 2022 12:06:08 GMT
Subject: RFR: 8213531: Test javax/swing/border/TestTitledBorderLeak.java fails
Message-ID: <Njia7F66IINfJqmT-OBEOXwoNbmPHh7ZuOHWzq2ZZLE=.228e4222-fbbb-45bc-9f02-cec6edaeb91d@github.com>

Test was failing in linux citing `java.lang.RuntimeException: Expected Total TitledBorder to be freed : 10 Freed 9 `
As per the fix done in JDK-8204963 http://hg.openjdk.java.net/jdk/jdk/rev/cd7d2f9154fd
there was no platform specific code done for the fix and logs in `TitledBorder.installPropertyChangeListeners` shows it was called 10 times for the test but `CleanerFactory.cleaner().register` action was only called 9 times in linux causing it to fail.

Modified the test to not show the frame which cause the problem to go away and also it can still be used as 8204963 regression test as it still fails without the fix and pass with it. Modified test has passed in all platforms for several iterations.

Also removed the deprecated `System.runFinalization`

-------------

Commit messages:
 - 8213531: Test javax/swing/border/TestTitledBorderLeak.java fails

Changes: https://git.openjdk.java.net/jdk/pull/8450/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8450&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8213531
  Stats: 8 lines in 2 files changed: 0 ins; 5 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8450.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8450/head:pull/8450

PR: https://git.openjdk.java.net/jdk/pull/8450


From erikj at openjdk.java.net  Thu Apr 28 12:36:42 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 28 Apr 2022 12:36:42 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings
In-Reply-To: <B6xmDBhPc8oL1MWp13PNRBe1uzGr8wscK18o_Cg5ajw=.d2b9fbdc-9a73-4a7a-8aa4-a9f2ea2262bb@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <B6xmDBhPc8oL1MWp13PNRBe1uzGr8wscK18o_Cg5ajw=.d2b9fbdc-9a73-4a7a-8aa4-a9f2ea2262bb@github.com>
Message-ID: <ea-HmEVAi3_om1Q2mI5VZBokopo16R16lIgbdFWyRKw=.d9a13032-2321-49bb-b1bd-c27dcb604367@github.com>

On Thu, 28 Apr 2022 07:16:30 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Erik/David/Phil, we already have a good central place where we set the definition of WIN32_LEAN_AND_MEAN
> 
> autoconf/flags-cflags.m4:460: ALWAYS_DEFINES_JDK="-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE autoconf/flags-cflags.m4:462: ALWAYS_DEFINES_JVM="-DNOMINMAX -DWIN32_LEAN_AND_MEAN"
> 
> should we add there the _WIN32_WINNT=0x0601 define (and remove the differing defines instead at the other places) ? (defines of _WIN32_WINNT in 3rd party code would stay like wepoll.c and harfbuzz).

Seems reasonable to me at least.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8428


From shade at openjdk.java.net  Thu Apr 28 13:10:41 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 28 Apr 2022 13:10:41 GMT
Subject: RFR: 8284956: Potential leak awtImageData/color_data when
 initializes X11GraphicsEnvironment
In-Reply-To: <3POzEJ3BfvLSZncFAN7pluxsSz9_UB_wyeCMV53X-CQ=.e24bef4e-3638-4338-bd3e-3d341e21428a@github.com>
References: <3POzEJ3BfvLSZncFAN7pluxsSz9_UB_wyeCMV53X-CQ=.e24bef4e-3638-4338-bd3e-3d341e21428a@github.com>
Message-ID: <R-HItecy6-6oU2S5OVh9HRqVkAyJRWiTt79A4aaah_8=.a7461f53-5375-4bf0-8cf9-804ede64575d@github.com>

On Wed, 20 Apr 2022 13:48:19 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> During initializing native data of `X11GraphicsEnvironment`, a single `AwtGraphicsConfigData` is used/reused, not only failed cases, but also succeeded cases. So `AwtGraphicsConfigData` internal states need to be cleanup properly to avoid memory leaks.
> 
> Test:
> - [x] jdk_awt

What about `_ColorData::img_grays`, `_ColorData::awt_Colors`, `_ColorData::img_oda_*`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8317


From andrew at openjdk.java.net  Thu Apr 28 13:17:38 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Thu, 28 Apr 2022 13:17:38 GMT
Subject: RFR: 8284956: Potential leak awtImageData/color_data when
 initializes X11GraphicsEnvironment
In-Reply-To: <3POzEJ3BfvLSZncFAN7pluxsSz9_UB_wyeCMV53X-CQ=.e24bef4e-3638-4338-bd3e-3d341e21428a@github.com>
References: <3POzEJ3BfvLSZncFAN7pluxsSz9_UB_wyeCMV53X-CQ=.e24bef4e-3638-4338-bd3e-3d341e21428a@github.com>
Message-ID: <QQ__Cl1SEMw3dYBfMHYzGlvNvrw1QEe242cRbnc4br0=.8ea39f9b-b3b2-4729-991a-ce7a2fc223bf@github.com>

On Wed, 20 Apr 2022 13:48:19 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> During initializing native data of `X11GraphicsEnvironment`, a single `AwtGraphicsConfigData` is used/reused, not only failed cases, but also succeeded cases. So `AwtGraphicsConfigData` internal states need to be cleanup properly to avoid memory leaks.
> 
> Test:
> - [x] jdk_awt

I see `calloc` calls also for `img_grays` and `awt_Colors`. Is there a reason these aren't freed too?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8317


From psadhukhan at openjdk.java.net  Thu Apr 28 13:34:31 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 28 Apr 2022 13:34:31 GMT
Subject: RFR: 8213531: Test javax/swing/border/TestTitledBorderLeak.java
 fails [v2]
In-Reply-To: <Njia7F66IINfJqmT-OBEOXwoNbmPHh7ZuOHWzq2ZZLE=.228e4222-fbbb-45bc-9f02-cec6edaeb91d@github.com>
References: <Njia7F66IINfJqmT-OBEOXwoNbmPHh7ZuOHWzq2ZZLE=.228e4222-fbbb-45bc-9f02-cec6edaeb91d@github.com>
Message-ID: <7f6imhO_fmNXVejmC3boQyV0uNjoHOJCiVzetcCOHpY=.b2d95eab-e3f7-45db-83ad-92e91e3a5585@github.com>

> Test was failing in linux citing `java.lang.RuntimeException: Expected Total TitledBorder to be freed : 10 Freed 9 `
> As per the fix done in JDK-8204963 http://hg.openjdk.java.net/jdk/jdk/rev/cd7d2f9154fd
> there was no platform specific code done for the fix and logs in `TitledBorder.installPropertyChangeListeners` shows it was called 10 times for the test but `CleanerFactory.cleaner().register` action was only called 9 times in linux causing it to fail.
> 
> Modified the test to not show the frame which cause the problem to go away and also it can still be used as 8204963 regression test as it still fails without the fix and pass with it. Modified test has passed in all platforms for several iterations.
> 
> Also removed the deprecated `System.runFinalization`

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Test fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8450/files
  - new: https://git.openjdk.java.net/jdk/pull/8450/files/ea2c3e11..8bf50cca

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8450&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8450&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8450.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8450/head:pull/8450

PR: https://git.openjdk.java.net/jdk/pull/8450


From andrew at openjdk.java.net  Thu Apr 28 14:23:49 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Thu, 28 Apr 2022 14:23:49 GMT
Subject: RFR: 8284680: sun.font.FontConfigManager.getFontConfig() leaks
 charset
In-Reply-To: <MgzLHY7B6i7YyEzX8rkn-cEdkDamqKvNofwkrf1JIKI=.72ba1959-fe21-4f4e-a346-0feb5ae4037c@github.com>
References: <MgzLHY7B6i7YyEzX8rkn-cEdkDamqKvNofwkrf1JIKI=.72ba1959-fe21-4f4e-a346-0feb5ae4037c@github.com>
Message-ID: <RWQWpmpVUHGbFOQ0rx1KqMwj11yuuU_871dczsRFYcA=.16f4cf61-8d2b-456d-9e8f-ebad3809d555@github.com>

On Mon, 11 Apr 2022 18:05:09 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this small patch that releases temporary charsets to avoid memory leak.
> 
> Test:
> 
> - [x] jdk_2d

Ok, let me see if I follow this correctly.

The main logic to call `FcCharSetDestroy` is within two loops. The outermost loop declares `unionCharset`. The inner loop declares `charset`.

On each of the iterations of the inner loop, `charset` is newly defined and obtains a character set via `FcPatternGetString`. This character set is not a copy and doesn't need to be freed.

I thus assume the need to free comes from the return value of `FcCharSetUnion`. On each iteration of the inner loop, this is used to add more characters to the character set pointed to by `unionCharset`.

On iteration 0, `unionCharset` is NULL so it is assigned `charset`, which is the character set for `fontset->fonts[0]`.
On iteration 1, `unionCharset` is now the charset for `fontset->fonts[0]`. `charset` will  be redefined and set to the character set for `fontset->fonts[1]`.
I see a problem on this iteration. `currentUnionSet` will be set to the character set for `fontset->fonts[0]` and `unionCharset` will then be allocated a new character set consisting of the union of the characters in the sets for `fontset->fonts[0]` (in `currentUnionSet`) and `fontset->fonts[1]` (in `charset`). How will `currentUnionSet` ever be equal to `charset` in this case? 

Unless I'm missing something, the second iteration is going to wrongly attempt to free the character set allocated in the first iteration.

For subsequent iterations, the free is fine, because it is indeed releasing the previous union.

A possible solution would be to introduce another variable e.g. `previousUnion` which is only set after the first union is created. The problem with using unionCharset is it is set to `charset` on the first iteration.

So something like:

unionCharset = (* FcCharSetUnion)(unionCharset, charset);
if (previousUnion != NULL) {
  (*FcCharSetDestroy)(previousUnion);
}
previousUnion = unionCharset;

-------------

PR: https://git.openjdk.java.net/jdk/pull/8187


From zgu at openjdk.java.net  Thu Apr 28 14:58:28 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 28 Apr 2022 14:58:28 GMT
Subject: RFR: 8284956: Potential leak awtImageData/color_data when
 initializes X11GraphicsEnvironment [v2]
In-Reply-To: <3POzEJ3BfvLSZncFAN7pluxsSz9_UB_wyeCMV53X-CQ=.e24bef4e-3638-4338-bd3e-3d341e21428a@github.com>
References: <3POzEJ3BfvLSZncFAN7pluxsSz9_UB_wyeCMV53X-CQ=.e24bef4e-3638-4338-bd3e-3d341e21428a@github.com>
Message-ID: <YecCJ9UbROUL_R5EzWr-w_FpCN_oI_n1GgC_ImuFgxc=.2044fbfc-7628-439f-8929-580497d07622@github.com>

> During initializing native data of `X11GraphicsEnvironment`, a single `AwtGraphicsConfigData` is used/reused, not only failed cases, but also succeeded cases. So `AwtGraphicsConfigData` internal states need to be cleanup properly to avoid memory leaks.
> 
> Test:
> - [x] jdk_awt

Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:

  Aleksey and Andrew's comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8317/files
  - new: https://git.openjdk.java.net/jdk/pull/8317/files/e6838cf0..64a74f3e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8317&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8317&range=00-01

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8317.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8317/head:pull/8317

PR: https://git.openjdk.java.net/jdk/pull/8317


From duke at openjdk.java.net  Thu Apr 28 15:26:10 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Thu, 28 Apr 2022 15:26:10 GMT
Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling
 changes
Message-ID: <B0ZUOVjp3bUuieQfuMeFFgclV1lo94EwkLsJFRxINC0=.cad3d7e4-bb3c-4f97-878f-0d2ffccef61d@github.com>

In Windows when desktop scaling was changed the tray icons was distorted/blurred a bit each time scaling changes.

With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario.

When DPI changes usually two messages are sent by windows -

- [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged)
- [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging)

I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update.

-------------

Commit messages:
 - removed whitespaces error due to CRLF
 - removed whitespace error
 - added manual to test case
 - trayicon changes

Changes: https://git.openjdk.java.net/jdk/pull/8441/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8441&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255439
  Stats: 177 lines in 5 files changed: 172 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8441.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8441/head:pull/8441

PR: https://git.openjdk.java.net/jdk/pull/8441


From psadhukhan at openjdk.java.net  Thu Apr 28 16:23:44 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 28 Apr 2022 16:23:44 GMT
Subject: RFR: 8285094: Test
 java/awt/Frame/InvisibleOwner/InvisibleOwner.java failing on Linux [v2]
In-Reply-To: <1FY4ypDIGUN3Hkz3R8hN6zyJonmrErTzUlU50bijZtw=.7ea435d2-6268-4454-9c58-e98fca7c8c20@github.com>
References: <nZJd4Qchm9OYGaFr3iBBm3XdYmqWXHzjfLElnUaCL90=.2fa7fc8c-23e2-46df-a5c5-acb33e7bf5fc@github.com>
 <1FY4ypDIGUN3Hkz3R8hN6zyJonmrErTzUlU50bijZtw=.7ea435d2-6268-4454-9c58-e98fca7c8c20@github.com>
Message-ID: <1Z-oRLSABy8uXBUc3CXHj8Cbk8RRw5n6dzmdxTEVdjU=.0095b70a-b669-4119-8315-f917ed7b829e@github.com>

On Thu, 21 Apr 2022 15:23:31 GMT, Phil Race <prr at openjdk.org> wrote:

>> As discussed in https://bugs.openjdk.java.net/browse/JDK-8285094 it seems that the test
>> java/awt/Frame/GetGraphicsStressTest/GetGraphicsStressTest.java destabilises the Xserver.
>> This causes java/awt/Frame/InvisibleOwner/InvisibleOwner.java to fail and even before that
>> other tests which do  pass are not visibly behaving as expected.
>> 
>> I didn't find any Xserver logs of "bad stuff" happening so it just seems like the Xserver was
>> having trouble keeping up and JDK was behaving correctly as it could despite the Xserver sending
>> lots of requests to repaint.
>> 
>> Just the "sleep" at the end of GetGraphicsStressTest.java seems to be enough but I'd already
>> reworked InvisibleOwner.java and I'd like to think it is a bit better than before.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285094

Marked as reviewed by psadhukhan (Reviewer).

test/jdk/java/awt/Frame/InvisibleOwner/InvisibleOwner.java line 159:

> 157:             robot.mouseMove(C_X, C_Y);
> 158:             robot.mousePress(InputEvent.BUTTON1_MASK);
> 159:             robot.mouseRelease(InputEvent.BUTTON1_MASK);

In other places,we have modified to use BUTTON1_DOWN_MASK, maybe we can do here too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8312


From duke at openjdk.java.net  Thu Apr 28 16:36:39 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 28 Apr 2022 16:36:39 GMT
Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int)
 [v4]
In-Reply-To: <xW_IMRaU3A70QAxx5vnH990FVkxQnTq1EAf-F7rz3Nw=.17ca4b0e-ee2b-45bb-8cd1-c380bb6a0990@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
 <zFlFjdt_WK9VyWsAxqnfhvu-MmJe1IKc7WtyBNkPE5A=.ec807db1-ad90-4e27-99d7-8a1ea145aa71@github.com>
 <S9LU83ceTWEKtLvzA4D63u3Qysv4rk6f83rZ7QvfR5E=.936ea9b1-c42b-47c7-8a98-4c8803c67fe8@github.com>
 <xW_IMRaU3A70QAxx5vnH990FVkxQnTq1EAf-F7rz3Nw=.17ca4b0e-ee2b-45bb-8cd1-c380bb6a0990@github.com>
Message-ID: <4K3rhX2RGM_yaCKKJALcP7EplXS2pJXM8zYGNGEg-6Y=.c03f7730-b26a-459a-8d60-ea8ab9149603@github.com>

On Wed, 27 Apr 2022 05:11:54 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> Also do not change J2DBench. We deliberately avoid using new API so that we can take it and run it on very old JDK versions to help track regressions.

For J2DBench, I don't see any changes that not complicated with older jdk version for now. please recheck. thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8301


From darcy at openjdk.java.net  Thu Apr 28 16:47:38 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Apr 2022 16:47:38 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v3]
In-Reply-To: <Ib04OwgWvasO3awv0GtN9pNgsFFhA6ZyEhJTfrO5KKY=.88362bf9-a83f-448a-9cfc-53743a6af63f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <EKgw2cuyScL05pjYGZSXIoPhtm_UOy1JVl-YQ5Eh1W8=.96f0bf77-d828-4ad2-8976-822c9d4668e2@github.com>
 <Ib04OwgWvasO3awv0GtN9pNgsFFhA6ZyEhJTfrO5KKY=.88362bf9-a83f-448a-9cfc-53743a6af63f@github.com>
Message-ID: <APLsOL7a9pdpPrF0yqc21hFBBblzmz4ufzfe0fkIPHE=.284c73bd-5701-4d0a-8dc2-f8906298db79@github.com>

On Thu, 28 Apr 2022 08:08:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to more review feedback.
>
> src/java.base/share/classes/java/nio/file/SecureDirectoryStream.java line 55:
> 
>> 53:  * against the <i>original path</i> of the directory (irrespective of if the
>> 54:  * directory is moved since it was opened).
>> 55:  * @param <T> the type of path
> 
> It may not be a path. The type parameter is specified in the super interfaces, can you copy that down instead?

Will change in the next push.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410


From duke at openjdk.java.net  Thu Apr 28 16:56:38 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 28 Apr 2022 16:56:38 GMT
Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int)
 [v5]
In-Reply-To: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
Message-ID: <vKFnwzOHGA2_EV-6k5nWOsrhZk2VOG8e-NIRVxdt8lk=.16f88bc5-87fe-4945-9978-f4ba1439ef9e@github.com>

> These are the changes that too many to be reviewed in 8186958, thus split some of them out.

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  revert changes to java.desktop as prrace said

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8301/files
  - new: https://git.openjdk.java.net/jdk/pull/8301/files/684d1528..c9cfb50a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=03-04

  Stats: 56 lines in 30 files changed: 8 ins; 0 del; 48 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8301.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301

PR: https://git.openjdk.java.net/jdk/pull/8301


From darcy at openjdk.java.net  Thu Apr 28 16:58:40 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Apr 2022 16:58:40 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v4]
In-Reply-To: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
Message-ID: <HMJ5qGsBGbV8az1D1GJFSu_fyBfjfzFGBZm3wgQLcQM=.aebea4cc-686f-4a39-88b8-3f90d64ebf61@github.com>

> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
> 
> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
> 
> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
> 
> I'll update copyright years before pushing.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to more review feedback.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8410/files
  - new: https://git.openjdk.java.net/jdk/pull/8410/files/db4919a9..aaa8f828

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8410.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8410/head:pull/8410

PR: https://git.openjdk.java.net/jdk/pull/8410


From darcy at openjdk.java.net  Thu Apr 28 16:58:40 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Apr 2022 16:58:40 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v3]
In-Reply-To: <Ib04OwgWvasO3awv0GtN9pNgsFFhA6ZyEhJTfrO5KKY=.88362bf9-a83f-448a-9cfc-53743a6af63f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <EKgw2cuyScL05pjYGZSXIoPhtm_UOy1JVl-YQ5Eh1W8=.96f0bf77-d828-4ad2-8976-822c9d4668e2@github.com>
 <Ib04OwgWvasO3awv0GtN9pNgsFFhA6ZyEhJTfrO5KKY=.88362bf9-a83f-448a-9cfc-53743a6af63f@github.com>
Message-ID: <vABdYW2fqKSy9FCs9pJIoHYgJdFs7TWXSKeO_pk6bBE=.224ba49c-2848-45f1-a3c9-561555f4880d@github.com>

On Thu, 28 Apr 2022 08:10:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to more review feedback.
>
> src/java.base/share/classes/java/nio/file/WatchEvent.java line 51:
> 
>> 49:     /**
>> 50:      * An event kind, for the purposes of identification.
>> 51:      * @param <T> the type of the context value
> 
> This is okay but the it differs slightly to the type parameters specified further up. I think the issue here is that it was just wasn't copied down to WatchEvent.Kind.

Okay -- I'll for the T type parameter of the Kind interface I'll reuse the wording of the T type parameter of the enclosing WatchEvent interface. (The type variable on Kind could be renamed to show that the two type parameters are distinct.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410


From alanb at openjdk.java.net  Thu Apr 28 17:30:50 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 28 Apr 2022 17:30:50 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v4]
In-Reply-To: <HMJ5qGsBGbV8az1D1GJFSu_fyBfjfzFGBZm3wgQLcQM=.aebea4cc-686f-4a39-88b8-3f90d64ebf61@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <HMJ5qGsBGbV8az1D1GJFSu_fyBfjfzFGBZm3wgQLcQM=.aebea4cc-686f-4a39-88b8-3f90d64ebf61@github.com>
Message-ID: <RWkPlAb3Lvs0UWXjBkya0RmLKXZunv02SSxQ1-PdeQk=.9aa846c3-bed9-4e8d-bb8d-ba91180bba58@github.com>

On Thu, 28 Apr 2022 16:58:40 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
>> 
>> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
>> 
>> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
>> 
>> I'll update copyright years before pushing.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to more review feedback.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410


From weijun at openjdk.java.net  Thu Apr 28 17:43:43 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 28 Apr 2022 17:43:43 GMT
Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int)
 [v5]
In-Reply-To: <vKFnwzOHGA2_EV-6k5nWOsrhZk2VOG8e-NIRVxdt8lk=.16f88bc5-87fe-4945-9978-f4ba1439ef9e@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
 <vKFnwzOHGA2_EV-6k5nWOsrhZk2VOG8e-NIRVxdt8lk=.16f88bc5-87fe-4945-9978-f4ba1439ef9e@github.com>
Message-ID: <l6_Ksx45t5ahkJuwy7OzkuYtMzEwLYcb2Kzq7wkoE3c=.8d719712-3600-4688-8909-2eabc90682d5@github.com>

On Thu, 28 Apr 2022 16:56:38 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> These are the changes that too many to be reviewed in 8186958, thus split some of them out.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes to java.desktop as prrace said

src/java.base/share/classes/sun/security/rsa/SunRsaSignEntries.java line 58:

> 56:         // start populating content using the specified provider
> 57:         // common attribute map
> 58:         HashMap<String, String> attrs = HashMap.newHashMap(3);

Looks like 1 is enough.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8301


From mchung at openjdk.java.net  Thu Apr 28 17:49:48 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 28 Apr 2022 17:49:48 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v4]
In-Reply-To: <HMJ5qGsBGbV8az1D1GJFSu_fyBfjfzFGBZm3wgQLcQM=.aebea4cc-686f-4a39-88b8-3f90d64ebf61@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <HMJ5qGsBGbV8az1D1GJFSu_fyBfjfzFGBZm3wgQLcQM=.aebea4cc-686f-4a39-88b8-3f90d64ebf61@github.com>
Message-ID: <LA-4M_w3p_hqJLf6j0DBR2uUpK0rcPr7xE18GQP4Tao=.ed7751d6-0f7e-44a8-b9c0-ced7724b4cd5@github.com>

On Thu, 28 Apr 2022 16:58:40 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
>> 
>> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
>> 
>> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
>> 
>> I'll update copyright years before pushing.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to more review feedback.

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410


From darcy at openjdk.java.net  Thu Apr 28 18:05:39 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Apr 2022 18:05:39 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v5]
In-Reply-To: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
Message-ID: <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com>

> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
> 
> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
> 
> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
> 
> I'll update copyright years before pushing.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Update copyright years.
 - Merge branch 'master' into JDK-8285676
 - Respond to more review feedback.
 - Respond to more review feedback.
 - Respond to review feedback.
 - Merge branch 'master' into JDK-8285676
 - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8410/files
  - new: https://git.openjdk.java.net/jdk/pull/8410/files/aaa8f828..cb1fe1c2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=03-04

  Stats: 687 lines in 59 files changed: 610 ins; 8 del; 69 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8410.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8410/head:pull/8410

PR: https://git.openjdk.java.net/jdk/pull/8410


From darcy at openjdk.java.net  Thu Apr 28 18:05:40 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Apr 2022 18:05:40 GMT
Subject: Integrated: JDK-8285676: Add missing @param tags for type parameters
 on classes and interfaces
In-Reply-To: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
Message-ID: <Xa8RvIRtpco75Ib21j-Mcvs5Pvj3iyog7CA9y0YzJ3o=.31542016-78a7-461c-9c07-1c8a45128d19@github.com>

On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
> 
> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
> 
> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
> 
> I'll update copyright years before pushing.

This pull request has now been integrated.

Changeset: bba456a8
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bba456a8dbf9027e4b015567c17a79fc7441aa08
Stats:     102 lines in 40 files changed: 76 ins; 0 del; 26 mod

8285676: Add missing @param tags for type parameters on classes and interfaces

Reviewed-by: wetmore, smarks, dfuchs, prr, alanb, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410


From duke at openjdk.java.net  Thu Apr 28 18:07:36 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 28 Apr 2022 18:07:36 GMT
Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int)
 [v6]
In-Reply-To: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
Message-ID: <WJ5kczxQoTQXG_mbbibVt9GfzhPMZDds-RyVRlBdAO0=.3c80fbab-038e-447b-a1e4-01759199d96b@github.com>

> These are the changes that too many to be reviewed in 8186958, thus split some of them out.

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  change from 3 to 1 according to wangweij

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8301/files
  - new: https://git.openjdk.java.net/jdk/pull/8301/files/c9cfb50a..1b4bac0f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8301.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301

PR: https://git.openjdk.java.net/jdk/pull/8301


From duke at openjdk.java.net  Thu Apr 28 18:07:37 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 28 Apr 2022 18:07:37 GMT
Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int)
 [v5]
In-Reply-To: <l6_Ksx45t5ahkJuwy7OzkuYtMzEwLYcb2Kzq7wkoE3c=.8d719712-3600-4688-8909-2eabc90682d5@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
 <vKFnwzOHGA2_EV-6k5nWOsrhZk2VOG8e-NIRVxdt8lk=.16f88bc5-87fe-4945-9978-f4ba1439ef9e@github.com>
 <l6_Ksx45t5ahkJuwy7OzkuYtMzEwLYcb2Kzq7wkoE3c=.8d719712-3600-4688-8909-2eabc90682d5@github.com>
Message-ID: <dLQrR1ArbwoHp6fRARMGoQhPnAJ4hgFnp-73a-_Jz5s=.b9e88df7-ba41-472c-8efe-a63b5b0d9fe8@github.com>

On Thu, 28 Apr 2022 17:36:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Looks like 1 is enough.

@wangweij done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8301


From zgu at openjdk.java.net  Thu Apr 28 18:25:59 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 28 Apr 2022 18:25:59 GMT
Subject: RFR: 8284956: Potential leak awtImageData/color_data when
 initializes X11GraphicsEnvironment [v2]
In-Reply-To: <QQ__Cl1SEMw3dYBfMHYzGlvNvrw1QEe242cRbnc4br0=.8ea39f9b-b3b2-4729-991a-ce7a2fc223bf@github.com>
References: <3POzEJ3BfvLSZncFAN7pluxsSz9_UB_wyeCMV53X-CQ=.e24bef4e-3638-4338-bd3e-3d341e21428a@github.com>
 <QQ__Cl1SEMw3dYBfMHYzGlvNvrw1QEe242cRbnc4br0=.8ea39f9b-b3b2-4729-991a-ce7a2fc223bf@github.com>
Message-ID: <Q1BAhIcyXkG4akt7FlOtCuCN61EYDczRDJcpGXQrKl4=.1cff1e0b-30ce-4ff1-b1e8-f6385f78d901@github.com>

On Thu, 28 Apr 2022 13:14:07 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Aleksey and Andrew's comments
>
> I see `calloc` calls also for `img_grays` and `awt_Colors`. Is there a reason these aren't freed too?

@gnu-andrew @shipilev Nice catch, fixed.

Thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/8317


From aturbanov at openjdk.java.net  Thu Apr 28 18:27:59 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Thu, 28 Apr 2022 18:27:59 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v5]
In-Reply-To: <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com>
Message-ID: <ly0yNqCx3P8EkbF_nagUNFG9fxo_DID-Q80BxAx9OZA=.93b1a3f1-00f7-4237-a36f-2268c7cedcb4@github.com>

On Thu, 28 Apr 2022 18:05:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
>> 
>> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
>> 
>> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
>> 
>> I'll update copyright years before pushing.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Update copyright years.
>  - Merge branch 'master' into JDK-8285676
>  - Respond to more review feedback.
>  - Respond to more review feedback.
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8285676
>  - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces

src/java.base/share/classes/java/lang/ref/PhantomReference.java line 48:

> 46:  * The {@link #refersTo(Object) refersTo} method can be used to test
> 47:  * whether some object is the referent of a phantom reference.
> 48:  * @param<T> the type of the referent

Shouldn't there be a space after `@param` ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410


From zgu at openjdk.java.net  Thu Apr 28 18:31:49 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 28 Apr 2022 18:31:49 GMT
Subject: RFR: 8284956: Potential leak awtImageData/color_data when
 initializes X11GraphicsEnvironment [v2]
In-Reply-To: <R-HItecy6-6oU2S5OVh9HRqVkAyJRWiTt79A4aaah_8=.a7461f53-5375-4bf0-8cf9-804ede64575d@github.com>
References: <3POzEJ3BfvLSZncFAN7pluxsSz9_UB_wyeCMV53X-CQ=.e24bef4e-3638-4338-bd3e-3d341e21428a@github.com>
 <R-HItecy6-6oU2S5OVh9HRqVkAyJRWiTt79A4aaah_8=.a7461f53-5375-4bf0-8cf9-804ede64575d@github.com>
Message-ID: <pmItocL68kNaviV1-QhPfnaPZImHVe82KmotKarFFFY=.dd698ae7-b743-468d-9955-2178c9398b90@github.com>

On Thu, 28 Apr 2022 13:07:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> What about `_ColorData::img_grays`, `_ColorData::awt_Colors`, `_ColorData::img_oda_*`?

`_ColorData::img_oda_*` are not malloc'd


 awt_data->color_data->img_oda_red   = &(std_img_oda_red[0][0]);
 awt_data->color_data->img_oda_green = &(std_img_oda_green[0][0]);
 awt_data->color_data->img_oda_blue  = &(std_img_oda_blue[0][0]);

and `std_img_oda_*` are defined as 

JNIEXPORT extern sgn_ordered_dither_array std_img_oda_red;
JNIEXPORT extern sgn_ordered_dither_array std_img_oda_green;
JNIEXPORT extern sgn_ordered_dither_array std_img_oda_blue;

-------------

PR: https://git.openjdk.java.net/jdk/pull/8317


From mchung at openjdk.java.net  Thu Apr 28 19:08:52 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 28 Apr 2022 19:08:52 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v5]
In-Reply-To: <ly0yNqCx3P8EkbF_nagUNFG9fxo_DID-Q80BxAx9OZA=.93b1a3f1-00f7-4237-a36f-2268c7cedcb4@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com>
 <ly0yNqCx3P8EkbF_nagUNFG9fxo_DID-Q80BxAx9OZA=.93b1a3f1-00f7-4237-a36f-2268c7cedcb4@github.com>
Message-ID: <-4fsP7Oz2b5SHJR3uPUb7dPXo8cVPj0lXNnCDAKgWGA=.7ab1337e-2e75-4dc9-85d8-fb9734ea598c@github.com>

On Thu, 28 Apr 2022 18:24:33 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Update copyright years.
>>  - Merge branch 'master' into JDK-8285676
>>  - Respond to more review feedback.
>>  - Respond to more review feedback.
>>  - Respond to review feedback.
>>  - Merge branch 'master' into JDK-8285676
>>  - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces
>
> src/java.base/share/classes/java/lang/ref/PhantomReference.java line 48:
> 
>> 46:  * The {@link #refersTo(Object) refersTo} method can be used to test
>> 47:  * whether some object is the referent of a phantom reference.
>> 48:  * @param<T> the type of the referent
> 
> Shouldn't there be a space after `@param` ?

Good catch.  Sorry I missed it. This occurs in all `java/lang/ref` files.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410


From prr at openjdk.java.net  Thu Apr 28 19:50:32 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 28 Apr 2022 19:50:32 GMT
Subject: RFR: 8285686: Upgrade to FreeType 2.12.0
Message-ID: <tVRK-O11GP6MeVKBPFQY-ie5vA6qfBwkQTBKaD9HPWM=.5c669509-73fb-4ecb-b888-4f0945fa000c@github.com>

This upgrades the JDK from using freetype 2.10.4 to 2.12.0
Automated tests pass, manual testing looks fine.
--with-freetype=bundled was used to make sure it is OK on Linux builds.

-------------

Commit messages:
 - 8285686

Changes: https://git.openjdk.java.net/jdk/pull/8456/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8456&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285686
  Stats: 10933 lines in 293 files changed: 6807 ins; 2146 del; 1980 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8456.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8456/head:pull/8456

PR: https://git.openjdk.java.net/jdk/pull/8456


From zgu at openjdk.java.net  Thu Apr 28 20:16:45 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 28 Apr 2022 20:16:45 GMT
Subject: RFR: 8284680: sun.font.FontConfigManager.getFontConfig() leaks
 charset
In-Reply-To: <MgzLHY7B6i7YyEzX8rkn-cEdkDamqKvNofwkrf1JIKI=.72ba1959-fe21-4f4e-a346-0feb5ae4037c@github.com>
References: <MgzLHY7B6i7YyEzX8rkn-cEdkDamqKvNofwkrf1JIKI=.72ba1959-fe21-4f4e-a346-0feb5ae4037c@github.com>
Message-ID: <VcaDl8iHomw0cjXuQW9e3j8K2PabHwiasOrEYDBJ1wY=.01ae5230-ddc9-418f-9731-1b1a7c7e1171@github.com>

On Mon, 11 Apr 2022 18:05:09 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this small patch that releases temporary charsets to avoid memory leak.
> 
> Test:
> 
> - [x] jdk_2d

> 

Hmmm, you are right. Phil probably pointed out the same problem, but I misunderstood it.

What's odd is that, I tested (made sure that `FcCharSetDestroy` indeed called), it did not crash and `valgrind` showed the leak site disappeared.

With your suggested fix, I think we still leak last `unionCharset`. BTW, the API documentation is really unhelpful, Sigh!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8187


From aivanov at openjdk.java.net  Thu Apr 28 21:29:23 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 28 Apr 2022 21:29:23 GMT
Subject: RFR: 8285306: Fix typos in java.desktop
In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
Message-ID: <1x04_BXzoS9x2Uh3iaA-wo08JPGM6xUli_YbFbyOkFY=.248133c8-2be5-4a68-89bc-9b6f62e33fb9@github.com>

On Thu, 21 Apr 2022 08:35:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
> 
> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Nearly 500 files are too many. Smaller chunks would be easier to review.

Some of the native code files could come from upstream libraries.

src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 535:

> 533: 
> 534:     static class AquaHierarchyButtonListener implements HierarchyListener {
> 535:         // Every time a hierarchy is change we need to check if the button if moved on or from

Suggestion:

        // Every time a hierarchy is changed we need to check if the button is moved on or from

Maybe even ?_the_ hierarchy?.
And probably ?_the_ toolbar? on the next line.

src/java.desktop/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java line 126:

> 124:             // see bug 8010925
> 125:             // we can't put this to handleWindowFocusEvent because
> 126:             // it won't be invoced if focus is moved to a html element

Suggestion:

            // it won't be invoked if focus is moved to an html element

src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m line 552:

> 550: }
> 551: 
> 552: // Orders window's children based on the current focus state

Suggestion:

// Orders window children based on the current focus state

I believe possessive is not necessary here, it's not used with inanimate objects usually.

src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m line 688:

> 686: }
> 687: 
> 688: // Hides/shows window's children during iconify/de-iconify operation

Suggestion:

// Hides/shows window children during iconify/de-iconify operation

src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m line 320:

> 318:     acquiring transform arrays from JNI, filling buffers, or striking glyphs. All resources or memory
> 319:     acquired at a given stage, must be released in that stage. Any error that occurs (like a failed malloc)
> 320:     is to be handled in the stage it occurs in, and is to return immediately after freeing it's resources.

Suggestion:

    is to be handled in the stage it occurs in, and is to return immediately after freeing its resources.

src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.m line 96:

> 94:     // The colors passed have low randomness. That means we need to scramble the bits of the color
> 95:     // to produce a good hash key. After some analysis, it looks like Thomas's Wang integer hashing algorithm
> 96:     // seems a nice trade off between performance and effectiveness.

Suggestion:

    // seems a nice trade-off between performance and effectiveness.

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGraphicsConfig.m line 63:

> 61:     jboolean metalSupported = JNI_FALSE;
> 62: 
> 63:     // It is guaranteed that metal supported GPU is available macOS 10.14 onwards

It sounds as if something is missing before ?macOS??
Suggestion:

    // It is guaranteed that metal supported GPU is available since macOS 10.14

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLVertexCache.m line 248:

> 246:         // we can give destination subtexturing properly but we can't
> 247:         // subtexture from system memory glyph we have. So in such
> 248:         // cases we are creating separate tile and scan the source

Suggestion:

        // cases we are creating a separate tile and scan the source

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLVertexCache.m line 250:

> 248:         // cases we are creating separate tile and scan the source
> 249:         // stride into destination using memcpy. In case of OpenGL we
> 250:         // can update source pointers, in case of D3D we ar doing memcpy.

Suggestion:

        // can update source pointers, in case of D3D we are doing memcpy.

src/java.desktop/share/classes/javax/swing/ActionPropertyChangeListener.java line 49:

> 47:  * <p>
> 48:  * WARNING WARNING WARNING WARNING WARNING WARNING:<br>
> 49:  * Do NOT create an anonymous inner class that extends this!  If you do

Suggestion:

 * Do NOT create an anonymous inner class that extends this!  If you do,

A comma will separate the condition from the result.

src/java.desktop/share/classes/javax/swing/BoxLayout.java line 503:

> 501:      * The relative axis values, PAGE_AXIS and LINE_AXIS are converted
> 502:      * to their absolute counterpart given the target's ComponentOrientation
> 503:      * value.  The absolute axes, X_AXIS and Y_AXIS are returned unmodified.

Shall we put a comma after LINE_AXIS and Y_AXIS and ?are??

src/java.desktop/share/classes/javax/swing/DefaultRowSorter.java line 1038:

> 1036:         if (!sorted || viewToModel.length == 0 ||
> 1037:                 (lastRow - firstRow) > viewToModel.length / 10) {
> 1038:             // We either weren't sorted, or to much changed, sort it all or

Suggestion:

            // We either weren't sorted, or too much changed, sort it all or

src/java.desktop/share/classes/javax/swing/GroupLayout.java line 1654:

> 1652:         /**
> 1653:          * Used to compute how the two values representing two springs
> 1654:          * will be combined.  For example, a group that laid things out

Suggestion:

         * will be combined.  For example, a group that laid out things

Not sure which one is correct. Usually the particle in a phrasal verb follows the verb is the object is a noun.

src/java.desktop/share/classes/javax/swing/JCheckBox.java line 248:

> 246: 
> 247:     /**
> 248:      * The icon for checkboxs comes from the look and feel,

Suggestion:

     * The icon for checkboxes comes from the look and feel,

src/java.desktop/share/classes/javax/swing/JLayeredPane.java line 532:

> 530:             if(curLayer == layer) {
> 531:                 layerCount++;
> 532:             /// Short circuit the counting when we have them all

Suggestion:

            /// Short-circuit the counting when we have them all

src/java.desktop/share/classes/javax/swing/JLayeredPane.java line 558:

> 556:             if(curLayer == layer) {
> 557:                 results[layerCount++] = getComponent(i);
> 558:             /// Short circuit the counting when we have them all

Suggestion:

            /// Short-circuit the counting when we have them all

src/java.desktop/share/classes/javax/swing/JMenu.java line 201:

> 199:      * Overridden to do nothing. We want JMenu to be focusable, but
> 200:      * <code>JMenuItem</code> doesn't want to be, thus we override this
> 201:      * do nothing. We don't invoke <code>setFocusable(true)</code> after

Suggestion:

     * to do nothing. We don't invoke <code>setFocusable(true)</code> after

src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 335:

> 333: 
> 334:     /**
> 335:      * Returns an point which has been adjusted to take into account of the

Suggestion:

     * Returns an point which has been adjusted to take into account the

src/java.desktop/share/classes/javax/swing/JSpinner.java line 675:

> 673:             // active vs those of the JFormattedTextField. As such we
> 674:             // put disabled actions in the JFormattedTextField's actionmap.
> 675:             // A binding to a disabled action is treated as a nonexistent

Suggestion:

            // A binding to a disabled action is treated as a non-existent

The word is spelt with a hyphen in all the preceding cases (in this code review).

src/java.desktop/share/classes/javax/swing/SwingWorker.java line 262:

> 260: 
> 261:     /**
> 262:      * handler for {@code process} method.

Suggestion:

     * Handler for {@code process} method.

To be consistent in starting from a capital letter, even though it's a private field.

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalRootPaneUI.java line 316:

> 314:         uninstallLayout(root);
> 315:         // We have to revalidate/repaint root if the style is JRootPane.NONE
> 316:         // only. When we needs to call revalidate/repaint with other styles

Suggestion:

        // only. When we need to call revalidate/repaint with other styles

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalTheme.java line 68:

> 66: public abstract class MetalTheme {
> 67: 
> 68:     // Constants identifying the various Fonts that are Theme can support

Suggestion:

    // Constants identifying the various Fonts that a Theme can support

src/java.desktop/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java line 332:

> 330:             return laf.getDerivedColor(key, hOffset, sOffset, bOffset, aOffset, true);
> 331:         } else {
> 332:             // can not give a right answer as painter should not be used outside

Suggestion:

            // cannot give the right answer as painter should not be used outside

The sentence suggests there's only _one_ right answer, therefore the definite article.

src/java.desktop/share/classes/javax/swing/plaf/nimbus/SynthPainterImpl.java line 126:

> 124:         Component c = ctx.getComponent();
> 125:         boolean ltr = c.getComponentOrientation().isLeftToRight();
> 126:         // Don't RTL flip JSpliders as they handle it internally

Suggestion:

        // Don't RTL flip JSliders as they handle it internally

src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html line 876:

> 874: 	used for all directions.</dd>
> 875:       <dt><a id="imagePainter.path"><samp>path</samp></a></dt>
> 876:       <dd>Path to the image. Path to the image.  If SynthLookAndFeel.load is

Suggestion:

      <dd>Path to the image.  If SynthLookAndFeel.load is

I believe the duplicate sentence can be dropped.

src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html line 877:

> 875:       <dt><a id="imagePainter.path"><samp>path</samp></a></dt>
> 876:       <dd>Path to the image. Path to the image.  If SynthLookAndFeel.load is
> 877:     passed a Class this will use the Class method getResource (with with the

Suggestion:

    passed a Class this will use the Class method getResource (with the

src/java.desktop/share/classes/javax/swing/text/WrappedPlainView.java line 661:

> 659:      * This class tries to be lightweight by carrying little
> 660:      * state of it's own and sharing the state of the outer class
> 661:      * with it's sibblings.

Suggestion:

     * state of its own and sharing the state of the outer class
     * with its siblings.

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1779:

> 1777:      * <p>
> 1778:      * The CSS parser uses the parseCssValue method to convert
> 1779:      * a string to whatever format is appropriate a given key

Suggestion:

     * a string to whatever format is appropriate for a given key

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1781:

> 1779:      * a string to whatever format is appropriate a given key
> 1780:      * (i.e. these converters are stored in a map using the
> 1781:      * CSS.Attribute as a key and the CssValue as the value).

Suggestion:

     * CSS.Attribute as the key and the CssValue as the value).

src/java.desktop/share/classes/javax/swing/text/html/parser/TagStack.java line 39:

> 37:  * When a start tag is encountered an element is pushed onto
> 38:  * the stack, when an end tag is encountered an element is popped
> 39:  * of the stack.

Suggestion:

 * off the stack.

src/java.desktop/share/classes/javax/swing/tree/FixedHeightLayoutCache.java line 645:

> 643: 
> 644:     /**
> 645:      * Ensures that all the path components in path are expanded, accept

Suggestion:

     * Ensures that all the path components in path are expanded, except

src/java.desktop/share/classes/sun/awt/image/ImagingLib.java line 68:

> 66: 
> 67:     /**
> 68:      * Returned value indicates whether the library initialization was

Suggestion:

     * Returned value indicates whether the library initialization

src/java.desktop/share/classes/sun/awt/image/ImagingLib.java line 71:

> 69:      * succeeded.
> 70:      *
> 71:      * There could be number of reasons to failure:

Suggestion:

     * There could be a number of reasons for failure:

src/java.desktop/share/classes/sun/swing/SwingUtilities2.java line 1782:

> 1780:     /**
> 1781:      * Returns an integer from the defaults table. If {@code key} does
> 1782:      * not map to a valid {@code Integer}, or can not be converted from

Suggestion:

     * not map to a valid {@code Integer}, or cannot be converted from

src/java.desktop/share/classes/sun/swing/SwingUtilities2.java line 1795:

> 1793:      * Returns an integer from the defaults table that is appropriate
> 1794:      * for the given locale. If {@code key} does not map to a valid
> 1795:      * {@code Integer}, or can not be converted from a {@code String}

Suggestion:

     * {@code Integer}, or cannot be converted from a {@code String}

And two more below.

src/java.desktop/share/classes/sun/swing/text/TextComponentPrintable.java line 772:

> 770:                         /*
> 771:                          * we do not store the same value as previous. in our
> 772:                          * documents it is often for consequent positions to have

Looks this actually means _consecutive_ positions?

src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java line 485:

> 483:     /**
> 484:      * returns item which mapped coordinates contain
> 485:      * specified point, null of none.

Suggestion:

     * the specified point, null if none.

src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java line 944:

> 942:      * This function needs to be overridden since
> 943:      * XBaseMenuWindow has no corresponding component
> 944:      * so events can not be processed using standard means

Suggestion:

     * so events cannot be processed using standard means

src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java line 390:

> 388:     /* Implement DisposerTarget. Weak references to an Object can delay
> 389:      * its storage reclamation marginally.
> 390:      * It won't make the native resources be release any more quickly, but

Suggestion:

     * It won't make the native resources be released any more quickly, but

src/java.desktop/windows/native/libawt/windows/awt_Label.h line 62:

> 60:     /*
> 61:      * if WM_PAINT was receiving when we can not paint
> 62:      * then setup m_needPaint end when can call this function

Suggestion:

     * if WM_PAINT was received when we cannot paint
     * then setup m_needPaint and when can paint call this function

src/java.desktop/windows/native/libawt/windows/awt_PrintDialog.cpp line 57:

> 55:                 (LOWORD(wParam) == IDCANCEL))
> 56:             {
> 57:                 // If we receive on of these two notifications, the dialog

Suggestion:

                // If we receive one of these two notifications, the dialog

src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 3173:

> 3171:                 (LOWORD(wParam) == IDCANCEL))
> 3172:             {
> 3173:                 // If we receive on of these two notifications, the dialog

Suggestion:

                // If we receive one of these two notifications, the dialog

src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp line 1085:

> 1083:       // Special awt message to call Imm APIs.
> 1084:       // ImmXXXX() API must be used in the main thread.
> 1085:       // In other thread these APIs does not work correctly even if

Suggestion:

      // In other threads these APIs do not work correctly even if

src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp line 1087:

> 1085:       // In other thread these APIs does not work correctly even if
> 1086:       // it returns with no error. (This restriction is not documented)
> 1087:       // So we must use thse messages to call these APIs in main thread.

Suggestion:

      // So we must use these messages to call these APIs in main thread.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8328


From mvs at openjdk.java.net  Thu Apr 28 22:16:34 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Thu, 28 Apr 2022 22:16:34 GMT
Subject: RFR: 8274597: Some of the dnd tests time out and fail
 intermittently [v3]
In-Reply-To: <PKtuBdvWgS96mNNJUmJbDu4WHk7yfGMXrXVahFBjio8=.25fcec82-0939-43b0-adeb-a6c1c6d9fe2f@github.com>
References: <PKtuBdvWgS96mNNJUmJbDu4WHk7yfGMXrXVahFBjio8=.25fcec82-0939-43b0-adeb-a6c1c6d9fe2f@github.com>
Message-ID: <tbXhXgPNjH5s0xhQ_adnjcRBUeRlKr7Pg5Vlw_xyolg=.9f62e643-a9c0-4f32-a8a4-dfb2bffe8a2c@github.com>

> These dnd tests fails with a time out intermittently in some machines(mostly Windows 11) which creates frequent noise in CI.
> 1. java/awt/dnd/AcceptDropMultipleTimes/AcceptDropMultipleTimes.java
> 2. java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java
> 3. java/awt/dnd/DropTargetEnterExitTest/ExtraDragEnterTest.java
> 4. java/awt/dnd/MissingDragExitEventTest/MissingDragExitEventTest.java
> 
> Issue :
> This doesn't seem to be a deadlock. When there is no sufficient delay after the mouse release(dragged mouse pointer release to drop the content), the frame is getting disposed even before the drop() method gets called. So it waits for the drop() method which will never happen as the frame has been already disposed and the test times out after some time.
> 
> Fix:
> Waiting for the drop() method to get called before disposing the frame.
> 
> Testing: 
> 1. All the four tests are run 10 times per platform and got all pass
> 2. All the four tests are run 10 times on Windows 11 and got all pass

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed: Removed changes in Utils and made all the 4 tests waiting for drop() to get called, formatting changes, set the frame on top

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8316/files
  - new: https://git.openjdk.java.net/jdk/pull/8316/files/f008f89a..e0d63537

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8316&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8316&range=01-02

  Stats: 115 lines in 5 files changed: 65 ins; 25 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8316.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8316/head:pull/8316

PR: https://git.openjdk.java.net/jdk/pull/8316


From mvs at openjdk.java.net  Thu Apr 28 22:21:37 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Thu, 28 Apr 2022 22:21:37 GMT
Subject: RFR: 8274597: Some of the dnd tests time out and fail
 intermittently [v4]
In-Reply-To: <PKtuBdvWgS96mNNJUmJbDu4WHk7yfGMXrXVahFBjio8=.25fcec82-0939-43b0-adeb-a6c1c6d9fe2f@github.com>
References: <PKtuBdvWgS96mNNJUmJbDu4WHk7yfGMXrXVahFBjio8=.25fcec82-0939-43b0-adeb-a6c1c6d9fe2f@github.com>
Message-ID: <5d-F4QcZM_iIJcus08tRQjsDagQXd6Jar1_zMwFeB5M=.cb91b495-1863-4fe2-b3cd-a55b28cdcb9d@github.com>

> These dnd tests fails with a time out intermittently in some machines(mostly Windows 11) which creates frequent noise in CI.
> 1. java/awt/dnd/AcceptDropMultipleTimes/AcceptDropMultipleTimes.java
> 2. java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java
> 3. java/awt/dnd/DropTargetEnterExitTest/ExtraDragEnterTest.java
> 4. java/awt/dnd/MissingDragExitEventTest/MissingDragExitEventTest.java
> 
> Issue :
> This doesn't seem to be a deadlock. When there is no sufficient delay after the mouse release(dragged mouse pointer release to drop the content), the frame is getting disposed even before the drop() method gets called. So it waits for the drop() method which will never happen as the frame has been already disposed and the test times out after some time.
> 
> Fix:
> Waiting for the drop() method to get called before disposing the frame.
> 
> Testing: 
> 1. All the four tests are run 10 times per platform and got all pass
> 2. All the four tests are run 10 times on Windows 11 and got all pass

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Removed extra blank line added to Util, no changes required in Util

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8316/files
  - new: https://git.openjdk.java.net/jdk/pull/8316/files/e0d63537..fae1d36a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8316&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8316&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8316.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8316/head:pull/8316

PR: https://git.openjdk.java.net/jdk/pull/8316


From mvs at openjdk.java.net  Thu Apr 28 22:21:38 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Thu, 28 Apr 2022 22:21:38 GMT
Subject: RFR: 8274597: Some of the dnd tests time out and fail
 intermittently [v2]
In-Reply-To: <LhNoZ8WmTxofgpc8gwmmYzG9_lezkJI5MgS0TZjEWGg=.70c18641-c309-4381-bc13-9849b296c880@github.com>
References: <PKtuBdvWgS96mNNJUmJbDu4WHk7yfGMXrXVahFBjio8=.25fcec82-0939-43b0-adeb-a6c1c6d9fe2f@github.com>
 <-M3RkI7ibFy3E3pyMdIyr-7-WWbZQXFo_4no53mvgDY=.761ad3d4-ff6c-4453-a328-173492e14616@github.com>
 <LhNoZ8WmTxofgpc8gwmmYzG9_lezkJI5MgS0TZjEWGg=.70c18641-c309-4381-bc13-9849b296c880@github.com>
Message-ID: <HHN05gkbuhBbLPOchO4H6V2fRkIoCyrxkKvVi3lo7fM=.3208be48-4c9b-41bb-9f70-2e6b70a0e73d@github.com>

On Wed, 27 Apr 2022 18:11:39 GMT, Phil Race <prr at openjdk.org> wrote:

>> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added blank line at end of file
>
> test/jdk/java/awt/regtesthelpers/Util.java line 325:
> 
>> 323:             robot.setAutoDelay(100);
>> 324:             autoDelaySet = true;
>> 325:         }
> 
> If this is the right place to fix it - in the Util class - then you can just call delay(100) in the places you need it - no need to set and then unset auto-delay.
> 
> Changing Util you will need to re-validate all tests that use this utility method.
> 
> Based on the explanation you gave ~mrserb I wonder if the test should also be waiting for the drop before disposing, not just throwing an arbitrary wait into the mix.

I have removed the changes done in Util.java and make the changes in all the 4 test files, so that the test will be waiting for the drop before disposing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8316


From duke at openjdk.java.net  Thu Apr 28 22:29:51 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 28 Apr 2022 22:29:51 GMT
Subject: RFR: 8285687 : Remove jtreg tag manual=yesno for
 ava/awt/print/PrinterJob/PageRangesDlgTest.java [v3]
In-Reply-To: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com>
References: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com>
Message-ID: <mTBmLRXI_aSpmubTE1tcefci2KEBv0SzUjwjx0DYEvg=.8cddc29e-76ad-4ce3-b83c-75283fc3bb71@github.com>

> 1) Fixed Parser error by removing  yesno from @run main/manual=yesno 
> 2) Used PassFaileJFrame to show the test instruction to the user instead of printing the test instruction on the console or jtreg log file. 
> 3) If printer is not configured then mark the test as passed.
> 
> @shurymury 
> @aivanov-jdk

lawrence.andrews has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8285687
 - Added @key printer since this test needs printer
 - 8285687 : Remove jtreg tag manual=yesno for ava/awt/print/PrinterJob/PageRangesDlgTest.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8412/files
  - new: https://git.openjdk.java.net/jdk/pull/8412/files/c178312a..4655a27a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8412&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8412&range=01-02

  Stats: 6443 lines in 206 files changed: 5220 ins; 440 del; 783 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8412.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8412/head:pull/8412

PR: https://git.openjdk.java.net/jdk/pull/8412


From serb at openjdk.java.net  Thu Apr 28 22:36:45 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Apr 2022 22:36:45 GMT
Subject: RFR: 8285686: Upgrade to FreeType 2.12.0
In-Reply-To: <tVRK-O11GP6MeVKBPFQY-ie5vA6qfBwkQTBKaD9HPWM=.5c669509-73fb-4ecb-b888-4f0945fa000c@github.com>
References: <tVRK-O11GP6MeVKBPFQY-ie5vA6qfBwkQTBKaD9HPWM=.5c669509-73fb-4ecb-b888-4f0945fa000c@github.com>
Message-ID: <9Ejkq4elVwt_pTMvbRlyO624bK--ja-TxpZn2nE8d-o=.9027b194-74db-4c9b-8b1e-91eef412c7f2@github.com>

On Thu, 28 Apr 2022 19:41:46 GMT, Phil Race <prr at openjdk.org> wrote:

> This upgrades the JDK from using freetype 2.10.4 to 2.12.0
> Automated tests pass, manual testing looks fine.
> --with-freetype=bundled was used to make sure it is OK on Linux builds.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8456


From serb at openjdk.java.net  Thu Apr 28 22:43:39 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Apr 2022 22:43:39 GMT
Subject: RFR: 8213531: Test javax/swing/border/TestTitledBorderLeak.java
 fails [v2]
In-Reply-To: <7f6imhO_fmNXVejmC3boQyV0uNjoHOJCiVzetcCOHpY=.b2d95eab-e3f7-45db-83ad-92e91e3a5585@github.com>
References: <Njia7F66IINfJqmT-OBEOXwoNbmPHh7ZuOHWzq2ZZLE=.228e4222-fbbb-45bc-9f02-cec6edaeb91d@github.com>
 <7f6imhO_fmNXVejmC3boQyV0uNjoHOJCiVzetcCOHpY=.b2d95eab-e3f7-45db-83ad-92e91e3a5585@github.com>
Message-ID: <b1x5axDbRrDpEYidpd3JDn4TzGDS5W0WLO6dmgD-7pM=.c345f63d-9fce-467e-ac17-5eded94e891d@github.com>

On Thu, 28 Apr 2022 13:34:31 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test was failing in linux citing `java.lang.RuntimeException: Expected Total TitledBorder to be freed : 10 Freed 9 `
>> As per the fix done in JDK-8204963 http://hg.openjdk.java.net/jdk/jdk/rev/cd7d2f9154fd
>> there was no platform specific code done for the fix and logs in `TitledBorder.installPropertyChangeListeners` shows it was called 10 times for the test but `CleanerFactory.cleaner().register` action was only called 9 times in linux causing it to fail.
>> 
>> Modified the test to not show the frame which cause the problem to go away and also it can still be used as 8204963 regression test as it still fails without the fix and pass with it. Modified test has passed in all platforms for several iterations.
>> 
>> Also removed the deprecated `System.runFinalization`
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

> Modified the test to not show the frame which cause the problem to go away

Does it mean that setVisible(true) cause some memory leak since it prevents the window to be disposed?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8450


From serb at openjdk.java.net  Thu Apr 28 22:45:51 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Apr 2022 22:45:51 GMT
Subject: RFR: 8254759: [TEST_BUG] [macosx]
 javax/swing/JInternalFrame/4202966/IntFrameCoord.html fails
In-Reply-To: <Xzq3WueM7chkh0W1Vwy-IztwkFFUV9aAxqvJ6Jj9Rt8=.f6065b51-f381-4b5e-a618-a692c17ffdb7@github.com>
References: <Xzq3WueM7chkh0W1Vwy-IztwkFFUV9aAxqvJ6Jj9Rt8=.f6065b51-f381-4b5e-a618-a692c17ffdb7@github.com>
Message-ID: <BerYwaPxR12_HjNr9GSGYv9y4IpTwrRgZsAi_c81TAw=.50d995a3-e257-47fa-9808-9c9fec7c6d2f@github.com>

On Thu, 28 Apr 2022 09:11:19 GMT, DamonGuy <duke at openjdk.java.net> wrote:

> Closed repo test fix from the test sprint. This test was approved in the closed repo and has been converted to an open repo test.
> 
> This test checks if the coordinates are still correct after changing focuses between different JInternalFrames. The test is now automated instead of manual like the previous, closed version. This needs to be a headful test to allow robot to click on the different frames and to check coordinates.
> 
> The issue was that in MacOS, the button wouldn't appear at a normal size. To fix this, the bounds have been increased to allow the button to be fully visible with the designated frame sizes on all L&Fs.

Please confirm that the mach5 is green for the few iterations.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8444


From naoto at openjdk.java.net  Thu Apr 28 23:14:42 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 28 Apr 2022 23:14:42 GMT
Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong
 size [v2]
In-Reply-To: <SAu4OKejClHuOK9uEAFVXIKnqfGBcfn3MtqNhuMoCPM=.fba07a11-93eb-494d-b098-62bd2b4fd107@github.com>
References: <z72T3X_wgR6K7BdFL7Tqg8t6GXbJh-Vk0pDGCJjUnEE=.ba87e570-fc0b-45d5-8099-9ffeeeb09fc5@github.com>
 <SAu4OKejClHuOK9uEAFVXIKnqfGBcfn3MtqNhuMoCPM=.fba07a11-93eb-494d-b098-62bd2b4fd107@github.com>
Message-ID: <tckHW63SLQeAbcrHYs_ZiNFcebyEaV3VPxg-C4SHyO8=.91e3e32a-bcaf-47b9-a684-19ae0313d385@github.com>

On Mon, 25 Apr 2022 08:15:18 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

>> Japanese logical fonts are drawn with wrong size since Java 18.
>> It's triggered by JEP 400, UTF-8 by Default. `sun.awt.FontConfiguration` (and `sun.awt.windows.WFontConfiguration`) seems to expect the native encoding instead of the default encoding. This patch changes to use native encoding.
>> 
>> Tested: jdk_desktop on Windows, Linux, and macOS
>
> Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved the fix to WFontConfiguration

The following diff seems to choose the right font:

--- a/src/java.desktop/windows/data/fontconfig/fontconfig.properties
+++ b/src/java.desktop/windows/data/fontconfig/fontconfig.properties
@@ -230,7 +230,7 @@ sequence.dialog.x-MS950-HKSCS-XP=alphabetic,chinese-ms950,ch
inese-hkscs,dingbats
 sequence.dialoginput.x-MS950-HKSCS-XP=alphabetic,chinese-ms950,chinese-hkscs,di
ngbats,symbol,chinese-ms950-extb

 sequence.allfonts.UTF-8.hi=alphabetic/1252,devanagari,dingbats,symbol
-sequence.allfonts.UTF-8.ja=alphabetic,japanese,dingbats,symbol
+sequence.allfonts.UTF-8.ja=japanese,alphabetic,dingbats,symbol

 sequence.allfonts.windows-1255=hebrew,alphabetic/1252,dingbats,symbol

This diff intends to choose the `japanese` set before the `alphabetic` set, in case for `ja` locale in `UTF-8` file encoding. I am not saying this is the right fix, but could be a starting point.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8329


From serb at openjdk.java.net  Thu Apr 28 23:20:43 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Apr 2022 23:20:43 GMT
Subject: RFR: 8284888 : [macos]
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with
 "NimbusLookAndFeel] : ERROR: icon and imageIcon not same."
In-Reply-To: <YDw1aahmhxdF-lXm-uHjCW4Gt46D8VGZ9f02a8pb56o=.b2b8c153-0fd4-4c46-8733-4017b5108baf@github.com>
References: <pfa7K1bO4jVy0R3GkJTdMJG5eYhcdgojfPL_pILKlOA=.c2789888-0055-47a7-9c95-19f5d0cf3be0@github.com>
 <1OYwEG8b8QLK1qYmQ3DIAL6XwKN-Le4-1ceI2-hX2u4=.6df0b3d6-c07e-46a6-8ecb-99ac2b65e075@github.com>
 <k2YkJg_Mi8gb2t6yE3Q3VYHZ5CrNkE0NHWqh0NMTWZg=.f1b0a738-fd58-488a-b595-7d743e0cd355@github.com>
 <YDw1aahmhxdF-lXm-uHjCW4Gt46D8VGZ9f02a8pb56o=.b2b8c153-0fd4-4c46-8733-4017b5108baf@github.com>
Message-ID: <vnlB4AbKGzx4OyCVtlcWKVOHHADkEzC1qUXjJh7U2uQ=.ab0b2523-f0a7-45d3-9b64-af4200732698@github.com>

On Wed, 27 Apr 2022 07:35:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Not sure I understand. It does not render same image twice but it renders an `ImageIcon `and an `Icon `and compare the bufferedimage of those 2 so I guess it alright to not have exact color check ` if (red1 != red2 || green1 != green2 || blue1 != blue2) {` and rely on color tolerance which we have in many tests involving bufferedimages..

Sure these are not the same images, but still, we render images and get different results, on one specific system? If the robot is not a root cause then looks like the difference occurrs somewhere in the rendering pipeline?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8380


From serb at openjdk.java.net  Thu Apr 28 23:23:44 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Apr 2022 23:23:44 GMT
Subject: RFR: 8274597: Some of the dnd tests time out and fail
 intermittently [v4]
In-Reply-To: <5d-F4QcZM_iIJcus08tRQjsDagQXd6Jar1_zMwFeB5M=.cb91b495-1863-4fe2-b3cd-a55b28cdcb9d@github.com>
References: <PKtuBdvWgS96mNNJUmJbDu4WHk7yfGMXrXVahFBjio8=.25fcec82-0939-43b0-adeb-a6c1c6d9fe2f@github.com>
 <5d-F4QcZM_iIJcus08tRQjsDagQXd6Jar1_zMwFeB5M=.cb91b495-1863-4fe2-b3cd-a55b28cdcb9d@github.com>
Message-ID: <CToZkgDBY4RUvfWNeDlbR729yAnUlTOZvnuupjsZet8=.06345672-968b-4aa1-9d1e-2972c6ae2d21@github.com>

On Thu, 28 Apr 2022 22:21:37 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> These dnd tests fails with a time out intermittently in some machines(mostly Windows 11) which creates frequent noise in CI.
>> 1. java/awt/dnd/AcceptDropMultipleTimes/AcceptDropMultipleTimes.java
>> 2. java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java
>> 3. java/awt/dnd/DropTargetEnterExitTest/ExtraDragEnterTest.java
>> 4. java/awt/dnd/MissingDragExitEventTest/MissingDragExitEventTest.java
>> 
>> Issue :
>> This doesn't seem to be a deadlock. When there is no sufficient delay after the mouse release(dragged mouse pointer release to drop the content), the frame is getting disposed even before the drop() method gets called. So it waits for the drop() method which will never happen as the frame has been already disposed and the test times out after some time.
>> 
>> Fix:
>> Waiting for the drop() method to get called before disposing the frame.
>> 
>> Testing: 
>> 1. All the four tests are run 10 times per platform and got all pass
>> 2. All the four tests are run 10 times on Windows 11 and got all pass
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed extra blank line added to Util, no changes required in Util

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8316


From serb at openjdk.java.net  Thu Apr 28 23:29:49 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Apr 2022 23:29:49 GMT
Subject: RFR: 6829250: Reg test:
 java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java fails in Windows
In-Reply-To: <L76k1XG6OONjtdJa2TlDSmthKUmOQmE6dMPO_dpS5eM=.51f88bb9-398f-4837-850c-ef0a5234c3bb@github.com>
References: <qDTR6A9kV9lbOGfZGYj5S5b9_M_5zhjvfak1NWPbwPY=.dce17901-1416-411a-a31f-f3f09d78389c@github.com>
 <YW26FpKhLBZ7OinfOhL65yoc4fpwrkXhZQAaJlA-LaQ=.e8f99138-58bc-45b1-ba18-24fa7d32db13@github.com>
 <L76k1XG6OONjtdJa2TlDSmthKUmOQmE6dMPO_dpS5eM=.51f88bb9-398f-4837-850c-ef0a5234c3bb@github.com>
Message-ID: <k3k4pbaeE7bFbHp2nC-Z5MYpIYCxM0Q6luKQ4E7MA2k=.71840622-3ce5-4791-8c93-5702d8a0eb9e@github.com>

On Wed, 27 Apr 2022 16:37:29 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> The MAXIMIZED_BOTH for undecorated frames works, however, for undecorated frames it allows window to overlap the taskbar so the window occupies the entirety of the screen. I do not think it is a bug.

It is a bug, it prevents the creation of the custom window decorations which behave like the native ones since the maximization action does not work. We have a number of JBS bugs for that, this one, then 4737788, and others see "relates to/duplicates"

-------------

PR: https://git.openjdk.java.net/jdk/pull/8314


From serb at openjdk.java.net  Thu Apr 28 23:31:47 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Apr 2022 23:31:47 GMT
Subject: RFR: 8285094: Test
 java/awt/Frame/InvisibleOwner/InvisibleOwner.java failing on Linux [v2]
In-Reply-To: <1FY4ypDIGUN3Hkz3R8hN6zyJonmrErTzUlU50bijZtw=.7ea435d2-6268-4454-9c58-e98fca7c8c20@github.com>
References: <nZJd4Qchm9OYGaFr3iBBm3XdYmqWXHzjfLElnUaCL90=.2fa7fc8c-23e2-46df-a5c5-acb33e7bf5fc@github.com>
 <1FY4ypDIGUN3Hkz3R8hN6zyJonmrErTzUlU50bijZtw=.7ea435d2-6268-4454-9c58-e98fca7c8c20@github.com>
Message-ID: <QMsStDYB4aI-rz7x62SLekpeQML-0AxDrSCuuI3cbPI=.8a7c5f63-19bc-4c63-83e3-6d39e0c552bb@github.com>

On Thu, 21 Apr 2022 15:23:31 GMT, Phil Race <prr at openjdk.org> wrote:

>> As discussed in https://bugs.openjdk.java.net/browse/JDK-8285094 it seems that the test
>> java/awt/Frame/GetGraphicsStressTest/GetGraphicsStressTest.java destabilises the Xserver.
>> This causes java/awt/Frame/InvisibleOwner/InvisibleOwner.java to fail and even before that
>> other tests which do  pass are not visibly behaving as expected.
>> 
>> I didn't find any Xserver logs of "bad stuff" happening so it just seems like the Xserver was
>> having trouble keeping up and JDK was behaving correctly as it could despite the Xserver sending
>> lots of requests to repaint.
>> 
>> Just the "sleep" at the end of GetGraphicsStressTest.java seems to be enough but I'd already
>> reworked InvisibleOwner.java and I'd like to think it is a bit better than before.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285094

Marked as reviewed by serb (Reviewer).

test/jdk/java/awt/Frame/GetGraphicsStressTest/GetGraphicsStressTest.java line 30:

> 28: /**
> 29:  * @test
> 30:  * @bug 8235638 8235739 8285094

It is not necessary to add bugid here, since this list is useful to verify the old bugs if the test will be reworked later.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8312


From serb at openjdk.java.net  Thu Apr 28 23:33:03 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Apr 2022 23:33:03 GMT
Subject: RFR: 8283624: Create an automated regression test for RFE-4390885
 [v4]
In-Reply-To: <ua67EQsKDpRJBS8ScbjUAeQsVvTWBLMW9OSVE5YoQSg=.235836cc-c780-4c35-9072-be094952ddd4@github.com>
References: <DfOvs0ck3_ucgdZG8gdlmXPriMoEM9-RjaveRlmRZYA=.b6690b6a-4a51-4c98-b5ee-6409fe4b0f84@github.com>
 <ua67EQsKDpRJBS8ScbjUAeQsVvTWBLMW9OSVE5YoQSg=.235836cc-c780-4c35-9072-be094952ddd4@github.com>
Message-ID: <WEa5tE5X9O5bo1v3eC7ASq6gGEOYAtAYEAOiwaLU57o=.a09266a5-d05e-4038-afdf-a6b1f10acc1f@github.com>

On Wed, 27 Apr 2022 10:17:16 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> Write a regression test for [JDK-4390885](https://bugs.openjdk.java.net/browse/JDK-4390885) Enhancement Request.
>> 
>> Issue:
>> Please add the ability to set the location of a JFileChooser. This might be a
>> bug, but JFileChooser.setLocation() has no effect when
>> JFileChooser.showXXXXDialog() is called. This is becoming very important as the
>> popularity of multiple monitors is increasing. These dialogs show up on the
>> wrong monitor which is really annoying. Also due to bug #4189244 I am unable to
>> avoid painting problems by positioning the dialog away from the menu item that
>> initiated it.
>> 
>> Fix:
>> Now it's possible to set the location of Dialog in JFileChooser.
>> 
>> Testing:
>> 1. Tested in Mach5 10 times per platform(macos,linux,windows) and got all Pass.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fixed: Accessed panel.getSize() in EDT

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7996


From duke at openjdk.java.net  Thu Apr 28 23:55:28 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 28 Apr 2022 23:55:28 GMT
Subject: RFR: 8285612 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java [v3]
In-Reply-To: <FjDS9wBgC4UrrnUaCoI-5tyAVVmg3FDQoNbPgij8rQI=.a18da791-1675-46dd-9ec8-cbd5f4f8a092@github.com>
References: <FjDS9wBgC4UrrnUaCoI-5tyAVVmg3FDQoNbPgij8rQI=.a18da791-1675-46dd-9ec8-cbd5f4f8a092@github.com>
Message-ID: <DL1Ks88asiPvxMNMeelRdvihqL_o7XDxbFxJ5IaymUA=.9e0b8e65-5760-47b5-bd43-6cacfe6c00e4@github.com>

> 1) Removed yesno to eliminate parserException
> 2) Added code to fit into manual framework so that timeout, pass & fail is handled.
> 3) Added code to mark the test as pass if printer service is not available
> 4) Added code to handle pressing or clicking of 'Cancel' button.
> 
> @shurymury 
> @aivanov-jdk

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  Added @key printer

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8391/files
  - new: https://git.openjdk.java.net/jdk/pull/8391/files/53aa04cb..eb44f668

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8391&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8391&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8391.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8391/head:pull/8391

PR: https://git.openjdk.java.net/jdk/pull/8391


From prr at openjdk.java.net  Fri Apr 29 00:10:33 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Apr 2022 00:10:33 GMT
Subject: RFR: 8285094: Test
 java/awt/Frame/InvisibleOwner/InvisibleOwner.java failing on Linux [v3]
In-Reply-To: <nZJd4Qchm9OYGaFr3iBBm3XdYmqWXHzjfLElnUaCL90=.2fa7fc8c-23e2-46df-a5c5-acb33e7bf5fc@github.com>
References: <nZJd4Qchm9OYGaFr3iBBm3XdYmqWXHzjfLElnUaCL90=.2fa7fc8c-23e2-46df-a5c5-acb33e7bf5fc@github.com>
Message-ID: <qaRpYKSKoYPnH4eMpvj3xWgrBvZWLD1mDfkGhKq9lCc=.c7a85b40-f38e-4bf9-87a2-93121b26aa63@github.com>

> As discussed in https://bugs.openjdk.java.net/browse/JDK-8285094 it seems that the test
> java/awt/Frame/GetGraphicsStressTest/GetGraphicsStressTest.java destabilises the Xserver.
> This causes java/awt/Frame/InvisibleOwner/InvisibleOwner.java to fail and even before that
> other tests which do  pass are not visibly behaving as expected.
> 
> I didn't find any Xserver logs of "bad stuff" happening so it just seems like the Xserver was
> having trouble keeping up and JDK was behaving correctly as it could despite the Xserver sending
> lots of requests to repaint.
> 
> Just the "sleep" at the end of GetGraphicsStressTest.java seems to be enough but I'd already
> reworked InvisibleOwner.java and I'd like to think it is a bit better than before.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8285094

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8312/files
  - new: https://git.openjdk.java.net/jdk/pull/8312/files/160b4eae..915e6aea

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8312&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8312&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8312.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8312/head:pull/8312

PR: https://git.openjdk.java.net/jdk/pull/8312


From prr at openjdk.java.net  Fri Apr 29 00:10:33 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Apr 2022 00:10:33 GMT
Subject: Integrated: 8285094: Test
 java/awt/Frame/InvisibleOwner/InvisibleOwner.java failing on Linux
In-Reply-To: <nZJd4Qchm9OYGaFr3iBBm3XdYmqWXHzjfLElnUaCL90=.2fa7fc8c-23e2-46df-a5c5-acb33e7bf5fc@github.com>
References: <nZJd4Qchm9OYGaFr3iBBm3XdYmqWXHzjfLElnUaCL90=.2fa7fc8c-23e2-46df-a5c5-acb33e7bf5fc@github.com>
Message-ID: <MMttrRfkd-92BpP7zqvZKAhXTnK-NRrv_J970HUWGgs=.902fcf16-1064-4237-b89f-c9bee9e40bf1@github.com>

On Wed, 20 Apr 2022 04:13:09 GMT, Phil Race <prr at openjdk.org> wrote:

> As discussed in https://bugs.openjdk.java.net/browse/JDK-8285094 it seems that the test
> java/awt/Frame/GetGraphicsStressTest/GetGraphicsStressTest.java destabilises the Xserver.
> This causes java/awt/Frame/InvisibleOwner/InvisibleOwner.java to fail and even before that
> other tests which do  pass are not visibly behaving as expected.
> 
> I didn't find any Xserver logs of "bad stuff" happening so it just seems like the Xserver was
> having trouble keeping up and JDK was behaving correctly as it could despite the Xserver sending
> lots of requests to repaint.
> 
> Just the "sleep" at the end of GetGraphicsStressTest.java seems to be enough but I'd already
> reworked InvisibleOwner.java and I'd like to think it is a bit better than before.

This pull request has now been integrated.

Changeset: 64d98ba1
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/64d98ba1001a24b301e5d8bce247f556fdcd39b2
Stats:     137 lines in 2 files changed: 73 ins; 9 del; 55 mod

8285094: Test java/awt/Frame/InvisibleOwner/InvisibleOwner.java failing on Linux

Reviewed-by: psadhukhan, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8312


From prr at openjdk.java.net  Fri Apr 29 00:16:44 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Apr 2022 00:16:44 GMT
Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong
 size [v2]
In-Reply-To: <tckHW63SLQeAbcrHYs_ZiNFcebyEaV3VPxg-C4SHyO8=.91e3e32a-bcaf-47b9-a684-19ae0313d385@github.com>
References: <z72T3X_wgR6K7BdFL7Tqg8t6GXbJh-Vk0pDGCJjUnEE=.ba87e570-fc0b-45d5-8099-9ffeeeb09fc5@github.com>
 <SAu4OKejClHuOK9uEAFVXIKnqfGBcfn3MtqNhuMoCPM=.fba07a11-93eb-494d-b098-62bd2b4fd107@github.com>
 <tckHW63SLQeAbcrHYs_ZiNFcebyEaV3VPxg-C4SHyO8=.91e3e32a-bcaf-47b9-a684-19ae0313d385@github.com>
Message-ID: <OdpsdaFI73JGq4Wzjg_KYQdyIhzg-_lMn4z-ut84c8Y=.3b105d73-0553-4339-9c63-2d32cf9b52d5@github.com>

On Thu, 28 Apr 2022 23:11:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The following diff seems to choose the right font:
> 
> ```
> --- a/src/java.desktop/windows/data/fontconfig/fontconfig.properties
> +++ b/src/java.desktop/windows/data/fontconfig/fontconfig.properties
> @@ -230,7 +230,7 @@ sequence.dialog.x-MS950-HKSCS-XP=alphabetic,chinese-ms950,ch
> inese-hkscs,dingbats
>  sequence.dialoginput.x-MS950-HKSCS-XP=alphabetic,chinese-ms950,chinese-hkscs,di
> ngbats,symbol,chinese-ms950-extb
> 
>  sequence.allfonts.UTF-8.hi=alphabetic/1252,devanagari,dingbats,symbol
> -sequence.allfonts.UTF-8.ja=alphabetic,japanese,dingbats,symbol
> +sequence.allfonts.UTF-8.ja=japanese,alphabetic,dingbats,symbol
> 
>  sequence.allfonts.windows-1255=hebrew,alphabetic/1252,dingbats,symbol
> ```
> 
> This diff intends to choose the `japanese` set before the `alphabetic` set, in case for `ja` locale in `UTF-8` file encoding. I am not saying this is the right fix, but could be a starting point.

I've been looking at that exact line since I think it is what we'd use in the new default locale
and also thinking about the "allfonts" issue we've seen with Korean.
And which font is "japanese" in this case ?
Maybe we want to fill out the UTF8.<lang> based locales in this file now that is the default 

I suspect it is a lot safer to do what Toshio is doing but I just want to understand the mechanism.
I didn't have all the JA fonts installed on my system and I've been trying but they don't seem to have
appeared yet, so specifically I don't have MS Mincho, so there's not much I can test yet.
It migh

-------------

PR: https://git.openjdk.java.net/jdk/pull/8329


From serb at openjdk.java.net  Fri Apr 29 00:26:44 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Apr 2022 00:26:44 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v3]
In-Reply-To: <o5b5cKS2vQBNzAUK1a9o_i1vriHLmPZF5CfeWNo3pVo=.685dbdf8-3470-426b-b777-b445f1f14bb1@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <QNwEljGPhlL8ImZFy0IGjfr7p8kenkdyliH6ic9UY_Y=.3ce0d201-7dcf-48d8-9fab-0b45c875a6c6@github.com>
 <l3-n06aLCnuDyt_zhUD39rskW34haYGoBDKmvxYbVJk=.31733d17-7089-43df-8c2c-2af7aa97d0b4@github.com>
 <7zYHFtn9L54eIDP49ZZtZA_kDPWwhwWTo1Zzy82gyYc=.21baf5bc-9604-4242-92d7-65bfb68cf9a0@github.com>
 <9YGqKP4x5N0miiskVwMoF201g7ng3JjTnJF5ctGkD5w=.9b763d6a-469d-49b0-83cd-79cc46cdfecd@github.com>
 <W6AqQeqEwesfv4ol5hrabENk_BbYhKB6ZPpFGSsqh_c=.a448304e-e2c9-4592-a8a7-9f16b6b64982@github.com>
 <o5b5cKS2vQBNzAUK1a9o_i1vriHLmPZF5CfeWNo3pVo=.685dbdf8-3470-426b-b777-b445f1f14bb1@github.com>
Message-ID: <Bphbxcyu4kTq0btWnVSulGL9qhsP3woiUTN8kapqtNk=.db4a5cba-70ec-4235-91d2-bd1aea5fa2db@github.com>

On Wed, 27 Apr 2022 15:41:33 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Why? As i shown in the test case the problem affects any ImageIcon based on the MultiResolutionImage. I'm not trying to solve the singular issue that in the Windows LaF - i am trying to eliminate the reason this problem can show up.

Default interpolation for all rendering in java2d is NN, if the user wants he may change it to any other modes. This is consistent for all types of images, and MultiResolutionImage is not any special. In this particular case the code where we call ImageIcon.paintIcon() may set different interpolation when some system property is set, similar to the [antialiasing](https://github.com/openjdk/jdk/blob/d5dacffaee5a3626e7c9994b5d24f9514926e40c/jdk/src/java.desktop/share/classes/sun/swing/SwingUtilities2.java#L480). But it is not so important since the root cause below.

> Because before that change we were using different binary API to retrieve icons. This API only allows gathering 8x8 and 16x16 icons. The new API can be used for requesting icons of any size but for some files it ignores the requested size and only returns 32x32 icon. In this case we creating the multi resolution image with that icon inside and allow icon painting routine do the scaling. As i shown in my test for this bug the scaling works poorly and here i'm trying to enhance it. Can it be done in WinLAF? Yes, absolutely, but it will not solve the more generic issue.

So this is the actual root cause of the problem: the change in behavior of the FileSystemView.getSystemIcon() caused by using a different API that ignores the passed size. Since the size 16x16 is the default size for getSystemIcon() it would be good to restore the old behavior(mix the new and old) and request the best resolution from the system. It will save some memory and provide the best performance.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7805


From serb at openjdk.java.net  Fri Apr 29 00:39:53 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Apr 2022 00:39:53 GMT
Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows
 scaling changes
In-Reply-To: <B0ZUOVjp3bUuieQfuMeFFgclV1lo94EwkLsJFRxINC0=.cad3d7e4-bb3c-4f97-878f-0d2ffccef61d@github.com>
References: <B0ZUOVjp3bUuieQfuMeFFgclV1lo94EwkLsJFRxINC0=.cad3d7e4-bb3c-4f97-878f-0d2ffccef61d@github.com>
Message-ID: <3HBkT_7SmunSZ1cby1bQtYO_qZ_XQtQHV42fQsI7_vg=.b1043cdc-3e4c-45d6-be69-24b67c1b9e8b@github.com>

On Thu, 28 Apr 2022 02:26:28 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

> In Windows when desktop scaling was changed the tray icons was distorted/blurred a bit each time scaling changes.
> 
> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario.
> 
> When DPI changes usually two messages are sent by windows -
> 
> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged)
> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging)
> 
> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update.

Did you have a chance to check why the WM_DPICHANGED does not work, any specific cases? It is used by checking the scale change for windows in AWT, and no issues were reported for that as far as I know.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8441


From serb at openjdk.java.net  Fri Apr 29 00:42:08 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Apr 2022 00:42:08 GMT
Subject: RFR: 8285693: Create an automated test for JDK-4702199
In-Reply-To: <MTg-FeYK5rgMiV-6xNy3f2TU86wShnNCyQXNNqTD_m0=.a2ec3667-5e74-43e4-8f38-215cec53443b@github.com>
References: <MTg-FeYK5rgMiV-6xNy3f2TU86wShnNCyQXNNqTD_m0=.a2ec3667-5e74-43e4-8f38-215cec53443b@github.com>
Message-ID: <UQ8fG7nCloo292URAsAQkNDvx39HHcwIrGxyvfZt_4E=.a6d039d7-3777-4da2-b890-f46abf8404c0@github.com>

On Wed, 27 Apr 2022 07:54:18 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> reate an automated test for [JDK-4702199](https://bugs.openjdk.java.net/browse/JDK-4702199)
> 
> In order for spatial Braille to work and screen reader "review mode", we need bounding rectangle information for all text on the screen, and also the ability to get text substrings. StarOffice 6.1, Netscape and GNOME accessibility also require this new interface for describing text in their applications. This new interface is required for accessibility to StarOffice 6.1, Netscape and GNOME applications as required by Section 508
> 
> The solution is to define a new interface and related two helper classes.
> AccessibleExtendedText,
> AccessibleTextSequence.
> AccessibleAttributeSequence
> 
> The test validates the public fields of the above classes.
> This review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8416


From serb at openjdk.java.net  Fri Apr 29 00:42:44 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Apr 2022 00:42:44 GMT
Subject: RFR: 7131823: bug in GIFImageReader [v3]
In-Reply-To: <IcHWyIghu2fjG930628ruMlpLUSZxqHzUQ_hnv4fgQI=.08340002-aaaa-4458-9a30-0fde8754e79a@github.com>
References: <LjpJTsq96m0N24mLMjS0p1aqlUBXvBHz9-E2uh4MPQU=.8df8c3ec-9271-498a-9f84-bff49db24e67@github.com>
 <IcHWyIghu2fjG930628ruMlpLUSZxqHzUQ_hnv4fgQI=.08340002-aaaa-4458-9a30-0fde8754e79a@github.com>
Message-ID: <2SCvR6NjjyvcUa3kzn65PoDVuYN6WITGWs80b1lSIWg=.7a23857d-4bb6-43a8-b934-d600ea66d359@github.com>

On Wed, 27 Apr 2022 22:10:43 GMT, Dan Lutker <duke at openjdk.java.net> wrote:

>> ?xception: Index 4096 out of bounds for length 4096
>> 
>> Adapted from https://github.com/openjdk/jfx/commit/7b7050c46299c0e6771ae02fbb5ceaf22104d3e4
>> 
>> # Testing done
>> Build locally on linux and ran jdk_imageio tests.
>
> Dan Lutker has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   7131823: bug in GIFImageReader

The updated code now uses NULL_CODE, so it covers both issues from the JBS. But does anybody have an idea what was the problem fixed by the "NULL_CODE", was and how hard to create a test for it?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8371


From serb at openjdk.java.net  Fri Apr 29 00:43:57 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Apr 2022 00:43:57 GMT
Subject: RFR: 8285687 : Remove jtreg tag manual=yesno for
 ava/awt/print/PrinterJob/PageRangesDlgTest.java [v3]
In-Reply-To: <mTBmLRXI_aSpmubTE1tcefci2KEBv0SzUjwjx0DYEvg=.8cddc29e-76ad-4ce3-b83c-75283fc3bb71@github.com>
References: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com>
 <mTBmLRXI_aSpmubTE1tcefci2KEBv0SzUjwjx0DYEvg=.8cddc29e-76ad-4ce3-b83c-75283fc3bb71@github.com>
Message-ID: <8bNWtvXyvA_PP2JTHxp9q7GnO2MgRDmdA7rycRApC5U=.150a085a-0161-4cd4-9979-5818b485218f@github.com>

On Thu, 28 Apr 2022 22:29:51 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> 1) Fixed Parser error by removing  yesno from @run main/manual=yesno 
>> 2) Used PassFaileJFrame to show the test instruction to the user instead of printing the test instruction on the console or jtreg log file. 
>> 3) If printer is not configured then mark the test as passed.
>> 
>> @shurymury 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8285687
>  - Added @key printer since this test needs printer
>  - 8285687 : Remove jtreg tag manual=yesno for ava/awt/print/PrinterJob/PageRangesDlgTest.java

Since the test now uses the printer keyword I doubt that it should pass silently if the printer is not installed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8412


From duke at openjdk.java.net  Fri Apr 29 01:20:39 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Fri, 29 Apr 2022 01:20:39 GMT
Subject: RFR: 8285687 : Remove jtreg tag manual=yesno for
 ava/awt/print/PrinterJob/PageRangesDlgTest.java [v3]
In-Reply-To: <8bNWtvXyvA_PP2JTHxp9q7GnO2MgRDmdA7rycRApC5U=.150a085a-0161-4cd4-9979-5818b485218f@github.com>
References: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com>
 <mTBmLRXI_aSpmubTE1tcefci2KEBv0SzUjwjx0DYEvg=.8cddc29e-76ad-4ce3-b83c-75283fc3bb71@github.com>
 <8bNWtvXyvA_PP2JTHxp9q7GnO2MgRDmdA7rycRApC5U=.150a085a-0161-4cd4-9979-5818b485218f@github.com>
Message-ID: <eq9DyfZcclhBqf9Do82zPANEfvbDh1lQDHTmEylXhOY=.7891f0f9-8dc8-40a5-b767-9a07c267b32f@github.com>

On Fri, 29 Apr 2022 00:41:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8285687
>>  - Added @key printer since this test needs printer
>>  - 8285687 : Remove jtreg tag manual=yesno for ava/awt/print/PrinterJob/PageRangesDlgTest.java
>
> Since the test now uses the printer keyword I doubt that it should pass silently if the printer is not installed.

@mrserb, run the test on Ubuntu 20.04 where printer is not configured and test passes as shown in the jtreg jtr file


----------messages:(5/203)----------
command: main PageRangesDlgTest
reason: User specified action: run main/manual PageRangesDlgTest 
Mode: othervm
Additional options from @modules: --add-modules java.desktop
elapsed time (seconds): 0.233
----------configuration:(3/40)----------
Boot Layer
  add modules: java.desktop

----------System.out:(1/59)----------
Printer not configured or available. Test cannot continue.
----------System.err:(1/15)----------
STATUS:Passed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8412


From duke at openjdk.java.net  Fri Apr 29 01:43:37 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Fri, 29 Apr 2022 01:43:37 GMT
Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows
 scaling changes
In-Reply-To: <3HBkT_7SmunSZ1cby1bQtYO_qZ_XQtQHV42fQsI7_vg=.b1043cdc-3e4c-45d6-be69-24b67c1b9e8b@github.com>
References: <B0ZUOVjp3bUuieQfuMeFFgclV1lo94EwkLsJFRxINC0=.cad3d7e4-bb3c-4f97-878f-0d2ffccef61d@github.com>
 <3HBkT_7SmunSZ1cby1bQtYO_qZ_XQtQHV42fQsI7_vg=.b1043cdc-3e4c-45d6-be69-24b67c1b9e8b@github.com>
Message-ID: <KiK7K2YQr0zcWbLKaij1DzTyA5mjKPR5qprXMR5UsFw=.cdccad09-f0bd-4fa6-8691-e69f9c07b1de@github.com>

On Fri, 29 Apr 2022 00:36:15 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Did you have a chance to check why the WM_DPICHANGED does not work, any specific cases? It is used by checking the scale change for windows in AWT, and no issues were reported for that as far as I know.

When DPI gets changed, many events are generated one after the other. By setting delays at various places in code I  observed that, the timing of triggering tray icon update could have effects on how it is rendered. 

When DPI is changed, along with `WM_DPICHANGED` msg the tray icon window's procedure receives `WMPOSCHANGING` and if we trigger a tray icon update before this, the icon gets distorted. I believe the cause for distortion might be - adding an icon to the system tray while it is still changing its size and position (WMPOSCHANGING) due to DPI changes. 

By triggering the update after `WMPOSCHANGING`, the tray icon gets added when all the updates to the System Tray are completed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8441


From mvs at openjdk.java.net  Fri Apr 29 04:13:46 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Fri, 29 Apr 2022 04:13:46 GMT
Subject: Integrated: 8283624: Create an automated regression test for
 RFE-4390885
In-Reply-To: <DfOvs0ck3_ucgdZG8gdlmXPriMoEM9-RjaveRlmRZYA=.b6690b6a-4a51-4c98-b5ee-6409fe4b0f84@github.com>
References: <DfOvs0ck3_ucgdZG8gdlmXPriMoEM9-RjaveRlmRZYA=.b6690b6a-4a51-4c98-b5ee-6409fe4b0f84@github.com>
Message-ID: <MO2rYjhLL4m38shjOR1hsrRaKjaL3vzBgkVaUfH2UtY=.1d0ee762-5571-44d4-8064-fc76cb05767d@github.com>

On Mon, 28 Mar 2022 14:17:17 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Write a regression test for [JDK-4390885](https://bugs.openjdk.java.net/browse/JDK-4390885) Enhancement Request.
> 
> Issue:
> Please add the ability to set the location of a JFileChooser. This might be a
> bug, but JFileChooser.setLocation() has no effect when
> JFileChooser.showXXXXDialog() is called. This is becoming very important as the
> popularity of multiple monitors is increasing. These dialogs show up on the
> wrong monitor which is really annoying. Also due to bug #4189244 I am unable to
> avoid painting problems by positioning the dialog away from the menu item that
> initiated it.
> 
> Fix:
> Now it's possible to set the location of Dialog in JFileChooser.
> 
> Testing:
> 1. Tested in Mach5 10 times per platform(macos,linux,windows) and got all Pass.

This pull request has now been integrated.

Changeset: 99388eff
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Abdul Kolarkunnu <akolarkunnu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/99388eff8da2cb3dc0bb34f05e8784795edb790e
Stats:     281 lines in 1 file changed: 281 ins; 0 del; 0 mod

8283624: Create an automated regression test for RFE-4390885

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/7996


From dholmes at openjdk.java.net  Fri Apr 29 05:12:30 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 29 Apr 2022 05:12:30 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings
In-Reply-To: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
Message-ID: <m9XwYrHV2pay3AEiq9vXKwSjyuZ0HaMbTDm7gMiJVPY=.5478a430-512d-423f-b68f-704733f46013@github.com>

On Wed, 27 Apr 2022 14:57:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
> Macros for Conditional Declarations
> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
> 
> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).

That only seems to be half of the issue though. If we are defining _WIN32_WINNT=0x0601 because the minimum required OS API support level is Windows 7, then don't we need a check that the build platform is also at least Windows 7?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8428


From serb at openjdk.java.net  Fri Apr 29 05:57:39 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Apr 2022 05:57:39 GMT
Subject: Integrated: 8264666: Change implementation of safeAdd/safeMult in the
 LCMSImageLayout class
In-Reply-To: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
References: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
Message-ID: <B_r-89aXF7FCqQ4ru4llnAIWyHYa49TDCLDD6ozaL8Y=.1e1a9d8c-c7e7-4e13-8c56-27bf950fbb6a@github.com>

On Fri, 2 Apr 2021 23:02:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Description of the new version of the fix:
> While I have worked on this change and tried to consider the comments, I have found that the usages of the "safeAdd/safeMult" in the LCMSImageLayout class are incorrect. Both methods are based on the "Math" versions but throw a different exception. The problem is that its implementation may accept the negative values during intermediate calculation, see the old implementation of "[verify](https://github.com/openjdk/jdk/blob/139615b1815d4afd3593536d83fa8b25430f35e7/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java#L343)" method:
>  1. We check the "offset" value: 0 <= offset <  dataArrayLength
>  2. We do some intermediate calculations that "accept" negative values
>  3. We check the final "off" value: 0 <= offset <  dataArrayLength
> 
> I wondered is it possible to provide some data that using wrong/negative data at step2 may result in the correct check at step3. I spent some time and was able to reproduce the problem with the attached test case. Note that the test is a little bit cryptic since it is not possible to reproduce it by input image data.
> 
> Note: I have removed all cleanup from the fix, to make it simpler.
> 
> <======>
> Description of the old version of the fix:
> - The hand-crafted methods for addition and multiplication are replaced by the "Math" versions.
> - Cleanup: the usage of do/while(false) is removed

This pull request has now been integrated.

Changeset: 40f19c01
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/40f19c014fed37b09db409cb9507f68f5011f139
Stats:     195 lines in 2 files changed: 169 ins; 15 del; 11 mod

8264666: Change implementation of safeAdd/safeMult in the LCMSImageLayout class

Reviewed-by: prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/3333


From serb at openjdk.java.net  Fri Apr 29 06:01:32 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Apr 2022 06:01:32 GMT
Subject: RFR: 8285687 : Remove jtreg tag manual=yesno for
 ava/awt/print/PrinterJob/PageRangesDlgTest.java [v3]
In-Reply-To: <8bNWtvXyvA_PP2JTHxp9q7GnO2MgRDmdA7rycRApC5U=.150a085a-0161-4cd4-9979-5818b485218f@github.com>
References: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com>
 <mTBmLRXI_aSpmubTE1tcefci2KEBv0SzUjwjx0DYEvg=.8cddc29e-76ad-4ce3-b83c-75283fc3bb71@github.com>
 <8bNWtvXyvA_PP2JTHxp9q7GnO2MgRDmdA7rycRApC5U=.150a085a-0161-4cd4-9979-5818b485218f@github.com>
Message-ID: <m12uh4yZpRKfnsqskDJhqaRR_g9o3SGb5_e0EPiDyug=.0c4a4461-9c0b-4c78-a063-9e9fe8be57d1@github.com>

On Fri, 29 Apr 2022 00:41:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> lawrence.andrews has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8285687
>>  - Added @key printer since this test needs printer
>>  - 8285687 : Remove jtreg tag manual=yesno for ava/awt/print/PrinterJob/PageRangesDlgTest.java
>
> Since the test now uses the printer keyword I doubt that it should pass silently if the printer is not installed.

> @mrserb, run the test on Ubuntu 20.04 where printer is not configured and test passes as shown in the jtreg jtr file

That's my point, why does the manual test for the printer silently pass if the printer is not installed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8412


From jdv at openjdk.java.net  Fri Apr 29 06:38:35 2022
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Fri, 29 Apr 2022 06:38:35 GMT
Subject: RFR: 8285686: Upgrade to FreeType 2.12.0
In-Reply-To: <tVRK-O11GP6MeVKBPFQY-ie5vA6qfBwkQTBKaD9HPWM=.5c669509-73fb-4ecb-b888-4f0945fa000c@github.com>
References: <tVRK-O11GP6MeVKBPFQY-ie5vA6qfBwkQTBKaD9HPWM=.5c669509-73fb-4ecb-b888-4f0945fa000c@github.com>
Message-ID: <2tTvQER8Mr4l6KPHUTTPYl1BfzB3LfcbqbJD2TWT4-c=.6e5b24c7-c1c6-4627-885b-31d0a845bc78@github.com>

On Thu, 28 Apr 2022 19:41:46 GMT, Phil Race <prr at openjdk.org> wrote:

> This upgrades the JDK from using freetype 2.10.4 to 2.12.0
> Automated tests pass, manual testing looks fine.
> --with-freetype=bundled was used to make sure it is OK on Linux builds.

Marked as reviewed by jdv (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8456


From mbaesken at openjdk.java.net  Fri Apr 29 07:05:40 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 29 Apr 2022 07:05:40 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings
In-Reply-To: <m9XwYrHV2pay3AEiq9vXKwSjyuZ0HaMbTDm7gMiJVPY=.5478a430-512d-423f-b68f-704733f46013@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <m9XwYrHV2pay3AEiq9vXKwSjyuZ0HaMbTDm7gMiJVPY=.5478a430-512d-423f-b68f-704733f46013@github.com>
Message-ID: <SbRAx5xiFk5Z0guL5ZOOlz4ulLz4K6PTiQkgXb1myyg=.10fd53be-cd26-4318-9d9a-e3cbb49c77cb@github.com>

On Fri, 29 Apr 2022 05:09:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> That only seems to be half of the issue though. If we are defining _WIN32_WINNT=0x0601 because the minimum required OS API support level is Windows 7, then don't we need a check that the build platform is also at least Windows 7?

Hi David,  on older OS than Windows 7 we wouldn't be able to build OJDK anyway currently. Our oldest VS we still support (see toolchain_microsoft.m4) is VS2017.  
VS2017 has the following system requirements 
https://docs.microsoft.com/en-us/visualstudio/releases/2017/vs2017-system-requirements-vs
see supported OS ,  there the oldest supported OS is Windows Server 2012 R2 and Windows 7 SP1. So on older than Win7 we would not even have a compiler anymore that passes configure.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8428


From mvs at openjdk.java.net  Fri Apr 29 08:23:12 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Fri, 29 Apr 2022 08:23:12 GMT
Subject: RFR: 8274597: Some of the dnd tests time out and fail
 intermittently [v5]
In-Reply-To: <PKtuBdvWgS96mNNJUmJbDu4WHk7yfGMXrXVahFBjio8=.25fcec82-0939-43b0-adeb-a6c1c6d9fe2f@github.com>
References: <PKtuBdvWgS96mNNJUmJbDu4WHk7yfGMXrXVahFBjio8=.25fcec82-0939-43b0-adeb-a6c1c6d9fe2f@github.com>
Message-ID: <CD034RBI3cjmFMknJ7SgUURZ4M1LMlRwAQhcOx5dSFo=.ea89504f-ca35-4576-bcb5-eb1eb3c9d2fd@github.com>

> These dnd tests fails with a time out intermittently in some machines(mostly Windows 11) which creates frequent noise in CI.
> 1. java/awt/dnd/AcceptDropMultipleTimes/AcceptDropMultipleTimes.java
> 2. java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java
> 3. java/awt/dnd/DropTargetEnterExitTest/ExtraDragEnterTest.java
> 4. java/awt/dnd/MissingDragExitEventTest/MissingDragExitEventTest.java
> 
> Issue :
> This doesn't seem to be a deadlock. When there is no sufficient delay after the mouse release(dragged mouse pointer release to drop the content), the frame is getting disposed even before the drop() method gets called. So it waits for the drop() method which will never happen as the frame has been already disposed and the test times out after some time.
> 
> Fix:
> Waiting for the drop() method to get called before disposing the frame.
> 
> Testing: 
> 1. All the four tests are run 10 times per platform and got all pass
> 2. All the four tests are run 10 times on Windows 11 and got all pass

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Some more stabilization: f.getLocationOnScreen() in EDT,frame made undecoratedand moved to center,added captureScreen when test fails

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8316/files
  - new: https://git.openjdk.java.net/jdk/pull/8316/files/fae1d36a..f55b4707

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8316&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8316&range=03-04

  Stats: 67 lines in 2 files changed: 50 ins; 3 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8316.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8316/head:pull/8316

PR: https://git.openjdk.java.net/jdk/pull/8316


From prappo at openjdk.java.net  Fri Apr 29 08:48:52 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 29 Apr 2022 08:48:52 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v5]
In-Reply-To: <-4fsP7Oz2b5SHJR3uPUb7dPXo8cVPj0lXNnCDAKgWGA=.7ab1337e-2e75-4dc9-85d8-fb9734ea598c@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com>
 <ly0yNqCx3P8EkbF_nagUNFG9fxo_DID-Q80BxAx9OZA=.93b1a3f1-00f7-4237-a36f-2268c7cedcb4@github.com>
 <-4fsP7Oz2b5SHJR3uPUb7dPXo8cVPj0lXNnCDAKgWGA=.7ab1337e-2e75-4dc9-85d8-fb9734ea598c@github.com>
Message-ID: <pGkmGP6Kv4-jzotC0k99b4kWdLBEyNf0swKLRTaF0n8=.00b80a95-55b4-404c-84f4-5b205e988692@github.com>

On Thu, 28 Apr 2022 19:06:04 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/ref/PhantomReference.java line 48:
>> 
>>> 46:  * The {@link #refersTo(Object) refersTo} method can be used to test
>>> 47:  * whether some object is the referent of a phantom reference.
>>> 48:  * @param<T> the type of the referent
>> 
>> Shouldn't there be a space after `@param` ?
>
> Good catch.  Sorry I missed it. This occurs in all `java/lang/ref` files.

> Shouldn't there be a space after `@param` ?

> Good catch. Sorry I missed it. This occurs in all `java/lang/ref` files.

I built the API documentation after this PR has been integrated and the result was okay. I saw this output in every such case:

Type Parameters:
T - the type of the referent

javadoc is quite robust. However, for some IDEs such missing whitespace seems significant. Not only do they highlight the `@param` tag, but the type parameter information is missing from the rendered output.

Although it's not critical, we should fix it; I have filed JDK-8285890.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410


From prappo at openjdk.java.net  Fri Apr 29 09:09:50 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 29 Apr 2022 09:09:50 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v5]
In-Reply-To: <pGkmGP6Kv4-jzotC0k99b4kWdLBEyNf0swKLRTaF0n8=.00b80a95-55b4-404c-84f4-5b205e988692@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com>
 <ly0yNqCx3P8EkbF_nagUNFG9fxo_DID-Q80BxAx9OZA=.93b1a3f1-00f7-4237-a36f-2268c7cedcb4@github.com>
 <-4fsP7Oz2b5SHJR3uPUb7dPXo8cVPj0lXNnCDAKgWGA=.7ab1337e-2e75-4dc9-85d8-fb9734ea598c@github.com>
 <pGkmGP6Kv4-jzotC0k99b4kWdLBEyNf0swKLRTaF0n8=.00b80a95-55b4-404c-84f4-5b205e988692@github.com>
Message-ID: <s7jcRxpCdX__MjSee5C2uABNv4DJwAw1t8Vz-PScIB4=.ad944e3a-6f20-4b9e-97e7-e463a6766405@github.com>

On Fri, 29 Apr 2022 08:45:42 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Good catch. Sorry I missed it. This occurs in all `java/lang/ref` files.

I've created a PR; feel free to review it at your convenience.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410


From mvs at openjdk.java.net  Fri Apr 29 10:37:43 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Fri, 29 Apr 2022 10:37:43 GMT
Subject: Integrated: 8274597: Some of the dnd tests time out and fail
 intermittently
In-Reply-To: <PKtuBdvWgS96mNNJUmJbDu4WHk7yfGMXrXVahFBjio8=.25fcec82-0939-43b0-adeb-a6c1c6d9fe2f@github.com>
References: <PKtuBdvWgS96mNNJUmJbDu4WHk7yfGMXrXVahFBjio8=.25fcec82-0939-43b0-adeb-a6c1c6d9fe2f@github.com>
Message-ID: <4jMQ1O6S4XJiMzgqYs4_O02HKXDj-fWU6DVrXxheWbM=.2e166c0d-5f26-4d49-9839-ac10593f00da@github.com>

On Wed, 20 Apr 2022 13:03:48 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> These dnd tests fails with a time out intermittently in some machines(mostly Windows 11) which creates frequent noise in CI.
> 1. java/awt/dnd/AcceptDropMultipleTimes/AcceptDropMultipleTimes.java
> 2. java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java
> 3. java/awt/dnd/DropTargetEnterExitTest/ExtraDragEnterTest.java
> 4. java/awt/dnd/MissingDragExitEventTest/MissingDragExitEventTest.java
> 
> Issue :
> This doesn't seem to be a deadlock. When there is no sufficient delay after the mouse release(dragged mouse pointer release to drop the content), the frame is getting disposed even before the drop() method gets called. So it waits for the drop() method which will never happen as the frame has been already disposed and the test times out after some time.
> 
> Fix:
> Waiting for the drop() method to get called before disposing the frame.
> 
> Testing: 
> 1. All the four tests are run 10 times per platform and got all pass
> 2. All the four tests are run 10 times on Windows 11 and got all pass

This pull request has now been integrated.

Changeset: 669ac611
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Abdul Kolarkunnu <akolarkunnu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/669ac611b269bbda5c53d84173e5c9d0eb4ce919
Stats:     159 lines in 4 files changed: 107 ins; 12 del; 40 mod

8274597: Some of the dnd tests time out and fail intermittently
8028998: [TEST_BUG] [macosx] java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java failed

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8316


From zgu at openjdk.java.net  Fri Apr 29 12:43:41 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 29 Apr 2022 12:43:41 GMT
Subject: RFR: 8284680: sun.font.FontConfigManager.getFontConfig() leaks
 charset [v2]
In-Reply-To: <MgzLHY7B6i7YyEzX8rkn-cEdkDamqKvNofwkrf1JIKI=.72ba1959-fe21-4f4e-a346-0feb5ae4037c@github.com>
References: <MgzLHY7B6i7YyEzX8rkn-cEdkDamqKvNofwkrf1JIKI=.72ba1959-fe21-4f4e-a346-0feb5ae4037c@github.com>
Message-ID: <2fPQGLdkv7f9ThHEpS9RleMYUPHhBMK6GHGFJ0mnwbQ=.df2d6df8-6e4e-4ef4-93db-6e13bf369ea3@github.com>

> Please review this small patch that releases temporary charsets to avoid memory leak.
> 
> Test:
> 
> - [x] jdk_2d

Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:

  Andrew's comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8187/files
  - new: https://git.openjdk.java.net/jdk/pull/8187/files/ce50c4e9..92ed6a78

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8187&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8187&range=00-01

  Stats: 11 lines in 1 file changed: 7 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8187.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8187/head:pull/8187

PR: https://git.openjdk.java.net/jdk/pull/8187


From smandalika at openjdk.java.net  Fri Apr 29 14:11:41 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Fri, 29 Apr 2022 14:11:41 GMT
Subject: RFR: 8285373: Create an automated test for JDK-4702233 [v2]
In-Reply-To: <zrkWQo-BoTq0XlQX_0_-CwnPIKkCge6wW8E5EqLAYRs=.2345ef0a-25eb-414c-ade6-de10d49d2bbe@github.com>
References: <zrkWQo-BoTq0XlQX_0_-CwnPIKkCge6wW8E5EqLAYRs=.2345ef0a-25eb-414c-ade6-de10d49d2bbe@github.com>
Message-ID: <z0o-FHmf-wr2qSy6UnFl-Ti8k67x5Gyqdz6kvoeJvx4=.5890d850-6b28-4de0-9d4c-eeb22d6744f8@github.com>

> Create an automated test for [JDK-4702233](https://bugs.openjdk.java.net/browse/JDK-4702233)
> 
> Several new AccessibleRole and AccessibleRelation constants are needed in those classes in the java.accessibility package. These new contants codify additions made in the GNOME, Netscape, and UNO (StarOffice) accessibility APIs.
> StarOffice 6.1 and GNOME accessibility require new role, state and relation
> constants in the javax.accessibility package. The existing constants are
> inadequate for providing accessibility to StarOffice and GNOME applications
> as required by Section 508.
> 
> Solution
> --------
> Define new constants in the javax.accessibility package.
> AccessibleRelation
> AccessibleRoles
> AccessibleState
> AccessibleAction
> AccessibleContext
> 
> The test validates the public fields of the above AccessibleConstants.
> 
> This review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Added missing CopyRight Header

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8342/files
  - new: https://git.openjdk.java.net/jdk/pull/8342/files/4e20fbc6..7715eb83

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8342&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8342&range=00-01

  Stats: 32 lines in 1 file changed: 29 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8342.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8342/head:pull/8342

PR: https://git.openjdk.java.net/jdk/pull/8342


From prr at openjdk.java.net  Fri Apr 29 16:43:48 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Apr 2022 16:43:48 GMT
Subject: Integrated: 8285686: Upgrade to FreeType 2.12.0
In-Reply-To: <tVRK-O11GP6MeVKBPFQY-ie5vA6qfBwkQTBKaD9HPWM=.5c669509-73fb-4ecb-b888-4f0945fa000c@github.com>
References: <tVRK-O11GP6MeVKBPFQY-ie5vA6qfBwkQTBKaD9HPWM=.5c669509-73fb-4ecb-b888-4f0945fa000c@github.com>
Message-ID: <xZeG1oOnMsFYy01dvTTINPKJk-QCSleLHIVqHmOsY0o=.57039f3e-a5b8-4cc9-aba8-24e65df73045@github.com>

On Thu, 28 Apr 2022 19:41:46 GMT, Phil Race <prr at openjdk.org> wrote:

> This upgrades the JDK from using freetype 2.10.4 to 2.12.0
> Automated tests pass, manual testing looks fine.
> --with-freetype=bundled was used to make sure it is OK on Linux builds.

This pull request has now been integrated.

Changeset: 67dd8a8d
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/67dd8a8d6a3f069f11d8e1492a775892f1f49829
Stats:     10933 lines in 293 files changed: 6807 ins; 2146 del; 1980 mod

8285686: Upgrade to FreeType 2.12.0

Reviewed-by: serb, jdv

-------------

PR: https://git.openjdk.java.net/jdk/pull/8456


From prr at openjdk.java.net  Fri Apr 29 16:54:45 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Apr 2022 16:54:45 GMT
Subject: RFR: 8285687 : Remove jtreg tag manual=yesno for
 ava/awt/print/PrinterJob/PageRangesDlgTest.java [v3]
In-Reply-To: <mTBmLRXI_aSpmubTE1tcefci2KEBv0SzUjwjx0DYEvg=.8cddc29e-76ad-4ce3-b83c-75283fc3bb71@github.com>
References: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com>
 <mTBmLRXI_aSpmubTE1tcefci2KEBv0SzUjwjx0DYEvg=.8cddc29e-76ad-4ce3-b83c-75283fc3bb71@github.com>
Message-ID: <wL5uix0dSbA47b8GrF61mK4uvADvw3olpxxrcBw2phI=.1f9bd696-37a7-4f64-823b-bf1039d33642@github.com>

On Thu, 28 Apr 2022 22:29:51 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> 1) Fixed Parser error by removing  yesno from @run main/manual=yesno 
>> 2) Used PassFaileJFrame to show the test instruction to the user instead of printing the test instruction on the console or jtreg log file. 
>> 3) If printer is not configured then mark the test as passed.
>> 
>> @shurymury 
>> @aivanov-jdk
>
> lawrence.andrews has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8285687
>  - Added @key printer since this test needs printer
>  - 8285687 : Remove jtreg tag manual=yesno for ava/awt/print/PrinterJob/PageRangesDlgTest.java

One thing we could start to do is use jtreg.SkippedException - which you define yourself.
It is a "special" in that jtreg recognises it as meaning a test was skipped due to some reason
that could not/was not determined before running. 
The test passes but with a special message so you know it didn't really run the test.
https://openjdk.java.net/jtreg/faq.html#what-if-a-test-does-not-apply-in-a-given-situation

For manual tests it might be good to change PassFailJFrame to be able to put up a  special message to the user in such a case and  disable "fail" ..

-------------

PR: https://git.openjdk.java.net/jdk/pull/8412


From prr at openjdk.java.net  Fri Apr 29 16:57:43 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Apr 2022 16:57:43 GMT
Subject: RFR: 8254759: [TEST_BUG] [macosx]
 javax/swing/JInternalFrame/4202966/IntFrameCoord.html fails
In-Reply-To: <Xzq3WueM7chkh0W1Vwy-IztwkFFUV9aAxqvJ6Jj9Rt8=.f6065b51-f381-4b5e-a618-a692c17ffdb7@github.com>
References: <Xzq3WueM7chkh0W1Vwy-IztwkFFUV9aAxqvJ6Jj9Rt8=.f6065b51-f381-4b5e-a618-a692c17ffdb7@github.com>
Message-ID: <U3TViHA6RlUjl9RmTHsigK3IY-T5fDLYZuiOheuxz0o=.7b475602-adfa-4bd3-92a0-de1b0df54d5a@github.com>

On Thu, 28 Apr 2022 09:11:19 GMT, DamonGuy <duke at openjdk.java.net> wrote:

> Closed repo test fix from the test sprint. This test was approved in the closed repo and has been converted to an open repo test.
> 
> This test checks if the coordinates are still correct after changing focuses between different JInternalFrames. The test is now automated instead of manual like the previous, closed version. This needs to be a headful test to allow robot to click on the different frames and to check coordinates.
> 
> The issue was that in MacOS, the button wouldn't appear at a normal size. To fix this, the bounds have been increased to allow the button to be fully visible with the designated frame sizes on all L&Fs.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8444


From prr at openjdk.java.net  Fri Apr 29 17:03:43 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Apr 2022 17:03:43 GMT
Subject: RFR: JDK-8282772: JButton text set as HTML content has unwanted
 padding [v2]
In-Reply-To: <KAUjhQE2nCh3gy2DworUnO3Jet9hlgORvxwnSShdIyg=.a0ef5921-94f0-4ab2-860e-1cafb45f37cc@github.com>
References: <IZSuTxegoGBNFqjBNLrh4P_xp2g7nSB5ylXRfMSXSCM=.3ff25a09-3671-41b2-be73-e3912c6c67b1@github.com>
 <KAUjhQE2nCh3gy2DworUnO3Jet9hlgORvxwnSShdIyg=.a0ef5921-94f0-4ab2-860e-1cafb45f37cc@github.com>
Message-ID: <rTyH-SWmwpUaCD1Y4CxnDO1xsVyQXvBgW9_rHAcNn5Y=.8a6f6c2c-c40f-4bfc-932c-4019a34492cf@github.com>

On Wed, 27 Apr 2022 18:52:46 GMT, DamonGuy <duke at openjdk.java.net> wrote:

>> The insets for buttons were incorrect for L&Fs except for Aqua when the text is set to HTML. This was fixed in Aqua by adding a conditional to check for the BasicHTML property key in the button component. This same logic can be used to fix Metal & Motif L&Fs in BasicButtonUI, but Nimbus is not fixed by this. Nimbus gets its default values from a skin.laf file, and when the defaults here are set to have left & right insets to 0 for ButtonUI, the issue is fixed. I also tested for non-HTML text after the changes, and the changes do not affect normal text.
>> 
>> The HtmlButtonImageTest has been changed to cycle through all L&Fs available on a device.
>
> DamonGuy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed approach to fix.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8407


From duke at openjdk.java.net  Fri Apr 29 17:21:53 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Fri, 29 Apr 2022 17:21:53 GMT
Subject: RFR: 8254759: [TEST_BUG] [macosx]
 javax/swing/JInternalFrame/4202966/IntFrameCoord.html fails
In-Reply-To: <BerYwaPxR12_HjNr9GSGYv9y4IpTwrRgZsAi_c81TAw=.50d995a3-e257-47fa-9808-9c9fec7c6d2f@github.com>
References: <Xzq3WueM7chkh0W1Vwy-IztwkFFUV9aAxqvJ6Jj9Rt8=.f6065b51-f381-4b5e-a618-a692c17ffdb7@github.com>
 <BerYwaPxR12_HjNr9GSGYv9y4IpTwrRgZsAi_c81TAw=.50d995a3-e257-47fa-9808-9c9fec7c6d2f@github.com>
Message-ID: <Z10BXziwYHLVjmiUp_t0l068Wf4ZvF7zMrffHQ8TcsI=.15d98168-742f-4e17-9a20-60463feb66f8@github.com>

On Thu, 28 Apr 2022 22:42:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please confirm that the mach5 is green for the few iterations.

I ran the test locally 50 times and it all passed. I also ran the test in mach5 with repeats and it all passed as well. Added results to JBS.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8444


From kizune at openjdk.java.net  Fri Apr 29 18:55:37 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 29 Apr 2022 18:55:37 GMT
Subject: RFR: 8254759: [TEST_BUG] [macosx]
 javax/swing/JInternalFrame/4202966/IntFrameCoord.html fails
In-Reply-To: <Xzq3WueM7chkh0W1Vwy-IztwkFFUV9aAxqvJ6Jj9Rt8=.f6065b51-f381-4b5e-a618-a692c17ffdb7@github.com>
References: <Xzq3WueM7chkh0W1Vwy-IztwkFFUV9aAxqvJ6Jj9Rt8=.f6065b51-f381-4b5e-a618-a692c17ffdb7@github.com>
Message-ID: <2lbnqK6QLGqDhIDSAmWHdadVQh-WXxIMy7FlVpiRXQg=.4b6821e8-6a36-4bb8-a6e2-6a5105426f1e@github.com>

On Thu, 28 Apr 2022 09:11:19 GMT, DamonGuy <duke at openjdk.java.net> wrote:

> Closed repo test fix from the test sprint. This test was approved in the closed repo and has been converted to an open repo test.
> 
> This test checks if the coordinates are still correct after changing focuses between different JInternalFrames. The test is now automated instead of manual like the previous, closed version. This needs to be a headful test to allow robot to click on the different frames and to check coordinates.
> 
> The issue was that in MacOS, the button wouldn't appear at a normal size. To fix this, the bounds have been increased to allow the button to be fully visible with the designated frame sizes on all L&Fs.

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8444


From duke at openjdk.java.net  Fri Apr 29 20:26:23 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Fri, 29 Apr 2022 20:26:23 GMT
Subject: RFR: 8285687 : Remove jtreg tag manual=yesno for
 ava/awt/print/PrinterJob/PageRangesDlgTest.java [v4]
In-Reply-To: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com>
References: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com>
Message-ID: <92Ifw18mxDgktPFDLpsnC743RLYog6CxXVcQC3rMlHo=.973c3c8e-a531-430e-a714-5c3b870cb4f0@github.com>

> 1) Fixed Parser error by removing  yesno from @run main/manual=yesno 
> 2) Used PassFaileJFrame to show the test instruction to the user instead of printing the test instruction on the console or jtreg log file. 
> 3) If printer is not configured then mark the test as passed.
> 
> @shurymury 
> @aivanov-jdk

lawrence.andrews has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8285687
 - Merge branch 'openjdk:master' into JDK-8285687
 - Added @key printer since this test needs printer
 - 8285687 : Remove jtreg tag manual=yesno for ava/awt/print/PrinterJob/PageRangesDlgTest.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8412/files
  - new: https://git.openjdk.java.net/jdk/pull/8412/files/4655a27a..446292ac

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8412&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8412&range=02-03

  Stats: 13123 lines in 362 files changed: 8418 ins; 2471 del; 2234 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8412.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8412/head:pull/8412

PR: https://git.openjdk.java.net/jdk/pull/8412


From duke at openjdk.java.net  Fri Apr 29 20:30:53 2022
From: duke at openjdk.java.net (DamonGuy)
Date: Fri, 29 Apr 2022 20:30:53 GMT
Subject: Integrated: 8254759: [TEST_BUG] [macosx]
 javax/swing/JInternalFrame/4202966/IntFrameCoord.html fails
In-Reply-To: <Xzq3WueM7chkh0W1Vwy-IztwkFFUV9aAxqvJ6Jj9Rt8=.f6065b51-f381-4b5e-a618-a692c17ffdb7@github.com>
References: <Xzq3WueM7chkh0W1Vwy-IztwkFFUV9aAxqvJ6Jj9Rt8=.f6065b51-f381-4b5e-a618-a692c17ffdb7@github.com>
Message-ID: <UcksjmYLhHUTkporGnqftNSaPJB4WyFAalzhpgDHA_4=.695c3d58-1f12-4d77-8cec-02e6e64751ee@github.com>

On Thu, 28 Apr 2022 09:11:19 GMT, DamonGuy <duke at openjdk.java.net> wrote:

> Closed repo test fix from the test sprint. This test was approved in the closed repo and has been converted to an open repo test.
> 
> This test checks if the coordinates are still correct after changing focuses between different JInternalFrames. The test is now automated instead of manual like the previous, closed version. This needs to be a headful test to allow robot to click on the different frames and to check coordinates.
> 
> The issue was that in MacOS, the button wouldn't appear at a normal size. To fix this, the bounds have been increased to allow the button to be fully visible with the designated frame sizes on all L&Fs.

This pull request has now been integrated.

Changeset: 2dd882af
Author:    Damon Nguyen <damon.nguyen at oracle.com>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2dd882af0830f174810840affa79045db4f04ef0
Stats:     145 lines in 1 file changed: 145 ins; 0 del; 0 mod

8254759: [TEST_BUG] [macosx] javax/swing/JInternalFrame/4202966/IntFrameCoord.html fails

Reviewed-by: prr, kizune

-------------

PR: https://git.openjdk.java.net/jdk/pull/8444


From duke at openjdk.java.net  Fri Apr 29 20:37:30 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Fri, 29 Apr 2022 20:37:30 GMT
Subject: RFR: 8285687 : Remove jtreg tag manual=yesno for
 ava/awt/print/PrinterJob/PageRangesDlgTest.java [v5]
In-Reply-To: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com>
References: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com>
Message-ID: <lIVMoVApEFi4EUemmpupdviToLxMudJqo75IxuxdVRQ=.2584f3cc-5526-434e-8f32-6fe501914e2f@github.com>

> 1) Fixed Parser error by removing  yesno from @run main/manual=yesno 
> 2) Used PassFaileJFrame to show the test instruction to the user instead of printing the test instruction on the console or jtreg log file. 
> 3) If printer is not configured then mark the test as passed.
> 
> @shurymury 
> @aivanov-jdk

lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision:

 - Added jtreg.SkippedException
 - Added jtreg.SkippedException

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8412/files
  - new: https://git.openjdk.java.net/jdk/pull/8412/files/446292ac..44f8aee3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8412&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8412&range=03-04

  Stats: 44 lines in 2 files changed: 42 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8412.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8412/head:pull/8412

PR: https://git.openjdk.java.net/jdk/pull/8412


From duke at openjdk.java.net  Fri Apr 29 22:48:00 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Fri, 29 Apr 2022 22:48:00 GMT
Subject: RFR: 8285867 : Convert applet manual tests SelectionVisible.java to
 Frame and automate
Message-ID: <eYCSkf6KBIobNTjUnRYORuwHGILHfi8OBjdhjMKaJL4=.c7604c78-0962-4101-b3ed-d825b3461486@github.com>

1) Removed Applet dependent code and used Frame as top level.
2) Automated the manual test.

@shurymury

-------------

Commit messages:
 - 8285867 : Convert applet manual tests SelectionVisible.java to Frame and automate

Changes: https://git.openjdk.java.net/jdk/pull/8477/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8477&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285867
  Stats: 212 lines in 4 files changed: 71 ins; 116 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8477.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8477/head:pull/8477

PR: https://git.openjdk.java.net/jdk/pull/8477


From serb at openjdk.java.net  Sat Apr 30 02:52:44 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 30 Apr 2022 02:52:44 GMT
Subject: RFR: 8254759: [TEST_BUG] [macosx]
 javax/swing/JInternalFrame/4202966/IntFrameCoord.html fails
In-Reply-To: <Xzq3WueM7chkh0W1Vwy-IztwkFFUV9aAxqvJ6Jj9Rt8=.f6065b51-f381-4b5e-a618-a692c17ffdb7@github.com>
References: <Xzq3WueM7chkh0W1Vwy-IztwkFFUV9aAxqvJ6Jj9Rt8=.f6065b51-f381-4b5e-a618-a692c17ffdb7@github.com>
Message-ID: <CvadOx6ZGnEbsjvGpMaP3_2FJzXTDRjO5YT75N3iCwE=.5a46d321-197c-48a3-a6a8-82cae65be558@github.com>

On Thu, 28 Apr 2022 09:11:19 GMT, DamonGuy <duke at openjdk.java.net> wrote:

> Closed repo test fix from the test sprint. This test was approved in the closed repo and has been converted to an open repo test.
> 
> This test checks if the coordinates are still correct after changing focuses between different JInternalFrames. The test is now automated instead of manual like the previous, closed version. This needs to be a headful test to allow robot to click on the different frames and to check coordinates.
> 
> The issue was that in MacOS, the button wouldn't appear at a normal size. To fix this, the bounds have been increased to allow the button to be fully visible with the designated frame sizes on all L&Fs.

test/jdk/javax/swing/JInternalFrame/4202966/IntFrameCoord.java line 77:

> 75:         };
> 76: 
> 77:         b.addMouseListener(mouseListener);

Note that b/if1/if2 are Swing components and should be accessed on the EDT

-------------

PR: https://git.openjdk.java.net/jdk/pull/8444